#juju 2012-01-09
<koolhead17> hi all
<nijaba> Good morning from budapest
<koolhead17> morning nijaba :)
<_mup_> juju/ssh-known_hosts r479 committed by jim.baker@canonical.com
<_mup_> Merged trunk
<hazmat> hazmat
<hazmat> jimbaker, bcsaller roadmap to fwereade's branches http://pastebin.ubuntu.com/798034/
<poolie> hello
<hazmat> hi poolie
<poolie> does juju work (well?) against openstack?
<hazmat> poolie, indeed it does
<hazmat> poolie, tested against canonistack
<poolie> hm ok
<poolie> that's good
<hazmat> i haven't done it recently, but several demos have been done against it (juju+openstack+orchestra)
<poolie> ok
<poolie> are you at the rally?
<hazmat> poolie, yup, we've got a room.. not sure which one it is
 * hazmat looks around for directions
<hazmat> we're in kazincy
<poolie> hm
<poolie> maybe i'll come find you
<hazmat> poolie, sure, or ask here, out of curiosity what room are you in?
<poolie> Huba
<bl> Hey,im trying to set up juju alongside ubuntu orchestra...but i get an invalid ssh error when i try juju status
<bl> will post my output
<bl> $ juju status 2012-01-09 17:52:52,066 INFO Connecting to environment. 2012-01-09 17:52:52,177 ERROR Invalid SSH key Cannot connect to machine MTMyNjA5NjExMy4xNDg4NzcyNDIuMDUwOTc (perhaps still initializing): Invalid SSH key 2012-01-09 17:52:52,182 ERROR Cannot connect to machine MTMyNjA5NjExMy4xNDg4NzcyNDIuMDUwOTc (perhaps still initializing): Invalid SSH key
<bl> any help would be appreciated :)
<fwereade> bl: nothing immediately springs to mind; but, just in case, would you pastebin the output of "juju -v status"?
<bl> sure
<bl> juju -v status 2012-01-09 18:00:40,633 DEBUG Initializing juju status runtime 2012-01-09 18:00:40,660 INFO Connecting to environment. 2012-01-09 18:00:40,660 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="oneiric01.ubuntu.lan" remote_port="2181" local_port="48457". 2012-01-09 18:00:40,778 ERROR Invalid SSH key Traceback (most recent call last):   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 388
<bl> err..one min
<bl> sorry
<bl> http://pastebin.com/crhqfNj7
<fwereade> bl: do you have any way of seeing what that machine is actually doing right now? I understand that may be tricky without ssh...
<fwereade> bl: because installing everything can take a fair while...
<bl> yes, i'll explain the scenario here..i have a lab,each computer has a seperate display
<bl> thing is when i try to ssh with its hostname
<bl> it works
<bl> but with juju it doesnt
<fwereade> bl: hm, that's very interesting
<fwereade> bl: so, to everything except juju, it looks as though it's installed everything including the ssh key?
<bl> yes,thats correct
<bl> i can ssh back and forth between the two machines
<bl> not a problem
<bl> only with juju status it seems to be giving me an invalid ssh key error
<jimbaker> bl, i've been asked to try to help here since fwereade has been called into a meeting
<bl> sure,thanks
<jimbaker> so one possible issue here is that you may be using a different account (or a different machine) to run juju status than what you used for juju bootstrap
<bl> thats what i thought
<bl> so i created a new account of the same username
<jimbaker> bl, you need to ensure the public key (in your ~/.ssh, so say id_rsa.pub) is the same
<fwereade> bl: hey, back again
<hazmat> bl, er. private key
<bl> ok,will recheck on that
<fwereade> bl: for reference, it uses the first it can find of [id_dsa.pub, id_rsa.pub, identity.pub] in ~/.ssh (unless you've explicitly set a different "authorized-keys" or "authorized-keys-path" in environments.yaml?)
<niemeyer> Dec 20 14:09:06 <niemeyer>      rog: I suggest s/SecurityGroupId/SourceSecurityGroup/, and adding GroupId to both SecurityGroup and            SourceSecurityGroup
<niemeyer> rog: ^
<bl> seems the same,will explicitly set it in the yaml file and try
<bl> although when i try to generate keypair usind rsa, when i try juju status it says ecdsa key fingerprint and then finally invalid ssh ke
<bl> *key
<bl> so i tried ssh-keygen -t ecdsa
<bl> still the same problem
<hazmat> the key is only put into place for juju to populate machines with on the initial bootstrap
<niemeyer> rog, TheMue: https://labix.org/gocheck
<niemeyer> Duh :)
<niemeyer> rog, TheMue: https://codereview.appspot.com/5504047/
<bl> no luck yet..will get back in some time
<koolhead17> i have got around 4-5 questions which am not aware of am writing it all at askubuntu, will that be fine/
<_mup_> Bug #913767 was filed: juju explicitly instructs cloud-init to install python-argparse which does not exist in precise <juju:New> < https://launchpad.net/bugs/913767 >
<mpl> rog: is juju using a public ami, or is there some sort of an existing ubuntu ami?
<rog> mpl: yeah, it's just using a public ami - you can actually specify which one, i think, in the environments.yaml file
<rog> mpl: (with caveats)
<mpl> ok, thx
<mpl> rog: and I suppose one can specify the instance type as well in a similar way?
<rog> mpl: yup
<mpl> thx. I know, I should go and read the juju docs again :)
<mpl> I'm actually reading the amazon docs now, so some dots with juju are finally connecting.
<mpl> trying to pitch using the cloud at work for some cases. if that works, maybe I can pitch using juju as well.
<koolhead17> mpl: also check askubuntu, we do have some hlping bits available there undere juju tag!! :P
<mpl> koolhead17: thx
<SpamapS> https://code.launchpad.net/~openstack-ubuntu-testing/juju/precise-fixes/+merge/87934
<SpamapS> hazmat: can I get a +1 for this (I think its a trivial)
<SpamapS> hrm actually
<SpamapS> that may have been a branch of the wrong branch
<koolhead17> is there any option like juju add unit wordpress n=10 ?
<SpamapS> koolhead17: --num-units 10
<koolhead17> SpamapS: thanks.
<koolhead17> also say my load is not high and i want to bring down 5 instance how will i do it and are these things available in the doc? am i missing something?
 * koolhead17 wants to write a blog. Had nice 1 hours QA/presentation/demo on juju :D
<negronjl> bcsaller1: The problem was the config.yaml file after all.
<negronjl> hazmat: ^^
<negronjl> SpamapS: ^^
<bcsaller1> negronjl: thanks for running that test for us
<negronjl> bcsaller: thanks for the help
<bcsaller> np, sorry I didn't see what was happening sooner
<SpamapS> negronjl: oh??
<negronjl> SpamapS: the format of the configuration file that I was using was wrong.  Ben pointed me to the proper format and it all works now
<koolhead17> also when i say juju expose wordpress it means i can access the instance only after that in web browser isn`it ?
<SpamapS> negronjl: but, really, that needs to be a bug at parse time or something
<negronjl> SpamapS: agreed.
<bcsaller> SpamapS: I think the problem was it was 'valid' to pass schema entries as string values for each key/value pair, I don't recall if the schema was using only the string type or not. If it wasn't string then there should have been an error
<mpl> niemeyer: hello. will you have a bit of time to discuss zk and ssh sometime this week?
<niemeyer> robbiew: ping
<niemeyer> mpl: yo
<niemeyer> mpl: Yeah
<niemeyer> mpl: Now/today is probably not a good moment, but can you please ping me tomorrow about it?
<robbiew> niemeyer: pong
<niemeyer> robbiew: Can you please come by?
<robbiew> yep
<robbiew> on my way
<niemeyer> robbiew: Cheers!
<mpl> niemeyer: will do, thx
<koolhead17> nijaba: around?
<koolhead17> hello robbiew
<jimbaker> fwereade, please try juju.agents.tests.test_provision.ProvisioningAgentTest.test_transient_unhandled_error_in_process_machines
<robbiew> hi koolhead17
<enmand_> :p
<enmand_> Er
<koolhead17> hi all
<koolhead17> sleepingt
<koolhead17> bye now
<koolhead17> oops
<shaon> koolhead17: :D
#juju 2012-01-10
<Pavan> i keep getting this ssh error whenever i do juju status
<Pavan> what should i do?
<koolhead17> hi all
<robbiew> hey koolhead17
<koolhead17> hello robbiew
 * koolhead17 is spending time on epoch time microseconds 
<shaon> when it says, ERROR Environment already bootstrapped, does it mean it is okay? or still I have problem?
<koolhead17> shaon: cool
<koolhead17> shaon: pastebin juju -v status :)
<shaon> okay :)
<shaon> koolhead17: http://paste.ubuntu.com/799129/
<koolhead17> shaon: your almost there. wait for few more minutes and check the status and tell me
<shaon> koolhead17: I think there is a problem, it should not take this long
<koolhead17> lynxman: around?
<koolhead17> https://bugs.launchpad.net/juju/+bug/907450
<_mup_> Bug #907450: juju does not work with Walrus when s3-uri has a suffix <juju:New> < https://launchpad.net/bugs/907450 >
<koolhead17> it currently restricts juju deployment on eucalyptus
<SpamapS> koolhead17: I believe this bug was in *txaws*, and was fixed already.
<lynxman> koolhead17: why do you need me for that? :)
<koolhead17> lynxman: needed the custom config you shared long time back!! I checked my folder and found it. :)
<lynxman> koolhead17: aah okay
<lynxman> koolhead17: don't think that solves the walrus thingie though
<koolhead17> SpamapS: shaon is currently working on eucalyptus + juju work and he is still stuck at same problem
<koolhead17> shaon: ping
<shaon> getting this error: http://paste.ubuntu.com/799173/
<koolhead17> lynxman: hehe. i needed a template to start with  :P
<lynxman> koolhead17: nonsense, you just miss me :P
<koolhead17> jcastro: i will follow your documentation modification guide and edit few things there :)
<therve> shaon, can you get the logs from the euca side?
<koolhead17> as SpamapS had sugegsted to do earlier :D
<koolhead17> lynxman: yes sir!! :P
<koolhead17> shaon: you can also pastebin dpkg -l juju
<shaon> sure, wait a min
<koolhead17> shaon: and you can also explain about your juju infra setup, it will be helpful
<shaon> koolhead17: http://paste.ubuntu.com/799211/
<koolhead17> 0.5+bzr440-1ju
<koolhead17> SpamapS: the above version still has the issue it seems
<_mup_> juju/alt-endpoint r443 committed by jim.baker@canonical.com
<_mup_> Alt implementation of endpoint scope
<_mup_> juju/ssh-known_hosts r480 committed by jim.baker@canonical.com
<_mup_> Merged trunk
<shaon> _mup_: is it about the problem I just said?
<_mup_> juju/ssh-known_hosts r481 committed by jim.baker@canonical.com
<_mup_> Docstrings/comments
<therve> shaon, txaws is reporting a 500 error from your cloud endpoint. Having the server side error would help.
<SpamapS> shaon: what about python-txaws ?
<shaon> getting error while bootstraping juju
<SpamapS> shaon: dpkg -l python-txaws
<SpamapS> shaon: btw, the command 'pastebinit' can be very helpful for this
<SpamapS> shaon: dpkg -l python-txaws | pastebinit will automatically paste it to paste.ubuntu.com and print out the link for you
<shaon> SpamapS: I am using that
<SpamapS> shaon: sweet
<_mup_> juju/ssh-known_hosts r482 committed by jim.baker@canonical.com
<_mup_> Rename to be explict about private methods in bootstrap
<shaon> SpamapS: http://paste.ubuntu.com/799246/
<SpamapS> shaon: ok, I'm quite certain that this bug is in txaws, but it looks like a new one, not the other one that we fixed a long time ago. :p
<shaon> SpamapS: hehe
<shaon> SpamapS: okay, then I am pausing for now, but did you get where the actual problem is?
<SpamapS> shaon: I don't have a eucalyptus system setup to test against, but it seems like we can compare, side by side, the request/response to s3 and euca and likely find a bug in *walrus*.. not txaws. :-P
<_mup_> juju/ssh-known_hosts r483 committed by jim.baker@canonical.com
<_mup_> Docstrings
<shaon> SpamapS: I have a euca setup here, so we can work on that sometime, if possible
<SpamapS> shaon: should be fairly easy, just use strace to see the requests/responses
<shaon> SpamapS: okay, thanks :)
<smoser> hazmat, http://paste.ubuntu.com/799273/
<shaon> SpamapS: sorry if I am wrong, but it seems txaws is not in the right directory. http://paste.ubuntu.com/799296/
<shaon> lots of files that are needed to open, seems missing :/
<shafiqissani> I realize that colocation and placement features are in queue for development ... but is there a release date/version set for these features ?
<hazmat> shafiqissani, 12.04
<hazmat> shafiqissani, they should land in the ppa prior to that, they'll be some email discussions on the list about the impl/design choices latter this week
<shafiqissani> thanks ... I'll be following that news closely
<secbrid> Chaps I have a question, I've been asked to justify juju over say jclouds/Whirr/Pallet. At the moment juju does seem a little less mature than other products. Is there anything in your opinion that raises it above the rest?
<_mup_> Bug #914392 was filed: LXC local provider does not respect 'series' (only installs oneiric) <juju:New> < https://launchpad.net/bugs/914392 >
<avoine> I'm trying to do a charm for Django do you think I should abstract options like the wsgi server (Gunicorn, uwsgi, etc) ? Or maybe doing an other charm for each?
#juju 2012-01-11
<_mup_> Bug #914610 was filed: When deployment config contains an invalid option, empty service is deployed with no units <juju:New> < https://launchpad.net/bugs/914610 >
<_mup_> Bug #914645 was filed: Rolling upgrades of packages <juju:New> < https://launchpad.net/bugs/914645 >
<lamalex> what room are you all in? (wrt sprint)
<jimbaker> lamalex, we are in dery
<lamalex> is there someone free to help me set up jenkins via the charm on my laptop?
<jelmer> poolie: https://code.launchpad.net/~awsvalidation/awsvalidation/trunk
<fwereade> hazmat: http://paste.ubuntu.com/800436/
<hazmat> fwereade, looks good, i'd add a blurb referencing the implementation point (relevant state is still extant)
<fwereade> hazmat: the final branch in the pipeline does include unit tests for do_error_depart; I think I noticed and fixed that in resolve-unit-relation-diffs (where I was actually directly working with the *relation* workflow)
<fwereade> hazmat: http://paste.ubuntu.com/800449/
<fwereade> hazmat: better?
<medberry> when I'm "done" with a juju demon in aws/ec2, do I juju destroy-service and juju terminate-machine or just one of those (and where should I find this info--most of the demo writeups I see end with the service running....)
<medberry> (that first word should be demo not demon)
<bcsaller> medberry: juju destroy-environment will remove everything for you if you want nothing left running
<medberry> ah, destroy-environment does the trick
<medberry> thanks.
<hazmat> fwereade, http://pastebin.ubuntu.com/800467/
<shaon> SpamapS: hello. any update with the eucalyptus problem?
<tyska> hi guys
<tyska> Someone here already get around this bug of juju with eucalyptus? https://bugs.launchpad.net/juju/+bug/907450
<_mup_> Bug #907450: juju does not work with Walrus when s3-uri has a suffix <juju:New> <txAWS:New> < https://launchpad.net/bugs/907450 >
<hazmat> with zk 3.4 secure zookeeper via sasl+kerberos -> https://github.com/ekoontz/zookeeper/wiki
<hazmat> niemeyer, rog ^
<hazmat> rog oh really ? ;-)
<rog> hazmat: oh really!
<mpl> hmm cool
<_mup_> juju/trunk r443 committed by kapil.thangavelu@canonical.com
<_mup_> [trivial] fix digestauth's reference of cert files to account for coverage test directory changes [r=bcsaller]
<hazmat> sadly that sasl + kerberos isn't exposed to the c client only java, there's an extant patch though.. https://issues.apache.org/jira/browse/ZOOKEEPER-1112
<EvilBill> jcastro: you around?
<_mup_> Bug #915022 was filed: local environment has no internet access <juju:New> < https://launchpad.net/bugs/915022 >
#juju 2012-01-12
<koolhead11> hi all
<koolhead11> is there a man page for juju? Or am missing something?
<niemeyer> rog:
<niemeyer> [ALIASES]
<niemeyer> log = log --show-ids
<niemeyer> in ~/.bazaar/bazaar.conf
<koolhead11> hazmat: around?
<hazmat> koolhead11, in body, spirit is questionable ;-), what's up?
<koolhead11> hazmat: hahaha. there is no manpage for juju currently juju --help does has infos
<koolhead11> any special reason 4 this :P
<jcastro> hazmat: http://caseconductor.wordpress.com/
<koolhead11> hola jcastro :)
<jcastro> good morning!
<koolhead11> jcastro: saw nice diagram explaining juju bootstrap process on askubuntu, why cant we have it in our official doc?
<jcastro> oh really?
<jcastro> link?
<koolhead11> jcastro: hold on sir!! :P
<jcastro> koolhead11: good point, hazmat, we should chat about docs
<jcastro> hazmat: but maybe later today, heh
<robbiew> jcastro: hey...do you have plans for a charm school at oscon?
<koolhead11> jcastro: http://askubuntu.com/questions/55179/what-is-the-purpose-of-the-bootstrapping-instance-in-juju
<robbiew> cfp is today...you can submit for a 3-hour "tutorial"
<jcastro> robbiew: yes, let's do that
<jcastro> robbiew: what do I need to do?
<robbiew> jcastro: http://www.oscon.com/oscon2012/user/proposal/propose/cfp/197
<robbiew> jcastro: adam_g lives in Portland, so he could help with the charm school
<robbiew> SpamapS won't be *that* up for travel then ;)
<SpamapS> Yeah, day trips only please
<koolhead11> robbiew: am also registering a talk on juju at FOSS conference in India :) I am not confident about 3 hr show though :P
<nijaba> m_3: using you nfs charm, I am hitting "#TODO fix oneiric package... install fails without this"
<nijaba> m_3: any hint on what needs to be done?
<koolhead11> hazmat: you think i should report a bug with *wishlist option sir? :D
<koolhead11> for manpages
<jcastro> robbiew: ok so how about adam_g/m_3/me for oscon?
<jcastro> or is 3 too many?
<SpamapS> charmers, I could use a quick review of this: https://code.launchpad.net/~clint-fewbar/charm-tools/apparmor/+merge/88321
<SpamapS> negronjl: ^^
<negronjl> SpamapS: checking
<negronjl> SpamapS: Just checked it and approved it.
<SpamapS> negronjl: woot thanks
<negronjl> m_3:  Can I take over this: https://bugs.launchpad.net/charm/+bug/803539
<_mup_> Bug #803539: Charm Needed: GlusterFS <hot> <juju Charms Collection:In Progress by mark-mims> < https://launchpad.net/bugs/803539 >
<hazmat> fwereade, please ignore the last line of my upstartify-services review
<hazmat> it was a leftover comment from an initial pass
<fwereade> hazmat, ah, ok, cool :)
<hazmat> koolhead17, that sounds good, i think there already is a bug report regarding manpages..
<hazmat> SpamapS, you did some work re manpages, is it just in the packaging?
 * koolhead17 digs hard to see if there exist same bug :P
<hazmat> i think we've given up on autogenerating the man pages from argparse internals madness
<koolhead17> hazmat: https://bugs.launchpad.net/juju/+bug/901017
<_mup_> Bug #901017: Juju should have a "info" or "man" option <Juju Charm Tools:Triaged> <juju:New> < https://launchpad.net/bugs/901017 >
<koolhead17> nijaba: ^^
<nijaba> koolhead17: oh, yes, I opened that a little while back
<koolhead17> juju --help does gives some decent result :)
<nijaba> koolhead17: but that bug is not the same as "juju needs a man entry", this is for juju to offer a man or info option for charms
<koolhead17> nijaba: you want me to open one with a *wishlist option :P
<nijaba> koolhead17: sure, go ahead
<_mup_> Bug #915238 was filed: manpage needed for Juju <juju> <manpage> <juju:New> < https://launchpad.net/bugs/915238 >
 * hazmat sighs at name change diffs
<_mup_> juju/ssh-known_hosts r484 committed by jim.baker@canonical.com
<_mup_> Merged trunk
<_mup_> juju/subordinate-docs r444 committed by jim.baker@canonical.com
<_mup_> Initial checkin
<secbrid> hi all, how would I include a file to be installed in a charm? I could use the cat >file<EOF but its quite a big file to be included in the install file
<SpamapS> secbrid: just put it in the charm directory
<secbrid> SpamapS: thanks, and then just cp it from `pwd`/filename to say /etc/moo/  ?
<secbrid> actually cp filename /etc/moo/ should work, right?
<SpamapS> secbrid: right
<secbrid> neat! thanks!
<SpamapS> secbrid: make sure that the license/copyright of this file is mentioned in the copyright file. :)
<secbrid> ah yes! :-)
<hazmat> rog, http://code.google.com/p/openpgm/
<hazmat> jcastro, doc talk?
<_mup_> Bug #915506 was filed: juju-log outputs {} on lxc <juju:New> < https://launchpad.net/bugs/915506 >
<_mup_> Bug #915520 was filed: locale is not set on lxc containers <juju:New> < https://launchpad.net/bugs/915520 >
<koolhead17> SpamapS: around
<hazmat> SpamapS, it looks like lennart threatened the dbus thing in passing, but not for real (from dbus freedesktop ml conversation)
<hazmat> SpamapS, looking over the last build log, something fishy it appears.. https://launchpadlibrarian.net/89795690/buildlog_ubuntu-precise-i386.juju_0.5%2Bbzr443-1juju2~precise1_FAILEDTOBUILD.txt.gz
<hazmat> SpamapS, i'm starting to suspect this is to do with a missing dep around ssl
<hazmat> those tests that fail do need openssl for certs validation afaicr
<hazmat> interesting that its no longer manifesting as a timeout problem
#juju 2012-01-13
<hasp> greetings
<hasp> can someone shed some light on the following bug:
<hasp> https://bugs.launchpad.net/juju/+bug/907450
<_mup_> Bug #907450: juju does not work with Walrus when s3-uri has a suffix <juju:New> <txAWS:New> < https://launchpad.net/bugs/907450 >
<hasp> what is the S3-URI being used for?
<hazmat> hasp, its used to store charms so that they can be retrieved/deployed onto machines
<hazmat> as well as some metadata regarding the location of the zookeeper servers
<hazmat> hasp, we're using the txaws library to communicate with the s3 endpoint, i haven't dug into the bug very much but there's an strace there that shows the full wire communication
<hspencer_> hi hazmat
<hspencer_> thanks
<hspencer_> i will check into it
<james_w> I can't run services on lucid instances with juju, correct?
<hspencer_> i think you can
<SpamapS> hazmat: re the missing SSL dep, can you elaborate?
<koolhead17> hi all
<shaon> hello koolhead17 :)
<koolhead17> hi shaon
<jcastro> m_3: SpamapS: Hey so my room is small if you guys want to do juju document review
<hazmat> SpamapS, g'morning lets meetup re that build jaunx
<hazmat> james_w, you can run the client, but running services is problematic for two reasons  1) no charms are available for that release series, 2) the zk client version in lucid has bugs which need an sru
<hazmat> both are addressable if its an important target
<hazmat> SpamapS, jcastro that charm count is correct btw, i ended up filtering a few that aren't published anymore on lp (but where in the past), but we're definitely north of 80 total distinct
<jcastro> hazmat: woo!
<hazmat> jcastro, where you at?
<tyska> hello guys
<tyska> some good new about this bug? https://bugs.launchpad.net/bugs/907450
<_mup_> Bug #907450: juju does not work with Walrus when s3-uri has a suffix <Eucalyptus:New> <juju:New> <txAWS:New> < https://launchpad.net/bugs/907450 >
<jcastro> m_3: can you come down to our end? meeting about events.
 * SpamapS will head down too
<koolhead11> phpbb3 package install bsd-mailx exim4 exim4-base exim4-config exim4-daemon-light along with it as < goshhhh> :(
<james_w> hazmat, it becomes much less important in a few months obviously, but given my current task is to spin up dev envs for a service running on lucid in production it is less than ideal to do it on oneiric/precise
<_mup_> juju/subordinate-spec r450 committed by jim.baker@canonical.com
<_mup_> Some copy editing
<_mup_> Bug #916057 was filed: all juju instances (in one environment) use the same credentials for zookepeper, preventing admin acl restrictions <juju:New> < https://launchpad.net/bugs/916057 >
<andrewsmedina> hi
<koolhead11> hey there
<andrewsmedina> anyone can explain me if juju only install ubuntu image on a vm instance or juju create a vm instace based on a image too
<andrewsmedina> ?
<koolhead11> andrewsmedina: whats your aim?
<andrewsmedina> koolhead11: know more what juju does
<koolhead11> andrewsmedina: juju.ubuntu.com :)
<koolhead11> andrewsmedina: am familiar with LXC and juju
<koolhead11> running on local amchine
<andrewsmedina> koolhead11: I already read the juju docs
<andrewsmedina> koolhead11: all already do the juju tutorial
<andrewsmedina> but, somethings were not clear for me
<andrewsmedina> koolhead11: when execute juju add-unit mysql for example
<andrewsmedina> koolhead11: juju create another vm instance and install mysql service?
<koolhead11> andrewsmedina: juju can be deployed on local machine or Vm via LXC and on cloud enviornmnet like openstack and AWS
<koolhead11> andrewsmedina: yes a service unit
<andrewsmedina> koolhead11: then juju makes de vm orchestration too?
<koolhead11> andrewsmedina: yes.
<andrewsmedina> koolhead11: then I can use juju for create vms on openstack and install the services for example?
<koolhead11> exactly
<koolhead11> :)
<andrewsmedina> koolhead11: do you know about some docs that explain how use juju with openstack instead ec2/LXC?
<koolhead11> andrewsmedina: the documentation expalins it
<koolhead11> plus
<koolhead11> enviornment.yaml needs to have these detials
<koolhead11> lemem pastebin
<koolhead11> http://paste.ubuntu.com/803181/
<koolhead11> replace it with yours
<koolhead11> and i found it somewhere on the documentation only
<koolhead11> hazmat: thanks:P
 * koolhead11 leaves 4 home
<koolhead11> laters
<andrewsmedina> juju only install services on a ubuntu distro?
<koolhead17> jcastro: around?
<hspencer> mronin
<koolhead17> hspencer: hola
 * hazmat yawns
#juju 2012-01-14
 * SpamapS runs through email while waiting at Ferihegy airport. :)
<hspencer> mronin
<hspencer> hazmat, i responded to bug https://bugs.launchpad.net/juju/+bug/907450
<_mup_> Bug #907450: juju does not work with Walrus when s3-uri has a suffix <Eucalyptus:New> <juju:New> <txAWS:New> < https://launchpad.net/bugs/907450 >
<hspencer> i think it has more to do with txAWS
<hspencer> i stepped through the python code with pdb
<hspencer> didn't work with and without slashes in the S3 URI
<hspencer> i will continue to run more tests
<hspencer> i will keep you posted
<_mup_> Bug #916623 was filed: txAWS 0.0.1 => unexpected keyword argument "s3_endpoint" <2.0.3> <eucalyptus> <juju> <s3> <walrus> <juju:New> <txAWS:New> < https://launchpad.net/bugs/916623 >
#juju 2014-01-06
<ghartmann> good morning
<lazypower> 'morning
<ghartmann> I wonder if anyone is using juju to deploy python / django apps.
<ghartmann> I started to look at the charm "python-django" but I didn't got such a good documentation on it.
<lazypower> ghartmann: Without having looked at it, what are you expecting to be documented that isn't?
<ghartmann> mainly I don't get how I am supposed to set the requirements and the repository
<lazypower> ghartmann: are you using the GUI or strictly CLI?
<ghartmann> I am using the GUI primarily
<ghartmann> but it's not a problem to use it on the console
<lazypower> http://i.imgur.com/dgAcL0k.png
<lazypower> there's the configuration field for the repository.
<lazypower> I'm not super familiar with Django, so i'm reading up on the requirements settings
<lazypower> i'm assuming that you're checking out from a Github repository?
<ghartmann> well, at the moment yes
<lazypower> ok, yeah plug the http clone url in that field
<ghartmann> but I intend to move to a internal git repository
<ghartmann> and the requirements.txt should be inside of the repo
<lazypower> shouldn't be a problem so long as you've got a deployment key on your repo.
<lazypower> Could you document this as you go through it for later examination? There's more than likely a few people in here that are more familiar with DJango app deployment with juju that can offer more input, and possibly modify the django charm based on your feedback.
<ghartmann> ok great
<ghartmann> where should I put this info ?
<lazypower> Either open a bugreport against the charm, or a blog post would work.
<lazypower> if you link me i'll run it around the circle of developers and see where feedback like this should go in the future.
<ghartmann> great, thanks
<ghartmann> * I am currently on the juju gui trying to re deploy the server *
<lazypower> ghartmann: Actually the more I think about it, the mailing list would be a prime location for that to go.
<ghartmann> the juju main mail list ?
<lazypower> https://lists.ubuntu.com/mailman/listinfo/juju
<ghartmann> thanks, I will subscribe to it
<rick_h_> marcoceppi_: ping, is there any help to charm devs for s3-like techniques for charms? We're using azure atm, but would prefer to do this in a cloud agnostic way.
<marcoceppi_> rick_h_: could you elaborate?
<rick_h_> marcoceppi_: I'm looking at backup up our jenkins config and such from our gui deploy on azure
<rick_h_> marcoceppi_: ideally, this would be in a cloud-agnostic way to backup to blog on azure, s3 on amz
<rick_h_> marcoceppi_: I can't find any way to do this but want to make sure I'm not missing anything
<marcoceppi_> rick_h_: there has been multiple talks of a generic backup charm but nothing materialized yet. Either something that would live as a subordinate charm or possibly in charm-helpers. As of right now, there's nothing really /in/ that space
<rick_h_> marcoceppi_: yea, each cloud has their own sdk/tooling for working with storage and we'd need something like cross-cloud s3cmd to do this well I think
<rick_h_> marcoceppi_: ok, thanks for verifying what I'm seeing
<marcoceppi_> rick_h_: I think just having all the tools installed, then using configuration to drive where to sync would be a good start. This still incurs the problem that you need to provide your account credentials an additional time to the charm, since the charm can't access environment creds from bootstrap
<marcoceppi_> that's always been the sort of non-starter for the charm
<rick_h_> marcoceppi_: right, doesn't juju itself store some blob storage?
<rick_h_> marcoceppi_: or does it actually store all the stuff in mongo itself? the charm zip files and such?
<marcoceppi_> rick_h_: there's some notion of storage for charm stuff, but nothing really exposed to the charms/services
<rick_h_> marcoceppi_: right, cool
<marcoceppi_> rick_h_: last I checked, it's still using provider based storage for charms
<rick_h_> marcoceppi_: right, so there's some idea of using the storage for each cloud in juju itself. That would be a cool way to expose it. juju store xxxx.tar.gz :)
<marcoceppi_> rick_h_: that's probable using a plugin. the issue is how do you get the storage information to the charm so it knows where to pull
<fcorrea> what's the best way to compute the unit name without charmhelpers? Since this one is a shell based charm, I suppose I should just extract it from the path or something?
<mgz> fcorrea: can't you just get the JUJU_UNIT_NAME envvar?
<fcorrea> mgz, oh, didn't know about that one. Thanks
<marcoceppi_> hatch: good news, I'm just about done reviewing your charm
<hatch> saweeeeet
 * hatch hopes it was ok
<marcoceppi_> hatch: there's bad news, but I don't want to harsh your excitement
<hatch> lol, well there are no tests
<marcoceppi_> well, that's one thing
<marcoceppi_> that I forgot to mention
<hatch> but they aren't required yet :P
<marcoceppi_> exactly
<hatch> it's ok, at least I will know what work to do
<hatch> I work with open source software, it's pretty hard to hurt my feelings with a review haha
<mgz> your code sucks and I hate you!
<hatch> then don't use it :P
<hatch> or
<hatch> write your own :P
<Makyo> In python.
<hatch> or even better
<hatch> pr's accepted
<Makyo> (or go?)
<marcoceppi_> y u no pascal?
<hatch> VB?
<mgz> hatch: if you've not read it, http://mumak.net/stuff/your-code-sucks.html
<Makyo> Haskelljuju.
<hatch> mgz I haven't, I'll have to check it out
<marcoceppi_> I could have saved a lot of writing in my review if I'd just written "ur code suks and I </3 u"
<hatch> haha
<hatch> well a lot of it was written by jcsackett so I'll blame the crappy parts on him
<hatch> lol
<marcoceppi_> bugger, I can't edit comments, grr
<jcsackett> hatch: yeah, but all the architecture decisions were things you stuck me with. :-P
<hatch> lol
<hatch> ok that's the truth
<jcsackett> hatch: did you ever get a chance to do the apache frontend stuff for the charm? i still haven't had much time to throw at it.
<hatch> jcsackett nope I started on it then stopped and started on nginx instead, then stopped on that
<hatch> heh
<hatch> I think I'm going to do nginx whenever I do get around to it
<marcoceppi_> hatch: nginx in main possibly for 14.04, I am so excite
<Makyo> \o/
<mgz> marcoceppi_: it is meme day today? :)
<hatch> marcoceppi_ yeah that's kind of why I dwecided to just to nginx and forget about apache
<marcoceppi_> mgz: everyday is meme day for me
<mgz> marcoceppi_: :D
<hatch> marcoceppi_ thanks a lot for the review, after todays sprint I'll take a look at it
<hatch> marcoceppi_ hmm there must be some new updates to proof from when I submitted because I didn't get any messages before
<marcoceppi_> hatch: there have been several
<marcoceppi_> though the does not provide anything has been there for a while
<hatch> oh haha ok
<hatch> oh yeah the provides one I knew about
<hatch> ok np I'll have to make sure to update my proof tool
<hatch> marcoceppi_ just read through the review - great comments thanks. Typically do you like people to reply to the reviews?
<marcoceppi_> hatch: it's whatever the author wants. I typically like people to update the charm ;) but for questions I usually say something like "Reply here, or find us in #juju, or ask ubuntu, or the mailing list"
<hatch> ok cool np, I'll definitely be updating the charm to address the concerns, just sometimes reviewers like to have a dialogue :)
<marcoceppi_> hatch: if, when you're ready for a review, and you want to address each bullet point, go for it. Otherwise it'll just go through a few review again. As I might (hopefully) won't be the one reviewing it again
<hatch> :)
<marcoceppi_> and by hopefully it's not that this charm is le suck, but rather hopefully there will be more than me doing charm reviews \o/
<hatch> lol
<Makyo> (but maybe also that)
<marcoceppi_> (oh, definitely that)
<marcoceppi_> hatch: actually, you might be interested in this: https://code.launchpad.net/~dstroppa/charms/precise/node-app/refactor-hooks/+merge/200330
<marcoceppi_> there's a charm.js now, that mocks a lot of the events in an async way
<hatch> yeah I would have rejected it
<hatch> :P
<hatch> jk
<hatch> but really it would fail jshint
<hatch> the improvements look really good
<hatch> though
<bcsaller> kirkland: are you still looking for me?
<kirkland> bcsaller: howdy!  yeah, I'm in a meeting right now, but want to catch up later
<bcsaller> kirkland: sounds good, I'll be around
<maxcan> good morning
<maxcan> in the mongodb charm, when i add units my services database-relation-changed hook gets called.  is there anyway to only have this triggered on by the primary unit of the replicaset?
<marcoceppi_> maxcan: no, this is buy design of juju
<marcoceppi_> by*
<maxcan> hm
<maxcan> do you know if there's anyway to determine the address of the primary in the relation-changed hook?
<marcoceppi_> maxcan: shouldn't all of them be able to accept connections?
<maxcan> they can
<maxcan> the problem is the mongodriver for haskell is kind of out of date and doesn't send writes to the primary
<marcoceppi_> maxcan: there's not peer election or anything like that in juju yet, relations are created at the service level, but executed on a per unit basis
<maxcan> i think
<maxcan> may be fixable on the haskell side
<maxcan> thanks
<marcoceppi_> maxcan: np!
<fwereade> cmars, bcsaller, marcoceppi_: hey, I've ducked out of the sprint
<fwereade> didn't see the reschedule
<fwereade> but it's not long after Iland backin malta so I'm not sure I can make that one either
<fwereade> since I'mhere,do you want to do it now?
<fwereade> mramm, cmars, bcsaller, marcoceppi_, jcastro: ^^
<marcoceppi> fwereade: if everyone else is available, I can make myself available as well
<cmars> fwereade, works for me
<mramm> sure
<mramm> we can do it now
<jcastro> I can go now
<fwereade> cmars, marcoceppi, mramm, jcastro, bcsaller: https://plus.google.com/hangouts/_/7acpiks0pmu1dt6ouvjavqr1k0?hl=en
<mgz> jcastro: semi-off topic, do you know what the around-fosdem plans are? I'm sorting out travel and stuff soon, and wonder if you still want me for anything.
<jcastro> mgz, yeah, we'd love to have you at cfgmngmnt camp
<jcastro> http://cfgmgmtcamp.eu/
<jcastro> mgz, as for fosdem itself, rbasak was going to submit a talk, I think you should too!
<rbasak> mgz: I've booked travel/hotel already. I would've asked you had I known you were coming!
<mgz> that's the hardest damn url to type
<jcastro> yeah, tell me about it
<mgz> rbasak: I was doing accomodation seperately anyway I think, but are you eurostaring over? could aim at the same train again
<rbasak> mgz: yes, I'm eurostaring. I'll forward you my iternarary
<mgz> rbasak: ta!
<rbasak> You have mail.
<bjorne> 2013-12-22 11:20:04,813 - url_helper.py[DEBUG]: Attempting to open 'http://172.16.1.21/MAAS/metadata//2012-03-01/user-data' with 1 attempts (0 retries, timeout=None) to be performed
<bjorne> 2013-12-22 11:20:04,856 - url_helper.py[DEBUG]: Failed reading from http://172.16.1.21/MAAS/metadata//2012-03-01/user-data after 1 attempts
<bjorne> 2013-12-22 11:20:04,856 - url_helper.py[DEBUG]: 1 errors occured, re-raising the last one
<bjorne> someone now anything about this?
<marcoceppi> bjorne: what version of juju? 0.7?
<bjorne> the lastest.
<marcoceppi> bjorne: that's a loaded answer, can you run juju version?
<bjorne> w8
<bjorne> 1.16.5.sauzy :)
<mgz> rogpeppe: can I have a rubber stamp on the cr to fix bug 1266518 please?
<marcoceppi> bjorne: I've never seen that error than, it's a new one to me
<rogpeppe> mgz: looking
<bjorne> marcoceppi https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1264717
<rogpeppe> mgz: LGTM
<mgz> rogpeppe: thanks, landing
<mgz> sinzui: ^landing that fix now
<sinzui> thank you mgz
<maxcan> hi, i'm following the instructions at https://jujucharms.com/fullscreen/search/precise/mongodb-20/?text=mongodb#bws-readme to set up mongoS
<maxcan> my shard replica sets have this error:  agent-state-info: 'hook failed: "replica-set-relation-joined"'
<marcoceppi> maxcan: can you get the logs from the failed unit under /var/log/juju/unit-*.log ?
<maxcan> yeah
<maxcan> this is the error:
<maxcan> 2014-01-06 19:44:19 INFO worker.uniter.jujuc server.go:108 running hook tool "juju-log" ["port_check: Unable to connect to ec2-54-245-13-124.us-west-2.compute.amazonaws.com:27017/TCP."]
<maxcan> that host is the host the machine is running on
<maxcan> s/machine/agent
<maxcan> it looks like the ports are open on the security group
<marcoceppi> maxcan: that's odd, can you paste more of the log to http://paste.ubuntu.com ?
<maxcan> http://paste.ubuntu.com/6705155/
<maxcan> here is my mongos log: http://paste.ubuntu.com/6705170/
<maxcan> and my deployment commands: http://paste.ubuntu.com/6705194/
<maxcan> so i played around a bit, and have managed to get  python error: http://paste.ubuntu.com/6705348/
<maxcan> this is in the juju logs for mongo shard001
<marcoceppi> maxcan: are you sharding via juju add-unit?
<maxcan> deploy -n 3
<maxcan> as in the readme.  should I try to deploy to one server then add-unit?
<marcoceppi> maxcan: I wonder if there's a race condition. Where are you deploying? I'm going to try in HP cloud with deploy -n 3 as well see if I can replicate
<maxcan> amazon
<maxcan> i'll try to add-unit
<marcoceppi> I usually demo with "Deploy mongodb, now we want to scale" and add-unit. Let me see if I can replicate this
<maxcan> in general, juju is theoretically parallel right?
<maxcan> as in I can fire off a bunch of deploy commands in parallel
<maxcan> or better to run everything serially
<sarnold> like juju deploy foo & juju deploy bar & juju relate ...  &  ?
<maxcan> yeah
<maxcan> well, more like: juju deploy mongo & juju deploy myapp & juju deploy haproxy ; juju add-relation mongo myapp
<marcoceppi> maxcan: yes, you can, totally and you don't even need & it can be juju deploy mongo; juju deploy myapp; juju deploy haproxy ; juju add-relation mongo myapp
<marcoceppi> maxcan: that doesn't mean that the charm isn't doing something bad though ;)
<lazypower> When using PPA's in my charm, its customary to document that, and why its there correct?
<lazypower> i ask because upstream broke ruby 1.9 compat, i have need of ruby 2.x and presently i can either rbenv install that or use a PPA for ruby 2.x on 12.04 - i opted into the PPA instead of having a ton of rbenv based deployments out there where things can go wonky.
<maxcan> marcoceppi: progress, thanks
<maxcan> but, still having problems
<maxcan> if you look at the bottom of the log for the mongos agent http://paste.ubuntu.com/6705606/ , you see "running hook tool "juju-log" ["mongos_relation_change: undefined rel_type: None"]"
<maxcan> and something similar at the bottom of the shard001 log: http://paste.ubuntu.com/6705649/
<maxcan> my add relation commands are:
<maxcan> juju add-relation mongos:mongos-cfg shard001:configsvr
<maxcan> juju add-relation mongos:mongos shard001:database
<maxcan> so, mongo wasn't running on the first shard001 machine and when I tried to start it via upstart, it immediately dies
<maxcan> it seems that when the other two members of the replica set come online, they kill the primary.  and I can't get the primry to start at all
<maxcan> service mongodb start on the host runs but the process immediately dies w/out any logs
<arosales> marcoceppi, were you going to add the pastebin examples to https://github.com/marcoceppi/amulet ?
<marcoceppi> arosales: yes, still am going to
<arosales> marcoceppi, ok thanks
<lazypower> arosales: o/
<lazypower> maxcan: thats typically due to a lock being present in the MongoDB data directory
<lazypower> however you should have gotten some log output.
<maxcan> checked the lock file
<lazypower> what locations did you check for logs? both /var/log/upstart and /var/log/mongodb right?
<maxcan> yes
<lazypower> Hmm :?
<arosales> lazypower, hello
<lazypower> maxcan: can you pastebin the logs?
<maxcan> sorry, just killed my environment.. will PB them in a few minutes
<lazypower> No problem. When you've got them I'd like to look them over. I had some funkyness when I moved a client's MongoDB setup to juju - the second pass went flawlessly and I couldn't find the bug i ran into.
<maxcan> #facepam
<maxcan> sorry guys, one of my commands was add-relation mongos:mongos shard001:configsvr instead of configsvr:configsvr
<lazypower> Glad its sorted :)
<maxcan> well, mongos:mongos-cfg
<maxcan> lazypower: i wish it was...
<maxcan> now, the mongos agent is running a plain, vanilla mongod daemon, not mongos
<maxcan> seems to not be picking up the config servers
<lazypower> hmm
<lazypower> maxcan: will you be working on this through the night? I'd be happy to join a hangout session and talk through this with you.
<maxcan> seems that you need 3 config servers
<maxcan> i was only running 1
<lazypower> its common to run config servers on each host thats going to house a mongod
<maxcan> ahh
<lazypower> if your config server tanks, they vote and promote just like mongod
<lazypower> also, they act as witnesses if configured properly.
<lazypower> or, whats the name they use? arbiter i think?
<maxcan> something like that
#juju 2014-01-07
<InformatiQ> arosales: good morning
<lazypower> o/ maxcan
<jcastro> I need to report a Juju gui bug
<jcastro> when a URL get's %20's instead of spaces
<jcastro> what kind of bug is that, "URL encoding"?
<bac> jcastro: that seems like it would work
<rick_h_> jcastro: what url is it?
<rick_h_> jcastro: there's a know bug on the features tab around that currently
<jcastro> https://bugs.launchpad.net/juju-gui/+bug/1266887
<_mup_> Bug #1266887: Charm Features page generates incorrect links <juju-gui:New> <https://launchpad.net/bugs/1266887>
<jcastro> rick_h_, oh I think I just duped it
<rick_h_> jcastro: rgr, it's on the board. Will dupe it.
<jcastro> ta
<jcastro> this is also weird
<jcastro> you still have a double for "Handle service's user data"
<jcastro> which is strange because it was doubled for whatever we called that bullet before
<rick_h_> bac: is that all deployed and happy now?
<jcastro> rick_h_, actually
<jcastro> a bunch of the bullets are out of date
<rick_h_> jcastro: yea, not sure if it's deployed or not.
<jcastro> oh ok
<jcastro> so I should wait then, roger that
<rick_h_> bac: was working on getting that going and we've got a deploy on the 'doing' list
<jcastro> rick_h_, you're going to kill me, I want to propose a few more
 * rick_h_ disconnects irc and runs away
<bac> jcastro: not deployed yet.  will happen once i get this next branch landed
#juju 2014-01-08
<arosales>  /away afk
 * arosales misssed that space
<xnox> I have pushed a charm to lp:~xnox/charms/trusty/jemjem/trunk I'm trying to open a bug against jemjem charm but apperantly "jemjem" is not published in the charm collection.
<xnox> How can I track bugs against my charm?
<xnox> Can I declare constraints in the charm itself? As in my charm can only work with minimum 2CPUs & 2GB RAM
<xnox> (i want to prevent people deploying it on worse configuration)
<xnox> I guess that's what bundles are for =)
<jam> xnox: it has come up a couple times, as you've found, bundles are the current answer for that
<mattyw> Hi Folks, If I do a local deploy is it possible for me to have different directories of the same charm for different version? like my-charm-1 and my-charm-2 and deploy them using local:my-charm-2? At the moment it looks like it doesn't work becuase the name in the metadata is differnt
<marcoceppi_> mattyw: I think what you can do is possible, but can you expand a little more how your files are setup and the end goal?
<mattyw> marcoceppi_, sure I'd have the same charm in a local directory - different versions would be under different directories ~/mycharms/my-charm-1 ~/mycharms/my-charm-2
<mattyw> ^^ but underneath they're the same charm - so the metadata is unchanged (but the revision number is different)
<marcoceppi_> ah, so that won't work. Charm versions are tracked via the revision file in the charm, not by the directory name
<marcoceppi_> mattyw: try ~/mycharms/my-charm and ~/mycharms2/my-charm instead
<mattyw> marcoceppi_, that's a pretty neat idea
<mattyw> marcoceppi_, I'll give that a go, thanks
<marcoceppi_> mattyw: np, cheers
<bashok> Hi, I am currently testing out juju with my private cloud setup, my cloud has multiple compute regions all my global services has endpoints with a region name, and nova endpoints has a different region name,  while configuring environments.yaml,  I can specify only one region name, which is creating issues, is there a way to overcome this, is this a hard requirement to have all services with same region in endpoints?
<arges> Hi. Is there a way to deploy a specific revision of a charm using juju deploy? Without having to locally clone, checkout etc...
<marcoceppi_> arges: juju deploy mysql-# where # is the version number
<arges> marcoceppi_: : ) thanks
<jcastro> marcoceppi_, can I get a +1 or -1 on my two new bullet proposals?
<jcastro> the GUI guys would like to do an update
<ghartmann> Hi, just a quick question. Anyone working on a IPython Notebook charm ?
<marcoceppi_> jcastro: neither really "require" anything by the charm author, per se
<marcoceppi_> jcastro: actually, I'll reply to the thread
<jcastro> yeah but it's a nice feature to show in the gui
<marcoceppi_> jcastro: truth
<marcoceppi_> ghartmann: not that I'm aware of!
<jcastro> since those are now more "this charm has this features" more than "this charm passes this"
<marcoceppi_> jcastro: true
<jcastro> either way reply to the list
<ghartmann> thanks
<caribou> In an existing charm, if I want to add a new option, is config.yaml the only place I need to go to define it ?
<medberry> I think so.  marcoceppi_ ^
<marcoceppi_> caribou: yes, then you need to make sure to utilze the new option in the config-changed hook :)
<caribou> marcoceppi_: thanks
<caribou> marcoceppi_: so you mean that *every* option has to appear at least once in config-changed ?
<caribou> marcoceppi_: my change is to add an option in a conf file
<marcoceppi_> caribou: no, it doesn't have to be used at all, but then why even bother addint it to config.yaml?
<marcoceppi_> I was more referring to the fact that it's best to have it in config-changed, it can be used in any hook of the charm though
<caribou> marcoceppi_: of course; my change is to define a value in a template file (cinder.conf for instance)
<jcastro> hey evilnickveitch
<evilnickveitch> jcastro, hey
<jcastro> hey on the list
<jcastro> the guy trying jenkins says the debug-hooks doc page is "opaque"
<jcastro> he thinks some examples there would be good
<caribou> marcoceppi_: nOOb's mistake, I forgot to increment the revision :-/
<evilnickveitch> jcastro, ok
<jcastro> hey marcoceppi_
<jcastro> bac landed the new QA bullets
<jcastro> https://manage.jujucharms.com/charms/precise/apache2/qa/edit
<jcastro> we can now check those off as part of the audit
<dpb1> Would it be possible for someone to look at this?  https://bugs.launchpad.net/charms/+bug/1259630
<_mup_> Bug #1259630: add storage subordinate charm <landscape> <Juju Charms Collection:New for davidpbritton> <https://launchpad.net/bugs/1259630>
<marcoceppi_> dpb1: if it's not in https://manage.jujucharms.com/tools/review-queue we don't really know about it
<marcoceppi_> dpb1: wait, is this a charm or an idea you want feedback on?
<dpb1> marcoceppi_: what do I do to get it there?
<dpb1> marcoceppi_: I have the bug marked with charmers, I have it assigned to me
<marcoceppi_> dpb1: but is it a charm or just a concept you want to discuss?
<dpb1> charm
<marcoceppi_> dpb1: you need to link a branch to for it to show up
<dpb1> blah
<marcoceppi_> I don't see a branch linked anywhere other than your jenkins mention
<dpb1> lp should just know! :)
<marcoceppi_> ;)
<marcoceppi_> dpb1: cool, it'll show up in the queue in the next 10 mins and I'll try to get eyes on by end of the week
<dpb1> marcoceppi_: thanks much!  we already have some follow-on work and are looking to integrate it into the postgres charm, so feedback would be appreciated
<marcoceppi_> dpb1: cool, I also see the swap charm is up for review soon too
<dpb1> marcoceppi_: yes, that one is much more limited in scope.  just something to clear out some todo items.  el-mo even told me already it sucked. :)
<jcastro> marcoceppi_,  I think I found the problem with the mongodb replicaset you mentioned in passing the other day
<marcoceppi_> jcastro: excellent!
<lazypower> jcastro, do tell
<jcastro> I think you need to set the replica set name before you add unit
<jcastro> I am testing it out now
<jcastro> lazypower, "Not using --replSet" do you get that in the UI?
<lazypower> jcastro, 1 sec on the phone with blythe
<jcastro> no worries
<jcastro> here it is
<jcastro>            19:22:40.165 [initandlisten] ERROR: can't use --slave or --master replication options with --replSet
<jcastro> negronjl, around?
<lazypower> jcastro, as i understand it, which may be incorrect, you have to define the heartbeat set and let election occur
<lazypower> *define the replica set, allow it to heart beat, and election occur before you define master slave relationships
<jcastro> yeah it's just none of that is in the instructions
<jcastro> it's like "yo, juju deploy, add-unit, done!"
<marcoceppi_> jcastro: maybe the config just doesn't have sane defaults?
<lazypower> good point, i ran into that helping maxcan get his mongodb cluster deployed.
<jcastro> marcoceppi_, maybe
<lazypower> and what actually solved it, was just running it again with -r after the config servers came online
<jcastro> I mean, the hardcore one with sharding needs a config.yaml and all that
<lazypower> oh this is strictly replset creation?
<maxcan> yup
<jcastro> this is just the simple multi node deployment
<jcastro> lazypower, yeah
<maxcan> resolved -r; rinse; repeat is your friend
<jcastro> ugh
<maxcan> also, needed to make sure that teh configsvr RS was all set up and good before relating to mongos
<jcastro> anyone have their history handy with all the commands? I am working on fixing the readme today
<jcastro> so you can just do it in the first try
<lazypower> Maxcan has a  sharded RS history
<lazypower> Let me reach out to some peeps and see if i can fetch the history of my last deployment.
<jcastro> ta
 * lazypower doffs hat
<jcastro> I don't need the sharded one yet, but I'll take it!
<lazypower> jcastro, its going to be a sharded repl set from me as well...
<jcastro> aha!
<jcastro> the resolved --retry seem to do the trick
<lazypower> jcastro, thats the race condition we ran into. Something's not getting set right away during the relationship-joined/changed hooks
<jcastro> ok
<jcastro> I am going to file a bug
<jcastro> and then add a note in the readme
<jcastro> https://bugs.launchpad.net/charms/+source/mongodb/+bug/1267222
<_mup_> Bug #1267222: Race condition when deploying a simple replica set <mongodb (Juju Charms Collection):New> <https://launchpad.net/bugs/1267222>
<jcastro> if anyone has anything to add
<marcoceppi_> So, you have the ability to create a testing configuration file, it will live in the tests directory. I have it called testplan.yaml but think it's too long. suggestions?
<negronjl> jcastro: I'll get back to you in a few minutes ... let me finish lunch
<jcastro> no worries!
<marcoceppi_> I was going to call it config.yaml, but didn't want ot confuse the actual config.yaml file
<jcastro> config_test.yaml?
<lazypower> marcoceppi_, is this related to setup/teardown of your testing suite? or specifics?
<marcoceppi_> lazypower: it's the ability to see the test driver with configuration options for your charm
<marcoceppi_> more like test plugin preferences
<marcoceppi_> jcastro: test_config.yaml sounds better, so I'll go with that unless someone thinks of the equivlant "promulgate" word for this before eod
<jcastro> no more weird words!
<lazypower> ^
<marcoceppi_> <3
<maxcan> lazypower: just got back, was on a cll
<lazypower> All good my man. I was too.
<lazypower> How's things post deployment? I assume it went without a hitch after we got the cluster setup?
<maxcan> no, took me several hours to get it right
<maxcan> but your help was invaluable
<lazypower> Well thanks for the plug :) Did you happen to do a writeup on your hurdles you faced?
<lazypower> maxcan, and if not, I can help by doing a phaux interview with you. I'm really interested in your experience.
<jcastro> mbruzek, arosales: TLDR is that the juju in stable ppa uses lxc-ls, which in trusty now requires root
<jcastro> 1.17 skips that and should work, so we'll be fine.
<jcastro> note, that it does not work for me right now
<marcoceppi_> jcastro: 1.17.1 should be landing in the dev ppa sooner or later
<mbruzek> should I enable trusty-proposed ?
<mbruzek> Or where do I get the dev one?
<marcoceppi_> mbruzek: ppa:juju/devel
<mbruzek> oh.
<mbruzek> juju dev
<marcoceppi_> actually, 1.17.0 is already out
<marcoceppi_> jcastro: did you try 1.17.0?
<mbruzek> mbruzek@skull:~/workspace/charms/tomcat$ juju --version
<mbruzek> 1.16.5-trusty-amd64
<jcastro> yeah
<jcastro> I get some connection refused error.
<marcoceppi_> mbruzek: yeah, 1.EVEN are "stable" releases, 1.ODD are devel releases
<marcoceppi_> so if you sudo add-apt-repository ppa:juju/devel; sudo apt-get update, sudo apt-get upgrade you'll get 1.17.0
<jcastro> jorge@jilldactyl:~$ sudo juju bootstrap
<jcastro>  ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused
<jcastro> is what I get currently
<marcoceppi_> jcastro: run it with --debug --show-log
<jcastro> oh dude, environment exists
<jcastro> I think I had it bootstrapped
<jcastro> and _then_ upgraded
<marcoceppi_> doh!
<jcastro> ugh, can't destroy it now
<marcoceppi_> jcastro: stop all the juju-* upstart tasks
<marcoceppi_> then rm -f /etc/init/juju-*
<jcastro> got it
<jcastro> blowing away .jenv did it
<jcastro> that's my new debug tool
<marcoceppi_> ah
<jcastro> "something broke? blow away the .jenv file"
<jcastro> ok, so it works fine now with 1.17
<marcoceppi_> jcastro: sweet
<maxcan> lazypower: i will definitely do a write up
<arosales> jcastro, sorry I was tied up in a meeting. thanks for the fyi in trusty needing 1.17
<maxcan> so, anytime I add-unit juju opens up my juju-amazon security group ports 22, 17070, and 37017 to 0.0.0.0/0
<davecheney> maxcan: yes, that is necessary
<maxcan> also dangerous
<davecheney> those are the control ports juju needs to talk to the bootstrap node, the state server and the api server
<maxcan> coulnd't it just only open those ports to the IP of the management server
<maxcan> why 0.0.0.0?
<davecheney> the management server is the bootstrap node
<davecheney> those ports are open so your client can connect to juju
<maxcan> i get that opening to the AWS security-group is to AWS specific
<davecheney> i understand your point
<davecheney> it's not something that juju does at the moment
<davecheney> please consider raising a freature request
<maxcan> i'll add it to my list of feature requests
<maxcan> that i'm writing up
<maxcan> FYI, my setup is that I have a client running on an EC2 host which requires yubikey 2FA for SSH access
<maxcan> my juju scripts generate a random admin secret and run all the juju commands from that machine
<maxcan> so that way, it should be impossible for any outside access to the juju boxes
<davecheney> sounds like a sound practice
<davecheney> the firewaller currently doesnt' handle source ip acls, it just knows how to configure by port
<davecheney> this would have to be something additional to juju
<maxcan> yeah
<maxcan> currently, on AWS at least, the default juju behavior is to open all ports on all juju machines to all juju machines
<davecheney> yes, charms expect that
<maxcan> but, each machine does get its own security group (juju-amazon-N) which is basically unused
<davecheney> yes, this is a known bug
<davecheney> it sort of extends from openstack providers which limit security groups
<davecheney> so we 1/2 finished the workaround
<maxcan> would it be consistent with charms' expected behaviors to only open up ports (besides conmand ports) when there is a relation
<maxcan> and to only use the relaitons ports
<davecheney> charms expect an open network
<davecheney> the open-port close-port comments relate to the external network
<davecheney> so, when i say open network
<davecheney> i mean open internal network
<maxcan> because not all relations have explicit ports?
<davecheney> open-port / close-port only talk about services exposed by the charms
<davecheney> when charms are related together the expectation is they have full network access to one another
<davecheney> eg, mysql <> wordpress
<davecheney> expects 100% access on a private network
<davecheney> wordpress may call expose-port, but that is realy just to setup the port forwarding
<maxcan> i see
<davecheney> eg, when wordpress and mysql relate the mysql charm will call
<davecheney> unit-get private-address
<davecheney> to obtain it's private ip address and pass that via the relation to wordpress
<maxcan> i see
<maxcan> kind of violates the principle of least access but if all the charms expect that, not much to do
<maxcan> for the charms i'm using and writing (mongo and internal) it could be accomplished
<maxcan> next question, is it possible to add-units to a service using a newer revision of the charm without upgading the running instances?
<davecheney> maxcan: no
<davecheney> add-unit always uses the version of the charm that is cached in the state
<maxcan> hm
<davecheney> ie, add-unit always depliys the same version of the charm
<davecheney> i know what you are trying to do
<davecheney> juju doesn't support smoke test upgrades at the moment
<davecheney>  s/smoke test/rolling/
<maxcan> so if i have 20 app servers and hit upgrade charm, will they be done serially or in parallel?
<davecheney> parallel-ish
<davecheney> we wave our hands and say juju is asynchronus
<maxcan> that seems not good-ish
<davecheney> so the only guarnetee is all the units will process the upgrade charm request
<maxcan> zero downtime deploys would be nice
<davecheney> a. eventually
<davecheney> b. before doing any other relation events
<davecheney> maxcan: for zero time upgrades we recommend having two environments
<davecheney> eg. omgubuntu has two environments, A and B, upgrade A, making it the primary B bcomes staging
<davecheney> upgrade B it becomes the primary and A becomes staging
<davecheney> ie is difficult for juju to handle zero downtime upgrades because juju is not a process manager
<davecheney> ie, it doesn't know the state of processes, only the agents which run comments
<davecheney> commands
<maxcan> that wouldn't work for us, we'd have to move our mongo cluster
<marcoceppi_> there's definitely room to for a subordinate charm to do zero downtime upgrades, but you'd have to not use upgarde-charm and instead opt for a configuration option on your service (ie a version configuration option)
<davecheney> another option is to create two services
<maxcan> so, for us, we dont need process managers because we're happy to have immutable app servers
<davecheney> marcoceppi_: yeah, that is what I think the openstack chamrs do
<maxcan> i.e. spin up 10 servers with version 2, when their started, kill the 10 servers with version 1
<davecheney> maxcan: you'd have to do that as two services
<marcoceppi_> right, they tack version as a configuration option and only use upgrade-charm when the charm's code changes. So you can juju set version="whatever"; then have your charm perform leader election and perform rolling upgrade execution
<maxcan> aaaahhh
<maxcan> now it all makes sense
<davecheney> maxcan: i don't know if the mongo db charm would give out the smae credentials on two different relations
<davecheney> i suspect it would not
<maxcan> essentially version my services
<marcoceppi_> davecheney: probably not
<marcoceppi_> maxcan: yes, the openstack charms do this and several others (discourse comes to mind)
<davecheney> maxcan: so possibly in that scenario you have two services, one with zero units, the other with 10
<davecheney> upgrade-charm on one service
<davecheney> then add units to it, and remove units from the other one
<davecheney> or have 10 in each
<davecheney> and just have a big red button on your load balancer that switches the load from one service backend to another
<marcoceppi_> maxcan: here's an example of the configuration options for discourse
<marcoceppi_> http://manage.jujucharms.com/~marcoceppi/precise/discourse and http://manage.jujucharms.com/~marcoceppi/precise/discourse/config
<maxcan> thanks!
<maxcan> davecheney: perfect
<marcoceppi_> If you decouple the application upgrade process from the charm upgrade process you no longer have to rely (as much) on juju to perform the upgrade and can implement your own upgrade logic via the peer relation and config-changed
<maxcan> marcoceppi_: we kind of have.  our install hook pulls a docker image from s3, so if that is updated, even wtihout the charm being updated, we'll get a new version
<marcoceppi_> cool
#juju 2014-01-09
<bashok> can someone shed some light on this bug? https://bugs.launchpad.net/juju-core/+bug/1261780
<_mup_> Bug #1261780: go 1.1.2 TLS-enabled client does not accept our CACert <security> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1261780>
<sarnold> bashok: ignoring the fact that the question is about node.js :) ... http://stackoverflow.com/a/14090402/377270
<bashok> sarnold, thanks for the pointer, does it mean that my cert needs to have subjectAltName that points to the IP in the URI,
<davecheney> i'm pretty sure you can't use ip addresses in subjectAldNames
<davecheney> but it's been a while
<sarnold> bashok: I don't know if the request is being made by IP or not, but if it is, that would make sense to try
<sarnold> davecheney: I don't know if future RFCs removed the ability, but RFC 2818 says in part, "In some cases, the URI is specified as an IP address rather than a
<sarnold> hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI."
<bashok> sarnold, thanks i will give a try to that
<davecheney> sarnold: right
<davecheney> thanks
<davecheney> this would only be for self signed certs
<davecheney> no CA would sign a cert for an IP
<sarnold> hahaha
<sarnold> davecheney: man I hope you're right :)
<sarnold> course worse things have happened..
<Shamaria> Hi all
<Shamaria> I'm a bit new to juju .. and I have a basic question
<Shamaria> What is the difference/relationship between openstack and juju
<Shamaria> ?
<Shamaria> is it based in anyway on openstack??
<lazypower> Shamaria, its not based on openstack. Juju sits a layer above openstack
<lazypower> Juju is an orchestration layer, that interfaces with your provisioner and deployer
<Shamaria> lazypower: thanks for the answer
<lazypower> Anytime
<Shamaria> so, does it require the presence of openstack?
<Shamaria> for any reason?
<lazypower> Nope. It runs on HPCloud, AWS, Azure, and has support for LXC Containers via the local provider.
<lazypower> Its important to know you can deploy openstack with juju - since I left it off that last list.
<Shamaria> interesting!
<Shamaria> so it is good to have tool anyway!
<lazypower> That it is. I encourage you to head over to jujucharms.com and interface with the demo gui to get a feel for what it can offer you
<Shamaria> I've seen a list of supported applications, they call it charms
<Shamaria> that can be delpoyed for me
<Shamaria> which very good
<Shamaria> I will take the venture and try it
<lazypower> Yep, and anything that's not there you can write a charm for in your deployer of choice. Whether that be shell script, ansible, chef, compiled bins.
<Shamaria> Wow
<Shamaria> lazypower: I'm really glad talking to you today
<lazypower> Glad I could be of help. If you have any questions don't hesitate to ask
<Shamaria> sure I will :) ... what is the best place to get stared?
<lazypower> I'm assuming you're running Ubuntu on a rig with at least 8gb of ram and 20gb of free disk space?
<Shamaria> not really, but I'll handle such requirement
<lazypower> I got started with the local provider - https://juju.ubuntu.com/docs/config-local.html
<Shamaria> does it need all the 8GB of ram??
<lazypower> Only if you're planning on deploying 3+ services on a local provider configuration
<Shamaria> I see
<lazypower> it runs quite well on AWS small instances
<Shamaria> v.nice
<ashipika> actually i'm playing with virtual machines and null environment :D
<Shamaria> ya!
<lazypower> Hows that coming ashipika? I haven't taken a look at the null provider in about a month. I htinkt hey just pushed another rev this week didn't they?
<ashipika> it's going great..
<Shamaria> one last question friends ... is the MAAS to Juju is like Hypervisor to Openstack??
<ashipika> i created two images.. a "controller" image and a "compute" image.. controller is automatically bootstrapped when it starts (and has at least 5GB of persistence partition - labeled casper-rw) and when i boot up a compute VM (again with at least 5GB of persistence) it automatically adds itself to the juju environment..
<lazypower> awesome :)
<ashipika> you can check it out here: xmaas.xlab.si (no connection to maas)
<ashipika> just writing a short tutorial for our guys
<lazypower> Shamaria, Correct. Maas is a provisioner, same as the hypervisor.
<lazypower> only, it works with bare metal not virtual machines.
<Shamaria> u mean real servers?
<lazypower> Correct
<Shamaria> and can't be VMs
<ashipika> yes.. read servers
<Shamaria> Oh .. I see
<lazypower> well, dont say can't be vm's
<Shamaria> LOOL .. I get you
<lazypower> because as I understand it, there is support for LXC containers coming to MAAS in the future
<lazypower> no ETA on it from me though, because its from the rumor mill at this point.
<ashipika> but MAAS requires you to have a separate network, because it needs to set up its own DHCP and DNS servers
<lazypower> I want to play with MAAS so bad, i just dont have the setup for it.
<ashipika> try my images.. close to maas, but not quite :)
<ashipika> and it works in VMs
<Shamaria> that's great to hear ... isn't MAAS a base rquirement for Juju?
<Shamaria> that juju can't work without?
<lazypower> Tell ya what ashi, when I'm not writing a plan for reducing cost of ownership on a network I'll do that.
<lazypower> Shamaria, incorrect. Juju is independent of MAAS
<Shamaria> when mass is needed then
<Shamaria> ?
<ashipika> only when you want to provision bare metal servers..
<ashipika> and deploy your services on the
<lazypower> When you want to use MAAS as a provisioner, it would assume the role that one of the other providers is assuming (Read: AWS, HPCloud, LXC, Etc.)
<ashipika> them\
<Shamaria> does this mean juju uses a similar architecutre of openstack's??
<Shamaria> database, rabbitmq, ...
<Shamaria> etc.
<ashipika> juju can deploy those for you..
<lazypower> It uses a controller unit, rabbitmq, zookeeper, mongodb.
<lazypower> so not quite like openstack
<Shamaria> but the same idea
<lazypower> i'm going to disclaim this - i'm not an openstack expert by *any* sense of the phrase
<lazypower> so take my comparisons with a grain of salt and maybe some light research.
<Shamaria> Ok
<ashipika> openstack does not deploy services for you, does it?
<Shamaria> it is an IAAS
<lazypower> i dont think so
<ashipika> yes
<Shamaria> so it doesn't help you providing any service
<ashipika> juju deploys services and does orchestration in a beautiful way :)
<ashipika> exactlly
<Shamaria> but it helps managing your cloud of servers
<Shamaria> Yes
<Shamaria> That's what I newly knew :)
<ashipika> so if you say juju deploy something it will by default as the provider to provision a new machine.. unless you specify --to option that lets you decide where you want to deploy stuff
<Shamaria> so, can I make use of virtual cloud machines to be that new machine?
<lazypower> yep
<ashipika> yup
<Shamaria> so it can be utilized on top of openstack
<Shamaria> that;s really good
<ashipika> yes
<Shamaria> why Juju is not that famous
<ashipika> or use maas if you have some extra machines around
<Shamaria> does it have bugs or it is unreliable in any way?
<Shamaria> ashipika: Yes
<ashipika> well.. it is in development.. so yes, expect some bugs.. i stumbled upon a few while testing.. but the good thing is that development is really active and bugs get fixed quickly
<lazypower> Shamaria, its gaining steam. The best part of juju is the quality gating through the charm store
<lazypower> your work will not be listed as public unless it passes the community review process
<lazypower> This works for building block charms, i'm helping a company here in Pittsburgh onboard with juju for their proprietary stuff since the orchestration just "makes sense"
<Shamaria> I see
<Shamaria> what is the mature similar application out there, I'm talking about open source ones?
<lazypower> I think the big draw for juju is the gui, and the fact you're not tied to a specific framework for your deployer.
<ashipika> br
<ashipika> b
<lazypower> The wordpress charm works really well, discourse, mongodb
<lazypower> I'm getting pretty close to pushing a release candidate for errbit
<Shamaria> I thought Juju's power is its GUI
<Shamaria> what do you mean by "specific framework for your deployer"??
<lazypower> The gui is slick, but everything you do in the gui you can do with the CLI
<Shamaria> of course
<lazypower> Meaning you're not tied to just chef, or ansible, or bash.
<lazypower> you can literally use whatever deployer framework you want
<Shamaria> is that a bad thing?
<lazypower> nope, its flexible
<Shamaria> yep
<Shamaria> brb
<ashipika> the only thing i REALLY miss in GUI is the --to option
<Shamaria> I'm back
<Shamaria> One very important question
<Shamaria> after installaing some architecture with the required connections between the apps
<Shamaria> then I decided for any reason to uninstall the juju
<ashipika> yes?
<Shamaria> will this affect by any mean the installed architecture
<ashipika> well.. no.. unless juju gets stuck destroying a unit or something..
<lazypower> I don't think that's recommended. You can power down the controller unit when its not in use to help reduce overhead costs if thats you're concern
<ashipika> but i would say that really depends on the charms you deploy
<ashipika> lazypower: do i understand correctly that i must subscribe "charmers" if i want a charm to go through the review process?
<lazypower> Correct
<lazypower> https://juju.ubuntu.com/docs/authors-charm-store.html
<lazypower> in-case you need a refresher.
<rawang> hello guys , i wonder after I installed ceph-radosgw, how do i test it from cli?
<Shamaria> lazypower: , ashipika: one point is still not so clear to me ... is it possible that MAAS will consider VMs as bare-metals
<ashipika> i never played with VMs and MAAS.. since it uses PXE boot to provision new machine it need to set up its own DHCP server or change the existing one -> our admins would go bat-crazy if i tried that..  so i created a dedicated network just for MAAS testing..
<lazypower> Shamaria, http://www.slideshare.net/openstackindia/maas-juju-introduction
<Shamaria> this makes you opt for the virtualization
<lazypower> really good set of slides over Juju, Maas, and whats capable at a high level.
<Shamaria> moreover, there must be a way to disable the isntallation of DHCP and DNS servers
<Shamaria> lazypower: the presentation you sent means yes
<Shamaria> MAAS can handle cloud instances as bare metal
<Shamaria> Did I get it right?
<lazypower> Not a MAAS expert, last i tried maas it wanted bare metal.
<lazypower> i think theres a VMAAS coming down the tube, but its going to be experimental if its available
<Shamaria> what if I wanted to deploy the service on multiple VMs
<Shamaria> what shall be done
<Shamaria> will I have to handle this manually?
<lazypower> Depends on the provider. If you're using one of the supported providers - no. It talks to the provider via their API and spins up a new server, bootstraps it, and then loads your service
<lazypower> if you're going with the null provider, provisioning machines is a manual process
<Shamaria> I'm afraid I have a very basic question ... what is the provider ?
<lazypower> Juju supports provider environments. Think of the provider as whatever service is going to be "providing" your machines. If thats bare metal, virtual, or otherwise.
<Shamaria> I see your point
<Shamaria> do you have examples of providers?
<ashipika> Shamaria: as i wrote earlier.. if you want to play with VMs you can always try the images at xmaas.xlab.si and the null environment/provider
<ashipika> it also gives you the option of creating bootable CD/USB, plug it into a machine and have it "bare metal"
<ashipika> i.e. without virtualization
<Shamaria> ashipika: Yes, you already said that .. exuese my novelty :)
<Shamaria> Thanks a lot
<lazypower> ashipika, bookmarked for later :)
<Shamaria> hahaha
<ashipika> > /dev/null :D
<Shamaria> LOL
<Shamaria> lazypower: , ashipika:  I really thank you both a lot
<Shamaria> I learned much from you today
<lazypower> Anytime. Happy to help
<Shamaria> I'll keep returning to this room
<ashipika> Shamaria: you're welcome.. i'm just a juju beginner myself
<Shamaria> but you helped a lot :)
<Shamaria> You both have a really good day/night
<InformatiQ> Hei guys anyone care to test this charm for me https://bugs.launchpad.net/charms/+bug/795480
<_mup_> Bug #795480: Charm needed: Trac <bitesize> <Juju Charms Collection:Incomplete by rhanna> <https://launchpad.net/bugs/795480>
<marcoceppi> jcastro: remember when you used to be able to get PNGs of a juju deployment
<marcoceppi> was that in jitsu?
<jcastro> it wasn't png's it was a gource thing
<jcastro> we just piped status to gource
<jcastro> or do you mean like a picture of a deployment? I don't think we ever did that did we?
<marcoceppi> jcastro: we def did. I can't remember if it was juju status --format=png or if it was in jitsu
<jcastro> huh
<jcastro> marcoceppi, ok here we go
<marcoceppi> jcastro: where are we going!
<jcastro> I am going to test negronjl's sharding mongo config via the local provider
 * marcoceppi holds breath
<negronjl> jcastro: good luck ( you'll need it ) :)
<jcastro> negronjl, load is 10!
<negronjl> jcastro: never tested it on local provider ... better you than me :P
<jcastro> yeah
<jcastro> it's not bad
<jcastro> machine is totally usable
<jcastro> load is now 15 and climbing
<jcastro> negronjl, dude, it's working
<jcastro> well, well on its way to working
<negronjl> jcastro: cool
<lazypower> Nice! You're swamping me already, i only deployed 12 units
<lazypower> 3 shards, x repls + config servers + arbiter
<lazypower> Let me see your YAML when you're done please
<jcastro> jorge@jilldactyl:~$ sudo juju bootstrap
<jcastro> ERROR cannot use 37017 as state port, already in use
<jcastro> marcoceppi, any ideas there?
<jcastro> hi fwereade
<jcastro> any idea why I would get this:
<jcastro> jorge@jilldactyl:~$ sudo juju bootstrap
<jcastro>  ERROR cannot use 37017 as state port, already in use
<marcoceppi> jcastro: it means you've already got juju-db running
<jcastro> oh ok
<jcastro> so restart it?
<marcoceppi> initctl list | grep juju
<marcoceppi> sounds like a bad destroy
<jcastro> it is not running
<jcastro> but yeah, probably a bad destroy
<marcoceppi> something is using that port, what does ps -aef | grep mongo show?
<fwereade> jcastro, yeah, that sounds most likely
<jcastro> mongod is using the port
<jcastro> do I stop or restart it?
<fwereade> jcastro, if you set api-port and state-port you should be able to run multiple local providers fwiw
<marcoceppi> stop it
<jcastro> when I stop it it seems to fire back up
<marcoceppi> jcastro: ohhhhhh
<marcoceppi> jcastro: these are probably per user upstart jobs
<marcoceppi> maybe not, idk if juju is using thatyet
<marcoceppi> what does sudo initctl list | grep juju show?
<jcastro> http://paste.ubuntu.com/6722577/
<marcoceppi> jcastro: yeah, sudo stop juju-db-root-local
<marcoceppi> jcastro: then
<marcoceppi> jcastro: I want you to try something different
<jcastro> ok
<marcoceppi> don't use sudo during bootstrap
<marcoceppi> jcastro: the suspense is killing me
<jcastro> ok
<jcastro> errors out with the normal "sudo must be used"
<marcoceppi> jcastro: ah, damn. Thought something magically had happened
<jcastro> should I try to sudo bootstrap again?
<marcoceppi> jcastro: yes
<jcastro> ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused
 * thumper looks briefly at chatter
<thumper> you guys tring to get multiple local providers working on one machine?
<jcastro> no
<marcoceppi> thumper: no, just one
<thumper> oh
<jcastro> I am trying to get one local working
<marcoceppi> jcastro: try your good 'ol .jenv dump
<thumper> jcastro: what is the tl;dr of the situation?
<jcastro> I ran out of disk space
<jcastro> so I added a drive and remounted /var/lib/lxc
<jcastro> ERROR environment is already bootstrapped
<jcastro> when I try to bootstrap, but there are no containers running
<marcoceppi> delete the local.jenv ?
<jcastro> yep
<thumper> jcastro: are you looking for the definitive list of shit to delete?
<marcoceppi> jcastro: rm -f /etc/init/juju-* ?
<thumper> there are to init files in /etc/init, one for the machine agent and one for the mongo db
<thumper> there is a file in /etc/rsyslog.d for the logging
<thumper> there are the containers defined in /var/lib/juju/containers
<thumper> there are the containers themselves in /var/lib/lxc
<thumper> there is the directory in ~/.juju/<environ>
<thumper> there is the .jenv file in ~/.juju/environments
<thumper> nuke all those
 * marcoceppi makes notes
<jcastro> which is the file for mongo?
 * thumper looks
<jcastro> mongodb.conf?
<thumper> nope
<thumper> /etc/init/juju-db-<user>-<envname>.conf
<thumper> /etc/init/juju-agent-<user>-<envname>.conf for the machine agent
<jcastro> should I move back to 1.16.5?
<thumper> /etc/rsyslog.d/25-juju-<user>-<envname>.conf
<thumper> jcastro: this hasn't really changed between 1.16.5 and 1.17
<jcastro> sigh
<jcastro> this never works for me
<jcastro> I'll just skip this and come back to it
<jcastro> I'm supposed to be reviewing 2 charms a day, not one charm in 2 days!
<thumper> :-(
#juju 2014-01-10
<bashok> Hi Guys, after all the hassles i was finally able to see the bootstrapping process made some progress, however still it was unable to start the bootstrap instance due to this error
<bashok> " ERROR juju supercommand.go:282 cannot start bootstrap instance: index file has no data for cloud {blr http://192.168.124.81:5000/v2.0} not found"
<bashok> any idea how to solve this
<bashok> sarnold, davecheney any thoughts?
<ashipika> hi guys.. anybody there?
<mgz> asking something like that just just begging for a "no" :P
<mgz> this is irc, if you have a question just write it and wait
<ashipika> sorry.. sorry.. a moment of panic :) logged into launchpad, all my code was gone.. after a minor heart attach figured out i used a wrong account.. all better now..
<mgz> :D
<ashipika> sorry again
<mgz> happy ending
<arges> I've used the 'juju sync-tools --source <path>' sucessfully after downloading tarballs locally. Is there a way to have --source point at a remote URL over HTTP? Thanks
<marcoceppi> hey sinzui - is there anything I can do about this other than wait? https://bugs.launchpad.net/charm-tools/+bug/1262836
<_mup_> Bug #1262836: charm-tools fails to build on trusty <trusty> <Juju Charm Tools:Triaged> <https://launchpad.net/bugs/1262836>
<marcoceppi> I didnt' see a workaround in the bug report
 * sinzui looks
<marcoceppi> oops, you didn't report that, jjox did
<sinzui> hmm, recipes always force native version, so the issue is to change the package version string
<sinzui> marcoceppi, This does look like the bzr-plugin forcing the recipe to build as native. Lp always rung with fallback mode
<sinzui> marcoceppi, I experienced this in Oct/Nov and found that I could make a version string that was acceptable. While I could get a recipe for juju-core, I abandoned it.
 * sinzui looks for old nots
<sinzui> marcoceppi, change the plus to a squiggle in the recipe. I seem to have played with that a lot
<marcoceppi> sinzui: there's not recipie for this, I've been cutting releases myself
<sinzui> marcoceppi, This is what I got to work before abandoning recipes: https://code.launchpad.net/~ce-orange-squad/+recipe/juju-core-unstable-packaging
<marcoceppi> using ppa-release similar to the juju-core releases now
<marcoceppi> err, ppa-release == backportpackage
<marcoceppi> oh, suddenly this bug makes sense
<marcoceppi> sinzui: sorry about that, I see the problem now
<sinzui> marcoceppi, oh, I saw the recipe was using quit in debian/source/format is your branch doing the same
<marcoceppi> sinzui: this is charmtools 0.3
<marcoceppi> 1.x isn't backwards compatible I think IS is building it themselves. I'll update the bug
<sinzui> ha ha
<marcoceppi> let me go get some caffine
<yolanda> hi, i'm working on clustering for rabbit charm, and i found an issue retrieving all the peers for a relation
<yolanda> i created 4 clustered nodes, if nodes are up, it works ok and i get a list of the 4 nodes when trying to query peers
<yolanda> but then i just stop first unit with nova stop, do the query again, and only the first unit (the one stopped) is reported
<marcoceppi> yolanda: that's interesting. When you say query you mean with relation-list or in the juju status
<yolanda> marcoceppi, in the relation-list
<yolanda> i can reproduce it right now
<yolanda> i got logs telling i only had first unit when i stop it
<yolanda> i started again and got all the units
<yolanda> i'm programming rabbitmq clustering and that's an issue, if first unit is stopped for some reason, i cannot add more units
<lazypower> jcastro, did you release your mongodb bundle?
<marcoceppi> yolanda: that's odd, I've never seen that before and I don't quite know where to start looking. If it's replicatable I'd file a bug against juju-core about it with instrutions to replicate
<yolanda> yes, i can replicate it
<yolanda> i'll write some bug
<jcastro> lazypower, I was just going to check
<jcastro> https://jujucharms.com/fullscreen/search/bundle/~jorge/mongodb-cluster/1/mongodb-cluster/?text=mongodb-cluster
<jcastro> Kablammo!
<lazypower> Great minds think alike
<lazypower> BOOM!
<marcoceppi> yolanda: thanks! sorry I couldn't be of more help
<jcastro> hey wanna give it a shot?
<yolanda> no problem
 * marcoceppi pings fwereade to see if he can shed light on yolanda's issue
<lazypower> You know i do!
<yolanda> files this one: https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1267913
<_mup_> Bug #1267913: juju relation-list doesn't report full units list when unit is down <juju (Ubuntu):New> <https://launchpad.net/bugs/1267913>
<fwereade> marcoceppi, sorry, was meeting, reading back
<fwereade> yolanda, thanks for the bug, that's bizarre and terrifying, I'll take a look
<yolanda> thx
<marcoceppi> Okay, last call for changes to charm-tools
<rick_h_> marcoceppi: I request a pony!
<lazypower> Hey jorge
<lazypower> with your mongodb-cluster bundle, the relationships incoming is a bit wonky and did not draw on the gui
<jcastro> yeah so
<jcastro> that happened to me yesterday
<lazypower> http://i.imgur.com/QUcHZQg.png
<jcastro> https://jujucharms.com/fullscreen/search/bundle/~jorge/mongodb-cluster/1/mongodb-cluster/?text=mongodb-cluster
<lazypower> WHen i go to draw the relationship, it shows a dialogue displaying the options for the relationship.
<jcastro> they're supposed to be there
<jcastro> let me try with a simple wordpress bundle
<jcastro> I mean, if you look in the bundle itself, the relationships are there
<lazypower> I dont doubt it, i'm still investigating.
<lazypower> Just reporting my initial findings
<jcastro> yeah, I'm just saying, I don't think it's the bundle itself
<lazypower> Ah, i think what happened is the relationships were pending this last unit coming online
<lazypower> I love juju, its so smart.
<rick_h_> lazypower: jcastro yea, relationships in budles are only applied after all units are up I believe
<jcastro> ah
<jcastro> but what happens if he had to resolve --retry a bunch of things?
<rick_h_> not sure, if the bundle process was still processing it might work, but not tested it tbh.
<lazypower> I can wipe this and start over
<rick_h_> if something throws an error the bundle deploy quits
<jcastro> aha
<jcastro> so basically, the race condition in the charm probably causes the bundle to quit
<lazypower> Thats my guess, but the other problem i ran into is the lxc container already created bug.
<lazypower> thats reported as resolved in .17 is it not?
<jcastro> lazypower, I tried it on aws
<jcastro> so I don't think it's a provider-specific thing
<lazypower> Ah ok
<marcoceppi> rick_h_: there's no way to re-run deployer?
<rick_h_> wipe everything and try again
<marcoceppi> rick_h_: is there anything on the roadmap to report when deployer throws an error to the gui? maybe like a "re-run" since deployer will pick up where it left off
<marcoceppi> I meah, obviously fixing the charm is a priority
<rick_h_> marcoceppi: right now if it dies in an error it should report whatever Juju tells it
<rick_h_> in the Gui notification box
<marcoceppi> rick_h_: gotchya
<rick_h_> if it does not, then there's an issue we need to fix, but we try to help the user know something went bad if we can
<jcastro> aha!
<jcastro> marcoceppi, found the issue with the local provider
<jcastro> I had to blow away .juju/local too
<rick_h_> jcastro: which issue is this?
<jcastro> marcoceppi, do you have that list of stuff you need to blow away from thumper? we should write that up
<jcastro> rick_h_, my local provider stopped working
<marcoceppi> jcastro: yeah
<marcoceppi> /etc/init/juju-*; /etc/rsyslog.d/25-juju*; /var/lib/juju/containers/*; /var/lib/lxc/juju-*; ~/.juju/<env>; ~/.juju/environments/<env>.jenv
<marcoceppi> jcastro: ^
<avoine> also /etc/lxc/auto/ I think
<avoine> the symlinks in it
<jcastro> http://askubuntu.com/questions/403618/how-do-i-clean-up-a-machine-after-using-the-local-provider/403619#403619
<jcastro> avoine, gotcha, adding now
<avoine> jam: btw I create a bzr branch for that like you ask: https://code.launchpad.net/~patrick-hetu/golxc/fix-1238541
<dpb1> marcoceppi:/jcastro: very simple apache2 fix, it's broken right now if you don't set "servername" and are generating self-signed-certs: https://code.launchpad.net/~davidpbritton/charms/precise/apache2/fix-no-servername-case/+merge/201254
<jcastro> ack
<jcastro> it's coming up on the charm audit anyway
<jcastro> nice catch!
<marcoceppi> dpb1: thanks
<dpb1> :)
<achiang> hello, this is more of a generic cloud question than juju-specific, but are there any cloud providers who give free accounts on micro/tiny instances?
<achiang> i thought a micro instance on EC2 might have been free, but it looks like that's only a promo price for 1 year
<marcoceppi> achiang: not that I'm aware of. AWS has 700 free hours of micro a month (which equates to about 1 micro a month) but the micro is a pretty poor performance instance size
<achiang> marcoceppi: is that forever?
<marcoceppi> achiang: for the first yea
<achiang> or does that only last for 1 year?
<achiang> damn, right...
<achiang> hoping for a more long term solution
<sarnold> canonistack?
<marcoceppi> if you work for Canonical, then that does work
<achiang> i'm working on something for the general public
<sarnold> ah
<achiang> too bad heroku isn't a generic OS
<achiang> maybe i should play with the vagrant images after all
<achiang> but that's slightly more annoying
<marcoceppi> it's certainly the cheapest
<achiang> going down the heroku path... i could package up my stuff and put it in pip maybe
<achiang> or pypi, rather
<achiang> and then could specify my package in requirements.txt
<achiang> ugh
<achiang> but then i have to make a whole django app
 * achiang keeps searching for a free lunch somewhere
<achiang> can i conceptually think of juju+vagrant as a "cloud environment on your desktop" ?
<achiang> who owns content here - https://juju.ubuntu.com/docs/config-vagrant.html
<achiang> the vagrant download link is old
<achiang> should be this link: http://www.vagrantup.com/downloads.html
#juju 2014-01-11
<TheLordOfTime> if someone has questions about making a custom Juju charm for a custom nginx+pagespeed thing, can I direct them here to get help with that?
<marcoceppi> achiang: the charmers do
<marcoceppi> achiang: I'll update the docs
<marcoceppi> TheLordOfTime: yes
<achiang> marcoceppi: cool, thanks
<marcoceppi> achiang: the vagrant gives you the ability to run an Ubuntu VM and LXC on that VM
<marcoceppi> giving you a cloud on your desktop
<achiang> marcoceppi: understood
 * achiang spent the afternoon hacking the actual REST end points he wants to charm
<achiang> so monday, i'll pick up vagrant again
<marcoceppi> achiang: cool, we'll be here to help ou
<marcoceppi> t
<achiang> :)
<achiang> thanks
<TheLordOfTime> marcoceppi: awesome, I'll direct them here.
<marcoceppi> TheLordOfTime: it's nearing the weekend, so the room tends to quite down, but during daylight hours Europe/US times the room is pretty active
<TheLordOfTime> marcoceppi: indeed.  They're on /r/Ubuntu so I don't expect them to immediately show up here though :0
<TheLordOfTime> :) *
 * marcoceppi goes and peeks at the subreddit
<TheLordOfTime> marcoceppi: http://www.reddit.com/r/Ubuntu/comments/1u8ptk/nginx_server_to_serve_bigger_role_in_ubuntu_1404/ if you want a direct link
<marcoceppi> oh yeah, we've done some modpagespeed stuff in the WordPress charm
<TheLordOfTime> marcoceppi: nginx isn't getting pagespeed in Debian or Ubuntu, because this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707069
<TheLordOfTime> marcoceppi: but they want a custom juju charm that can launch the custom nginx+pagespeed build but meh
 * TheLordOfTime isn't a Juju person, he's just the triager / Unofficial Ubuntu Maintainer for the NGINX Packages
<marcoceppi> charms are like the archive, if the archive was the wild west
<TheLordOfTime> hehe
<marcoceppi> so that's a pretty good use case for juju
<TheLordOfTime> mhm
<TheLordOfTime> marcoceppi: personally, I'll stick to the package maintenance and just point the nginx + juju questions to you all :p
<TheLordOfTime> since I know absolutely 0 about juju :)
<TheLordOfTime> other than the fact it exists
<marcoceppi> TheLordOfTime: fair enough :D
<marcoceppi> I've abused the heck out of your nginx packages over the years
<TheLordOfTime> marcoceppi: hehe
<TheLordOfTime> marcoceppi: i haven't been maintaining them *that* long
<TheLordOfTime> only the past year and a half maybe
<TheLordOfTime> (in the PPAs)
<TheLordOfTime> and I'm WAY behind on the updates there :P
 * TheLordOfTime just finished fixing an FTBFS in the mainline branch :p
<marcoceppi> well, at least for the last 10 mos
<marcoceppi> seems like years
<TheLordOfTime> indeed
<TheLordOfTime> marcoceppi: the fact that Jorge even said the prep for nginx being even remotely considered for main was because of me, that means my name's technically tied to the nginx packages in Ubuntu now..
<TheLordOfTime> especially since arstechnica and omgubuntu picked it up
<TheLordOfTime> but that's a discussion for elsewhere, I'll leave you all be :)
<marcoceppi> :D
<TheLordOfTime> ... wait, I did mention that nginx is being considered for main in 14.04... right?
<marcoceppi> Oh I'm well aware of that, and very excited
<TheLordOfTime> so are a lot of people apparently.
<TheLordOfTime> :O
<TheLordOfTime> :) *
<jaywink> hi - is it normal for an openstack bootstrap instance to be allocated three IP's toward the public network?
<jaywink> hmmm http://streams.canonical.com/ is empty :P is this normal?
#juju 2014-01-12
<Jose__> hi can I create private cloud storage and computing with #juju
<Jose__> ?
<Jose__> @markthoms ho
<mbruzek> hello marcoceppi I have a few questions
<marcoceppi> mbruzek: go for it
<mbruzek> I am reading that Amulet can be installed via pip.  How does one add something so pip can find it?
<marcoceppi> mbruzek: if you're on Ubuntu, just apt-get install amulet
<mbruzek> Yeah I saw that
<marcoceppi> mbruzek: as for pip, you just `sudo pip install amulet`
<mbruzek> I am just a curious person and have used pip before, but don't know how you get your code in the pip repos
<marcoceppi> pip is a package management tool for python, so you install pip with the pip package; then just pip install <package>
<marcoceppi> you'll need sudo for amulet as it modifies system paths
<marcoceppi> pip amulet and apt-get amulet will conflict with each other though
<mbruzek> But how does pip know where to find amulet?
<marcoceppi> mbruzek: PostScript
<marcoceppi> oop
<marcoceppi> mbruzek: https://pypi.python.org/pypi
<marcoceppi> huh, maybe I didn't put it on pip yet
<marcoceppi> pypi*
<marcoceppi> oops, only charm-tools and charmworldlib are on pypi. So you can't install amulet with pip yet
<mbruzek> Ok I see the Python Package index.  Thanks marcoceppi
<marcoceppi> np o/
<jaywink> hi. Anyone tips on how to modify image-metadata-url of bootstrapped machine? I bootstrapped to an openstack cloud with the image metadata hosted locally but of course the bootstrap instance cannot connect to my computer so I cannot deploy anything :)
<mbruzek> hi jaywink I am guessing that your computer is not on the same subnet as your OpenStack instance?
<jaywink> mbruzek, no :P I can upload the image metadata somewhere but the bootstrap was kind of tricky due to this cloud being in beta so wondering if I can modify the config on the bootstrap instance to use another metadata url
<marcoceppi> jaywink: you can't modify it once bootstrapped, iirc; you'll need to destroy, put the image-medata somewhere accessible, then rebootstrap
<jaywink> marcoceppi, ok :/ tnx
 * mbruzek defers to marcoceppi 
<marcoceppi> jaywink: I'd check with one of the devs tomorrow, maybe fwereade would know, but they're usually not on during the weekends
<marcoceppi> from what I understand it's not a trivial process
<jaywink> btw what has happened to http://streams.canonical.com? it has gone empty
<jaywink> marcoceppi, maybe I will raise I bug. I can think of a use case in a production environment if the metadata needs to be moved or is moved for some reason - recreating everything just to change the metadata url doesn't sound ideal :)
<marcoceppi> jaywink: I'm not sure about the streams URL. The metadata is either stored in the object store or in the mongodb database. If it's the former, you should be able to download, overwrite it, then upload it again. If the latter it's going to be a bit more complex
<marcoceppi> jaywink: check the bucket you defined as control-bucket if any of the files have the metadata information in there
<jaywink> ok tnx will check
<jaywink> marcoceppi, nah only tools in the objectstore afaict
<marcoceppi> jaywink: hum, it's probably in the mongodb database then
<marcoceppi> *unforunately*
<jaywink> no prob, will raise a bug. thanks!
<popey> I am running juju 0.7+bzr628+bzr633~precise1 on 12.04, and i have done a deploy of cs:~popey/precise/yacy-5 and expose, but it doesn't seem to get an IP
<popey> where's the best place to start debugging?
<popey> 2014-01-12 14:18:00,948 Machine:0: unit.deploy INFO: Started service unit yacy/1
<popey> 2014-01-12 19:42:52,581 INFO Service 'yacy' was already exposed.
<popey> 2014-01-12 19:42:52,584 INFO 'expose' command finished successfully
<popey>         public-address: null
<popey> â¹
<marcoceppi> popey step 1) don't use 0.7
<marcoceppi> popey: latest recommended stable is 1.16.5 from ppa:juju/stable
<marcoceppi> if you don't want to add a PPA, consider using the cloud-tools archive (since you're on 12.04)
<popey> alan@homeserver:/etc/apt/sources.list.d$ cat juju-pkgs-precise.list
<popey> deb http://ppa.launchpad.net/juju/pkgs/ubuntu precise main
<popey> thats my current ppa in use
 * popey adds that ppa
 * popey destroys and starts again
<popey> bah!
<popey> juju now needs mongo
<popey> why didn't it install that as a dependency rather than echo some lines telling me how to use apt. how odd
<popey> http://paste.ubuntu.com/6741064/
<popey> bah
 * popey regenerates config
<popey> alan@homeserver:~$ juju debug-log
<popey> Permission denied (publickey).
<popey> ERROR exit status 255
<popey> bah!
<popey> alan@homeserver:~$ juju expose
<popey> error: no service name specified
<popey> inconsistency detected! (all other errors are "ERROR", but that one is "error:"
<popey> \o/ got it working, thanks marcoceppi
<marcoceppi> popey: debug-log doesn't work on local provider
<marcoceppi> https://juju.ubuntu.com/docs/config-LXC.html#debug-log
<marcoceppi> also, the errors should all be lower case, the ERROR exit status is an error message from SSH just being passed through to the client
<marcoceppi> popey: to fix the mongodb issue, you should just install juju-local (which should be the package it tells you you need instead of saying "oh just install mongodb"
 * marcoceppi wanders offline again
#juju 2015-01-05
<weblife> Would anyone here be interested in a book about "Engineering Customer Relationship Management Web Applications with Node.js & MongoDB" : https://github.com/webbrandon/simple-secure-auth
<lazyPower> Morning Juju o/
<rick_h_> lazyPower: woot woot
<skay> o/
<skay> arg, I don't know why this just started happening. juju bootstrap is failing. it was working earlier today. http://paste.ubuntu.com/9677528/
<skay> halp
<marcoceppi> skay: you may have some old reminants laying around
<marcoceppi> skay: what does `sudo initctl list | grep juju` show?
<skay> marcoceppi: juju-agent-sheila-local start/running
<marcoceppi> skay: yeah, you've got an unclean destruction of the local provider
<skay> marcoceppi: the first time this started happening, I ran http://paste.ubuntu.com/9677575/ in hopes it would clean up everything
<marcoceppi> skay: `juju destroy-environment --force local`
<marcoceppi> skay: well, that's a start..
<marcoceppi> skay: it's missing a few things
<marcoceppi> it's a bit overreaching, I should go update that ask ubuntu question
<skay> retrying after running destroy-environment --force local
<marcoceppi> skay: wait
<skay> marcoceppi: same result
<skay> marcoceppi: sorry, trigger happy
<marcoceppi> run `sudo stop juju-agent-sheila-local` first
<marcoceppi> you delete the init file, but never actually stop the process
<marcoceppi> you should stop the juju-agent processes first, then run the clean up script
<skay> oh cool, I got an interesting error when I tried to stop the process
<skay> stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
<marcoceppi> skay: right, because you removed the init file :)
<mwak_> hi
<skay> derp. what do I do now?
<marcoceppi> skay: ps -aef | grep mongo
<skay> kill that?
<marcoceppi> skay: maybe
<marcoceppi> depends if it's the right mongo proc
<marcoceppi> I think there's something else that runs too
<marcoceppi> let me check
<skay> there seems to be only one running here
<marcoceppi> skay: kill the mongo if it's from /usr/lib/juju
<marcoceppi> skay: also, kill any jujud processes running
<marcoceppi> of which there may be one
<skay> marcoceppi: things are good now
<skay> marcoceppi: thanks kindly
<marcoceppi> skay: no worries, I'll add this in to the local provider plugin I'm building
<skay> marcoceppi: I guess in the script I have, it should go through the list of files in /etc/init/juju-* and sudo service stop them?
<marcoceppi> skay: yes, you should basically loop thorugh each of the services listed in `sudo initctl list | grep juju`
<skay> marcoceppi: what's going to be in the plugin?
<marcoceppi> skay: a whole bunch of stuff, I've outlined here:
<marcoceppi> https://github.com/juju-solutions/juju-local
<skay> marcoceppi: thanks. btw, I went ahead and started adding the step to put a stop to juju daemons in my script, https://github.com/codersquid/dotfiles/blob/master/bin/juju-cleanup#L16 though I haven't tested it yet. but if you see a problem in that line at a 2 second glance, let me know
<marcoceppi> skay: you could add them to the existing juju plugin
<marcoceppi> https://github.com/juju/plugins/blob/master/juju-clean
<skay> marcoceppi: okay
<skay> marcoceppi: I'm not certain the script I'm using does things you'd want in that plugin, but I'll go ahead and submit a PR for comment
<skay> marcoceppi: hey, https://github.com/juju/plugins/pull/41
<skay> I wish I could remember whoever it was in here who helped with a cleanup script before. what I'm using is based on the answer and on their script
<lazyPower> skay: probably mbarnett
<lazyPower> er mbruzek
<marcoceppi> skay: thanks for the PR, looks good for the most part, left some feedback
<designated> what does the little heartbeat icon next to the hacluster charm represent?  does the number indicate the number oc clusters?
<designated> s/oc/of
<marcoceppi> designated: it indicates the number of services heartbeat is connected to
<marcoceppi> since it's a subordinate and can only exist on an existing service
<marcoceppi> err
<marcoceppi> s/heartbeat/hacluster
<designated> marcoceppi: thank you
<designated> marcoceppi: is it normal, once clustering completes, for the relation to turn gray and the heartbeat icon to show "1"?
<marcoceppi> designated: yes
<marcoceppi> subordinate relation lines tend to go grey to stay out of the way of the tree
<designated> marcoceppi: thank you, that clears up a little of the confusion
<seal_> I have deploy a simple docker charm, which simply installs docker on ubuntu 1404
<seal_> when I run juju ssh <service>/0 and
<seal_> then run sudo docker run -i -t ubuntu /bin/bash -v
<seal_> I get FATA[0000] Cannot connect to the Docker daemon. Is 'docker -d' running on this host?
<marcoceppi> seal_: well, is docker -d running on the host?
<seal_> tried running sudo docker -d
<seal_> yes
<seal_> wait
<seal_> cheecking
<seal_> permission denied and I ran it as root
<seal_> also tried running under ubuntu user
<seal_> permission denied
<marcoceppi> I'm not sure why it'd be doing that, lazyPower ^?
<lazyPower> sec - on another problem. be with you shortly
<seal_> ok thanks
 * lazyPower reads scrollback
<lazyPower> seal_: which docker charm did you look at?
<lazyPower> seal_: also, that is indeed strange, as sudo - it should have had no problems communicating with it.
<seal_> well I could not find any
<seal_> so I just wrote a basic charm with a single install hook
<seal_> mainly curl -sSL https://get.docker.com/ubuntu/ | sudo sh
<seal_> which reported no error even when using juju debug-hooks
<lazyPower> seal_: https://github.com/chuckbutler/docker-charm
<seal_> ok will try that
<lazyPower> seal_: this is our active work target for docker, and when its completed we'll runt he gauntlet of upstream review
<lazyPower> it has some preliminary documentatino around cross host networking - but that's going to be the first serious change we make to it, as we're investigating in splitting it out from the charm itself and making it composeable with subordinates
<lazyPower> i'm not sure why docker would be doing that to you though - thats a really strange issue to crop up
<lazyPower> seal_: feel free to ping with any questions/comments/concerns/issues
<seal_> yeah very strange as I have it installed locally and it works
<seal_> thanks lazyPower
<lazyPower> np
<noise][> Hi, I'm trying to troubleshoot an issue where I've got a working relation-changed hook from my website providing charm to haproxy. All is good with the 1st deploy of both services, but when I add a 2nd website unit and it calls relation-set to the haproxy, the haproxy charm's reverseproxy-relation-changed never gets called
<lazyPower> noise][: is this being done via add-unit? or are you relating a second charm all together to haproxy?
<noise][> add
<noise][> lazyPower: add-unit
<lazyPower> interesting, it should have called the rp-relation-changed hook to set it as a round-robin target
<noise][> y, no sign of it though :(
<lazyPower> noise][: can you file a bug against the haproxy charm on this?  https://bugs.launchpad.net/charms/+source/haproxy
<noise][> lazyPower: will do. any idea where to start looking to hunt it down? It looks like the haproxy charm just doesn't even get called again
<lazyPower> noise][: i would attach to a debug-hooks session on haproxy, run the relationship and try to intercept it and run teh hooks interactively
<lazyPower> i suspect whats happening is the hook is getting called but bailing out because its getting a false positive thinking its already configured and doing a no-op
<noise][> y, tried that, got no calls
<lazyPower> hmmm
<noise][> but i'll try again w/a clean start
<lazyPower> what version of juju noise][?
<noise][> 1.20.10-utopic-amd64
<lazyPower> ok thats -stable in utopic, hmm
<lazyPower> yeah i cant come up with any reason why it wouldnt' get called
<noise][> lazyPower: i should note I'm using the "Relation-Driven Proxying" method, specifying "services=" in the relation-set
<noise][> but it works fine for the first website unit, so not sure why it's failing for additional
<noise][> anyway, i'll file a bug and continue to hunt
<whit> cory_fu, is there a way to beam back changes from a unit w/ dhx?
 * whit is trying to figure out sync
<cory_fu> whit: -s
<whit> so if I have dhx session running without -s cory_fu?
<cory_fu> dhx -s unit will automatically do a sync-charm when the session is done
<whit> cory_fu, but I have to start it with -s (in the charm dir?)
<cory_fu> whit: Well, you could always close the current dhx session and then start a new one with -s
<whit> ok... that works
<cory_fu> In the charm dir, yes.  You could also just manually run sync-charm
<cory_fu> It's pretty straightforward
<cory_fu> whit: Basically just: juju sync-charm unit/0
<cory_fu> (from within the charm directory)
#juju 2015-01-06
<X-Rob> Any way to change the default memory size of KVM guests when they're made?
<X-Rob> Everything seems to be being created with  512M or RAM no matter what I do
<sarnold> X-Rob: what's creating your kvm guests?
<X-Rob> sarnold: 'juju add-machine kvm:10 --constraints mem=8G'
<X-Rob> which various places seem to imply should work
<sarnold> X-Rob: interesting, I hadn't seen the kvm:10 thing before :) thanks
<X-Rob> https://bugs.launchpad.net/juju-core/+bug/1399613
<mup> Bug #1399613: juju-core not using constraints when creating KVM  unit on maas machine <constraints> <kvm> <maas-provider> <juju-core:New> <https://launchpad.net/bugs/1399613>
<thumper> X-Rob: hmm... almost certainly a bug
<thumper> X-Rob: in that the requested constraints for the container aren't passed down to the host
<X-Rob> That says it's my issue, but, it's linked to a totally different bug
<thumper> um..
<thumper> I'm pretty sure that memory constraints were tested when I wrote it...
<X-Rob> thumper: Well, any debugging I can do?
<thumper> X-Rob: I agree that it should work
<sarnold> X-Rob: that bug looks like it describes your problem exactly, but the duplicate feels like a mistake to me
<X-Rob> Ahha
<X-Rob> OK
<lazyPower> sarnold: yeah that was supported before lxc:# :)
<sarnold> lazyPower: it was?? why does'nt anyone tell me these things :)
<lazyPower> sarnold: because we stink at writing changelogs?
<sarnold> looks like sinzui's not online, bugger, he might have had a good reason for duping them..
<sarnold> lazyPower: yeah, I might really enjoy using a kvm: option.. :)
<X-Rob> I can't seem to find where, if any, logs of this stuff would be
<lazyPower> sarnold: whoa whoa buddy - lets not get carried away here. LXC is the hotness
<lazyPower> X-Rob: I think those bits are in the machine-0 log, but i might be mistaken. They coudl be going to stdout/err and by proxy discarded.
<X-Rob> LXC -is- the hotness, except, it doesn't work well with pacemaker and floating IP addresses.
<X-Rob> lazyPower: nah, nothing in machine-0
<lazyPower> X-Rob: ah i was tongue in cheek'ing @ sarnold.
<thumper> X-Rob: is your environment running?
<X-Rob> thumper: eeyup
<sarnold> lazyPower: heh, I spin up a dozen kvms all the time, {i386,amd64}x{lucid,precise,trusty,utopic,vivid,wet}, etc...
<sarnold> lazyPower: containers are neat enough but not sufficient for those kinds of tests :)
<lazyPower> thumper: are we capturing the lxc container / kvm creation logs? Its sounding like we arent.
<lazyPower> in which case i'm more than happy to file a bug on it
<thumper> X-Rob, lazyPower: ok, this is going to give you a lot of info...
<thumper> you want to rack up the logging on a certain subset
<thumper> so
<X-Rob> Woo, I love logs.
<thumper> get the existing logging by running 'juju get-env logging-config'
<thumper> tell me what you have
<lazyPower> <root>=WARNING;unit=DEBUG
<X-Rob> ^^ same
<thumper> ok, do this:
<thumper> juju set-env 'logging-config=juju.container.kvm=TRACE'
<lazyPower> oh i love it
<lazyPower> thumper: <3 can we put that in the docs?
<thumper> this will capture all command line calls to the libvirt and their output
<thumper> lazyPower: yes
<lazyPower> WOO
<sarnold> yay docs! :)
<thumper> lazyPower: juju.container.lxc does the same for the lxc commands
<thumper> X-Rob: this will tell us whether the 8G mem constraint is being passed to libvirt or not
<thumper> if it is, it is a libvirt problem
<thumper> if it isn't, it is a juju problem
<X-Rob> thumper: OK, lemme go do this thing.
<X-Rob> https://www.irccloud.com/pastebin/z0Bi2JHZ
<X-Rob> now.. for the logs..
<X-Rob> ... um. OK, WHICH logs? on 9?
<X-Rob> yep, on 9
<X-Rob> 2015-01-06 02:03:27 TRACE juju.container.kvm libvirt.go:35 uvt-kvm [create --log-console-output --user-data /var/lib/juju/containers/juju-machine-9-kvm-7/cloud-init --bridge juju-br0 --memory 512 --cpu 1 --disk 8 juju-machine-9-kvm-7 release=trusty arch=amd64]
<X-Rob> thumper: juju's fault.
<thumper> X-Rob: add that to the bug please
<thumper> I'll try to get someone to look at it
 * thumper complains that it used to work
<thumper> actually
<thumper> not sure if I tested that particular use case
<thumper> I tested kvm machines created for the local provider using memory constraints
<thumper> probably never worked...
<thumper> oops
<thumper> my bad
<lazyPower> thumper: the bits to reset the logging to default?
<lazyPower> juju set-env 'logging-config=<root>=WARN;unit=DEBUG' ?
<thumper> juju set-env 'logging-config=<root>=WARN'
<lazyPower> stellar
<lazyPower> Thank you
<thumper> lazyPower: the unit=DEBUG is added unless you explicitly turn it down
<thumper> this means that we always see hook output
<lazyPower> right
<thumper> you can turn it off by doing this:
<thumper> juju set-env 'logging-config=<root>=WARN;unit=WARN'
<thumper> that way your logs won't contain the hook output
<thumper> lazyPower: levels are: TRACE, DEBUG, INFO, WARNING, ERROR
<thumper> highly recommended that you have at least WARNING
<thumper> and anything under WARNING is likely to be developer related debugging and logging
<thumper> so not necessarily intelligible
<thumper> the logging-config can be as long as you like
<X-Rob> I like logs.
<thumper> juju help logging
<X-Rob> but.. not much use with this
<thumper> LIKE A BOSS
<lazyPower> https://github.com/juju/docs/pull/216
<X-Rob> OMGDOCSWTF
<sarnold> lazyPower: <3
<lazyPower> X-Rob: i'm like Tron - I fight for the users.
<sarnold> lazyPower: .. where do those logs go?
<lazyPower> sarnold: in thumpers email, where they belong :P
<thumper> all-machines.log
<sarnold> lazyPower: lol
<thumper> which is looked at for 'juju debug-log'
<lazyPower> Updating
<X-Rob> https://i.imgur.com/ZPHgGeu.jpg
<X-Rob> That's my test environment, by the way
<sarnold> X-Rob: is that sixteen "blades" with two storage boxes?
<X-Rob> sarnold: yeah.
<lazyPower> sarnold: whats your github user id? you're not sarnold @_@
<sarnold> X-Rob: and is that a volleyball in the back? :)
<X-Rob> sarnold: that's actually my gym 8)
<sarnold> lazyPower: "setharnold", I laughed at github and didn't move on it quickly enough...
<X-Rob> https://i.imgur.com/gn1aoRw.jpg
<sarnold> "the whole point of git is that it is decentralized, who would want to put it all on a central server anyway?" ... heh
<X-Rob> my exuse is that I don't use it anyway, and it's got aircond, AND I happen to have 2 15amp 240v circuits in there
<sarnold> X-Rob: sweet, complete with minisplit aircon! :)
<X-Rob> (<-- au, we have 240v natively)
<sarnold> nice
<X-Rob> Ebay, $2k
<thumper> X-Rob: what are you testing for exactly?
<sarnold> X-Rob: wow, I thought the "au tax" would make that rig five times that...
<X-Rob> thumper: Well, the long term result is this stuff is going to be an openstack build for my minecraft server (I run mcau.org)
<X-Rob> sarnold: I did have to jump in my van and drive for 16 hours (each way) with 1 hour notice to my wife to go pick it up. The guy wanted it gone NOW
<sarnold> X-Rob: ooof :)
<X-Rob> thumper: the short term is me learning all about openstack, because fuck vmware. I'm a VCP, but I now (officially) hate them.
<sarnold> man australia is a big place.
<thumper> VCP?
<thumper> my kids are now all into minecraft :)
<X-Rob> https://www.google.com.au/maps/dir/Gladstone+QLD/Caringbah+South+NSW/@-28.8680946,146.9265686,6z/data=!3m1!4b1!4m13!4m12!1m5!1m1!1s0x6bc27489ada17a29:0x500eef17f210e60!2m2!1d151.2597998!2d-23.8487083!1m5!1m1!1s0x6b12c78d09dddc5b:0x5017d6816334960!2m2!1d151.1213599!2d-34.0551444
<X-Rob> thumper: vmware certified professional
<X-Rob> I did the course and stuff
<X-Rob> thumper: well, mcau will be MAAS+JUJU+OpenStack
<thumper> nifty
<lazyPower> sarnold: https://plus.google.com/100016143571682046224/posts/ZHG9ybVN3pR
<lazyPower> lots of activity on the post here - seems like one person was already +1 on this idea
<sarnold> X-Rob: long-ass drive, but for that kind of hardware at that price, probably makes sense...
<X-Rob> sarnold: yep, it was. It's kinda old, but, good enough for lots of small minecraft servers.
<lazyPower> thumper: did you see the minecraft post I made lastyear? Let me refresh you :D  https://plus.google.com/100016143571682046224/posts/PaVGh51FYCR
<sarnold> lazyPower: heh, I gave a +1 earlier.. is it mine? :)
<lazyPower> sarnold: actually no - an indie security researcher
<sarnold> X-Rob: I'm eyeing some older server gear for home use myself, I'm more interested in a pile of storage than a bunch of vms though..
<sarnold> aha
<X-Rob> sarnold: it's really easy to get a pile of storage these days. ceph + a couple of cheap-arse motherboards with 6 or 8 SATA sockets.
<sarnold> X-Rob: I've thought a bit about going that route but think I'd rather get something like a supermicro or norco with 15~20 drive bays and do zfs instead...
<sarnold> X-Rob: a pal keeps suggesting getting a drive shelf instead and hook it up with external sas, but I think I'd rather avoid expanders ..
<sarnold> .. of course, I also worry about the noise of going that route. a few desktops running ceph would probably be quieter.
<X-Rob> Ick, I';m with you there, external sas is nothing but heartache
<X-Rob> sarnold: my original ceph cluster was two milk crates with motheboard|cardboard|pizza spacers|cardboard|sata disks
<X-Rob> and I cabled tied the psus to the outside
<sarnold> hahaha
<X-Rob> PROFESSIONAL AWW YES
<lazyPower> seems legit
<lazyPower> the pizza expanders made it even more legit
<lazyPower> s/expanders/spacers/
<sarnold> yeah I lost it at the pizza spacers :)
<X-Rob> heheh
<X-Rob> They were needed, they gave the cardboard better structural integrity so it didn't collapse all over the motherboard
<sarnold> plus also, kept the pizz from getting the cardboard messy in the first place, amirite? :)
<X-Rob> heh. They weren't pizza boxes. That would have been the best idea, now I think about it
<catbus1> Hi, I have used juju to deploy some charms, my understanding is juju would cache charms, where can I find the cached charms?
<sarnold> catbus1: iirc, in ~/.juju/ there's a directory of cached charms..
<catbus1> sarnold: I do see them in ~/.juju/, there is environments/, environments.yaml and ssh/.
<catbus1> I don't see a list of charms I deployed in those 2 directories.
<sarnold> catbus1: look under environments/, it's probably in a subdirectory named after the environment
<catbus1> sarnold: there is just maas.jenv in environments/.
<lazyPower> catbus1: is this a local environment, or a cloud environment?
<lazyPower> catbus1: if its ac loud environment,t hose charms are then cached on the stateserver
<catbus1> lazyPower: a local environment.
<lazyPower> catbus1: then sarnold is correct, you should have a local charm cache in ~/.juju/local/
<lazyPower> thumper: has anymore thoughts/discussions happened wrt making the stateserver an honest container on the local provider?
<thumper> lazyPower: yeah... I'm considering doing Fun Fridays :-)
<thumper> lazyPower: got to get through MESS first
<thumper> or at least happy it is going in the righ tway
<thumper> lazyPower: I know what I want to do...
<lazyPower> oh agreed, i wasnt pressuring by any means, just curious if we're still headed down that path in the future.
<thumper> lazyPower: and it doesn't seem too hard
<thumper> oh yes
<thumper> I want it
<thumper> and I want it soon
<lazyPower> because to be honest, it sounds really compelling. And i'd love to see that be the case.
<thumper> so I can test MESS and HA using a local environment
<lazyPower> MESS?
<lazyPower> haha
<lazyPower> <3
<thumper> multi environment state server
<lazyPower> OH!
<thumper> mark hates it
<thumper> the name that is
<thumper> but I think it is cute
<thumper> I'm just making a mess
<lazyPower> i just laughed so hard i got light headed
<lazyPower> haha
<sarnold> hehe
<thumper> lazyPower: so, in something completely unrelated
 * lazyPower smells a work item coming out of this aside
<thumper> lazyPower: I want python-django to support django 1.7, virtual environments, and python 3
<lazyPower> called it
<thumper> I've hacked my local python-django so I can deploy my django 1.7 app
<thumper> and I wanted to use python 3
<thumper> but gave up
<thumper> so I'm using 2.7 and django 1.7
<lazyPower> that should be fairly simple. Python3 exists in the repositories
<lazyPower> you should be able to warden all of that with venv's
<thumper> yeah, but python-django doesn't use virtual envs
<bladernr`> lazyPower: catbus was incorrect, we're using juju via MAAS
<lazyPower> bladernr`: ok - that makes more sense why it wasn't showing up in ~/.juju/local
<bladernr`> not the local provider.  so you're saing the charms would be cached on the bootstrap node?
<lazyPower> bladernr`: the cached charms will be on your state server on the MAAS machine.
<lazyPower> correct
<lazyPower> thumper: are those charms getting stuffed in gridfs or are they on disk on the state server? this is where i get fuzzy
<thumper> um...
<thumper> deployed charms?
<lazyPower> and wait what? django doesn't support venvs?
<thumper> lazyPower: nope
<thumper> hang on
<lazyPower> as in the framework or the charm?
<thumper> django does
<thumper> the charm doesn
<thumper> tt
<lazyPower> ah ok, the charm could be modified i would think to be a simple task
<lazyPower> inspect for a .venv file/dir, if so - route throught hat. using something like virtualenvwrapper
<thumper> lazyPower: if you make it work, I'll test it
<lazyPower> thumper: if you file bugs, i'll put it on the list
<thumper> ha
<thumper> fair call
<lazyPower> forewarning though - i'm not a django dev - so i might make a bigger mess than MESS
<lazyPower> so i imagine i'll be pestering you for pairing
<bladernr`> lazyPower: thanks, /var/lib/juju/charmcache finally found it
<lazyPower> bladernr`: awesome! glad you got it sorted :)
<thumper> lazyPower: perhaps we can scratch each other's back...
<thumper> lazyPower: I may submit a patch or two to python-django
<lazyPower> thumper: go on...
<thumper> mostly to clean it up
<lazyPower> I'd like that, and i'm sure the maintainer would too
<thumper> it is a bit messy,
<lazyPower> yeah, last time i poked around in there i had @_@ these eyes
<lazyPower> its one of those inhereted charms from when the store was the wild west
<thumper> but if I just make multiple small patches
<lazyPower> we're cleaning quite a bit of it up though - did you see the email that hit the last pre-break about the 30 or some odd charms slated for moving to ~unmaintained?
<thumper> I'm a little frustrated that it doesn't support django 1.7 even though it has been released for 10 months
<thumper> lazyPower: I don't follow the list too closely for those things
<lazyPower> tsk tsk, but you could say the same to me for not diving through the -dev list for all your features that are landing.
<lazyPower> okay, belated new years resolution - i'll follow juju-hackers 10% more closely than i currently do.
<lazyPower> which will put my current level of monitoring at 10%
<X-Rob> heh
<X-Rob> Actually, lazyPower, 10% more of 0% is still 0%.
<thumper> lazyPower: and one for me, you'll get a patch for python-django in the next few weeks
<sarnold> 1.1 * 0.0 == 0.0 ... success!
<X-Rob> snap, sarnold
<sarnold> X-Rob: your message got to me first though, you beat me fair and square :)
<X-Rob> So the company I work for has been bought by another company and they want me to use exchange.
<lazyPower> sarnold X-Rob: touche - however 1.1 * 1 = 1.1
 * X-Rob grumbles.
<lazyPower> reading juju-hackers list is kind of like checking the fridge, looking around for something because you know you'r ehungry - closing the door and coming back 15 minutes later to repeat the process.
<lazyPower> you shuffle around the condiments a bit, figure there's nothing in there to munch on and order a pizza
<sarnold> X-Rob: suuuuuck
<lazyPower> completely missing the cheese cake in the back
<skay> lazyPower: just saw you were talking about the python-django charm... and missed hte conversation.
<skay> lazyPower: will the pure-python branch be merged soon? the ci tests and stuff got cleaned up
<skay> I have some patches I'd like submit once that goes
<marcoceppi> lazyPower: what's the deal with this? https://bugs.launchpad.net/charms/+bug/1373006
<mup> Bug #1373006: Hortonworks hdp 2.1 Storm+ZK bundle <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1373006>
<skay> any chance of getting pure-python python-django MR pushed soon? I would like to start putting together some MR and that has a lot of changes in it
<skay> I'll be in merge hell if I don't wait
<marcoceppi> skay: I'm not sure the state of the review, but you're welcome to do a review of it yourself if it's waiting for more eyes
<skay> marcoceppi: I am relatively new to juju and not sure my review would be very insightful
<marcoceppi> skay: well, we always welcome community reviewers. If you're looking to get mroe in to charming it's a great way to look at what other people are tyring to do. If you find something comment on it! If you don't that's fine too, it'll still go through the review of a charmer before making it's way to the store
<skay> it's been reviewed by some charmers already and has passed hte ci tests
<skay> the commiter made fixes based on the review cmments
<marcoceppi> sounds like it's just stuck waiting finial approval then
<marcoceppi> I'll see if I can take a look at it today, the queue is mighty big these days :\
<skay> is there a way for me to tell?
<skay> at this point, I would like to provide suggestions by submitting some small merge requests rather than holding up the MR
<marcoceppi> http://review.juju.solutions/
<marcoceppi> is where it is in the queue, it's pretty close to the top now
<skay> thanks
<marcoceppi> yeah, this is just waiting for a merge, I'll take a few mins to finalize and merge it today
<skay> \o/
<skay> btw, I'm getting an error when I try to login to the site
<marcoceppi> skay: what's the error?
<skay> marcoceppi: The server encountered an unexpected internal server error
<roadmr> odd... I was able to log in just fine
<skay> it hates me
 * skay sobs
<marcoceppi> myself as well, I wonder if this is because of some weird issue with code
<roadmr> skay: did you tell it your name? (the openid interstitial that lets you choose what to share)
<skay> I was curious if I could log in and trigger a new jenkins job
<marcoceppi> skay: ah, you can't, that's reserved only for charmers
<skay> roadmr: yep, after it fafiled I went and gave it all the permissions
<roadmr> I noticed nothing was ticked, so I ticked everything before going on
<roadmr> skay: ok, so that's not it
<marcoceppi> the internal server error is just the reviewq not having much good code around login since it was kind of a last min thought
<marcoceppi> skay: try again?
<marcoceppi> yeah, I see why it's failing
<marcoceppi> it's a known issue
<skay> okiedokie. not urgent
<marcoceppi> skay: once you get a review in the review queue log in will start working for you
<jose> hey tvansteenburgh, have a min for a PM?
<tvansteenburgh> jose: yup
<wesleymason> Anyone know if a lint with warnings will stop a charm getting promulgated into the store?
<marcoceppi> wesleymason: a warning, yes. though depends on the warning
<marcoceppi> which are you getting?
<jcastro> cory_fu, what's the closest thing you have to a homepage for DHX?
<cory_fu> jcastro: I guess the blog post: http://blog.juju.solutions/cloud/juju/2014/11/26/debug-hooks-ext-plugin.html
<cory_fu> Why do you ask?
<jcastro> I am giving a presentation to the SA guys in like 2 weeks
<jcastro> and I want to go over DHX
<cory_fu> Ah, cool
<jcastro> because it seems they would benefit a bunch from knowing about it
<skay> hey, someone is giving a juju talk at lcaconf. my spouse is on the video team for the conf
<skay> I wish I could be there. I want to go to lcaconf one day
<skay> this year's is in Auckland, which would be so cool to visit
<X-Rob> lca is pretty awesome
<wesleymason> marcoceppi: start/stop hooks missing, it's a subordinate with a binary called on demand, so there's no service to start/stop..I know I can just add blank hooks, but feels messy given they're unnecessary.
<marcoceppi> that hasnt been a warning in s long time wesleymason
<marcoceppi> wesleymason: do you have the latest charm-tools from ppa:juju/stable ?
<wesleymason> marcoceppi: nah, from universe
<marcoceppi> wesleymason: yeah, sadly that version of charm-tools is a whole rewrite behind
<marcoceppi> we'll have it updated in vivid and in releases going forward
 * wesleymason ignores the warnings then
<marcoceppi> until then ppa:juju/stable is the best place to get the most recent version
<wesleymason> marcoceppi: ta
<marcoceppi> wesleymason: you can also install it in a python virtualenv from pip if you're so inclined
<wesleymason> marcoceppi: avoiding using latest until juju is upgraded in prod by IS
<marcoceppi> wesleymason: ack, I can make a charm-tools only ppa if that helps
<wesleymason> marcoceppi: tbf I could just pin it, might just install in the virtualenv anyway as using one for tests
<marcoceppi> wesleymason: virtualenv works pretty well and is the least amount of effort betweent the two of us
<wesleymason> marcoceppi: ta muchly
<marcoceppi> np
<noise][> lazyPower: https://bugs.launchpad.net/charms/+source/haproxy/+bug/1407815 - I finally tracked down the cause of that relation-changed bug I mentioned yesterday
<mup> Bug #1407815: adding a 2nd website unit fails to call reverseproxy-relation-changed <haproxy (Juju Charms Collection):New> <https://launchpad.net/bugs/1407815>
<lazyPower> noise][: looking
<noise][> lazyPower: now I need to go look through the code to figure out __why__
<lazyPower> noise][: weird, byproduct of a debug setting?
<noise][> right??
<lazyPower> that smells
<noise][> nearly drove me insane
 * lazyPower identifys a code smell
<lazyPower> noise][: well i'm glad you've got more info to go on. I'm subbing to this bug to monitor your progress
<lazyPower> if you need any help feel free to reach out. I'm not an expert with the charm but i can lend a second pair of eyes
<noise][> i was just about to chuck my computer in the bin!
<noise][> lazyPower: cool, shouldn't be too hard to find the root cause now
#juju 2015-01-07
<designated> Can anyone tell me if configuration options are changed after deployment of an openstack charm, if that information will automatically get updated in the database?  As an example, will changing the VIP update the keystone endpoint list in the DB?
<marcoceppi> designated: it should
<marcoceppi> designated: however, there are a few configuration options that are immutable, I don't think that is one of them though
<mwak_> hey
<stub> Can I get a peer unit's public-address ?
<stub> Hmm... I guess I can set it myself on the peer relation
<marcoceppi_> stub: you'd have to set it on the wire
<marcoceppi_> as you allueded to
<mwak> marcoceppi_: ping.
<dpb1> rick_h_: happy new year!  the store is out of date with bzr for https://jujucharms.com/landscape-client/trusty/10 and https://jujucharms.com/landscape-client/precise -- there are two more revisions for each
<rick_h_> dpb1: otp will look
<mbruzek> dpb1 did I see you committed changes to the landscape charm to fix automated testing errors?
<dpb1> mbruzek: yes
<mbruzek> dpb1 it is a happy new year
<dpb1> hah
<dpb1> :)
<lazyPower> \o/
<skay> logistics question. I've never submited MR for a charm. and also haven't used bzr much. do people prefer getting small logical MR for something, or is that a pain due to the review process?
<skay> e.g. I want submit 2 changes in how pip is handled to the python django charm. 1. support extra args for pip. 2. stop using deprecated options
<skay> in some projects, it would be the custom to submit those separately, what is the preference here?
<lazyPower> skay: small chunks are fine for MR's
<lazyPower> you can make chained dependencies on Merge proposals
<lazyPower> the smaller the change, the more likely it is to be merged fairly quickly
<skay> thanks lazyPower, I like small changes. (I didn't know about the chained thing)
<skay> I forgot where in the docs it lists which config types are allowed. I would like to use a list, but I can't remember if that's allowed
<skay> right now I do a split on ' ' or ',' in some places, and a list would probably be more natural
<skay> oh derp. I found it. sorry for the trigger happy question
<dpb1> rick_h_: gentle ping reminder. :)
<rick_h_> dpb1: yes, just finished phone calls and starting to look.
<dpb1> ty
<rick_h_> dpb1: will be out first time using out fancy ingestion log so looking up how we can use it.
<dpb1> oooh, hopefully it's easier this time!
<rick_h_> dpb1: these were updated a while ago?
<dpb1> let me check the revno
<rick_h_> looks like back mid-dec
<dpb1> ya, sounds right
<rick_h_> trying to see how far back I can get logs for
<rick_h_> logging every 15min means that's a while back
<dpb1> :)
<rick_h_> did find this for you as an fyi https://pastebin.canonical.com/122931/
<dpb1> rick_h_: ok... will look at that as I work up the stack
<rick_h_> dpb1: well the good news is I found the logs from that timeframe
<rick_h_> dpb1: the bad news is that I don't see any reference to your charms in any warning/error logs so no closer to knowing wtf
<dpb1> :(
<rick_h_> dpb1: so creating a card and will get it assigned to chase it down but probably more time than a quick "oh, there's your problem"
<dpb1> rick_h_: ok, thanks for looking. it's not super urgent, as long as we get it fixed.
<rick_h_> promise that
<skay> \o/ yay, I submitted a small merge request for python-django.
<skay> does the ci job get kicked off automatically, or do I need to ask for it here?
<jcastro> anyone: I've got a PR to juju-solutions.github.io to add a containers page if someone wants to ack it pls.
<marcoceppi_> skay: it'll be kicked off by whoever is doing review
<lazyPower> marcoceppi_: mbruzek: https://bugs.launchpad.net/juju-core/+bug/1408467
<mup> Bug #1408467: juju help-tool does not reflect all options available to relation-set <audit> <docs> <help> <juju> <papercut> <juju-core:Confirmed> <https://launchpad.net/bugs/1408467>
<mbruzek> Oh I hate that bug!
<mbruzek> We should fix that one!
<marcoceppi_> bah, what a horrid bug!
<johnny_shieh> learning to write charms following tutorial found on web
<johnny_shieh> can create/launch the demo wordpress
<johnny_shieh> would like to log into container
<lazyPower> johnny_shieh: if you dont mind me asking, which tutorial are you following?
<johnny_shieh> but ssh <ipaddress> fails with permissions issue.
<lazyPower> johnny_shieh: try doing juju ssh service/#
<lazyPower> eg: juju ssh wordpress/0
<johnny_shieh> https://juju.ubuntu.com/docs/
<johnny_shieh> hmmm, let me try
<mbruzek> https://bugs.launchpad.net/juju-gui/+bug/1408472
<mup> Bug #1408472: The juju-run command on the unit does not have help  <docs> <help> <juju> <papercut> <juju-gui:New> <https://launchpad.net/bugs/1408472>
<lazyPower> Oo another one!
<lazyPower> we should fix that one too
<mbruzek> I know!  ... Right?!
<johnny_shieh> thanks lazyPower
<johnny_shieh> worked
 * lazyPower hat tips
<johnny_shieh> thx for help, be back in a few days with actual, real problems.  ha-ha
 * arosales heads over to the review can for some review time.
<arosales> s/can/queue
<arosales> marcoceppi_:  mbruzek: any ideas/opions on how we should handle the MPs for tests that are currently failing auto test?
<arosales> marcoceppi_: mbruzek: I presume these are due to the charm and not the test as the charm tests do not touch the charm code.
<arosales> it seems like it would be good to have these tests included in a charm that failing. Specifically, when someone comes along to fix it then can run the tests and have seed tests to build off from.
<mbruzek> arosales: tvansteenburgh had some strong opinions
<mbruzek> on this subject.
<mbruzek> arosales: I reluctantly agree with you and tvansteenburgh
<mbruzek> But that still feels "bad"
<arosales> mbruzek: is the concern that the charm is failing auto charm testing but the MP is still accepted?
<mbruzek> arosales: yes because that sets a bad precedent, other folks are going to ask them to merge their changes while the tests STILL fail
<arosales> mbruzek: I see that point. Whats interesting here is that for tests they don't touch charm code.
<arosales> and in the case for failing tests adding tests actaully may help debug the charm.
<mbruzek> arosales: agreed
<arosales> my opinion is that it helps get the charm into a better passing state
<arosales> so the decision is to nack or ack the MP
<arosales> on the one had if you nack, then the next person doesn't have seed tests or a charm tests to run against the charm to see what the failure was
<arosales> on the other hand if you ack, then at least the next person has a test to run and try to reproduce and a seed test to build off from.
 * arosales 2 cents
<mbruzek> arosales: we already get requests to merge MPs that fail charm proof, or other minor problems that "the change did not touch"
<arosales> are those tests or charm code?
<arosales> jose, dbp, marcoceppi_, mbruzek, lazyPower, niedbalski, tvansteenburgh, lazyPower: any opinons ^
<mbruzek> charm code, that someone is adding, they say since they didn't make the charm proof any worse they want their MP merged
<arosales> its a fair question and good point for not accepting the charm test.
<tvansteenburgh> if adding tests to to a charm that has none, i'd merge even if they fail
<tvansteenburgh> b/c at least now we know there's a problem
<arosales> my 2 cents is that the charm tests actaully help get the charm into a good state (passing tests) and thus should be accepted there. A charm code MP may not be able to state that, in general.
<mbruzek> arosales: to be clear I agree with you and tvansteenburgh, we should merge the failing tests
<arosales> mbruzek: I appreciate you are trying to weight both sides.
<arosales> My proposal is to get a few charms, at least 3, to agree so we can clear out the queue with these MPs.
<arosales> been in there far too long
<arosales> so two charmers +1 any others?
<mbruzek> we should resume this conversation when marcoceppi_ has a chance to comment.  I suspect he has strong feelings one way or the other.
 * mbruzek believe marcoceppi_ is eating now.
<mbruzek> the force is strong with that one
<tvansteenburgh> he agrees
 * arosales pinged other charmers too
<arosales> at least the ones I could recall.
 * arosales will wait patiently
<arosales> tvansteenburgh: mbruzek: in the mean time is there any thing I can to to help wth those MPs?
<arosales> leave a comment in them or does a charmer just need to take action on them once the decsion is made?
<mbruzek> pull requests to fix why the test is failing
<mbruzek> In the end that is what we are after
<tvansteenburgh> :)
<arosales> lol mbruzek
<arosales> nice one
<mbruzek> You can pull request against me or marco's branch to fix the test
<mbruzek> or pull request against the charm.
<arosales> understood :-)
<arosales> marcoceppi_: when you return, for lp 1387465 can you let me now what action is needed to get this item out of the queue?
<arosales> marcoceppi_: same thing for 1387467
 * arosales taking a +1 look @ 1396237
<lazyPower> wat
<lamont> lazyPower: brain dump to follow...
<lazyPower> mbruzek: ^
<lamont> what we have: maas node with 2ea openvpn-server charms and 1 openvpn-p2p charm forced onto one node (along with a few subordinates).  the other side of the p2p link is outside of maas/juju, as is the entire pki infra.  ergo, the openvpn-server and p2p charms have a bunch of config vars to delvier ca.crt and host key/cert and such
<lamont> which makes reading/deploying the charms problematic for someone using just juju (no PKI wat?)
<lamont> enter the openvpn-pki charm, which optionally relates to the other 2, and provides a PKI infra (most notably, today it delivers the ssh pubkey and IP address that will be doing the syncing)
<lamont> currently coded as "when this relation comes up, dump some config vars into a file on the unit, and silently override the juju config variables with the actual answers from the openvpn-pki unit)
<lazyPower> lamont: i can understand the situation you're trying to solve - however relationship data should not overwrite config data coming from teh user - that alone would get a nack on a charm review. My thoughts would be if you have a third party PKI utility - it should either proxy the information in from your existing infra, or allow those bits to be set by the user, that way the onus of where the config is coming from is not on the openvpn server
<lazyPower> itself but on the PKI charm you're relating to the unit. In which case - depending on if its coming from a proxy or being set by the user is dependent on how the charm is deployed
<lamont> which is vomitworthy
<lazyPower> and you could then send that information via the relationship to openvpn and not worry about this
<lazyPower> this way both scenarios are modeled in the juju language, and both are actionable
<mbruzek> So lamont what happens to the ca.cert if the user sets a ca.cert on the openvpn charm and then the openvpn-pki charm comes by with a different ca.cert?
<lazyPower> you can then say "if user config data" is present, that will override any relationship data - so it follows the juju tenants, and if that data is not present, it sends the data from the proxy
<lamont> I was just thinking...  how horrible would it be to have the charm behave correctly, and then have a subordinate charm that eliminates the need for a relationship to openvpn-pki?
<lazyPower> a subordinate woudl be a fine approach too - you dont necessarily need to tie up a unit for data-pass
<lazyPower> actually - a sub would be the preferred route forward
<lamont> mbruzek: as it sits, openvpn-pki wins:  code says "conf = config(); if-file-exists { read yaml and overwrite into conf}'
<mbruzek> lamont that would break the user experience.
<lamont> mbruzek: hence the "how much would you guys scream" that brought me here...
<lazyPower> lamont: <3
<mbruzek> lamont: if a user sets something with config-set or from the gui we should do EVERYTHING possible to preserve that
<lamont> if I understand this, the correct solution is: openvpn-pki <-> openvpn-{server,p2p} quietly delivers the info over the relation (and server/p2p spill it to a file which is used in config), and an "openvpn-external-pki" subordinate provides all of the variables for juju set to let a non-juju pki be used instead of the charm.
<mbruzek> Making the user know/care about the order of charms deployed is ALWAYS a "bad idea"
<lamont> and server/p2p do not have settable variables for the pki meta
<lamont> mbruzek: If it helps, I was feeling dirty.
<lazyPower> lamont: that soudns correct to me in the ascii diagram above - the subordinate allows for you to either proxy the info in or configure it, correct?
<mbruzek> lamont: clean your self up this is a family show.
<lamont> it felt _wrong_, which led me to seek help
<lamont> so that summary sounds right?
<mbruzek> lamont: Yes I like you ascii diagram solution
<lamont> ascii ftw
<lamont> all of which means I have my work cut out for me.
<mbruzek> lamont: dont' forget to write the README.md too.
<lamont> and stupid question: subordinate charms... will I need a relationship there, too?
<mbruzek> The openvpn-p2p readme was VERY sparse
<lazyPower> well, *good* charms can be difficult to write as complexity grows. but a bundle/bundle(s) will make this simple for users to get setup and moving with, and we'll give you much fanfare when it lands
<lamont> mbruzek: there is this significant feedback item about how terse (or, conversely, verbose) my explanations are.  working onit.
<lazyPower> lamont: expect some blogging / an instructional video when it lands tho - we'll give ya the red carpet for your efforts.
<mbruzek> lamont: subordinate charms relate on the juju-info relationship to a container charm (non subordinate)
 * lamont still gets grief from a former coworker from many years ago for a program of several hundred lines, with the singular comment "do stuff" in it.
<mbruzek> lamont: so you get the subordinate relationship for "free"
<sarnold> lamont: at least it wasn't misleading or incorrect, right? :)
<lamont> mbruzek: for the charm writer of poor literacy.... does that mean that config() in the container charm returns the set variables from the subordinate?
<mbruzek> lamont: something that lazyPower and I talked about just *today* was that subordinates can have peers too, so one subordinate can be related to different container charms and the subordinates can use the peer relation
<lamont> sarnold: fact
<lamont> actually, hrm.
<lazyPower> sarnold: *rimshots*
<lazyPower> o/
<skay> hehe do stuff
<lamont> sarnold: it's from the "self documenting code" era
<skay> I like "read my mind and do what I want"
<lazyPower> lamont: re: your question to mbruzek - no, config() will continue to only return the config data from that charm. Data being sent over the wire is in relation-get
<lamont> sarnold: that code used a 400MB (yes, MB) disk to transfer files between a un*x box and a non-un*x box.  beacuse of reasons
<lamont> lazyPower: and the relation is "just there" by right of the subordination?
<lazyPower> lamont: now we're talking about interfaces and properly consuming/documenting interfaces+data in the readme/contributing documents. But when you get to that point, feel free to tap me in and i'll help.
<lazyPower> you define it by every variable you send OTW via relation-set
<sarnold> lamont: at least it wasn't "literate programming".. I'll take self-documenting code any day :)
<lazyPower> this is why its super important to document it, otherwise users have to read teh code to know what its doing, and we as charmers will hate you forever. we already have a truckload of interfaces to document
<mbruzek> lamont: re: config - No the subordinate configuration are not in the container charm's config
<lamont> lazyPower: I'm guessing that I still need Provides/Requires?
<lazyPower> lamont: thats depreciated, its the wild west with interfaces - no forced gets/sets
 * lamont drops the side conversation with sarnold. :p
<lazyPower> its even been removed from the documentation
<lazyPower> you just arbitrarily set them, and consume them
<lazyPower> skay: sounds about right :D
<lamont> ok.  this'll be fun. :D
<lamont> config-changed only triggers on juju set, correct?
<lazyPower> config-changed triggers when the charm config changed
<lazyPower> so 'yes' to juju-set triggering it
<lazyPower> but it also runs after install and upgrade-charm
<mbruzek> lamont:  don't forget the gui
<lamont> mbruzek: right.  was thinking api-speak.
<lazyPower> relation-name-changed triggers when relation-set is called on any of teh charms in the relationship chain "do stuff" that sets a variable.
<lamont> sometimes, I hate computers
<lamont> lazyPower: and (duh) relation-setting doesn't trigger config-changed
<lamont> is it true that both hooks will never run concurrently? (only one hook to a unit, at a time, yes?)
<lazyPower> correct
<lamont> what I really want is a juju status item that says "and no hooks are queued or running at this time"
<lamont> (though there could be one queued/starting right after the status, don't care)
<lazyPower> lamont: we all want that. its a work item in the near cycle(s) to get better information from status about whats going on in the unit
<lamont> \o/
<lamont> with that, time to go rewrite some charms.
<lazyPower> lamont: all the best o/ cheers
<lamont> example of a subordinate charm that does things by the new /current method?
<lazyPower> lamont: one doesn't exist as we dont have many/any ['proxy','configurable'] subordinates that I'm aware of. But again, tap me in and I can help when you get to writing the hooks
<lazyPower> and/or planning of said charm
<lamont> ah, well... that'd be "about now", since it basically consists of ripping out a bunch of config vars from openvpn-serfver and creating said charm.
<lamont> here, or /pm?
<lazyPower> Lets do it here so others can benefit from our riffing
<lamont> ok.
<lamont> categories:
<lamont>   - misc
<lamont> subordinate: true
<lamont> :D
<lazyPower> you'll need to add a requires relation that is scope: container
<lazyPower> https://juju.ubuntu.com/docs/authors-subordinate-services.html
<lamont> requires:
<lamont>   openvpn-pki-recipient:
<lamont>     interface: openvpn-pki-sync
<lamont>     scope: container
<lamont> cool
<lazyPower> ok, so you've now got an openvpn-pki-recipient ['joined','changed','broken','departed'] relationship on both sides
<lazyPower> the subordinate unit itself shoudl relation-set the relevant parts, if its coming from proxy or from user config (possibly both are user config, depends on how you build it)
<lazyPower> and the openvpn-pki-recipient service itself will need to consume whats being sent via relation-set
<marcoceppi_> mbruzek: why is lp 1408472 targeted at juju-gui?
<lazyPower> seem straight forward enough?
<lazyPower> (so far anyway)
<lamont> lazyPower: yep
<lamont> ta
<arosales> lazyPower: any opinions on the earlier conversation on approving MPs that only add tests even though the charm is failing those tests?
<lamont> in config-changed (yes), how do I find the relations(s) to do the relation-set calls? (python, with charmhelpers)
<mbruzek> marcoceppi_: because I made a mistake
<lamont> lazyPower: (in a clean/current way - I'm learning that nagios-external-master is not a charm to crib from)
<mbruzek> no
<marcoceppi_> arosales: I just linked a new branch and initiated tests against the new branch so that we can know if it passes or not for 1387465.  1387467 needs another test run executed. I just queued it up
<mbruzek> lamont: we have several flagbearer charms
<marcoceppi_> mbruzek: <3
<lazyPower> mbruzek: fyi - rails is not one of them, i've gone back through and started re-working that one, so anyone asking about chef - send them to me direct until I can get the charm reworked and the docs updated to reflect the new pattern i'm working on.
<marcoceppi_> arosales: I'm a plus one, but we have another issue steming from that. Whos responsible to fix that? Should we hault all further changes to that branch until someone fixes it? or just keep merging things that address issues even though the tests continually fail
<arosales> marcoceppi_: once those tests are done for 1387465 and 1387467 will those fall out ofthe queue. Seems odd they are still in the queue even though the bug is marked as "Fix Released"
<mbruzek> lamont: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-flag-bearer-charms
<lamont> ta
<marcoceppi_> arosales: that is weird.
<mbruzek> personally I recommend the lamp charm for the tests, but I don't remember if the _charm_ code is any good
<marcoceppi_> arosales: one sec
<arosales> marcoceppi_: in regards to charm tests. Per policy https://jujucharms.com/docs/charm-unmaintained-process
 * mbruzek knows the tests are "awesome" because he wrote them.
<mbruzek> That is all from me tonight, I have guests coming over and need to go for the evening.
<lazyPower> oh nice - rails didnt make the list. <3
<arosales> if the charm continues to fail tests (ie deploy is broken) then it becomes a candidate to move into un-maintained if no action is take on it to fix it
 * mbruzek waves
<lazyPower> i'll get that fixored eventually
<lazyPower> arosales: how long is that period after we start accepting contributions? anotehr 15 day grace period?
<marcoceppi_> arosales: fixed
<arosales> marcoceppi_: thanks I don't see them in the queue anymore
<arosales> lazyPower: sorry I didn't properly parse your question
 * marcoceppi_ decides to do a bunch of fixes to the review queue tonight
<arosales> lazyPower: in regards to unmaintained charms; if a bug is logged against a charm and no action is taken to fix it 1 month after the bug is failed the charm will then be moved into the unmaintained branch.
<lazyPower> arosales: right - but you were saying if the tests continually fail
<lazyPower> at this point, we know there is an issue with the charm when we start accepting these contributions cognisent of them having failing tests
<arosales> lazyPower: ah
<lazyPower> it doesn't seem right to just merge that in and reset the countdown timer on unmaintained.  Maybe i'm being a stickler though
<arosales> the way I read policy is that if active work is going on in the charm then the charm is not a candidate for unmaintained
<arosales> the issue is when there is a bug against a charm and no work is being done to address it
<lazyPower> 10-4
<lazyPower> so if i'm reading htis properly - we file a bug about the failing test
<lazyPower> if nobody comes around to fix that, but they keep adding MP's we just ignore the failing test for the time being until someone gets around to fixing it
<arosales> currently auto testing will only run against a charm when there is a MP agaist it which would signal an effort to bring the charm into good standing.
<lazyPower> ok, i mean seems fair enough as we dont really know what the community at large will do with this information against their charms, we only have a handfull right now failing tests right? ~ 30 or so?
<lazyPower> or am i looking at the wrong data sheet
<arosales> ya, I think it was around 30
<marcoceppi> I hope to add failing charms in to the review queue soon
<marcoceppi> as a section
<lazyPower> marcoceppi: <3 you and the rev queue magic, all the new queues and what not
<marcoceppi> yeah...as soon as they show up...one day
<lazyPower> marcoceppi: i have an idea that we kind of riffed out tonight about the store + recommended that I want to send to teh charmers team for pre-feedback in the near future
<marcoceppi> lazyPower: okay, there is the monthly thingy
<lazyPower> it will address a few different areas that we're experiencing pain in one move
<lazyPower> we are still doing that?
<lazyPower> i thought we didnt want to do that
<arosales> lazyPower: so to mbruzek's earlier point if an MP comes in and touches charm code but the charm tests are failing a charmer would need to decide if that MP should be accepted
<arosales> lazyPower: so I don't think we should ignore the failing tests
<lazyPower> arosales: i'll put on my "take me seriously hat" and put googley eyes on the review about the tests.
<arosales> but what we shouldn't do is move the charm into unmainted as there is "active" work on it.
<lazyPower> yeah, i'm +1 for that... We already have a high bar for getting into recommended status
<lazyPower> if we just start nuking charms because we have a stickler for tests, we will be alienating people working
<arosales> ya moving to unmaintained is really a last resort when a charm is broken and there is zero work to bring the charm back  to a working state.
 * lazyPower recalls there being a yoda image at one point that summed it up nicely
<arosales> the thought being that the recommeded charm store should always have charms that are in a working state or at least a state of being fixed
<lazyPower> well i'm a fan of ~recommended being the de-facto best of the best
<lazyPower> namespaces are around for the rest, for in-dev, community love, and development focus
<arosales> so lazyPower marcoceppi: my original question to the charmers team is do you guys agree the oustanding MPs in the queue to add tests should be accepted even though the charm is failing tests?
<lazyPower> but this is starting to touch on what i want to riff with marcoceppi and other ~charmers about - kind of our curation process and bits - but it is goign to take a lot fo fleshing out as i'm sur ei've got gaps in what i'm thinking.
<arosales> my comment was that the tests actually help get the charm fixed as it provides a reproducibile failing environment, and add seed tests to the next person wanting to improve the charm. Plus the tests don't touch charm code.
<marcoceppi> arosales: I agree, but with reservations
<lazyPower> arosales: yeah, if there's work going on towards a charm - and it doesnt effect the tests - file a bug against the charm about tests and move on
<lazyPower> keep making it happen
<lazyPower> marco will have a test failure queue soon(ish) that we can address when we have more info about longevity of a charms failure rates
<arosales> lazyPower: in this case we don't know if there is work on the charm outside of the tests
<arosales> we only know that marcoceppi and mbruzek added seed tests to charms
<lazyPower> welp, getting the tests in there is the first step right?
<arosales> some of those charms fail the tests
<arosales> so we got a load of those in the charm queue
<lazyPower> seems wrong to stop progress at step 1 if we have a course of action to completion
<arosales> and we just need to make a decision to nack or ack those
<marcoceppi> I was going to say it's the author of the tests job to fix the charm
<marcoceppi> then I realized how much more work that was for me
<marcoceppi> and decided to not say that
<marcoceppi> except right then
<arosales> lazyPower: agreed
<marcoceppi> when I said it
<lazyPower> arosales: because that basically says "We gave basic deploy tests, and its failing - so due dilligence is needed. No maintainers in 30 days step up? time to hit the eject button"
<lazyPower> this will do a couple things
<lazyPower> ditch some old charms people dont want to undertake updating, and give us metrics to empower the decision
<lazyPower> and i'm all for making data driven decisions
<arosales> lazyPower: ya I agree it helps get the charm into a fixed state by first identiying there is a problem
<lazyPower> arosales: so, can we make that the workflow? file a bug after the MP lands with the failing est
<arosales> thus my proposal is for the charmers to accept charm tests even if the charm is failing those tests
<lazyPower> and that kicks off the countdown timer
<lazyPower> arosales: i'll be happy to go through and verify everything that i run across during review time if you leave a breadcrumb trail that its been filed and identified as a failure
<lazyPower> and we can pass off a notice to other charmers that this is what we are donig
<lazyPower> *doing
<arosales> lazyPower: so all the charms @ http://review.juju.solutions/
<lazyPower> arosales: woo all of them are failing? hooo boy
 * lazyPower puts on his firemans hat
<arosales> from mbruzek and marcoceppi with "add-tests" or "tests" branch are what need approval
<lazyPower> 10-4
<lazyPower> if you pre-triage i'll follow behind you before i EOD or first thing tomorrow
<lazyPower> i still owe for review this week - i managed to miss my slot on Tuesday
<arosales> also tvansteenburgh and mbruzek +1ed accepting these tests
<arosales> jsut wanted at least charmers to +1
<lazyPower> yeah, still need votes from jose, dpb1, and niedbalski if they are around and want to chime in
<lazyPower> but i'm all for it
<arosales> so if lazyPower and marcoceppi +1 then it sounds like it ok for your to accept these tests for the above reasons
<lazyPower> you sold me, good salesmanship
 * arosales already pinged them ealier
<lazyPower> ah, then we'll silently discard those votes if they are negative ;)
<arosales> no replies yet
<lazyPower> <3 if they read scrollback
<arosales> well you have the majority of charmers +1ing it
<arosales> but I would be interested to hear an objection if there is one
<lazyPower> yeah i'm just being obtuse. its late in the day.
 * lazyPower goes back to hacking on subordinate logic
<arosales> lazyPower: I am happy to traige those test MP,  what specific action do you need from me a +1 on the syntax of the charm tests?
<lazyPower> I would say that, and i'll go through and add bugs to the charms when the MP's land for failing tests
<lazyPower> that way its part of my wrap-up email to the list
<lazyPower> which can serve as day 1 of notice
<lazyPower> 30 days to fix failing tests, unless other active dev is going on - if active dev is going on - they get an extension to fix the tests basically. but it puts us 1 step closer to trimming the warts on the store.
<arosales> sounds good
<arosales> I am going to finish up my review of OpenID/SSO  and then work on the testing MPs
<arosales> lazyPower: thanks!
 * lazyPower hat tips
#juju 2015-01-08
<thumper> marcoceppi, lazyPower: the latest merge into python-django charm, is that fully backwardly compatible?
<thumper> as in, as a user of the charm, there should be no change>?
<lazyPower> thumper: link?
<thumper> lazyPower: didn't marcoceppi update it?
<thumper> lazyPower: in an email to the juju list today
<lazyPower> looking
<thumper> https://code.launchpad.net/~charmers/charms/trusty/python-django/trunk
<thumper> last commit 19 hours ago
<lazyPower> thumper: no serious change to config - you should be fine. I would recommend you simulate a deploy in a staging env before you do this on anything you have in production
<lazyPower> it changed some of the defaults, but theory states you already have these values set on your charms in the wild. so again, looks g2g at first glance
 * thumper twitches
 * thumper grabs the code and proposes a fix
<lazyPower> if you're relying on unit-config - it will block you from upgrading.
<lazyPower> as that config option was removed, so i stand corrected
<thumper> lazyPower: how do I run the tests on this thing?
<lazyPower> thumper: make a virtualenv, pip install bundletester into that virtualenv and just run bundletester from the charm root.
<lazyPower> ti will execute against your currently active juju env
<lazyPower> marcoceppi: added an inline diff comment on that python-django merge that thumper is talking about - this merge violates policy
<marcoceppi> lazyPower: it doesn't anymore, juju handles this now as well as removing relations
<lazyPower> marcoceppi: our policy docs clearly state that its violated
<lazyPower> included for easy ref.
<lazyPower> it has to be maintained until the next series release
<lazyPower> so if this was going to vivid, sure
<lazyPower> but not according to policy today
<lazyPower> s/vivid/vivid or utopic/
<lazyPower> or even trusty
<lazyPower> unless im' mis-reading policy
<lazyPower> which is possible
<thumper> lazyPower: my first charm patch https://code.launchpad.net/~thumper/charms/precise/python-django/tweaks/+merge/245807
<lazyPower> thumper: no tests to validate? :(
<thumper> lazyPower: no behaviour has changed
<thumper> so all tests should be the same, no?
<thumper> I've not added any functionality, just pulled four copies of code into one place
<lazyPower> ah i see what you did here
<lazyPower> tvansteenburgh: oh man, we got lazr authentication pulled in pip proper now? no more crazyness with --alow-unverified and --allow-unsigned? Very nice!
<lazyPower> thumper: something is hozed in my env, waiting on automated tests
<thumper> lazyPower: no rush
<lazyPower> noodles785: hey this is cool, the /etc/ansible/host_vars/localhost  - i had no idea we were storing all this data - makes it kind of handy to access via current_relation['var']. well played sir.
<jose> lazyPower, arosales: I do object to the auto-merging of thos
<jose> lazyPower, arosales: after working with Matt with some of them, not all of them are acceptable as-is. Some charms will not be satisfied with an autogen, since they force you to set an specific key, or maybe need an specific setup that's specified in the readme and not the metadata
<jose> lazyPower, arosales: so, yes, I would test *all* of them and if tests pass then merge it, as I've been doing lately
<lazyPower> jose: seems like something as simple as setting a key could be updated in the test during the merge
<lazyPower> are there other scenarios?
<arosales> jose defaults for a charm ~should~ work correct?
<jose> lazyPower: needing to *create* the key somewhere else, and as I said, specific deployment
<jose> arosales: not always
<lazyPower> jose: thats policy. sane defaults. the charm should deploy without any user intervention, and if it requires user intervention - it must be clearly outlined in teh readme. which means we can set it.
<jose> e.g. the newrelic charm, I had to create an account and add my key to the tests in order for them to pass, otherwise I would get a clear failure
<lazyPower> unless its something like pagekite where it requires an account - and thats iffy at best putting test credentials in a charm.
<lazyPower> smells of abuse
<jose> pagekite is not in the store yet :)
<arosales> its a valid point but I think we should take that as the exception and not the rule to the pending MPs
<lazyPower> jose: indeed - but it was an example case.
<arosales> jose: do you see any of the charms currently in the queue?
<jose> if you get them all in and then start to find failures, warned you
<jose> arosales: I did, yes. newrelic-php and another couple I saw before the  holiday break
<arosales> jose: also one action lazyPower was going to take is to file a bug against the charm that is failing
<arosales> jose: if you could add a comment to those MPs that would be greatly appreciated
<arosales> I am curently going through them too.
<jose> yep, I've been working on newrelic-php and trying to check how can I fix it since it's a bit weird
<arosales> ie https://code.launchpad.net/~marcoceppi/charms/precise/seafile/tests/+merge/240964
<jose> I was going to propose a fix
<jose> seafile... I believe there is an incoming MP to fix the non-deployment?
<arosales> even for the point you outlined I think it is good to accept these tests
<jose> sure
<arosales> it brings up points and possible bugs that would not have been noticed had the autogen charm test not been there
<arosales> so I am commenting on the MPs.
<arosales> I'll leave it up to the charmers team to make the final decision.
<arosales> thus far 4 +1 to accept and your -1 to nack
<jose> if they're going to be tested at the end, I'd say run the test and if there's an error *because of the test* then nack
<jose> take it as a 0, not as a -1
<jose> half/half in with the proposal
<arosales> we lose the unit logs with auto charm testing
<arosales> for the ones I can tell if the test is failing though we should note that
<arosales> very good point jose
<jose> arosales: btw, that seafile error, if the queue follows its natural flow the fix should land before the test
<arosales> ah very nice
<arosales> I am going to get some dinner, but I'll return later tonight and keep commeting on these outstanding test MPs
<jose> cool :)
<arosales> and looking for the ones that have charm tests that may need updating
<jose> also, when I run bundletester over here and something fails, everything is kept as is
<arosales> jose: thanks for your reply on the matter
<jose> sure.
<jose> enjoy your dinner
<lazyPower> arosales: i'm getting close to being at a point i can transition to helping with the queue, in a furious debug session with racing config between two hosts
<arosales> jose: thanks
<lazyPower> but this is looking awesome and should give lamont a good basis to look at for sep. of concerns on a host vs its subordinate
<jose> lazyPower: I've gone back to the queue after a 'discussion' with my ISP and my connection being off
<lazyPower> jose: are you getting throttled already?
<jose> lazyPower: I was. couldn
<jose> couldn't stay online for more than 5mins or it'd kick meoff
<lazyPower> thats the pitts, i know it bothers me when comcast gets nosey in my bidniss and throttles me during the day because i'm pushing volumes of data related to builds
<lazyPower> After 3 months of back and forth i gave up and they won, i get throttled from 10am => 5pm
<lazyPower> jose: however - if you get to those MP's before me - just make sure you file bugs against the ones with failing tests you ack - so we have a point of reference when the problem surfaced, and how long we have to make it correct. The mail to the list of status will serve as the first step in its trajectory
<jose> not getting this... are you asking me to merge all of them?
<lazyPower> jose: there's a 20 minute scrollback worth of conversation about it. if the test fails, and its not an edge case merge that requires crednetials - yes.
<lazyPower> *credentials
<lazyPower> and filing of a bug against the charm that it has failing tests, tagged audit.
<jose> I'll leave that to you.
<jose> marcoceppi: ping
<lazyPower> hey thumper, you still kickin around?
<thumper> yeah, in a call now
<lazyPower> thumper: when you get a moment - i'm attempting to send relationship data out of a relationship context - i have a dependent service that needs to update config based on values being passed from a different context, and i have no way of triggering that manually that i'm aware of , but i have this bit of shell in my head that i should be able to do this...
<lazyPower> https://gist.github.com/chuckbutler/443777748984e3673925
<lazyPower> using relation-set -r docker:8 foo=bar - i thought i could push data out of band and trigger the relationship-changed hook on that relation id, no?
<thumper> lazyPower: sorry, not sure
<lazyPower> ill sync up with marcoceppi tomorrow - thanks for taking a look thumper
<thumper> kk
<thumper> nigth
<X-Rob> Is there any way to reset the positioning of all the icons in juju-gui? It's totally mental, and getting lots of NaNs
<lazyPower> X-Rob: Yeah, i ran into that myself
<lazyPower> let me find the snippet for you
<lazyPower> X-Rob: are you familiar with the browser console and how to get to it?
<X-Rob> lazyPower: extremely
<lazyPower> X-Rob: this will reset every last charm you have in your gui (up to 100 services) to teh same X/Y
<lazyPower> https://gist.github.com/chuckbutler/edf2efe5a426b62b1e1b
<lazyPower> shoudl get rid of those nasty NaN errors as well - this happens during a botched upgrade of juju-gui releases as i understand it. Its really rare though - so if this doesn't persist - reach out to hatch and he can get you locked down. there was some additional steps I had to take in teh end to fully resolve it
<lazyPower> but that might fix you up with no additional work required
<X-Rob> I actually gave up, lazyPower. 'juju destroy-environment' and I'll just start again
<tvansteenburgh> wwitzel3: know how to fix this? http://pastebin.ubuntu.com/9693080/
<tvansteenburgh> (or anyone else)
<wwitzel3> tvansteenburgh: looking
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charm-helpers/kilo-enable/+merge/245870
<wwitzel3> tvansteenburgh: can you pastebin the output of: go env
<tvansteenburgh> wwitzel3: http://pastebin.ubuntu.com/9693183/
<wwitzel3> tvansteenburgh: going in to my standup, I would try deleting that pkg folder and attempting re go get
<tvansteenburgh> wwitzel3: k, thanks
<tvansteenburgh> marcoceppi: i have a test that i kicked off from RevQ that finished, but RevQ status didn't get updated: http://juju-ci.vapour.ws:8080/job/charm-bundle-test/10878/console
<tvansteenburgh> marcoceppi: it's http://review.juju.solutions/review/1893 in the RevQ
<marcoceppi> tvansteenburgh: all test results are giving a 404
<marcoceppi> Did the URL change?
<tvansteenburgh> marcoceppi: example?
<marcoceppi> actually, it's not getting the URL back at all
<marcoceppi> tvansteenburgh: did the jenkins test change?
<tvansteenburgh> curl http://review.juju.solutions/review/1893/ctb_callback/344 --data-urlencode status=PASS --data-urlencode result_url=http://reports.vapour.ws/charm-tests/charm-bundle-test-10878-results
<marcoceppi> tvansteenburgh: this is in the database: http://paste.ubuntu.com/9693288/ it's got the callback, but hte url wasn't recorded
<marcoceppi> yeah, it's still looking for that. Let me add some debug information in
<tvansteenburgh> well that is weird? there were many yesterday that *did* work
<marcoceppi> omg
<marcoceppi> weird
<marcoceppi> tvansteenburgh: this is why
<marcoceppi> tvansteenburgh: http://reports.vapour.ws/charm-tests/charm-bundle-test-10878-results/json
<marcoceppi> that result url doesn't work
<jose> hey marcoceppi, have you seen an error where Amulet tries to relate yet-to-be-deployed services?
<marcoceppi> jose: that should never happen unless the d.add for the service is executed after the initial d.setup
<marcoceppi> jose: could you be more explicit, like witha test file and the output of the test run?
<jose> marcoceppi: sure, I have the test file but not the output (that was yesterday night), I'll run again
<jose> sec for link
<jose> https://code.launchpad.net/~mbruzek/charms/precise/oops-tools/tests/+merge/240997 to be specific
<mbruzek> what did I do?
<jose> mbruzek: autogen tests are throwing an unexpected amulet error, sorry for the highlight :)
<mbruzek> jose:  that is fine, probably due to bad test author
<mbruzek> (me)
<jose> well, this time Amulet is to blame :P
<jose> but *only for this time*
<mbruzek> Have you *met* Marco?  He is never wrong!
<jose> I have
<jose> I believe that was... 2012
<mbruzek> jose marcoceppi the reason that test is failing is because I misspelled postgresql
<mbruzek> jose postresql
<jose> mbruzek: oooh, good catch!
<jose> why did the autogen misspell?
<mbruzek> Autogen didn't do that, that was a *human* error
<mbruzek> fixing now
 * marcoceppi is always right, yet again! ;)
<jose> :P
<wwitzel3> tvansteenburgh: did that resolve your issue?
<tvansteenburgh> wwitzel3: which dir were you suggesting i delete?
<wwitzel3> tvansteenburgh: GOPATH/pkg/linux_amd64 folder
<wwitzel3> tvansteenburgh: just delete the whole thing and retry
<skay> when I try to run tests for a charm I get an import error due to yaml; however, yaml is installed
<skay> is hte python path getting munged by bundletester in some way? I haven't used it before now
<tvansteenburgh> skay please paste errer
<tvansteenburgh> error
<tvansteenburgh> wwitzel3: what is your GOROOT?
<wwitzel3> tvansteenburgh: mine is /home/wwitzel3/opt/go .. I built go from source
<skay> tvansteenburgh: http://paste.ubuntu.com/9693519/
<skay> tvansteenburgh: I imported it from a shell for a sanity check http://paste.ubuntu.com/9693523/
<tvansteenburgh> skay: are the tests using py3 perhaps?
<skay> facepalm
<skay> tvansteenburgh: yes, thanks for the tip :)
<skay> forgot to check
<tvansteenburgh> np :)
<skay> tvansteenburgh: what's the common practice -- do people usually have a readme that explains how to run the tests for the charm that is being worked on, and have a testing requirements.txt file for people to use?
<skay> that's something I have when I'm creating things, but I'm making a small change for the first time to a charm, and I've never gonet hrough the process before
<marcoceppi> skay: usually a Makefile
<marcoceppi> with a test target
<tvansteenburgh> make test is most common for unit teste
<tvansteenburgh> tests
<marcoceppi> oh, is that not this?
<skay> oh I see. there's a makefile with the test target commented out
<tvansteenburgh> no, i'm just slow
<skay> I wasn't sure what to do, so I gave up and decided to see what commands jenkins would call so I could mimic it
<skay> I saw that it was running a bundletester command and tried to use that
<tvansteenburgh> yeah that is what you should do
<skay> so, for this charm, the test target is commented out. there is an integration-test target, and there's nothing that creates a virtualenv to install the testing dependencies and such
<skay> is it common practice for people to set all that up using some other method?
<skay> or should I plan to edit the Makefile to do what I think is probably good practice?
<tvansteenburgh> the latter
<tvansteenburgh> bundletester will call `make test`
<tvansteenburgh> and execute anything in tests/
<tvansteenburgh> so just make sure that your test target has a prereq that sets up deps
<skay> tvansteenburgh: is there an exemplar project with a makefile and such that follow best practices?
<tvansteenburgh> there are several, let me find one...
<skay> I'd like not to make newbie mistakes, though I know it is inevitable
<skay> I am thinking about a guide: So you want to contribute to an existing charm! here's what you do
<skay> and then later: So you want to make a charm that is easy for new contributors to hack on! here's what you do
<tvansteenburgh> skay: trusty/haproxy
<tvansteenburgh> look at test, .venv, and lint targets
<tvansteenburgh> that's standard setup
<tvansteenburgh> then put amulet tests in tests/
<skay> tvansteenburgh: thanks! checking my assumptions -- bundletester will kick off by creating a container or vm and then run make test for me?
<skay> I want to make sure I'm not clobbering my system
<tvansteenburgh> bundletester does not create a container yet, although it is planned
<tvansteenburgh> hence the .venv target
<skay> tvansteenburgh: okay, so I wouldn't want to do .venv that way for my system, since I install virtualenv from pip and not the apt package.
<skay> but I would guess standard practice must be to use system dependencies where they exist?
<skay> thus I should probably make a container when I do this
<skay> tvansteenburgh: thanks for the help. I am grateful for it!
<skay> I am also very happy that people have done a lot of work in the review queue
<tvansteenburgh> sure thing, any time :)
<tvansteenburgh> wwitzel3: http://pastebin.ubuntu.com/9693596/
<tvansteenburgh> wwitzel3: should i need sudo for that?
<wwitzel3> tvansteenburgh: umm shouldn't since it is in your home, you might if you attempted to sudo go get anything.
<wwitzel3> tvansteenburgh: /home/tvansteenburgh/src/go/pkg/linux_amd64/ that is the folder you want to delete
<tvansteenburgh> i did, see paste
<tvansteenburgh> the place it's installing is not in my home
<tvansteenburgh> it's under /usr/lib/go
<tvansteenburgh> i tried unsetting GOROOT but it still used that path
<ianrossi> jamespage, Ian Rossi here, long time no see. I was wondering if you could help direct me to the right person at Canonical that  can delete an ubuntu pastebin
<noise][> can anyone recommend a dirt-simple charm that exposes a website relation? like just a hello-world pageâ¦ so far i'm just finding things like wordpress that are too complex for my simple bug repro'ing use
<jose> hey cory_fu, have a min?
<cory_fu> Sure
<jose> cory_fu: I see you opened an MP against a branch I already merged, mind opening it against the parent branch?
<jose> https://code.launchpad.net/~johnsca/charms/precise/couchbase/fix-install/+merge/243575
<cory_fu> jose: I did mention that MP on the original MP.  I had hoped that mbruzek would have a chance to merge my fix into his branch, or that the person merging the original MP upstream would include mine to fix the tests.
<jose> cory_fu: that's why I'm asking if I you can open an MP over there, so I can take a look in a while
<cory_fu> jose: That said, sure I can resubmit against the parent.  :)
<cory_fu> Sure
<jose> \o/
<jose> thank you!
<cory_fu> jose: https://code.launchpad.net/~johnsca/charms/precise/couchbase/fix-install/+merge/245892
<cory_fu> Thanks for taking a look at those
<jose> yep, got the email
<jose> will look after I'm done with a couple more tests
<cory_fu> I wish we had a better or more defined procedure for submitting fixes against other people's MPs
<cory_fu> jose: I'm open to ideas for the future.  :)
<cory_fu> The review process could certainly use some stream-lining
<jose> yeah, my fault over there - saw you reported the bug but didn't see the other branch
<cory_fu> Meh.  MPs against MPs seem prone to getting missed like that.  I don't think it's a great method, but it was all I could come up with at the time.
<jose> if I do an MP against an MP I tend to contact the owner of the branch to see if I can get it merged before it's reviewed
<Mmike> Hi guys. When I'm doing amulet tests, how can I print to stdout? Plain print() produces no output.
<noise][> take 2: can anyone recommend a dirt-simple charm that exposes a website relation? like just a hello-world page
<cory_fu> jose: Yeah, I think I did mention it to mbruzek at the time, but he's a busy guy and he added tests to a lot of charms.  :)
<jose> noise][: the pubphoto charm does a good job over there
<jose> Mmike: are you running that test individually? if so, a print('Hello!') should write Hello! on the console
<cory_fu> Mmike: Well, I would expect that to depend on your test runner, but if you're using print to debug, I would recommend trying out pdb (or ipdb, if you want to be fancy), since it gives you an interactive session that is more flexible than just prints
<Mmike> pudb is actually the neatest I found :) it's ncurses based
<cory_fu> Interesting.  I'll have to check that out.  :)
<Mmike> but, during the test I want to print stuff on stdout like 'creating habooka', 'testing against habooka', and stuff like that
<noise][> jose: thx
<Mmike> jose, I do: juju test 02_my_habooka_test.py
<Mmike> and print('mario is super!') prints me nothing
<jose> Mmike: try running ./02_my_habooka_test.py
<Mmike> jose, when I do so then jujuj-deployer complains about not being able to find condiguration in /tmp/amulet-blahblah...
<lazyPower> Mmike:  if you're using the juju test runner, i believe it traps output unless you pass teh verbose flag
<Mmike> lazyPower, tried that , no dice.
<Mmike> dunno what's the issue, I see that amulet has raise_status method which uses print too, but using it also produces no output
<lazyPower> Mmike: somethings trapping your stdout - if you run the test directly you say juju-deployer raises errors?
<Mmike> yup, I'm assuming 'juju test' creates deployer config or something...
<lazyPower> its coming from amulet, amulet wraps juju-deployer
<lazyPower> what version of amulet are you running?
<Mmike> 1.9.0
<Mmike> with juju  1.21-beta4
<lazyPower> tvansteenburgh: any thoughts on Mmike's issue above? amulet shouldn't be crying wolf about deployer on latest packaging
<nicopace> \quit
<Mmike> I created a simple test script which just does print('wonka!')
<Mmike> and when I juju test it, nothing is printed
<lazyPower> Mmike: tvan is the current maintainer of our testing tools - give him a bit to come aroudn and he should be able to get you lined out.
<lazyPower> but you're right, the fact you're getting no output and directly running the tests with exceptions bubbling up about juju-deployer smells of a local configuration problem
<Mmike> ack, no rush
<Mmike> maybe it's because i'm using juju 1.21, But I can't have my lxcs in /var/lib/lxc, and with juju 1.20 I can't use local envs when I tell lxcs NOT to be placed in /var/lib/lxc
<noise][> lazyPower: not sure if you saw it but I added easy repro steps for that HAProxy relation bug, still makes no sense though
<lazyPower> noise][: i actually haven't been tracking it as closely as i should be - a bit scattered since i got back from break. I can give it a look later today when i context switch to the queue
<noise][> lazyPower: cool, no rush since it's easy to avoid, but damn if it isn't a weird one
<lazyPower> yeah, enabling debug changes behavior of the charm - i dont like that at all
<tvansteenburgh> Mmike: try using bundletester instead; pip install bundletester; then run it in your charm dir
<Mmike> tvansteenburgh, is bundletester replacement for amulet?
<tvansteenburgh> no, for juju test
<tvansteenburgh> amulet is a testing library, bundletester is a test runner
<Mmike> oh, I see
<Mmike> neat
<rick_h_> thumper: oh buddy oh pal
<thumper> o/ rick_h_
<rick_h_> thumper: frankban asked me to poke you about his branch and some 'naming of things' questions he had when you showed up
<rick_h_> so /me pokes you about all that
<thumper> kk
<jose> marcoceppi: ping
<marcoceppi> o/ jose
<jose> marcoceppi: hey, I was checking on one of your MPs but turns out it has conflicts
<marcoceppi> oh, which?
<jose> https://code.launchpad.net/~marcoceppi/charms/precise/thinkup/tests/+merge/240894
<jose> ^
<marcoceppi> jose: I'll rectify
<jose> thank you :)
<jose> please let me know once it's done so I can re-verify the merge
<jcastro> lazyPower, https://github.com/juju-solutions/juju-solutions.github.io/pull/20
<lazyPower> jcastro: missing the directive in _config.yml
<lazyPower> jcastro: commented
<jcastro> lazyPower, done, I fixed it just forgot to push, thanks
<lazyPower> jcastro: just make sure you frontload your page with a permalink to get the proper page location
<lazyPower> jcastro: eg: permalink: /containers.html
<jcastro> ack
<jcastro> lazyPower, is layout: post fine too?
<lazyPower> You'll inherit stuff from teh blog post layout. I can build another layout tonight if you need one.
<lazyPower> but to get you moving - yeah thats fine
<jcastro> nah, I think we're fine for now
<jcastro> the idea is for this content to be moved to the real site anyway
<jcastro> so we don't need to spend a ton of time making it pretty
<lazyPower> Fair enough
#juju 2015-01-09
<mwak> Anyone is familiar with hadoop charm?
<mwak> Trying to run it on arm but get some errors
<mwak> http://pastebin.com/i20qtEgf
<mwak> http://pastebin.com/JxMHzbdH
<jcastro> mwak, you're looking for lazyPower ^^^
<bloodearnest> rick_h_, hey, are you guys still gonna be in london week after next?
<rick_h_> bloodearnest: yes
<rick_h_> 19-23
<jamespage> rick_h_, I'm assuming that you guys are aware that the machine view appears to get a little confused by suboridnate charms
<jamespage> keeps generating them for placement
<rick_h_> jamespage: /me checks bugs
<jcastro> lazyPower, also can you see if the Pittsburgh Code and Supply talk can be recorded?
<bloodearnest> rick_h_, so, the number of reasons for me to visit bluefin are increasing, you wanna schedule a slot to talk?
<rick_h_> bloodearnest: yes, I would like to. Know what day works for you?
<bloodearnest> rick_h_, weds?
<rick_h_> bloodearnest: wfm
<rick_h_> jamespage: closest I can find is https://bugs.launchpad.net/juju-gui/+bug/1369576 marked fix released months ago
<mup> Bug #1369576: juju-gui MV shows subordinate services as unplaced units <juju-gui:Fix Released by hatch> <https://launchpad.net/bugs/1369576>
<rick_h_> jamespage: so a bug report/screenshot/etc would be great
<jamespage> rick_h_, will do
<jamespage> rick_h_, thats exactly what i see
<rick_h_> jamespage: ah ok, so regression perhaps or old juju-gui version?
<jamespage> rick_h_, freshly deployed in the last hour
<rick_h_> jamespage: ok, regression then
<jamespage> so I would suspect regression
<rick_h_> had to check :)
<rick_h_> jamespage: I'll just reopen that bug and we'll take a look then if that's exactly what you're seeing
<skay> I had a lot of python-django questions, so instead of asking here I posted to the list
<jose> arosales: ping, mind a PM?
<lazyPower> jcastro: jxreese says he'll try to make that happen.
<arosales> jose sure :-)
 * arosales doesn't mind at all
<lazyPower> mwak: which charm is this? is this the 'hadoop' charm or 'hdp-hadoop'?
<mwak> hadoop
<mwak> https://manage.jujucharms.com/charms/trusty/hadoop
<lazyPower> mwak: ok, i'm not nearly as familiar witht he hadoop charm. Looking at this - can you verify the hadoop service is up and running? if you execute `jps` you should see a few processes.
<mwak> ubuntu@onlinelabs-15ae7c187615497fa4d5dc9f62332bae:~$ jps
<mwak> 12936 Jps
<mwak> 23665 NameNode
<mwak> 19137 ResourceManager
<lazyPower> hmm, it appears the services are running... interesting
<mwak> yep
<lazyPower> yet you're getting a connection timeout
<lazyPower> single host deploy or multi-host?
<mwak> got this :9000 failed on connection exception: java.net.ConnectException: Connection refused;
<mwak> details
<mwak> 15:47 < mwak> http://pastebin.com/i20qtEgf
<mwak> 15:47 < mwak> http://pastebin.com/JxMHzbdH
<mwak> multi-host deployment
<lazyPower> ah i missed the first paste
<mwak> np
<lazyPower> can you pastebin me your site.xml?
<lazyPower> should be in /etc/hadoop/conf
<mwak> sure
<mwak> hum
<mwak> i ve no site.xml
<mwak> in /etc/hoadoop/conf
<lazyPower> thats for sure the location in hdp-hadoop - it might be different in the apache hadoop charm
<mwak> http://pastebin.com/x4ghffEE
<mwak> have the following in this dir
<lazyPower> hmm... can you pastebin the core-site.xml as a start?
<mwak> sure
<mwak> http://pastebin.com/LRB4pBYd
<lazyPower> mwak: does a hdfs dfsadmin -report listing work?
<mwak> negative
<mwak> http://pastebin.com/CkGtpYpu
<mwak> connection refused
<lazyPower> mwak: i'm grepping through notes i've got over here - i'm not sure why its missing site.xml and why nothing appears to be started when jps is reporting the services are active. I'm composing an email to our resident big data expert who's out on vacation this week to see if i cant get a quick troubleshooting list to run through
<lazyPower> mwak: no ETA on the response but i'll take point as POC until we get you resolved.
<mwak> lazyPower: alright
<mwak> note that it is running on arm 32bit servers
<lazyPower> mwak: would you happen to be from our friends over at onlinelabs
<mwak> hum, not sure to understand
<jose> arosales: sorry, my ISP cut my connection and it's back on, shooting now
<lazyPower> mwak: no worries - just curious.
<lazyPower> mwak: can you reach out in private with your email so i can cc you on this?
<mwak> oh sure
<mwak> PM
<lazyPower> confirmed - thanks mwak. i'll get you on a comms about this with the big data team
<mwak> alright, if they want an access to a similar environment, ping I will give them an access
<mwak> could be more confortable
<lazyPower> mwak: additionally - we haven't been testin in an arm32 lab ourselves - so we might be pioneering with the charm(s)
<mwak> :)
<lazyPower> mwak: are any of these pastbin links set to self destruct?
<lazyPower> i'm referencing them in my comms - jsut making sure i dont need to copy them out to a non-self-destructing pastebin before i move forward
<mwak> lazyPower: no
<lazyPower> perfect. sending now
<lazyPower> mwak: alternatively - if you want to join in the development discussion / participate in the future of the charms - we have a bigdata-developer mailing list over here: https://launchpad.net/~bigdata-dev  that you can register for with your launchpad account. I'll reach out if/when i hear back from Amir - our lead developer on the charms. He's our resident big data guru, and is scheduled to be back by Tuesday of next week - but he might get back to
<lazyPower>  us via email before then.
<johnny_shieh> Hi, is there online documentation and a URL site (which I guess the documentation would point me to) to a sandbox ubuntu system where I can test out my charm?
<lazyPower> johnny_shieh: certainly - we have a vagrant box at your disposal
<lazyPower> https://jujucharms.com/docs/config-vagrant
<lazyPower> johnny_shieh: and https://jujucharms.com/docs/howto-vagrant-workflow
<johnny_shieh> cool, thanks!
<lazyPower> aisrael: wait didn't we change the workflow to no longer require sshuttle?
<aisrael> lazyPower: Hm. I guess not.
<lazyPower> aisrael: well, i meant the process not the doc :D
<lazyPower> i'll file a bug against teh docs for this so we dont forget we need to update that page
<aisrael> lazyPower: Yeah, we've totally got a better process for it now. I kind of wonder if it can be baked into the vagrant image itself.
<lazyPower> aisrael: https://github.com/juju/docs/issues/218
<lazyPower> nice
<aisrael> lazyPower: excellent, thanks! Dropped the link to the blog post in there.
<lazyPower> johnny_shieh: when you get to reaching inside the vagrant image - might want to take a look at the bug post above as it has some workflow items that will save you a headache with sshuttle
<johnny_shieh> okay, thanks.
<johnny_shieh> hey, if I'm still on Mavericks, I'm okay with the shuttle issue right?
<johnny_shieh> I mean, I can use shuttle
<aisrael> johnny_shieh: Yep, you can.
<johnny_shieh> thx
<aisrael> johnny_shieh: You may notice some network slowness over sshuttle, fwiw.
<johnny_shieh> okay
<lazyPower> yeah, the encryption overhead and funky packet latency
<aisrael> It essentially tears down every packet and reassembles it on the other side of the ssh connection.
<mbruzek> Hello beisner, lazyPower asked me to send you this MP link. https://code.launchpad.net/~mbruzek/charms/precise/rabbitmq-server/add-tests/+merge/246025
<mbruzek> Please review the amulet tests for rabbitmq-server and let me know if you have any feedback.
<mbruzek> Thanks.
#juju 2015-01-10
<beisner> thanks mbruzek appreciate it!
<beisner> hi lazyPower, mbruzek - commented on https://code.launchpad.net/~mbruzek/charms/precise/rabbitmq-server/add-tests/+merge/246025     one minor add should do the trick.   holler with any questions.  thanks a ton!
#juju 2015-01-11
<TheFezzer> Hey there, does anyone know about using a Juju to deploy commercial software?
<TheFezzer> Like, the potential legal ramifications?
<TheFezzer> I work for a medium-sized n-tier application publisher and I'm interested in making charms with our products, but sometime soon I'm going to have to face the Dreaded Legal Review.
<X-Rob> Hmmm. It would be REALLY NICE if you could make uvt-simplestream use a damn cache.
<X-Rob> I don't know what it's like for you lot, but downloading images isn't anywhere near instant
<X-Rob> and maas gives me a handy cache.
<X-Rob> Oh, it -is- using the ache. But it's ignoring the 'dont' use a https source'
<rick_h_> TheFezzer: charms you write are yours as far as license and such. So there's no reason you couldn't charm up your software and use it as a local charm
<rick_h_> TheFezzer: if you want to chat on it more hit up maarten (maarten.ectors@canonical.com)
<lazyPower> snap rick_h_ beat me to it
<rick_h_> X-Rob: yea, that came up. We're supposed to look into providing charms over plain http (on our todo list).
<rick_h_> I thoguht I saw some commit recently related..../me checks email log
<X-Rob> rick_h_: That's not that bad. I dont' mind https'
<X-Rob> for the charms
<lazyPower> rick_h_: well.... doesnt that expose us to MITM?
<rick_h_> lazyPower: right, which is why we've been hesitent
<X-Rob> but for large chunks of data, having https is amazingly annoying
<rick_h_> but so many chaching tools don't cache https ootb
<X-Rob> rick_h_: you can't cache https
<X-Rob> it's not like http, where you ask the proxy server to get a page, with https you say 'Connect to this IP address, give me all the data
<rick_h_> right, you have to really proxy/cache
<rick_h_> right, mitm yourlse
<rick_h_> self
<TheFezzer> Hey Rick, thanks for the response. The charm would not contain the software, just wget it as part of the start hook.
<X-Rob> Mmmmm. OK,
<X-Rob> https://github.com/juju/juju/blob/master/container/kvm/libvirt.go#L43
<X-Rob> So that says that there's an OPTION for a source
<rick_h_> X-Rob: damn if I can't find it sorry.
<X-Rob> rick_h_: I do this, and this caches most stuff:
<X-Rob> https://www.irccloud.com/pastebin/CYUOadac
<rick_h_> X-Rob: but yes, know issue and something that annoys us as well with things like the orange boxes when squid fails cache as much as we'd like
<rick_h_> X-Rob: very cool
<X-Rob> But.. I can't seem to trace this damn source back
<rick_h_> TheFezzer: lazyPower can hook you up if you want more detailed info or get you in the right direction
<rick_h_> he's more on that side than myself tbh
<X-Rob> rick_h_: So, here's a question. Why doesn't juju machine0 run a cache for this sort of stuff?
<TheFezzer> ok, I just saw his Digital Ocean walkthrough, great work.
<rick_h_> X-Rob: it's in the works, at least much of it is. The core folks have been working on a storage implementation to store stuff in the state servers, we'll be looking at doing some stuff in the charmstore itself to help, not sure on the streams. I don't tend to mess with them much
<rick_h_> X-Rob: you could email the list and get tips/tricks and maybe better details on the status, but it's come up the last couple of sprints and I know we want to get to an offline story which will help with the cached story.
<lazyPower> oo guess i should move irc ot my primary workspace
<rick_h_> lol
<rick_h_> lazyPower: get to work on your Sat night...I mean Sunday night
<rick_h_> :P
<lazyPower> dockering up my apps like a boss
<lazyPower> testing this new stack i put together
<lazyPower> <3 me some green field charms
<rick_h_> heh
<lazyPower> TheFezzer: we have some stuff cooking for ISV's that want to charm up their apps. i was working with MariaDB before the break to get their ENTERPRISE edition charmed up as an upgrade path in their community edition charm
<lazyPower> TheFezzer: so if you want to move forward with building charms for your apps - we can most def. get you kicked off in the right direction - host a charm school for your team to get you moving, and do reviews as you work towards getting your charm in the charm store
<TheFezzer> I am a Developer Advocate with a mid-size (but top tier IMHO) ISV and I'm charming up our lineup
<TheFezzer> I've made charms for our 5 most popular apps, but they're not good yet
<TheFezzer> i.e., not idempotent and the relationships don't relate yet
<TheFezzer> we're in SF
<lazyPower> TheFezzer: sounds awesome :) if/when you want someone to review them just reach out - https://jujucharms.com/docs/authors-charm-store#submitting  is a good first-tier checklist and walkthrough
<TheFezzer> ok, so if I submit them to the charm store, I'm not releasing any rights or anything like that?
<lazyPower> not at all - the charm code itself has to be an OSI approved license for inclusion - but the software it installs can be as proprietary as you need it to be
<lazyPower> here's the policy doc on that: https://jujucharms.com/docs/authors-charm-policy
<lazyPower> for example, MariaDB enterprise is very much proprietary - we included an extra license file and gave an upgrade path that depends on a config option of EULA acceptance
<TheFezzer> the software is free to try so the charm will make a full featured server that's good for 90 days, and the charm itself is just simple bash scripting. If it needs configs, it will download them during install
<lazyPower> without that option the upgrade-path no-op's until thats set to true.
<lazyPower> so it can be as simple as including a .txt and adding a boolean config option
<TheFezzer> ok, so I could do something like that for authentic Oracle JDK?
<lazyPower> You are correct sir
<lazyPower> we have a really stellar example in the IBM Websphere charm, let me fish that up for you
<TheFezzer> I'm Charming JIRA, which is really picky about its jdk/jre
<lazyPower> https://code.launchpad.net/~ibm-demo/charms/trusty/websphere-liberty/trunk
<TheFezzer> using the WebUpD8 repo, but it seems like just throwing the flag in the start script is cheating... and Oracle has claws.
<lazyPower> There are 2 licenses in there to accept, and the installation path in config-changed will give you a baseline of the logic you might need.
<lazyPower> right, it has to be linked to the config option otherwise its very much claw worthy
<TheFezzer> ok
<lazyPower> and again - if you get a prototype done and would like a ~charmer review - we're here to help
<TheFezzer> I have a prototype, but 'done' is not quite here yet
<TheFezzer> I really need to understand the order of ops for the scripts.
<lazyPower> TheFezzer: Thats the second time i've heard this - I'll add a card to get a flow-chart diagram for the order of hooks made and included ni the docs
<TheFezzer> like when it comes online, it seems like START and CONFIG-CHANGED run... but when you make a relationship, does it run RELATIONSHIP-JOINED and RELATIONSHIP-CHANGED?
<lazyPower> Relationship-joined runs with pretext of nothing has come over the wire, this is for you to install things like database adapters, or ancilliary software relating to the relationship (or do backups if you're changing app config to support the relationship)
 * rick_h_ decides he should be in bed since it's now tomorrow, have a good night all
<lazyPower> changed will run anytime a relation-set is sent on either side of the relationship, and can be run many times throughout the service/relation lifecycle
<lazyPower> g'nigth rick_h_
<lazyPower> see ya on monday
<lazyPower> TheFezzer: and broken runs when the relationship is first `juju remove relation'd` - and has the pretext of doing things like backing up settings and preparing for reconfiguration of the application
<TheFezzer> oh wait, wat? so if I fire three relation-set in a row, I get three relation-changed?
<lazyPower> sure could
<TheFezzer> oh wat
<lazyPower> and it goes up on the order of N depending on how many units are in the service stack
<lazyPower> say you have 3 mongodb units, and you relate them to rails
<lazyPower> you'll get db-relation-changed hook firing 3 times, one for each unit
<TheFezzer> no idea what that means
<TheFezzer> oh, ok
<TheFezzer> so on the mysql side it fires 9x, 3x for three relation-set and 3x for three nodes
<TheFezzer> s/mysql/mongodb
<lazyPower> it only fires 3x - each unit runs a relation-set during its relation-changed event.
<TheFezzer> but each rails sees only 3x for three relation-set?
<lazyPower> but if your application receives data and sends data back - mongodb will run its own relation-chagned event again
<TheFezzer> ok, but if each one ran three? i did not see a way to set multiple.
<TheFezzer> ok, so you could have a veritable conversation in the hooks. I like this.
<lazyPower> would be easier to explain with a diagram so you can show which side is emitting the information.
<lazyPower> but yeah - they can talk, and re-run hooks
<lazyPower> the power of an event driven system :)
<lazyPower> think of each charm as a state machine with no final step until it reaches teh stop hook.
<lazyPower> you're constantly moving between states, and depending on context - will determine which state to enter/exit
<TheFezzer> totally off topic, but I'm using the web client for IRC and it's terrible. I'm on mac. What should I be using for IRC?
<lazyPower> no idea, i'm on ubuntu and i use quassel - but its crash happy on mac
<lazyPower> http://www.codeux.com/textual/
<lazyPower> this looks to be helpful as it expands images inline and what not
<TheFezzer> ok, so if a relation is set, then changed is only run if joined hasa relation-set event?
<lazyPower> it will run by default once on each end
<TheFezzer> all right, I'm going to try it out. back in a sec.
<lazyPower> TheFezzer: are you aware of juju debug-hooks?
<lazyPower> you can trap event runs in a tmux session and run them interactively - this will help immensly with grokking whats going on during relationships
<TheFezzer> Did I make it?
<lazyPower> looks like it
<TheFezzer> sweet
<lazyPower> <lazyPower> TheFezzer: are you aware of juju debug-hooks?
<lazyPower> <lazyPower> you can trap event runs in a tmux session and run them interactively - this will help immensly with grokking whats going on during relationships
<TheFezzer> I tried debug-hooks, but I didnât grok. I would keep hitting relation-set on one side expecting something to happen (or at least be visible in relation-get)
<lazyPower> it wont trigger the data showing up on the other end until that hook is exited on the unit relation-settin'g the data
<TheFezzer> oh!
<lazyPower> this is when the changed hook will cycle a second time
<lazyPower> so you exit on both sides
<lazyPower> the other side receiving the info fires changed again, and your data is now present
<TheFezzer> soâ¦ if one side sets multiple values in one run, then it only sets them at the end of the run, triggering the other side to run changed?
<lazyPower> you'll see several charms that exit 0 when no data is present, as there are no actions to take without the data
<lazyPower> correct
<TheFezzer> nice.
<TheFezzer> I think I get it.
<TheFezzer> so if I set one in debug-hooks, I wouldnât expect to see it until the hook exits /and then a new hook runs on the opposite side/.
<lazyPower> you got it
 * lazyPower raises the roof
<TheFezzer> ok, and so then Iâm guessing itâs convention to not set in  the joined hook?
<lazyPower> you can
<TheFezzer> yâall need a checklist of what each hook is to do
<TheFezzer> ;)
<lazyPower> but it wont be available in -joined on the other side
<lazyPower> it will be available in -changed
<lazyPower> (but i may be wrong, i havent actually set data in a joined hook)
<lazyPower> the context of -joined is pretext work, they units aren't actually communicating yet
<TheFezzer> it just sounds like not a thing to do. soâ¦ the settings are durable, right?
<lazyPower> TheFezzer: but good point, could you file a bug report on that against teh docs? i'd love to get the feedback so we can improve the docs
<lazyPower> https://github.com/juju/docs/issues
<TheFezzer> I would not mind writing something up
<TheFezzer> I could put in a PR or some text in the feature request
<lazyPower> if you feel up to doing a PR that would be most excellent :)
<lazyPower> get some review time on your concept comprehension to boot
<TheFezzer> yes
<lazyPower> i like where your head is at TheFezzer :) glad i stuck around tonight
<TheFezzer> :D
<TheFezzer> Iâm a newly minted Dev Advocate and itâs time for me to get out there and actually do the work of advocating.
<TheFezzer> gah, the Github interface seems so backwards to me. Where the heck is that clone link? ;)
<lazyPower> fork it
<lazyPower> best way to do it, then the clone link is on the right hand side
<lazyPower> tehre's a guide to contributing in the readme
<TheFezzer> ok, cool
<lazyPower> allright, 1am seems like a good time for me to head out an dhead to bed
<lazyPower> best of luck to ya Fezzer
<TheFezzer> good night, thank you for your help.
<X-Rob> .. .So, I had an idea re uvt-simplestream. Why don't I manually run it on the machine with a http://  url before I do anything? That'll sync it, AND pull it from the local proxy. If it needs to update, it'll update via the proxy.
<X-Rob> This is what I'm doing now.
<X-Rob> https://www.irccloud.com/pastebin/mJOZEgpA
<X-Rob> Yep. That seems to work
<X-Rob> Except.. I downloaded daily instead of release. Sigh.
<TheFezzer> Soâ¦ it seems like whenever one of my apps connects to another app, its proxied through the central server. is there a way to avoid this?
<X-Rob> TheFezzer: 'connects' and which central server?
<X-Rob> connects how? curl? socket?
<TheFezzer> hmm, not sure
<TheFezzer> I should look at the code
<X-Rob> TheFezzer: so what's making you think it's going via a central server?
<TheFezzer> well, the host has an IP whitelist, and I set it for 10.0.3.26. But then I send .26 off to register, and I get the âNo connection allowed from 10.0.3.1 403â
<TheFezzer> soâ¦ (shrug)
<X-Rob> is it a web connection? http?
<TheFezzer> ehrmâ¦ should be http
<TheFezzer> from a tomcat to a tomcat
<X-Rob> by any chance did you deploy via MaaS?
<TheFezzer> itâs Vagrant on OSX/Yosemite
<X-Rob> Hmm
<X-Rob> Well anyway, I'm guessing it's your http_proxy environment variables.
<TheFezzer> in which env, Vagrant or the host?
<X-Rob> that 10.0.3.1 host
<X-Rob> is that juju's machine0?
<TheFezzer> I presume. brb.
<TheFezzer> um, juju status lists 0 as âlocalhostâ
<X-Rob> so what host is that IP address?
<TheFezzer> that is the vagrant host machine, which would be the âlocalhostâ from juju status
<X-Rob> ahha, ok, so yeah that's machine0.
<TheFezzer> ok
<X-Rob> I'm guessing that vagrant installs a proxy
<X-Rob> most commonly this is propogated through http_proxy environment variables
<X-Rob> if you want to ssh to one of your clients
<TheFezzer> Iâm sshâd to a couple
<X-Rob> you can 'cat' the /proc/pid/environ file
<TheFezzer> hacking out charm scripts, as it were
<X-Rob> that'll show you all the environment variables for that process
<X-Rob> so check the tomcat process
<X-Rob> see if it has a http_proxy variable
<TheFezzer> hmm
<TheFezzer> ubuntu@vagrant-local-machine-5:~$ sudo cat /proc/pid/environ
<TheFezzer> cat: /proc/pid/environ: No such file or directory
<X-Rob> you need to change 'pid' to be the pid
<X-Rob> process id
<TheFezzer> derp
<X-Rob> of the tomcat process
<TheFezzer> ok
<TheFezzer> hmm, donât see one
<X-Rob> juju run --machine $BAY2,$BAY3,$BAY4 "sudo apt-get -y install uvtool-libvirt"
<X-Rob> juju run --machine $BAY2,$BAY3,$BAY4 "sudo reboot"
<X-Rob> juju run --machine $BAY2,$BAY3,$BAY4 "sudo -E uvt-simplestreams-libvirt sync --source http://cloud-images.ubuntu.com/releases/ release=trusty arch=amd64"
<X-Rob> Thse previous lines will pre-load the libvirt cache from the proxy. Yay.
<X-Rob> I realise that probably no-one else cares about this 8)
<X-Rob> Geez.
<X-Rob> I swear that the people who wrote this stuff haven't actually used anything in the real world.
<X-Rob> https://bugs.launchpad.net/charms/+source/hacluster/+bug/1409548
<mup> Bug #1409548: Multicast Address isn't randomized <hacluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1409548>
#juju 2016-01-11
<D4RKS1D3> #maas
<D4RKS1D3> sorry
<D4RKS1D3> Hi everyone
<beisner> y
<beisner> lol
<beisner> o/
 * beisner tells the next step in his laptop upgrade, yes, please, move along
<lazyPower> beisner \o
<beisner> lazyPower, howdy
<beisner> whew.  just upped my main rig from vivid to wily to xenial dev and survived.
<beisner> not that i expect anything less though!
<lazyPower> nice :D
<tiagogomes__> Hi, I have a question regarding running JuJu in OpenStack. Does it create persistent storage?
<tiagogomes__> Does it create persistent storage for the VMs that are running the services?
<lazyPower> tiagogomes__ : Juju allows you to model persistent storage, so it depends on the charm. There are docs about this feature here:
<lazyPower> tiagogomes__ : https://jujucharms.com/docs/1.25/storage
<tiagogomes__> lazyPower thanks
<lazyPower> icey ping
<icey> lazyPower
<lazyPower> disregard, i actually need to ping beisner
<beisner> lazyPower, yo
<matt_dupre> Just noticed a charm in the store that hasn't picked up some changes to the corresponding bzr trunk branch.  Could someone please take a look and let me know if I'm doing anything wrong?
<matt_dupre> The charm is https://jujucharms.com/u/project-calico/bird/trusty/ and the branch is https://code.launchpad.net/~project-calico/charms/trusty/bird/trunk
<matt_dupre> The last 3 revisions haven't been reflected in the store (3rd was only pushed just now, but the other 2 are old and should have appeared long ago)
<lazyPower> matt_dupre: We're aware of some ingestion issues that started on Friday
<matt_dupre> 2 of these revisions date back to August though (!)
<lazyPower> matt_dupre: https://github.com/CanonicalLtd/jujucharms.com/issues/189
<lazyPower> may want to chime in on this bug and subscribe to it
<matt_dupre> OK, so I've looked at the corresponding link to api.jujucharms.com/... (i.e. the view code links) and actually that has been updated for the old changes.  I double checked with a copy of the charm downloaded by `juju deployer` and that was also good.  Looks like it's only the "10 revisions" bit displaying the history that's wrong
<matt_dupre> Thanks for the link though: I'll watch the latest change and update it if it doesn't work.  Would you like an issue for the history box in the charm store not updating properly?
<lazyPower> matt_dupre : subscribe here, seems applicable - https://github.com/CanonicalLtd/jujucharms.com/issues/196
<matt_dupre> lazyPower: thanks, done
<gnuoy> Has anyone else been having charm assembly problems with ruamel.yaml 0.10.13 ?
<gnuoy> http://paste.ubuntu.com/14470761/ <- seems to be at the point when config.yaml from multiple layers is combined
<gnuoy> downgrading ruamel.yaml in the virtualenv seems to fix it
<lazyPower> gnuoy: can you file a bug against the charm build process?
<lazyPower> gnuoy: we use ruamel to preserve the ordering of yaml items
<lazyPower> gnuoy: github.com/juju/charm-tools
<gnuoy> lazyPower, I files an issue already, is that the same thing?
<gnuoy> https://github.com/juju/charm-tools/issues/88
<lazyPower> gnuoy: perfect. Thanks for the report. We need to either take this up with upstream or pin the version of ruamel
<gnuoy> kk
<natefinch> ericsnow: is it possible to setresource without any data?
<ericsnow> natefinch: probably
<natefinch> ericsnow: I'll let you know ;)
<ericsnow> natefinch: :)
<natefinch> looks likely... but you never know on these edge cases
<pmatulis> for LXD local provider. will the user need to manually manage images (delete and import) in order to keep things fresh? this will include both the LXC host cache and the chosen (local or remote) image store i imagine
<jrwren> pmatulis: I think so, yes.
#juju 2016-01-12
<gnuoy> jamespage, is there any harm in having two network endpoint entries one for quantum and neutron ?
<cholcombe> launching juju local containers over crappy hotel wifi is super painful
<tiagogomes__> Hi, does JuJu requires Cinder to be installed when bootstrapped on OpenStack when some charms define some storage requirements?
<cholcombe> tiagogomes__, i would guess yes.  Let me have a look at the charm
<cholcombe> tiagogomes__, what does your deploy currently look like?
<tiagogomes__> cholcombe which deploy? JuJu? I am not trying to deploy anything yet. I am just trying to understand if Cinder is required, because for some reasons we can't have Cinder installed in our setup
<cholcombe> tiagogomes__, i see
<cholcombe> tiagogomes__, i'll have to defer to one of the openstack guys.  I'm not certain
<tiagogomes__> If JuJu calls "nova attach" i would say it needs
<tiagogomes__> but on https://jujucharms.com/docs/1.25/storage, it says persistent storage is future work.
<jamespage> gnuoy, hey - hows it going?
<jamespage> tiagogomes__, to use an openstack cloud using juju, you don't need cinder deployed
<tiagogomes__> hi jamespage. Thanks. So what happens when you assign storage to a service? Or when you run "juju storage add"
<jamespage> tiagogomes__, you won't be able to assign persistent storage to a service without cinder
<jamespage> I suspect the command will throw an error but I don't know definatively
<tiagogomes__> jamespage so some charms may not work if they specify storage right and there is no Cinder service right?
<jamespage> tiagogomes__, most will default to using the root disk if storage is not explicilty configured
<tiagogomes__> jamespage I understood that. Bu what if f storage is explicilty configured?
<tiagogomes__> *But
<jamespage> tiagogomes__, tbh its such a new feature I don't think you will hit that today
<jamespage> tiagogomes__, maybe in April...
<jamespage> but not today
<tiagogomes__> ah, so storage functionality is new
<gnuoy> jamespage, good, do you see my mps?
<stub> cory_fu_, marcoceppi : And the unreadable diff of the year goes to  https://code.launchpad.net/~stub/charms/+source/postgresql/+git/postgresql/+merge/282299
<stub> Yay git file name tracking
<tiagogomes__> Another JuJu question, can I choose the flavor that VMs will use for JuJu bootstrapped on OpenStack
<tiagogomes__> Hi, is it possible to run the JuJu state server on the baremetal, whilst orchestrating the services in OpenStack VMs?
<marcoceppi> lazyPower: ping
<marcoceppi> tiagogomes__: technically, yes
<marcoceppi> tiagogomes__: any reason why you would want the state server on the bootstrap node and not in the cloud?
<tiagogomes__> marcoceppi it was requested by a costumer
<marcoceppi> tiagogomes__: so, the bare metal and the openstack cloud would need to be on the same network, or addressable, and it's really more a hack.
<marcoceppi> tiagogomes__: not something that juju was designed to do
<tiagogomes__> marcoceppi they will be in the same network. Is there instructions how to do so?
<marcoceppi> tiagogomes__: no, because it's really not a supported thing
<marcoceppi> tiagogomes__: you basically have to bootstrap the openstack cloud first, juju add-machine ssh@baremetal; juju ensure-availability --to 1; destroy machine 0 from openstack
<tiagogomes__> marcoceppi thanks, by "bootstrap the openstack cloud first" you mean 1. deploy openstack 2. bootstrap juju on Openstack?
<coreycb> gnuoy, tiny mp if you can take a look: https://code.launchpad.net/~corey.bryant/charm-helpers/swift-mitaka/+merge/282337
<gnuoy> coreycb, how can 2.5.0 equate to both liberty and mitaka ?
<coreycb> gnuoy, I originally thought that was going to be a problem but it appears not to be
<gnuoy> coreycb, I don't understand tbh. If I look up what release 2.5.0 is won't I always get liberty returned?
<coreycb> gnuoy, get_os_version_codename() is called with the codename (mitaka) as the first parameter, and it then loops through the SWIFT_CODENAMES looking for the 2.5.0 that has 'mitaka'
<coreycb> gnuoy, well, sortof.  actually it just loops until it finds mitaka and returns 2.5.0
<coreycb> gnuoy, although there's a call to SWIFT_CODENAMES[vers] elsewhere that looks like it could be an issue
<gnuoy> yeah, I think it'll break get_os_codename_package
<gnuoy> coreycb, ^
<gnuoy> From what I can tell it'll always return mitaka for 2.5.0
<coreycb> gnuoy, ok I need to figure something out for this and I"ll get back to you. thanks.
<gnuoy> np
<lazyPower> marcoceppi pong
<marcoceppi> lazyPower: I have some concerns about the 'subprocess run'.split() stuff
<lazyPower> marcoceppi: do tell
<marcoceppi> lazyPower: https://github.com/juju-solutions/charms.docker/pull/10 if any of those parameters have a space in it, there's a potential for breakage
<marcoceppi> while, not likely in this scenario, it's a common pattern I'm seeing and I think it has some reprocusions
<lazyPower> marcoceppi: Aside from scrubbing the input strings, suggestions on a fix?
<marcoceppi> lazyPower: well, don't split the string, build a list instead
<bdx> openstack-charmers: is there a best practice for provisioning multiple availability zones using the cinder-ceph charm?
<marcoceppi> lazyPower: http://paste.ubuntu.com/14479145/
<marcoceppi> lazyPower: the first command creates foo\ bar the second creates foo and bar
<lazyPower> marcoceppi https://github.com/chuckbutler/charms.docker/commit/f19a0c67d6af5c9e2644451543b32838390d52e9
<marcoceppi> lazyPower: thanks, not to be a stickler, but there's a potential for a breakage if the password has a space
<lazyPower> np, good catch
<marcoceppi> lazyPower: also, there's an extra space between [ and 'docker
 * marcoceppi analretentive mode disabled
<lazyPower> marcoceppi updated the pr
<lazyPower> approve when ready :)
<bdx> openstack-charmers: I'm currently deploying 3 extra instances of cinder volume to work around being able to have different availability zones
<bdx> http://paste.ubuntu.com/14479202/
<bdx> openstack-charmers: by setting cinder_cross_az_attach=True, I am able to attach instances on hypervisors in an availability zone other than nova, to storage in the nova az
<bdx> but it seems the availability zone have to exist in cinder in order for this to work
<bdx> openstack-charmers: what I'm wondering, is, am I going about this right?
<bdx> "seems the availability zone have to exist in cinder in order for this to work" <-- I deploy the extra cinder-vol charms to get these availability zones created
<bdx> even though they are not 'really' used
<bdx> openstack-charmers: these compute nodes http://paste.ubuntu.com/14479284/ cannot use cinder volumes unless they exist in cinder as well http://paste.ubuntu.com/14479280/
<bdx> even if there is no actual storage backend in the az, they just have to exist
<Prabakaran> Hello Team,  I am writing amulet test code for ibm-java and since it is a subordinate charm i am using ubuntu charm to test ibm-java subordinate charm.  For testing purpose i have downloaded ubuntu charm and edited metadata.yaml file and mentioned provides as "java". Here both ibm-java and ubuntu charm are connected via java interface.  Now here i want my amulet test code to pick ubuntu charm from my local location which is (/home/ch
<Prabakaran> i want my amulet test code to pick ubuntu charm from my local location which is (/home/charm/charms/trusty/ubuntu) here i dont want ubuntu charm from charm store. How to achieve this. Could someone please help me to resolve this?
<Prabakaran>  if i am using ubuntu charm from charm store for my amulet test while adding the relation ie. d.relate('ibm-java:java', 'ubuntu:java') i am getting relation error. Please advise.  Please find the 10-deploy.py code is http://pastebin.ubuntu.com/14479663/
<bdx> charmers: is the packages option in reactive-base-layer usable?
<bdx> charmers: Is this legitimate http://bazaar.launchpad.net/~jamesbeedy/charms/trusty/fiche/trunk/view/head:/layer.yaml ?
<mbruzek> Hi James.
<mbruzek> bdx I don't know the answer to that
<mbruzek> bdx: cory_fu_ or one of the bigdata charmers might know
<lazyPower> beisner ping
<lazyPower> nvm i see you're out on teh calendar
<bdx> mbruzek: hey, thanks for responding ... I guess I should probably ping one of the main contributers of reactive-base-layer even ..
<bdx> marcoceppi: can you comment on ^
<mbruzek> bdx: Yeah I took a look but I was not sure what you were doing, I saw some fixes come in for the "options"  on base layers from the bigdatacharmers, kwmonroe, cory_fu_, or others
<mbruzek> bdx: cory_fu_ and marcoceppi are in a different timezone right now, eating dinner I believe.
<bdx> mbruzek: gotcha, ok
<bdx> mbruzek: I'm trying to install apt pkg deps using the basic packages option
<bdx> mbruzek: https://github.com/juju-solutions/reactive-base-layer/blob/master/layer.yaml
<lazyPower> wait what?
<lazyPower> layers supports package installation?
<lazyPower> bdx WHERE DID YOU READ THIS WIZARDRY?
<bdx> lazyPower: https://github.com/juju-solutions/reactive-base-layer/blob/master/layer.yaml
<mbruzek> see bdx, not everyone knows about this
<bdx> lol
<bdx> darn
<mbruzek> bdx: I saw a fix come down today, from andrewmcleod.
<mbruzek> https://github.com/juju-solutions/reactive-base-layer/issues/21
<bdx> mbruzek: totally, I'm tracking, and up to date with that patch
<mbruzek> bdx: check out the layer-hadoop for more information?
<lazyPower> https://github.com/juju-solutions/layer-hadoop-client/pull/1/files
<lazyPower> look at how nicely that cleaned up
<lazyPower> kwmonroe nice wizarding
<bdx> yea, been there, from what I can understand layer-hadoop had to implement the packages option
<bdx> not use it from basic
<bdx> mbruzek, lazyPower: is ^ consistent with your interpretation of whats going on there?
<lazyPower> i think there's stuff still being fleshed out with it
<lazyPower> i mean this landed yesterday
<lazyPower> sorry 4 hours ago
<mbruzek> bdx: I just learned about this now, so I would not trust my interpretation of the options, kwmonroe or cory_fu_ would know more.
<mbruzek> but if what you have works, that would be awesome and I will look into this for my next charm.
<bdx> ok, yea .... I see this (https://github.com/juju/charm-tools/issues/85) as well, the last comment makes me think that the override needs to happen bc basic packages option isn't ready yet...
<bdx> yea, I'm pumped on it too!
<mbruzek> bdx this looks great!
<mbruzek> bdx: from what I read on issue 85 it looks like your layer.html is correct, but again I just learned about this today so confirm with marco, cory or ben
<bdx> mbruzek: thanks, yea .. will do!
<kwmonroe> hey bdx - is your layer.yaml not working, or is it overwriting other package options (the problem discussed in issue 85)?
<bdx> kwmonroe: my install hook fails due to the packages not being installed ... http://paste.ubuntu.com/14480678/
<bdx> kwmonroe: my layer.yaml merges fine
<kwmonroe> fwiw, the big data charms are kinda tough to use as a reference because we used a "dist config" class that handles packages, so we're in the process of moving stuff that we used to do with our own dist logic to more generic packages stuff handled by the base layer.
<bdx> kwmonroe: ok, entirely.
<wesleymason> The charm I'm working on that was fine this morning is now refusing to install, dies at the initial bootstrap phase: http://pastebin.ubuntu.com/14480739/
<bdx> wesleymason: rebuild your charm
<wesleymason> bdx: already did, same result
<bdx> wesleymason: it will pull in the new changes from base layer
<bdx> should*
 * wesleymason kills deps
<lazyPower> yeah wheels die slowly
<lazyPower> make sure you nuke your artifact and rebuild occasionally
<lazyPower> its additive only, doesn't seem to remove older deps
<wesleymason> strange, that looks like it accidentally pulled and older pre-py3 charmhelpers wheel
<bdx> lazyPower: yea, is there a reason for that^?
<wesleymason> as the basestring error should only happen for py2 only being run with p3
<lazyPower> bdx removals are hard
<kwmonroe> wesleymason: did you rebuild within the last 6 hours?  the basestring problem was fixed in https://github.com/juju-solutions/reactive-base-layer/issues/19
<wesleymason> kwmonroe: I rebuilt, but didn't blow away everything properly, seems to have hung on
<kwmonroe> yeah - a charm build without an rm -rf is probably not a good charm build ;)
 * wesleymason burns everything with fire
<kwmonroe> that's a known issue -- obsolete artifacts should be killed Real Soon Now, but my MO is to just burn it down every time.
<kwmonroe> bdx, i'm working up a better example for pakcages in layer options (better than the big data stuff).. but i'll need about 20 more minutes.
<wesleymason> so, while I wait for juju to bootstrap and charm to run, let me say that I'm loving the new reactive stuff ð
<wesleymason> Building an errbot charm with it: https://github.com/1stvamp/juju-errbot
<kwmonroe> meanwhile bdx, if you're blocked, you can always do the old school apt-get install git in your fiche charm: https://github.com/juju-solutions/layer-ubuntu-devenv/blob/master/reactive/ubuntu-devenv.py
<bdx> kwmonroe: yea, I just abandoned it in favor of using the layer basic packages option
<kwmonroe> heh. understood bdx.  it's gonna be great ;)
<bdx> kwmonroe: funny, thats what I keep saying about HA openstack service endpoints :-0
<kwmonroe> bdx: i've tried to break this a bunch, but it Just Works.. not sure why package options in your layer.yaml aren't working.. here's my convert from an install hook to layer.yaml: https://github.com/juju-solutions/layer-ubuntu-devenv/commit/c66183ce52e9cefe188af32facf5929406aacce5
<kwmonroe> and the resultant charm ends up installing bzr/cvs/git/svn like i want
<kwmonroe> bdx: the only thing i can think of is perhaps your layer.yaml isn't being parsed correctly because of the lack of indetion on lines 2-3: http://bazaar.launchpad.net/~jamesbeedy/charms/trusty/fiche/trunk/view/head:/layer.yaml  shot in the dark, but maybe try indenting those?
<bdx> kwmonroe, thats how they end up after charm generate
<bdx> or `charm build`
<bdx> or `charm compose`
<kwmonroe> :)  gotcha
<bdx> ha
<kwmonroe> i wasn't sure how picky the yaml parser was
<bdx> kwmonroe: do yours not end up indented like that?
<kwmonroe> well, now i'm embarassed to say.. i was looking at the output of charm build, but yes, in fact my layer.yaml looks like this:  http://paste.ubuntu.com/14481219/
<kwmonroe> *wasn't
<bdx> ok
<bdx> hmm
<kwmonroe> bdx, can you ssh to the unit with the failed install and see if the other stuff was there?  like autoconf, make, etc?
<bdx> kwmonroe: yea, they are not.
<kwmonroe> bummer
<bdx> kwmonroe: yea... cool that it works for you
<bdx> you give me hope
<bdx> I think there might be an issue with my layer.yaml getting parsed.... I'm thinking only the layer from nginx gets parsed
<kwmonroe> bdx: i'm gonna try using git in my install hook.. maybe somehow the layer packages options are still being installed when the install hook is run.  i dunno, i'm grasping here.
<bdx> kwmonroe: thanks.... I just `rm -rf`'d my trusty/fich dir and rebuilt
<bdx> I'm hoping that does it
<bdx> hoping that fixes*
<bdx> kwmonroe: it worked for me
<kwmonroe> ha!  awesome.. that's great news bdx.
<bdx> I must of had a stale charm-tools hanging out in my wheelhouse
<bdx> anyway
<bdx> thanks for your help
<bdx> and insight
<kwmonroe> yeah sure - glad it worked.. i won't charge you for this session.
<bdx> ha
<marcoceppi> bdx: do you still need help?
<marcoceppi> bdx: your layer.yaml looks good to me
<marcoceppi> are you seeing an issue?
<bdx> marcoceppi: I figured it out - looks like I hadn't `rm -rf`'d my trusty/fiche dir for a few builds
<marcoceppi> bdx: ah
<bdx> marcoceppi: I closed that issue in layer-basic ... my bad
<marcoceppi> bdx: cool, there are some limitations, cory_fu_ and I are working on them this week
<marcoceppi> but we're in GMT+2 for the week
<bdx> awesome
#juju 2016-01-13
<pitti> hello
<pitti> so several minutes ago I did "juju destroy-service autopkgtest-cloud-worker", and it did destroy the autopkgtest-cloud-worker/0 instance and the associated machine
<pitti> but "juju status" still keeps "autopkgtest-cloud-worker" with a status of "life: dying", and it never goes away
<pitti> http://paste.ubuntu.com/14485499/
<pitti> is that because some subordinate charms still reference this?
<pitti> I can't redeploy the charm while it's in that state
<pitti> I already tried "juju destroy-relation ksplice autopkgtest-cloud-worker", and same for landscape-client, but that doesn't help
<pitti> I tried destroying the landscape-client and ksplice services too, but still didn't help
<marcoceppi> pitti: taking a look
<pitti> marcoceppi: axino suggested to do "sudo restart jujud-machine-0" on the 0 machine, but that didn't help either
<marcoceppi> pitti: that's alos a bit...drastic
<marcoceppi> pitti: it's odd, because it's referencing ksplice and landscape but I don't see services with those interfaces deployed
<pitti> marcoceppi: well, they are subordinate charms -- they get deployed on each "real" service
<pitti> they are not standalone services
<marcoceppi> pitti: sure, but they're not in status at all
<marcoceppi> pitti: right, but th relations for that service are listed with no units
<marcoceppi> pitti: it seems the service isn't being recycled, because of this relation
<marcoceppi> because the machine is basically gone, no units exist, etc
<marcoceppi> does juju remove-relation autopkgtest-cloud-worker ksplice do anyhting?
<pitti> marcoceppi: nothing visible at all
<marcoceppi> pitti: weird. obviously this isn't supposed to happen
<pitti> marcoceppi: well, they are in status, you see e. g. landscape-client/6
<marcoceppi> pitti: right, but not on the autopkgtest service
<pitti> yeah, as that's gone after destroy-service
<marcoceppi> pitti: does `juju destroy-service --force autopkgtest-cloud-worker` do anything?
<marcoceppi> it's just stuck in dying, which usually means something as failed, a relation or something else
<pitti> marcoceppi: there's no such option
<pitti> juju --version: 1.24.7-trusty-amd64
<marcoceppi> :\
<pitti> it's actually quite simple for me to destroy and re-deploy the whole env, I was just wondering as this did work before
<pitti> I re-deployed the worker service individually two or three times
<marcoceppi> pitti: it should work, something is stuck where Juju says it's not ready to reap the service because there's still an action pending against this
<marcoceppi> you see this a lot when relations fail on destroy, or stop hook fails
<marcoceppi> but I can't see exactly what it's stuck on, and since it's a 1.22 version I don't remember if there were any oddities in that release
<pitti> 1.24
<pitti> marcoceppi: anyway, I'll re-do the whole thing; thanks for looking!
<marcoceppi> pitti: you may have 1.24 locally, that deployment is agent-version: 1.22.6. either way, good luck!
<pitti> marcoceppi: ah, ok
<pitti> marcoceppi: whatever is in prodstack
<pitti> marcoceppi: but maybe they updated to 1.24 by now, and with re-deploying I'll get that too, I'll see
<marcoceppi> \o/
<pitti>     agent-version: 1.24.7
<pitti> marcoceppi: seems so
<pitti> marcoceppi: so next time I run into errors I'll have a less outdated version
<marcoceppi> pitti: awesome, it's easier to support 1.24.7 since 1.25.0 is latest
<wesleymason> Anybody seen an issue were a reactive built charm during upgrade/install continually loops around uninstalling and reinstalling wheels?
<marcoceppi> wesleymason: interesting.
<cory_fu_> Can't say that I have.
<marcoceppi> wesleymason: do you have a link to the charm? more importantly can you show me the hooks/upgarde-charm file?
<wesleymason> marcoceppi: charm is https://github.com/1stvamp/juju-errbot (WIP)
<marcoceppi> wesleymason: I think I know the issue, we can patch in a few mins
<wesleymason> marcoceppi: upgrade-charm hook: http://pastebin.ubuntu.com/14485929/
<marcoceppi> wesleymason: thought so, thanks, we'll patch this quickly
<wesleymason> marcoceppi: cheers ð
<marcoceppi> wesleymason: when this lands in a few mins, `charm build` again https://github.com/juju-solutions/reactive-base-layer/pull/23
<wesleymason> marcoceppi: aha, tvm
<wesleymason> perhaps marcoceppi's PR could get a bit of love? https://github.com/juju-solutions/reactive-base-layer/pull/23 - in order to keep working on my charm I keep having to manually copy everything in and void a proper rebuild
<wesleymason> s/void/avoid
<tiagogomes__> I am correct to assume the JuJu State Machine VM, needs to have access to the OpenStack endpoint APIs? If I use floating IPs, does the uJu State Machine communicates with other VMs using floating IPs or in the tenant network?
<marcoceppi> wesleymason: I just poked cory_fu_
<wesleymason> marcoceppi: ta
<cory_fu_> marcoceppi: lgtm, but let me test it.  ;)
<marcoceppi> psh, tests ;)
<wesleymason> In other news I can now deploy errbot with juju ð (minus nrpe, http and the ability to install from a wheelhouse rather than pypi)
<cory_fu_> wesleymason: Ok, the wheelhouse loop on upgrade-charm is fixed, if you rebuild your charm.
<wesleymason> cory_fu_: marcoceppi: cheers guys
<D4RKS1D3> Hi, I removed a charm via command line but in the juju-gui i see the charm, which it is the way to solve this problem? thanks in advance
<lazyPower> D4RKS1D3  whats the current status when you look at the service in `juju status`?
<D4RKS1D3> environment: maas machines: {} services: {}
<D4RKS1D3> juju resolved -r neutron-api/0 ERROR unit "neutron-api/0" not found
<lazyPower> D4RKS1D3 and the GUI still has the service as listed? Reloading the browser tab doesn't correct itself?
<D4RKS1D3> if I reload the page continue neutron-api service
<D4RKS1D3> but not the uni
<lazyPower> D4RKS1D3 That sometimes happens when you destroy a machine out from under a service, and dont remove the service... but if your juju status output says there's nothing registered, thats bug worthy
<D4RKS1D3> http://s22.postimg.org/4aqldlaz5/Screenshot_130116_13_53_43.png
<lazyPower> D4RKS1D3 can you psatebin me the output from juju status --format=tabular ?
<D4RKS1D3> of course
<D4RKS1D3> lazyPower, http://paste.ubuntu.com/14487078/
<lazyPower> D4RKS1D3 ok it appears you have removed the machine/unit, but not the service
<lazyPower> D4RKS1D3 juju destroy-service netron-api
<lazyPower> *neutron-api
<D4RKS1D3> I wrote this command, yes
<lazyPower> seems stuck huh? try adding a unit to neutron-api, then running juju destroy-service neutron-api
<D4RKS1D3> Okey lazyPower
<D4RKS1D3> juju add-unit neutron-api --to lxc:3 ERROR cannot add unit 1/1 to service "neutron-api": cannot add unit to service "neutron-api": service is not alive
<lazyPower> progress, seems that the service itself is stuck without a unit showing in status.. but somethings lingering in the state server keeping it around.
<lazyPower> D4RKS1D3 Can i get you to file a bug about this? https://launchpad.net/juju-core/  https://login.launchpad.net/LfAACUW1CApYLLfk/+decide
<D4RKS1D3> Of course
<lazyPower> include the status output, gui screenshot, and the all-machines.log, steps to reproduce
<D4RKS1D3> Yes
<D4RKS1D3> what do you need
<lazyPower> > status output, gui screenshot, and the all-machines.log, steps to reproduce
<tiagogomes__> Hi, can someone reply to this: I am correct to assume the JuJu State Machine VM, needs to have access to the OpenStack endpoint APIs? If I use floating IPs, does the JuJu State Machine communicates with other VMs using floating IPs or in the tenant network?
<lazyPower> tiagogomes__ the tenant network i do believe
<D4RKS1D3> I think the same, only the tenant network
<lazyPower> tiagogomes__ juju uses the private interface for communicating with the nodes. I'm pretty sure floating-ip only effects the public interface
<lazyPower> D4RKS1D3 oh lol i just realized i pasted a login link to you. the intended link was launchpad.net/juju-core
<tiagogomes__> ok. I see. And the JuJu state machine needs to call the OpenStack APIs right? Or is the client that does that?
 * tiagogomes__ is trying to sort out network requirements
<lazyPower> The state server makes requests to the OS API's
<lazyPower> depending, juju deploy openstack, juju deploy an environment into that openstack. So you'e got the idea of your cloud, and as beisner  says, your "undercloud"
<lazyPower> so it depends on which layer of cloudy goodness you're talking about :)
<D4RKS1D3> lazyPower, I do not see the the link in the juju-core
<lazyPower> D4RKS1D3 https://bugs.launchpad.net/juju-core/+filebug
<tiagogomes__> I see. I am talking about JuJu bootstrapped on OpenStack. And The JuJu gui makes requests to the state server right? It doesn't call the OpenStack APIs
<lazyPower> Correct
<lazyPower> all juju interaction is routed through the model controller (state server)
<tiagogomes__> tvm lazyPower!
<lazyPower> np tiagogomes__
<D4RKS1D3> lazyPower, all-machines.log is a huge file! hahahaha
<beisner> o/ hi all
<D4RKS1D3> hi beisner
<beisner> is that mr beedy?
<lazyPower> i dont think so bdx is beedy
<beisner> hi D4RKS1D3 ;-)
<beisner> lazyPower, chipping away at the rvw Q.  i don't have merge perms on mysql.  can you do the honors on this?  https://code.launchpad.net/~barryprice/charms/trusty/mysql/add-innodb_file_per_table/+merge/281398
<jcastro> hey lazyPower
<jcastro> so like marco told me with him the LXD provider breaks like every 6 bootstraps or so
<jcastro> but I have not had issues
<jcastro> what would be a good way to just automate having my laptop fire up workloads in a loop?
<jcastro> I figure, let it run for like 8 hours and see what happens
<jose> beisner: did you get it merged already?
<beisner> hi jose!  nope, but it's ready to land.
<jose> beisner: ok, let me take a look
<lazyPower> jcastro cronjob to run a bundletester job?
<jcastro> I've not used bundletester before
<jcastro> is there a tldr doc somewhere?
<lazyPower> pip install bundletester && bundletester -F -l DEBUG -v in the charmdir
<lazyPower> lemme see what we have in the docs
<lazyPower> i'm positive we have somem stuff in the dev docs about this too
<lazyPower> jcastro https://jujucharms.com/docs/devel/developer-testing#bundletester
<jcastro> ack, thanks
<jose> beisner: and, pushed!
<lazyPower> ta jose
<jcastro> seems to still use juju-deployer
<beisner> jose, great, thanks.  i'll send a review mail to the list.
<lazyPower> also, o/ jose
<jose> hey, lazyPower!
<lazyPower> jcastro thats probably the case. juju deploy is too new to have it consumed in our testing infra already
 * jcastro nods
<lazyPower> does the lxd provider not work with juju-deployer?
<jcastro> I am not sure yet, I was just reading the github page on bundletester
<lazyPower> beisner have i introduced you to my personal assistant, charmbot 5000? aka jose
<jose> >.>
<lazyPower> xD
<jcastro> huh, juju-jitsu is still in xenial
<lazyPower> whoa
<lazyPower> i thought that was deprecated as of precise
<jcastro> I'll find out how to remove it
<jose> jcastro: on main?
<jose> or, I mean, universe?
<lazyPower> hey jcastro, i have a potential TC attendee to the charmer summit. Think we have some space for floating heads in a box on a laptop?
<lazyPower> tc = teleconference
<jose> jcastro: you'll need to get a MOTU to remove the package
<jcastro> https://bugs.launchpad.net/ubuntu/+source/juju-jitsu/+bug/1533738
<mup> Bug #1533738: Remove juju-jitsu package from Xenial <juju-jitsu (Ubuntu):New> <https://launchpad.net/bugs/1533738>
<jcastro> they told me what to do
<jcastro> we just file a bug and subscribe ubuntu-archive with an explanation
<beisner> lazyPower || jose - can you review/land this?  it's a c-h resync to enable openstack mitaka (ceilometer + mongodb) deployability.  https://code.launchpad.net/~1chb1n/charms/trusty/mongodb/ch-sync-mitaka/+merge/282211
<lazyPower> jose wanna take that one?
<jose> beisner: I have to run an errand right now - if lazy hasn't done it by when I'm back I'll do it
<jose> lazyPower:
<jose> ^ *
<lazyPower> sound good
<jose> cool
<lazyPower> beisner in a meeting, gimme a few and i'm on it
<beisner> thx guys.  fwiw, the code it's pulling in has already been reviewed and landed in lp:charm-helpers.
<jacekn> hello. I am trying to write an amulet test for a simple subordinate. It uses "juju-info" relation. I am trying to relate it with cs:ubuntu charm like this: "cls.deployment.relate('ubuntu:juju-info', 'collectd:juju-info')"
<jacekn> I am getting this: http://pastebin.ubuntu.com/14488256/
<jacekn> any ideas what I am doing wrong?
<beisner> jacekn, are you able to make the same relation on those services outside of the test?  ie.     juju add-relation X Y
<jose> jacekn: not sure on this, but does your charm provide juju-info?
<jose> like, explicitly stated?
<jacekn> beisner: only if I do "juju add-relation ubuntu collectd"
<jacekn> beisner: so it seems to me that the amulet depends on juju-info being in the metadata.yaml which it probably shouldn't
<beisner> jacekn, yeah i've not looked at the code, but i suspect it just parses metadata.yaml to populate valid interfaces.
<jacekn> see this: http://pastebin.ubuntu.com/14488278/
<jacekn> so how should I test my subordinate?
<beisner> given the empty dict, i bet you're right. {   u'Error': u'no relations found', u'RequestId': 1, u'Response': {   }}
<beisner> i'd say it's in python-jujuclient
<beisner> or hrm.  that explicit juju add-relation fail takes me back to:  juju-info is somehow super-special
<jacekn> even juju itself can't add that relation (ubuntu:juju-info collectd:juju-info)
<lazyPower> jacekn correct, juju-info relations are bad
<lazyPower> using it as the implicit interface on a scope: container relation is ok
<lazyPower> but not as the relation name
<lazyPower> beisner ^
<lazyPower> jacekn swap that relation to be something like: "metric-host:   interface: juju-info  scope: container" and you should clear up that error
<icey> in developing a layer, not a top level layer, is it OK to use any of the @hook decorators?
<jacekn> lazyPower: you mean in my subordinate's metadata.yaml?
<icey> also, would it be a good idea to (if possible) make a layer that is not intended to be the top layer deployable?
<icey> ie: calling charm build on the layer would make a deployable charm
<lazyPower> jacekn correct
<lazyPower> icey you can
<lazyPower> icey you just cant mix @hook and @when decorators
<lazyPower> icey however we do prefer that you not use the @hook decorators unless they are absolutely necessary. Like set up a method that uses/provides a synthetic state
<lazyPower> and use those states to drive, as thats more natural when charming with consuming layers
<icey> I'm thinking more about the install hook :)
<lazyPower> its odd to try to intercept @hooke('config-changed')  in 3 layers, vs doing something like @when_not('dependency.installed')
<icey> everything else I'm fine pushing to reactive state but can't figure out a non-ridiculous way to handle the install
<lazyPower> well
<lazyPower> considering states run until their state change occurs in the bus coupled with a guarding @when_not()
<lazyPower> you can set the state you want to imply install, and @when() on your other 3 or 4 method decorators
<jacekn> lazyPower: that did not help: http://pastebin.ubuntu.com/14488410/
<beisner> lazyPower, can you re-trigger tests for http://review.juju.solutions/review/2394 ?
<lazyPower> beisner aws and lxc re-added to the queue
 * lazyPower circles back
<beisner> lazyPower, thx
<lazyPower> inc rev/merge on above link
<icey> lazyPower: how would I get my needed state set?
<lazyPower> icey charms.reactive set_state('thing.amabob')
<icey> in an @hook('install')?
<lazyPower> sure
<lazyPower> from charms.reactive import set_state
<lazyPower> set_state('thing.amabob')
<icey> I know how to set states, wondering what the recommended way to replace an install hook would be
<lazyPower> oh
<lazyPower> @when_not('thing.amabob')
<lazyPower> def do_something()
<lazyPower> # do something here
<lazyPower> set_state('thing.amabob')
<lazyPower> then in followign methods
<lazyPower> @when('thing.amabob')
<jose> lazyPower: on it?
<lazyPower> do_something() will trigger in that first sweep of the reactive bus
<lazyPower> jose already merged
<lazyPower> just need to push
<lazyPower> actually the merge is hng up
<jose> lazyPower: gotcha
<lazyPower> if you wanna do it go for it
<jose> bzr push :parent
<jose> ^^ copy and paste
<lazyPower> nah its stuck on the merge dude
<lazyPower> $ bzr merge lp:~1chb1n/charms/trusty/mongodb/ch-sync-mitaka
<lazyPower> sitting here on this, cycling
<jose> ok let's see
<jose> as long as it's not a fat charm I'm good
 * icey lunches
<jose> beisner: merged
<beisner> thanks jose
<jose> np
<beisner> jose o/   got one hot off the press.  https://code.launchpad.net/~ajkavanagh/charms/trusty/mongodb/fix-unit-test-lint-lp1533654/+merge/282472
<beisner> ie.  some old existing lint in the unit test file just crossed the failure line in whatever bleeding edge version of flake8 gets pulled from pypi
<jose> beisner: lucky you, I still have that directory open
<beisner> woot
<jose> and landed
<beisner> thanks again, jose :)
<jose> np
<icey> lazyPower: got a few minutes to chat more about the layers / reactive stuff, maybe on a hangout?
<mbruzek> Hey guys I just reviewed a charm that uses SFTP and no crypto verification.  Is that OK?
<mbruzek> Does using sftp remove the need to do cryptographic verification of a payload?
<marcoceppi> mbruzek: ehhhhhhhhh
<marcoceppi> mbruzek: it's on the fence, I'd mail the list
<lazyPower> icey : hey sorry i stepped out for lunch
<lazyPower> marcoceppi are we doing standup in 10?
<icey> no worries lazyPower :) I figure IRC is async
<marcoceppi> lazyPower: probably, yes
<marcoceppi> moving to better wifi
<lazyPower> icey But i can help out of band, whats up?
<icey> just trying to wrap my head around best practice for intermediate layers and hooks
<lazyPower> icey well i prototyped some of what this looks like elsewhere
<lazyPower> icey this is a sandwich layer with a short lifespan, it will be deprecated in favor of layer-docker-libnetwork
<lazyPower> https://github.com/chuckbutler/flannel-layer/blob/master/reactive/flannel.py
<lazyPower> but i dont bind to *any* of the default hookenv hooks
<lazyPower> i'm sniffing states off the base layer and setting states for hte top layer to consume via unitdata.kv()
<icey> marcoceppi: can you let me know how to depoloy a local charm with a bundle
<marcoceppi> icey: set JUJU_REPOSITORY and set charm: local:trusty/charm
<icey> thanks, yeah the bundle export from juju gui gave me an error with the charm number after
<bdx> hey whats up guys? Is there a charmhelper function, or best practice anyone knows of to generate self-signed certificates other then using subprocess and pipes?
<marcoceppi> bdx: you should talk to lazyPower
<lazyPower> bdx hi there
<marcoceppi> o/ arosales
<marcoceppi> bdx: and mbruzek
<lazyPower> bdx have you looked at the TLS layer in interfaces.juju.solutions?
<bdx> oooh ... I just realized you can pass a -config option to a file
<bdx> lazyPower: I was looking at the way its done in the apache2 charm
<lazyPower> bdx nope!
<lazyPower> we have new stuff
<bdx> lazyPower: nice, I'll check it now, thanks
<lazyPower> bdx https://github.com/mbruzek/layer-tls
<lazyPower> the tls layer is only peer capable so its not server/client aware yet
<lazyPower> but getting there
<lazyPower> sets up PKI, each unit generates a CSR, the leader signs it and hands back the certificate
<lazyPower> consume, easy self signed pki
<bdx> this is great!
<bdx> I want to use it now
<lazyPower> do it!
<lazyPower> we want bugs / feedback / layers to use this
<lazyPower> bdx we're doing server/client key generation for kubernetes with this and its workign quite well
<mbruzek> bdx it is still very new, but please give us feedback
<lazyPower> so if you need an example to follow, we have one for ya
<lazyPower> i should have the prelim work done w/ swarm to hand over soon'ish too, its about a week behind the k8s refactoring
<bdx> lazyPower, mbruzek: entirely, awesome!
<mbruzek> bdx we aim to please
<bdx> mbruzek: it was a great idea to make this a layer ... every website/api endpoint should/could need this
<mbruzek> I know!  Right?
<mbruzek> To be honest we stumbled upon that with our kubernetes work
<mbruzek> but yeah I want to make it more generic and useful to any charm layer so please advise, open bugs, or sing is praises in #juju
<bdx> of course :-)
<beisner> mysql charm mitaka prep ready for review/landing.  https://code.launchpad.net/~1chb1n/charms/trusty/mysql/ch-sync-mitaka/+merge/282209   i believe this is the last of the mitaka uca blocker syncs - jamespage || gnuoy
 * D4RKS1D3 GoodNight!
#juju 2016-01-14
<tiagogomes> Hi, if I loose the juju state server, and I haven't ran the ensure-availability command, is all lost?
<jose> tiagogomes: was your server turned off or completely shut down?
<jose> by 'completely shut down' I mean destroyed forever
<tiagogomes> jose I was talking about a hypothetical scenario. I'd like to know if was possible to recover from "completely shut down"
<jose> not 100% sure on this
<tiagogomes> ok. what if I ran ensure-availability. And laster I acquired new hardware. Would it be possible to rerun ensure-availability so that a new state server starts on the new hardware?
<stub> I think the review queue needs a kick. 30 mins and my MP isn't up.
<jose> stub: let me check if the merges I did cleared from the queue
<lazyPower> stub it may be behind a bit, when tvansteenburgh surfaces i'll poke at him to poke @ the logs and see if it needs cycled
<lazyPower> also o/ stub
<stub> ta both of you
<stub> o/
<lazyPower> mornin jose
<lazyPower> tiagogomes thats tricky
<stub> I'm never sure if it has hung or if my ISP is being evil.
<lazyPower> stub :(  always a gamble
<tiagogomes> lazyPower oh, can't just I add a state server?
<lazyPower> tiagogomes nope. if you ran a single state server (no ha) and then destroy it, the chances of re-creating your model controller node are pretty minimal
<lazyPower> there are some backup/restore tecnniques but i dont recall off hand what they were
<lazyPower> natefinch: didn't' you do a writeup to the list on how to recover from a tanked state server? or was it just how ot recover from missing .jenv files?
<tiagogomes> lazyPower oh I think that you were replying to my first question. I asked after "<tiagogomes> ok. what if I ran ensure-availability. And laster I acquired new hardware. Would it be possible to rerun ensure-availability so that a new state server starts on the new hardware?"
<lazyPower> tiagogomes - i think if you had one node still participating, you could reasonably re-create a HA state server, but restoring from a single node you're in for some heartache
<lazyPower> but to 100% be certain of that i would need to confirm from core that its been tested
<lazyPower> this is all theory at the moment
<lazyPower> beisner still need that mysql mitaka sync landed?
<tiagogomes> My use case is that I purchase some blade server to use for JuJu. Later on I purchase another server and I would like to run the state server in the new server for high-availability, as they are in two different availability zones
<beisner> hi lazyPower - indeed if you've got cycles, please do.  TA!
<lazyPower> beisner just pushed. LGTM
<lazyPower> i like what you did in tests/tests.yaml
<jose> ohai lazyPower
<lazyPower> o/
<lazyPower> updates
<natefinch> lazyPower: howdy... not me, I don't think.  Maybe perrito666?  He's the restore master.
 * perrito666 feels summoned
 * natefinch waves at perrito666.
 * natefinch points at lazyPower.
 * lazyPower points at scrollback
 * natefinch sorta misses MUDs and all the emotes they had sometimes.
<beisner> thx lazyPower
<lazyPower> haha
<lazyPower> natefinch did you MMUD bro?
<natefinch> lazyPower: hugely in college... even ended up running a MUD for a while.
<lazyPower> same here, i pulled it out in 2014 and played a couple months worth of "let the bot autoroam in foreveralone mode"
<perrito666> I see, it is theoretically possible
<perrito666> although I never tried to do exactly that
<lazyPower> tiagogomes ^
<lazyPower> seems like its theory, but not practice yet
<lazyPower> beisner np np
<lazyPower> If anyone is looking for some background noise, I just cut the final edit of the systemzoo podcast - episode 3 featuring former juju developers Wayne Witzel, and Whit Morriss - http://systemzoo.org/3
<tiagogomes> lazyPower ?
<lazyPower> tiagogomes - confirmation that rebuilding from a fractured HA setup hasn't been verified
<lazyPower> perrito666 says its "theoretically possible" but it doesn't appear that we have data to back it up
<tiagogomes> lazyPower, ha, what you mean by fractured.  I was hoping to rerun ensure-availability with a working system to make it even more HA
<perrito666> backing up, changing a server and restoring should work but we never tested said feature as a migration, only as a rescue
<tvansteenburgh> stub: lazyPower: revq looks ok on the backend, should get to your mp eventually
<pmatulis> can juju use a network image store remote with the lxd local provider?
<matt_dupre> I've pushed a bundle to Launchpad, but it hasn't appeared in the charm store (been a few hours).  I used lp:~project-calico/charms/bundles/<bundle-name>/bundle; but is there anything else I need to do?
<lazyPower> matt_dupre nope, that looks about right
<lazyPower> we were having issues with ingestion in the last couple of weeks though
<lazyPower> matt_dupre - take a look here and if its a problem item add the url to the bug please - https://github.com/CanonicalLtd/jujucharms.com/issues/189
<matt_dupre> What kind of time should I expect for a bundle?
<lazyPower> matt_dupre the longest you should have to waiti for a bundle ingestion is ~ an hour. publications using the launchpad ingestion system cycle every half hour
<matt_dupre> OK, thanks lazyPower: I'll add a note to the issue
<lazyPower> this problem will "go away" with juju 2.0 - as store upload is a direct process.
<lazyPower> while that doesn't help today, we're getting there quickly!
<Prabakaran> Hello Kevin, Hope you are doing great !!. This is regarding IBM Java layer charm. Since it is a subordinate charm i am using ubuntu charm to test ibm-java subordinate charm.
<Prabakaran> In this case i am connecting ibm-java charm and Ubuntu charm via java interface. So before running charm build command layer.yaml file looks like this http://pastebin.ubuntu.com/14497095/ .
<Prabakaran> If I am connecting via java interface to test my charm, i have downloaded ubuntu charm and edited metadata.yaml file and mentioned provides as "java".
<Prabakaran> Now if I want to connect ibm-java layer charm with Ubuntu charm with juju-info interface. I think I may have to change layer.yaml file before running charm build command.
<Prabakaran> If so, is there anything that i need to edit in the layer.yaml file, please advise how to connect Ubuntu charm and ibm-java layer charm with juju-info interface.
<tiagogomes> Hi, I am trying to boostrap JuJu on OpenStack but I am getting an not very helpful authentication failed. Is there a way to see more information about what's going on? I am using verbose mode. Also, does JuJu supports keystone v3?
<kwmonroe> hi Prabakaran - the java relation is needed to test your charm.  without it, the java states won't be set, which means you will not enter the code that does install or config-changed.  so i don't think you should change your ibm java charm to use juju-info.
<kwmonroe> Prabakaran: i'm working on the following, which is a generic ubuntu charm that already has the java interface for you.  if you deploy this, you shouldn't have to modify a local ubuntu charm.  instead, relate your ibm-java charm to ubuntu-devenv:  https://jujucharms.com/u/kwmonroe/ubuntu-devenv
<kwmonroe> Prabakaran: the nice thing about a generic ubuntu-devenv is that we can use the same thing for stuff like ibm-xlc and ibm-fortran, in addition to jdk providers like ibm and zulu.
<Prabakaran> Thanks kevin, i will test my charm with ubuntu-devenv charm
<kwmonroe> cool - good luck Prabakaran!  once i get tests added to that charm, i'll put it up for review.  until then, you can deploy it in a test like this (note the cs:~kwmonroe namespace for ubuntu-devenv): http://paste.ubuntu.com/14497345/
<tiagogomes> does JuJu boostrapped on OpenStack requires Swift?
<bdx> mbruzek, lazyPower: Nice work on layer-k8s and layer-tls!  After giving it some thought, and reviewing what I'll be trying to do alot of using the tls-layer, I feel like I need to use the  ca(), client_cert(), and server_cert() functions in k8s.py, everywhere I will be using layer-tls. Should/could those functions just be part of layer-tls?
<lazyPower> bdx we're considering shipping a lib w/ the tls layer
<lazyPower> that would be a good abstraction point
<bdx> lazyPower: each of the three functions, and the other two functions they depend on could just be defined in lib/tlslib.py and accept an input parameter of dest_dir?
<lazyPower> something like that
<lazyPower> we like the idea of key retrieval from unit data
<lazyPower> its all nicely encapsulated there in the charm state store, so why not?
<lazyPower> you can put it wherever you want
<lazyPower> keep it in memory if thats something you're into
<lazyPower> skys the limits
<lazyPower> bdx: file a bug and lets sketch what it looks like there
<lazyPower> i'lll ping the list about it, see how many "does this work with lets encrypt" responses and then land a lib
<bdx> lazyPower: sweet!
<bdx> will do
<icey> what's the policy with regards to layers on python versions, I'm trying to use a layer that does not work on python3 but works fine on python2
<lazyPower> i think we're targeting python3
<lazyPower> i know stub has strong feelings on this. I feel like as a whole we are moving away from python2 as its long since deprecated.
<icey> that's what I was hoping to hear :)
<icey> I notice that the hooks generated with charm build use /usr/bin/env python3
<bdx> lazyPower, mbruzek: like this https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/lib/tlslib.py ?
<lazyPower> bdx add some unit tests and you're talkin buddy!
<lazyPower> bdx btw we like py.test <3
<bdx> lazyPower: Is there a way to run my tests w/o deploying the layer/charm?
<lazyPower> just unit tests, if you want to functionally test it, you'll either need to provide the env its expecting or mock it out like crazy.
<lazyPower> bdx i have a few concerns of mixing state in a library, as that seems like a layer should be doing that
<bdx> entirely, I was wondering about that too
<lazyPower> i suppose if its properly namespaced, theres no harm in it, but in the event that webapp.certificate.available ever is set in another layer... its going to cause unintended side effects
<lazyPower> i think if it just performs the system level operation, and is used like a helper
<bdx> totally
<lazyPower> and all state is set outside of that utility library, its good as is, just needs some uniform docstrings and unit tests
<bdx> lazyPower: https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/lib/tlslib.py
<lazyPower> bdx i like where this is headed
<lazyPower> +1 to your docstrings
<bdx> thx
<bdx> lazyPower: so looking into unit_tests, I want to start with the unit_test template for a charm modified for this layer
<bdx> lazyPower: https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/unit_tests/test_actions.py
<bdx> is this ok/recommended in a layer?
<lazyPower> bdx thats fine, i've also adopted a py.test pattern here - https://github.com/juju-solutions/charms.docker/blob/master/tests/test_docker.py
<lazyPower> but i also made this a proper python package that is nested in charms.d
<lazyPower> charm.*
<lazyPower> s/m./ms./  # epic typing fail of the week achieved
<bdx> wow, really cool
<lazyPower> bdx just basic python unit tests
<lazyPower> i try to keep my code as concise as possible so i'm only done one, and at most two mocks at a time while testing the code
<lazyPower> stacks of mocks get messy, and i dont always trust that i'm testing what i think i'm testing
<bdx> lazyPower: I feel like I need the keys to exist to be able to test the functions in lib .... should I create optional input params to those functions for source_directory?
<lazyPower> you can make it a test fixture
<lazyPower> be aware that unitdata.kv() will create a db in the directory that is running the tests
<lazyPower> and need to clean itself up
<bdx> lazyPower: so I could essentially create a fixture for layer-tls, or just for each of the functions?
<lazyPower> just for that test file
<lazyPower> test fixtures aid in ssetting up things like controlled files on disk so you can create/remove a database in between tests, or only at start/end of test run
<lazyPower> bdx https://pytest.org/latest/fixture.html
<bdx> wow, really cool
<lazyPower> bdx: sorry split brain. i re-read the scroll back and yeah - i would make some optional input parameters, and also template a couple of throw away certs to load in as fixture data
<lazyPower> that way you're not married to having the amenities provided by the layer, you're only dealing with the end certificates w/ examples to test with in that lib. that will keep the sep. of concerns to a minimal.
<bdx> lazyPower: ok, what about things like JUJU_UNIT_NAME ?
<bdx> http://paste.ubuntu.com/14498348/
<bdx> lazyPower: should I just set the env vars that it needs in the tests?
<lazyPower> those are environment variables when they are read in, so now we're heading into mocking out os.environ
<lazyPower> or setting those in the fixture
<bdx> gotcha
<aisrael> lazyPower: "Authors can use this hook to take action if their protocols for
<aisrael> leadership, consensus, raft, or quorum require one unit to assert leadership." <-- should raft be draft?
<lazyPower> negative. Raft is a consensus algorithm
<lazyPower> aisrael ^
<aisrael> lazyPower: ack, thanks!
<aisrael> lazyPower: This a good link? https://en.wikipedia.org/wiki/Raft_(computer_science)
<lazyPower> aisrael indeed
<aisrael> Wow
<aisrael> Wrong window ^_^
<lazyPower> aisrael mind = blown? :)
<aisrael> pwoooosh
<icey> https://gist.github.com/ChrisMacNaughton/f8a6e9b32b8d9bccfbe5 is replacing newlines in the output file with nothing and I can't figure out why; if I print privkey to stdout, it has newlines correctly but the written file has none, I've tried splitting on \n and iterating on lines, I've tried leaving the base64decode result as bytes and opening the file as binary
<hatch> has there been any discussion around adding 'required' fields to a charm configuration?
<aisrael> jrwren: Hey, is this ready for re-review? https://code.launchpad.net/~evarlast/charms/trusty/apache2/trunk/+merge/278220
<jrwren> aisrael: yes, iirc
<jrwren> aisrael: or no.
<jrwren> aisrael: if the tests pass, then yes. otherwise, no.  Sorry, I lost track of that one.
<bdx> lazyPower: https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/unit_tests/test_actions.py
<bdx> lazyPower: any pointers from here?
<bdx> lazyPower: https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/lib/tlslib.py
<aisrael> jrwren: ack. I'll re-test and bump the bug if it needs attention
<jrwren> aisrael: thanks.
<lazyPower> bdx close, i dont see any assertions
<bdx> ahh entirely..... what should I assert though? just '0' ?
<bdx> oooh
<bdx> I should assert that the certs are in the correct places after the functions are ran/tested
<lazyPower> that or just verify the write operation was called
<lazyPower> we dont have to test python, we should test that we're using python correctly though
<icey> lazyPower: ever use base64 to pass blobs of data into charm configs that you end up writing out to a file?
<lazyPower> i have
<icey> a layer I'm trying to use does that but it doesn't work correctly, (stripping newlines?!)
<lazyPower> uhh
<lazyPower> what?
<icey> want to see the code?
<lazyPower> what layer?
<lazyPower> yeah
<icey> https://plus.google.com/hangouts/_/canonical.com/juju-client
<icey> and the layer is the juju-client one
<icey> :-P
<lazyPower> icey i'm in standup room atm
<icey> doing standup or hanging out?
<lazyPower> it might still happen ;)
<lazyPower> not sure yet, we have 5 minutes for it to go either way
<icey> hahaha
<icey> this shouldn't take 5 :)
<icey> but I can wait too :-P
<icey> let me know
<bdx> lazyPower: now? https://github.com/jamesbeedy/layer-tls/blob/port_k8s_to_tls_lib/unit_tests/test_actions.py
<icey> lazyPower: maybe we can look at it in the AM if I can't figure it out by then :)
<lazyPower> icey Sounds like a plan
<lazyPower> i need ot EOD soon
<lazyPower> bdx Hit me with a PR in the morning and i'll review
<icey> me too :) started tearing down my aws env and realized we had an outstanding maybe today :)
<lazyPower> haha, right on icey  thanks for circling back
<icey> course lazyPower, will ping you tomorrow if I haven't cracked it by then :)
<beisner> coreycb, first of many mitaka amulet test enablement MPs, ready for review/landing if ya will:  https://code.launchpad.net/~1chb1n/charms/trusty/cinder/next-amulet-mitaka-1601/+merge/282519
<coreycb> beisner, ok
<lazyPower> beisner: how did that ppc64 patch go?
<lazyPower> from sfeole
<beisner> lazyPower, thx for directing us to that.  gave feedback on the MP re: targeting at a different charm branch.  /me --> EODs
<ennoble> could someone explain to me how the runcmd file that is handed to cloud-init is created by juju?
<bdx> Is there a way to direct `charm generate` to grab layers from charms/layers if they exist instead of from there repos?
<bdx> whoops ... my bad, looks like it already does :-)
<bdx> I can spell
#juju 2016-01-15
<lazyPower> bdx yep, $LAYER_PATH and $INTERFACE_PATH
<tiagogomes> Hi all, does JuJu boostrapped on OpenStack requires Swift?
<gnuoy> jamespage, got a sec for https://code.launchpad.net/~gnuoy/charms/trusty/nova-compute/1515570/+merge/277556 ?
<stub> tvansteenburgh: Bootstrap is failing in the lxc test runner (ERROR there was an issue examining the environment: cannot use 37017 as state port, already in use)
<tvansteenburgh> stub: thanks, will fix
<icey> has anybody made a custom hook for juju before?
<icey> outside of juju core that is
<jrwren> icey: I don't even know what that means. When would it trigger? :)
<icey> as a result of juju-run :)
<jrwren> icey: how would that differ from an action?
<icey> expanding on an idea that came out of the sprint
<icey> it woudn't really, except that the user shouldn't be calling it, another charm would be :-D
<jrwren> icey: how would that differ from a realtion? :]
<icey> this charm would have no relations
<icey> it woulkd interct with potentially every other charm deployed
<jrwren> why not?
<icey> IF the other charm had defined this hook
<jrwren> ah, there is the implicit relation, right?
<icey> in essence, it would be an advanced service health monitor
<jrwren> i can't see how this differs from a relation.
<jrwren> IMO you have just defined relation.
<icey> can I have one side of a relation run a command on the other service?
<icey> there's relation-joined, relation-departing
<jrwren> yes?
<icey> but not relation-run?
<icey> itr should run every update-status
<jrwren> well, both run.
<icey> it*
<jrwren> relation-changed
<jrwren> so update-status would change the relation state causing the relation-changed to run
<icey> thaat could be a lot of bouncing back and forth
<jrwren> what is update-status? do you mean maintenance status?
<icey> update-status is a hook that runs regularly
<icey> update-status provides constant feedback to the user about the status of the service the charm is modeling. The charm is run by Juju at regular intervals, and gives authors an opportunity to run code that gets the âhealthâ of the service or services.
<jrwren> ah cool, i've not used that. maybe I should :)
<icey> yeah, in essence I'm working on a beefed up version of that, and charm authors can define both health checking functionality and potentially remediation for issues
<jrwren> sounds very interesting.
<icey> examples coming from storage charms: hard drive becomes unhealthy, system can remove the hard drive, run tests against it, and maybe re-add it
<icey> if that fails, alert a human to intervene
<jrwren> we are currently using nrpe for health checking and the nrpe subordinate and nrpe module in charmhelpers makes it simple and great.
<icey> my coworker has been lightly discussing it with someone on the core team and they like it, we're going to talk about it more but I figure maybe I can hack together a super basic version :)
<icey> so far it's working out but I wondered if anybody had done anything similar
<jrwren> icey: I think you can. update-status could change relation data which would cause relation-changed to execute. That gives you what you need afaict.
<icey> I really don't want to have to add a relation to it; it also works just fine by adding the juju-client layer to the charm
<icey> if we have to add relations, it becomes something that the administrator must add all of the relations when it can be done through juju itself
<jrwren> i see. yeah.
<beisner> hi all.  juju 1.25.2 is in ppa:juju/proposed.   today i'll be flipping our openstack charm testing lab to use that version for test automation.
<tiagogomes> Hi all, does JuJu boostrapped on OpenStack requires Swift?
<beisner> hi tiagogomes, i don't believe it is expressly required.  two links for reference:
<beisner> https://jujucharms.com/docs/1.25/config-openstack
<beisner> https://jujucharms.com/docs/1.25/howto-privatecloud
<tiagogomes> thanks. I have seen those, but I when I try to bootrap juju I got an "caused by: the configured region "RegionOne" does not allow access to all required services, namely: compute, object-store. access to these services is missing: object-store" error
<mgz> beisner: yell if you see anything fun with 1.25.2
<beisner> mgz, thx sir.  i've just done a global force of all uosci jobs to proposed 1.25.2.  it'll get some serious exercise as we're in charm freeze/testing.
<mgz> since I added extra validation to our OS-deployer job we've had intermittent failures due to the env not finishing all relations, but that should hopefully just be master
<beisner> mgz, our automation calls `juju-wait -v` immediately after juju-deployer exits.  that has resolved the testing-too-soon issue for us.
<beisner> we found that arbitrary sleep times are racy, given the undercloud load varies.
<beisner> but i can't point at a single case where juju-wait failed to wait 'til the deployment, hooks, relations, etc., were actually-done.
<beisner> so that's a cool tool.  +100 stub
<beisner> +1000 even
<mgz> beisner: my version is similar to that, but also looks at the workload-status reported by the charms
<mgz> well, instead really.
<beisner> mgz, yeah in our amulet tests we don't use juju-wait, we wait for extended workload state as well.  which is arguably the best way.  for the charm to announce: ok, i'm ready now.
<mgz> indeed, but relies on charm sanity
<beisner> yep
<lazyPower> oi, our charms are sane
<mgz> :P
<lazyPower> what are you insinuating mgz? ;)
<aisrael> tvansteenburgh: Should this merge request be showing up in the queue? It's been reviewed as needs fixing but the original author hasn't responded since then: https://code.launchpad.net/~brad-marshall/charms/trusty/memcached/add-monitors-relation/+merge/276958
<aisrael> tvansteenburgh: also, item 2391 in the queue is a dead link
<tvansteenburgh> aisrael: 2391 removed
<aisrael> ta
<tvansteenburgh> aisrael: i'll have to look into the other thing, just not right this sec
<aisrael> tvansteenburgh: No worries. Just wanted to make sure it was on your radar.
<icey> anybody have thoughts on testing an action that would require removing parts of a unit and multiple minutes for any differences to become visible
<stub> icey, jrwren : You don't need update-status. You can call the juju-run tool from a cronjob running on the unit to do stuff in a hook context.
<mbruzek> cory_fu_: marcoceppi, lazyPower, any other charmers, can I get a review on the charm-helpers update: https://code.launchpad.net/~mbruzek/charm-helpers/host-docstrings/+merge/282788
<bdx> marcoceppi: do have a example of layer-django being consumed?
<bdx> marcoceppi: I've created `anyapp` to test with here -> https://github.com/jamesbeedy/anyapp
<bdx> and django-nginx charm here http://bazaar.launchpad.net/~jamesbeedy/charms/trusty/django-nginx/dev/files
<bdx> marcoceppi: what I'm wondering is how you are setting up your django project <-> what params you are setting in your django.yaml
<lazyPower> i'm pretty sure marco is travelling today bdx, replys may be latent.
<lazyPower> thanks for the PR btw :)
<bdx> lazyPower: ok. cool. yea... about that ... I'm testing it out a bunch as well .... not sure its fully there yet ... but I think I'm making some good headway... http://bazaar.launchpad.net/~jamesbeedy/charms/trusty/django-nginx/dev/view/head:/reactive/django_nginx.py
<lazyPower> nice
<bdx> lazyPower: the @when hook will only execute when all states are met right?
<lazyPower> yep
<bdx> lazyPower: but will it execute everytime the states are met?
<lazyPower> yep
<lazyPower> unless you add a @when_not to prevent it from running
<lazyPower> or something to that effect
<bdx> so then using the only_once hook will ensure that it only runs one time, no matter how many times the states are satisfied in the @when?
<lazyPower> good question, i'm not sure :)
<lazyPower> I've not used only_once
<tiagogomes> Hi, when JuJu 1.25 will be released? Will it be part of ubuntu 16.04 ?
<lazyPower> tiagogomes 1.25.0 is already out as stable
<lazyPower> 1.26.0-alpha is the current dev release, with 2.0 on the horizon
<tiagogomes> lazyPower ah thanks
<icey> I'm adding an action to a charm and I'm not entirely sure how to test it; it changes a config in a running program, the easiest way I've thought of testing it is to query that the config value is changed. If I add testing for the functionality exposed by the configuration, I'm testing the underlying software as part of the charm tests, would that be desired?
<stub> I think it is desired. You do want to test the underlying software, because you need to confirm that the process you are using to change the configuration is correct (eg. you are remembering to send a HUP signal to reload, or that this particular setting requires the daemon bounced)
<stub> You could test that you changed the config and maybe issued a reload command, but that doesn't mean it actually works.
<stub> icey: ^
<lazyPower> o/ stub
<stub> o/
<stub> Off into the night in a tick
<icey> well, the program I'm using lets us send in cluster config through the program itself, and I can query the program to validate that the configuration changed stub
<icey> testing the underlying functionality would require me removing a disk, waiting (10+ minutes) for the disk to be marked down, bring the disk back up, trigger the action, kill the disk, wait longer than the first time to make sure it is not marked down
<icey> so, 20+ minutes of waiting?
<icey> and the program, ceph, will report the config to me if it is set
<stub> Right. Removing disks isn't possible in most automated test frameworks, so that is right out. Setting the config value and reading it back from ceph (not just looking at the config files) seems good.
<bdx> stub: yes!!!!
<icey> yeah, it's not a config file thing, it's literally telling ceph `ceph osd set nodown`
<icey> stub: thanks~!
<bdx> stub: you just touched on something near and dear to my heart
<bdx> stub: removing/replacing ceph disks is a danger zone
<bdx> stub: this is an area that needs help from the MAAS team
<stub> The kernel guys might be able to help you fake a failed disk if you really want (if ln -s /dev/random /dev/sdb2 doesn't do the trick)
<bdx> stub: if you replace/remove a disk in ceph, maas will assume a different drive for sda
<bdx> you also have to reboot the node
<bdx> but
<bdx> stub: ^ is a huge issue for me right now
<bdx> I have done alot of DR testing with ceph/maas
<bdx> maas would need to recommission  the node to be able to account for a new/replaced disk
<icey> bdx stub we're working on making the ceph experience better with juju, including updating / replacing disks
<icey> it's on our roadmap :)
<bdx> thats a relief
<bdx> the CIO of my company keeps bugging me about it
<bdx> he knows its not a thing
<bdx> I have been able to work around it by manually altering maasdb
<aisrael> stub: Is the cassandra work you've done ready-ready to go? https://code.launchpad.net/~stub/charms/trusty/cassandra/ensure-thrift/+merge/279869
<stub> aisrael: Yes. Just been resending it to the CI system for laughs.
<aisrael> stub: CI always needs something to do. :D
<stub> Good timing if you are reviewing - that branch was about to go into production ;)
<aisrael> stub: Yup, I am reviewing. So far, so good.
<icey> so, I'm noticing that the update-status hook doesn't seem to actually exist in any documentation yet?
<stub> icey: No, but I already opened an issue on that and it is being added.
<icey> ok, just wanted to make sure it was ok stub, thanks!
<mbruzek> bdx: I just got back from lunch and I am going to review your tls/k8s pull requests after my meeting
<bdx> mbruzek: sweet! its small, just swapped out your local chdir
<bdx> but the tls one is a little bigger
<icey> is there a recommended way to run actions in a functional test?
<tvansteenburgh> icey: https://github.com/juju/amulet/blob/master/amulet/deployer.py#L362
<icey> thanks tvansteenburgh, I just found the PR that added that :)
<icey> it's funny when google shows the PR before the actual file :-P
<pmatulis> mbruzek: fyi, https://github.com/juju/docs/pull/801 , comments welcome
<mbruzek> pmatulis: I am taking a look now
<mbruzek> pmatulis: I see what I was looking for on line 54!
<mbruzek> still reading
<pmatulis> mbruzek: thanks for the comments
<mbruzek> pmatulis: thanks for sending me the link
<bdx> anyone have luck with GitUrlFetchHandler or install_remote from charmhelpers.fetch ?
<natefinch> rick_h_: you around?
<mbruzek> bdx how did you run the tls tests?  http://paste.ubuntu.com/14510918/  I am getting an assertion error on the test_ca() method
<mbruzek> bdx I see a /tmp/server.crt, but not a /tmp/ca
<mbruzek> .crt
<bdx> mbruzek: ooo mbruzek, my bad, here
<mbruzek> no problem I am fixing it
<mbruzek> and setting up the repo to run these tests every push
<bdx> niceee
<lazyPower> 'eating broccoli' ;)
<lazyPower> bdx: Landed your class + tests with some refactoring
<lazyPower> give a look at master
<lazyPower> bdx https://travis-ci.org/mbruzek/layer-tls
<mbruzek> bdx: we had to rewrite the tests to pass.
<lazyPower> not really i mean
<lazyPower> we took his high level abstract, and then made it red2green
<bdx> lazyPower, mbruzek: nice!
<bdx> I knew the tests would need a little love
#juju 2016-01-16
<lazyPower> bdx hopefully they serve as a good jumping off point to start looking at when unit testing code for charms :)
<jose> anyone with op access, can you please banforward apuimedo? it makes it really hard to read backlog.
<lazyPower> jose you can do a local ignore that should accomplish the same thing
#juju 2016-01-17
<bdx> lazyPower: ^ entirely
#juju 2017-01-09
<kjackal> Good morning Juju world!
<CarlFK> good morning!
<sfeole> perhaps someone here can tell me if this is actually a bug? https://bugs.launchpad.net/juju/+bug/1655020
<mup> Bug #1655020: Newly Built Charm, "Vanilla" Fails to install, when following "Charm Build Getting Started Guide" <juju:New> <https://launchpad.net/bugs/1655020>
<sfeole> I just filed it, going through the proper channels. Just need a sanity check at this point :)
<Zic> hello here, do you know how to build a Kubernetes cluster with Juju but with multi-master HA? because the Juju charms demonstrated for Canonical Kubernetes just build a cluster with one master
<marcoceppi_> Zic: you should be able to take the bundle and add more units to master. I think there's a few gotchyas that are being ironed out though
<marcoceppi_> Zic: I can give you a bundle with multi-master if you'd like to try
<Zic> oh thanks, I'm interested
<marcoceppi_> Zic: Give me a few mins
<marcoceppi_> Zic: If you download http://paste.ubuntu.com/23770746/ and save it as something like ha-k8s.yaml, you can do `juju deploy ./ha-k8s.yaml` it's experimental, but if you hit any bugs please report them here https://github.com/juju-solutions/bundle-canonical-kubernetes
<Zic> thanks, I will take a look
<vmorris> trying to bootstrap a controller on localhost LXD while on a private network (squid proxy and dns forwarder in use)... using a custom lxd bridge and dnsmasq instance
<vmorris> http://paste.ubuntu.com/23771485/
<vmorris> i can't understand why jujud would be connecting to 10.20.123.254:8443/1.0 (this is the default gateway passed in through dnsmasq)
<SimonKLB> trying to setup juju on maas but im stuck with: ERROR failed to bootstrap model: waited for 20m0s without getting any addresses
<SimonKLB> however, sshing to the maas node works fine
<SimonKLB> any ideas?
<sfeole> SimonKLB, i just happened to click into this Channel and saw your message. When you issue the $juju bootstrap --debug <cloud> <controllername> do you see a node in MAAS becoming allocated and deploying?
<sfeole> SimonKLB, are you using --debug flag with bootstrap?
<SimonKLB> sfeole: yes, the maas node is started when im executing juju bootstrap
<sfeole> SimonKLB, mmmm, once the MAAS node is deployed is it in fact accessible via the network after MAAS deploys it?   Do you have access to watch the logs in /var/log/juju or /var/log/cloud-init to see if in fact the node is actually coming up fully?
<sfeole> SimonKLB, also, perhaps check you're not setting http_proxy or similar in your terminal..
<sfeole> SimonKLB, usually when I ran into the problem you
<sfeole> SimonKLB, you're mentioning, it's usually a problem with the MAAS host
<SimonKLB> sfeole: cloud-init logs are available but nothing juju related from the looks of it
<SimonKLB> sfeole: no obvious errors in the cloud-init logs
<sfeole> SimonKLB, the Node actually reached the "Deployed" state in MAAS?
<SimonKLB> sfeole: yep!
<sfeole> SimonKLB, hmm
<SimonKLB> it started off with a normal interface, but then created a br-eth0 and added the ip to that bridge instead of the physical nic
<SimonKLB> is that the expected behaviour?
<sfeole> SimonKLB, yes, it creates a bridge device by default
<sfeole> SimonKLB, could you post the juju bootstrap --debug output in pastebin?
<SimonKLB> sfeole: sure one sec
<SimonKLB> sfeole: http://paste.ubuntu.com/23771843/
<vmorris> beisner: I have the this paste showing a localhost+lxd bootstrap failure.. it nearly completes and then craps out at the end...
<vmorris> http://paste.ubuntu.com/23772244/
<vmorris> beisner: I think it's when it tries to connect to http://unix.socket/1.0/containers/juju-94a8f2-0/state
<vmorris> beisner: but i see on my http proxy that it's actually trying to connect to 10.20.123.254 (the default gateway), which gets denied
<vmorris> i have no idea what to tune or even where to dig in for more information... i couldn't really see anything in /var/log/lxd
<beisner> hi vmorris https://bugs.launchpad.net/charm-test-infra/+bug/1633788
<mup> Bug #1633788: juju 2.0.0 bootstrap to lxd fails (connect to wrong "remote" IP address) <canonical-is> <juju> <lxd> <lxd-provider> <uosci> <OpenStack Charm Test Infra:Confirmed> <juju:Triaged by rharding> <https://launchpad.net/bugs/1633788>
<vmorris> beisner qq
<admcleod_> facepalm
<vmorris> lol was that just good timing or what?
<vmorris> oh i thought that was somebody doing the triage in real time
 * vmorris facepalms
<sfeole> SimonKLB, sorry i got pulled away from meetings. How about the juju logs on the bootstrap node, since you have access?
<bdx> hey whats up everyone? is there a `--force` type arg for 'destroy-model'?
<bdx> I'm just getting "Waiting on model to be removed..." for days
#juju 2017-01-10
<lazyPower> bdx - no force flag for destroy-model
<lazyPower> sorry :(
<kjackal> Good morning Juju world
<deanman> Hi, I have an openstack controlled by juju and have configure it with `use-floating-ip`. I notice that every time i deploy a service it associates the same floating IP (i.e. moves it around) instead of assigning a new floating IP. Is that normal or a bug ?
<deanman> to be more precise when i deploy the same service, eg. deploy 3 ubuntu units will only assign a single floating IP and associate it with the last.
<kjackal> hi deanman_ you might have more luck if you asked at #openstask-charms
<Zic> re here, as I understand if I want to use Juju to deploy charms on physical server, I must also use MaaS?
<Zic> or if I set up manually my Ubuntu Server, I can bypass this step?
<magicaltrout> yeah you can use the juju manual provider to deploy to non bootstrapped servers
<Zic> I will search more documentation about that, thanks :)
<Zic> magicaltrout: I found https://jujucharms.com/docs/1.24/config-manual and I'm trying to run `juju generate-config` but all I have is a "ERROR unrecognized command: juju generate-config"
<Zic> does this doc is up-to-date?
<magicaltrout> not the 1.24
<magicaltrout> you want stable
<Zic> oops, sorry
<magicaltrout> you should be able to do something like a juju bootstrap lxd... to get a controller node running then add the unit
<magicaltrout> but i have no idea what the best practice is there
<deanman> hey kjackal, it is not related to openstack charms, I'm simply deploying on top of openstack.
<kjackal> deanman: I see, I thought it was an openstack configuration
<Zic> magicaltrout: seems that the equivalent for the stable version is this link: https://jujucharms.com/docs/2.0/clouds-manual
<magicaltrout> yup
<Zic> by the way, if I have a deployment that typically spawn 11 nodes on cloud, with my "manual provider" in my case, I read that I need to use "placement directive"
<Zic> but in the example, it's just a "1 node - 1 app"
<magicaltrout> you still need to place them
<magicaltrout> afaik
<Zic> my problem is: the general case explains placement directive as : "juju deply --to x" where 'x' is the id of the machine seen in 'juju status'
<Zic> but can I run something like --to 0,1,2,3,4,... ?
<magicaltrout> i don't believe so
<Zic> I just found a "juju add-unit rabbitmq-server -n 4 --to host1,host2,host3,host4" example in the doc... hmm, let's try it, it's only a PoC, I can break it if needed :)
<smgoller> Is there a way to specify in a bundle an IP address for a service? I've got a maas cluster that I'm deploying openstack on and it would be nice to be able to specify the address for things like horizon dashboard.
#juju 2017-01-11
<kjackal> Good morning Juju world
<junaidali> Hi guys, I'm trying to restore a failed juju controller. I have created a new controller and running the command 'juju restore-backup -b --file=juju-backup-20170110-092916.tar.gz'
<junaidali> but it is erroring out with the message 'ERROR old bootstrap instance ["bootstrap:6tdgfk"] still seems to exist; will not replace'
<junaidali> I'm following this doc->https://jujucharms.com/docs/2.0/controllers-backup. Am I missing anything here?
<kjackal> hi junaidali, you might want to also ask at #juju-dev
<junaidali> kjackal: thanks
<axino> hi
<axino> does anyone have an example of a config file you can pass to "juju deploy --config" ?
<axino> https://jujucharms.com/docs/devel/charms-config wee
<kjackal> axino: what are you looking for? Why isn;t the example enough?
<axino> kjackal: the example is enough and is what I was looking for
<axino> :)
<axino> I was just answering to myself
<kjackal> aaah :) sorry
<Hetfield> Hi i'm using conjure-up with openstack base charm
<Hetfield> unfortunately it seems using up to 18 machines (from juju status). i have 8 registered with maas server
<Hetfield> docs say i only need 4 machines. how to tell juju to relocate services to available machines? (ram is enough)
<Zic> hi here, what is the best way to controll where Juju deploys "roles" of a multi-machine Charms? For example, I'm still on my PoC testing of canonical-kubernetes, I deployed some VMs "foo-k8smaster-0[123]" and "foo-k8snode-0[123]" and added all of them to Juju with manual provisionnong (juju add-machine)
<Zic> if I run a juju deploy ./bundle.yaml of my custom canonical-kubernetes templates (wich have 3 kubernetes-master), Juju will deploy them somewhere else foo-k8smaster-0[123]
<Zic> (for this special example, foo-k8smaster-01 was dedicated to EasyRSA part, and foo-k8snode-02 was choosen to be the kube-api-loadbalancer...)
<petevg> cory_fu: matrix PR for you when you get the chance: https://github.com/juju-solutions/matrix/pull/69 (I think that this is the best way to get the matrix output_dir passed through everything -- it avoids attempting to resolve collisions between the args for bundletester and the args for matrix, and also only necessitates a code change in one more place. The
<petevg> only downside is that it doesn't work if we point the cwr  output at an S3 bucket ... but I figure that we can cross that bridge when we come to it.)
<sfeole> hey everyone, i'm working on my own charm and using subprocess.run to carry out a particular action, when i install the charm, the install hook fails complaining that subprocess does not have a module called 'run'. according to the docs the reactive framework runs in python3. Anyone have ideas?
<tvansteenburgh> sfeole: subprocess.run was added in 3.5
<sfeole> tvansteenburgh, reactive does not?
<sfeole> tvansteenburgh, oh i missed that
<sfeole> tvansteenburgh, thanks, btw, libjuju rocks
<tvansteenburgh> sfeole: thanks, glad to see people using it
<jhobbs> where can i get a juju deployer that works with juju 2.0 and juju2.1?
<jrwren> its built in as `juju deploy bundle.yaml`
<jhobbs> yeah but you can't deploy to existing machines with that
<vmorris> jhobbs: juju-deployer doesn't work for both versions? https://launchpad.net/juju-deployer
<jhobbs> vmorris: yeah i think it does, just wondering what ppa to install it from i guess
<jhobbs> the version in xenial is old
<vmorris> i think the last doc i saw said to use virtualenv and pip
<jhobbs> ah ok
<vmorris> https://pypi.python.org/pypi/juju-deployer/
<jhobbs> that would work too i think
<jhobbs> thanks vmorris
<vmorris> jhobbs yw
<emjburns> Hi, I'm using the canonical distribution of kubernetes charm. I can use the juju command to ssh into the nodes, but I'm wondering how to ssh into the nodes w/o juju - where are the credentials stored? I'm also wondering if there's any plan for the juju command to support rsync
<jhobbs> emjburns: ~/.local/share/juju/ssh
<lazyPower> emjburns - "ssh into the nodes without juju" - are you referring to just ssh user@ip? without routing through juju? i'm not certain i understand that portion of the question.
<emjburns> lazyPower: yes, i'm looking to do just ssh user@ip. I'd like to get rsync to work so i can grab the log files off each machine and put them in a central place (my kubectl logs command isnt working because of lack of FQDNs in my cluster)
<emjburns> jhobbs thanks!
<jhobbs> you're welcome emjburns
<lazyPower> emjburns ah, yeah :) that credentials path jhobbs posted is where you can find the client ssh credentials. you can alternatively add your owns sh key to the mix as well
<tvansteenburgh> jhobbs: the latest juju-deployer is in ppa:tvansteenburgh/ppa
<lazyPower> emjburns juju run --application foobar "ssh-import-id gh:my-github-id"  or leave off the gh: and use your launchpad id to import from launchpad.
<emjburns> lazyPower good to know! The next thing I'm wondering: is there a tutorial anyone can point me to for hooking up the juju ELK stack with my kubernetes cluster? I'm new to ELK.
<lazyPower> emjburns - ok, bit of contention there. our ELK offering is using older versions of all those components. (pre 5.0 release)
<lazyPower> you can still use it, just know that it comes with that caveat, its not the most recent version fo elastic's wares. I've been leading an effort to try and get community maintainers to help pitch in and make those charms prod ready
<emjburns> lazyPower ok also good to know. what would you suggest that I use then? (that effort would be awesome, btw)
<lazyPower> emjburns - the recommended path is to deploy the beats-core bundle
<lazyPower> and then relate those beats to your services you wish to monitor
<lazyPower> i haven't done that in a few weeks, you might be bitten by series mismatch on the beats charms themselves.
<emjburns> hmm ok. any tutorial you can point me towards that's more in depth than the beats-core info page?
<lazyPower> I do believe iw rote  a blog post about this, 1 moment
<lazyPower> emjburns https://insights.ubuntu.com/2016/09/22/monitoring-big-software-stacks-with-the-elastic-stack/
<emjburns> lazyPower cool thank you so much!
<lazyPower> emjburns no problem. If you're interested in the 5.0 upgrade story and have cycles to lend, i could certainly use your hands :)
<emjburns> lazyPower ok if beats doesn't work out for me I may see what I can do
<lazyPower> I'm all ears on this issue, there are several users that have requested better monitoring/metric collection from their k8s clusters, and i'm happy to entertain ideas/suggestions until we have a solid roadmap built around the story. Our initial goal is to provide options, so ELK, perhaps greylog if someone has the time to write the charm, prometheus, et-al
<emjburns> lazyPower I'm quite new to using the kubernetes charm, but I would absolutely love if it came with (or had the option to enable in the bundle.yaml) some logging solution. (or, i'm always happy to follow tutorials to set it up using other charms!)
<lazyPower> emjburns - well it does ship with log aggregation for the running workloads. there's a fluentd forwarding system that is used in the administrative dashboard
<lazyPower> but if you're looking for trend reporting, and long term retention, that's not enabled in our current bundle, and would be better served as an external deployment in my humble opinion (how do you log kubernetes if your cluster is unhealthy?)
<emjburns> lazyPower makes total sense as an external deployment, good point.
#juju 2017-01-12
<justicefries> just as a wild-eyed thought
<justicefries> i wish juju was structured a little bit more like Kubernetes where when I created a charm, I was just submitting a manifest rather than a charm with code, and my code was something more like third party resources.
<justicefries> how this would work in practice, I couldn't tell you.
<lazyPower> justicefries well we can skinny up that charm with layers
<lazyPower> but that only goes so far. I guess in reality if you wanted to get *really* persnickety, you could use just a metadata that declared resources, and a single hook, but thats really not what we're here to do. Operational code is often large to handle the complexities of interactions and what that effected change means in a context to your workload.
<lazyPower> also note: its midnight here so i hope i'm not babbling gibberish
<junaidal1> tvansteenburgh: Any idea, when networks spaces feature is added to juju-deployer? https://bugs.launchpad.net/juju-deployer/+bug/1642157
<mup> Bug #1642157: deployer doesn't support juju 2.0 network-spaces feature <juju-deployer:New> <https://launchpad.net/bugs/1642157>
<kjackal> Good morning Juju world!
<junaidali> Good morning kjackal
<SimonKLB> just deployed openstack bundle with conjureup, instead of deploying them on lxd containers inside the machines it deployed all the charms on different machines
<SimonKLB> what couldve happened to cause this?
<SimonKLB> this is on maas btw
<junaidali> can you share your bundle? is it openstack base bundle?
<SimonKLB> junaidali: yes, "OpenStack base for MAAS"
<junaidali> SimonKLB: this bundle https://jujucharms.com/openstack-base/ right?
<SimonKLB> junaidali: afaik
<SimonKLB> junaidali: it's the pre-defined one in conjure-up, i've not added a custom bundle
<junaidali> SimonKLB: is there a machine section in that bundle?
<SimonKLB> junaidali: yes
<SimonKLB> junaidali: but it might be due to the fact that it says "lxc:1" instead of "lxd:1" come to think of it
<SimonKLB> junaidali: ive seen something similar in the past
<SimonKLB> junaidali: never had any trouble deploying the bundle manually with juju deploy, but conjure-up seem to be tricked by it
<stokachu> SimonKLB, whats juju status look like?
<junaidali> SimonKLB: I've not used conjure up but manually deploying a bundle works even if there is lxc:<machine number>. Juju deploy command auto deploys to lxd
<SimonKLB> junaidali: yes
<SimonKLB> stokachu: http://paste.ubuntu.com/23786000/
<SimonKLB> 18 machines heh...
<SimonKLB> i wouldnt be surprised if it was the lxc/lxd bug
<stokachu> SimonKLB, yea gimme a few finishing something up and ill check it
<SimonKLB> stokachu: cool, thanks
<mskalka> SimonKLB mind showing the bundle.yaml?
<SimonKLB> mskalka: https://api.jujucharms.com/charmstore/v5/openstack-base/archive/bundle.yaml
<mskalka> ok so you're definitely on the base bundle.. that's quite odd
<SimonKLB> mskalka: well, that's just my guess tbh, conjure-up have some bundles pre-defined
<SimonKLB> mskalka: the one i deployed was named "OpenStack base for MAAS"
<SimonKLB> mskalka: i assume that is the one i linked to
<stokachu> SimonKLB, you're also on 2.1-rc1 it looks like
<SimonKLB> stokachu: yea, thats right
<mskalka> try pulling down the bundle from https://jujucharms.com/openstack-base/ and deploying it from local
<stokachu> ok just wanted to get the right juju version
<SimonKLB> mskalka: will do
<SimonKLB> anyone got a nice one-liner to empty a model of all it's applications?
<mskalka> can't guarantee anything but it might rule out conjure-up shenanigans
<SimonKLB> mskalka: yea
<mskalka> other than killing the controller? Not really
<stokachu> just destroy-model
<stokachu> juju destroy-model
<SimonKLB> stokachu: ah, conjure-up created a model of it's own
<stokachu> SimonKLB, :)
<SimonKLB> mskalka: stokachu how do i use conjure-up with a local bundle.yaml?
<stokachu> SimonKLB, cp -a ~/.cache/conjure-up-spells/openstack-base ~/openstack-base
<stokachu> then put your bundle in openstack-base
<stokachu> and you can run conjure-up -d <path_to_spell>/openstack-base
<SimonKLB> stokachu: ah, just deployed it through juju deploy now, works like it should - conjure-up will have to wait for another day
<SimonKLB> there is an issue ticket with a similar experience that i had, i commented my problem as well https://github.com/conjure-up/conjure-up/issues/553
<stokachu> SimonKLB, yea i've got someone on it
<stokachu> hopefully will have it fixed today
<SimonKLB> stokachu: great to hera!
<SimonKLB> hear*
<tvansteenburgh> junaidali: probably whenever someone submits a patch. i may get to it eventually but i doubt it'll be soon
<pmatulis> hi, using ppa:juju/stable i install juju and juju-deployer but i get a juju 1.x type error. i notice that juju-deployer actually gets installed from universe. i think there is a packaging snafu. see http://paste.ubuntu.com/23786563/
<tvansteenburgh> pmatulis: ftr, the most up-to-date juju-deployer is in ppa:tvansteenburgh/ppa
<pmatulis> tvansteenburgh, oh
<cory_fu> rick_h: https://github.com/juju/python-libjuju/blob/e13c7c82396da82780c0b18c32f88c79647d09a6/examples/deploy.py (once https://github.com/juju/python-libjuju/pull/46 is merged)
<tvansteenburgh> cory_fu: shouldn't it be loop.run(main())
<tvansteenburgh> or loop.run_until_complete(step())
<tvansteenburgh> i guess the former so that args can be passed
<Catalys> Good afternoon, is manage.jujucharms.com down? (Reason my Openstack single node installation is failing)
<magicaltrout> yup
<smgoller> how can I force destroy a model? I've got a model that's stuck on "Waiting on model to  be removed, 8 machine(s)...
<magicaltrout> can you remove-machine?
<smgoller> no
<magicaltrout> unlucky
<magicaltrout> dunno then
<lazyPower> smgoller juju remove-machine # --force is your saving grace here as magicaltrout pointed out.
 * magicaltrout gets lucky \o/
<lazyPower> sometimes, i've seen slow cloud cause issues where models can take up to 20 minutes to be reaped, and force removing the machines seemed to have done the trick
<smgoller> this is a maas cluster, and i've run that command and the machine is still not gone.
<lazyPower> its the controller doing the right thing trying to execute all the extant removal hooks, (*-departed, *-broken, stop), and then issue a removal request via the cloud api.
<smgoller> i released the machines on the maas side now so I'm just trying to figure out how to clean up without killing the controller
<lazyPower> smgoller - is this 2.0.2?
<smgoller> yes
<lazyPower> smgoller - can you tail your controller logsync file and see if there's anything pertinent spamming in the controller logs so we can file a bug?
<lazyPower> this smells of a regressionb ut we're going to need a root cause to be helpful
<smgoller> where is that located?
<lazyPower> you can juju switch controller && juju ssh 0 && tail -f /var/log/juju/*.log
<lazyPower> er that last && wont work as a chain, you'll probably need to put that in the ssh session
<smgoller> i know what's wrong
<smgoller> it's not juju
<magicaltrout> you coming to gent this year lazyPower ?
<lazyPower> magicaltrout yessir
<magicaltrout> excellent
<lazyPower> smgoller oh ok! do tell if you get it resolved
<smgoller> controller can't resolve the hostname of the maas server
<smgoller> is the actual problem
<lazyPower> magicaltrout i took a look at the mesos/k8s integration bits over holiday. we might actually get to that this year
<smgoller> so i'm good. thanks!
<lazyPower> smgoller oh awesome! thats good to hear (not that its a quibble, but that its  not a regression)
<smgoller> yes :)
<magicaltrout> nice one lazyPower I've got one of my guys working very slowly on LXC support for Mesos
<lazyPower> oh snap
<smgoller> i prefer problems to be mine instead of the software's i'm using
<lazyPower> lex dee in mesos :D
<magicaltrout> I need to sort out my Mesos charms and get them up to date as well
<magicaltrout> then bring in flannel
<magicaltrout> they have support in there somewhere
<lazyPower> magicaltrout yep, lmk when you've got that in the pipeline and i can try to schedule out some time to collab so we can do an external scheduler relation
<magicaltrout> yeah that would be good. I moved all my existing stuff to DC/OS as a test platform, but DC/OS is just Marathon with a fancy UI and some authentication, so I reckon we can do that nicely in Juju, but then it doesn't have the universe packager and stuff, but i reckon if LXC works as a cloud provider in Mesos, who cares! ;)
<lazyPower> ^
<lazyPower> that
<lazyPower> we can do universe packager as a stretch goal whenever someone wants it eh?
<magicaltrout> indeed its only marathon apps wrapped up in a git repo
<magicaltrout> still need to write my cfgmgmtcamp talk =/
<magicaltrout> when don't I need to write a talk?
<magicaltrout> and sumbit some to apachecon
<jrwren> only during the 1hr you are actualy giving a talk do you need to not write a talk. :)
<magicaltrout> aye, even then though....
<magicaltrout> lazyPower: got any cool K8S demo stuff? I have a conference I'm sponsoring full of developers in a few weeks, gonna take down a screen and stuff
<lazyPower> yeah, i wrote up an ARK server workload
<lazyPower> i hear games steal the show when you demo neat stuff with moving game servers
<magicaltrout> there will certainly be game and app developers there
<lazyPower> k let me get you my resource files
<magicaltrout> banging
<lazyPower> you'll need to drop the $20 on steam for the game tho
<lazyPower> prepare your wallet
<magicaltrout> i'm over it
<lazyPower> that soon huh?
<magicaltrout> lol, if it gets me work :P
<lazyPower> magicaltrout https://gist.github.com/99a68eb6602b2a9502f79315517969b2
<lazyPower> you'll want to scrub that private registry image link, incoming second gist wit the docker bits to build the server image
<lazyPower> https://gist.github.com/c3c3c5be88ec31b288a18b6577a8c832
<magicaltrout> excellenet
<magicaltrout> thanks lazyPower
<lazyPower> np, lmk if you have any issues with that
<lazyPower> its oddly specific to my homelab
<lazyPower> so there's maybe dragons in there i'm not aware of
<bugg> oops
<bugg> don't kill tmux
<magicaltrout> I'll spin it up in AWS next week lazyPower and let you know if anything starts crying
<magicaltrout> looking forward to it, not sponsored an event before. Gonna take along a bunch of Juju stuff, K8S, build pipelines for auto build and deployment, data processing etc
<magicaltrout> see if it gets any love
<magicaltrout> sam is going to sort me out with some marketing stuff as well now I have the master services agreement signed
<lazyPower> nice
<lazyPower> you should get some love with that stack, being able to deploy it and demonstrate it at the drop of a hat is a nice feather to have on your tail
<stokachu> aluria, can we get the review queue in the topic changed to review.jujucharms.com?
<aluria> jam, jcastro: ^
<aluria> stokachu: I'm not a jujudev -- but cheers :)
<stokachu> ah just showed you the last person to update the topic
* jcastro changed the topic of #juju to: Welcome to #juju || Review Queue: http://review.jujucharms.com || Summit: http://summit.jujucharms.com
* jcastro changed the topic of #juju to: Welcome to #juju || Review Queue: http://review.jujucharms.com || Summit: http://summit.jujucharms.com || Docs: http://jujucharms.com/docs || FAQ: http://goo.gl/MsNu4I || Youtube: https://www.youtube.com/c/jujucharms
<Teranet> ok who has Openstack on Juju experiance ? I do have an contrainer issue and don't know how to tackle it
<stokachu> jcastro, thanks
<pmatulis> Teranet, just ask a well-formulated question and see if someone can answer
<admcleod_> Teranet: whats the issue?
<Teranet> HI I do have a hook error which I don't know how to fix : hook failed: "cloud-compute-relation-changed" for nova-compute:cloud-compute
<Teranet> THis is on Nova-Cloud-Controller
<Teranet> and also neutron-gateway is blocked
<Teranet> all other container look green and ok
<kwmonroe> Teranet: does debug-log give you any more details? "juju debug-log --replay" will give you the whole log; if that's too much info, you can restrict it to unit with "juju debug-log -i unit-nova-compute -XX --replay", where 'XX' is the unit number of your failing unit.
<kwmonroe> er, that should be "-i unit-nova-compute-XX" <-- no space between the unit and unit number
<admcleod> Teranet: if you find anything with kwmonroe 's suggestion could you pastebin and give us the link?
<Teranet> yes ofcourse sorry totally alseep today up since 4AM :-(
<Teranet> Here is the pastbin result : http://paste.ubuntu.com/23788886/
<Teranet> and it's now clear to me what the real issue is
<Teranet> it's like persistant but not willingly to tell me what's wrong with it.
<Teranet> new link : http://paste.ubuntu.com/23788899/
<Teranet> I added a full status overview of the juju containers as well
<Teranet> it's just I am pulling my hair out because I don't really see how to see the real error or how to fix it. :-(
<Teranet> Which drives me crazy
<admcleod> teranet: if you "juju ssh" to one rabbit node, can you ping the hostname of the other rabbit node?
<Teranet> Yes don't worry about rabbitMQ for now
<Teranet> that's a man mad issue :-)
<admcleod> Teranet: well it looks like a problem with reverse dns on the nova cloud controller node, you might also want to ask the same question / paste the logs in openstack-charms
<kwmonroe> yeah Teranet, #openstack-charms might be better a better place.. admcleod, just out of morbid curiosity, does nova-cloud-controller :: nova-compute have the same nonsensical rev dns requirement that namenode :: datanode has?  any way to be "ip-only" in an openstack env?
<admcleod> kwmonroe: i think there is a requirement for forward and reverse to work and match up
<admcleod> kwmonroe: so.. i assume, dont know for sure, even if you used IP's it would do both checks
<elbalaa> hi all, is juju dead?
<Teranet> what forward and revers ?? Juju don't control DNS nor does MAAS or OpenStack
<kwmonroe> elbalaa: my juju lives.  strong like bull.
<admcleod> Teranet: the hook is failing because of an NXDOMAIN error
<kwmonroe> Teranet: line 220 of your first paste
<Teranet> where do you see the NXDOMAIN ?? ok let me check
<admcleod> Teranet: also i think MAAS should be handling the DNS
<admcleod> Teranet: but i have very little maas knowledge
<Teranet> Maas only does do DHCP but won't do DNS
<Teranet> our Corp is to big and complex which does not allow dynamic DNS
<admcleod> Teranet: are you following any particular set of instructions for this deployment?
<admcleod> Teranet: https://github.com/conjure-up/conjure-up/issues/487
<Teranet> Yes I do follow the last OpenStack/Ubuntu deployment setup which I rewrite right now for Cluster Enviroments like we use at Rackspace and IBM right now
<admcleod> Teranet: i was wondering what that setup mentions about DNS. also see the link i just posted
<admcleod> elbalaa: is that a philosophical question?
<Teranet> ... one sec let me check
<Teranet> I don't see where to repoint DNS to MAAS I do see certain records in MAAS DNS but that's it
<elbalaa> admcleod: wow juju does windows
<admcleod> Teranet: just before you said 'maas only does do DHCP but won't do DNS' - has it been disabled? you may also want to ask about this in #maas.
#juju 2017-01-13
<rmcadams> juju makes me want to bang my head on the desk sometimes :)
<kjackal> Good morning Juju world!
<spaok> heya, is there a way to force juju 1.25 to use a particular controller?
<Spaulding> Hi folks!
<Spaulding> https://gist.github.com/pananormalny/11144709446aa80e956d7977df3d88d1 anyone know how to run it just once? @only_once seems to be not working here...
<magicaltrout> only_once is really a thing?!
<Spaulding> also i have no idea what is the best way to check if db is already filled, should I check that some tables exists or there is some other fancy way of doing this
<magicaltrout> so it is
<magicaltrout> I don't know how fixed it is Spaulding but a issue here says:
<magicaltrout> "Another consideration that needs to be documented because it is very non-obvious is that, because of an implementation detail, @only_once must be the innermost decorator, if combined with @when, etc."
<magicaltrout> yours is the outer most
<magicaltrout> :)
<Spaulding> omfg
<Spaulding> let's try it then :)
<magicaltrout> i know... my google-fu is amazing on a Friday
<Spaulding> haha
<Spaulding> friday the 13th
<magicaltrout> shit
<magicaltrout> i didn't even notice
<Spaulding> so now you know ;)
<Spaulding> your magic abilities works even today!
<BlackDex> hello there
<BlackDex> i used juju with maas and i created several network aliasses on one vlan/interface
<BlackDex> maas deploy's it correctly
<BlackDex> i can access the servers on every network
<BlackDex> but when i let juju generate lxd's on these hosts, they only receive one ip
<Zic> hi here, I'm (always) testing canonical-kubernetes bundle charms, and I test to shut an etcd member to see if the 2 others deployed by default will be hurted
<Zic> when I shut the etcd/1 or etcd/2 it's fine
<Zic> but if I shut etcd/0, the cluster go unhealthy
<magicaltrout> lazyPower: one for you -^
<lazyPower> Zic which versin of the etcd charm?
<Zic> have you any idea about this issue?
<Zic> charm: cs:~containers/etcd-21
<lazyPower> I have done disaster testing where we tear down nodes, and i haven't encountered this behavior.  Is the broken deploy still around? Can you collect the logs from one of the etcd nodes thats failing after you've destroyed etcd/0?
<Zic> yep, I collected it, it just try to relink to the etcd/0 in loop (nothing unexpected) : http://paste.ubuntu.com/23792623/
<Zic> I have the same type of message if I shut etcd/1 or etcd/2, but the cluster stay healthy and Kubernetes cluster is working
<Zic> but if I shut etcd/0, all kubectl or even the kubernetes-dashboard is dead, with a "etcd cluster unhealthy or misconfigured" error message
<lazyPower> oh Zic  i know what happened here. it looks like the etcd cluster lost quorem and didn't re-elect a new master because it couldn't reach consensus via the 2 nodes that were still active, and not acting as coordinator
<Zic> lazyPower: oh, it seems logic, but how can I prevent that ?
<lazyPower> Zic juju add-unit etcd -n 2  -- that will bring the total number of etcd units to 5, and you should be able to test the disaster recovery at that point
<Zic> note that I put etcd on the same machine that's running kubernetes-master charm, instead of the default model where etcd is running alone in a machine
<Zic> don't know if it's a safe way
<lazyPower> Zic thats not recommended for production deployments :)
<magicaltrout> etcd needs to man up and make a decision! ;)
<lazyPower> as etcd is the core database tracking the state of your cluster.
<Zic> yeah, but I scale 3 kubernetes-master
<Zic> (and test kube-api-loadbalancer ;))
<lazyPower> but its fine to colocate etcd for testing purposes
<Zic> even if I run through 3 kubernetes-master, do you recommend to put etcd separately ?
<Zic> to put it correctly: the default model deploy 1 kubernetes-master, 1 etcd, 1 etcd, 1 etcd
<Zic> I add two more kubernetes-master, and place etcd charms alongside
<Zic> is it a poor design choice for production cluster? :|
<lazyPower> i think thats fine
<lazyPower> extend the etcd cluster onto those principal units, 3 independent, 2 shared
<lazyPower> where 2 is N really
<Zic> lazyPower: thanks, I will try that
<Zic> bonus question: is kube-api-loadbalancer really experimental? I hesitate to run it for production environment, bus as I lurked in what it is doing, it's just an automatically configured nginx which act as reverse-proxy
<Zic> s/bus/but/
<lazyPower> Zic we've found some interesting behavior with the proxy, there's still some tuning to do before we can call it GA
<lazyPower>  it works well, and needs no further tuning in 90% of the scenarios in which its deployed
<lazyPower> but if you're using addons like HELM, we've found that it doesn't work when routed through the LB
<Zic> lazyPower: 5 etcd units in total permits what fault-tolerance? 2 nodes down as they stay 3 to make a quorum decision?
<lazyPower> Zic https://coreos.com/etcd/docs/latest/v2/admin_guide.html
<lazyPower> see the table under Optimal Cluster Size
<Zic> oh yeah, I found this link yesterday and forgot it, sorry :)
<lazyPower> Zic no worries :) I just find it useful to spot check my own knowledge against their upstream docs
<lazyPower> it keeps me honest
<Zic> :)
<magicaltrout> nooo lazyPower make him pay!!!!
<magicaltrout> make him paaaaaaaay!
<magicaltrout> sorry, friday.
<lazyPower> and according to magicaltrout you owe us pizza and beer... because we posted links.
<lazyPower> and he pinged me
 * lazyPower pokes magicaltrout 
<magicaltrout> \o/
<magicaltrout> marcoceppi_: i should be in DC in the last week in March
<magicaltrout> consider yourself warned
<magicaltrout> conference season hasn't even started and i'm already juggling trips
<Zic> true! come in France, but I must warn you, we don't have good pizzas (and our 'good' bear is tolen from Belgian neighbors)
<magicaltrout> i was in Paris last year, that was fun
<lazyPower> Zic i'll gladly take your belgian brews
<magicaltrout> hehe
<magicaltrout> wise lazyPower you need to get practicing ;)
<lazyPower> practicing what exactly?
<magicaltrout> drinking 15% beer for Ghent ;)
<lazyPower> dear lord
<lazyPower> i am not ready
<lazyPower> magicaltrout you have lofty goals ;)
<magicaltrout> its always achievable... just requires dedication and practice... and the distinct possiblity of doing talks whilst still drunk
<lazyPower> That would clearly follow in the footsteps of my hero Jamie Windsor
<lazyPower> i think it was chef conf 2012, where he took the stage blitzed and tried to run a live siri-controlled infra deploy and it failed fantastically. RIP that demo, but it certainly was memorable
<magicaltrout> lol
<Zic> hehe, here we use Puppet generally... but for some new projects (like K8S) we're testing Juju :)
<Zic> lazyPower: if I don't care about ressources, do you advice me to split up etcd from machines which already host kubernetes-master? or staying with 3 kubernetes-master+etcd and 2 others etc separately is also fine? (more question more beers, I know :()
<lazyPower> i do, i think its the best strategy to keep them out of the kubernetes units themselves for instances of scale
<lazyPower> if you colocate etcd with kubernetes-master-3,4,5 for example
<lazyPower> and your cluster goes dormant, and you remove master-4,5
<lazyPower> you'll still have tainted machines running with those etcd units
<lazyPower> Plus, in juju land, when you colocate services (we call this  hulk-smashing), it *can sometimes* have unintended behavior, like say we add an addon that requires an isolated etcd container to be running... (i'm looking @ you CNI networking providers)
<lazyPower> if you've got a colocated etcd unit on that node, you'll hit port collision
<Zic> ok, good advices, I will apply them :)
<lazyPower> and in some cases, it will cause the addon workload to fail
<spaok> so, my juju is broken badly, mongo won't cluster and keeps restarting, I can't issue ensure-availability, I tried restoring a lxc snapshot but the last two didn't help, before I try something drastic, like restoring the first snapshot (removing the newer to do so) anyone have any ideas how I might recover?
<lazyPower> spaok have you been able to collect the logs from your container? which juju version?
<spaok> should be 1.25
<spaok> its an older install we are trying to decomm, but juju broke so it making that harder
<lazyPower> yeah, thats a rough situation. sorry spaok i'm not certain how to resolve mongo clustering issues but i would lead with a bug with those logs so we can attempt to triage, but it sound slike you're on a time table
<magicaltrout> friday is here \o/ gin o'clock
<magicaltrout> this ones for you kwmonroe https://youtu.be/u6mJMJzDD-M?t=1m13s
<kwmonroe> no way i'm clicking that
<magicaltrout> lol
<magicaltrout> its music! :P
<magicaltrout> it popped up on spotify on the way home and made me think of you
<kwmonroe> ugh.. fine.  i'll click it.
<kwmonroe> ha!  i like it.  you're back on my nice list magicaltrout!
<magicaltrout> lol
<magicaltrout> thanks :P
<elbalaa> spaok: did you try sshing into the mongo machine and looking at the logs?
<spaok> elbalaa: ya there was some corruption or something, mongo would try to cluster and then restart
<spaok> we were able to finally find a mix between a previous snapshot and turning off the repl
<spaok> then recovering from there
<spaok> so it's up enough that we can finish the decomm process
<elbalaa> spaok:  "corruption or something" story of my life when working with mongo
#juju 2017-01-14
<spaok> is there a channel for lxd type of questions?
<rmcadams> just a longshot, has anyone found a work around for https://bugs.launchpad.net/juju/+bug/1633788
<mup> Bug #1633788: juju 2.0.0 bootstrap to lxd fails (connect to wrong "remote" IP address) <canonical-is> <juju> <lxd> <lxd-provider> <s390x> <uosci> <OpenStack Charm Test Infra:Confirmed> <juju:Triaged by rharding> <https://launchpad.net/bugs/1633788>
<spaok> anyone know what this error is from? INFO install subprocess.CalledProcessError: Command '['network-get', '--primary-address', 'data']' returned non-zero exit status 1
<spaok> the charm is failing to install
<ejat> can maas 2.0 and juju 2.0 works to build Canonical OpenStack Autopilot?
#juju 2017-01-15
<pmatulis> ejat, you can install autopilot with juju. autopilot can then be used to install openstack, normally by pointing it at an existing maas
<ejat> pmatulis: got charm for autopilot ?
<rmcadams> Is there an option, when bootstrapping juju, to tell it an address to use, in order to combat https://bugs.launchpad.net/juju/+bug/1633788? - It doenst matter what version of LXD or juju I'm using, I keep hitting this bug when bootstrapping it to a localhost container.
<mup> Bug #1633788: juju 2.0.0 bootstrap to lxd fails (connect to wrong "remote" IP address) <canonical-is> <juju> <lxd> <lxd-provider> <s390x> <uosci> <OpenStack Charm Test Infra:Confirmed for 1chb1n> <juju:Triaged by rharding> <https://launchpad.net/bugs/1633788>
<pmatulis> ejat, autopilot is landscape. sorry for not being clear
<pmatulis> ejat, so search jujucharms.com store for landscape charm
#juju 2018-01-08
<jam> bobeo: are they at the same IP address that they were before? you can look at ~/.local/share/juju/controllers.yaml and see if the IP address matches the controller macihne.
<jam> bobeo: the other option is something like "ufw" that was manually stopped on a machine that is now blocking remote access, or something like that.
<gunix> stokachu: are online now? :D
<stokachu> gunix: yep, whats up
<stokachu> hbogert_: /win 3
<stokachu> hbogert_: sorry, i meant to ask why are you disappointed?
<stokachu> hbogert_: also logging into IRC as root isn't usually a good idea
<jose-phillips> hi
<jose-phillips> any way to check issues on juju charm
<jose-phillips> juju deploy /pathofcharm package
<jose-phillips> keeps on waiting
<jose-phillips> status
<kwmonroe> jose-phillips: can you tell what it's waiting for?
<jose-phillips> when i do juju status
<jose-phillips> i see on application
<jose-phillips> keeps on waiting
<kwmonroe> jose-phillips: what are you deploying?
<jose-phillips> a custom charm
<jose-phillips> that i do based on solidfire charm
<kwmonroe> jose-phillips: try "juju status --format yaml <name-of-charm>"
<kwmonroe> sometimes the yaml output will give more output about why the charm is waiting
<jose-phillips>       message: waiting for machine
<jose-phillips> better :")
<jose-phillips> ls
<kwmonroe> jose-phillips: where are you deploying? aws/local/etc?
<jose-phillips> local
<jose-phillips> should be deployed on cinder container
<kwmonroe> jose-phillips: waiting for machine typically means juju can't find a place to deploy given a set of constraints.  is this local with lxd or maas?
<jose-phillips> local with lxd
<kwmonroe> jose-phillips: the important bit to figure out is why juju can't find a machine to deploy to... maybe the charm has a constraint that can't be fulfilled by your controller (mem=X, etc)
<jose-phillips> ok question
<kwmonroe> unfortunately, i need to get outta here like 2 minutes ago -- pastebin a 'juju debug-log --replay' and i can try to help diagnose later
<jose-phillips> if on metadatada
<jose-phillips> have few tags
<jose-phillips> is will going to use these tags rights?
<jose-phillips> done
<jose-phillips> was a missing relation
<jose-phillips> thanks anyways
#juju 2018-01-09
<thumper> jose-phillips: the tags in the charm metadata are only for finding related things in the charm store
<thumper> they aren't used for deployment at all
<gunix> stokachu: i have some questions regarding kubernetes
<stokachu> gunix: go for it
<bobeo> hey guys! made a change via juju with juju configure osd osd-devices='devices names' and it updated my osds, but now my ceph mons keep showing error due to the changes. rebooted them, but they still didnt correct. Is it broken, or do I need to clear the error?
<bobeo> how do I find all the options a spcific charm has
<bobeo> I am specifically looking to see al the juju config options I have available to me with the openstack base charm
<hml> you can find on the charmâs page in the charm store
<hml> or if itâs installedâ¦ with juju config <application>
<bobeo> hml: I dunno. im there now. all it has is the ability to expand on the current server counts, and a few modest options wth additional features
<bobeo> hml: yea I tried that. juju config ceph-osd
<bobeo> but it didnt tell me the options available to ceph-osd
<hml> openstack-base is a bundle
<hml> so most of the setup is done
<bobeo> ignore me
<bobeo> I forgot to hit <enter>
<hml> :-)
<bobeo> im a special case today :(
<bobeo> Im so tired. we are so close on this project, and three last minute work stops
<hml> thatâs never fun
<bobeo> first was the firewall almost being eaten, then the firewall being pissy, understably mind you. id be mad bro too if you tried to eat me. now console access isnt loading for openstack instances
<bobeo> i feel like im missing somethn small, but its major if forgotten.
<hml> iâd check with the openstack-charms folks perhaps?
<bobeo> I wish we could just cut a check to get this last piece finished
<bobeo> we are all so tired x...x
<gunix> stokachu: do you have any tutorial about deploying kubernetes on bare metal, with dedicated management network and nic redundancy?
<stokachu> tvansteenburgh: ryebot kjackal knobby ^
<ryebot> gunix: No, nothing that specific. Have you attempted on your bare metal cluster with MAAS+CDK and run into a problem?
<magicaltrout> graping at straws here "container runtime is down,PLEG is not healthy"
<magicaltrout> anyone seen that on a CDK install?
<gunix> ryebot: no, we are planning to run openstack bare metal and kube on top of that just because it is easy to implement
<gunix> but kube bare metal is far better
<ryebot> gunix: Alright. Well, best I can advise is to try out our standard installation and let us know if you run into any issues.
<ryebot> magicaltrout: No; is that an error from kubelet?
<gunix> ryebot: what do you mean by standard installation?
<ryebot> gunix: https://jujucharms.com/canonical-kubernetes/
<gunix> i tried the lxd one
<gunix> but some of the stuff failed after intall, so i tried rancher instead
<ryebot> What stuff failed?
<gunix> I can't remember exactly, it was about a month ago
<gunix> kubernetes deployed but i think grafana or heapster failed, or both
<ryebot> gunix: If you try it again and still hit issues, flag me down and I'll try to help you out.
<gunix> and it displayed a few links with stuff, like stuff you could access through kubernetes proxy, but none of the links work :D
#juju 2018-01-10
<fatgoose> anyone know how to get the kube-controller-manager log from a k8s (the canonical distribution of kubernetes) deployment?
<fatgoose> where is it on the master node?
<thumper> unfortunately many of the k8s charmers are in the USA and past EOD
<tvansteenburgh> if fatgoose comes back, the answer is:
<tvansteenburgh> juju ssh kubernetes-master/0 -- journalctl -o cat -u snap.kube-controller-manager.daemon.service
<magicaltrout> docker crashes when removing containers \o/
<rick_h> magicaltrout: howdy, and :(
<rick_h> magicaltrout: I wanted to make sure you saw https://blog.jujugui.org/2018/01/03/accessing-the-juju-cli-from-within-the-gui/ and see if your folks had a chance to try it out
<rick_h> have to pull the plug on the juju show due to some issues on my end today folks. Apologies for all of you looking forward to hearing my dulcet tones again after the new year
<kwmonroe> bummer rick_h - i have wicked allergies today and was hoping to have an opportunity to blow my nose on youtube.
<rick_h> kwmonroe: lol sorry man
<jhobbs> is there a way to show the current space bindings for an application?
<thumper> jhobbs: does it show in the yaml status?
<jhobbs> no thumper
<kwmonroe> jhobbs: does 'juju list-spaces [--format yaml]' show the apps for each space?
<jhobbs> kwmonroe: no
<kwmonroe> i don't have an env to test atm, but i'll keep my fingers crossed that it does
<kwmonroe> doh
#juju 2018-01-11
<jose-phi_> exist a way
<jose-phi_> when juju deploy a container
<jose-phi_> to setup the network from juju?
#juju 2018-01-12
<skay> where's upstream of django-layer-base? I forked it from somewhere and github isn't showing where I forked it from
<rick_h> skay: hmm, I think that's bdx's work
<skay> I can't even remember why I forked it
<skay> someone's been giving me PRs and I want to point them to upstream
<rick_h> bah, don't see it in his GH but might be under a different org so not sure.
<skay> rick_h: I found one in omnivector
<skay> is he part of that?
<rick_h> yes!
<rick_h> yea, I see the sentry stuff in that namespace he was working on
<skay> rick_h: thanks! I contactd github to ask them to link up my repo as a fork
<skay> bdx: I had a brainfart and merged a couple of requests from someone to my repo. I've asked the contributor to submit them to your repo. https://github.com/codersquid/layer-django-base/pulls?q=is%3Apr+is%3Aclosed
<skay> bdx: ah, the vanishing fork solved. I forked an old repo of yours that no longer exists. someone from github got back to me to explain this.
<catbus> Hi, is there a way to update the maas endpoint in the juju cloud settings? maas cloud is added then the endpoint is changed.
<catbus> the 'update-cloud' seems to work with only public clouds.
<freyes> catbus, you could update it manually in ~/.local/share/juju/clouds.yaml
<catbus> I did. juju is still trying to reach the old maas endpoint.
<catbus> freyes: ^^^
<catbus> juju show-cloud shows the new endpoint that I manually modified. juju destroy-controller --destroy-all-models throws the error that it can't reach maas at the old endpoint.
<freyes> catbus, ah, an already deployed environment, that's stored in mongodb, you would need to edit the database manually
<freyes> I don't know what the specific collection where that information is stored, sorry :\
<catbus> freyes: no problem. working on database directly is too much. Do you happen to know if I can kill the controller, remove the maas cloud setting in juju, and manually release the machines in this order?
<freyes> catbus, yes you can, and if you update clouds.yaml first, I think the kill-controller will be able to reach maas to release the nodes
<catbus> ok, will give it a try.
<freyes> kill-controller makes the client (the one running in your laptop) talk to the cloud provider directly
<catbus> freyes: kill-controller failed for the same error, not able to reach the old maas endpoint..
<catbus> ERROR getting controller environ: getting environ using bootstrap config from client store: Get http://<old endpoint> i/o timeout. So the config in the controller needs update.
<freyes> catbus, try editing bootstrap-config.yaml
<catbus> cool
<catbus> I think it's working. I see 'will kill machines directly in 4m5s'.
<catbus> freyes: the juju controller node is released successfully, but not the rest. it does say 'manual intervention may be necessary to ensure resources are released.' I will manually release them via maas. Thanks!
<freyes> catbus, probably it couldn't get the list of nodes associated with that controller
<freyes> catbus, yw ;)
<hml> catbus: you can change the maas endpoints with juju add-cloud âreplaceâ¦ instead of editting the file though iâm not sure what happens with an exsiting controller
<catbus> hml: oh, will try --replace next time. Didn't know it. I have killed the controller, so my guess is if I bootstrap again, it will use the new settings that I manually modified.
<hml> yes
<catbus> hml: shouldn't this fall in 'update-cloud'?
<hml> update-clouds is for public cloud info.
<hml> you had to do an add-cloud to setup the maas cloudâ¦
<hml> though it is a little weird to do an add-cloud to change it perhaps
<catbus> hml: right, that's what I meant. The doc is clear that update-clouds is for public cloud only, but for maas, you have to use add-cloud --replace to update.
<hml> catbus: iâm not clear on your question then, can you expand on it please?
<catbus> hml: It's not a question. I just echoed what you said that though it is a little weird to do an add-cloud to change it perhaps. I know update-clouds is for public cloud only, clear from the juju doc.
<hml> :-)
#juju 2020-01-06
<wallyworld> babbageclunk: here's a small juju/os PR https://github.com/juju/os/pull/17
<babbageclunk> wallyworld: ok, taking a look
<wallyworld> babbageclunk: ty, disco support runs out on 18th jan
<babbageclunk> oh right
<wallyworld> babbageclunk: and here's the tiny juju dep update https://github.com/juju/juju/pull/11068
<babbageclunk> wallyworld: no Gopkg.lock change?
<babbageclunk> wallyworld: approved
<wallyworld> babbageclunk: yeah, i forgot to push it, sorry
<babbageclunk> nw
<wallyworld> babbageclunk: hopefully last one, https://github.com/CanonicalLtd/juju-qa-jenkins/pull/356
<babbageclunk> wallyworld: lgtm!
<wallyworld> ta
<wallyworld> now to generate jobs
<wallyworld> tlm: can i get a +1 on a unit test fix? https://github.com/juju/juju/pull/11070
<tlm> yep
<tlm> done, maps have order :|
<wallyworld> great ty
<stickupkid> achilleasa, can you CR https://github.com/juju/cmd/pull/74
<achilleasa> stickupkid: I will take a look in about 20min if that's OK
<stickupkid> achilleasa, sure nps
<Harm133> Hi guys, I'm trying to bootstrap OSM via juju but am getting this error: ERROR failed to bootstrap model: cannot start bootstrap instance in availability zone "my-juju-machine": no matching image found
<Harm133> Command used: sudo juju bootstrap localhost osm
<rick_h> Harm133:  hmm, is there something setup in the .local/share/juju/clouds.yaml that has that "my-juju-machine" in there?
<Harm133> There is no clouds.yaml file in that folder
<Harm133> hmm, I deleted the folder
<Harm133> Now I have something I can work with, a timeout error regarding the clouds.syaml file
<stickupkid> Harm133, example of the error ?
<Harm133> Hmm, I'm getting this now :
<Harm133> ERROR failed to bootstrap model: cannot start bootstrap instance in availability zone "my-juju-machine": Failed remote image download: Get https://cloud-images.ubuntu.com/releases//streams/v1/index.json: Unable to connect to: cloud-images.ubuntu.com:443
<Harm133> while a curl towards that URL works fine
<rick_h> Harm133:  hmm, so that's probably coming from the lxd container that's started up so it might be an issue with lxd containers reaching the outside world?
<Harm133> that could be, can I pass a proxy towards the container?
<rick_h> typically you'd adjust the bridge on the host I believe. There are proxy settings you can set in bootstrap config if you need to for https and such
<Harm133> I've altered the env on the host but that does not seem to work, how would one go about configuring proxy settings within the bootstrap config?
<Harm133> Got it, lxc config set core.proxy_https / lxc config set core.proxy_http
<hml> stickupkid: youâre too fast!  :-D.
<hml> stickupkid: didnât get a chance to link my results.  ha
<hml> stickupkid: ty!
<stickupkid> hml, was waiting for a thing to land :D
<stickupkid> hehe
<hml> stickupkid: ha!
<stickupkid> wow, if you don't have a credentials yaml file, all hell breaks loose in the CLI
<rick_h> stickupkid_:  yea...hitting that with these demos
<rick_h> and if you don't have the cloud forget credentials
<stickupkid_> hml, if you get a chance, no rush though - https://github.com/juju/juju/pull/11072
<hml> stickupkid_: ack
<bdx> hello, happy new year!
<bdx> does anyone know if there is a way to migrate a model into jaas from a non-jaas/local auth juju controller
<bdx> ?
<bdx> guessing this probably can't be done - due to the users of the model needing to match in the source and target controllers
<rick_h> bdx:  yea, it can't be done but more because I don't think JAAS supports model migrations due to it thinking it's one controller vs multiple
<bdx> ok
<rick_h> bdx:  it might be doable by a JAAS admin user if they had full access to the local model, but would be a test
<rick_h> bdx:  what's a good bundle that shows off a service with different bits to it that's not a platform like openstack, k8s?
<bdx> https://paste.ubuntu.com/p/zJ5VQ49446/
<rick_h> bdx:  hah good stuff
<bdx> killed 2/3 juju controllers in aws yesterday after having recreated the infrastructure in jaas
<rick_h> yay?
<bdx> one of them was the longest lived instance in our aws account
<bdx> yeah
<rick_h> nice
<bdx> yeah - no reason other then to cut down on our operational costs
<rick_h> yea, that's good stuff though
<bdx> totally
<bdx> this graylog model on this controller cant be spun down and recreated as easily as the others
<bdx> so I was hoping there might be a way to migrate it into jaas so I could finsh off 3/3 :)
<rick_h> yea, I wish but not quite
<bdx> not a big thing ... but if someone is down to poke at it for a few minutes I can create a sample model for them
<bdx> totally
<hml> babbageclunk:  https://github.com/CanonicalLtd/juju-qa-jenkins/pull/359 pls?  nice and short
<babbageclunk> hml: looking
<babbageclunk> hml: approved
<hml> babbageclunk: ty
<cory_fu> wallyworld: You around?
<cory_fu> Or kelvinliu?
<kelvinliu> hi cory_fu:
<kelvinliu> how can i help u
<cory_fu> kelvinliu: I'm getting an unexpected error on a CMR with a k8s charm and I was hoping you could help me understand what's going on.
<cory_fu> kelvinliu: https://pastebin.ubuntu.com/p/7wHvXy3Nf4/
<cory_fu> That works fine when not using a cross-model relation
<cory_fu> I'm also surprised that the unit name is not replaced by the UUID like it is in non-k8s charms.
<kelvinliu> cory_fu: mind share the bindle or how did u relate the cmr
<cory_fu> kelvinliu: Well, I hit this while testing https://github.com/johnsca/charm-gitlab-k8s using the new framework, along with cs:~charmed-osm/mariadb-k8s.  For the CMR case, I just did a separate model in the same k8s cloud and did a normal offer / consume.
<cory_fu> SAAS         Status  Store     URL
<cory_fu> mariadb-k8s  active  microk8s  admin/other.mariadb-k8s
<kelvinliu> ok thanks
<kelvinliu> I will take a look and let you know i found. ty cory_fu
<cory_fu> Ok, thanks
<kelvinliu> np
<wallyworld> cory_fu: i would have thought it would give the uuid also. there's no difference in k8s vs cloud in how cmr works so it does seem weird. it maybe well be a latent bug
#juju 2020-01-07
<thumper> https://github.com/juju/juju/pull/11076 for anyone wanting a simple PR to review
<kelvinliu> thumper: lgtm ty
<thumper> kelvinliu: thanks
<kelvinliu> np
<wallyworld> babbageclunk: i've updated https://github.com/juju/juju/pull/11071 with the correct fix, just re-testing now
<wallyworld> would be awesome if you could take another look
<wallyworld> tlm: for QA steps, you should also run juju controller-config to check the value and also test updating it
<tlm> wallyworld: ta, just found a bug with it as well. Will update all in a sec
<wallyworld> ok
<thumper> wallyworld: package move https://github.com/juju/juju/pull/11077
<wallyworld> ok
<wallyworld> thumper: can't see any issues
<thumper> wallyworld: I'm running the tests locally as well to ensure everything builds and passes
<wallyworld> sgtm
<tlm> wallyworld: all updated
<wallyworld> righto
<wallyworld> tlm: i've left a couple of things to look at, let me know if anything is unclear
<tlm> cheers
<tlm> wallyworld: sent you a private message just in case notifications are still off
<babbageclunk> wallyworld: ok looking
<wallyworld> ta
<wallyworld> kelvinliu: i have a trivial forward port of 2.7 into develp https://github.com/juju/juju/pull/11078
<kelvinliu> wallyworld: lgtm ty
<wallyworld> ta
<wallyworld> tlm: also forgot to mention sorry, the controller name PR should be targetted against develop not 2.7
<tlm> np will shift it around
<thumper> wallyworld: have we fixed the bootstrap / upgrade issue that we were hitting with the build number?
<wallyworld> thumper: that's the PR that babbageclunk is looking at currently
<thumper> sweet
<stickupkid> getting nothing past hml, yesterday - haha
<zeestrat> Any news on a new libjuju release?
<stickupkid> zeestrat, doing it now
<stickupkid> :D
<zeestrat> Yay :D
<stickupkid> zeestrat, just catching up on what the changes are
<stickupkid> manadart, you around?
<manadart> stickupkid: Yep.
<stickupkid> quick ho?
<manadart> Sure.
<stickupkid> manadart, CR please https://github.com/juju/python-libjuju/pull/378
<stickupkid> zeestrat, hopefully we can verify that everything is fine so that 2.7.0 can go out https://github.com/juju/python-libjuju/pull/378
<stickupkid> zeestrat, I ran against this, but manage to mitigate this issue luckily https://github.com/juju/python-libjuju/issues/377
<stickupkid> manadart, when you get time https://github.com/juju/juju/pull/11067
<manadart> stickupkid: Yep.
<manadart> stickupkid: Got a sec to HO?
<nammn_de> anyone  quick cr? https://github.com/juju/juju/pull/11079
<manadart> nammn_de: Done.
<nammn_de> manadart: thankso!
<stickupkid> manadart, i'm in daily
<stickupkid> watching you eat
<roadmr> hey folks, how do I get a leaderless applicatin to get a leader?
<roadmr> [INFO] canonical-livepatch does not have a leader <- appears repeatedly and juju status indeed shows no unit for that application with the nice asterisk *
<rick_h> roadmr:  hmmm, can you check the logs to see if there's a reason no one's winning leadership?
<rick_h> roadmr:  the cases we've seen with this in the past has been more leader stomping where it's taken more than the time allotted for the leader hook to run and someone else tries to get it and the first one gives up
<stickupkid> zeestrat: 2.7.0 is released https://discourse.jujucharms.com/t/pylibjuju-2-7-0-release-notes/2489
<stickupkid> zeestrat, we had to bump the facades to 2.7.0, which was a bit of a pain, but now it's done the release went smoothly :D
<stickupkid> let us/me know if you hit any issues
<rick_h> gnuoy:  ^
<rick_h> thedac:  ^ /me can't recall who wanted it
<gnuoy> rick_h, me ! it was me !
<gnuoy> thanks
<zeestrat> stickupkid: ty very much! We'll let you know :)
<thedac> rick_h: stickupkid: thanks, I'll spread that knowledge to my team.
<cmars> roadmr: wondering if https://bugs.launchpad.net/juju/+bug/1853055 is related to your issue
<mup> Bug #1853055: "ERROR could not determine leader" but `juju status`  says there is a leader <juju:New> <https://launchpad.net/bugs/1853055>
<cmars> although your status shows a leader?
<cmars> one thing i've had to do to work around that, is scrape the json status for the unit that shows "leader" and address that unit specifically
<cmars> maybe see what juju status --format yaml (or json) shows
<roadmr> cmars: no, we see no leader :(
<roadmr> rick_h: 2020-01-07 15:28:36 INFO juju.worker.leadership tracker.go:217 canonical-livepatch leadership for canonical-livepatch/2 denied (no further explanation as to why)
<cmars> anarchy!
<roadmr> cmars: exactly what I said :)
<roadmr> on some units I see "2020-01-06 14:28:25 DEBUG juju.worker.leadership tracker.go:125 canonical-livepatch/1827 making initial claim for canonical-livepatch leadership" right before the above
<stickupkid> hml, I've updated https://github.com/juju/juju/pull/11072
<hml> stickupkid: approved
<stickupkid> ta
<nammn_de> achilleasa: quick cr? https://github.com/juju/charmrepo/pull/158
<achilleasa> nammn_de: looking
<nammn_de> rick_h: i have made the patch as small as possible. This now should mostly enhance bash completion ux https://github.com/juju/juju/pull/11032/
<rick_h> nammn_de:  k, let's try it
<rick_h> roadmr:  can you file a bug please?
<nammn_de> rick_h: thanks! something special needed to put that into  edge beside just merging it? I did  quite a lot of local testing and I don;t see any reason why this should make it worse... :D
<rick_h> nammn_de:  no, just land it in develop and it'll go into edge when our builds get back happy
<rick_h> nammn_de:  and just keep an eye out for any issues
<achilleasa> nammn_de: can I get a quick CR on https://github.com/juju/charm/pull/301?
<nammn_de> rick_h:  will do!
<achilleasa> nammn_de: or stickupkid can someone take a look at https://github.com/juju/juju/pull/11080?
<nammn_de> achilleasa: approved
<stickupkid> hml, there is fallout from my PR around handling outputs correctly, i.e. we put the empty value in stderr and not stdout, can you review my PR https://github.com/juju/cmd/pull/75
<stickupkid> achilleasa, or can you look into it (see above)
<achilleasa> stickupkid: looking
<achilleasa> stickupkid: done
<verterok> rick_h: Hi! regarding roadmr leaderless issue, we have https://paste.ubuntu.com/p/Cp8tbkgHkv/ in the logs
<verterok> cmars: ^
<verterok> even after adding a new unit
<verterok> that logs is from a fresh unit
<rick_h> verterok:  do you know if you're using legacy leases or raft leases?
<verterok> rick_h: this is a IS managed controller, the main one...let me check
<rick_h> verterok:  I'm not seeing "leadership for" in the current code so getting a bug with juju version, where it's at (prodstack I thought moved off leagacy leases but axino can correct me), and model version details would be good please
<rick_h> verterok:  I'm a bit distracted atm but if we can get the details pulled together I can ask someone to investigate
<verterok> rick_h: 2.6.10 in client and model
<rick_h> verterok:  ok, good to know. on prodstack 4.5 you're saying?
<verterok> yup
<axino> features                 []
<axino> no legacy leases !
<verterok> axino: thx
<rick_h> axino:  ok cool ty for the confirmation there
<hml> stickupkid: back, reviewing now.
<hml> stickupkid: or not.  :-)
<verterok> roadmr, cmars, rick_h: this looks pretty similar to what we are seeing: https://bugs.launchpad.net/juju/+bug/1656275
<mup> Bug #1656275: unit leadership gets confused <leadership> <logging> <model-migration> <juju:Fix Released by thumper> <https://launchpad.net/bugs/1656275>
<verterok> but in a version that should have that fix...which points to a regression of some kind
<roadmr> ð±
<_thumper_> verterok: I know that there was additional work later on that
<_thumper_> but I would have thought that it would be in 2.6.10
<verterok> thumper: right, we are seeing a similar symptom: leadership claim -> denied
<verterok> only difference I can guess is that in our case is a subordinate...in case that makes any difference
<thumper> verterok: I am wondering about whether this could be scale and timeout related...
<roadmr> ð¦  <- lots of scales here
<thumper> I just see ð¦
<thumper> that is a rectangle...
<verterok> heh
<roadmr> thumper: haha you copy-pasted the rectangle and I see exactly what I posted :)
<verterok> thumper: the model itself is nothing crazy, 18 machines with same number of canonical-livepatch subordinates
<thumper> verterok: but this is on the shared ps4.5 controller?
<verterok> thumper: yup
<thumper> that has scale
<verterok> indeed
<roadmr> only two things to mention: this env has been up for a loong time and it sees a lot of churn (applications being created/removed very frequently)
<roadmr> since we add a new application on every new code version rollout
<roadmr> that tends to make juju unhappy
<verterok> thumper: anything we could do to recover? is there any way to force a leader?
<verterok> this is blocking rollouts to staging, as we use mojo and it doesn't like to have applications without a leader :)
<thumper> verterok: it looks like raft thinkgs there is probably a leader, but mongo doesn't
<thumper> verterok: we need to work out who raft thinks is the leader
<thumper> you can probably do that with juju run over the app with 'is-leader'
<thumper> then shut down that unit for a minute to force expiration
<verterok> thumper: all return false
<thumper> ah...
<thumper> wat?
<roadmr> verterok: did you file the bug already?
<roadmr> verterok: please please make the bug title "ANARCHY!!!!!!"
<verterok> thumper: https://paste.ubuntu.com/p/RwbDQFyYf3/
<thumper> babbageclunk: thoughts ? ^^^
<verterok> roadmr: didn't file one as I found 1656275
<roadmr> ahh... bummer :(
<thumper> verterok: please file a new one
<verterok> thumper: will do
<thumper> verterok: it is probably a different issue
<roadmr> it is anarchy!!! hahah
<verterok> roadmr: can let you the honors
<verterok> *do
 * roadmr won't pass up the chance to file a silly bug
<roadmr> verterok: hm - we tried restarting juju agents for that application but not the machine-X agents, think it might help?
<verterok> roadmr: I can restart all agents
<babbageclunk> thumper: missed this - reading back
<roadmr> https://bugs.launchpad.net/juju/+bug/1858693 has a summary
<mup> Bug #1858693: ANARCHY!!!!!!! Entirely leaderless application spotted in the wild <juju:New> <https://launchpad.net/bugs/1858693>
<verterok> roadmr: all machine agents restarted, no changes
<babbageclunk> verterok: if you deploy a new application, does the new unit become the leader?
<verterok> babbageclunk: a new application or add-unit?
<babbageclunk> verterok: trying to determine whether all of leadership is broken, or whether there's some kind of pinning happening for that application specifically
<babbageclunk> new application (can be an existing charm but with a new name)
<verterok> babbageclunk: leadership for other applications seems to be fine
<babbageclunk> do you mean, you can see leaders for other applications? Or you've seen leadership change for other applications when the problem has been happening?
<babbageclunk> because the former might not indicate it's fine
<babbageclunk> it might just be stuck in a non-visible way
<verterok> babbageclunk: let me try deploying a trivial ubuntu unit, would that be enough?
<babbageclunk> yup
<babbageclunk> thanks
<verterok> running: juju deploy cs:ubuntu -n 2
<verterok> babbageclunk: I get the leadership * as expected in juju status
<verterok> babbageclunk: and juju run --aplication ubuntu is-leader return True and False as expected
<babbageclunk> verterok: ok - so it sounds like the canonical-livepatch application has leadership pinned?
<babbageclunk> Was there an upgrade-series done at some point?
<verterok> babbageclunk: no upgrade-series AFAIK, the env is old but always in xenial
<babbageclunk> verterok: oh, another useful thing might be to remove the leader unit of the new ubuntu and make sure that the other one eventually claims leadership
<babbageclunk> hmm, that's the only thing that would do a pin that I know of
<verterok> babbageclunk: we do remove units and deploy new ones on each new code revision
<verterok> babbageclunk: which also means killing and spawning new suboardinates (which includes canonical-livepatch)
<roadmr> verterok: 18 units in all, you said? each add/remove has a 20% or so chance of removing the current leader
<babbageclunk> right - which would explain why the leader went away? But not why there's not a new one
<roadmr> (we add 4 units, then remove the 4 old ones)
<verterok> roadmr: right, 18
<babbageclunk> It might be that the raft time isn't being updated, so it's not expiring the old one.
<roadmr> well if elections happened every 3 weeks eventually you'd also want there to not be a leader, right?
<roadmr> (j/k not helping haha)
<babbageclunk> if you kill the leader of the new ubuntu, does leadership switch to the other unit?
<babbageclunk> verterok: ^
<verterok> checking
<verterok> gimme 2'...because I need to deploy them again (killed them too soon :P)
<babbageclunk> ha doh
<roadmr> babbageclunk: where can I check the controller logs? (I assume it's you who asked for those)
<babbageclunk> yeah, that's me
<verterok> roadmr: IS can
<roadmr> ah ok
<verterok> babbageclunk: how long could it take to elect a new leader?
<verterok> ok, after a brief moment of panic, it worked
<babbageclunk> should happen in a minute or less
<verterok> babbageclunk: /4 was leader, and after remove-unit the * is now in /3
<babbageclunk> huh.
<babbageclunk> it's a pain but I'm kind of tempted to suggest you remove and re-add canonical-livepatch.
<verterok> babbageclunk: that was our plan if we needed to unblock deploys
<roadmr> is that a non-suggestion suggestion? :)
<babbageclunk> I mean, it's the tactical nuclear fallback suggestion ;)
<roadmr> if there's nothing else to be gleaned from the current live environment, we might as well
<roadmr> we need to wait for controller logs anyway,if that's where more clues might be
<babbageclunk> Well, I could definitely do with the logs
<babbageclunk> as long as you're ok with waiting
<roadmr> filing the RT
<babbageclunk> but I'm not sure how it could get into this state without the application being pinned.
<roadmr> babbageclunk: do you have a sec to drop by #is in case Alexandre needs more specifics on what to dig for in the logs?
<babbageclunk> sure
<roadmr> (I can triangulate if needed but might be more efficient if you're there)
<verterok> thanks for the help babbageclunk
 * verterok EODs
<kelvinliu> hi cory_fu: the current 2.7 edge `2.7.1+2.7-ec91b32` should be working fine for CaaS cmr now.
<cory_fu> kelvinliu: Great, thanks
<cory_fu> I'll give it a try
<kelvinliu> cory_fu: ty,
<wallyworld> babbageclunk: i just saw the bug - if you remove a unit that is leader, juju does not immediately elect a new leader, the current lease needs to time out. this is a known issue / works as designed.  there are bugs like bug 1469731 raised back in 1.23 days
<mup> Bug #1469731: Leadership must be dropped before removing lead unit <canonical-is> <charm> <charmers> <leadership> <teardown> <juju:Triaged> <postgresql (Juju Charms Collection):New> <https://launchpad.net/bugs/1469731>
<babbageclunk> wallyworld: yeah, but in this case it's been ages
<wallyworld> ah, ok, longer than the lease timeout
<roadmr> ð´  ages :)
<babbageclunk> wallyworld: yup as in hours
<wallyworld> :-(
<babbageclunk> wallyworld: but other applications seem to be ok - leadership changes fine
<wallyworld> i guess we'll need the raft logs, engine reports etc
<babbageclunk> yeah, although none of that really helps if leases seem to be changing ok for other applications
#juju 2020-01-08
<mruffell> does anyone happen to know how long it takes for a charm to appear in the store once you have pushed it and released it to stable?
<mruffell> oops forgot to grant to everyone =p
<wallyworld> kelvinliu: here's a mostly nechanical PR to remove some more bakery.v2 unstable stuff https://github.com/juju/juju/pull/11082
<kelvinliu> wallyworld: yep
<kelvinliu> wallyworld: one more place to refacor 15:42:59 apiserver/bakeryutil/service.go:43:3: cannot use store (type bakerystorage.ExpirableStorage) as type "github.com/juju/juju/vendor/gopkg.in/macaroon-bakery.v2-unstable/bakery".Storage in field value:
<wallyworld> kelvinliu: hmmm, that's fine for me. i may need to regenerate GoPkg.lock
<kelvinliu> just saw build failed
<wallyworld> ok, i may have some screwed deps locally, i'll wipe everything and fix any issues
<wallyworld> kelvinliu: i pushed a new toml and lock file. there was an issue with the deps and what i had cached
<kelvinliu> ic
<manadart> stickupkid: Got a minute to HO?
<stickupkid> manadart, sure can
<stickupkid> achilleasa, can you do a follow up CR - https://github.com/juju/cmd/pull/76
<achilleasa> stickupkid: sure
<achilleasa> stickupkid: have a question on the PR
<stickupkid> achilleasa, updated my pr
<stickupkid> achilleasa, removed the confusing ambiguity
<achilleasa> stickupkid: can you also update the comment on L528?
<stickupkid> of course
<achilleasa> (we are not checking for silence errors anymore)
<stickupkid> achilleasa, done
<achilleasa> stickupkid: approved
<stickupkid> achilleasa, ta much
<stickupkid> manadart, still around?
<manadart> stickupkid: Yeah. OTP with rick_h. Gimme a few.
<stickupkid> nice nice
<manadart> stickupkid: Back in Daily?
<stickupkid> manadart, yeah quickly
 * nammn_de off to doc
<skay> did anyone want to look at an environment with "Failed to connect to controller: invalid entity name or password (unauthorized access)" going on?
<skay> I'll leave my environment alone, if so. last time this happened (mid december) thumper said that it happened but they hadn't been able to reproduce it
<cory_fu> kelvinliu: https://pastebin.ubuntu.com/p/pfhs8QfX8R/
<kelvinliu> cory_fu: did u install latest edge?
<cory_fu> kelvinliu: installed:       2.7.1+2.7-ec91b32
<cory_fu> tracking:     2.7/edge
<cory_fu> refresh-date: today at 12:16 EST
<kelvinliu> cory_fu: clear jujud docker image cache in microk8s? and im testing it again now
<cory_fu> kelvinliu: Oh, I didn't do that.  There an easy way to do that without un/re-installing microk8s?
<kelvinliu> microk8s.ctr --namespace k8s.io image list | grep juju
<kelvinliu> then delete it
<kelvinliu> microk8s.ctr --namespace k8s.io images rm docker.io/ycliuhw/jujud-operator:xxxx
<kelvinliu> cory_fu: sorry, i tested yesterday using my branch build image, i found juju pushed but jujud docker image probably was not pushed yet.
<cory_fu> kelvinliu: Ah, ok.  I won't continue this test, then.
<kelvinliu> i will let you know once all pushed
<kelvinliu> cory_fu: to use edge image, please use `jujuqabot`,   juju bootstrap microk8s k1 --config caas-image-repo=jujuqabot
<kelvinliu> for docker repo
<cory_fu> kelvinliu: Is it ready for testing now?
<kelvinliu> yeah
<kelvinliu> i tested all good
<cory_fu> Ok
<cory_fu> kelvinliu: Yep, it's working.  Thanks!
<kelvinliu> cool, np
<asbalderson> Where can i find the list of possible states a machine can be in for juju-status?
<rick_h> asbalderson:  https://discourse.jujucharms.com/t/charm-unit-status-and-their-meanings/1168
<asbalderson> thanks rick_h; im looking for the actual machine status; not the unit status (running, down, other?)
<rick_h> bdx:  around?
<rick_h> asbalderson:  https://github.com/juju/juju/blob/2ad84b1b676eab460d6b9604aa1973944af02f9d/state/machine.go#L1785
<rick_h> asbalderson:  looks like started, stopped, pending, error, down
<timClicks> new juju article live "data ops at petabyte scale" https://ubuntu.com/blog/data-ops-at-petabyte-scale
<asbalderson> Thanks rick_h!
#juju 2020-01-09
<kelvinliu> wallyworld: jujuqabot/jujud-operator:2.8-beta1.3113  image pull failed
<kelvinliu> wallyworld: ho?
<kelvinliu> wallyworld: https://github.com/juju/juju/pull/11084 got his pr to fix CaaS bootstrap on develop, +1 plz
<wallyworld> kelvinliu: am in meeting but i will ping soon to talk about the build num PR
<kelvinliu> wallyworld: yep, gonna grab some food, back in ~15mins
<kelvinliu> wallyworld: im back, ping me when ur ready.
<wallyworld> kelvinliu: free now?
<kelvinliu> yes
<wallyworld> ok, am in standup
<stickupkid> manadart, https://github.com/juju/python-libjuju/pull/381
<manadart> stickupkid: Done. I have uncovered a an issue with CMR and the allwatcher, which is affecting the model cache :(
<stickupkid> manadart, YESSS! ho?
<manadart> stickupkid: Yep.
<stickupkid> rick_h, this will unblock pylibjuju for future jujus https://github.com/juju/python-libjuju/pull/382
<icey> is it just me or does Juju not create security group rules for IPv6 when you open_port something? I don't see an option to do IPv6 either
<icey> (on OpenStack)
<rick_h> icey:  ipv6 and juju :( we don't officially support it honestly
<hml> icey: it should, i remember seeing the code
<hml> icey: but also what rick_h  said
<icey> rick_h: color me sad; if there's IPv6 on the network, Juju shows that in the status, but opening the port doesn't seem to actually create the security group rule for it :-/
<hml> icey: it could be that the security groups are created for ipv6 when a juju unit is created, but it doesnât follow thru the open_port code
<icey> hml: yeah - I see the egress rule created for 0.0.0.0/0 and ::/0, but the open_port ingress rule is only created for ipv4
<icey> oh well, call it wishlist :)
<nammn_de> manadart: are my thouhts correct? For finding all the bindings in that space I would do the following:  get all endpointsbindings, look at each binding map (inverse) and see whether the space is used. or do we have an easier/faster way given the database layout
<manadart> nammn_de: That's how I understand it. achilleasa has been all up in that and might know an alternative.
 * achilleasa thinks
<achilleasa> nammn_de: is that for an application?
<manadart> achilleasa: Yes.
<achilleasa> nammn_de: I think the easiest approach is to create one of these: https://github.com/juju/juju/blob/develop/state/endpoint_bindings.go#L499 and then iterate the returned map from Map (for spaceIDs) or MapWithSpaceNames
<achilleasa> (just pass nil as the last arg of the ctor to get what's in the DB)
<nammn_de> achilleasa: great, thanks! Yeah was looking at the code you send before that. Was planning to do that similiarily
<nammn_de> manadart achilleasa: can i always deduce the application name from the endpointbinding _id? e.g. "32fee8a8-650b-46ed-8664-4d91d99f4b7c:a#haproxy" -> haproxy this would reduce the queries i need to make
<hml> nammn_de: https://github.com/juju/juju/blob/develop/state/endpoint_bindings.go#L272  so, yes
<nammn_de> hml: great, thanks!
<hml> nammn_de: but thatâs not necessariily the best way to go
<hml> nammn_de: usually thereâs a better way than looking at a doc id
<nammn_de> hml: my current approach to list all the applicationbindings using a space was the following: `get all endpoints  from collection` -> `check whether binding to that space exists` -> if yes ->  deduce application name
<nammn_de> couldn't think of a shorter way to get all applications running with a space binding
<hml> nammn_de: all endpoint bindings have a space.  even if itâs just the default
<hml> nammn_de: depends on what you mean by ârunningâ
<hml> explicitly using?
<nammn_de> hml: yeahh I meant by searching for a specific space
<nammn_de> e.g. show-space
<nammn_de> shows all applications bindings using that space
<nammn_de> show-space db-space, should show all applications which have endpoints bound to db-space
<nammn_de> so show-space _default(or alpha?) should show all, if nothing bind yet, i think
<hml> nammn_de: bbiab, i have a phone call
<nammn_de> hml: sure, thanks :)
<hml> nammn_de: back phone call moved.
<nammn_de> hml: we can HO quick
<nammn_de> maybe more clear
<hml> nammn_de: looks like there isnât a clean way to do that query.
<hml> nammn_de:  sure - daily?
<nammn_de> hml: comming
<roadmr> do newer jujus support ipv6?
<evhan> Hi folks, I'm writing a bundle but juju isn't liking my YAML, saying that the "bundle overlay file used deprecated 'services' key, this is not valid for bundle overlay files". I've just tried again with `applications` and that seems to have worked. Is this the right fix?
<rick_h> evhan:  yea, services were renamed to applications back in juju 2.0 and I think overlays came along and nudge folks in the right path
<evhan> Cool, ty.
<roadmr> do newer jujus support ipv6? ð¤
<rick_h> roadmr:  it supports it by ignoring it basically. It's not fully supported tbh. If the machines come up with it we make sure not to go boom
<rick_h> roadmr:  what are you trying to do?
<roadmr> using juju on a network with ipv6 only? :)
<rick_h> roadmr:  I think icey was asking about firewall support earlier today so curious if it's the same issue or something else?
<rick_h> yea...not sure that's ever been done
<roadmr> rick_h: something else - I think simpoir's home network (and all his configuration) are ipv6 and he was trying to use juju with lxd provider and got a "juju doesn't ipv6"
<rick_h> at one point we had a customer driving it as a use case but then they didn't need it and it never got on the roadmap
<rick_h> yea
<roadmr> rick_h: no big deal tbh, mostly a "just curious, will it work?" kind of question :)
<rick_h> no sorry, always wanted to get that going
<roadmr> no problem :)
<roadmr> at least I'm happy that the anarchy situation got resolved, apparently one of the controllers was reset and leaders were elected everywhere
<babbageclunk> roadmr: sorry I didn't think to check the snapshots until after you'd blown away the model!
<roadmr> babbageclunk: hehe no problem!
<roadmr> fwiw we never redeployed - we got held up by the controller troubles, but when one of them was reset trying to solve that, leaders magically appeared
<babbageclunk> roadmr: ah, yeah, that would do it too. It seems like the cause was unit 1816 still running (for some unknown reason). But if the controller went down, it wouldn't have been able to log back in, and might have removed itself from systemd. Would be worth checking the unit files on your machines?
<roadmr> sure, I can check with verterok tomorrow
#juju 2020-01-10
<babbageclunk> roadmr: thanks!
<evhan> What's the right way to send things to `juju debug-log` from an operator-based charm? Does CharmBase have access to a logging method or similar?
<wallyworld> evhan: there will be a logging method somewhere which does the same thing as the existing "juju-log" hook command but i don't know off hand where it is. the folks who can answer for sure will be online later
<evhan> wallyworld: Yeah, I had been shelling out to juju-log, then I found a method in charmhelpers.core.hookenv which is working in the meantime.
<wallyworld> yeah, the charm helpers one works for now
<wallyworld> charm helpers will be going away i expect, so stuff will need to be properly modelled on the charm class
 * thumper blows out a long breath
<thumper> debugging session over, and email sent out
<wallyworld> exhaling is always a good idea at some point
<timClicks> looks like it's been a hard day
<evhan> If I want to always run juju with some particular options, is there a client config file I should use? Or just set up an alias with some flags?
<wallyworld> most people just use an alias AFAIK
<evhan> cool, worksforme
<icey> wallyworld: charmhelpers won't be going away for a long time, methinks - do you know something I don't?
<wallyworld> icey: there's discussions around if it is wanted to be in the new charm operator framework, since it's a relatively uncurated set of funcs() just sort of dumped in a python library
<icey> wallyworld: the new charm operator framework that's going to replace the world like reactive did? ;-)
<wallyworld> something like that
<wallyworld> it's actually quite nice
<icey> yeah, don't hold your breath :-P
<icey> wallyworld: it looked nice in Paris, but can we migrate workloads using classic charms to it?
<icey> and can we get roadmap time to re-do 8 years of charming? :-P
<wallyworld> well yeah, there is that :-)
<icey> wallyworld: so we'll just have a third generation of charms - at least we kind of know what we need to do with our CI to add a new kind of thing :-D
<wallyworld> typically takes 3 goes to get a framework all nice and peachy
<icey> heh
<flxfoo> Hi all
<flxfoo> I have few questions. But a first one would be something about using python juju lib, and using scp to get a file from a container. Is it the right place to ask?
<wallyworld> flxfoo: it is, i am about to EOD, but stickupkid (when he comes online) should be able to help with pylibjuju etc
<flxfoo> wallyworld: thanks will wait :)
<flxfoo> Hi stickupkid, wallyworld told me that I could post a question here regarding the use of juju python lib...
<stickupkid> flxfoo, yeah, go for it
<flxfoo> ok, I am trying to write small script, I manage to get a unit, go through the model etc... run, and run-action... more explicitely, I want to use the API, to run backup from a non leader percona server, then scp that backup to the caller machine
<flxfoo> so I can get a non leader percona server fine
<flxfoo> I can run the backup action fine
<flxfoo> but not sure how to use the scp method
<stickupkid> flxfoo, I didn't write, it, but let me check
<flxfoo> I was looking at getting a mchaine object, but I don't see how I would get the "caller" instance to grab the source (remote container) down to "local" location...
<flxfoo> stickupkid: thanks
<flxfoo> in other words I would like to do something like : "juju scp mysql/1:/home/ubuntu/db.tar.gz /tmp/storage/" kind of
<manadart> stickupkid: I think I have found the export issue for relation scopes. Testing now.
<stickupkid> flxfoo, I'm actually unsure how to scp from a container, I don't think it's coded for
<stickupkid> flxfoo, let me write something and see if I can get it to work, be right back
<flxfoo> stickupkid: thanks
<flxfoo> stickupkid: that's what I am afraid of... it sounds that one wuld scp from a container to another only... no sure
<flxfoo> I would have another question regarding credentials, here locally (lxd) I can connect to the model with "connect_current()" and perform a `run('uname -a')` (eg) without problem, but
<flxfoo> on production... I would probably need to use `connect()` with a user/password certificate etc... which we do use with "semaphore" (deployment) ... but when I use `run()` (whatever command) I have a permission denied, I suppose the user is restricted on units?
<stickupkid> pylibjuju uses what ever is found in `~/.local/share/juju` unless you override in connect()
<flxfoo> stickupkid: ok, so that what I tried is to use connect locally... I got the pem certificate from `juju controller-config ca-cert` but when I try to connect using "endpoint` user /pass and cert (pem) it sasys incorrect certificate
<flxfoo> maybe it is a lxd specific stuff?
<stickupkid> flxfoo, so yeah, scp doesn't know how to resolve the container address. The work around would be to get your machine to first get the backup from the container and then get it from the machine
<stickupkid> flxfoo, this shows how to get it from a machine https://github.com/juju/python-libjuju/pull/383
<stickupkid> flxfoo, attempting to get it from a container will fail (it fails for Juju CLI as well by the way)
<stickupkid> flxfoo, juju scp 0/lxd/0:/home/ubuntu/.profile /tmp/profile2
<stickupkid> 0/lxd/0 <- first machine in a lxd container, wanting the first container
<flxfoo> stickupkid: many thanks I will try some stuff and keep you posted...
<drul> Hi, all.  Having issues with HA (hacluster charm) on multiple services (mostly testing on openstack-dashboard and keystone).  Deployment is fine, service is reachable via VIP.
<drul>   However, when I pause a unit that ISN'T the current active node (i.e. doesn't have the vip on its container), I get a service outage for several (varies, usually 5-30) seconds.  Any thoughts?
<drul> (I do pause the related hacluster unit first)
<flxfoo> stickupkid: how do I get the machine id from a unit name?
<stickupkid> flxfoo, you can't, in order to get a machine id, you would do - `unit.machine.id`
<flxfoo> stickupkid: thanks
<stickupkid> flxfoo, names aren't a hierarchy, the relations are through requesting methonds
<stickupkid> *methods
<stickupkid> flxfoo, generally you try and work controller -> models -> machines, not the other way around
<stickupkid> it is possible, but it means walking it backwards
<stickupkid> manadart, ace
<stickupkid> that makes soooo much sense
<manadart> stickupkid: You're looking at it? https://github.com/juju/juju/pull/11091
<stickupkid> manadart, i am
 * manadart nods.
<stickupkid> manadart, just doing the QA steps
<manadart> stickupkid: Wait on.
<stickupkid> :(
<manadart> stickupkid: It's alright :) I copied QA from another patch. If you use this, it's faster: https://pastebin.canonical.com/p/ppsKFKrk2Q/
<manadart> When that lands, I have the integration tests ready to go.
<stickupkid> manadart, done
<manadart> stickupkid: Ta.
<achilleasa> manadart: stickupkid or rick_h can you recommend a simple charm that stores state that I can use for testing?
<stickupkid> what sort of state?
<achilleasa> don't care; anything that potentially ends up in sqlite
<stickupkid> was going to suggest dummy-sink
<stickupkid> but unsure if trolling me with sqlite
<stickupkid> redis ;)
<drul> Am I right in deducing that pausing the hacluster subordinate will move the vip elsewhere (if it's on that unit), but will not remove the parent charm's service from haproxy?  i.e. service requests to the vip can (and do) still hit that unit?
<achilleasa> not trolling. I think that state gets serialized into a blob and stored in a sqlite :D
<stickupkid> does it
<zeestrat> drul: I recommend asking in #openstack-charms or on discourse.jujucharms.com
<drul> zeestrat: ah, okay, thank you, appreciate the response :)
<zeestrat> drul: Np. Sorry that I don't have anything more helpful. I don't have dev running at the moment so I can't test.
<manadart> stickupkid: https://github.com/juju/juju/pull/11092
<manadart> stickupkid: Am I missing something here? It is in the same file... https://github.com/juju/juju/pull/11092/checks?check_run_id=383499793
<stickupkid> dunno, that does look suspicious
<stickupkid> manadart, looking at the code now
<stickupkid> manadart, https://paste.ubuntu.com/p/c7xx8cwp8r/
<stickupkid> manadart, it's because you have multiple functions with the same name.... crappy regexp
<hml> manadart:  when youâve time - hereâs the change https://github.com/juju/utils/commit/ecdb27d4bf024174ae351b99a94c5400fd219ade
<manadart> hml: Ack.
<hml> manadart:  in the test, i need to get a cert in pem format to the client to test.  the cert should be know about by the server too to pass.
<stickupkid> manadart, quick HO?
<manadart> stickupkid: That's done.
<manadart> hml: Is there a parent PR for that that I can pull down to play?
<hml> manadart:  I donât have one yes, but give me a few and can do.
<achilleasa> hml: have a few minor comments for your PR
<hml> achilleasa:  thx
<hml> manadart:  getting weird dependency issues with deps on this.  will take a bit longer
<hml> manadart:  had to fix a dependency circle with names/utils.  https://github.com/juju/juju/pull/11094
<hml> manadart: can wait for monday definitely
<manadart> hml, will look first thing.
<hml> manadart: ty, have a good weekend
