#juju 2012-01-16
<SpamapS> hrm.. https://launchpadlibrarian.net/90171425/buildlog_ubuntu-lucid-i386.charm-tools_0.2%2Bbzr119-7~lucid1_FAILEDTOBUILD.txt.gz .. especially confusing
<SpamapS> + dpkg -l openssh-client
<SpamapS> + awk /^ii/ { print $3 }
<SpamapS> + ssh_version=
<SpamapS> especially that part, since running that locally in a lucid chroot produces ssh_version=1:5.3p1-3ubuntu7
<rog> TheMue: morning!
<TheMue> rog: Hey, Roger, good morning. Returned well?
<rog> TheMue: yeah, journey back good, and i had a nice rest-of-weekend too, thanks
<rog> TheMue: you?
<TheMue> rog: everything fine, thx. took a first look for the may trip. that will be a harder journey. ;) at least about 25h from here, maybe more.
<rog> TheMue: i should do the same. better organise it with a couple of days of recovery time at the start...
<rog> TheMue: i was in the heathrow lounge with a few of the guys going back to Oz, and their flight was delayed by 11 hours!
<mpl> where will it be in may?
<rog> mpl: oakland, i think
<mpl> florida?
<TheMue> rog: yep, landing on sunday evening to start fresh on monday morning won't work.
<mpl> oh no, CA
<TheMue> oakland, california
<mpl> ouch indeed.
<mpl> TheMue: it shouldn't take that long though. I think my flight from Madrid to Chile took me 13 hours.
<TheMue> mpl: from Germany I only found two stop trips with about 23h travel time (w/o driving from/to airport and check-in)
<mpl> TheMue: right, everything included it might account for as much
<mpl> oh, w/o you said.
<rog> TheMue: flying to oakland or SFO?
<TheMue> yip
<TheMue> OAK
<rog> TheMue: you might find flying to SFO is a better option
<mpl> oh well, you'll see. good luck with that though. the way in was ok for me, but I found the way back (from chile) pretty horrible indeed.
<TheMue> rog: Good tip, looks better.
<mpl> rog: that's actually why I missed one full morning of the last iwp9. I was so tired from the trick back to Chile, and with a cold from the horrible constant a/c during the flight, that I overslept and didn't hear at all my phone alarm.
<mpl> s/trick/trip/
<rog> TheMue: yeah, SFO looks about 5 hours better for me, at least (14h vs 21h)
<TheMue> rog: same here, and one choice is taking the A380 (nice)
<mpl> TheMue: I've been told one big advantage of the A380 is it's way less noisy (you don't hear the reactors/engines so much as in the other ones).
<TheMue> mpl: Would be a great benefit to at least have the chance for some napping during the flight.
<mpl> TheMue: exactly.
<mpl> can anyone come to the ubuntu meetings or does one have to be a canonical employee?
<TheMue> mpl: http://uds.ubuntu.com/
<mpl> TheMue: thx
<mpl> cool. I might try to go to the next one happening in europe then.
<SpamapS> While OAK is closer to the venue, SFO has tons of direct flights from Europe.
<SpamapS> mpl: you can apply for sponsorship.. juju will get just a few slots to sponsor community members.
<SpamapS> mpl: plane noise can be handled quite effectively by simple ear plugs. :)
<SpamapS> oh my, its 2am, I should sleep
<mpl> SpamapS: the price is not the main issue for me. I just try to not travel by plane too far away when I can, for ecological reasons.
<mpl> SpamapS: and yeah I never travel anymore without earplugs, as I usually have a very light sleep.
<niemeyer> Helloooo
<niemeyer> How's everybody doing this fine Monday?
<hazmat> niemeyer, pretty good
<hazmat> ;-)
<niemeyer> hazmat: Still here :)
<hazmat> its a national holiday in the US as well
<niemeyer> My connectivity is a bit on the bad side at the moment
<niemeyer> hazmat: Oh, double holiday then :)
<hazmat> niemeyer, we're having a good discussion in juju-dev on charm upgrades
<hazmat> looks like no history bot on the channel though
<rog> niemeyer: mornin'!
<rog> niemeyer: flight go ok?
<hazmat> niemeyer, here's the log fwiw http://pastebin.ubuntu.com/806218/
<niemeyer> hazmat: Thanks
<niemeyer> rog: Hey!
<niemeyer> rog: Yep, all good
<niemeyer> Hmm.. hungry.. lunch time.
<gmb> Hi folks. Is there a way to run the juju test suite without it (apparently) trying to connect to EC2?
<gmb> I assume I've missed something screamingly obvious here.
<hazmat> gmb, it doesn't actually connect to ec2 for the test suite
<hazmat> gmb, it may ask for values for the account but you can put in dummy values
<gmb> hazmat: Ah, really? It breaks because my AWS credentials aren't in the environment, which seems a bit odd.
<gmb> Thanks for clarifying though.
<hazmat> gmb, yeah.. that's a test setup bug, feel free to file a bug on it
<gmb> hazmat: Righto, will do. Thanks!
<_mup_> Bug #917228 was filed: ./test --functional errors if EC2 credentials aren't in the global environment <juju:New> < https://launchpad.net/bugs/917228 >
<niemeyer> gmb, hazmat: ./test *--functional* should probably connect to EC2, though?
<SpamapS> niemeyer: perhaps the tests that need AWS_ should be skipped with a helpful message.. "set AWS_... to run these functional tests"
 * SpamapS says.. from "holiday" :)
<niemeyer> SpamapS: The error message seems pretty ok (Could not find AWS_ACCESS_KEY_ID)
<niemeyer> SpamapS: But I agree, it could be improved
<SpamapS> I have never been very comfortable with directing people to use those variables, especially since the aws cmdline utilities don't even use them anymore (which is quite baffling to me that they changed them)
<mpl> niemeyer: yo. do you have a couple minutes today to discuss ssh ?
<niemeyer> SpamapS: Huh.. when were they changed?
<niemeyer> SpamapS: I still use them
<niemeyer> mpl: Sure, what's up?
<mpl> niemeyer: I haven't looked at it again, but basically I don't see how to connect the ssh connection with a zk Dial call. Because exp/ssh only gives us net conn to work with as a reader/writer. and otoh zk.Dial() does some things that I don't see how to replicate in terms of smaller operations.
<SpamapS> niemeyer: ec2-* doesn't seem to listen to AWS_* anymore
<SpamapS> niemeyer: I have to set EC2_... now
<niemeyer> SpamapS: Which version of the tools are you using?
<niemeyer> SpamapS: I'm probably missing an upgrade then
<niemeyer> mpl: What we want to do is exactly what the Python code is doing, except we'll be using the internal package rather than delegating to an external process
<niemeyer> mpl: The overall functionality and the reason why it works is exactly the same
<niemeyer> mpl: The server side behavior is also the same.. we'll be connecting to sshd, not to something else
<SpamapS> niemeyer: 1.5.0.0
<SpamapS> niemeyer: I didn't use them really at all between Ubuntu 10.10's release and early in 11.10's cycle.. so it changed somewhere in there
<hazmat> niemeyer, indeed but those tests are likely bit rotted
<SpamapS> niemeyer: since euca-* is typically faster to start up.. being in python instead of java. :)
<niemeyer> SpamapS: Ok, I'm using 1.4.3 still..
<niemeyer> hazmat: How's that related to the bug?
<hazmat> niemeyer, not.. i hadn't realized the --functional flag was being used.. which does indeed require  a valid ec2 account creds
<niemeyer> SpamapS: Hmm.. not really
<mpl> niemeyer: I understand how to pass along bytes from point A to point B through the established ssh tunnel. what I don't get is how to pass a "valid" dial as the zk server is expecting it.
<niemeyer> SpamapS: I'm using the 11.10 version, I believe
<niemeyer> mpl: It's normal TCP connection forwarded through the ssh channel
<SpamapS> niemeyer: hrm, actually I may have been confused how ec2-* worked.. it never read AWS_* ... it was respecting EC2_PRIVATE_KEY / EC2_CERT ...
<niemeyer> SpamapS: Ah, ok.. those are different indeed
<SpamapS> Does that mean that the ec2-* utils only use the SOAP interface, while euca-* uses the RESTful API?
 * SpamapS has never much cared how they worked.. only that they do. :-P
<SpamapS> niemeyer: also its definitely a *lot* slower to use the ec2-* on my system.. http://paste.ubuntu.com/806410/
<SpamapS> 4.0s vs 0.6s
<mpl> niemeyer: ok. but do you agree that with the way exp/ssh works, I cannot uze zookeeper.Dial() and I have to replicate whatever it is doing (tcp connection plus whatever else it's doing)?
<mpl> *use
<niemeyer> mpl: No, I disagree
<niemeyer> mpl: You seem to be thinking about implementing something else, that is not what the Python code is doing
<niemeyer> mpl: Imagine you had to change the Python logic to get rid of the fact it uses the external "ssh" command for establishing connections to the server
<niemeyer> mpl: That's all you have to do
<niemeyer> mpl: zookeeper's concerns are completely irrelevant
<mpl> niemeyer: it's not the same. because since the python code uses the external ssh, it just gets for free a new port that is listened on to connect to
<mpl> niemeyer: while with exp/ssh, you just get a net conn on which to read and write
<niemeyer> mpl: "because since the python code uses the external ssh, it just gets for free a new port that is listened on to connect to"
<niemeyer> mpl: Yep, and that's what we want to do as well!
<niemeyer> mpl: Again, you're thinking about implementing something else that is not what the Python version does. Think about the behavior of ssh, and imagine how you'd mimic it
<mpl> niemeyer: ok, I have my mimicking ssh tunneling listening on that new port. I receive a zk.dial() call, so I establish the tunnel to the sshd.
<niemeyer> mpl: Right
<mpl> niemeyer: but then how do you
<mpl> sorry
<mpl> how do you forward that dial that was received?
<mpl> hmm
<niemeyer> mpl: Programming? ;-)
<mpl> maybe I don't have to do anything because when establishing the ssh tunnel there alread was a dial to the zk server.
<mpl> niemeyer: I'm sorry, I just get the feeling that I had already tried those things and failed. I guess I'll just retry.
<niemeyer> mpl: It's certainly possible.. I think Dave even had some code doing something similar already
<niemeyer> mpl: But I'm afraid I can't help you much more than that :(
<niemeyer> mpl: The way I can figure exactly how to do it is by sitting down and doing it
<niemeyer> mpl: Alternatively, we might look at some other task that you'd feel more comfortable about
<mpl> niemeyer: as you wish. if you feel like you need it done soon, then maybe. but I'm happy to retry.
<niemeyer> mpl: We're not in a rush about this just yet, so you certainly have some extra time to retry if you wish
<mpl> (I don't like giving up in general)
<SpamapS> woot, 2 big boxes of juju t-shirts just arrived at my door. :-D
<SpamapS> jcastro_: ^^
<SpamapS> correction, *3* big boxes of juju t-shirts
<koolhead17> SpamapS:
<koolhead17> jcastro_: where is my kit sir!! :P
<SpamapS> koolhead17: what kit?
<koolhead17> SpamapS: there is a event where am thinking to take 1-2 hr session on juju workshop, like charm school
<SpamapS> koolhead17: ahh. Well we're still just now getting juju shirts/stickers/etc. made for the first time. So please have patience. :)
<SpamapS> juju only spun up its first EC2 instance about a year ago. ;)
<koolhead17> SpamapS: feb11 is event date
<koolhead17> SpamapS: yeah i know, i am planning to show juju/charm magic on/via LXC
<SpamapS> koolhead17: cool :)
<koolhead17> i have  added a talk too. :)
 * koolhead17 has fingers crossed 4 talk getting selected
<mpl> niemeyer: sorry, had to talk with my boss. so yeah, I'll retry, thanks for the talk. going home now.
<hspencer> koolhead17, i updated more info on juju with Walrus
<hspencer> put a bug in with txAWS
<hspencer> waiting to hear back
<hspencer> but yea
<hspencer> somethign is up with txAWS
<koolhead17> hspencer: hey dude
<hspencer> how was your weekend?
<koolhead17> hspencer: but are we able to get juju working on euca
<koolhead17> SpamapS: hspencer is euca developer
<hspencer> err i didn't try it...i just looked at txaws
<koolhead17> hspencer: weekend was cool, beer/strangers and music
<hspencer> juju uses txaws to talk to Walrus correct?
<hspencer> does it do it by default?
 * koolhead17 looks at SpamapS hazmat niemeyer
<SpamapS> hspencer: yes all AWS interaction in juju is done via txaws
<SpamapS> hspencer: I think I responded to your txaws bug report about how its unfortunate but ultimately running S3 commands under a prefix path is not quite the same as S3...
<hspencer> SpamapS, yea, it is.  But what i found more interesting is that it looked like there was some syntax checking done on on the URL before it was being sent.  I used ngrep on my Walrus component to track traffic occurring on the wire. I didnt' see anything there
<hspencer> is there some syntax checking?
<hspencer> just curious?
<SpamapS> hspencer: I don't have a deep understanding of txaws, I just observed the result of the actions and confirm that the code is working as intended. I don't have a working walrus to test against though I think we need to get a eucalyptus system setup to run juju's functional tests against at some point.
<hspencer> if you want, you can test it against the ECC
<hspencer> you just need an account on there
<hspencer> you don't need to launch an instance
<hspencer> i just used the txaws commandline tools directly
<hspencer> figured if they work that way, then it shouldn't be a problem to get it working with juju
<hspencer> know what i mean?
<hazmat> yup
<hazmat> i can setup an account with ecc and have a look then..
<koolhead17> fwereade: hey there
<fwereade> heya koolhead17
<koolhead17> fwereade: how are you?
<koolhead17> hspencer: so we are almost there?
 * koolhead17 is hopeful to get juju on euca too :)
<fwereade> koolhead17, not too bad, just finishing up some python stuff so I can get to work on go :)
<koolhead17> :P
<hspencer> koolhead17, workin on it
<hspencer> :)
<koolhead17> hspencer: ;-)
<hspencer> workin with hazmat
<koolhead17> hspencer: SpamapS and hazmat are always here
<koolhead17> yes
<hspencer> its good stuff
<hspencer> lookin forward to tit
<koolhead17> indeed.
<hspencer> to it
<hspencer> for the folks workin on debugging txAWS issue: EMI on ECC is uploaded and available
<hspencer> IMAGE	emi-BBBB188B	oneiric-uec/oneiric-server-cloudimg-amd64.img.manifest.xml	hspencer	available	public		x86_64	machine	eki-81ED1733	eri-E8B51886	instance-store
<hspencer> if you have an account on the ECC, you should be able to launch and run that instance
<hspencer> hazmat, SpamapS, niemeyer: just an FYI, oneiric image up on ECC.  Working on getting natty image up there as well.  Let me know if you guys have any issues
<niemeyer> hspencer: Sweet, thanks
<hspencer> yep, no problem
<hspencer> i want to help get this issue fixed. shouldn't be having this issue
<hspencer> plus, i would like to have another tool to use with Walrus
<hspencer> outside of s3cmd
<hspencer> any way i can help
<hspencer> just lemme know
<hspencer> hazmat, SpamapS, niemeyer: natty is on the ECC.  The image information for natty and oneiric are as follows
<hspencer> IMAGE	emi-55CC1725	natty-uec/natty-server-cloudimg-amd64.img.manifest.xml
<hspencer> IMAGE	emi-BBBB188B	oneiric-uec/oneiric-server-cloudimg-amd64.img.manifest.xml
<hspencer> lemme know if you guys have any issues running those images on the ECC
<SpamapS> hspencer: so, question.. is walrus normally setup as a sub directory in Eucalyptus, or is that just one option?
<_mup_> Bug #917405 was filed: charm upgrade from charm store can leave units out-of-date and unfixable <juju:New> < https://launchpad.net/bugs/917405 >
#juju 2012-01-17
<hspencer> SpamapS, when you mean sub directory, do you mean on the physical machine?
<hspencer> where Walrus is running
<hspencer> ?
<hspencer> typically on the physical machine where Walrus is running, there is a directory under /var/lib/eucalyptus/bukkits
<hspencer> under there, all the buckets are kept there, along with the information thats in each bucket..but its all encrypted
<hspencer> encrypted
<koolhead17> SpamapS: around>
<koolhead17> ?
<SpamapS> koolhead17: yeah, whats up?
<koolhead17> SpamapS: can i get a AWS account for few days to show juju demo at conf ? I find Juju way to slow on/via LXC :(
<SpamapS> koolhead17: we could probably give you one with limited capabilities for a few hours. Are you sure there's no way Amazon will let you setup your own account? All you need is a credit card of some kind.
<koolhead17> SpamapS: yeah i dont have a credit card :(
<SpamapS> koolhead17: its kind of an odd thing to demo something that you can't use.
<koolhead17> SpamapS: cool i will strict to LXC then
<koolhead17> leave it
<koolhead17> :)
<koolhead17> *restrict :D
<SpamapS> koolhead17: perhaps see if somebody else can contribute a machine with lots of RAM for your demo. :)
<koolhead17> yes. fortunately organizers have asked for hardware needed, i am asking for system with minimum 4 GB RAM  and Oneiric running :)
<SpamapS> koolhead17: we could always just spin you up an m2.xlarge for 4 hours ($2) and let you run the LXC provider in that on a tmpfs partition. ;)
<SpamapS> koolhead17: but then you'd get spoiled and want that kind of speed all the time.
<koolhead17> SpamapS: actually i need AWS as i worked on it during ensemble with friends account for charm school session because i am not sure if all the participants gonna have all the required hw/sw installed on there box
<koolhead17> it will take few hours for me to show how/what needed to do in AWS and then they are on there own :P
 * koolhead17 is confused. or i should just mention what i need from the participants :P
<SpamapS> koolhead17: we've talked about setting up a dedicated openstack cluster for charm schools.
<koolhead17> SpamapS: how much time it will take
<SpamapS> koolhead17: months
<SpamapS> many months
<koolhead17> SpamapS: :P ok
<SpamapS> koolhead17: but we do plan on doing a bunch of charm schools all over the place this year.. and it would make things a lot simpler if we can just give people limited accounts.
<koolhead17> SpamapS: what should i do then sir for feb11 event? :)
<SpamapS> koolhead17: I would recommend 4GB of RAM for LXC, or that people have their own AWS accounts.
<koolhead17> SpamapS: ok.
<SpamapS> koolhead17: another option is to use orchestra and a bunch of old machines.
<koolhead17> SpamapS: am reading up on orchestra and not very familiar with it. I will restrict to LXC/AWS
<koolhead17> SpamapS: also how will juju behave when am running it behind proxy? am i supposed to pass some argument during bootstrap
<SpamapS> koolhead17: orchestra is just a cobbler server + webdav to store the charms. You can just turn machines on and point them at the preseed file that cobbler generates, and then they will install and join the juju cluster.
<SpamapS> koolhead17: its not exactly "simple".. but it is certainly the *cheapest* option if you have a bunch of old machines lying around.
<koolhead17> SpamapS: i will add that option as well in requirement :D
<koolhead17> (01:38:21  IST) koolhead17: SpamapS: also how will juju behave when am running it behind proxy? am i supposed to pass some argument during bootstrap
<SpamapS> koolhead17: not sure.. haven't tried that
<koolhead17> SpamapS: i think i will try it because am sure these events will have proxy with them
<koolhead17> and i failed to get juju working on my openstack proxy env
<SpamapS> koolhead17: you seem to always be dealing with very complicated setups. :/
<koolhead17> SpamapS: well unfortunately yes
<koolhead17> :(
<mpl> bleh, just figured why zookeeper service wouldn't start on this lucid lynx. apparently it's because of --chuid zookeeper:zookeeper, beats me.
<mpl> just removed that for now as just need a running zookeeper to dev against.
<niemeyer> Goood morning all!
<andrewsmedina> niemeyer: morning
<andrewsmedina> It's possible create more than one wordpress service with juju?
<niemeyer> andrewsmedina: Morning :)
<niemeyer> andrewsmedina: Yeah, you can create as many services as you want (and you have machines for)
<mpl> hello Gustavo
<andrewsmedina> niemeyer: thanks
<andrewsmedina> niemeyer: I was trying without set the service name
<andrewsmedina> niemeyer: would be nice if the juju generate a random name is the name of the service already exists
<niemeyer> andrewsmedina: Interesting.. I imagined people would prefer to choose sensible names
<andrewsmedina> niemeyer: hm..
<mpl> niemeyer: ok, it's a bit of a mess, but I managed to send a zk.Create() command over ssh I think, so hurray :)
<niemeyer> mpl: Woah, sweet! :-)
<mpl> niemeyer: the sad thing is I actually was almost there last time I tried. I've basically only changed a tidbit now.
<nijaba> when you need a review of a modification in an existing charm, is there a tag to set so that charmers can see all the pending reviews in the queue?
<lynxman> gah I forgot, what was the parameter again in enviroments.yaml to tag your EC2 machines to your specific juju install? (so they're easy to clean up afterwards)
<lynxman> hazmat: ping
<koolhead17> smoser: around?
<koolhead17> hey nijaba
<nijaba> hello koolhead17
<koolhead17> nijaba: i tried playing with phpbb3 and exim4 is required pkg
<koolhead17> :(
<nijaba> koolhead17: then do not use the package
<nijaba> (which seems pretty poor quality)
<koolhead17> nijaba: okey.
<smoser> koolhead17, here.
<nijaba> koolhead17: I would also file a bug against the package
<koolhead17> nijaba: cool. let me confirm it again and file a bug!! :P
<nijaba> koolhead17: it should at least not require exim, just some smtp provider
<hazmat> lynxman, pong
<lynxman> hazmat: nevermind, found my anwer in the server channel :)
<lynxman> hazmat: I'll ping SpamapS later, looks like the distro packages for both oneiric and precise are not working (I reckon its txaws)
<lynxman> hazmat: just for your curiosity http://pastebin.ubuntu.com/807434/
<smoser> koolhead17, did you need something?
<lynxman> smoser: morning o/
<smoser> good morning, mr lynxman
<koolhead17> nijaba: yes help to get the juju part working inside proxy setup of my openstack infra
<koolhead17> :D
<koolhead17> oops i meant smoser :)
<koolhead17> ^^
<koolhead17> nijaba: am wrong http://paste.ubuntu.com/807460/  phpbb3 recommends exit4 not depands
<koolhead17> nijaba: seems like i found bug for phpbb3 now, http://paste.ubuntu.com/807466/
<koolhead17> see the following packages will be installed option, it installs exim4
<koolhead17> :(
<secbrid> chaps, quick question I've created some servers with juju, but how do i now ssh onto them, using what username and password/key ?
<koolhead17> secbrid: so you have some units running
<koolhead17> juju -v status
<secbrid> koolhead17, yeah, and i'm trying to ssh root@<server>.eu-west-1.compute.amazonaws.com
<secbrid> i'm getting Permission denied (publickey).
<koolhead17> secbrid: is  juju -v status giving u something?
<secbrid> koolhead17, yeah, it looks like this: http://paste.ubuntu.com/807525/
<secbrid> koolhead17, i would normally do juju debug-hooks relay/0 but i'd like to do it the ssh way if possible as well
<koolhead17> secbrid: yeah thats wht i would do
<secbrid> is the username root@<server> ? I'm just making sure it's not expecting another username instead, im using ssh -i as well to try use my key file, but thats give the same Permission denied (publickey). message
<koolhead17> secbrid: i am not much aware about the AWS part, am using juju on LXC only. but to see more debugging option i would check my juju dir and then the log files inside the units directlry
<koolhead17> *directory
<secbrid> roger, thanks koolhead17
<koolhead17> secbrid: welcome ^^
<fwereade> secbrid, have you tried "juju ssh 0" (or whatever machine id you're interested in)?
<nijaba> koolhead17: I read on phpbb "Recommends: <mail-transport-agent>" which means that it can be resolved to any mta, not just only exim
<koolhead17> nijaba: yeah but http://paste.ubuntu.com/807466/
<nijaba> koolhead17: so this is fine.  Just as msmtp-mta on your install command, and you'll see that that exim won't be pulled anymore
<nijaba> koolhead17: not that recommends do get installed by default since 9.04 IIRC
<nijaba> s/not/note
<koolhead17> nijaba: ooh:-(
<secbrid> fwereade, you legend!!! Thank you! that worked perfectly!
<fwereade> secbrid, a pleasure :-)
<fwereade> iirc, you should also be able to "ssh ubuntu@..." -- it should have picked up your key at bootstrap time -- so you can do that if for whatever reason juju ssh doesn't work
<secbrid> ah excellent! i wasn't sure what username to use. very useful thanks
 * koolhead17 notes fwereade just mentioned :)
<lynxman> hazmat: ping
<hazmat> lynxman, pong
<lynxman> hazmat: I have an issue with txaws and bucket creation with EC2 secret having not alphanumeric characters
<lynxman> hazmat: latest ppa package for oneiric, distribution package for precise and oneiric with same result
<lynxman> hazmat: Error Message: The request signature we calculated does not match the signature you provided. Check your key and signing method.
<hazmat> lynxman, is this against ec2 or openstack?
<bcsaller> hazmat: any chance of feedback on https://codereview.appspot.com/5541054 today?
<hazmat> bcsaller, sure
<bcsaller> awesome
<lynxman> hazmat: against ec2
<hazmat> oh.. the ppa
<lynxman> hazmat: yeah got latest package from the ppa for oneiric
<lynxman> hazmat: also distro packages give the same result :/ (both oneiric and precise)
<EvilBill> jcastro: ping
<hazmat> lynxman, i just did a run through with the distro packages without issue (deps only), trying with the ppa
<jcastro> EvilBill: hi
<lynxman> hazmat: my EC2 auth has a '+'
<lynxman> hazmat: as the only weird character there
<EvilBill> jcastro: we should chat re: scale, and if you need my assistance with your charm school
<jcastro> we should
<jcastro> tomorrow fine?
<jcastro> EvilBill: mchenetz tells me he's almost done with the mac bits
<EvilBill> jcastro: cool.
<EvilBill> that works
<jcastro> EvilBill: right now the #1 thing I need is loud people getting people to show up. :)
<EvilBill> I just wanna know where I need to be, when, and what I need to be prepped for.
<EvilBill> cause right now all I'm bringing to scale is my laptop, ipad, iphone, and a bottle of rum
<EvilBill> yaaarr.
<jcastro> sounds perfect
<jcastro> it's at 1:30 on the Friday
<jcastro> but we can hang out and go to these devops talks all day
<EvilBill> yeah, that sounds like a plan
<EvilBill> Am really looking forward to that
<EvilBill> going to be bringing the Kyle down with me
<EvilBill> we'll be rolling in Thursday evening.
<hazmat> lynxman, mine does as well re '+', just finished up using the ppa packages without error as well
<hazmat> on oneiric
<lynxman> hazmat: cool thanks
<mpl> niemeyer: first example cleaned up a bit, e-mail sent. I'm going home now but I'll be available on irc again in a while if you want to talk. see you.
 * hazmat tries again with a new s3 bucket
<niemeyer> mpl: Superb, thanks a lot!
<lynxman> hazmat: I'll try again then, any recommendations on how to get more debug?
<m_3> lynxman: it might be worth it to try all over again from a fresh vm
<lynxman> m_3: I think I'll do that...
<lynxman> m_3: this has been killing me today :)
<hazmat> lynxman, i'd verify your ec2 creds
<m_3> yeah, it's just strange
<lynxman> hazmat: they work on other apps :/
<m_3> lynxman: juan's still successfully using them right?
<lynxman> m_3: yeah :)
<m_3> negronjl: thanks for the charm-tools fix man
<jcastro> robbiew: ok, so remind me again why we sent some shirts to me, and some to Clint?
<robbiew> Clint is for SCALE10x Charm School
<jcastro> ok and then ones I just got for ... ?
<robbiew> you have the rest and whatever we have left from SCALE for the remaining Charm Schools
<jcastro> got it.
<robbiew> and giveaways to folks at your discretion ;)
 * m_3 jealous jorge doesn't have to do laundry for a month
<SpamapS> hazmat: any luck on that twisted issue? I suppose we should open a bug
 * SpamapS has a s***ton of shirts :)
<arosales> SpamapS: Daviey was telling me of a bug that breaks juju on prcise.  Do we have a bug opened for the  incompatibility with juju and the version of twisted in precise?
<SpamapS> arosales: ^^ just asked hazmat
<arosales> SpamapS: ah ok, thanks.  Once we have one we should probably add it to Daviey's bug list (http://status.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html)
<hazmat> SpamapS, refresh .. which twisted ?
<hazmat> SpamapS, ah that one, no.
<negronjl> m_3: no worries
#juju 2012-01-18
<_mup_> Bug #917954 was filed: juju.providers.orchestra.tests.test_digestauth fails with twisted 11.1 <juju:New> < https://launchpad.net/bugs/917954 >
<SpamapS> hazmat: assigned bug 917954 to you
<_mup_> Bug #917954: juju.providers.orchestra.tests.test_digestauth fails with twisted 11.1 <ftbfs> <juju:New for hazmat> <juju (Ubuntu):Triaged> < https://launchpad.net/bugs/917954 >
<hazmat> SpamapS, sounds good
<SpamapS> hazmat: did you have any time to look closely at it, or still just getting your head screwed back into US time zone?
<hazmat> SpamapS, not since the sprint, been trying to get back into the review stack, its multiplied again
<niemeyer> Good mornings!
<rog> niemeyer: hiya!
<TheMue> morning
<highvoltage> ââââ âââââââ niemeyer
<TheMue> lol
<niemeyer> Some serious voltage there
<highvoltage> :)
<jcastro> lynxman: mchenetz tells me OSX client should be available for testing this week
<lynxman> jcastro: wohooo \o/
<jcastro> statik: FYI ^^
<lynxman> jcastro: great news
<jcastro> EvilBill: bring your mac to SCALE, we can try it there
<rog> robbiew: G+?
<robbiew> rog: yep...will send an invite
<koolhead11> lynxman: thanks!! :D
<lynxman> koolhead11: np
<mpl> niemeyer: hello. have you had time to have a look at the code I pointed to?
<koolhead11> jcastro: around
<jcastro> hi
<niemeyer> mpl: Nope, sorry
<niemeyer> mpl: I really have to focus on a few other things, so may not be able to come back to you until next week unfortunately
<niemeyer> mpl: That said, if you are in a good direction, we may start talking about how to integrate this
<niemeyer> mpl: It should be put in the form of a proper package that enables us to set up forwarding with a nice interface
<niemeyer> mpl: Maybe the easiest way to move forward is for you to write down a proposal for how you feel we could structure such a package interface, and send a merge proposal for that
<niemeyer> mpl: You can use a file such as environs/ssh.go under juju's tree
<mpl> niemeyer: ah, good idea. will try that then, thx.
<niemeyer> mpl: Don't worry about the implementation for the momnet
<niemeyer> mpl: Just write down the skeleton for the package
<mpl> hmm
<mpl> ok
<niemeyer> mpl: Sorry, not for the package.. we can have it within environs itself
<niemeyer> mpl: Just write a skeleton for the functionality
<mpl> niemeyer: so you mean, environs/ssh.go will not contain everything?
<niemeyer> mpl: For now it will
<niemeyer> mpl: Everything for the functionality you're tackling
<mpl> niemeyer: in the form of a package, right?
<niemeyer> mpl: We can reestructure later, if necessary.. but right now all we need is a proposal for its interface
<niemeyer> mpl: No, in the form of a file, ssh.go
<mpl> ah yes, silly me
<niemeyer> mpl: Within the environs package
<mpl> ok
 * hazmat grabs lunch
 * SpamapS caresses lunch
<robbiew> jcastro: m_3: had a good showing at the Austin Cloud Users Group lastnight for the juju demo...I was asked if we would be giving a charm school at the Austin DevOpsDays event April 2/3....interested?
<robbiew> SpamapS: that's nasty
<gary_poster> heh
<m_3> robbiew: lemme check calendar
<m_3> robbiew: yeah, I can do that one
<m_3> robbiew: you have a contact?  is that a LinearB event?
<robbiew> m_3: no clue -> http://devopsdays.org/events/2012-austin/program/
<robbiew> m_3: shoot an email to organizers-austin-2012@devopsdays.org about hosting a Charm School
<robbiew> I'm sure they'll ask for sponsorship $$$
<m_3> robbiew: maybe talk _and_ charmschool?
<robbiew> I can raise that internally if so
<robbiew> sure
<m_3> ok, I'll ping em
<m_3> thanks!
<jcastro> m_3: if you get both ask to do the talk first
<m_3> jcastro: yup... will do
<SpamapS> m_3: devopsdays that I have been to have been really good
<m_3> yeah, it's gonna be a great venue I think... strong community in Austin
<robbiew> m_3: for sure
<robbiew> I had some really good..and tough...questions last night
<robbiew> folks were super interested though
<m_3> robbiew: yup... lots of shops with established practices
<robbiew> did my lisa'11 demo...local deploy thinkup...aws deploy thinkup...aws deploy hadoop...terrasort...scale up...destroy
<robbiew> done
<m_3> nice
<SpamapS> robbiew: want some gource training? ;-)
 * SpamapS realizes he hasn't read email at all yet today .. doh
<robbiew> SpamapS: heh...the hadoop dashboard and ganglia helped
 * robbiew waiting for the juju --visualize option
<SpamapS> juju viz
<robbiew> that automatically displays status to gource
<robbiew> yeah
<robbiew> juju-viz
<SpamapS> if you say it with an accent it sounds like juju-bees ;)
 * m_3 groans
<robbiew> lol
<robbiew> well...I dunno about all that, but having a plugin that fired up gource would be sweet
<robbiew> maybe we can get koolhead17 to do it
<robbiew> :P
<SpamapS> yeah its still 2 pipes and a special argument to python.. ;)
<robbiew> a.k.a the pitbull of juju community development
<SpamapS> JUMP UP JUJU GO CRAZY
<koolhead17> hello robbiew sir
<jcastro> yes, finally, lp:charms
<koolhead17> yay
<jcastro> with the S, as god intended
 * koolhead17 scrolls up
<m_3> jcastro: whoohoo!
<jcastro> SpamapS: you're doing the viz for our talk right?
<robbiew> jcastro: lol
<SpamapS> jcastro: yeah I'll bring the beez
<SpamapS> ;)
<jcastro> SpamapS: this time I will try to use the right slides.
<SpamapS> meh, keep the challenge high
<SpamapS> You were doing fine at powerpoint karaoke
<m_3> jcastro: is there any way to make the wiki urls case-insensitive?  i.e., juju.ubuntu.com/charmschool _and_ juju.ubuntu.com/CharmSchool
<jcastro> not afaik
<jcastro> what I do is create redirects for the common cases
<m_3> gotcha
<koolhead17> jcastro: in case of modifying juju-doc i only have to modify the rst file or have to some some compilation stuff as well
<jcastro> just the rst
<jcastro> there is a cronjob to generate the html
<jcastro> well, theoretically there is a cronjob but you don't have to worry about that
<koolhead17> so i pulled the doc bzr branch lp:juju/docs
<koolhead17> i will upload the changes in my branch and will it automatically get merged?
<koolhead17> am not very familier with workflow so asking
<jcastro> no, you make a branch, make your changes
<jcastro> then you submit a merge proposal
<koolhead17> k
<jcastro> on your branche's lp page there will be a "propose for merging" button
<jcastro> it's automagic if you do like lp:~yourusername/juju/whatever-the-fix-is
<jcastro> then you just click merge when it's ready and it'll pile up in the queue
<koolhead17> ok
<koolhead17> in https://juju.ubuntu.com/docs/provider-configuration-local.html  do you want me to add the askubuntu infos like the networking and other things which need to be checked
<koolhead17> jcastro: http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage/65360#65360
<_mup_> Bug #65360: [UNMETDEPS] libbonobouimm1.3 has unmet dependencies <libbonobouimm1.3 (Ubuntu):Fix Released by geser> < https://launchpad.net/bugs/65360 >
<hazmat> jcastro, net.ipv4.ip_forward=1?
<hazmat> that should be done by the libvirt packages
<jcastro> someone else added that, I don't recall ever having to need that
<koolhead17>  juju-origin: distro
<jcastro> koolhead17: I would move all that stuff into the official doc, and then edit the answer in there to point to the official docs when it's merged
<koolhead17> jcastro: cool so i will modify our doc by adding this and other parts, i will not add net.ipv4.ip_forward=1
<jcastro> well, somebody added it for a reason, maybe it was a bug that was subsequently fixed
<jcastro> either way, when you have it, test it a few times to make sure it works
<koolhead17> also writing a charm section we have to create a file is charm root name revision and have to have number 1
<niemeyer> <jcastro> yes, finally, lp:charms
<niemeyer> jcastro: I apologize for that one
<koolhead17> jcastro: i had to use option as mentined in askubuntu on my oneiric
<jcastro> niemeyer: it's ok, rather to fix it now than 6 months from now
<koolhead17> LXC setup
<niemeyer> jcastro: Other folks (I remember at least SpamapS) suggested that early on, and I was stubborn
<robbiew> hazmat: enjoy performing your civic duty...the price you pay when you register to vote ;)
<hazmat> robbiew, ain't you heard.. dc is 'taxation without representation'..
<hazmat> its on plate of every car
<robbiew> hazmat: yep...have family there, so know ALL about it
 * hazmat digs into some twisted changelogs
<hspencer> hazmat, hows it goin?  any progress on the txaws/walrus issue?
<hspencer> anything i can do to help
<hazmat> hspencer, i'm tracking down a twisted problem thats stopping builds on precise atm
<hazmat> hspencer, i suspect the euca issue is with the url signing and prefixes in txaws, we had some problems with that a few months back when doing openstack compatiblity
<hazmat> it sounds like something very similiar
<hazmat> except ostack didn't do suffixes on s3, so its probably the url signing not taking into account the url suffix is my guess
<hspencer> k
<hspencer> well, lemme know how i can help
<hspencer> i would like to try and get it working..also try it out with Eucalyptus 3.0
<hazmat> hspencer, is euca 3.0 out ?
<hspencer> you follow the devel branch of euca?
<hspencer> you should check it out
<koolhead17> hazmat: so the revision file in charm root directory keeps the major revision of the charm?
 * koolhead17 is editing juju docs
<hazmat> koolhead17, yes.. there are no minors.. just the one revision number kept in that file
<hazmat> koolhead17, its in a  separate file because things like the charm store have license to update it automatically to keep the revision monotonically increasing across individual branches of the same charm
<hazmat> so if one branch replaces trunk, the revision stays consistent
<koolhead17> hazmat: cool. cos i have to write one line info too :)
<koolhead17> hazmat: you want me to put same info along with it?
<hazmat> koolhead17, hmm.. a little to much detail for the intro
<hazmat> i'd just grab the revision info that used to be in  metadata.yaml that should suffice
<hazmat> user docs shouldn't be explaining infrastructure decisions unless needed for clarification
<koolhead17> hazmat: current doc in metadata.yaml says notthing about revision :(
<niemeyer> ----- lp:~charmers/charm/oneiric/couchbase/trunk
<niemeyer> ----- lp:~charmers/charm/oneiric/couchdb/trunk
<niemeyer> ----- lp:~charmers/charm/oneiric/etherpad-lite/trunk
<niemeyer> ----- lp:~charmers/charm/oneiric/ganglia/trunk
<niemeyer> You guys know what this is doing, don't you? ;-)
<niemeyer> SpamapS: ping
<SpamapS> niemeyer: pong, sup?
<niemeyer> SpamapS: Yo
<niemeyer> SpamapS: We have a small problem in certain charms
<niemeyer> SpamapS: Just going through them, but this is an example: lp:~charmers/charm/oneiric/minecraft/trunk
<niemeyer> SpamapS: The problem lies in its config.yaml
<niemeyer> SpamapS: Here:
<niemeyer>   spawn-animals:
<niemeyer>     default: true
<niemeyer>     type: string
<SpamapS> heh I see that
<niemeyer> SpamapS: Pondering about the best course of action
<SpamapS> that will become True
<SpamapS> or rather, bool(True)
<niemeyer> SpamapS: I think we should introduce bool, and fix existing charms
<hazmat> sounds good
<SpamapS> niemeyer: I've always wanted boolean types
<niemeyer> SpamapS: Ok, awesome
<niemeyer> hazmat: Who can help us on the Python side?
<SpamapS> I think in that case, we did actually fix that particular charm for this exact problem
<hazmat> niemeyer, i'm game
<SpamapS> But its going to be a common mistake
<niemeyer> SpamapS: As long as the author is warned immediately, it's fine I think
<niemeyer> hazmat: Awesome, thanks!
<niemeyer> hazmat: Should it be "bool", or "boolean"
 * SpamapS prefers english
<hazmat> given we spell out all the others, boolean
<niemeyer> Sounds good
<SpamapS> string, boolean, integer
<niemeyer> Poifect
<niemeyer> mpl: ping
<niemeyer> fwereade: ping
<niemeyer> That's called high-availability applied to task distribution ;-)
<niemeyer> Let's see.. we have a few others
<fwereade> niemeyer, heyhey
<fwereade> niemeyer, what can I do for you?
<niemeyer> SpamapS: That's yours:
<niemeyer>   nova-config:
<niemeyer>     default: /etc/nova/nova.conf
<niemeyer>     type: str
<niemeyer> SpamapS: In
<niemeyer> lp:~clint-fewbar/charm/oneiric/nova-cloud-controller/trunk
<niemeyer> fwereade: Yo!
<SpamapS> Oh we should definitely delete that one
<niemeyer> fwereade: I have a beautifully tiny and self-contained task for you
<fwereade> niemeyer, oh yes?
<niemeyer> fwereade: yeah.. introducing "boolean" types under juju/go/charm/config.go
<fwereade> niemeyer, sounds pretty hard to crew up catastrophically ;)
<fwereade> screw up^^
<niemeyer> fwereade: The changes are negligible
<niemeyer> chances
<fwereade> niemeyer, excellent, I may not have time tonight but it's top of the list for tomorrow morning :)
<niemeyer> fwereade: Oh yeah, go have some fun!
<niemeyer> fwereade: (in another way ;-)
<niemeyer> Hmm.. peculiar
<niemeyer> error: YAML error: line 5: found a tab character where an intendation space is expected
<niemeyer> investigating
<niemeyer> Wow, really?
<niemeyer> Can't YAML lines be indented by a space?
<niemeyer> Erm
<niemeyer> Can't YAML lines be indented by a tab?
<SpamapS> niemeyer: hmmmm
<SpamapS> niemeyer: I can't delete that branch
<niemeyer> SpamapS: WHy?
<SpamapS> niemeyer: the others stack on top of it
<niemeyer> "YAMLâs indentation-based scoping is similar to Pythonâs (without the ambiguities caused by tabs)."
<niemeyer> Straight from the spec..
<niemeyer> Which is.. amazing..
<niemeyer> For once, I found something that YAML finds invalid!
<niemeyer> SpamapS: Can't you delete the stacked ones too?
<SpamapS> niemeyer: launchpad doesn't tell me the 3 stacked on top of it
<niemeyer> SpamapS: :(
<SpamapS> niemeyer: I suspect one of those is the official branch though
<SpamapS> niemeyer: I may be able to fix with --overwrite, will ask #bzr
<niemeyer> SpamapS: Oh, that sounds clever
<_mup_> Bug #918386 was filed: config.yaml should have enum type  <juju:New> < https://launchpad.net/bugs/918386 >
<koolhead17> jcastro: https://code.launchpad.net/~koolhead17/+junk/jujudoc
<koolhead17> i have modified the revision file part there
<jcastro> SpamapS: m_3: https://juju.ubuntu.com/CharmSchool/Handout
 * robbiew begins flashing 200 Ubuntu Cloud Live USB sticks...13 at a time...whoohoo!
<koolhead17> jcastro: i created correct branch added a merge request!! :P
<mpl> niemeyer: sorry, was at kungfu practice. How may I be of service?
<niemeyer> mpl: Not a problem
<niemeyer> mpl: fwereade already took over the problem, so it's all good
<mpl> niemeyer: oh, ok then. still, what was it about? shall I just read the backlog?
<mpl> I see, booleans.
<mpl> oh well, time for a well deserved soup then.
<SpamapS> niemeyer: so, it may be more appropriate to ignore branches that are marked as anything other than 'Development' and 'Mature'...
<SpamapS> niemeyer: if somebody has taken the time to mark their branch 'Abandoned'.. seems like we should take their word for it... though it is troubling how hard it is to delete a branch
<jcastro> SpamapS: does "charm get mediawiki" work for you?
<jcastro> I get "mediawiki does not exist in official charm store."
<m_3> jcastro: you might make sure you have the latest charm-tools package
<jcastro> ok so ppa, got it
<niemeyer> SpamapS: Hmm, yeah, we could end up doing that indeed
<SpamapS> actually
<SpamapS> precise has done something foul with charm-tools
<SpamapS> or rather
<SpamapS> I did
<SpamapS> precise has 0.3, but the PPA has 0.2
<SpamapS> I'll fix that
 * SpamapS currently fixing tests to not be so fragile
<matsubara> hi there
<jcastro> Can you guys sanity check my example? https://juju.ubuntu.com/CharmSchool/Handout
<matsubara> I'm trying to write a charm for python-oops-tools (django application that uses postgresql). I successfully deployed a postgresql charm and the oops-tools charm. When I try juju add-relation postgresql oops-tools I get an ERROR No matching endpoints
<matsubara> could someone help me debug what's wrong with the oops-tools charm?
<SpamapS> matsubara: branch url?
<m_3> jcastro: you need a release directory
<m_3> maybe try:
<m_3> mkdir -p ~/charms/oneiric
<m_3> charm get mysql ~/charms/oneiric/mysql
<m_3> ...
<m_3> juju deploy --repository ~/charms local:mysql
<m_3> otherwise it'll be looking for an oneiric directory
<jcastro> man, I am so not going to miss that part when the CS lands...
<matsubara> SpamapS, https://code.launchpad.net/~matsubara/+junk/oops-tools-charm
<m_3> otherwise, looks quite nice
<SpamapS> matsubara: well you'll need to define a requires that has interface: postgres
<SpamapS> wait no
<SpamapS> matsubara: err, I mean interface: pgsql
<SpamapS> matsubara: http://bazaar.launchpad.net/~charmers/charm/oneiric/postgresql/trunk/view/head:/metadata.yaml
<SpamapS> matsubara: also since there are two, you'll have to always be explicit that you want the 'db' relation, or the 'db-admin' relation.
<SpamapS> matsubara: so 'juju add-relation oops-tools postgresql:db'
 * SpamapS runs off to find a bit of lunch
<matsubara> ah right. I was following the tutorial and thought the interface was postgresql
<SpamapS> matsubara: the postgresql charm is pretty bare bones, so feel free to dig into it and propose any changes that you might need.
<matsubara> SpamapS, is there a way to redeploy a service so it'll pick up the change to the charm?
<SpamapS> matsubara: upgrade-charm
<SpamapS> juju upgrade-charm --repository .. servicename
<bac> i'm trying to bootstrap locally and it hangs starting networking with "WARNING: gnome-keyring:: no socket to connect to" -- anyone know what the problem might be?
<SpamapS> bac: its trying to ask you for your sudo password
<bac> it looks like the gnome-keyring warning might not be relevant.  the bootstrap is hanging at net.start()
<SpamapS> bac: DISPLAY="" might help with that
<SpamapS> bac: after installing libvirt-bin, you have to logout/back in to get the correct groups.
 * SpamapS really has to eat now
<bac> SpamapS: i have rebooted since installing libvirt-bin
<matsubara> SpamapS, thanks! enjoy your meal. :-)
<jcastro> SpamapS: we need to come full circle
<jcastro> in 6 months we should rename it to principias
<jcastro> with an S
<SpamapS> jcastro: we're the boxers of the cloud.. stick and move.. never let 'em see where you're coming from ;)
<SpamapS> jcastro: btw, charm-tools in the PPA should be fixed
<jcastro> ta
<SpamapS> hrm.. interesting difference between bash and dash .. aliases seem to survive entering a function in dash.. basically they are global.. but in bash aliases seem to be removed inside functions
<SpamapS> jcastro: I was mistaken.. the PPA is still 2 hours away from building
<SpamapS> <sigh>
<jcastro> it's ok, I already knew that
<jcastro> i've budgeted time to test it tomorrow before I travel
<SpamapS> jcastro: you can force it with 'apt-get install charm-tools=0.2+119-7~precise1'
<m_3> SpamapS: juju-demo (just the container) and juju-classroom (container w ajaxterm) are both working
 * m_3 back to testing
<SpamapS> Speaking of testing... and stuff..
<SpamapS> nijaba: around?
<SpamapS> I'm thinking of turning off the peer tests entirely
<SpamapS> they're just too complicated
<SpamapS> and the stuff the peer helpers do is.. difficult to grok
<SpamapS> On thinking twice about it, I'm afraid we may have gone a bit too far
<SpamapS> nijaba: I think the peer copy things should probably be re-done in a proper language, and perhaps configured more like a traditional service... where the hooks just feed data in and the service handles the transfers.
<SpamapS>    30 helpers/sh/apparmor.sh
<SpamapS>   184 helpers/sh/net.sh
<SpamapS>   559 helpers/sh/peer.sh
<SpamapS> 500 lines of shell is just too much. ;)
<SpamapS>    71 tests/helpers/test_apparmor.sh
<SpamapS>   171 tests/helpers/test_net.sh
<SpamapS>   498 tests/helpers/test_peer.sh
<SpamapS> And the tests are similarly overly complicated
<dazz> howdy juju developers :D
#juju 2012-01-19
<m_3> dazz: o/
<dazz> SO!  I've been tasked to learn myself some juju.  Using a local environment.  All was well for the first deploy of wordpress/mysql - awesome.  Killed that environment.  Tried to write my own charm.  Got stuff installing.  Killed that environment, now I can't get anything out of a state: pending....
<dazz> where would you suggest I go to find why nothing seems to be happening?
<dazz> I'm getting feedback from debug-log - started service unit wordpress/0 - but juju status is still pending?
<m_3> dazz: so local provider can be a little quirky atm... we're workign to fix that
<dazz> kk.  So it's nothing that can be helped at the moment.
<m_3> what I'd recommend in the mean time is wiping your lxc cache when you see strange things happening
<dazz> hokaydokay
<m_3> make sure you start with a 'juju destroy-environment'
<m_3> then once everything's down, you can wipe /var/lib/lxc
<dazz> nothing seems to be present in /var/lib/lxc...
<m_3> hmmm...
<dazz> should juju always be run as root in this event?
<dazz> maybe it's a permission thing / not getting sudo where required
<m_3> well then I'd go through another cycle of 'juju bootstrap' and then deploy something
<dazz> should I try as root?
<m_3> so juju should be run as a user, but it'll ask for sudo password when it needs it
<m_3> better as a user
<dazz> yeah cool.  Thought as much
<m_3> try a 'groups' as the user
<m_3> make sure you see libvirtd
<m_3> try 'virsh net-list --all'
<m_3> should see 'default' and it should be active
<dazz> yeap
<dazz> confirmed both those
<m_3> ok, then bootstrap and deploy something
<m_3> during the first deploy, it's gonna sit in 'pending' state for a _long_ time
<m_3> (it's installing an operating system template)
<m_3> once you've successfully got something like mysql in a 'started' state, then subsequent deploys _should_ go quicker
<dazz> roughly how long is a "long" time?
<m_3> (it'll cache the machine template in /var/lib/lxc)
<dazz> 15-20 minutes?
<m_3> yeah... depends on your connection
<dazz> excellent.  Cheers.
<dazz> I know the first time was about 5-10 minutes.
<m_3> I'd worry if it takes more than 30mins... typically 10 for me I guess
<dazz> cool cool
<dazz> Is there a way to get feedback on it's current deployment?
<m_3> don't know the best way to see that with the local provider... lemme poke around
<m_3> dazz: so there're some lxc tools 'lxc-'<hit tab> and then some logs that go into your 'data-dir' configured in your .juju/environments.yaml
<dazz> what is roots passwords for the containers?  Default toor for lxc doesn't seem to work.
<dazz> does it use an environment setting?
<dazz> mysql seems to be running
<dazz> I can query it.  the mysqld service is not running however.
<m_3> dazz: does it show 'started'?  if so, you should be able to 'juju ssh mysql/0'
<m_3> it'll pick up your primary key
<dazz> juju reports that it's waiting for the unit to come up
<dazz> but lxc suggests it's already running
<m_3> ok, sounds good... the unit will take a bit once the machine is up to install msyql packages and actually run the charm
<dazz> hokay-dokay
<dazz> so rule number one - don't destroy the environments
<dazz> remove the units
<dazz> <_<
<m_3> you can ssh directly to the machine once it's running 'ssh -lubuntu 192.168.122.xxx'
<m_3> rule number one is to wait that first time for a full cache to be built... that happens a lot
<m_3> we've got some bugs open to better inform users what the heck is going on
<m_3> it's totally confusing and seems like it's jammed
<dazz> juju seems really awesome - but it's current documentation is pretty limited.
<m_3> yup
<dazz> so "long time" and... lol.  10 minutes is long for me XD
<dazz> I must have done something the first couple of times when deploying the charms...
<m_3> we're working hard to fix that
<dazz> no it's okay :)  That's what now-informed-users are for.
<m_3> ha!
<m_3> yeah, the next release is a long-term-support one, so it's gotta be cleaned up by then
 * m_3 bbaib... (coffeeshop -> home)
<dazz> cheers sir!
<dazz> o/
<m_3> dazz: on the way home I realized I told you the wrong cache to clear... it's /var/cache/lxc and not /var/lib/lxc
<dazz> ah ha
<dazz> let me try that.
<m_3> so if things still aren't good, I'd destroy the environment, wipe that cache, then try again
<dazz> cause it's still stalled.
<dazz> cheers!
<m_3> sorry
<dazz> it's all good.
<SpamapS> dazz: there's a bug that will cause it to wait forever on a failed instance...
<SpamapS> dazz: do you see an 'lxc-wait' running?
<dazz> not at the moment
<dazz> I see lxc-create
<dazz> it's probably working better at the moment since I've deleted that cache.
<dazz> as in debug-log I see it creating.  I haven't been posted "ready" yet.
<dazz> was just going to have a shower, come back and see how it's going
<dazz> when is the long-term support of juju being released?  In 3-6 months or something like that?
<SpamapS> Along with 12.04
<SpamapS> Though I expect quality will continue to improve well after that. :)
 * SpamapS disappears
<dazz> o/ SpamapS
<dazz> cheers
<dazz> bad file descriptor while attempting to start the containers....
<dazz> ooo
<dazz> shit be happening
<dazz> lol
<dazz> m_3: you about good sir?  How does one debug the db-relation-changed process?
<dazz> oh....  appears while debugging you hold commands back.... hang 2. Think I'm okay.
<SpamapS> dazz: juju debug-hooks
<SpamapS> dazz: opens a tmux window with the name of the hook you are meant to run
<dazz> yes but when you catch lets say, a db-change and a new terminal opens... changes don't happen (like, updating the charm or another db-relation-change) until that window is closed.
<dazz> or so it appears.
<SpamapS> right
<SpamapS> thats the entire point. :)
<dazz> yeah I missed that <_<
<dazz> so I was screaming why -x wasn't working
<dazz> when a new tmux window is opened, am I meant to be seeing output of what's going on in my script?
<SpamapS> no you're meant to run your script
<SpamapS> or pretend to run it and do something else..
<SpamapS> its pausing just before execution, and will respect the return code of your shell (so if you 'exit 1' during an install hook, then your service will be in state: install_error)
<dazz> fantastic
<dazz> !
<dazz> !!!!
<dazz> lol
<dazz> awesome - so - I can only do the script - while in that state.
<SpamapS> right, thats the idea
<dazz> re: when I was trying ./db-relation-changed I was probably in db-relation-joined
<dazz> cheers
<dazz> yeap
<dazz> getting it
<dazz> man I am so documenting all of this
<SpamapS> https://juju.ubuntu.com/docs/write-charm.html#debugging-hooks
<SpamapS> good luck
 * SpamapS goes off to do family stuff
<dazz> cheers again sir
<dazz> so, is it possible to have two databases on the one mysql unit?
<niemeyer> Morning!
<rog> niemeyer: yo!
<mpl> hello gustavo
<andrewsmedina> hi
<lynxman> nijaba: Hey nijaba, what was the charm that you wrote that uses certificate transfer between charms?
<lynxman> nijaba: nevermind found it
<lynxman> when you do a juju charmname set var=something it calls config-changed right?
<marcoceppi> lynxman: Correct
<lynxman> marcoceppi: cool. thanks :)
<_markh_> I'm new to juju - have a basic question. I understand juju works with LXC ( http://cloud.ubuntu.com/2011/09/juju-in-11-10-beta2-lxc-and-openstack-improvements/ ), but it's not clear to me whether that behaviour made it into oneiric. I'm also having trouble tracking down how I'd go about telling deploy to use LXC rather than Amazon ECS. Is there some fairly complete documentation somewhere?
<koolhead17> _markh_: askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage  might help
<_markh_> Thx
<hazmat> argh.. digging out this twisted regression is definitely like being a rat in a maze
<jimbaker> hazmat, in twisted itself?
<hazmat> jimbaker, yeah.. some sort of change to ssl handling had a regression from 11.0 to 11.1 wrt to juju's usage for orchestra provider storage usage
<jimbaker> hazmat, got the scope
<hazmat> i tried treating the sympton which gets most of the tests working except some which just hang.. just digging through the changelog and while its germaine its not realy clearly what's the operational change.. http://twistedmatrix.com/Releases/Twisted/11.1/NEWS.txt
<secbrid> chaps when i run juju status -e sample the output seems to be yaml parse-able , however the command also spits out the INFO section so that if i parse the output to python  and run print yaml.load(status_command_output) it errors on the last line. Is there a way to output in pure yaml or without the INFO status line?
<hazmat> secbrid, afaicr it should log on stderr and output on stdout
<hazmat> if not then it should get a bug report
<secbrid> ooh riight!! excellent! thanks hazmat will check that now
<SpamapS> indeed, logs are on stderr over here
<secbrid> nice that works when i separate out the streams. thanks guys
<m_3> lp:charm is now lp:charms
<m_3> change your push branches accordingly (i.e., lp:~mark-mims/charms/oneiric/mycharm/trunk)
<SpamapS> bzr pull --remember lp:charms/foo works
<poolie> you'll need to re-set the push location separately
<SpamapS> is there a way to do that without calling push --remember ?
<SpamapS> reconfigure doesn't seem to have an option
<SpamapS> poolie: ?
<poolie> vi .bzr/branch.conf
<poolie> or i think maybe bzr configure
<poolie> bzr config push_location=lp:....
<SpamapS> perfect
<SpamapS> oh and that makes extracting the current values cleaner too
 * SpamapS de-awks his script
<m_3> does that make it less awk-ward?
<SpamapS> less tawk more rawk
<m_3> wow, it's just stand-up night in the channel
<koolhead17> is someone doing something at http://charms.kapilt.com/charms
<koolhead17> i see charms being repeated in the list
<koolhead17> jcastro: sir if you have time check at my merge request :)
<m_3> koolhead17: I think jcastro is traveling right now
<koolhead17> m_3: ooh okey.
<m_3> koolhead17: also we've made some changes to launchpad that'll cause problems for all charm-related tools
<m_3> fixes in progress, but it'll probably leak into the weekend for some tools
<koolhead17> m_3: np. i just saw so was bit confused.
<SpamapS> hazmat: I suspect charms.kapilt.com needs to be redirected at the new lp:charms
<SpamapS> oh looks like it was, but something else caused the dupes
<hazmat> hmm, haven't addressed it at all
<hazmat> curious how it handles ;-)
<hazmat> ah.. dups everything because it keeps historical values
<hazmat> on the notion that once published ... well its published and possibly installed
<hazmat> i'll reset it
<SpamapS> hazmat: how long should it take to refresh?
<m_3> SpamapS: looks like it's refreshed
<hazmat> yeah.. should be good now
<SpamapS> ah ok it wasn't at 13:54, done now. :)
<SpamapS> hazmat: thanks!
<SpamapS> doh
 * SpamapS now knows what its like to try and inhale about 0.5oz of sugar free red bull
<SpamapS> swallowing + laughing == near death experience
<hazmat> SpamapS, a cautionary tale ? ;-)
<SpamapS> The Curse of The Caffeine Addicted Hacker
<avoine> hehe
#juju 2012-01-20
<negronjl> SpamapS: I approved your merge request (https://code.launchpad.net/~clint-fewbar/charms/oneiric/mediawiki/misc-fixes/+merge/89369)
<SpamapS> negronjl: sweet thanks
<nijaba> lynxman: reg certificate transfer, I would recommend you to have a look at https://code.launchpad.net/~nijaba/charms/oneiric/drupal/nb (which is still waiting for a review - hint) as it is I think the best example.
<lynxman> nijaba: thanks :)
<tyska> hello guys
<tyska> niemeyer: are u there?
<niemeyer> tyska: I am indeed
<niemeyer> tyska: How're things?
<tyska> niemeyer: evolving
<niemeyer> tyska: That's good :)
<tyska> niemeyer: if someday you come to RG, come here to visit us
<niemeyer> tyska: Will do.. where are you located?
<tyska> i am on FURG - campus carreiros
<niemeyer> tyska: Ok, any department/subdepartment?
<tyska> yeah, Centro de CiÃªncias Computacionais - C3
<niemeyer> tyska: Nice name :)
<_markh_> I'm using juju to set up some local (LCX) services on a single system. When that sys reboots, none of the services restart and juju status says "ERROR could not connect before timeout". How can I restore to the previously running state?
<_markh_> LCX==LXC ... doh!
<niemeyer> _markh_: Yeah, I could guess it :)
<niemeyer> _markh_: There are two different angles to that question:
<niemeyer> _markh_: The local LXC provider is really meant to be used for local experimentation
<niemeyer> _markh_: Rather than for actual deployments
<niemeyer> _markh_: So it won't survive a reboot
<niemeyer> _markh_: The second angle is that the constraint of rebooting was inherited from the prototyping stages even for EC2
<niemeyer> _markh_: So the story isn't great with the trunk code
<niemeyer> _markh_: On the bright side, though, the code fixing that is up for review already
<_markh_> That's OK - we're not looiking to deploy immediately with juju. As long as I know the contraints then all is well
<_markh_> Good to hear that there are improvements in the pipeline (12.04 ? )
<niemeyer> _markh_: Cool.. so yeah, definitely in good ground there. Don't use the local provider for real stuff.
<niemeyer> _markh_: There's a _big_ pipeline :-)
<_markh_> :)
<niemeyer> _markh_: There's code landing every week, and there will be for the foreseeable future
<tyska> niemeyer: do you have some new about that juju + eucalyptus problem?
<_markh_> I'm really excited for juju. It could absolutely help with the deployment issues we struggle with.
<_markh_> Thx.
<niemeyer> tyska: Hmm.. sorry, do you have a bug number?
<tyska> niemeyer: yeah, wait a minute
<niemeyer> _markh_: That's great to hear.. it's indeed the kind of problem we're aiming at helping people on
<tyska> niemeyer: 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 >
<niemeyer> tyska: Not much action there yet
<niemeyer> tyska: I'll clarify the problem for the folks asking
<tyska> niemeyer: great, thanks! ;)
<niemeyer> tyska: np, sorry it wasn't fixed yet
<tyska> np
<mpl> niemeyer: that carmack quote is brilliant :)
<niemeyer> mpl: And true! :)
<mpl> yep
<Ng> I'm wondering about running juju in an openstack cloud - I know the juju docs currently say that only ec2 is supported as a cloud, but I'm guessing openstack support is coming. Is it something I can play with ahead of time if I run juju from, say, trunk?
<lynxman> question, when a new charm is deployed, after finishing install it'll always execute config-changed?
<hazmat> lynxman, more specifically.. it will always execute config-changed when starting the service before executing the start hook
<hazmat> Ng, openstack is supported
<lynxman> hazmat: yeah just realised :) silly me
<lynxman> hazmat: thanks
<hazmat> np
<hazmat> ah.. the faq needs updating
<mbarnett> hazmat: To run on an openstack implementation is it just a case of updating the type in environments.yaml to openstack and adding the appropriate keys there?
<hazmat> mbarnett, the default-image-id also needs to be specified in addition to the ostack credentials.. on the openstack side we use the ec2 apis to talk to openstack so either s3server.py needs to be running or the swift s3 middleware.
<mbarnett> hazmat: okay, thanks.
<andrewsmedina> hazmat: it's possible I use openstack + s3?
<hazmat> andrewsmedina, no.. the ec2/aws provider assumes the same credentials are valid for storage and compute, the s3 server could be setup just for juju's minimal storage usage if their isn't any need for the object storage server in the deployment
<andrewsmedina> hazmat: I'm having problem to have the same authentication in nova and swift
<hazmat> andrewsmedina, if your just looking to get started.. s3server.py is basically just a single module python s3 server (in nova), afaicr it doesn't even bother with verifying the signed url authentication.
<hazmat> andrewsmedina, are you using keystone for both nova and swift?
<andrewsmedina> hazmat: im using tempauth for swift
<andrewsmedina> hazmat: I will try s3server.py instead swift
<lynxman> hazmat: quick question for you sir, any easy way to know the zk instance address from a juju instance?
<hazmat> lynxman, its in the cloud-init data, and environ of the agents
<lynxman> hazmat: so how can I recover it from the environ?
<hazmat> lynxman, cat /proc/<pid-of-agent>/env
<hazmat> er. /environ
<lynxman> hazmat: thanks :)
<_mup_> juju/twisted-precise-compat r444 committed by kapil.thangavelu@canonical.com
<_mup_> orchestra storage provider twisted 11.1 forward compatibility
<hazmat> jimbaker, how goes?
<hazmat> bcsaller, jimbaker would either of you mind looking at this trivial, it fixes the precise builds. https://code.launchpad.net/~hazmat/juju/twisted-precise-compat/+merge/89490
<jimbaker> hazmat, good. did you have a chance to talk w/ bcsaller about niemeyer's review of the subordinate spec?
<jimbaker> hazmat, i'll take a look at the trivial
<hazmat> jimbaker, i didn't, i looked over the niemeyer's review though
<jimbaker> imho, i don't really such much implementation difference between the two approaches
<hazmat> bcsaller, give me a ping when your up for a chat re spec
<hazmat> i'd still like to flush out the relation structure on disk
<hazmat> er. zk
<bcsaller> hazmat: I can do it in 2 minutes if you'd like
<jimbaker> hazmat, as far as i could see, that's the only real diff, but it doesn't really carry into the impl - either is fine
<hazmat> hey smoser what's cirros?
<smoser> https://launchpad.net/cirros
<smoser> in a nutshell, ttylinux-uec version 2.0
<jimbaker> hazmat, +1 on the trivial
<jimbaker> i appreciate the good doc on rationale
<hazmat> jimbaker, thanks... took way to long to find that magic line
<jimbaker> hazmat, definitely understand that! :)
<bcsaller> hazmat: yeah, the trival looks fine, but the api around _completelyDone *sigh*
<hazmat> bcsaller, what api ? ;-)
<bcsaller> yeah
<bcsaller> and why the default it has?
<hazmat> bcsaller, because by default most http requests are request/response and done
<bcsaller> I'd say most client code wants to follow redirects though
<hazmat> bcsaller, this one just signals that it might be multiple request/responses before the semantic request result is obtained
<hazmat> true
<bcsaller> hazmat: want to have that talk now? shame gustavo isn't around
<hazmat> bcsaller, sounds good re talk
<SpamapS> hrm... "lightning" talks that are 15 minutes long.. more like thunder talks. :p
<_mup_> juju/trunk r444 committed by kapil.thangavelu@canonical.com
<_mup_> [trivial/merge] fix orchestra storage provider compatibility with twisted 11.1 [r=jimbaker,bcsaller][f=917954]
<_mup_> juju/upgrade-config-defaults r432 committed by kapil.thangavelu@canonical.com
<_mup_> merge trunk
<_mup_> juju/upgrade-config-defaults r433 committed by kapil.thangavelu@canonical.com
<_mup_> address review comments
<_mup_> juju/trunk r446 committed by kapil.thangavelu@canonical.com
<_mup_> merge upgrade-config-defaults, config values are lazily instantiated. [r=bcsaller,fwereade][f=900560]
<_mup_> Previously configuration values where prepopulated from defaults, now
<_mup_> values are lazily computed from explicitly set values, and defaults.
<_mup_> For charm upgrades config values not explicitly set will recieve now new
<_mup_> charm defaults.
#juju 2012-01-21
<_mup_> Bug #919514 was filed: use a write ahead log for transitions <juju:New> < https://launchpad.net/bugs/919514 >
<nijaba>  /msg NickServ identify oakland22
<nijaba> great...
<mpl> heh
<koolhead17> nijaba: :P
<SpamapS> nijaba: HA HA
<nijaba> never been such a great time to change a password :)
<koolhead17> SpamapS: sir
<SpamapS> koolhead17: sir
<_mup_> Bug #919745 was filed: config-changed should be invoked after upgrade <juju:New> < https://launchpad.net/bugs/919745 >
<_mup_> juju/trunk r447 committed by kapil.thangavelu@canonical.com
<_mup_> trivial resolve test config set errors from not taking into account charm defaults
#juju 2012-01-22
<hazmat> argh.. the state of quantum and openvswitch in precise is rather sad
<_mup_> Bug #920000 was filed: 2012-01-22 21:59:44,005 ERROR Failed to launch machine MTMyNzIzOTgxNi44OTA5Nzg5OS43NDY5Mw; attempting to revert. <juju:New> < https://launchpad.net/bugs/920000 >
<sara89> ciao
<sara89> !list
<SpamapS> The SCALE talk went well I think
<SpamapS> good questions
<SpamapS> lots of interest
<pindonga> hi all... juju works against openstack? (ie, can I deploy to openstack instead of ec2?)
<SpamapS> pindonga: yes ,using the openstack EC2 api compatibility
<SpamapS> pindonga: you will need to set some extra parameters, s3-uri and ec2-uri,
<pindonga> SpamapS, I did so, but I get this error: Error Message: The AWS Access Key Id you provided does not exist in our records.
<SpamapS> pindonga: http://askubuntu.com/questions/65364/how-can-i-configure-multiple-deployment-environments-for-juju
<SpamapS> pindonga: make certain you have changed everything necessary...
<pindonga> SpamapS, ah, I was using environment variables for the secrets
<pindonga> had to replace them with the real values
<pindonga> thx
<SpamapS> pindonga: the env vars should still work for the secrets
<SpamapS> interesting...
<SpamapS> I just now noticed that we don't ever specify AvailabilityZone in juju's ec2 provider .. resulting in random placement
<nijaba> SpamapS: random or always East-1 (default)?
<SpamapS> random
<SpamapS> nijaba: us-east-1 would be the region... then you have 1a, 1b, et
<SpamapS> c
<SpamapS> nijaba: perhaps the real answer is that 1b has been expanded and so Amazon just started spawning things there
#juju 2014-01-13
<lazypower> Woo new ghost release today. I smell a charm upgrade in my future
<popey> hmm. juju init && sudo juju bootstrap && juju deploy minecraft && juju expose minecraft, i can see no minecraft running
<popey> the expose works, it gets an ip, and I can juju ssh into the container
<popey> looking at the charm it should put it in /opt in the container, my container is empty
<popey> for local, where is this logged?
<mgz> what does juju status say?
<marcoceppi> popey: https://github.com/juju/charm-tools/commit/349f9c7153c7a79ade358cce500d656ee591b8cf
<marcoceppi> oops
<marcoceppi> popey: https://juju.ubuntu.com/docs/config-LXC.html#debug-log
<popey> http://paste.ubuntu.com/6745466/ is juju status
<marcoceppi> popey: yeah, the unit hasn't started yet, it's still in a pending state
<marcoceppi> popey: tail -f ~/.juju/local/log/unit-minecraft-0.log should reveal what's going on
<popey> ok
<popey> http://paste.ubuntu.com/6745472/
<popey> git
<popey> ?
<marcoceppi> popey: you've got an old cloud image
<marcoceppi> git is used by juju-core internall
<popey> ok
<popey> where did that cloud image come from?
<popey> I just updated juju and destroyed everything and started again
<popey> how do i update it?
<marcoceppi> popey: can you show the output of `sudo ls -lah /var/cache/lxc/cloud-precise`
<popey> -rw-r--r-- 1 root root 221M Jun 24  2013 ubuntu-12.04.2-server-cloudimg-amd64-root.tar.gz
<popey> -rw-r--r-- 1 root root 220M Mar 25  2013 ubuntu-12.04-server-cloudimg-amd64-root.tar.gz
<marcoceppi> popey: yeah, old images. Run `sudo juju destroy-environment`, then `sudo rm -f /var/cache/lxc/cloud-precise/*cloudimg*.tar.gz` then run your bootstrap commands above again
<popey> ok
<popey> thank you
<marcoceppi> np, let me know if that doesn't resolve it for you
<ghartmann> btw, so far my experience with juju is excellent
<marcoceppi> ghartmann: glad to hear!
<ghartmann> I just though of giving a feedback on that
<popey> marcoceppi: same again
<popey> http://paste.ubuntu.com/6745793/ is my ~/.juju/local/log/unit-minecraft-0.log
<lazypower> popey: are you bootstrapping on a 12.04 host?
<popey> ya
<lazypower> Ok, 1 sec
<lazypower> let me try to reproduce what you're seeing
<lazypower> popey: it completed here without a hitch. really odd, this must be due to the cloudtools marco was pointing at earlier. Its not ideal but you can work around this by entering a juju debug-hooks and sudo apt-get install git-core
<jcastro> negronjl, hey did you get a chance to look at the mongo charm?
<marcoceppi> popey: if it's still not working then there's something else wrong. no git package measn cloud-init isn't running, can you ssh ubuntu@<lxc-container-ip> for minecraft/0 and pastebin the /var/log/cloud-init* files?
<popey> marcoceppi: http://paste.ubuntu.com/6746061/ and http://paste.ubuntu.com/6746063/
<marcoceppi> popey: here's the problem
<marcoceppi> http://paste.ubuntu.com/6746074/
<marcoceppi> cloud-init isn't able to install git
<marcoceppi> I have no idea what that error means
<popey> bug 969299
<_mup_> Bug #969299: apparmor prevents dpkg-divert and localedef from working in a container <rls-mgr-p-tracking> <apparmor (Ubuntu):Confirmed> <lxc (Ubuntu):Fix Released> <apparmor (Ubuntu Precise):Won't Fix> <lxc (Ubuntu Precise):Fix Released> <https://launchpad.net/bugs/969299>
<popey> found via bug 936981
<_mup_> Bug #936981: apt-get dist-upgrade fails to upgrade udev in lxc container <udev (Ubuntu):New> <https://launchpad.net/bugs/936981>
<marcoceppi> OH APPARMOR
<marcoceppi> booo
<marcoceppi> I thought this was fixed already
<popey> i am on lxc 0.7.5-3ubuntu69
<popey> guessing this is because I'm not using an ubuntu kernel on my server?
<popey> using upstream 3.12.5 because btrfs
<marcoceppi> popey: that shouldn't be an issue? I'm not sure wrt that
<jcastro> I wonder if it's the LXC in 12.04?
<jcastro> there were other issues with juju and containers in 12.04 iirc.
<negronjl> jcastro: still working on it ... it's proven more difficult than expected.
<jcastro> oh ok, but you've confirmed there's a problem?
<jcastro> lazypower, we are not crazy!
<lazypower> Debateable
<popey> should I file a bug somewhere?
<marcoceppi> popey: file one against juju-core I suppose. While it's not jujus fault they should be aware of it
<marcoceppi> The fixed LXC version needs to be in the cloud-tools archive
<marcoceppi> for precise
<popey> oh, it's broken lxc?
<jcastro> I think that's the problem
<jcastro> I am not 100% sure though
<popey> bug 1268689
<_mup_> Bug #1268689: juju on 12.04 can't install packages in lxc containers <juju-core:New> <https://launchpad.net/bugs/1268689>
<marcoceppi> popey: there's a later release of lxc that works around this apparmor issue. It's not a problem in raring, saucy, or trusty AFAIK
<thumper> kirkland: ping
<thumper> kirkland: can we organise a call some time this week
<kirkland> thumper: pong
<thumper> kirkland: I want to talk about closed network stuff
<kirkland> thumper: sure
<kirkland> thumper: I'm in another call at the moment
<thumper> kirkland: I have a call with mramm shortly too
<thumper> kirkland: could do later today
<thumper> ?
<thumper> or tomorrow around this time?
<kirkland> thumper: cool -- what's your timezone?  seems like an odd time to see you online :-)
<thumper> kirkland: UTC+13
<kirkland> thumper: let me grab a bit of lunch, and then I'll ping you today
<mramm> kirkland: thumper: back... sorry trying to balance a lot of crazynes this week
<thumper> mramm: sure, np
<jcastro> marcoceppi, when you get a minute let's talk charm school
<jcastro> most of it will be your availability
<marcoceppi> jcastro: lets do it now
<jcastro> ok
<jcastro> what's your availability on fridays for the next month?
<jcastro> do you have like 2 days in mind we could do?
<marcoceppi> I'm out the 21st and 24th due to travel and this friday looks a bit heavy
<marcoceppi> 24th, 31st*
<marcoceppi> 7th is next available friday
<marcoceppi> though we could do one this Thursday
<jcastro> I'd like to give people more of a warning
<jcastro> marcoceppi, how about 17th of this month?
<jcastro> +7th?
<marcoceppi> 7th of feb
<marcoceppi> this friday is heavy for me as for availablility
<jcastro> oh right, sorry, dumb calendar indicator never highlights _today_ properly
<jcastro> marcoceppi, how's 21 feb look to you wrt. the 2nd one?
<marcoceppi> jcastro: we'll be in LA
<marcoceppi> for SCALE
<achiang> hi, i'm still trying to puzzle my way through juju + osx + vagrant. i've gotten as far as installing and configuring vagrant properly, and going to 127.0.0.1, i do successfully get a juju gui
<achiang> question is, what's next? should i install juju from brew, and try to manipulate charms on the locally running vagrant image?
<achiang> or do i ssh to the vagrant image (using the sshuttle technique) and develop charms there?
<marcoceppi> achiang: you can just run vagrant ssh, that will log you in to the unit where juju is running
<kirkland> thumper: I'm back from a very short lunch now
<marcoceppi> the vagrant image is a self contained local environment with a working juju install achiang
<thumper> kirkland: otp with mramm now
<marcoceppi> if you want to drive any other environmnt, achiang, other than local, then you'll need to brew install juju and use that to drive ec2, openstack, azure, etc
<achiang> marcoceppi: ok, for what i'm playing with, i want to pretend the vagrant image *is* the cloud unit and do interesting things with it. so i think for me, i need to figure out how to open up some other ports on it
<marcoceppi> achiang: not quite, the vagrant image is just an ubuntu machine. The LXC machines on that are the cloud
<marcoceppi> achiang: the sshuttle is the port opening stuff
<achiang> marcoceppi: hm, ok
<marcoceppi> so it's a bit of an inception. You have OSX, then you're running an Ubuntu VM, then you're running a small cloud inside that VM
<achiang> brain... melting ;)
<marcoceppi> hah
<marcoceppi> I mean, if you want to think of the vagrant image as the cloud, that's fine
<jcastro> - Writing your own Juju plugins
<jcastro> - Using Juju Bundles
<jcastro> are the next 2 topics marcoceppi
<marcoceppi> but it's a corner case achiang the local provider is special in what it does
<marcoceppi> jcastro: I like those, those are good topics
<marcoceppi> the plugins is like a 20 min talk
<marcoceppi> bundles are probably 45-60
<jcastro> bundles seem more useful for users for now
<marcoceppi> yeah, rotate 'em around
<jcastro> whereas plugins is more advanced and for users
<jcastro> so let's do bundles on the 7th?
<marcoceppi> We could even just do a quick ad-hoc plugins video
<marcoceppi> jcastro: yeah
<marcoceppi> make it so!
<achiang> marcoceppi: ok, maybe the question i really want to answer is, "how do i deploy my own test charm onto this vagrant image?"
<marcoceppi> achiang: cool, after running vagrant up; run vagrant ssh
<marcoceppi> then run your juju commands from there
<achiang> marcoceppi: ah, ok
<achiang> marcoceppi: thanks, i'll play around with it
<marcoceppi> achiang: np, let me know!
<kirkland> thumper: want to turn that into a hangout?
<thumper> kirkland: it is a hangout :-)
<dpb1> marcoceppi: Hi, did you get a chance to look over that storage charm?
<achiang> some super minor feedback, but reading through the charm tutorial... i was skimming it and didn't realize that "vanilla" is actually the name of some software package
<achiang> i saw this command line in step #2 - juju charm create vanilla
<achiang> and thought that was the command to create an empty charm
<achiang> wasn't until later that i realized that vanilla was something real
<achiang> :-/
<achiang> argh. just tripped over https://bugs.launchpad.net/juju-core/+bug/1233497
<marcoceppi> dpb1: Was just reviewing it now
<marcoceppi> initial thought, I like the structure of it, very interesting idea, I have some concerns about data handling but I'll be outlining it in the review tonight. bcsaller also has some opinions on it that he'll way in with on the bug report
<marcoceppi> achiang: there's a way around that
<marcoceppi> achiang: https://juju.ubuntu.com/docs/config-LXC.html#debug-log
<dpb1> marcoceppi: OK, looking forward to it, thx
#juju 2014-01-14
<timrc> Does the config option need to be defined in a yaml file before it can be settable?  I'm charming a service with nested configuration options.  I have a "channels" config option which is a coma-delimited list encapsulated in a string but for each channel I would like to have a "<channel>_devices" config option which encapsulated a coma delimited list inside a string
<mgz> timrc: yes
<mgz> everything should be in config.yaml so you can't have pseudo-lists
<timrc> mgz, Can I specify multiple config yamls? (e.g. config.yaml has the base config and then a local.yaml which not part of the charm but is used to deploy a specific instance/set of instances)
<timrc> er as the base config*
<mgz> no.
<mgz> you can just be cleverer about what you're packing into your string
<timrc> mgz, ugh
<mgz> there might be a neater way of doing what you're attempting, that some experienced charmer could explain if you give the whole problem
<timrc> mgz, I'm just going to use a ConfigParser-type config file, point to it in the config.yaml, and have my config-changed script read and Do The Right Thing (tm)
<mgz> timrc: config.yaml just describes the config
<mgz> your charm needs to get the values out when hooks run using the juju commands
<lazypower> marcoceppi: im' getting a key error on admin-secret, i'm in the local environment for juju, and the trace is: http://paste.ubuntu.com/6750920/
<lazypower> this is regarding an amulet test - btw. not juju core, i should specify that.
<marcoceppi> lazypower: yeah, this is a deployer error, do you have an admin-secret key set for your local environment?
<lazypower> i dont want to answer that...
<lazypower> i do not (facepalm)
<marcoceppi> admin-secret is used by deployer because it's the password for gui
<marcoceppi> that's why deployer is failing, since amulet uses deployer to drive deployments you have your answer
 * marcoceppi makes note to make deployer fails nicer
<lazypower> That i knew. My environments.yaml has changed from what i remember it being, or I'm thnking of my juju lab. 1 sec while i run this down.
<jcastro> man, what happened to the queue
<jcastro> we were doing so well!
<marcoceppi> jcastro: all in due time my friend
<sinzui> marcoceppi, jcastro: How do I bootstrap juju on trusty. I know how to make a charm go to trusty, but not bootstrap the state-server on trusty
<jcastro> the bootstrap node is trusty
<lazypower> man I think i just hozed my juju installation :| I've got a leftover in here somewhere after downgrading from 1.17 thats breaking my local provider
<lazypower> ERROR TLS handshake failed: x509: certificate signed by unknown authority
<marcoceppi> lazypower: delete ~/.juju/environments/local.jenv
<marcoceppi> sinzui: default-series: trust?
<marcoceppi> I've never tried to make a trusty bootstrap node
<sinzui> marcoceppi, yeah, that is the only way I know too
<marcoceppi> sinzui: did it not work?
<sinzui> marcoceppi, we haven't checked yet. actually, I do know that method works. We wanted to use an existing env in yaml, but just change the series
<arosales> sinzui, does bug 1254401 only affect 1.17?
<_mup_> Bug #1254401: error reading from streams.canonical.com <bootstrap> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1254401>
<arosales> sinzui, specifically is 1.16 not effected
<sinzui> arosales, it affects 1.16+ it will be fixed when we deploy to the site
<arosales> sinzui, so all deploys are dead in the water this whole week?
<sinzui> arosales, there is nothing for a developer to do the bug cannot be in progress, or if it is, utlemming is working on it
<sinzui> arosales, the site has  never been up
<arosales> I am just wondering if folks know the severity
<sinzui> arosales, the bug was filed months ago
<arosales> sinzui, understood but 1.16 worked before .  .
<sinzui> arosales, juju always tries the tools-url, then streams.canonical.com then aws
<sinzui> oh, it looks in the control bucket first
<arosales> sinzui, oh so deploys should still work after streams.c.c fails
<arosales> sinzui, sorry I thought deploys were broken all together
<sinzui> arosales, CI has never failed because the site doesn't exist
<arosales> sinzui, whew
<arosales> sinzui, I understand now, thanks for clearing that up.
<sinzui> arosales, log show a a lot of hate, then juju comes to terms with the issue and moves on
<arosales> sinzui, gotcha and thanks for the education
<arosales> mbruzek, note your hp deploy should succeed after the errors ^
<mbruzek> right according to the workaround in the bug 1254401 I was able to get this to work with the following
<_mup_> Bug #1254401: error reading from streams.canonical.com <bootstrap> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1254401>
<mbruzek> juju bootstrap -e hpcloud --upload-tools
<sinzui> mbruzek, no need to that
<mbruzek> no?
<mbruzek> juju bootstrap -e hpcloud ended in Error the first time I tried it
<mbruzek> juju sync-tools didn't work either.  Same error
<sinzui> mbarnett, each CPC has a local copy of tools. Looks like Juju doesn't check for the CPC tools, but you can tell it to
<sinzui> mbruzek, ^ add tools-url: https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910/juju-dist/tools
<mbruzek> I was only able to get it to work with the --upload-tools
<sinzui> mbruzek, I understand that feature will be removed in the future, but will work for a few more months. it is often abused
<mbruzek> OK
<sinzui> mbruzek, tools-url will be renamed tools-metadata-url. It will always to the right thing and do it quickly
<mbruzek> OK so add tools-metadata-url: https://... to my environments.yaml file under hpcloud?  Or tools-url?  This is for trusty and 1.17?
<mbruzek> adding tools-url
<jcastro> mbruzek, hey so devel release questions will be closed on askubuntu, things like that where stuff is fast moving should be on irc or the mailing list.
<mbruzek> I was trying to document this for others, and build rep.
<jcastro> yeah that won't work. :)
<lazypower> jcastro: should this be removed then? http://askubuntu.com/questions/405472/how-can-i-downgrade-my-juju-revision
<jcastro> I would drop the specific versions
<jcastro> and make it more generic
<jcastro> "How do I revert from a development version of Juju to a production one?"
<lazypower> Thanks. Completed.
<marcoceppi> hey, juju-core guys, what does JUJU_HOME expect as a value? With or without the .juju directory? natefinch?
<natefinch> marcoceppi: with
<marcoceppi> natefinch: ta!
<natefinch> marcoceppi: /home/foo/.juju is the default value for JUJU_HOME
<marcoceppi> natefinch: that's what I was looking for, awesome
<natefinch> i.e., if you set it, we don't put a .juju folder in the folder we specify, we just dump data directly in that directory
<natefinch> s/we specify/you specify
<marcoceppi> mbruzek: I couldn't get hpcloud to bootstrap with tools-url, were you able to get a bootstrap?
<mbruzek> Yes only with the --upload-tools
<mbruzek> It was already running from that, so my tools-url is untested
<marcoceppi> mbruzek: nvm, I got it working had to remove the .jenv file
<jcastro> marcoceppi, the postgres review wasn't as heavy as I thought it would be
<jcastro> so I just pushed
 * jcastro cowboys
<marcoceppi> jcastro: yeah, stub does a great job maintaining the charm already
<marcoceppi> _thumper_: did the default behavior of destroy-environment change from using a -e flag to just a parameter?
<marcoceppi> I could have sworn it used to be -e flag
<thumper> marcoceppi: yes
<thumper> marcoceppi: the name of the environment is now always needede
<marcoceppi> thumper: y u do dis
<thumper> marcoceppi: no, nate
<thumper> marcoceppi: primary reason was to make someone type 'juju destroy-environment production'
<marcoceppi> and just like that, half of my scripts broke because -e is no longer a valid flag
<thumper> instead of just getting the name from the environment
<marcoceppi> https://juju.ubuntu.com/docs/charms-destroy.html#destroy-environments needs updating too
<marcoceppi> thumper: when did this change land? or is it a 1.17 thing?
<marcoceppi> I can't recall this being an issue in 1.16
<thumper> marcoceppi: I think so
<marcoceppi> ohhh, this will be tricky
<marcoceppi> can I file a regression that -e should be valid with no parameters passed for env?
<marcoceppi> thumper: as in, do you think that would be addressed by next stable?
<marcoceppi> or, is it even possible to do
<thumper> anything is possible, just not simple
<marcoceppi> is it simple* to do?
<thumper> no
<thumper> well... kinda
<thumper> marcoceppi: feel free to file the bug, and we can discuss it
<marcoceppi> thumper: Okay, I'll file it as a bug then and hope it gets prioritized for a 1.18 cut
<marcoceppi> thumper: thanks o/
<thumper> np
<_mup_> Bug #1269119 was filed: destroy-environment no longer accepts an -e flag <pyjuju:New> <https://launchpad.net/bugs/1269119>
<marcoceppi> damnit, wrong project
<lazypower> maxcan: you around?
<maxcan> I am
<maxcan> whats up?
<maxcan> you're question has the horrifying implication that I'm considered someone who knows something about juju
 * lazypower grins
<lazypower> You're doing docker + juju "loose integration" in your production stack arent you?
<maxcan> what do you mean by "loose"
<maxcan> we have some charms that where we use a binary that we  "ship" as docker images
<maxcan> the charm downloads and runs that docker image
<maxcan> if thats what you mean
<maxcan> i've thought about writing a generic docker image charm
<maxcan> but it wouldn't work for us since we require authnetication to d.load the charm etc
<mbruzek> Writing an amulet deploy test, I got an error when trying to create a relation
<mbruzek> ValueError: Can not relate, service not deployed yet
<marcoceppi> mbruzek: can you pastebin the test?
<lazypower> maxcan: ah ok. I thought i saw environment exports for the config and relation changes
<lazypower> mind you that was what, a week ago at 11pm EST :)
<mbruzek> http://pastebin.ubuntu.com/6752404/
<mbruzek> marcoceppi, ^
<marcoceppi> mbruzek: you reference rabbitmq but you deploy rabbitmq-server
<maxcan> lazypower: you mean on the MMS charm?
<mbruzek> Thanks marcoceppi
<marcoceppi> mbruzek: either change the add line to d.add('rabbitmq-server', 'rabbitmq') or change the d.relate to use the rabbitmq-server name
<maxcan> lazypower: oh, for our main charm?  yes, we export env vars into hte docker container with -e
<mbruzek> If I had changed the name on the deploy that would have worked
<maxcan> s/main/docmunch-yesod
<marcoceppi> mbruzek: actually, it's d.add('rabbitmq', charm='rabbitmq-server')
<marcoceppi> sorry about that
 * marcoceppi needs to read his own docs
<maxcan> lazypower: i was about to step out for lunch, anything i can help with before I go?
<lazypower> That was it my man. I had a cursory question about your docker usage with juju
<lazypower> Thanks!
<maxcan> np
<marcoceppi> thumper: the output a user gets during bootstrap,that's you, right?
<thumper> marcoceppi: as in, did I do that?
<thumper> no, that was axw
<marcoceppi> yeah
<marcoceppi> aw, next time I see him, let him know it's really nice
<marcoceppi> don't have to scratch my head anymore
<thumper> \o/
<dpb1> marcoceppi: hey, did you get a chance to review that storage charm? :)
<lazypower> dpb1: he did, he's pending a paper writeup for you.
<dpb1> oh no
<dpb1> lazypower: I responded to your review comments on the swap charm, thx. :)
<lazypower> and its not "oh no" :) you're doing some interesting new stuff in there
<dpb1> lazypower: yes, agreed.  We are eagerly anticipating the results.
<lazypower> Thank you for submitting the swap fixes so quickly!
<lazypower> I'll try to get that re-reviewed by tomorrow morning, bit backed up atm
<dpb1> lazypower: no worries, that one is pretty simple.
<mbruzek> OK I have a new amulet test written ( http://pastebin.ubuntu.com/6752656/ )with the relations corrected.  When I run the test I see it getting started on the hpcloud but I run into this error.
<mbruzek> AttributeError: 'module' object has no attribute 'CalledProcess'
<marcoceppi> mbruzek: can you provide the full trace?
<mbruzek> http://pastebin.ubuntu.com/6752675/
<mbruzek> my admin-secret is not setup correctly?
<mbruzek> We need that for the local one, but I set this environment up for hpcloud where juju uses the keypair
<mbruzek> So set something for admin-secret and do I need to rebootstrap?
<marcoceppi> mbruzek: all environment s need an admin secret
<marcoceppi> yes
<mbruzek> OK
#juju 2014-01-15
<jose> hey guys, anyone around?
<jose> bcsaller: ping
<ashipika> Hi.. Need a bit of help with a local installation of openstack.. when i try to bootstrap i get the following http://paste.ubuntu.com/6755106/
<ashipika> juju on openstack, bootstrap fails -> caused by: the configured region "regionOne" does not allow access to all required services, namely: compute, object-store
<michal_s> hi marcoceppi, can You confirm, that wordpress + memcached deployment works properly on Windows Azure? I'm deploying: mysql + wordpress + add-relation, and then deploy memcached + add relation with wordpress. After all I have: agent-state-info: 'hook failed: "cache-relation-changed"'
<michal_s> if I run juju resolved --retry wordpress/0 it is going to run, but in WP I have "Plugin settings are not yet saved for the site, please save settings! Â» WP-FFPC Settings"
<michal_s> and "Memcached cache backend activated but no PHP memcached extension was found.
<michal_s> Please either use different backend or activate the module!
<michal_s> also Memcached configuration in WP-FFPC is for 127.0.0.1
<ashipika> local openstack -> ERROR failed to list contents of container: juju caused by: request (http://172.16.93.211:8080/swift/v1/juju?delimiter=&marker=&prefix=tools%2Freleases%2Fjuju-) returned unexpected status: 204; error info:
<lazypower> I'm having troubles with 1.17.0 and the local provider not booting the lxc  containers. They sit in a "pending" state.
<perrito666> hello, can anyone point me to the actual link of the hooks section mentioned in https://juju.ubuntu.com/docs/authors-charm-components.html ? the one in there is just a link to the same document
<lazypower> perrito666, https://juju.ubuntu.com/docs/authors-charm-hooks.html
<perrito666> lazypower: thank you very much
<lazypower> perrito666, no problem. Thank you for pointing out the mis-link :)
<marcoceppi> michal_s: memcached is broken in wordpress
<michal_s> marcoceppi: thanx for info. There is information about memcached in WordPress charm readme, so maybe there should be no info about it there? ;)
<marcoceppi> michal_s: well, it used to work, and it should just be fixed
<marcoceppi> there's a bug about it on the wordpress charm
<michal_s> oh, ok :)
<vila> hazmat: ping, ev told me you may be interested by http://paste.ubuntu.com/6757161/
<hazmat> vila, i am, it looks like a bug in core
<hazmat> vila, i almost always do juju-deployer -TW
<hazmat> it will stream what's happening back to the client
<vila> hazmat: what I understood (incompletely ;) is that this happened when a service has an hook error, this seems to block/upset juju-deployer leading to that traceback
<hazmat> vila, deployer should be auto resolving errors when doing destroy
<hazmat> but noted
<vila> hazmat: the hook failed was gunicorn wsgi-file-relation-broken and the charm was expecting the service to exist and destroy it
<vila> hazmat: so the log was suggesting that this hook was run twice
<vila> hazmat: oh, noted
<hazmat> vila, can you pastebin juju-deployer -TW against that env if its still active
<hazmat> actually with trunk (1.17) we have a simpler way of cleanly doing this via terminate-machine --force
<vila> hazmat: not active anymore, will ping you when I encounter it again (and I run lp:juju-deployer) err, wait, 1.17 refers to ?
<vila> hazmat: ha, juju, yeah, 1.17.0-0ubuntu1~ubuntu13.10.1~juju1 here
<hazmat> yup .. refers to juju-version
<vila> hazmat: ok, thanks for the feedback so far, will come back to you when I've more meat ;)
<hazmat> vila, np
<vila> cjohnston: meet hazmat who asked for -TW output
<vila> hazmat: meet cjohnston how just reproduce the traceback in an active env \o/
<vila> s/jow/who/
<cjohnston> it's running -TW now
<vila> s/how/who/ with new fingers
<cjohnston> vila: hazmat https://pastebin.canonical.com/103023/
<hazmat> cjohnston, thanks, that clarifies it a bit, does look like a bug in deployer to me
<cjohnston> hazmat: ok.. do you need a bug filed?
<hazmat> cjohnston, that would be great
<hazmat> cjohnston, also which version of deployer are you using?
<cjohnston> hazmat: trunk I believe
<hazmat> cool
<hazmat> cjohnston, hmm.. that's not trunk.. it looks like  a package install
<cjohnston> ubuntu@tarmac:~/projects/amulet$ aptitude search deployer
<cjohnston> p   juju-deployer
<cjohnston> would it be packaged under anything else hazmat ? I'm guessing it comes from http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-ci-services-itself/trunk/view/head:/tests/run#L75
<hazmat> cjohnston, that doesn't match your traceback paths
<hazmat> oh.. nevermind it does
<hazmat> i was looking at jujuclient
<hazmat> cool
<cjohnston> hazmat: https://bugs.launchpad.net/juju/+bug/1269519
<_mup_> Bug #1269519: juju-deployer -T fails with jujuclient.EnvError: <Env Error - Details:  {   u'Error': u'state watcher was stopped', u'RequestId': 3, u'Response': {   }}  > <pyjuju:New> <https://launchpad.net/bugs/1269519>
<_mup_> Bug #1269519 was filed: juju-deployer -T fails with jujuclient.EnvError: <Env Error - Details:  {   u'Error': u'state watcher was stopped', u'RequestId': 3, u'Response': {   }}  > <pyjuju:New> <https://launchpad.net/bugs/1269519>
<hazmat> cjohnston, thanks.
<hazmat> cjohnston, also this is a random issue?
<hazmat> cjohnston, or reproducible?
<cjohnston> hazmat: I've reproduced it twice, vila atleast once
<hazmat> cjohnston, any chance i can get a copy of machine-0.log from that env
<hazmat> should be in machine 0 @ /var/log/juju/
<hazmat> cjohnston, via chinstrap is fine.. talking with a core dev  about as well
<cjohnston> hazmat: I can give you access if you like
<hazmat> cjohnston, sure that works.. i just need a copy of the file, not going intending to touch the live env
<hazmat> but if direct access is easier sure
<cjohnston> hazmat: ubuntu@10.55.32.15 should get you there
<hazmat> cjohnston, got it thanks
<cjohnston> :-)
<cjohnston> hazmat: just making sure you don't think you'll need anything else before I blow it up
<hazmat> cjohnston, all good, thanks
<cjohnston> hazmat: fwiw, I did just reproduce it again, so each time I've run it it's given the error
<hazmat> cjohnston, noted
<hazmat> cjohnston, one more question.. what version of jujuclient are you using (looks like that one is from package)
<cjohnston> 0.0.7+bzr12-0~bzr16~precise1ubuntu1~0.IS.12.04
<hazmat> cjohnston, bug filed against pyjuju ;-)
<hazmat> the deployer one you filed
<jcastro> marcoceppi, I found a silly charm proof bug I think
<jcastro> it thinks line 11 on the memcached charm readme is boilerplate, but it is not
<marcoceppi> jcastro: cool, I'm about to roll a release so I'll take a look
<jcastro> do a fresh pull of memcached, I just pushed up the readme
<jcastro> it was an OG clint charm, so no readme at all. :p
<jcastro> marcoceppi, memcached with wordpress being broken, is that a wordpress charm bug or a memcached charm bug?
<marcoceppi> jcastro: wordpress
<jcastro> marcoceppi, hah man, guess what my next audit is
<jcastro> hadoop
<marcoceppi> have funnnn
<marcoceppi> jcastro: I have no idea why it says that
<jcastro> marcoceppi, is it saying it for you?
<marcoceppi> yeah, but line 11 is the deploy line :\
<jcastro> I marked the charm as passing proof because it does
<jcastro> for all intents and purposes, even though it does not, heh, and it's only a W: anyway
<jcastro> I just found it strange
<marcoceppi> jcastro: found the problem
<marcoceppi> you have this sentance in the readme: Though this will be listed in the charm store itself don't assume a user will know that, so include that information here:
<marcoceppi> which is why it's matching
<marcoceppi> so it's saying that boilerplate line 11 is in the readme
<jcastro> OH!
<jcastro> fixing
<marcoceppi> I'll fix the message for this
<jcastro> hey also
<jcastro> can you cut something out of README.ex while you are there?
<jcastro> cut ## Charm contact and everything below that
<marcoceppi> k
<dpb1> marcoceppi: heard you were ripping me a new one on the storage charm? :)
<lazypower> Thats not what I said!
<lazypower> oy
<marcoceppi> dpb1: prepare youself ;)
<dpb1> hah
<marcoceppi> no, it's not bad. as a tl;dr I find the structure interesting, have some concerns about data integrety, a little swamped haven't be able to pound out a formal review response
<dpb1> marcoceppi: heh, I know the feeling (swamped).  We already have some follow-on branches, including one transforming it into python with charmhelpers and tests.  btw.
<marcoceppi> dpb1: oh, then by all means, feel free to push those up for review :D
<dpb1> OK, sure.  Let me get an ETA
<dpb1> marcoceppi: still a bit off on that python conversion.  WIP.  Just expect we will follow up with it shortly.  But the general structure and purpose wont'
<dpb1> ... won't change.
<dpb1> marcoceppi: IOW, sorry for the noise. lol
<marcoceppi> dpb1: awesome, I'll simply move the bug to incomplete to remove it from the queue for now
<marcoceppi> make sure to put the bug back at either "new" or "fix committed" when ready for review
<dpb1> marcoceppi: sure, that is fine.  Do you have even partial thoughts typed up?  would be good not to cycle on those
<marcoceppi> dpb1: I don't have anything typed really :\
<dpb1> ok
<dpb1> will ping when we are ready.
<jcastro> marcoceppi, https://bugs.launchpad.net/charms/+source/memcached/+bug/1269537
<_mup_> Bug #1269537: Charm needs a peer relation <audit> <memcached (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1269537>
<marcoceppi> hazmat: deployer can be a bit aggressive with agent state down for machines coming online
<marcoceppi> is there a way to increase it's timeout threshold?
<hazmat> marcoceppi,  there's a couple of timeout params that can be passed via cli params
<marcoceppi> hazmat: would that fall under REL_WAIT ?
<marcoceppi> it's getting tripped up before relations though
<hazmat> marcoceppi, its triggering against -t, --timeout
<hazmat> its a global timeout for the entire deployment
<marcoceppi> says default is 45 mins? these are dying after about 5
<marcoceppi> with the follwoing error
 * marcoceppi gets it
<marcoceppi> hazmat: jujuclient.EnvError: <Env Error - Details: {   u'Error': u'state watcher was stopped', u'RequestId': 4, u'Response': {   }} >
<marcoceppi> it seems agent state of a machine stays in "down" for about 45 seconds before moving to started
<hazmat> marcoceppi, i had a long discussion with roger about that..
<marcoceppi> hazmat: ah, I thought I saw some of it earlier today in here
<hazmat> the state watcher was stopped, there was a corresponding conversation in juju-dev as well
<hazmat> https://bugs.launchpad.net/juju-core/+bug/1269519
<_mup_> Bug #1269519: Error on allwatcher api <juju-core:New> <juju-deployer:New> <https://launchpad.net/bugs/1269519>
<marcoceppi> this really breaks automated testing :\
<hazmat> marcoceppi, yeah.. so in terms of trying to debug it and getting a fix from core, i think we need to turn the log level back to high
<marcoceppi> hazmat: I'm open to do whatever to help fix it
<marcoceppi> I have a way to replicate it though
<hazmat> marcoceppi, you do? do tell.. rogpeppe mentioned he has branch in the review queue thats turns up logging around api conn behavior a bit  https://codereview.appspot.com/52850043
<marcoceppi> hazmat: both lazypower and mbruzek can replicate it
<rogpeppe> marcoceppi: i wanna know!
<hazmat> marcoceppi, but how?
<lazypower> indeed, i was blaming the fact that i'm on plattered disks so the file copy took longer to happen than expected...
<lazypower> but i have no evidence to back that up
<lazypower> hazmat, i'm available for stack traces, just let me know what you need and i'll make myself available.
 * hazmat can't remember the syntax for turning up the logging level
<marcoceppi> thumper should know
<marcoceppi> there's a doc somewhere around here too that has that info
<sarnold> https://lists.ubuntu.com/archives/juju/2013-September/002998.html
<sarnold> there might be something newer, but that's easily accessible in my history :) hehe
<hazmat> marcoceppi, if only it was the docs..
 * marcoceppi makes a bug
<hazmat> sarnold, thanks
<lazypower> sarnold, thanks, bookmarked
<hazmat> lazypower, so re reproducing what do you have a deployer file you can share?
<lazypower> You bet, give me another 10 minutes to wrap up this call and I'll start
<lazypower> hazmat, the output is going to have some chatter from amulet, is that going to be a problem?
<hazmat> lazypower, that's fine.. what we're interested in actually the log from the state-server machine-0.log there in /var/log/juju
<hazmat> lazypower, basically bootstrap, turn the logging way up, and then do your reproduce, and then send over the machine-0.log
<lazypower> Ok, that helps. I just cranked the debug level to DEBUG, running the sequence now.
<hazmat> cool
<lazypower> hazmat, i dont think i did it right
<lazypower> http://paste.ubuntu.com/6759208/
<lazypower> i see a ton of the provider output, but not so much on the state server.
<lazypower> i take that back, i had not scrolled back far enough in history to see it.
<hazmat> lazypower, yeah.. that looks correct
<hazmat> its the apiserver output that's of interest
<lazypower> The behavior sequence is the containers go from pending => down  => started
<lazypower> when they hit down is when the state server bails
<hazmat> lazypower, i don't see the sympton we're looking for in that log file.. i
<hazmat> lazypower, ie. deployer exiting with an EnvError relating to 'state watcher was stopped'
<lazypower> That bubbles up in the juju stacktrace of the actively running command
<lazypower> let me wipe and restart
<lazypower> hazmat,  juju set-env 'logging-config=<ROOT>=DEBUG;juju.api=DEBUG'
<lazypower> is that the correct debug tuning line i want to run?
<hazmat> lazypower,  juju set-env "logging-config=<root>=DEBUG" should do
<lazypower> http://paste.ubuntu.com/6759241/
<lazypower> theres the parent running command stack trace
<hazmat> lazypower, the log level in that pastebin looked correct, it had debug api messages from the state server
<lazypower> http://paste.ubuntu.com/6759246/
<lazypower> theres the machine log for machine-0
<lazypower> hazmat, i just thought of something that may be causing this as well, my lxc containers are bridged and set to pull from my network DHCP server. That may or may not be relevant
<hazmat> lazypower, that log looks truncated, the timestamps don't quite match up even taking into account utc between the host and container
<hazmat> i just don't see evidence of the deployer api connection in that log
<lazypower> I dont either, which concerns me too
#juju 2014-01-16
<lazypower> i'm not sure what to do about the log truncation, any suggestions on what you would like me to do next?
<hazmat> lazypower, if the log on disk is bigger than the pastebin, the easiest thing to do would be to zip it up and email it to me.. but it doesn't look like its truncated just very short
<lazypower> its not any larger than whats in the pastebin
<lazypower> however i'm more than happy to send you a tarball of the logs for completeness sake
<hazmat> lazypower, hmm.. sure.. it might be on local provider its in a different log
<marcoceppi> lazypower: include /var/log/upstart/juju* in that tarbal
<_thumper_> marcoceppi: plz file a bug and assign to me for "juju help logging"
<hazmat> yeah.. not seeing anything in the log files
<marcoceppi> thumper: https://bugs.launchpad.net/juju-core/docs/+bug/1269618
<_mup_> Bug #1269618: Need to document log level changing <juju-core:Confirmed for thumper> <juju-core docs:Confirmed for evilnick> <https://launchpad.net/bugs/1269618>
<thumper> marcoceppi: ta
<stub> Anyone know of a charm using charmhelpers.fetch.configure_sources? I want to see how to spell install_sources & install_keys in the config.yaml
<marcoceppi> stub: not that I'm aware of, I can take a quick look though
<stub> I've got a whole pile of config options that should be lists. I didn't realize config.yaml even supported that until I saw the example in charmhelpers.config_sources()
<stub> Need to work out how to sanely version the config and migrate to a saner structure, deprecating and rewiring
<marcoceppi> yeah, that's going to be a ton of fun
<stub> def upgrade_charm(): log('ââ©â(â£_â¢)ââ©â')
<marcoceppi> hahaha
<marcoceppi> stub: none of the charms in the charmstore use configure_sources :\
<stub> marcoceppi: I'll give it a go. Someone has to be first :) My existing extra_archives is bogus anyway, as it specified space separated list... which doesn't work.
<noodles775> stub: I've used it (before I switched to using ansible for a charm I'm working on). Let me see if I can find it. Using ansible makes a lot of that pain go away though.
<stub> noodles775: go away or transfer it elsewhere ;)
<ashipika> can anybody here help me use juju on my local openstack installation?
<noodles775> marcoceppi: Are you using amulet with latest juju-core? Or maybe the issue is with juju-deployer - I'll start digging (http://paste.ubuntu.com/6761334/)
<marcoceppi> noodles775: we are using amulet with latest juju-core, but I've not seen that error. It's originating from deployer though
<noodles775> Yeah, I'll find out why.
<marcoceppi> noodles775: I'm switching gears from charm-tools to amulet for the next few days to fix it up and get it ready for the automated testing infrastructure. if you find anything else let me know or open a bug and it'll get eyes on
<noodles775> marcoceppi: will do (I just switched back this morning from other stuff too). BTW, by latest juju-core, I meant trunk (sorry). It works with 1.16.5-saucy-amd64, but not trunk: http://paste.ubuntu.com/6761360/
<marcoceppi> noodles775: ah, we've been testing 1.17.0
<marcoceppi> noodles775: if you bootstrap with trunk, and run juju status, what does the output look like?
 * marcoceppi will be sad if dns-name was dropped from machine output
<noodles775> No - it's there, that's the first thing I checked. I'll dig down in a minute (just finishing something else).
<marcoceppi> ah, k, cool
<marcoceppi> we're going to be testing against devel/latest built release, but I'll keep trunk in mind
<noodles775> OK, I'll switch to that too.
<noodles775> marcoceppi: jfyi, I must have checked the wrong status earlier. Deploying a charm with trunk does indeed have unexpected output for juju status: http://paste.ubuntu.com/6761458/
 * noodles775 switches to 1.17.0
<marcoceppi> that makes me a sad panda
<noodles775> I'm assuming that's not intended, probably an issue in trunk. Any devs who can confirm?
 * marcoceppi usually pings fwereade, I'm sure he loves that
<fwereade> marcoceppi, noodles775: hmm, someone was swearing blind that already-exists bug was fixed
<fwereade> marcoceppi, noodles775: dns-name is sometimes delayed a bit in status
<marcoceppi> cool, as long as it's not a surprise for 1.17.1 I'm fine :)
<noodles775> fwereade: great (fwiw, the above was with r2212 of juju-core apparently: http://paste.ubuntu.com/6761485/)
<fwereade> noodles775, ok, thanks, that's very good to know
<ev> hazmat: hi. I have an environment where juju-deployer -TW -r5 refuses to succeed, no matter how many times I run it. Is this interesting to you? Any debugging information I can provide?
<marcoceppi> stub: here's a merge that adds configure_sources support: https://code.launchpad.net/~cmars/charms/precise/haproxy/trunk/+merge/201458
<stub> ta
<ev> hazmat: http://paste.ubuntu.com/6761718/
<stub> marcoceppi: alas it breaks when you want an empty list. I'll file a bug and fix.
<marcoceppi> stub: ack, thanks. fwiw, charm-helpers is going to be getting some serious attention by the charmers in the very near future
<stub> marcoceppi: does that mean I don't have to fix the bug myself ;)
<marcoceppi> stub: very near future, unfortunately not the immediate future :P
<marcoceppi> ev: so, jenkins/0 can't be removed because lander-jenkins is in a pending state but also dying. This is why deployer keeps repeating it's message
<ev> marcoceppi: still a bug in deployer though, no? I mean my understanding of -T is it's destroy-environment without the bootstrap node - I just want the instances to go away, I don't care how violently it's done.
<marcoceppi> ev: I don't think deployer has --force functionality yet, but you could run `juju terminate-machine --force 10` then run the juju deployer -TW -r5
<marcoceppi> ev: it's more a feature request, --force is a very new flag in juju, I think it landed sometime in the 1.16 series
<ev> marcoceppi: won't juju immediately try to recreate the node?
<ev> oh right
<marcoceppi> ev: no, that hasn't been a feature since the go conversion
<ev> ^ vila, in case you're not following along already
<marcoceppi> ev: def file a bug/feature request about it, it's great to have as a part of -T
<ev> on it now
<marcoceppi> the manual terminate-machien is a work around for now though
<vila> ev: pure gold, thanks for the ping
<vila> ev: and no I wasn't following so I would have missed
<ev> vila: there's a precise backport of 1.16 that we can use for tarmac: http://archive.admin.canonical.com/pool/main/j/juju-core/
<vila> ev: that means that we can replace juju-deployer -T by for $m in (juju all your machines expect 0): juju terminate $m ?
<vila> cjohnston: ^
<ev> that's my understanding. marcoceppi ^ any gotchas there that you can think of?
<vila> ev, cjohnston: 1.16 ?  We don't need 1.17 ?
<ev> ps. thanks for amulet. It's lovely.
<marcoceppi> ev: that would be a temporary work around until -T uses the --force option, deployer still does a bit more elegant things
<ev> vila: we just need whatever version has the --force flag
<ev> marcoceppi: *nods*, thanks
<marcoceppi> 1.17.0 def has it, let me check 1.16.5
<vila> ev, cjohnston: and why can't we use saucy of even trusty for tarmac ? This is exactly why I'm advocating using ubuntu dev releases for devs (and tarmac needs to be closely in sync with devs).
<marcoceppi> vila: ev there's stable builds (1.16, etc) in the cloud-tools archive for precise as well
<ev> marcoceppi: filed: https://bugs.launchpad.net/juju-deployer/+bug/1269783
<_mup_> Bug #1269783: -T should have a complimentary --force option <juju-deployer:New> <https://launchpad.net/bugs/1269783>
<ev> ah cheers
<marcoceppi> ev: vila 1.16.5 has --force, so you should be good to use that
<vila> marcoceppi: ack
 * vila lost the battle that one time ;)
<mattyw> marcoceppi, you got a few minutes for a charm helpers question?
<marcoceppi> mattyw: I'll do what I can
<mattyw> marcoceppi, the only occurance of an apt-get-install call seems to be in the jujugui contrib?
<marcoceppi> mattyw: charmhelpers.fetch.apt_install
<marcoceppi> http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/fetch/__init__.py#L76
<marcoceppi> fetch will have most apt functions in it
<mattyw> marcoceppi, ah brilliant, I missed that
<marcoceppi> np!
<marcoceppi> mattyw: typically the contrib stuff is hyper specific to that service (ie: openstack-helpers, jujugui, ansible, etc)
<mattyw> marcoceppi, ok cool
<mattyw> are there any firm plans of what goes into core - or is it just done quite ad hoc?
<cjohnston> ev, vila I'm already on 1.17.0-0ubuntu1~ubuntu12.04.1~juju1
<ev> cool
<marcoceppi> mattyw: there will be. Basically it needs to be generic and have tests atm, but we're drawing up a roadmap and restructure of charm-helpers to make it a little less adhoc and a little more structured
<marcoceppi> core has really lost it's meaning, since it was supposed to be contrib and core, things get put in contrib as a testing/fleshing out then promoted to core. but now fetch and payload are outside of both contrib and core, so not sure what happened there
<vila> cjohnston: \o/ Is your setup documented somewhere ? No urgency but that's a blind spot for me so far :-}
<cjohnston> vila: I'm still trying to make it all work, so no (or its in progress)
<vila> cjohnston: ack
<cjohnston> basically its just a precise instance and trying to get all of the different deps.. that's really it
<vila> cjohnston: charmed or setup manually ?
<cjohnston> vila: manually atleast for now
<cjohnston> vila: my tarmac runs more than just CI stuff too
<vila> cjohnston: ok, as long as you keep track of what you install there, we'll be fine
<hazmat> smoser, the cloudinit docs on readthedocs look nice
<smoser> hazmat, thanks. that is mostly harlowja. things can definitely be improved still.
<hazmat> yeah.. features overview is a bit light, but i was googling around and reading the format docs yesterday and found them quite helpful.
<fwereade> noodles775, ping
<noodles775> Hi fwereade
<fwereade> noodles775, can you confirm you saw "service already exists" with r2212 client and --upload-tools?
<noodles775> I didn't use --upload-tools, dimitern mentioned that I should try that. Let me do so now.
<fwereade> noodles775, we have a bug that STM to be the same, with a very inappropriate title: https://bugs.launchpad.net/juju-core/+bug/1259925
<_mup_> Bug #1259925: juju destroy-environment does not delete the local charm cache <destroy-environment> <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1259925>
<fwereade> noodles775, ah, the local provider does that anyway I think
<fwereade> noodles775, if you take a look at the jujud installed alongside juju, and the jujud inside one of your containers, I think they'd be bit-for-bitthe same
<fwereade> noodles775, so as long as your jujud matched your juju you'd be fine
<fwereade> noodles775, would you update that bug with whatever detail you have please? I think the name is better now
<noodles775> fwereade: I don't understand why you changed the name of that bug - it seems quite different. I actually created a dupe of that bug at the time, and as you can see from the dupe, I had no problems deploying a service with the juju I was using.
<noodles775> fwiw, here's the result using juju bootstrap --upload-tools http://paste.ubuntu.com/6762332/
<noodles775> Works fine with 1.16.5-saucy-amd64
<fwereade> noodles775, ok,about the bugs quickly: I'm confused
<fwereade> noodles775, the bug I linked was complaining that a service already existed
<fwereade> noodles775, and I thought that matched what you were talking about this morning
<fwereade> noodles775, your charm caching bug is IMO not a duplicate of that other one -- but it had a bad title that made it seem like it was
<fwereade> noodles775, (the one I changed had a bad title, not your bug)
<fwereade> noodles775, am I making sense here?
<noodles775> fwereade: not really (at least, not to me :-) ). That is, the paste I showed this morning, http://paste.ubuntu.com/6762349/ , I expected the service to already exist (line 18) because I'd just deployed it (line 5). What I didn't expect was the output of juju status to not contain the details.
<noodles775> It's probably clearer on the second paste: http://paste.ubuntu.com/6762332/ (as it shows juju status before the deploy as well).
<noodles775> That said, there's something wrong with the installed packages - juju-core is at 1.16.5 while jujud version shows 1.17.1.. http://paste.ubuntu.com/6762349/
 * noodles775 apt-get updates to be certain.
<fwereade> noodles775, yeah, that mismatch is almost certainly a problem
<noodles775> Where's jujud coming from? http://paste.ubuntu.com/6762365/
<mattyw> marcoceppi, this is definately a crazy question - have you ever tried installing juju in a unit?
<mattyw> (so that in the unit you can do a juju bootstrap to create a local environment
<marcoceppi> mattyw: yeah, a few times, pyjuju used to go ape over it, juju-core should run fine side by side in a deployed unit
<mattyw> marcoceppi, juju init compains about juju_home not being set
<marcoceppi> mattyw: juju-core doesn't actually install any juju packages, it's all custom paths, etc
<mattyw> but afaik it's set by juju - it doesn't need to be present in the env before hand
<marcoceppi> mattyw: yeah, that's because there is no HOME environment variable in the hooks env
<mattyw> marcoceppi, oh right - so I should set home in the hook env?
<marcoceppi> mattyw: yup, that should resolve that
<mattyw> marcoceppi, I'll give it a go - thanks
<marcoceppi> mattyw: I'm sure there are a few other minor nuances, but there shouldn't be any major blockers
<mattyw> marcoceppi, ok thanks, I'll see how far I can get
<marcoceppi> mattyw: np, gl
<marcoceppi> lazypower: postgresql is a good example of this
<lazypower> haha
<marcoceppi> it has a 01_unittest.test
<marcoceppi> and a 10_function_tests.test
<lazypower> ok, i think i was more granular than that
<marcoceppi> juju test plugin, by default, will hault once a test file runs
<marcoceppi> so unittesting will cause the whole ship to sink if it fails
<lazypower> i have tests titled deploy_test that check the deployed resources, and another config_test that cache the config flags and test that they are sent over the wire (Which feels like i'm testing juju itself and not the charm)
<marcoceppi> lazypower: well you can have as many test files as you want, this is just how stuart structured it
<lazypower> next up was relationship_test that check db, caching, etc. relationships
<lazypower> but if i'm using amulet in a wrong context what should I be using for unit testing? I'll add it to my required reading list
<marcoceppi> lazypower: amulet really is there to help you stand up an environment and poke at it with a sharp stick
<marcoceppi> lazypower: there's tons of unittesting tools out there, if the charms in python there's a unittest python modules that's part of core
<marcoceppi> that allows you to test functions, etc, with a nice set of assertions, bleh
<lazypower> Right but I feel like poking at the end environment is still a good way to do assert the intent was performed properly
<lazypower> but ok, let me spin on the unit test conversation a bit more and i'll come back to this
<marcoceppi> lazypower: it's a lot of effort to stand up a deployment only to test is a config key was changed or removed
<marcoceppi> unittesting is nice to have, just like integration tests, they're both pieces to a larger quality puzzel
<lazypower> marcoceppi, http://paste.ubuntu.com/6762527/
<lazypower> like, i understand that's expensive, but I need a deployed unit to validate the intent was completed. Maybe I'm approaching integration testing with a unit testing mindset?
<marcoceppi> lazypower: the concept looks fine to me
<lazypower> Ok i'm going to finish this suite and put it up on CR
<lazypower> ta
<marcoceppi> lazypower: congrats, papertrail passed review
<mhall119> marcoceppi: I need your help
<mhall119> I'm getting this again:
<mhall119> Error details:
<mhall119> Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused
<mhall119> don't remember what you had me to last time to fix it
<marcoceppi> mhall119: what version of juju?
<mhall119> 1.16.3-saucy-i386
<marcoceppi> mhall119: not that it'll help this, but 1.16.5 is latest, fyi
<mhall119> is it in saucy?
<marcoceppi> mhall119: is the environment already bootstraped? or are you trying to bootstrap?
<marcoceppi> mhall119: it's in ppa:juju/stable
<mhall119> if it's not in saucy, it's not the latest for me :)
<mhall119> marcoceppi: to be honest, I thought I had destroyed this env, haven't used it in months, but I'm seeing instances still running
<marcoceppi> mhall119: fair enough, just a reminder :)
<marcoceppi> mhall119: okay, there's like a 10 step process to purge with fire
<mhall119> marcoceppi: make jcastro backport 1.16.5 to saucy's archives
<mhall119> marcoceppi: I've alredy done step 1: Admitting that I have a problem
<marcoceppi> mhall119: http://askubuntu.com/a/403619/41
<jcastro> I was hoping we'd be backporting point releases back to released Ubuntus
<marcoceppi> just delete all those files
<jcastro> sinzui, is there a plan for that?
<marcoceppi> jcastro: we are, 1.16.0 shipped in saucy, saucy-updates has 1.16.3
<marcoceppi> it just seems to not have 1.16.5
<mhall119> thanks marcoceppi
<jcastro> yeah I am just wondering if there's a timed cycle or if it's best effort or what
<marcoceppi> jcastro: ah
<sinzui> jcastro, 1.16.4 is stalled over discussion about the definition of bug fixes
<marcoceppi> mhall119: likely it's the last two paths goofing you up, but the rest are good to clean out
<marcoceppi> mhall119: OH, also
<jcastro> sinzui, <nod>
<marcoceppi> mhall119: if it's been months, delete this too: /var/cache/lxc/cloud-precise/ubuntu-12.04*.tar.gz
<sinzui> jcastro, as a policy they will but backported because they are stable, but we need to argue the case when we add a feature because it address how ubuntu stable users interact with Juju, such as backups need to work like saucy expects
<lazypower> marcoceppi, \o/ wooo
<mhall119> I thought backports was specifically for new stuff
<lazypower> i'm going to be in the charm store
<jcastro> sinzui, are we putting new features in these point releases or just pure bugfixes?
<sinzui> mhall119, confusion over the term backport. You are correct, jcastro is asking about the SRU for juju in saucy
<mhall119> ah, ok
<lazypower> marcoceppi, can you think of a good charm to reference for relationship testing? My immediate guess is to parse the DB Config file of a service and regex out the db credentials.
<marcoceppi> lazypower: sentries can do that already
<sinzui> jcastro, backup of the state-server in juju 1.16.3 and below doesn't work. That was fixed in 1.16.4, but that fix takes the form of a plugin/feature
<lazypower> wot
<lazypower> marcoceppi, thats not documented is it?
<marcoceppi> lazypower: sentries haven't been documented yet
<lazypower> Ok i'll take notes and ship them to you when i'm done so you can verify i understand what i think i understand
<lazypower> I smell a blog post coming
<marcoceppi> d.sentry.unit['ubuntu/0'].realation( 'db', 'mysql:db') - https://github.com/marcoceppi/amulet/blob/master/amulet/sentry.py#L100
<lazypower>     def directory_stat(self, *args): <- that checks if a directory exists?
<marcoceppi> lazypower: that's the whole point of the relation_sentry service, it proxies all the relations and acts like a MITM, recording all the relations
<lazypower> er sorry i mean tot get def directory()
<lazypower> i see dir_stat is not implemented yet
<marcoceppi> lazypower: dir_stat is
<marcoceppi> Look at UnitSentry class
<lazypower> https://github.com/marcoceppi/amulet/blob/master/amulet/sentry.py
<lazypower> is what i'm reviewing right now
<marcoceppi> Look at UnitSentry class
<lazypower> wow, ok
<marcoceppi> lazypower: I forget what dir_stat data looks like, but it basically is a way to check if dir exists
<lazypower> I think i overcomplicated my deploy test concept
<lazypower> the sentry does all this already...
<marcoceppi> lazypower: yeah, sorry, I should have picked up on that
<lazypower> nbd :) learning curve
<marcoceppi> most of what you need to know is in that unit_sentry class, it's just the formatting of what each returns which needs to be documented
<lazypower> I'm keeping notes that i want to swap with you after your travels, i think we can build a fairly comprehensive documented suite, or at least API reference for Amulet fairly quickly
<marcoceppi> lazypower: evilnick did a great job making my README look pretty in the docs
<marcoceppi> https://juju.ubuntu.com/docs/tools-amulet.html
<lazypower> I did see that.
<marcoceppi> just need to expand on it with sentry and the other stuff not in there :\
<lazypower> i've been referencing that, and the tests that mbruzek and I paired over yesterday
<rick_h_> marcoceppi: or jcastro I've qa'ing stuff and removing/resetting my .juju over and over to test out quickstart. I keep getting ERROR TLS handshake failed: x509: certificate signed by unknown authority
<rick_h_> any ideas on what else i need to clear/reset/remove to prevent these issues? I see bug #1178312 but that's a bit different
<_mup_> Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>
<jcastro> I've seen that error before
<jcastro> but can't remember when
<marcoceppi> rick_h_: you're blowing away the entire $HOME/.juju dir?
<rick_h_> marcoceppi: yea, I was
<rick_h_> now it's working
<rick_h_> bah
<marcoceppi> :)
<jcsackett> rick_h_: what environment? I get those periodically when i'm using a sshuttle instance to canonistack that's gone stale.
<rick_h_> lxc and juju on trusty is giving me grief here and there
<rick_h_> I know it's in flux, I just seemed to get stuck but rm'd the whole thing again and it worked
<jcsackett> huh, ok. never seen that on local.
<jcsackett> but then, i'm not on trusty yet.
<mhall119> marcoceppi: do I need to reboot after following the 10-step program, or should I be okay to bootstrap a new environment and work with it?
<diogoviannaarauj> hi you guys
<diogoviannaarauj> I'm getting the error "timed out waiting for mgo address from []" when trying to use juju with openstack
<diogoviannaarauj> and i can't find anything about it
<hatch> somehow my local juju env has been corrupted, there are no lxc's running, juju status shows the env, but I can't destroy it because it can't find a local-machine.conf file. Is there a 'nuke it' option?
<hatch> ahh found http://askubuntu.com/questions/403618/how-do-i-clean-up-a-machine-after-using-the-local-provider
<marcoceppi> mhall119: no restarts needed
<marcoceppi> diogoviannaarauj: this typically means the machine didn't boot
<mhall119> thanks marcoceppi
<diogoviannaarauj> marcoceppi: oh, will check out, but going on openstack panel i can do everythin
<diogoviannaarauj> marcoceppi: any log i should inspect?
<marcoceppi> diogoviannaarauj: so you've got an instance launched?
<diogoviannaarauj> i can do throu
<diogoviannaarauj> i can do through openstack interface
<marcoceppi> diogoviannaarauj: yes, if you can ssh in to it first, check /var/log/cloud-init*, then run initctl list | grep juju to see if any jobs exists/are arunning
<marcoceppi> Is this a private openstack setup?
<diogoviannaarauj> yes
<marcoceppi> k
<diogoviannaarauj> I'm using openstack with docker
<diogoviannaarauj> to create containers
<diogoviannaarauj> my friend who is in the project from beginning is joining the room to explain better
<diogoviannaarauj> hi jogn00santos, marcoceppi is trying to help us
<diogoviannaarauj> he said: if you can ssh in to it first, check /var/log/cloud-init*, then run initctl list | grep juju to see if any jobs exists/are arunning
<john00santos> ok
<john00santos> are running
<john00santos> juju-db-root-local start/running, process 3353
<john00santos> juju-agent-root-local start/running, process 3363
<mhall119> stub: is cs:precise/postgresql-56 the charm I should be testing the api-website with?
<marcoceppi> john00santos: okay, what happens if you run juju status right now?
<john00santos> waiting
<marcoceppi> john00santos: run the command with --debug and --show-log flags
<john00santos> Ok
<john00santos> 2014-01-16 19:07:38 ERROR juju supercommand.go:282 Unable to connect to environment "openstack".
<john00santos> Please check your credentials or use 'juju bootstrap' to create a new environment.
<john00santos> Error details:
<john00santos> timed out waiting for mgo address from []
<john00santos> Por default ele se conecta usando o valor em "auth-url"?!
<john00santos> By default it connects using the value "auth-url"?
<marcoceppi> john00santos: does your bootstrap instance have an IP address that reachable by your machine?
<john00santos> yes
<john00santos> 198.27.90.250 5000
<john00santos> vagrant@precise64:~$ echo 1 > /dev/tcp/198.27.90.250/5000
<john00santos> vagrant@precise64:~$ echo $?
<john00santos> 0
<john00santos> vagrant@precise64:~$
<marcoceppi> john00santos: The auth-url should be the keystone URL for your openstack, if you got juju to launch and instances, that should be correct
<marcoceppi> john00santos: do you have swift setup on this openstack?
<john00santos> yes
<john00santos> Ok, looks environment.yaml
<marcoceppi> john00santos: what version of juju-core do you have (`juju version`)
<lazypower> marcoceppi, so this means the relationship failed to be parsed by amulet, right?
<lazypower>  {   u'Error': u'service "relation-sentry" has no "requires-mediawiki_db-mysql_db" relation',
<john00santos> vagrant@precise64:~/.juju$ juju version
<john00santos> 1.16.5-precise-amd64
<marcoceppi> john00santos: okay, good, you have the latest
<john00santos>   openstack:
<john00santos>     type: openstack
<john00santos>     # Specifies whether the use of a floating IP address is required to give the nodes
<john00santos>     # a public IP address. Some installations assign public IP addresses by default without
<john00santos>     # requiring a floating IP address.
<marcoceppi> lazypower: can you run juju status and pastebin the output?
<marcoceppi> john00santos: please use http://paste.ubuntu.com for more than one line of text
<lazypower> http://paste.ubuntu.com/6763722/
<john00santos> ok
<marcoceppi> lazypower: that message is correct, there is no requires-mediawiki_db-mysql_db relation
<marcoceppi> lazypower: there are no relations to the relation-sentry
<lazypower> right
<lazypower> its mediawiki:mysql
<lazypower> duhhh
 * lazypower facepalms
<marcoceppi> lazypower: well, relation-sentry is designed to proxy those
<marcoceppi> lazypower: did you get that error during d.setup() ?
<lazypower> yeah, do i leave off the interface?
<lazypower> d.relate('mysql','mediawiki')
<marcoceppi> lazypower: you need to be explicit and include the relations
<lazypower> https://juju.ubuntu.com/docs/tools-amulet.html#functionality
<lazypower> docs are wrong and should probably be updated
<marcoceppi> d.relate('mysql:db', 'mediawiki:db')
<lazypower> i'll branch and fix
<marcoceppi> lazypower: docs are correct
<lazypower> d.relate('mysql:db', 'mediawiki:db')
<lazypower> thats what i have in my code thats failing
<marcoceppi> lazypower: can you add this line prior to d.setup()
<marcoceppi> import json
<marcoceppi> print(json.dumps(d.schema(), indent=2))
<lazypower> surely
<marcoceppi> then pastebin the schema that it drops
<john00santos> http://paste.ubuntu.com/6763735/
<lazypower> http://paste.ubuntu.com/6763752/
<marcoceppi> lazypower: can you pastebin /tmp/sentry_etcadv/relation-sentry/metadata.yaml
<lazypower> http://paste.ubuntu.com/6763760/
<marcoceppi> john00santos: your config looks fine, try running juju destroy-environment, make sure the node that juju launched shuts down
<marcoceppi> john00santos: set use-floating-ip to True, rm -f ~/.juju/envs/openstack.jenv; then run `juju bootstrap --show-log --debug`
<marcoceppi> lazypower: yeah, that's correct
<marcoceppi> lazypower: and it's giving you grief about now having a relation? was this a test running against a clean environment?
<lazypower> nope, i chained right off of the standup test
<lazypower> let me clear and try fresh
<marcoceppi> lazypower: that's the problem
<marcoceppi> lazypower: the relation-sentry doesnt' get upgraded, so it doesn't get the latest metadata.yaml
<lazypower> i just hit the setup() portion of the test, so far so good
<lazypower> ahhh ok
<marcoceppi> so technically relation-sentry doesnt have those defined yet
<lazypower> so the sentries cache data then
<marcoceppi> lazypower: no, the deployment caches data
<lazypower> whatever config comes in initially they hold on to, and are not reprogrammable
<marcoceppi> its a juju feature, can you open a bug to make sure that amulet runs an upgrade each time deployer runs?
<lazypower> sure, against amulet right?
<marcoceppi> lazypower: yes
<marcoceppi> lazypower: I think I just need to add the --update-charms flag to deployer
<marcoceppi> could you add that as a note, I'll investigate later
<lazypower> https://bugs.launchpad.net/amulet/+bug/1269914
<_mup_> Bug #1269914: Upgrade Charm on juju-deployer run <Amulet:New> <https://launchpad.net/bugs/1269914>
<marcoceppi> john00santos: any luck?
<john00santos> this uploading tools for bucket
<marcoceppi> john00santos: gotchya
<john00santos> I found these strange errors http://paste.ubuntu.com/6763823/, but he ignores her and continues uploading
<amrilinux> hi guys !!! plz i need to know about juju !!!
<amrilinux> whats juju ???
<sarnold> amrilinux: juju is a cloud-provider independent way to orchestrate 'services' -- you can with a few commands or clicks deploy a few hundred machines to run the services you need; check out https://juju.ubuntu.com/ for the details
<lazypower> hi amrilinux, what would you like to know about juju?
<marcoceppi> john00santos: those are somewhat exected errors, it's just juju trying to find tools and imagemetadata
<amrilinux> lazypower: hi ! i don't know nothing about her !!
<lazypower> Well, Juju is the coolest tool in data center orchestration, distilling away the pain of deployment and setup of your infrastructure. My first suggestion is you visit juju.ubuntu.com and get the overview of the application. I'll be more than happy to answer any specific questions you may have about the platform.
<lazypower> amrilinux, ^
<rick_h_> http://www.youtube.com/watch?v=1yoIdgdqzLk&list=PLc2mSdaCQVXYBiIRrA72T6yCJi8AKU4lb for the video lovers of learning what something is
<john00santos> It did not work ... Error: http://paste.ubuntu.com/6763859/
<john00santos> re-running http://paste.ubuntu.com/6763888/ , generating ImageData the problem is resolved, but will return to the initial error
<marcoceppi> john00santos: Okay, have you created image metadata for your cloud already?
<marcoceppi> the second paste shows a failure to find a machine to launch
<john00santos> I will create and upload to the bucket, do you think the problem may related to the fact that I'm using OpenStack with docker
<marcoceppi> john00santos: it shouldn't be, but I don't think we've tested that combination yet, so I can neither confirm or deny it works with juju
<john00santos> I will upload the metadata and you have the output step
<marcoceppi> john00santos: thanks
<john00santos> The id is the image that stored in the right glance?
<john00santos> marcoceppi, The id is the image that stored in the right glance?
<marcoceppi> john00santos: yes, you should see it in the drop down in horizon for the create an instance
<john00santos> thanks
<john00santos> marcoceppi, I did upload metadas and ran the juju status and error was the same http://paste.ubuntu.com/6764202/
<marcoceppi> john00santos: so you uploaded metadata, then ran a bootstrap?
<john00santos> yes
<john00santos> http://paste.ubuntu.com/6764297/
<john00santos> marcoceppi: yes, http://paste.ubuntu.com/6764297/
<john00santos> marcoceppi?!
#juju 2014-01-17
<noodles775> marcoceppi: Hi! So with 1.17.0 I get a bit further with amulet - now jujuclient is erroring with 'state watcher was stopped' - http://paste.ubuntu.com/6766988/ If that's familiar, let me know. I'll start digging.
<marcoceppi> noodles775: it's a know dwployer/juju bug
<noodles775> marcoceppi: OK, so how are you working around it when you test amulet using juju 1.17.0??
 * noodles775 checks for the bug (sorry, the two ?? there is just because of net-lag :P)
<marcoceppi> just run the rest a second time without destroying env
<marcoceppi> noodles775: let me see if i can find it
<noodles775> marcoceppi: oh - as in, you write your first amulet test to simply create the environment, then other files in tests/* are run with the existing already-setup env? (I'd assumed each file would be run with a freshly-bootstrapped env)
<marcoceppi> noodles775: you /can/ do that, but juju-test is designed to destroy environment before each test file
<marcoceppi> noodles775: what you can do is just run the tests again without destroying environment, IE: tests/01-amulet-test-name
<marcoceppi> it'll fail with https://bugs.launchpad.net/juju-deployer/+bug/1269519
<_mup_> Bug #1269519: Error on allwatcher api <juju-core:In Progress by rogpeppe> <juju-deployer:Confirmed> <https://launchpad.net/bugs/1269519>
<marcoceppi> then just run the test again and deployer will pick up where it left off
<noodles775> marcoceppi: oh? Let me try that (I'd assumed it creates a separate deployment).
<marcoceppi> noodles775: no, juju test files expect to have a clean environment, they don't actually destroy anything
<marcoceppi> noodles775: since amulet uses deployer, deployer just picks up where it left off
<noodles775> Yeah, I was assuming that the test files expect a clean env (and wasn't doing any destroying), but didn't realise I could re-run the test and have it pick up where it left off. Great. Thanks!
<marcoceppi> noodles775: np! Just know that's not normal behavior of the juju test plugin, the test plugin (which executes each test file) does the destroying, bootstrapping, and log archival. The tests can be written in anything (amulet, for example)
<rogpeppe> marcoceppi: can you reproduce that bug?
<rogpeppe> marcoceppi: i really don't have much to go on until i see a way to reproduce it - nothing jumps out in the code
<marcoceppi> rogpeppe: not personally, but lazypower and mbruzek both can
<marcoceppi> and noodles775 just encountered the issue as well
<mbruzek> Hello rogpeppe which bug are we talking about
<rogpeppe> lazypower, mbruzek: it would be great if you could add the way you can reproduce the bug to the #1269519
<_mup_> Bug #1269519: Error on allwatcher api <juju-core:In Progress by rogpeppe> <juju-deployer:Confirmed> <https://launchpad.net/bugs/1269519>
<mbruzek> rogpeppe, I just did it today, it happens when I run an amulet test on my local juju environment
<mbruzek> 1.17.0-trusty-amd64
<mbruzek> I can send you the amulet test if you like?
<rogpeppe> mbruzek: if you could post a from-scratch way that you can reproduce it to that bug, that would be marvellous, thanks!
<rogpeppe> mbruzek: better to attach it to the bug report, i think
<mbruzek> Yes absolutely.  My only concern is there is nothing special I am doing, no complicated setup.
 * noodles775 can do that too, I've got a public branch.
<mbruzek> And I have not committed my amulet test
<mbruzek> no wait it is committed just not pushed,  will update bug
<noodles775> rogpeppe: my repro instructions too - I'll add them to the bug. http://paste.ubuntu.com/6768177/
<Ming_> What is best way to layout my charm source if I want to support multiple Ubuntu release?  I see most charm has precise/<charm name>. But seems I need change it saucy/<charm name> if want to deploy the charm on Ubuntu 13.10
<Ming_> at lest with local provider
<marcoceppi> Ming_: that's correct, typically people will create ~/charms/{precise, saucy}, then put their charm in precise, and symlink it to saucy
<Ming_> k. thx
<Ming_> Does charm must use suggested template for the shape?  Our company has rule on logo/icon. I have hard time to select background color.
<Ming_> I mean charm icon
<marcoceppi> Ming_: yes, if you want the charm in the charm store it should follow our charm icon guidelines. Depending on the icon we may be able to make exceptions
<marcoceppi> Ming_: you should email juju@lists.ubuntu.com about that
<Ming_> Thanks Marco.  We talked before in the workshop you and Jorge provided.
<marcoceppi> o/ awesome welcome back
<noodles775> marcoceppi: after calling d.configure() to change some charm configs after an initial deployment, what needs to be called to do the juju set's? (I expected d.configure() to do that, but it just sets some state in a local dict).
<lazypower> d.setup() i believe
 * noodles775 tried that, but the expected config change didn't happen... it works fine with juju set though. I'll keep digging, thanks lazypower
<marcoceppi> noodles775: this is a bug atm
<mbruzek> So configure does not set the values?
<Ming_> Can I call "relation-get" and "relation-set" in config-changed hook?
<marcoceppi> mbruzek: it does, just not after deployment
<marcoceppi> Ming_: not easily
<marcoceppi> noodles775: https://bugs.launchpad.net/amulet/+bug/1270174
<_mup_> Bug #1270174: Post deployment commands <Amulet:Triaged by marcoceppi> <https://launchpad.net/bugs/1270174>
<lazypower> Ming_, Its best practice to create relational hooks to work with any data coming over the wire for the relationship.
<Ming_> but I cannot configure our cluster when all nodes are ready. I want to manually trigger the action through configure-changed
<mbruzek> Hello Juju.  I am encountering a problem with my local LXC environment.  When I run juju status I see
<mbruzek> agent-state-info: '(error: container "mbruzek-local-machine-1" is already cr
<mbruzek> eated)'
<marcoceppi> mbruzek: you had a dirty stage
<mbruzek> I recognized this as a clean up error that jorge reportd in bug 1227145
<_mup_> Bug #1227145: Juju isn't cleaning up destroyed LXC containers <cts-cloud-review> <local> <papercut> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1227145>
<mbruzek> Marco I cleaned up since my last bootstrap and I watched the script remove those files
<marcoceppi> Ming_: there is a way to do this, the relation hooks set special environment variables, so you'll need to record these for each unit then when you want to run the commands you'll need to loop through the available units on the relation and set the -r flag for relation-get/set
<marcoceppi> Ming_: I don't know off the top of my head and I'm not at my main computer to get you exact details, you may want to mail juju@lists.ubuntu.com or ask on http://askubuntu.com/ with the tag juju and Ican get back to you (or someone else) with more details
<mbruzek> marcoceppi, you are right I remembered to run the script
<Ming_> Sure. thx
<mbruzek> But I see they were directories rather than files
<marcoceppi> mbruzek: yes, they're the contents of the LXC container
<mbruzek> my scritpt tried to rm those rather than rmdir or rm -rf
<mbruzek> Thanks
<mbruzek> fixing that
<rogpeppe> noodles775: i didn't get too far with your instructions - i get this error when trying to run 00-single-node-install: http://paste.ubuntu.com/6768907/
<rogpeppe> noodles775: is "requests" a python module that i should apt-get from somewhere?
<rogpeppe> mbruzek: ^
<lazypower> rogpeppe, sudo apt-get install python-requests
<rogpeppe> lazypower: ta!
<mbruzek> rogpeppe, I don't have import requests in my code
<mbruzek> Do I ?
<rogpeppe> mbruzek: the third line in 00-single-node-install ?
<mbruzek> 00-single-node-install is not my code
<mbruzek> Not the one I posted.  basic_deploy_test.py
<mbruzek> That is the one in the tests directory
<marcoceppi> mbruzek: I think it's a bad dep on the amulet package
<mbruzek> OK
<marcoceppi> since amulet uses requests
<mbruzek> yeah I got it
<rogpeppe> ha, it barfs on my environments.yaml
<Ming> Is there a way to broadcast an event to every node? change configuration variable persist the change so is not desired in this case
<Ming> HI Marco, I sent the email to juju@lists.ubunut.com
 * rogpeppe hates yaml, once more
<mgz> rogpeppe: when in doubt, just write json :)
<rogpeppe> mgz: i do, and i did
<rogpeppe> mgz: but the python yaml parser barfed on it
<rogpeppe> mgz: it didn't like my tab characters
<rogpeppe> mgz: perfectly valid json :-)
<rogpeppe> mbruzek: i was trying to follow Michael Nelson's (noodles775?) instructions, since they seemed a little more specific, but it's not working for me; i'll try yours
<rogpeppe> mbruzek: should i get juju-deployer via apt-get or branching a repo?
<mbruzek> I am in a meeting, I didn't do anything to juju-deployer
<mbruzek> I used apt-get to get juju-deployer
 * mbruzek is in a meeting
<rogpeppe> mbruzek: thanks
<rogpeppe> mbruzek, noodles775: i got a traceback from the code, but the issue itself doesn't seem to have reproduced (i don't see the "state watcher was stopped" error mentioned in the bug description and logs)
<rogpeppe> ah, sorted that out
<rogpeppe> mbruzek, noodles775: reproduced! thanks v much for the test case
<mbruzek> great
<rogpeppe> mbruzek, noodles775: found the bug, i'm pretty sure
<mbruzek> Great
<rogpeppe> marcoceppi: ^
<marcoceppi> rogpeppe: excellent!!!!!
<rogpeppe> marcoceppi: the issue is that if a client connection goes three minutes without sending a Ping, it gets terminated
<rogpeppe> i'm not sure that's actually what we should do for a client connection, but i'm pretty sure that's the culprit
<marcoceppi> rogpeppe: is it something we can patch in on jujuclient python lob? to juat send a ping
<rogpeppe> marcoceppi: probably
<rogpeppe> marcoceppi: except that the python library doesn't allow concurrent requests, which is a bit of a problem
<rogpeppe> marcoceppi: so no, i think it might not be possible to fix without fixing that client lib
<rogpeppe> marcoceppi: we could probably just turn off the ping requirement for non-agents.
<rogpeppe> marcoceppi: it's really there so that we know when agents are still alive
<marcoceppi> rogpeppe: thatd be great
<rogpeppe> marcoceppi: i objected to this feature when it was implemented originally FWIW
 * rogpeppe likes naivity
<mbruzek> Hello Juju.  I am trying to use juju 1.17.0-trusty-amd64 with trusty and a local lxc environment.
<mbruzek> I am aware of the clean up commands that Jorge put on askubuntu
<mbruzek> When I bootstrap a clean local environment it comes up ok, but when I try the first deploy I see the following in my juju status
<mbruzek> agent-state-info: '(error: symlink /var/lib/lxc/mbruzek-local-machine-1/co
<mbruzek> nfig
<mbruzek>       /etc/lxc/auto/mbruzek-local-machine-1.conf: no such file or directory)'
<mbruzek> I can paste bin the whole thing, if that helps
<mbruzek> I am certain the /var/lib/lxc/mbruzek-local-machine-1 directory was cleaned up from the script
<mbruzek> http://paste.ubuntu.com/6769679/  <- Whole juju status
<mbruzek> Does anyone on the juju team have an idea?
<mbruzek> of what is wrong
<mbruzek> It looks similar to Jorge's bug 1227145
<_mup_> Bug #1227145: Juju isn't cleaning up destroyed LXC containers <cts-cloud-review> <local> <papercut> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1227145>
<mbruzek> But I used the commands he has to clean up after a destroy-environment and can not get anything to deploy on my local env
<mbruzek> That bug is linked to 1238541
<rick_h_> mbruzek: yea, I have the same issue. I assumed it was trusty/lxc bits getting sync. Looking at that bug looks ilke it's set for 1.17.1
<mbruzek> is there any way I can get that version?
<rick_h_> sinzui: what's the next release timeframe that might include that?
<mbruzek> Can I add the dev repository ?
<sinzui> rick_h_, maybe next week.
<mbruzek> What package is it in so I can watch for it?  juju-core?
<sinzui> mbruzek, you can add the dev repo. 1.17.x does not work with 1.16.x and it is unstable; it is not suitable for production use yet
<sinzui> mbruzek, that's right, juju-core
<mbruzek> I am trying to make progress on amulet tests for the eco team
<rick_h_> mbruzek: bring up a non-trusty venv?
<mbruzek> Right will do that.
<mbruzek> Thanks for clarification rick_h_ and sinzui
<mbruzek> I will look for this next week
<mbruzek> and work on a different env in the mean time
<sinzui> mbruzek, I can provide precise, saucy, and trusty debs that we build for testing
<sinzui> mbruzek, http://162.213.35.54:8080/job/prepare-new-version/ always shows what we built for testing
<mbruzek> That is great now I know where to look.
<jcastro> marcoceppi, this one is all you: http://askubuntu.com/questions/407010/413-request-entity-too-large-nginx-1-1-19
<rogpeppe> mbruzek, marcoceppi: i've proposed a fix: https://codereview.appspot.com/53810045
<adam_g> the mysql charm is not deployable on newer ubuntu versions. when can we expected trusty charms to start showing up?
<jcastro> adam_g, probably in the next few weeks
<arosales> does anyone know what the tools-url for aws is off hand?
 * arosales is working around https://bugs.launchpad.net/juju-core/+bug/1254401 
<_mup_> Bug #1254401: error reading from streams.canonical.com <bootstrap> <juju-core:Fix Committed by wallyworld> <https://launchpad.net/bugs/1254401>
<arosales> I thought it was tools-url: http://juju-dist.s3.amazonaws.com/tools
<wallyworld_> arosales: try http://juju-dist.s3.amazonaws.com/
<wallyworld_> without the /tools at the end
<arosales> wallyworld_, thanks I did get aws bootstrapped with     tools-url: https://juju-dist.s3.amazonaws.com/tools
<arosales> I needed to remove .juju/environments/aws.jenv first though
<wallyworld_> ok
#juju 2014-01-18
<mbruzek> Is there a trick to ssh to the juju machines on local host?
<mbruzek> juju ssh <machine-number>
#juju 2014-01-19
<coventry> "juju bootstrap" fails for me with "(Permission denied (publickey).)"  I can definitely ssh to the bootstrap-host as the bootstrap-user.  What might cause this?
<john00santos> Hello, anyone ever seen this error?  timed out waiting for mgo address from []
<coventry> I upgraded to juju 1.17.1.  It gives a little more information from "juju bootstrap --show-log".  It says that it's initializing with user "", which I suppose is the reason I'm getting a (Permission denied (publickey).) error.  How can I fix this?  I have "bootstrap-user: root" in the "null" stanza of environments.yaml.
<marcoceppi> coventry: the room is typically quiet during the weekend. you can email juju@lists.ubuntu.com or ask on askubuntu.com which will allow you to persist your question
<coventry> marcoceppi: Thanks for the info.
#juju 2015-01-12
<stub> TheFezzer: I'm currently using webup8's Oracle JVM packages, but still need to run the approach past legal. If legal disagrees, I'm stuck with requiring users to provide the tarball.
<stub> TheFezzer: Look for jvm in https://bazaar.launchpad.net/~stub/charms/trusty/cassandra/spike/view/head:/hooks/helpers.py
<stub> TheFezzer: It is also an example of supporting proprietary software, since the DataStax edition of Cassandra can be used.
<TheFezzer> I think that if I require the user to actively flip the config flag, weâre good. Otherwiseâ¦ wait a minute. Is there a single developer alive who hasnât yet signed the Oracle EULA at some point or another?
<TheFezzer> itâs free to try, and weâre not even stuffy about licenses.
<TheFezzer> We give it to ASF for free, even. ;)
<stub> TheFezzer: Well... it is probably a statistically insignificant number, so statistically it is 100%. So yes, everyone has signed the license even if they haven't :)
<stub> The most annoying part is testing
<TheFezzer> the particular product Iâm working on today is okay with open-jdk so pshaw. ;)
<stub> How can an automated test runner accept a license agreement?
<TheFezzer> Iâm making my first Python charm, and wow the features.
<TheFezzer> It seems like someone was saying earlier that IBM was okay with someone flipping a config flag and that released the charm to do it?
<TheFezzer> websphere-liberty
<TheFezzer> but one would presume that Amulet would be empowered to flip a flag
<stub> I imagine, as the author of the test and person who installed it into the test runner, I would be the person who accepted the license. If I lived in a jurisdiction where it had any effect, which I don't.
<stub> Which is why I punt it to legal later, since I'm not the person who would get sued :)
<stub> But yeah, websphere should have already jumped any hurdles. I'll have a look myself later.
<TheFezzer> :D
<catbus11> why the icon bounces back to where it was in the juju gui canvas? Why doesn't it stay where I dragged it to?
<catbus11> I can't see all the icons without moving the canvas left or right. It's been zoomed out to the max.
<gnuoy> jamespage, do you have anytime to take a look at https://code.launchpad.net/~gnuoy/charm-helpers/nrpe-service-functions/+merge/246104 ?
<jamespage> gnuoy, +1
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charm-helpers/kilo-enable/+merge/245870
<jamespage> if you have time please
<gnuoy> jamespage, +1
<gnuoy> jamespage, I'll merge yours while I'm at it
<jamespage> gnuoy, thanks
<jamespage> gnuoy, are you going todo a general charm helper sync post that?
<gnuoy> jamespage, I am as part of this nrpe work
<jamespage> gnuoy, awesome - I won't bother then
<gnuoy> kk
<gnuoy> jamespage, a small mp if you have a moment https://code.launchpad.net/~gnuoy/charm-helpers/add-nrpe-gethostname/+merge/246110
<gnuoy> jamespage, dosaboy, coreycb I have a bunch of mps based on bradm s work to add nrpe. Most of the logic has landed in charmhelpers so mostly it's a charmsync plus a bit. There are a few of them but any reviews greatly appreciated https://pastebin.canonical.com/123178/
<jamespage> gnuoy, as they are re-syncs + tweaks to the nrpe stuff in the charms, I'm happy to give a conditional +1 across the board based on osci checking things out OK
<gnuoy> jamespage, I'll take that! thanks
<jamespage> gnuoy, have those syncs for nrpe landed yet? going to start testing kilo support tomorrow
<gnuoy> jamespage, osci is still working through. But on the subject of those mps, does your +1 stand for branches with no amulet tests?
<jamespage> gnuoy, yes
<gnuoy> ta
<gnuoy>  jamespage those mps are merged with the exception of cinder. The amulet tests are failing atm. I don't think it's related but I'm checking.
<beisner> lazyPower, around?
<lazyPower> beisner: in a pairing session, replies may be latent. whats happening?
<beisner> hi lazyPower nothing urgent.  just want to pick your brain a bit some time re: bundletester - i've gotten onto another track as well, will holler another time.
<lazyPower> beisner: sounds good - ping me whenever and i'll be happy to respond with what i know
<jose> guys, would you say advertisement is allowed in a charm's readme? found something that looks like it.
<sarnold> tastefully on-topic might be alright..
<noise][> hi, I'm just getting started w/mojo and trying to figure out how to make mojo run work w/locally modified a spec, but it seems to be pulling from the latest commit even when I specify my spec_url as a local file path
<skay> noise][: is your local file path a local bzr repo?
<skay> noise][: I have been using a local bzr repo successfully
<noise][> skay: it's a bzr repo, yes
<skay> noise][: have you committed the changes you wnat it to run?
<skay> if yes and yes, then I am out of suggestions
<noise][> no, uncommitted
<skay> I am very new myself
<skay> oh, okay. commit them and then run
<noise][> :( , kinda tedious for each change and going to make for a long commit history
<skay> :( yeah
<noise][> skay: well thx for the tip in any case
<skay> there is probably something I'm missing, and hopefully you'll get a reply with a proper response
<skay> meanwhile this maybe be a workaround
<roadmr> noise][, skay : since mojo uses bzr to fetch (think: branch) the spec from the target repo, it will pull only committed changes. Yes, it would make for a somewhat longish history but that's how bzr works anyway
<noise][> roadmr: ok, an unpleasant debug cycle,. but i'll press ahead
<skay> roadmr: the history drives me crazy :)
<roadmr> noise][: you could always work until you have amassed a good set of changes, then bzr uncommit until you have a blob you like, and recommit everything in a single commit. Not as powerful as git history manipulation but could do the trick
<skay> roadmr: I admit I sometimes play around with a completely local repo until I've flogged something to death THEN I go commit it to the real place
<noise][> roadmr: my kingdom for git rebase :)
<roadmr> noise][: ah, if you test, then flip something minor then test again, you could bzr uncommit, do the tweak, then bzr commit again. That will keep your history from growing too much. Only problem is, if you want to change something you committed N revisions ago (N > 1) it will be more painful
<skay> noise][: did anyone tell you about git-lp? sometimes I use it
<skay> it won't help with this though
<roadmr> skay: yea, that'd be the other option (using a scratch bzr repo)
<skay> noise][: where did you learn about mojo?
<skay> I only recently started using it
#juju 2015-01-13
<seal1> How do I approach sending over a masker ssh key to a related slave for the jenkins and jenkins-slave charm? I have taken the follwoing approach and cannot find the documentation of how to access a related unit - https://gist.github.com/slatunje/c357791dcc1b42d4df12
<jamespage> gnuoy, could you review - https://code.launchpad.net/~james-page/charm-helpers/lp.1391784/+merge/242422
<jamespage> it adds a default backend to all haproxy configurations that will loadbalance over private-address
<gnuoy> yep (otp at the mo)
<jamespage> gnuoy, ta
<gnuoy> jamespage, unit_test fail
<jamespage> gnuoy, oh joy
<jamespage> gnuoy, let me see
<jamespage> gnuoy, fixed and pushed
<gnuoy> jamespage, merged
<jamespage> gnuoy, thanks!
<jamespage> gnuoy, are you ok for me to sync that out to the next charms?
<gnuoy> jamespage, absolutely
<jamespage> gnuoy, done
<mwak> hi
<marcoceppi> Is there any charmhelper to run a command as a user?
<lazyPower> marcoceppi: not at present, no.
<marcoceppi> lazyPower: ta
<mwak> o/ marcoceppi lazyPower
<lazyPower> o/ mwak
<marcoceppi> \o mwak
<mwak> still fighting with the hadoop charm
<mwak> I ve rebuilt hadoop on armhf but still the same issue with hdfs
<lazyPower> mwak: it sounds more like there's an issue with the setup than with the binaries. but I cant really confirm that at present.
<lazyPower> mwak: have you tried a single node setup vs the cluster so there's fewer moving parts to debug?
<mwak> lazyPower: you mean juju deploy hadoop and then run the test on the machine?
<mwak> right
<mwak> ?
<lazyPower> yeah
<lazyPower> mwak: just teh master/slave nodes actually - you'll still need a yarn controller and some computes - so single node is a mosnomer on my part.
<mwak> I did, but I just respawn to re-try
<mwak> What I did atm is re-built hadoop from the source on an armhf server, edit the charm to use the oracle jdk
<lazyPower> yeah that shouldn't have much effect - it should still work without any issue being java is mostly portable among jre's
<mwak> yep but there are .so libraries which were not built for arm.
<lazyPower> very true, the bins they bundle with it
<mwak> lazyPower: I have to start it manually when I deploy on a single node?
<lazyPower> mwak: start manually + i think you'll have ot edit the configs to point to the local microservices - as those are not set until relationship exchange
<mwak> alright
<mwak> it is started!
<mwak> interesting
<mwak> http://pastebin.com/7DEb6bMG
<lazyPower> mwak: smells like progress to me
<mwak> right, but cpu usage is 0%
<mwak> :/
<lazyPower> so the job itself is probably failing to start
<lazyPower> but the microservices are connecting
<mwak> yep
<mwak> looks like the problem occurs when relation change
<mwak> http://212.47.235.30:8088/cluster/app/application_1421159802799_0001
<jamespage> gnuoy, know you are probably a busy man, but could you review the MP's on https://bugs.launchpad.net/charms/+source/nova-cloud-controller/+bug/1391784
<mup> Bug #1391784: HA failure when no IP address is bound to the VIP interface <openstack> <cinder (Juju Charms Collection):In Progress> <glance (Juju Charms Collection):In Progress> <keystone (Juju Charms Collection):In Progress> <neutron-api (Juju Charms Collection):In Progress> <nova-cloud-controller
<mup> (Juju Charms Collection):In Progress> <openstack-dashboard (Juju Charms Collection):In Progress> <percona-cluster (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1391784>
<jamespage> they re-introduce the cidr and iface configurations options as fallbacks for when people want to bind VIP's to subnets which are not also configured as subnets for primary addresses
<jamespage> dimitern, see the crazy networking stuff that people get up to ^^
<jamespage> dimitern, its an edge case but one for which I've had two separate bug reports for
<dimitern> jamespage, wow :)
<dimitern> jamespage, is there something juju can do for these short-term?
<jamespage> dimitern, not really - its an accidental feature that we took away last cycle ...
<jamespage> dimitern, but it does highlight what things people do
<jamespage> dimitern, I've categorically never ever deployed an HA solution in that way
<jamespage> but apparently some people do
<rick_h_> deryck: ! dude
<deryck> Hi rick_h_!
<dimitern> jamespage, I'll have a closer look for educational purposes then :)
<jamespage> dimitern, sounds like a good idea
<gnuoy> jamespage, approved
<jamespage> gnuoy, thanks!
<lazyPower> mbruzek: whit:  https://pythonhosted.org/charmhelpers/api/charmhelpers.payload.html  -- docs on teh execd pattern in charmhelpers
<lazyPower> dannf: landed your arm64 update to mongodb. Thanks for the patience on this one - looks really good, i like the pattern you used to do this too
<dannf> lazyPower: ack, thx!
<lazyPower> stub: ping
<lazyPower> Looking over your merge against precise postgres charm - does this warrant additional action against the trusty charm as well when accepted for precise? https://code.launchpad.net/~stub/charms/precise/postgresql/manual-replication/+merge/240556
<lazyPower> or is this scoped strictly to precise
<alexis_> hello everyone
<lazyPower> btw mbruzek i landed those arm64 changes. Make sure you sync with master if/when the review you're working on is ready.
<lazyPower> o/ alexis_
<alexis_> hello how are you
<mbruzek> lazyPower: the mongodb tests fail for me.
<jcastro> lazyPower, can you check this  pls? https://github.com/juju-solutions/juju-solutions.github.io/pull/21
<lazyPower> jcastro: need it merged or just asking if it looks right? cuz +1
<jcastro> I didn't want to merge it because I wrote it
<jcastro> That's just nice manners right? But yeah, merge pls.
<lazyPower> done
<lazyPower> :)
<lazyPower> mwak: I'm still a bit confused on the diagnosis of whats wrong. but based on the last pm - you need to restart all the hadoop services and ar easking how to do so?
<lazyPower> cory_fu: ^
<lazyPower> can you help mwak triage some port binding and service management in the apache hadoop charm
<mwak> lazyPower: at the moment I have
<mwak> : running the terasort.sh give me the following output
<mwak> ubuntu@onlinelabs-d2d614b9ffa944a5bfd0731c3e3bf18d:~$ /usr/local/hadoop/terasort.sh
<mwak> rm: `in_dir': No such file or directory
<mwak> 15/01/13 16:18:36 INFO client.RMProxy: Connecting to ResourceManager at /10.1.8.72:8032
<mwak> 15/01/13 16:18:38 INFO ipc.Client: Retrying connect to server: onlinelabs-d2d614b9ffa944a5bfd0731c3e3bf18d/10.1.8.72:8032. Already tried 0 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
<mwak> ubuntu@onlinelabs-d2d614b9ffa944a5bfd0731c3e3bf18d:~$ lsof -i  | grep 8032
<mwak> java    8997 ubuntu  183u  IPv6  13866      0t0  TCP localhost:8032 (LISTEN)
<mwak> It looks like there is a bind problem
<mwak> curl localhost:8032 -> ok | curl 10.1.8.72:8032 -> refused
<lazyPower> mwak: yeah, seems like its bound to local and not the interface
<lazyPower> mwak: that should be defined in site.xml
<lazyPower> or core-site.xml
<mwak> in core-site i have
<mwak>     <value>hdfs://10.1.8.72:9000</value>
<mwak> What should I do to bind on the 10.1.8.72 instead 127.0.0.1
<mwak> ?
<mwak> which file to edit
<cory_fu> yarn-site.xml
<jcastro> lazyPower, I get this http://pastebin.ubuntu.com/9731838/
<cory_fu> Looking for yarn.resourcemanager.address
<cory_fu> mwak: ^
<lazyPower> jcastro: do you have bundler installed?
<lazyPower> if so, create a Gemfile in your repository and place the following in it:
<cory_fu> That gets populated from either `unit-get private-address` or `relation-get private-address` in the charm, neither of which should return localhost
<jcastro> lazyPower, yeah
<lazyPower> https://gist.github.com/4ca44ea8c7251d01dadd
<lazyPower> that should get jekyll and all teh required gems
<mwak> cory_fu: the address is correct in yarn-site.xml
<mwak> <value>10.1.8.72:8032</value>
<lazyPower> then bundle exec jekyll serve
<mwak> Oo
<cory_fu> Hrm.  Actually, now that I think about it, that's probably the wrong end of the config, there
<jcastro> lazyPower, I get "could not locate Gemfile", but also github isn't generating the page either
<lazyPower> jcastro: let me pull the repo and see whats up, 1 sec.
<lazyPower> this may be environment vs configuration
<mwak> cory_fu: hum ok..
<cory_fu> mwak: Still looking...
<jcastro> lazyPower, afaict I've followed every instruction exactly.
<mwak> cory_fu: FYI all value in yarn-site.xml are binded
<mwak> to localhost and not private ip
<lazyPower> jcastro: i've got all kinds of jekyll errors spewing at me atm when i pull wahts in master
<cory_fu> mwak: Wait, what?  I thought you said it had the non-localhost IP address?
<mwak> sec
<mwak> will paste the file
<cory_fu> Ok
<mwak> http://pastebin.com/6yB2MnWt
<lazyPower> jcastro: i know why its not generating
<lazyPower> the post layout expects there to be a date
<lazyPower> you need to frontload this with all the data points you would have in a normal blog post
<jcastro> for post, not pages though right?
<lazyPower> the layout:post is whats telling jekyll waht to load and parse this page content file as
<mwak> cory_fu: http://pastebin.com/tnK9rsRw
<lazyPower> 2 options - add the data points to make this like a blog post so it satisfies the liquid variables, or add a layout that strips those variables it wants.
<stub> lazyPower: The PostgreSQL precise and trusty branches are identical, so I'll get them in sync later.
<lazyPower> stub: 10-4, thanks for confirmation
<cory_fu> mwak: That seems correct.  Not sure why it would have bound to localhost, then
<stub> lazyPower: Thanks for the review :)
<jcastro> lazyPower, could I use "default" for the post layout instead of post?
<lazyPower> jcastro: i added a date and it worked as expected
<mwak> cory_fu: to restart the master what should I do? run the stop-all.sh / start-all.sh scripts?
<jcastro> lazyPower, I changed it to "default" and it works now as expected
<jcastro> lazyPower, thanks for the help
<lazyPower> np
<jcastro> http://blog.juju.solutions/containers.html
<jcastro> blam, instant generation
<jcastro> now to fix the content ...
<TheFezzer> hey there lazypower, if youâre into reviewing charms, can I show you one?
<cory_fu> mwak: I imagine that would work, though the charm uses, e.g., su yarn -c '/usr/lib/hadoop/hadoop-2.4.1/sbin/yarn-daemon.sh --config /etc/hadoop/conf.juju stop resourcemanager'
<lazyPower> TheFezzer: is it in the queue? :) we have several in here that have waited their turn to get reviewed.
<adalbas> hi! i'm trying to write charms using the python charmhelpers. When I ran "charm create -t python mycharm", i got a different structure than expected (no hooks.py, no cham-helpers.yaml). Does anyone have the same problem?
<jcastro> whit, do you have any kubernetes information I could add to this page?
<lazyPower> adalbas: proibably looking for python-basic
<TheFezzer> uhh, iâm not sure I can really do that sort of stuff without a sign-off from Legal. Oracle has /claws/.
<lazyPower> adalbas: the charm create -t python generates a services framework charm.
<whit> jcastro, looking
<lazyPower> TheFezzer: lets take this out of band, if you're working on ISV work we can work something out for you to get regular charm reviews as a partner until its in the queue.
<adalbas> lazyPower, so i should use charm create -t python-basic instead, is that it?
<lazyPower> s/queue/store/
<lazyPower> adalbas: give that a go and see if thats what you're looking for.
<adalbas> lazyPower, thanks!
<jcastro> lazyPower, unless anyone objects I'm not going to PR work on the team blog, too heavyweight for now, leave that for the posts themselves I figure.
<lazyPower> jcastro: i'm not sure what you're telling me - pr work? OH you mean github pull request? i think we're ok with that for now as you work on those topic pages.
<lazyPower> but i defer to the team, as there's several of us involved in that.
<TheFezzer> Ya, I just really want a once-over aka sanity check
<TheFezzer> not any sort of serious review
<whit> jcastro, we could add some links I guess, let me get those
<whit> jcastro, https://github.com/kapilt/bundle-kubernetes
<whit> jcastro, that will be the main entry point
<whit> jcastro, should be good to start with
<jcastro> ta
<jcastro> http://blog.juju.solutions/containers.html
<jcastro> ok, now we're cooking!
<lazyPower> aww yeee
<lazyPower> jcastro: might want to link to the docker charm docs as well...
<lazyPower> http://chuckbutler.github.io/docker-charm/
<jcastro> yeah, after lunch
<jcastro> ta
<jcastro> <--- lunch
 * marcoceppi lunchy lunch lunch
<mwak> cory_fu: don't understand why, but after restart it is the same
<mwak> the wrong interface is bind
<cory_fu> mwak: Strange.  I'm deploying it now to see if I get the same results, though on aws instead of onlinelabs
<mwak> alright
<mwak> fyi if i bind on 0.0.0.0 it works
<mwak> oO
<mwak> all interfaces are listening
<captine> evening all.  just started playing with juju on my local machine (desktop) and wanting to know if there is a way to allow other machines on my network to connect to the juju services? I see the juju containers get their own IP address which is different to that of my lan.
<captine> some pointers would be much appreciated.
<TheFezzer> I found that the sshuttle instructions for OSX.9 were good
<TheFezzer> but the ones for X.10 were better
<TheFezzer> also welcome to the club :)
<lazyPower> captine: i have a write up for that 1 moment
<captine> lazyPower, that would be awesome. Thnx
<lazyPower> captine: http://blog.dasroot.net/making-juju-visible-on-your-lan.html
<TheFezzer> captine if you do either of those, you can just use the address from juju status or from the unit panel in the gui
<captine> thanks.  I will check it now.  I want to be able to access some of the services from outside my lan, so as long as I can do some forwarding from the router, it will be perfect.
<TheFezzer> nice doc
<TheFezzer> :D
<lazyPower> Ta :)
<cory_fu> mwak: Sorry it took so long, but it finally finished deploying.  On AWS, everything seems to have bound correctly: http://pastebin.ubuntu.com/9733248/
<cory_fu> mwak: Also confirmed that the terasort.sh worked.  Let me pastebin the exact deploy steps I used
<mgarza> Regarding MariaDB or MySQL charms is it possible for another charm to create multiple databases without using the db-admin relation?
<cory_fu> mwak: http://pastebin.ubuntu.com/9733381/
<lazyPower> mgarza: you'd need to use the db-admin relationship
<lazyPower> mgarza: the defaults for the db relationship assume a single db per service that is related
<whit> hey marcoceppi for backporting commits from the trusty version of a prescise charm (w/no tests), what's the procedure wrt review?
<lazyPower> mgarza: it sounds like a possible reason to add another relationship if you want to do an exchange cycle of what the app needs. i'd like to see that chatter back and forth before anything was merged - but i'm def. interested in your take on how it should work.
<marcoceppi> whit: open a merge from trusty version to precise
<whit> marcoceppi, thinking of https://code.launchpad.net/~niedbalski/charms/precise/mysql/precise-syncup/+merge/244436
<whit> marcoceppi, that's been done, I'm asking what I should do re reviewing
<whit> automated test failure is a AWS hiccup
<marcoceppi> whit: I'll kick off another test, but that's about it, it's just a normal review. Really just make sure it deploys and works on precise
<whit> marcoceppi, thanks
<whit> will do
<mgarza> lazyPower: Thanks I just wanted to make sure
<lazyPower> np
<cory_fu> mwak: I can't get onlinelabs to bootstrap, though, so I can't test it there.  :/  (Getting prompted for root password, despite having added my juju ssh key via the website.  Tips appreciated.)
<lazyPower> cory_fu: you should add your personal id_rsa - as thats what its using to connect for the intial bootstrap
<lazyPower> *id_rsa.pub
<captine> hi lazyPower.  I already had some juju instances and have tried following some articles on cleaning my local juju and redoing it, but keep getting the following "ERROR there was an issue examining the environment: cannot use 37017 as state port, already in use"
<captine> when trying to bootstrap again
<mwak> cory_fu: gimme a sec
<lazyPower> captine: interesting - are you running something on port 37017?
<lazyPower> captine: if not, it sounds like there may be a stale api-server around, and can you show me a pastebin of the output from initctl --list | grep juju
<lazyPower> sorry, no double tack on the list command:  initctl list | grep juju
<captine> no idea.
<captine> i also see my eth0 dissappeared... only have wireless now..  lol.  fun learning
<jose> rick_h_: ping
<captine> nothing shows
<captine> just blank
<marcoceppi> captine: it sounds like you deleted the upstart job before stoping it
<captine> mmm.  not sure i follow (am just a simple accountant playing around :))
<marcoceppi> captine: if you do a `ps -aef | grep juju`
<marcoceppi> you should see 0 results
<marcoceppi> but you'll probably see a jujud and a mongod running
<captine> i see it is running
<captine> do i do a killall -9 or something?
<marcoceppi> captine: kill those processes
<marcoceppi> just a kill on each process id (the second colum) is sufficient
<captine> i type "sudo kill xxxx" where xxx is the id.  after doing it for each, the ps - aef shows more processes with different id's.  Like it is respawning or something
<lazyPower> well thats fun... we're playing chase the pid huh?
<sarnold> pkill can help obliterate lots of pids :)
<lazyPower> sarnold: why do i never think of this in the hot seat? good insight.
<captine> yip
<captine> cannot type fase enough
<captine> lol.  pkill didnt help, unless there is an option i should use
<captine> would they start up after rebooting?
<captine> I can try that
<lazyPower> captine: that might resolve it but i know that hjistorically we placed upstart jobs for the containers
<lazyPower> it also appears some of the upstart dependency concerns have moved as well
<lazyPower> we should see jujud in the listing from initctl
<lazyPower> or we used to
<captine> :)
<captine> change and progress... keeps it interesting
<lazyPower> ahhh ok
<lazyPower> if you sudo, those tasks should show up
<lazyPower> sudo initctl list
<lazyPower> also - i re-read the scrollback and know whats going on
<lazyPower> you did those bridge instructions on a running environment didnt you?
 * lazyPower makes a note to circle back and add that in huge warning text
<captine> sudo works
<lazyPower> ok, can you sudo service juju-db-<name>-local stop and run the same on the agent?
<captine> lazyPower, about the running environment... yip, think i did
<lazyPower> that should stop the pids from spawning like crazy
<lazyPower> and then we can go back and triage the environment
<lazyPower> as right now, its in a very inconsistent state
<lazyPower> its using lxcbr0 to communicate according to the jenv, but if you wiped that .jenv file - those lxc containers are still running and panicking that they cannot communicate with the state server
<lazyPower> so we'll need to start from scratch
<lazyPower> if there's any data you have in those containers - we can attach and preserve that info before wiping them - if its all inconsequential stuff all the better that we can have zero concern about whats in those lxc containers
<captine> na
<captine> i was just playing with them
<lazyPower> ok
<captine> no data to save
<lazyPower> so lets confirm we have the processes stopped of jujud
<captine> i couldnt stop the one service "juju-agent-$USER-local start/running, process 7472"
<captine> using the sudo service ... stop, it says it is unrecognized... and I copy pasted it from the service listing
<lazyPower> ok
<lazyPower> so we have a runaway process... can you pkill the zygote in psaux to ensure its been nuked with fire?
<lazyPower> sarnold: does that sound legit? ^
<captine> juju bootstrap is running now though
<captine> so lets see
<captine> :)
<lazyPower> captine: can you pastebin me the output of sudo lxc ls --fancy?
<lazyPower> captine: i want to see what lxc containers are left around from that old deployment so we can clean those up as well
<captine> lxc: command not found
<sarnold> lazyPower: the best part about pkill is that you can use e.g. pkill -u sarnold to kill all the processes from one uid.. I suspect it's still racy, but running it a few times might do the job
<lazyPower> sarnold: you probably dont want to pkill everything as the user you're logged in as
<lazyPower> i can see that being the cause of nuking your current session
<lazyPower> captine: sudo lxc-ls - my brain is failing me hard core today on commands
<lazyPower> captine: so to confirm, its sudo lxc-ls --fancy
<sarnold> lazyPower: oh, sure, but it works also for e.g. juju :)
<jrwren> agent-state-info: 'cannot run instances: gomaasapi: got error back from server: 409 CONFLICT (No node available.)'    how do I trigger a retry?
<captine> http://slexy.org/view/s202HrnQ3K
<lazyPower> jrwren: re-run the bundle deployment
<lazyPower> juju-deployer should pick up where it left off
<jrwren> lazyPower: *sigh* *grumble*  *ugh*   :p
<lazyPower> captine: ok, see all those -local-machine-# containers that are stopped?
<captine> lazyPower, do you work for Canonical?  how you guys all remember this stuff is beyond me
<captine> i think so
<captine> it says stopped
<jrwren> juju-deployer does some magic more than just issuing another deploy command?
<lazyPower> captine: you'll want to sudo lxc-destroy --name $name, the juju-$series-lxc-template containers can be left as is - they are used as clones to build the service containers.
<lazyPower> jrwren: i dont know ;)
<lazyPower> jrwren: use deployer though
<captine> thanks a mil.
<captine> will do so
<jrwren> lazyPower: *grumble*
<lazyPower> jrwren: <3
<lazyPower> captine: no problem, let me know if you run into any further blockers, and thanks a bunch for circling back that there was an issue - and i need to up date that guide :)
<captine> thanks for the guide.
<dalek57> do the juju charmhelpers provide a way to execute bash? I'm just doing subprocess.Popen right now. I'm not finding it in the docs
<dalek57> I'm trying to install rvm
<jrwren> dalek57: charmhelpers.core has liberal use of subprocess.check_call and subprocess.check_output, which are a bit easier than Popen, if you can get away with using them instead.
<dalek57> jrwren: well, I have a shell script for installing rvm saved in the charm directory, and I'd like to run it. If I were just doing this as a bash script, I could just do $CHARM_DIR/helpers/install_rvm.sh. Is there a best practice for doing this in python?
<jrwren> dalek57: I'm guessing call_check is what you want. the differences are what is captures as return values in python.
<jrwren> or maybe just subprocess.call()
<lazyPower> yeah subprocess is the successor to Popen and family
<lazyPower> dalek57: what jrwren outlined is what i would do. subprocess.call(['scripts','rvm_install.sh'])
<marcoceppi> or translate the rvm_install.sh script to python
<jrwren> or don't use rvm and package the ruby version you want for ubuntu.
<marcoceppi> except the ruby version in ubuntu is not the best
<jrwren> all the more reason to make it better.
<rick_h_> jose: pong, what's up?
<jose> rick_h_: hey! would it be a problem if I push a new docs folder for ES translated ones?
<jose> or would it be preferred to not do it yet?
<rick_h_> jose: hmm, so we're working on a deployment today/tomorrow that will udpate our docs loading
<rick_h_> If you had a change what would be great would be if you had that change in a fork
<rick_h_> jose: and then email us, we'd setup a QA to make sure that your fork worked and upgraded fine from where we're awt now
<rick_h_> jose: and fix any bugs on our end
<rick_h_> jose: and then once we're ready/sure it'll be fine merge your forked branch of the docs into trunk
<marcoceppi> jose rick_h_ is there any build process for other languages?
<rick_h_> marcoceppi: no, right now we just follow what you all were doing to build
<rick_h_> marcoceppi: so that's what I want to see, what's in the changes jose is speaking of
<jose> rick_h_: sure - I don't have direct push access. I guess I'll start translating today and will let you know once the branchis ready
<marcoceppi> rick_h_: so you're pulling from github or from the bzr branch?
<rick_h_> marcoceppi: from github
<jose> so, in the docs there is an en folder, I'd like to create an es one so I can translate the docs into Spanish
<rick_h_> marcoceppi: so if the org/structure of that process changes we need a heads up to make sure we're ready to follow the change
<jose> if that's not supported I'll hold my horses
<marcoceppi> jose: it'll be ignored by the build process
<rick_h_> jose: well fork the docs and do what you will and we'll work on a path to make sure things work and get pulled together
<rick_h_> jose: there's no reason not to start the work and we appreciate the heads up.
<jose> ok, cool
<marcoceppi> jose rick_h_ we want to do two additional things and this just reminded me that there's two build processes now
<jose> thanks
<rick_h_> marcoceppi: ok, we talked witht he web team to get docs redirected by the end of the week to jujucharms.com/docs
<rick_h_> marcoceppi: so yea, if we've got changes we need to know and sync up.
<marcoceppi> rick_h_: we want to create branches for releases of juju so we can tie docs to versions
<marcoceppi> rick_h_: let me knwo when is a good time to talk about that, it's a git change which won't effect master
<marcoceppi> but something we'd like to do
<marcoceppi> rick_h_: I'd like to talk to you about possibilties before chit chatting on the list
<marcoceppi> or we can do vice versa
<rick_h_> marcoceppi: sure thing, can we setup a call tomorrow?
<marcoceppi> rick_h_: yeah, sounds good
 * rick_h_ is out of the office working from the car dealer atm
<rick_h_> marcoceppi: either over lunch or after your standup work best?
<marcoceppi> rick_h_: either works
<rick_h_> marcoceppi: ok, sent. let me know if there's anyone else we should invite (nick?)
<marcoceppi> rick_h_: probably, we've chatted about this multiple times, but it wouldn't hurt
<rick_h_> marcoceppi: ok added
<marcoceppi> rick_h_: this would just be a "is this possible, how would this look" once that's figured out I'll mail the list with the intentions for feedback and go from there
<rick_h_> marcoceppi: sure thing
<rick_h_> we've thought about and made sure it's possible
<rick_h_> marcoceppi: so just have to get down to it
<dalek57> Why might subprocess.check_call(("./helpers/rvm.sh && source /etc/profile.d/rvm.sh && rvm install ruby-"+ruby_version).split(), shell=True) create a zombie process, and never complete the installation?
<dalek57> rvm is installed, but it doesn't get ruby-2.1.3, and when I juju ssh, I'm told that there is 1 zombie process
<lazyPower> dalek57: are you su'ing or re-initializing the shell?
<lazyPower> dalek57: sounds to me like you restarted teh shell and that caused it to tank leaving a zombie process
<dalek57> lazyPower: does `source` do that?
<lazyPower> depends on what you're sourcing
<lazyPower> cehck the file you're sourcing and make sure it isn't reinitializing the shell. i do beleive that rvm does that
<lazyPower> its fairly heinous like that.
<dalek57> yeah, ok. Well, when I run the command when I'm sshed in, it completes fine
<dalek57> would I see side effects of it reinitializing the shell?
<lazyPower> thing is, when you're ssh'd in youre in a shell
<lazyPower> when you reinitialize the shell in subprocess - you're not in a login shell you're in a thread nested inside the python process thats running
<lazyPower> so when you reinitialize teh shell, that thread goes away
<lazyPower> argh, netsplits :(
<sebas5384> hey!! somebody had this error before? https://gist.github.com/anonymous/0a88537322e6b4daa516
<lazyPower> o/ seal
<lazyPower> er
<seal> hi all
<lazyPower> sorry seal, netsplits are driving me batty with mistargeting people when trying to reply
<lazyPower> sebas5384: o/
<lazyPower> sebas5384: where did that error origniate? is that coming from your debug-log?
<lazyPower> dalek57: wb - did you get any of my response?
<seal> Is there a way to test the current hook being executed? I have tried if [[ $JUJU_HOOK_NAME == 'config-joined' ]]; then ... fi but this works within debug but fails when running
<lazyPower> I may be wrong, but i think that only gets exported during debug sessions - but marcoceppi may say i'm incorrect. A way to find out seal would be to dump your env at the beginning of the hook for inspection.
<seal> mmm
<seal> I ask since I am extending the jenkins / jenkins-slave within the hook/install.d/* and I need to execute base on the current hook
<seal> I will try the env dump
<marcoceppi> seal: it's possible
<marcoceppi> seal: but it's done by getting the basename of argv
<seal> ah I see
<marcoceppi> seal: so, basename $0 should give you hook name
<seal> thanks
<seal> will try that
<marcoceppi> np, that's how it's done in the Python Charm Helpers
<marcoceppi> seal lazyPower: for references: http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/core/hookenv.py#L160
<lazyPower> marcoceppi: Gracias. i forgot all about that.
 * marcoceppi intensifies hat tipping
<seal> marcoceppi: great tip
<sebas5384> lazyPower: hey! :)
<sebas5384> lazyPower: in the Drupal charm
<sebas5384> from nothing Â¬Â¬
<lazyPower> sebas5384: that tls error has to be coming from something... its either failing to handshake with the state server or something weird is going on in the env.
<sebas5384> yeah maybe is something like a timeout
<sebas5384> i'm in an instable internet right now
<dalek57> lazyPower: I'm getting strange behavior out of subprocess, and thought you might have more insight. subprocess.check_call('ls') returns a folder called ruby-install-0.5.0, but when I execute subprocess.check_call('cd ruby-install-0.5.0 && make install'), I get "no such file or directory"
<dalek57> I ran the command on the machine manually, and the make install doesn't error out
<sarnold> try make -C ruby-install-0.5.0 install instead
<lazyPower> ^
<sarnold> that avoids the use of the shell built-in 'cd', feels more likely to succeed to me
<lifeless> or
<lifeless> subprocess.check_call('make install', cwd='ruby-install-0.5.0')
<lifeless> IIRC
<sarnold> ooo
<sarnold> yeah that feels even more likely to work :)
<lifeless> you could set shell=True, but honestly, eewwwww.
<dalek57> sarnold: Thanks!
<sarnold> dalek57: check out lifeless's suggestion for cwd= -- it more closely replicates what you were doing with cd ... && make ...
#juju 2015-01-14
<X-Rob> https://bugs.launchpad.net/bugs/1409548
<mup> Bug #1409548: Multicast Address isn't randomized <hacluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1409548>
<X-Rob> Anyone wanna have a chat about that one?
<X-Rob> jamespage: dosaboy
<X-Rob> jamespage: dosaboy, apparently the hacluster stuff is your baby. https://bugs.launchpad.net/bugs/1409548
<mup> Bug #1409548: Multicast Address isn't randomized <hacluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1409548>
<rick_h_> X-Rob: I know jamespage is in the UK so he's beddy-by atm I'm sure
<rick_h_> X-Rob: an email to the list or the like might be your best bet tbh
<X-Rob> rick_h_: It'll be easier to chat when they're awake
<rick_h_> X-Rob: k, just heads up on delayed response at the moment
<X-Rob> rick_h_: thanks, yeah
<X-Rob> It's one of those 'I don't understand if this is amazingly clever, or fundamentally broken' things
<rick_h_> if james is involved I'd vote clever :)
<X-Rob> The issue is, there's so few bugs about this. I can't understand how it could ever work.
<X-Rob> *Sigh*
<X-Rob> Anyway, I'll eb around for another 8 hours or so, if I'm lucky one of them will emerge 8)
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/ceph-radosgw/embedded-webserver/+merge/246394
<jamespage> just a little one pre-freeze
<jamespage> (thats running in serverstack now)
<jamespage> but I'm guessing that may impact on your HA stuff
<gnuoy> jamespage, does this mean you might be up for reviewing my ceph-radosgw ha branch later today ...
<jamespage> gnuoy, +1 yes
<gnuoy> thanks, just finishing off some test runs
<jamespage> gnuoy, it would be nice to get radosgw into a 'we can support this state' for 15.01
<gnuoy> jamespage, I think ssl will still be absent
<jamespage> gnuoy, I can live with that
<gnuoy> kk
<jamespage> functional + HA is good for me
<gnuoy> jamespage, it doesn't look like there is anything to stop a user enabling the embedded_webserver on an early version of radosgw that doesn't support it
<jamespage> gnuoy, its supported on all supported ceph versions
<gnuoy> tip top
<gnuoy> jamespage, approved
<rick_h_> marcoceppi: how often to charm tests run? we're looking to make sure our new gui release yesterday fixed our issues
<marcoceppi> rick_h_: they run whenever an update is made to a charm for promulgated charms
<marcoceppi> rick_h_: http://juju-ci.vapour.ws:8080/job/charm-bundle-test/
<rick_h_> marcoceppi: ok, yesterday we released trusty-17 for the gui and looking here http://reports.vapour.ws/charm-tests but not seeing it?
<marcoceppi> rick_h_: I can kick off a test if it helps
<rick_h_> marcoceppi: np, I just want to be proactive and make sure we got it and if not we get it fixed asap
<marcoceppi> rick_h_: it might be in a blacklist?
<rick_h_> looks like the Jan 14th build stopped/died
<marcoceppi> not sure, tvansteenburg and the QA team maintain this
<marcoceppi> yeah, exceeded public IP addresses for a cloud
<rick_h_> ok, will be patient or bug others. This helps thanks
<tvansteenburgh> i'm lookinc
<tvansteenburgh> looking
<marcoceppi> tvansteenburgh: can you also kick off a test for gui when you got a min
<tvansteenburgh> marcoceppi: done
<rick_h_> ty guys
<marcoceppi> tvansteenburgh rick_h_: I think I see a problem with the way tests are structured for gui http://juju-ci.vapour.ws:8080/job/charm-bundle-test/10924/console
<marcoceppi> good news, unit tests pass ;)
<rick_h_> marcoceppi: yea, we're sure of that every release but making them pass in your infrastructure is our new goal
<marcoceppi> rick_h_: +1
<rick_h_> ok, so this looks like the other notes in the tooling frankban brought up in that original bug.
<tvansteenburgh> marcoceppi: yeah, fixing that is on my to-do list
<rick_h_> ok, thanks guys. Just wanted to ake sure they ran/etc
<stub> marcoceppi: I've got a replacement Cassadra charm that should be ready for next week. It isn't backwards compatible, so I was going to get it slotted in as trusty/cassandra and leave precise/cassandra the old charm for old Cassandra 1.0.
<marcoceppi> stub: is there no trusty/cassandra yet then?
<stub> marcoceppi: promulgating the precise charm would make speedbumps
<marcoceppi> stub: oh, I see
<stub> marcoceppi: Not that I can see, no.
<marcoceppi> stub: cool, I'll make sure it's not int he review queue
<stub> ta
<marcoceppi> stub: looking forward to seeing the new charm!
<stub> You will be amazed.
<jose> tvansteenburgh: hey, morning! have time for a quick pm?
<tvansteenburgh> jose, yup
<skay> mojo workspace-new is throwing permission denied, though I am not running commands any differently than I have been. and I'm still doing chmod 755 on the container.
<skay> it wasn't throwing it yesterday, and I'm not certain what changed
<skay> resolution -- I didn't realize I had upgraded from 0.1.2 to 0.1.3 yesterday, and there's an issue at the moment that requires a manual workaround to change perms on /var/lib/lxc for mojo
<mwak> o/
<marcoceppi> mwak: \o
 * skay waves
<skay> maybe now that I've been using mojo for a few weeks (monthish) it could be interesting to post to the juju lest and tell people my experiences. but that may be boring. dunno
<skay> s/boring/too obscure
<marcoceppi> skay: not boring
<marcoceppi> please post!
<skay> marcoceppi: I'll try to put together something interesting. I was thinking maybe one of you would want to post about it soon?
<skay> if you think, I'll wait to post until after
<marcoceppi> skay: it's been announced already
<skay> oh! I missed it
<marcoceppi> https://insights.ubuntu.com/2015/01/13/mojo-juju-service-orchestration-distilled/
<skay> marcoceppi: spiffy! I can write something from the point of view of a new user
<jose> marcoceppi: hey, is the queue updating?
<wayneoutthere> uh... this is my first time to use IRC. Do I just type something here and then someone from that long list on the right might have some ideas/answer?
<wayneoutthere> ok anyways, here is my first juju question: i have installed wordpress and owncloud charms.  wordpress displays a kind of virtual IP address in 'juju status' but owncloud does not.  How do I access owncloud via browser?
<skay> wayneoutthere: hi, I don't have an answer to your question. Since you are new to irc, I wanted to mention that if you don't get an answer right away, you can stay in the channel. a lot of times people will be "idling" and not immediately around to answer a question
<skay> wayneoutthere: what happens in that case, is that someone may reply to you and preface the replay with your nick. Most irc clients will give you a notification when that happens, and then you will know someone is talking to you
<wayneoutthere> thanks skay
<skay> wayneoutthere: so I encourage you to stick around
<wayneoutthere> thanks, I will.  I really want to blow this juju thing up
<wayneoutthere> it's great
<wayneoutthere> skay how do I preface it so it beeps on your screen like you just did? Thanks for your help BTW
<skay> I have been using it for about a month now
<skay> wayneoutthere: if you include someone's nick (nickname) in your message, they will usually get a beep
<skay> wayneoutthere: so you may be getting a beep now because I am including your nick in my reply
<wayneoutthere> oh, so I don't need any codes arund name or hash tags? Just type the name? skay skay did you get two beeps ;)
<skay> also, if you want to talk to someone, you can do tab completition. like, type s and k and then tab. it will autocomplete my nick
<wayneoutthere> sweet
<wayneoutthere> skay:
<wayneoutthere> nice.
<skay> wayneoutthere: no, only one. btw, if you are new to irc and open source projects in general, you could join #openhatch.
<wayneoutthere> thanks again for your help. i'm a big helper in the ubuntu vancouver group but never much in the backend like this but getting more and more in here.  thanks skay
<skay> wayneoutthere: that is a friendly group who helps introduce people to the open source community and the technologies people use when participating, like irc
<skay> wayneoutthere: cheers. see ya around
<wayneoutthere> :)
<jose> wayneoutthere: hey
<jose> wayneoutthere: you need for owncloud to turn from pending state to started state, and then everything will be ready for you on juju status
<wayneoutthere> jose: owncloud:     charm: cs:trusty/owncloud-2     exposed: true     life: dying     relations:       db:       - mysql       shared-fs:       - nfs
<jose> wayneoutthere: you have destroyed the service, see life: dying
<wayneoutthere> oh..sorry it's dying
<wayneoutthere> i know
<wayneoutthere> but it was the same except for that. I couldn't reach it while living/started
<wayneoutthere> and that's another issue jose . it should be destroyed by now. why still 'dying'?
<jose> wallyworld: because the relations are still up, you haven't destroyed them
<jose> if you destroy the relations, there will be nothing left since it's dead
<jose> and you can re-deploy them
<jose> juju destroy-relation owncloud mysql; juju destroy-relation owncloud nfs
<jose> also, the owncloud-nfs relation is kinda broken atm, and I'm looking forward to fix it in the near future
<wayneoutthere> jose thanks jose.  i'll try again.  I noticed someting was a bit weird with NFS maybe that is the problem.
<wayneoutthere> can I do it without NFS or is the functionality dependent on it?
<wayneoutthere> jose: it's interesting. I did both a 'destroy service' via GUI as well as juju destroy-service owncloud via CLI and both seem to leave it in 'dying' state....
<wayneoutthere> jose: nevermind. I think maybe I had to destroy the relationships before it would fully die ... let's seee. sorry for my bother by the way and thanks for your help
<jose> wallyworld: sorry, had to step away for a min.
<jose> let me know if you have further probs
<jose> and you *can* do it without nfs
<jose> works fine as a standalone service too
<wayneoutthere> jose:  np.   i cannot seem to get rid of nfs, owncloud, or any of their relationships no matter what I do.  Could you tell me: if this was working correctly, would I see a 'virtual ip' like the other services? Ilike the dns-name
<jose> nope
<jose> yep*
<jose> yes, you would see an IP
<jose> have you tried the commands I gave you?
<wayneoutthere> jose:  weird. i have never seen that.  commands? Maybe I missed that one.  I have done the usual ones... let me oh. now i see the commans. sorry let me try that.
<jose> np
<wayneoutthere> jose: i've done those commands now which I think i have done before. it breaks the relations on one of the units but it doesn't seem to fully clean this out.... very odd.  I'll give it a minmute while it processes that last command set again
<jose> ok!
<wayneoutthere> jose: i get this for mysql and nfs, but I can't seem to actually destroy the services
<wayneoutthere> agent-state-info: 'hook failed: "nfs-relation-broken" for owncloud:shared-fs'
<jose> wayneoutthere: juju resolved nfs/0
<lazyPower> jose: seems like owncloud is in error state on nfs - so he should resolve owncloud.
<jose> ah, yep. wayneoutthere: juju resolved owncloud/0 should do
<wayneoutthere> is that a command to run?
<wayneoutthere> never seen that one
<wayneoutthere> jose: I'll just run it anyways because that's just how I am. never fear the button!  here we go
<marcoceppi> wayneoutthere: yeah, it will tell juju you acknowledge the error and move on to the next event in the juju queue
<jose> yep, without the 'should do'
<wayneoutthere> jose: ok lets see
<wayneoutthere> jose: sorry about that had phone call.  so i do not have owncloud/0
<jose> can you paste your juju status on paste.ubuntu.com and give me the link please?
<wayneoutthere> jose: sure. didn't know that's there was such a paste tool cool. just a sec
<wayneoutthere> jose: cool! Love the paste site: http://paste.ubuntu.com/9751700/
<jose> wayneoutthere: juju resolved mysql/0
<wayneoutthere> jose: you are the fastest in the west ;) i'll try
<wayneoutthere> jose: wow! I think that workd. that stuff seems to be gone now.
<jose> perfect!
<wayneoutthere> now I will try doing it again without the nfs
<jose> now you can just go ahead and do `juju deploy owncloud`
<wayneoutthere> beaut
<wayneoutthere> thanks coach
<jose> do it standalone. no nfs neither mysql
<jose> if you have any questions, here to help
<wayneoutthere> oh! no relations?
<wayneoutthere> jose: cool! Looks like I got my virtual IP!
<wayneoutthere> you da man
<jose> \o/
<jose> once it says open ports: 80 443 then you're ready to go
<wayneoutthere> jose: hey, only thing is that I have to use SSH to SOCKS firefox so probably it will kill this session here in IRC but we'll see
<wayneoutthere> let me say thanks in advance and I'll hang around here and learn and grow too
<jose> cool :)
<wayneoutthere> my goal for this week is to try to make suiteCRM into a charm or something
<wayneoutthere> jose: juju is super awesome. so far in my understanding it's a 'free cpanel' and 'one click app install' system with the ability to scale customized.
<wayneoutthere> is that a good explanation so far?
<jose> could be, it's just that it doesn't actually work with one server, but with one cloud environment
<jose> so it will fire machines each time a service is deployed unless specified
<jose> but the one-click app install is mostly true :)
<wayneoutthere> jose: i'm using it with one server (LXC)
<wayneoutthere> seems to be working...
<jose> oh, ok
<wayneoutthere> but maybe it'snot. Myt port 80 is closed so i need to test in real environment soon.  We're considering hosting small hosting bizz using this as backend (friends family to start)
<wayneoutthere> ok here goes test likley i will fae out here hope to find my way back. thanks jose
<jose> np, hope it works!
<wayneoutthere> rrnwexec is that you pal??? haha
<wayneoutthere> jose: awesome. looks like owncloud is now working.  you are appreciated.
<jose> yay
<wayneoutthere> and looks like i'm still online
<dalek57> In the charmhelpers servicemanager docs, there are a lot of mentions of MySQLRelation(). Where does that come from? Does the mysql charm author implement that, or do I? There's a class in the docs that takes a RelationContext. Is that the same?
<dalek57> jose: ^^
<jose> dalek57: sorry, don't work much with charmhelpers. though marcoceppi could probably give a hand :)
<dalek57> marcoceppi: you around?
<wayneoutthere> jose: now back to my orignal question.  If someone wants to reach my 'owncloud' service and a different person needs to reach my 'wordpress' service, and they are now both running (as you could see in my paste) how do I configiure thaat?  Do I do it with subdomains,e tc?  If i enterr hostIP i think it will default to
<jose> dalek57: probably on a meeting, but he'll surely reply once he's back around
<wayneoutthere> sorry that wsa incomplete
<wayneoutthere> good enough though
<jose> wayneoutthere: unfortunately you wouldn't be able to do that with LXC
<wayneoutthere> oh?
<wayneoutthere> interesting....
<wayneoutthere> so it would only work if someone could VPN in or someting?
<jose> if you're working with the local provider it would be pretty difficult and would require manual intervention
<jose> it can be done, yes, but requires manual intervention
<wayneoutthere> I see. it's not automated which totally defeats the purpose of juju...
<jose> exactly
<wayneoutthere> so we would need to invest in a bunch of proper storage (or rent from provider) and then delply that way in the other nonLXC ways
<jose> yep
<jose> have you tried AWS?
<wayneoutthere> roger. no i have not
<jose> they give you a year completely free
<wayneoutthere> what is it?
<wayneoutthere> aws...
<jose> Amazon Web Services, a cloud provider
<wayneoutthere> oh, well I'm working with that dude up there rrnexec on something local maybe so it might happen
<wayneoutthere> a year free is good
<wayneoutthere> hmm
<wayneoutthere> good to know.
<jose> let me know if you want me to give you a hand setting up aws
<sebas5384> from nothing one of the lxc containers change their IP so now juju is lost
<sebas5384> somebody know how to solve this?
<wayneoutthere> jose: thanks.  so help me understand the very big general picture of juju.  is it designed for a company to instantly launch web services to their own organization?  Like you would set up all the stuff your compayny would need  as charms and then customize it that way  and login to 'environment' would take place via domain?  how does juju help hosting like the way i was expecting it.  It was  a very easy setup.... sorry for the 
<jose> sebas5384: sec, let me grab a doc and answer this other question real quick
<sebas5384> i should have to change lxc containers old ip ?
<sarnold> wayneoutthere: btw, irc has line-length limits, you hit it at "sorry for the"
<sebas5384> jose: sure!  :D
<wayneoutthere> jose:  haha.  that was the end.  I'll try to control myself
<jose> wayneoutthere: yep, I would say that. so Juju would help you save costs since one engineer can manage all services
<jose> and you can use a cloud, which means services are scalable
<jose> sebas5384: http://blog.dasroot.net/reconnecting-juju-connectivity.html may be able to help you
<jose> I believe that in that .jenv file you'll find the IPs of the instances
<sebas5384> jose: but for the lxc instances you say?
<jose> yes
<jose> just change the name values and that stuff
<jose> make sure to check the correct environment.jenv file
<sebas5384> jose: I think we are talking about different things
<sebas5384> https://gist.github.com/anonymous/ef83f4b3d2e26c30ae1b
<jose> read the blog post
<jose> in the environments.jenv file there's the info about each unit
<jose> also, I do not see any discrepancies on that status
<sebas5384> jose: take a look at the list of lxc https://gist.github.com/anonymous/97d4b64e9d963c19c6c3
<jose> have you checked the environments.jenv?
<sebas5384> jose: wow! oO
<sebas5384> i restarted the machine
<jose> ?
<sebas5384> jose: and the ip go back to normal
<jose> there you go, then
<sebas5384> yeah, strange hehe
<sebas5384> but thanks jose!
<sebas5384> jose++
<jose> np
<marcoceppi> dalek57: hey
<marcoceppi> dalek57: so, that's implemented inside of just a charm now, cory_fu was planning on putting it in the contrib/mysql module
<marcoceppi> dalek57: not sure the progress of that, but this is what it looks like
<dalek57> marcoceppi: so I'm doing a custom rails deployment and I want it to connect to kafka, which is written in shell. Does it have a KafkaRelation()?
<dalek57> the charm is written in shell
<marcoceppi> which rails or kafka?
<dalek57> the kafka charm is in shell, and I'm writing a rails charm in python
<sarnold> ..
<cory_fu> dalek57, marcoceppi: The documentation for charmhelpers on pythonhosted.org is a little out of date.  The current CH includes a MysqlRelation implementation in charmhelpers.core.services.helpers
<marcoceppi> dalek57: no, so the kafka charm would do what it needs to, you would write the KafkaRelation in the charm you're creating to process the data from it
<cory_fu> dalek57: http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/core/services/helpers.py#L112
<marcoceppi> cory_fu: thanks
<marcoceppi> dalek57: you'd write the KafkaRelation, much like the MySQL one to define the parameters and keys needed and it woudl be used in your services framework charm
<marcoceppi> dalek57: Kafka doesn't even have to know about it
<cory_fu> marcoceppi: What ever happened to removing the default charm create template and making it prompt (as well as renaming the current "python" template to "python-framework")?
<marcoceppi> cory_fu: next release of charm-tools
<marcoceppi> so, next week?
<cory_fu> Cool
<marcoceppi> I have to sort out some dependency things
<dalek57> cory_fu: thanks for the link
<dalek57> marcoceppi: thanks as well. I'll surely be back with more questions
<dalek57> :)
<cory_fu> dalek57: No problem.  The relation classes are just there to encapsulated the keys that you expect and depend on from a particular relation
<cory_fu> dalek57: I'm happy to answer any questions regarding the framework.  :)
<tvansteenburgh> cory_fu, dalek57: just pushed latest charmhelpers docs to pythonhosted
<cory_fu> tvansteenburgh: Awesome.  Thanks
<dalek57> cory_fu: Is a helper for postgres? I would imagine that it would look pretty similar to the mysql one
<cory_fu> It would look very similar, yes, but I don't think there is one available yet, so you would need to implement it.
<lazyPower> What are the implications of --upload-tools? When you run juju upgrade does it expect you to continue to upload the toolchain for that series?
<lazyPower> s/series/version
<marcoceppi> lazyPower:  I'm going to assume yes, --upload-tools should not really be used
<lazyPower> you *have* to use it on the beta tools because streams cannot find them
<marcoceppi> lazyPower: we have betastreams...
<lazyPower> however - im' wondering why its not default behavior to fall back to --upload-tools vs making me know about it.
<lazyPower> marcoceppi: try bootstrapping a provider with 1.21.beta-r
<lazyPower> *beta-4
<lazyPower> it will fail 100% of the time due to missing tools - i've been passing --upload tools all week, and i'm curious why it doesnt fall back to that
<lazyPower> if there's some kind fo inherent behavior modification to long running environments
<marcoceppi> lazyPower: you have to set the stream to devel
<marcoceppi> there's docs on this somewhere
<lazyPower> i mean its nothing serious - but my lack of knowledge around whats going on other than compiling the stuff and shipping it off to the state server - which is all i know its doing
<marcoceppi> agent-stream: devel
<marcoceppi> it's in the announce email
<lazyPower> I'll ping the list with this question, seems like a good place for it
<marcoceppi> true, but utlimtealy the answer is never use --upload-tools unless you're doing devel
<wayneoutthere> jose: thanks for your answer earlier. had to have a bite to eat.  i'm thinking that there must be a way to use subdomains and domains to direct WAN traffic to specific juju services.... even if it was manual intervention.  My friend could say "I want a wordpress site"
<wayneoutthere> jose: and I could say "ok, give me $10/month and I will install and maintain a word press site for you " and then use juju to deploy it in an instant
<jose> wayneoutthere: you could with apache, yes. but as you said, requires manual intervention and defeats the purpose of juju
<wayneoutthere> so in that case I would be better using a cpanel style traditional system?
<jose> haven't worked with cpanel much?
<wayneoutthere> it's just the interface where customers can manage their own hosting.
<wayneoutthere> email, domains, subdomains, blah blah
<jose> yeah. haven't worked with it much and wouldn't be able to provide insight
<wayneoutthere> no problem.
<wayneoutthere> i think juju has the potential to replace a good part of cpanel somehow
<wayneoutthere> that would be a killer market.
<wayneoutthere> hmm. let me look a bit deerp in the web world
<wayneoutthere> thanks jose
<jose> sure :)
<dalek57> cory_fu: I'm confused about how "start" works in charmtools. In order to start my application, I need a connection to postgres. So I put PostgresRelation() in the "required_data" field, then implement that class. Then I make an action called "handle_pg" and put a reference to it in "data_ready". Do I need to separately define "postgresql-relation-* hooks?
<wayneoutthere> jose: idea;.  is it possible to have a domain (www.example.com) have that point to dns server which points it to MyServer (normal so far) and then somehow tell it to go to the virtual IP like (10.0.3.254) by means of forward slash directory or subdomain?  c
<cory_fu> dalek57: You need to define postgresaql-relation-* hooks (at a minimum -changed) such that it calles manager.manage().  With your PostgresRelation in "required_data", your "handle_pg" action will only be called once the postgres relation is connected and it has sent over the expected keys.  The data for the relation can be gotten either from the PostgresRelation() instance (it's a glorified dict) or via normal hookenv methods
<cory_fu> dalek57: If you use the PostgresRelation() instance, you would access the data as pg_rel_instance[pg_rel_instance.name][0]['key']
<jose> wayneoutthere: nope, it'd make it crash since 10.* are internal addresses
<wayneoutthere> right....
<dalek57> cory_fu: What is the best way to see what keys postgresql is going to send over?
<wayneoutthere> can you install more than one instance of juju on one server? I'm guessing no... like have one in subdom.example.com and another one in subdom2.example.com?
<cory_fu> If you want to use the hookenv methods, keep in mind that other requirements (if you have any) might not be met during the posgres hooks, so you will need to figure out the proper relation ID (which is why the PostgresRelation instance is easier)
<cory_fu> dalek57: It should be documented in the postgres charm.
<jose> wayneoutthere: nope, that's not possible
<cory_fu> In the README, hopefully
<wayneoutthere> jose: thanks
<wayneoutthere> jose: wait... but if i manually change the port of 10.0.3.254 (internal) which is running service (ie. wordpress) to port 82 (for example) instead of default then I should be able to manually direct taraffic to that service... or with the router.. ?
<jose> wayneoutthere: eh, first you'd have to make sure that the LXC address is the one exposed to the world with the public IP
<wayneoutthere> yes, it already is
<wayneoutthere> oh... you mean the internal?
<wayneoutthere> lxc is the 10.0?
<jose> exactly
<wayneoutthere> oh... eeks
<wayneoutthere> thanks
<jose> so you'd need to redirect the public ip to your internal ip
<jose> and then the internal one to the lxc one
<wayneoutthere> rrnwexec: hey coach.  this guy jose has been awesome. thanks for juju irc idea
<rrnwexec> jose IS awesome :)
<rrnwexec> and the juju folks on this channel are the coolest people I know ;)
#juju 2015-01-15
<dalek57> cory_fu: I'm trying to figure out the config templating stuff. I created a jinja2 database.yml template, and passed a bunch of arguments to render_template. Python is complaining that I'm passing in unexpected keyword arguments. The docs say that render_template will merge all of the "required_data contexts" together. I don't know what that means. How do I pass arguments into my template?
<dalek57> I'm reading these docs development: <<: *default database: autoponics_control_panel username: railsdev password: password
<dalek57> nope
<dalek57> these ones http://pythonhosted.org/charmhelpers/examples/services.html?highlight=jinja2
<dalek57> lazyPower: looks like cory_fu isn't here. Can you help me out with the templating stuff?
<lazyPower> dalek57: hang on reading the backscroll
<lazyPower> I'm on my way out for the evening but i can surely give you some pointers
<lazyPower> dalek57: show me some code, i'd like to see the template, the render template code, and the stacktrace you got if you can round all three of those up for me
<dalek57> lazyPower: yep, just a sec
<dalek57> lazyPower: http://pastebin.com/6kTipXDm
<lazyPower> ah
<lazyPower> you ned to pss those values in as a dictionary
<dalek57> do I need to pass them in with a keyword arg?
<lazyPower> not unless you reference them with a keyword
<dalek57> but the dictionary doesn't need to be identified by a keyword arg?
<lazyPower> dalek57: it looks like i'm wrong looking over the SF docs
<lazyPower> I'd need to dive deeper into the code or fish up an example out of our cloudfoundry suite to find one for you
<lazyPower> let me link you to that - but i gotta jet afterwords
<lazyPower> dalek57: i'm not finding a good reference example :( I'm sorry. If you dont figure it out feel free to ping me in the AM
<lazyPower> i'll either tag in cory to come help or find you a definitive example
<lazyPower> Best of luck
<dalek57> lazyPower: no worries! I'll look through some other charms. I'll be around tomorrow. Have a good evening.
<dalek57> are there any people left here that can help me with charmhelpers?
<lazyPower> marcoceppi: so, yeah - overwhelming response in favor of the info you gave me yesterday regarding --upload-tools
<lazyPower> there be dragons there
<marcoceppi> lazyPower :) I only know from experience
<jose> nicopace: hey, no need to open bugs for your mps - they're handled separately
<nicopace> jose: the idea is to start a conversation about the need for that test
<jose> nicopace: not sure it's needed - if it's in the review queue a charmer will take a look and see if it fits, if it doesn't a discussion will be started on the mp
<jose> anyways, subject to different opinions.
<nicopace> jose: so i don't waste time implementing a test that is not required, or to receive feedback from before implementing it.
<nicopace> oh, i'm creating issues for tests that are not implemented
<nicopace> not for the ones that i've already implemented
<jose> oh, ok
<nicopace> i have a question... how can i know who is the mantainer of a certain charm? (e.g. apache2)
<jose> metadata.yaml
<nicopace> thanks!
<jose> np
<nicopace> guys, the "Iterface docs >" hyperlink here doesn't work: http://manage.jujucharms.com/interfaces/http
<nicopace> any idea where to fill that bug?
<marcoceppi> nicopace: not quite sure, that webpage is going away soon to begin with. rick_h_ ^ ?
<rick_h_> marcoceppi: nicopace hmm, that points to https://juju.ubuntu.com/Interfaces/http which doesn't exist
<nicopace> marcoceppi: and which one is going to replace it? it is so simple to search for interfaces and charms that implement them!
<marcoceppi> rick_h_: right
<rick_h_> marcoceppi: so yea that site is going away. I think that should point to https://jujucharms.com/docs/authors-interfaces
<rick_h_> nicopace:
<rick_h_> ^
<nicopace> ok, thanks rick_h_ !
<gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/ceph-radosgw/next-support-ha/+merge/243263 if you get a chance
<jrwren> I ran remove-service, status now says life: dying, and agent-state: started and the agent seems to be hung, doing nothing.
<jrwren> is there a way to kick an agent into action?
<lazyPower> jrwren: any relations to the unit?
<lazyPower> Is the bundle equivalent of exposing a service "expose: true" or "exposed: true"?
<jrwren> lazyPower: yes, relations. I'll remove them, but I have done this 20+ times in teh past week+ and never had this issue.
<lazyPower> jrwren: was just going to say - if any of them are in error state its trapping hook execution on the remove-service
<jrwren> lazyPower: nothing is in error state
<lazyPower> jrwren: use a big hammer
<jrwren> lazyPower: assume this is production adn would cost me $$$ to use a hammer :)
<lazyPower> jrwren: if teh agent state isn't changing - is there any output in debug-log in the last 500 or so lines for the unit?
<jrwren> lazyPower: nothing significant AFAICT.  "got service change", "no new charm event", "go relations change", "got unit change", "unit is dying"
<marcoceppi> jrwren: are you sure a hook isn't currently running on the unit?
<marcoceppi> jrwren: ps -aef | grep hook
<jrwren> marcoceppi: nothing but the grep :)
<marcoceppi> jrwren: what about a grep for juju?
<jrwren> marcoceppi: the machine and unit agents.
<seal> Does juju cache charms even after destroying an environment?
<marcoceppi> seal: yes
<seal> marcoceppi: thank you, where can I remove this. I am trying to figure out why a jenkins git plugin does not install even though I changed the config
<mwak> o/
<mwak> cory_fu: you can download the modified chadoop charm version here https://fr-1.storage.online.net/mwak/hadoop.tar.gz
<blr> charm-helper templating (via charm create -t python) appears to be broken in charm-tools 1.5.0, workaround presumably is to just grab the bzr branch?
<lazyPower> blr: thats charm-tools
<lazyPower> charm create -t that is.
<blr> lazyPower: right, but I gather that should scaffold a charm with charm-helpers, it does not do that
<marcoceppi> lazyPower: i think thry mean the charm-helper charm template
<marcoceppi> blr: I haven't had an issue, what are you seeing?
<blr> marcoceppi: https://bugs.launchpad.net/charm-tools/+bug/1395560
<mup> Bug #1395560: "create -t python " does not install lib/charmhelpers <Juju Charm Tools:New> <https://launchpad.net/bugs/1395560>
<lazyPower> ah
<blr> no hooks.py symlinking, no charm-helpers.yaml
<lazyPower> blr: thats a services framework template, and it pip installs.
<lazyPower> blr: i think what you're looking for is charm create -t python-basic
<blr> lazyPower: ah ok, looks like the docs on http://pythonhosted.org/charmhelpers/getting-started.html potentially need updating?
<lazyPower> can you give that a go and let me know?
<marcoceppi> blr: yes, so we're pushing a 1.6.0 soon which will do a few things: 1) it'll prompt on first run the default type of template you wish to use, 2) it'll rename python to python-services
<blr> sweet, that does what you would expect lazyPower and marcoceppi
<blr> thanks guys
<lazyPower> np blr, sorry for the confusion
<lazyPower> and thanks for the pointer @ the docs. We'll get that shored up shortly
<blr> cheers :)
<lazyPower> https://bugs.launchpad.net/charm-helpers/+bug/1411412
<mup> Bug #1411412: getting-started docs needs updating <Charm Helpers:New> <https://launchpad.net/bugs/1411412>
#juju 2015-01-16
<jobot> Hello, I have tried to create my first charm. The install hook is here: http://paste.ubuntu.com/9759291/ , it fails on line 44 saying that the site does not exist. If you wouldn't mind giving me some guidance on this hook, it would be appreciated
<sarnold> jobot: I -think- you need to change this name: /etc/apache2/sites-available/suitecrm to /etc/apache2/sites-available/suitecrm.conf
<sarnold> jobot: there was a change somewhere along the way that I -think- requires the .conf extension on those files now.
<jobot> Ok. Thank you. I will try that :)
<blr> on utopic, cloud-utils is marked recommends for lxc-templates, which appears to result in failed container creation with the local provider
<blr> potentially I just had my machine in a weird state, but it seems curious.. might try in a clean vm
<Muntaner> good morning
<Muntaner> I'm quite new to Juju and having problems
<Muntaner> can anyone help me? Am I in the right place?
<Odd_Bloke> Muntaner: You are in the right place; ask a question and hopefully somebody will be able to answer it. :)
<Muntaner> ok! I have two laptops connected to the same networks, 192.168.0.194 and 192.168.0.197
<Muntaner> on the second one, I installed devstack to do some tests
<Muntaner> and I'm trieing to deploy services from the first laptop
<Muntaner> with Juju, naturally :)
<Muntaner> I set all the fields with juju-quickstrap
<Muntaner> and I get this error:
<Muntaner> RROR juju.cmd supercommand.go:323 index file has no data for cloud {RegionOne http://192.168.0.197:5000/v2.0} not found
<Muntaner> is the devstack installation "incomplete" or I am doing something wrong on the first laptop?
<Muntaner> it seems like the file "index.json" is missing from the devstack computer... I can read errors like these:
<Muntaner>  DEBUG juju.environs.simplestreams simplestreams.go:419 fetchData failed for "http://192.168.0.197:8080/v1/....../images/streams/v1/index.sjson": failed to GET object images/streams/v1/index.sjson from container con-366ffb69922d4b7892e6bef717239473
<Muntaner> and now I'm quite lost, don't know exactly what o do
<Muntaner> to do *
<dimitern> Muntaner, can you give me a bit more background please
<dimitern> ?
<Muntaner> whatever you need!
<dimitern> Muntaner, how is your deployment structured - 2 machines, each with 2 network interfaces?
<Muntaner> two laptops, connected to the same network with internet access. They have the local IPs I wrote - 192.168.0.194 and 192.168.0.197
<Muntaner> I'm pretty sure they can see each other (from the first one, I'm able to login in the devstack running on the second one via the web browser)
<dimitern> ok, so are these IPs configured via DHCP or statically?
<Muntaner> Probably static - I can't manage the network configuration
<dimitern> Muntaner, also, it will help if you can use paste.ubuntu.com to share some logs to see what errors you're getting
<dimitern> Can you give me a summary of the commands/operations you used?
<Muntaner> here it is: http://paste.ubuntu.com/9760532/
<Muntaner> I used some basic commands... juju init, juju bootstrap, juju quickstart etc.
<dimitern> so you're using juju-quickstart - let me ask some of the folks working on this
<dimitern> rick_h_, hey, can you have a look at that log please ? ^^
<Muntaner> yes, yesterday I arrived to the same error by configuring manually environments.yawl
<dimitern> how did you install juju-quickstart?
<Muntaner>  1217  sudo add-apt-repository ppa:juju/stable
<Muntaner>  1218  sudo apt-get update
<Muntaner>  1219  sudo apt-get install juju-quickstart
<Muntaner> if needed, I can copypaste my environments.yawl aswell
<urulama> dimitern: i'll ping frankban to look at that log, he should be joining soon.
<dimitern> Yes please - you can redact keys/passwords/etc. from it first
<dimitern> thanks urulama!
<Muntaner> here it is my environments.yawl: http://paste.ubuntu.com/9760545/
<Muntaner> control-bucket and admin-secret have been autogenerated by clicking on the option in juju-quickstart
<dimitern> Muntaner, hmm.. ok so I believe the issue is you'll need to run sync-tools first to generate metadata for your private openstack installation
<Muntaner> I'll ask a very silly question now:
<dimitern> Muntaner, I'll give you more info in a sec
<Muntaner> do the laptop with devstack need to install anything about juju?
<Muntaner> because, right now, it has nothing installed - just devstack
<dimitern> Muntaner, assuming you want to use the devstack laptop as "the cloud", no - you install the juju client (quickstart does that for you) and use it to bootstrap an environment on the other laptop
<Muntaner> exactly, that was the test I wanted to do
<Muntaner> just to get involved into the software and try some charms
<dimitern> Muntaner, that's *awesome* - thanks for trying Juju out!
<dimitern> Muntaner, I'm checking a few places first, but I think I can help you with your issue
<Muntaner> Thanks, I already tried it in my laptop only - deploying Wordpress + MySQL has been a piece of cake :)
<dimitern> sweet!
<dimitern> Muntaner, ok, so let's try the easiest thing first
<dimitern> Muntaner, add the following to your environsments.yaml, e.g. just after the line "username:", with the same indentation
<dimitern> Muntaner, agent-metadata-url: https://streams.canonical.com/juju/tools
<dimitern> Muntaner, sorry - for 1.20.x use "tools-metadata-url" instead
<dimitern> or agent-metadata-url
<Muntaner> ok, I try now and give feedback
<dimitern> ..instead *of
<dimitern> Muntaner, then, run $ juju bootstrap --debug 2>&1 > juju-bootstrap.log and paste that please
<Muntaner> seems like nothing changed - juju-bootstrap.log is empty
<Muntaner> I can copypaste whatever is needed
<dimitern> Muntaner, did you see output on the console?
<Muntaner> yes, looks like they are the same errors
<Muntaner> http://paste.ubuntu.com/9760633/
<Muntaner> new environments -> http://paste.ubuntu.com/9760637/
<dimitern> Muntaner, hmm.. that's weird.. I'll have a look at the code to see what's happening
<dimitern> Muntaner, before anything - please try running $ juju-quickstart --upload-tools --debug and paste the log
<Muntaner> yes, just a sec
<dimitern> btw I've reported a bug for your issue against quickstart, so we can think how to improve the experience in cases like yours - https://bugs.launchpad.net/juju-quickstart/+bug/1411574
<mup> Bug #1411574: quickstart should detect private clouds somehow and generate metadata url in the environments.yaml <juju-quickstart:Confirmed> <https://launchpad.net/bugs/1411574>
<dimitern> Muntaner, you might later try following the docs here - https://juju.ubuntu.com/docs/howto-privatecloud.html#deploying-private-clouds
<Muntaner> I'm back now, sorry
<Muntaner> result of juju-quickstart --upload-tools --debug: http://paste.ubuntu.com/9760712/
<dimitern> Muntaner, thanks, it's weird how nothing has changed though.. try $ juju metadata validate-images and then also $ juju metadata validate-tools ?
<Muntaner> so
<Muntaner> juju metadata validate-images: http://paste.ubuntu.com/9760764/
<Muntaner> and juju metadata validate-tools: http://paste.ubuntu.com/9760771/
<Muntaner> shall I try something else, guys?
<dimitern> Muntaner, thanks, will get back to you shortly
<Muntaner> ok!
<dimitern> Muntaner, let's try adding "images-metadata-url: http://cloud-images.ubuntu.com/releases/" to environments.yaml and re-run $ juju metadata validate-images
<Muntaner> at the moment devstack isn't running - I'll try this in minutes
<Muntaner> sorry
<dimitern> ok, no worries
<Muntaner> did we just discover an hidden bug or this may be my bad configuration of the "net" ?
<dimitern> Muntaner, well, for one - it's definitely a bug with quickstart, as the user experience can be improved
<dimitern> Muntaner, but the reason it fails is insufficient configuration, so it's not a juju bug - at least not yet
<Muntaner> aw ok. Now, I'm installing Ubuntu Server on the devstack laptop
<dimitern> Muntaner, what happened with devstack btw? why do you need to do this now?
<Muntaner> dimitern, laptop owner decided to do so, needs Ubuntu server for other stuff. Btw, the previous devstack installation is "safe" on another partition with Linux Mint (the OS with who I was experimenting and encountered the problems)
<dimitern> Muntaner, ok, thanks for the info; I'll need to finish some other stuff now, but please let me know if you still have issues later.
<gnuoy`> jamespage, did you see my request for a review of https://code.launchpad.net/~gnuoy/charms/trusty/ceph-radosgw/next-support-ha/+merge/243263 if you have time?ay ?
<Muntaner> dimitern, I did what you suggested
<Muntaner> I get the same error
<dimitern> Muntaner, what did you do last?
<Muntaner> I'm pasting it for you
<Muntaner> http://paste.ubuntu.com/9761344/
<Muntaner> the environments.yawl is: http://paste.ubuntu.com/9761347/
<dimitern> Muntaner, I think I have a solution - try theses steps: 1) keep tools-metadata-url set as before; 2) run $ juju metadata generate-images -d $HOME/.juju/metadata (paste any errors); 3) run $ juju metadata validate-images -d $HOME/.juju/metadata (should be fine, but again paste any errors); 4) run $ juju bootstrap --debug --metadata-source $HOME/.juju/metadata and paste the output
<dimitern> Muntaner, but first, remove "images-metadata-url" from environments.yaml
<Muntaner> dimitern, error: unrecognized command: metadata generate-images
<dimitern> Muntaner, sorry - generate-image
<Muntaner> ok!
<Muntaner> dimitern, ERROR image id must be specified
<Muntaner> I'll be back in an hour
<Muntaner> boss calling, see you later
<dimitern> ok
<Muntaner> and thanks :)
<dimitern> Muntaner, np - re that error, yes sorry - specifying image id (-i <..>) for generate-image is required. You need to know your devstack available images. Here's an article providing pretty much all you need I think - http://blog.felipe-alfaro.com/2014/04/29/bootstraping-juju-on-top-of-an-openstack-private-cloud/
<Muntaner> dimitern, thanks, I'm following that post
<dimitern> great!
<dimitern> please let me know if you're successful
<Muntaner> dimitern, is it hard to write own charms?
<dimitern> Muntaner, :) depends on what the charm does, but for simple things it's not hard at all
<dimitern> Muntaner, here's the right place to ask just this - any one of the guys like jcastro, lazyPower, mbruzek, from the ecosystem team can help you with that
<lazyPower> o/
 * lazyPower reads scrollback
<jcastro> hi!
<dimitern> :)
<lazyPower> Muntaner: thats subjective :) but if you were to ask me 1:1 i'd say - "Charm development isn't hard - but writing *good* charms requires a fair amount of thought and testing"
<Muntaner> it's fine! was just curious about that ;)
<Muntaner> btw, dimitern
<Muntaner> I'm reading that post, I jumped the whole part inerent to OpenStack Glance
<lazyPower> thats one of the things I love about charm development, its like any other software project. its an iterative process and you can prototype quickly in bash before you commit to a config management framework
<lazyPower> regardless of that being something like chef/puppet or using our own charm helpers libraries to greenfield develop in python.
<dimitern> Muntaner, yeah - that happens to be the most important part :)
<nicopace> Muntaner: two days ago, i implemented a simple charm pretty quickly. You can look at it, it is pretty small in LOCs :) https://code.launchpad.net/~nicopace/+junk/simplewebservercharm
<Muntaner> in your opinion, what is the best language to implement charms? is Java fine?
<mbruzek> Muntaner you could
<mbruzek> Muntaner: but as a Java developer I have tried that and it is not easy.
<jrwren> Muntaner: python
<mbruzek> Muntaner: Technically you could write a charm in anything that runs on Ubuntu
<jrwren> Muntaner: the charm-helpers library makes python for charms the best.
<mbruzek> Muntaner: but setting up the Java environment was a hassle for me, just to write the charm hooks in Java
<jrwren> you'd have to write part of the install hook in some other language to install the JRE.
<mbruzek> but Muntaner it can be done
<lazyPower> Muntaner: the fact is we support close to anything/everything - so long as you can encapsulate the logic in a format that resembles the events we model with the hooks. So as a java developer you can certainly write hooks in java but your pre-install will require you to install a JRE, and any third party deps you require - another option would be to write them in scala which is similar to java, but not quite right?
<jrwren> scala:java::ocaml:C++
<Muntaner> ok, I understand. Thanks for this lot of info
<mbruzek> Muntaner: As a fellow Java Developer, I would be willing to help you with any questions you might have.  Please feel free to IM me on IRC
<Muntaner> mbruzek, thanks a lot :)
<mbruzek> no problem at all
<jose> mbruzek, lazyPower, marcoceppi_, tvansteenburgh1: if any of you guys have a minute to do a review, I've got a critical security fix on the waitlist (queue not updating), mind taking a look? https://code.launchpad.net/~jose/charms/precise/owncloud/fix-poodle/+merge/246208 https://code.launchpad.net/~jose/charms/trusty/owncloud/fix-poodle/+merge/246205
<jshieh> sorry to be off topic, but looking for macfarlan or a. rosales...a good channel to find either of them?
<lazyPower> jshieh: arosales is CO based and should be around within the hour here.
<lazyPower> jose: in standup will sync with you afterwords
<jshieh> okay
<jose> soudns good, thanks lazyPower!
<Muntaner> dimitern, got some news
<dimitern> Muntaner, is it good? :)
<Muntaner> dimitern, no, lol, I got new errors
<Muntaner> dimitern, if you want I can copypaste them for you
<dimitern> Muntaner, yes please
<Muntaner> dimitern, http://paste.ubuntu.com/9762355/
<Muntaner> care, it's quite long
<arosales> jshieh: hello
<arosales> sorry my network was done earlier this morning
<Muntaner> dimitern, I'm going crazy, lol
<dimitern> Muntaner, *much* better!
<dimitern> Muntaner, you've managed to bootstrap almost :)
<Muntaner> dimitern, wow! :D
<Muntaner> dimitern, yep, what remains now?
<dimitern> Muntaner, but the image metadata seems incomplete - try validate-images and also make sure that image id b2731f9e-6971-4c91-bea3-39aa0e23e15b is in it
<dimitern> Muntaner, but first - change tools-metadata-url back and drop --upload-tools from bootstrap
<dimitern> *back to what it used to be (I see it empty)
<dimitern> I have to go unfortunately
<nicopace> Hi guys.. is there any way that a charm is run using python2?
<asanjar> mwak_: hi there, cory_fu said you had some issues with hadoop charm?
<cory_fu> asanjar: mwak_ had to leave for the weekend.  :/
<cory_fu> We'll have to reconvene on Monday
<asanjar> cory_fu: do you have his email?
<cory_fu> No.  :/
<asanjar> okay then, we wait till Monday
<jrwren> nicopace: What do you mean? charm hooks are run as binaries or #! directive. #!/usr/bin/python is python2
<nicopace> yes... when i specify python3 as the hook.py interpreter, it say 'bad interpreter'
<nicopace> i ssh-ed into the unit, and it seems python3 is not installed!
<nicopace> jrwren: ^
<avoine> nicopace: try with #!/usr/bin/env python2
<lazyPower> nicopace: is this a precise host? i tend to use env to route those properly
<avoine> or just #!/usr/bin/env python actually
<lazyPower> also just saw your email to the list about apache2 tests - i haven't dug in, but thanks for taking a look at that :)
<nicopace> oh... if it is precise it uses python2 by default?
<nicopace> lazyPower: :D
<lazyPower> nicopace: python2 is default across precise/trusty
<lazyPower> but trusty has python3 interpreter in the base image i do beleive, if not its a simple apt-get install away
<nicopace> avoine, lazyPower: that actually works, but as i'm using charmhelpers i need python3
<lazyPower> charmhelpers is python2 compliant
<lazyPower> as is amulet
<nicopace> that's strange... i think it is failing because it requires six
<lazyPower> can you hand me a stacktrace of what you're looking at? we've had some issues with test dependencies in the past
<nicopace> sure
<lazyPower> i think tvansteenburgh1 was the one that put a lot of those fixes in place during our last bug-run.
<lazyPower> he's kind of a big deal when it comes to fixing python dependency chains :)
<nicopace> lazyPower: http://paste.ubuntu.com/9763023/
<nicopace> the problem is that charmhelpers is requiring six, and it is not installed
<lazyPower> yep, missing python dependency on the host. Which provider is this?
<nicopace> lxc
<lazyPower> interesting, thats a cloud image.
<lazyPower> if you add python-six to the install routine of the charm does it work as expected?
<lazyPower> as in (apt-get install python-six)
<nicopace> i can't, as i'm using hooks.py
<nicopace> well... i can, but i have to add a middleman
<lazyPower> nicopace: typically when there are pre-deps the install hook becomes a shell script that then calls hooks.py
<captine> eve all.  can someone point me to where i can figure out what is causing the below (first time trying juju and trying to get it to use br0 for local containers to get network ip's..
<captine> ERROR juju.provisioner provisioner_task.go:418 cannot start instance for machine "2": container failed to start
<captine> same error for machine 1
<lazyPower> captine: that can be for a variety of reasons and its not really clear unfortunately
<lazyPower> captine: i'm assuming this is with regard to bridging for reaching into the containers from outside your host right?
<captine> lazyPower, am guessing
<captine> since the last time we were chatting, i havent looked at things until now
<lazyPower> captine: when we last left off, we had just gotten the bridge adapter created and you were working through a bootstrap
<captine> yip
<lazyPower> we need to look @ your template container configs and ensure the networking was applied to those - i'm betting it wasnt and we have a few options
<captine> template container configs?
<lazyPower> you'll need inspect the 'config' file in /var/lib/lxc/juju-$series-lxc-template
<lazyPower> i bet its pointing at lxcbr0
<lazyPower> these template containers get cloned to create the local provider machines
<captine> ok
<captine> let me check it
<lazyPower> the line we are concerned with is: lxc.network.link = lxcbr0
<lazyPower> you'll need to change that to br0 and give it another go
<captine> changed them both
<captine> so now do i destroy the 2 machiens
<captine> and bootstrap again?
<lazyPower> yep
<captine> ok.  crossing fingers
<nicopace> lazyPower: sorry, i had to go out for some minutes
<nicopace> i understand
<nicopace> i'll try that
<nicopace> thanks!
<lazyPower> nicopace: no worries
<captine> lazyPower, assuming this works, is there a way to stop the lxc containers starting automatically?  may want to only start manually>?
<lazyPower> captine: there is but i'm not aware off teh top of my head
<captine> np.  will google
<lazyPower> i'm fairly certain we are generating jobs in /etc/lxc/autostart or something similar to that
<lazyPower> it *should* be as simple as removing those, but i cannot be certain as I have not done so before. Typically when i have containers I want to control i dont create them with juju
<lazyPower> i build them with lxc-create
<stub> nicopace: if you look at charmhelpers/__init__.py you should see some bootstrap code that installs python-six packages. If it is empty, you can fix it by getting that file synced in.
<captine> lazyPower, does it work the same way with lxc-create?
<captine> would i need to do something to get br0 to be used?
<lazyPower> captine: its 100% manual. you get zero magic from juju
<captine> ah
<captine> lazyPower, not sure it is working.  agent state has been "pending" for 10 minutes
<lazyPower> captine: it should be up within 30 seconds depending on disk io
<lazyPower> so, if its still pending we have hit another issue
<captine> maybe i didnt destroy everything correctly.
<lazyPower> what I suggest is actually removing those templates
<lazyPower> destroy-environment, remove the templates
<captine> from /var/lib/lxc/juju
<lazyPower> sudo lxc-destroy --name
<lazyPower> remove any containers that are related to juju, destroy the local environment with -y --force, and then start from step 1, it'll re-download the templates and generate them according to teh config
<captine> lxc-destroy -- is that to remove the templates
<captine> or do i just rm -rf the templates?
<captine> from /var/lib....
<lazyPower> i would use lxc-destroy
<lazyPower> we're basically resetting your local provider environment to square 1
<lazyPower> by removing the templates and containers, we're eliminating any traces of old config
<lazyPower> and letting juju perform the setup according to the files we edited in our prior session
<captine> ok
<captine> done.
<captine> noting in /var/lib/lxc/
<captine> bootstrapping now
<marcoceppi_> lazyPower arosales jcastro: maas just got a little more interesting https://insights.ubuntu.com/2015/01/15/virtualbox-extensions-for-maas/
<lazyPower> nice!
<captine> lazyPower, still not working.  should i remove lxc and juju with apt-get purge?  then start again?
<lazyPower> captine: its hard to say depending on why the containers are failing to start. can you try starting the container manually so we can debug?
<captine> lazyPower, so the container is not up (  "1":
<captine>     instance-id: pending
<captine>     series: trusty
<captine> how do i manually start that (sorry for pasting multiple rows.  didnt think it would do that)
<lazyPower> sudo lxc-start --name $container-name -d
<captine> so would the name be "1"?
<lazyPower> negative, thats in the output from sudo lxc-ls --fancy
<captine> well.  guess what.  my machine must just be slow
<captine> just checked status again, and i see an ip address
<captine> woohooo
<lazyPower> nice :)
<lazyPower> remember on first boot
<lazyPower> its goign to download those templates
<lazyPower> so juju deploy cs:precise/wordpress -- the very first time its pulling down the 200mb cloud image and building that template container
<lazyPower> then ti clones it and kicks off the charm
<captine> lazyPower, thanks a mil.  I am connecting and it is working well
<captine> now the learning starts :)
<lazyPower> awesome
<lazyPower> captine: glad we got you sorted :) make sure you tell your friends about us here in #juju
<arosales> marcoceppi_: thanks for the link talking a look
<captine> lazyPower, just a questions.. maybe a dumb one.  i dont need to ssh to these lxc containers to run apt-get update and apt-get upgrade?  or do I?
<captine> do they update when i run it on the hose?
<captine> host?
<lazyPower> they dont
<captine> ok
<captine> cool.
<lazyPower> think of them as isolated VM's. you'll need to apt-get update/upgrade
<captine> cool. so i can install management software into them etc.  very cool.
<lazyPower> and its typically a good pattern to adopt in your charm to do that during the install hook - but certain members like jrwren have their own opinions about it.
<lazyPower> i reference you not out of finger pointing but knowing that you have good and valid reasons for avoiding that p attern jrwren <3
<jrwren> :)
<captine> well, it will be months/years away from writing charms.  am an accountant by trade, so dont get much time for my tech hobbie :)
<captine> lazyPower, what was ur blog address again for the setup of br0 etc... it didnt seem to save in my fabourites
<lazyPower> captine: blog.dasroot.net
<lazyPower> captine: it would be a good idea to back up those config files we modified in the event you *ever* need to go back through and edit them on another system
<captine> thanks
<jrwren> I just like the speed of skipping the apt-get update upgrade step.
<lazyPower> updates will prompt you that there is a collision and you may have to manually edit them again, but ubuntu is good about not clobbering user updates to config files.
<captine> i best get a local apt-mirror setup to install from
<lazyPower> read up on setting up a squid deb proxy :)
<lazyPower> path of least resistance
<jrwren> I like the speed because EC2 IOOPs are very slow and IOOPS on my slow spinning rust drives are also very slow. I'd likely not care on all SSD.
<captine> lazyPower, whats the best way to backup the files?  just copy to fileserver?  or is there a good tool?
<lazyPower> captine: i myself just keep a git repository of all my config stuff on my NAS
<captine> i need to learn to use git more
<captine> just installed it on a vm at work to try to get our IT department to use it for application rule file (IBM Cognos files)... but am not very good with it
<captine> going to crash. thanks again for all the help
<captine> cheers
<lazyPower> cheers Caguax :)
<lazyPower> er.. yeah
<Caguax> cheers lazyPower
<arosales> marcoceppi_:  lazyPower: mbruzek: jose: niedbalski_: tvansteenburgh1: dpb1:  Got a good question from the openstack folks I wanted to get your opinion on
 * dpb1 listens
 * mbruzek waves
<arosales> apparmour
<arosales> :-)
<arosales> Policy states, "Should make use of AppArmor to increase security."
<arosales> https://jujucharms.com/docs/authors-charm-policy
<arosales> But we don't make any references to how this can be accomplished in the charm, and we unfortunately don't have any good examples.
<arosales> I am a +1 for security, but how do we enforce this or if a user says, "Great how do I do this" what is the answer?
 * arosales ends question
<sarnold> hey arosales :) there's a handful of policies in /etc/apparmor.d/ on most ubuntu systems that can serve as a too-quick introduction to apparmor
<arosales> sarnold: hello :-)
<sarnold> arosales: jdstrand has a series of short-and-sweet blog posts about apparmor that are a decent enough introduction, too, https://penguindroppings.wordpress.com/2014/06/06/application-isolation-with-apparmor-part-iv/
<arosales> Perhaps the right answer here is to reach out to the ubuntu security team and formulate some examples in the docs
<sarnold> arosales: one thing that I'd love to see in juju charms is making use of the relation information to help create flexible policies
<mbruzek> arosales: This policy predates me, but I have not seen a charm using apparmor.  I suspect *someone* knows how to do that
<arosales> sarnold: do you feel this is handled inside the app, or are there extra measure the charm should be taking?
<sarnold> arosales: it depends; e.g., installing mysql from the archive will automatically get the packaged apparmor policies installed
<mbruzek> good point sarnold
<arosales> good point, but others may not .  . .
<sarnold> arosales: but if you're creating a charm for software that doesn't already supply its own policy, you could bundle it alongside the charm, drop it into /etc/apparmor.d/, and .. *waves hands about making sure it's loaded before the service is started*
<sarnold> arosales: one complicating factor is that apparmor policies currently can't be nested; the local provider uses LXC, which uses apparmor to enforce some of its policies. so, local deployed charms wouldn't be able to use their own policy. (this is being addressed but probably won't be ready for many months.)
<sarnold> arosales: jdstrand and sbeattie also put together an apparmor "policy template" language, apparmor-easyprof, that _might_ be a suitable starting place for charm authors to smack out some quick template-based policies -- which might be useful for tuning them based on configurations
<arosales> interesting re lxc, didn't think of that
<sarnold> I think the mysql init stuff may have mechanisms in place to cope, I haven't looked in ages.
<arosales> sarnold: do you have a link to the "policy template" lauguage?
<arosales> sarnold: do you know of any issues with xen or kvm in app armour policies?
<sarnold> arosales: hrm, I'm having trouble finding links to apparmor-easyprof examples; it's used a bit with snap / click packaging but those tools aren't exactly easy to learn from
<lazyPower> arosales: i agree that we need to get documentation around this or link to the proper docs in our charming series docs
<sarnold> arosales: xen / kvm should work just fine; libvirtd does have apparmor policies confining portions of the systems (e.g. shared host/guest filesystems sometimes have trouble, and need extended policies) -- but the kvm-emulated machine or xen-emulated machine get their own apparmor policies no trouble
<jhobbs> fyi i filed a bug on it here https://github.com/juju/docs/issues/229
<lazyPower> arosales: what may be a good starting poitn would be to get a charm school video about security enhnacement with apparmor profiles on a simple charm - like pick the day1 charm and put in some nginx app armor policies
<lazyPower> however app armor itself is a beast of a topic and goes into a broad range of things as sarnold has pointed out
<lazyPower> and o/ sarnold :)
<arosales> jhobbs: thanks
<sarnold> hey lazyPower :)
<sarnold> I've got to head off for lunch, but I'll be back ~hour :)
<arosales> lazyPower: ya I think at a min we need some docs to point users on how to accomplish this
<arosales> sarnold: if you come across those links please send them onto us :-)
<lazyPower> arosales:  i have a marching order over this next week to get some visualizations done for my slides / video over charm relationships - i can add an addendum to that for app armor as a follow up task.
<arosales> sarnold: thanks for the input here, much appreciated
<sarnold> the policies are easy enough; the hard part is tying them together to handle e.g. running under lxc, getting them loaded before programs start, etc..
<lazyPower> i've ran into some really good articles that we - being juju charmers, are not warehousing, but i can distill that info into a digestible doc for starting out with app armor and link to the app armor community documentation which goes into further depth how to write them
<arosales> lazyPower: if you have some time to start some docs on apparmor that wold be helpful
<lazyPower> yeah, i'll try tos queeze it in :)
<lazyPower> maybe as a slack task
<arosales> lazyPower: sounds good
<jose> arosales: so as it's a should and not a must hasn't probably been looked at much. the policies are installed with packages on the archive, but I guess this is more directed to packages which are installed from an external sourcec
<jose> arosales: agree with contacting the security team, if we can get examples it would make it easier for all authors to understand what is and how it works - without reference in our own docs it's tedious work to understand it
<lazyPower> arosales: and if we can get the security team to contribute those docs - would probably be better than me putting down the crumbs of info i have picked up from blog posts over the last 3 years.
<lazyPower> sooooooo... theres *that* little tidbit of info
<arosales> jose: ya some folks read that should in policy and want to follow it but don't know how, and we don't give docs on how to do so unfortunately
<arosales> perhaps some "shoulds" in the policy should be best practice
<arosales> policy is usually a little more black and white and not gray. These are valid points the openstack folks like jhobbs are pointing out
<lazyPower> i agree with that statement, a should sounds like it can or cannot
<lazyPower> policy should be true/false
<jose> I believe this specific one would apply to charms that gather things from outside
<arosales> jose: lazyPower: but regardless of where it lives we should reach out to the security team and get some good docs around app armor
<jose> +1 on that
<arosales> jose: lazyPower: also how do you guys evaluate a charm "following the spirit of Ubuntu?"
<arosales> another policy item that is kind of vague, but a good one
<jose> arosales: http://en.wikipedia.org/wiki/Ubuntu_%28philosophy%29 and CoC
 * arosales has read that :-)
<lazyPower> arosales: http://www.ubuntu.com/about/about-ubuntu/our-philosophy
<arosales> just wants to know how you guys evaluate that against a charm
<lazyPower> but to be honest
<arosales> jose: lazyPower: we allow for a charm to deploy propritary bits so does that go against the philosophy?
<lazyPower> i am probably the most lienient about that line in policy
<lazyPower> as i haven't nacked anything for not being in the spirit of ubuntu
<arosales> well my point is "spirt of ubuntu" could mean a lot of different things
<jose> arosales: I wouldn't say so. It is giving you the opportunity to deploy software easily, which is the purpose of a charm
<arosales> how does one consistantly review a charm against that policy statement
<lazyPower> arosales: well, if it follows the PCBSD spirit, its clearly not in the ubuntu spirit
 * lazyPower rimshots
<arosales> don't get me wrong I like following the spirit of ubuntu big +1 there
<mbruzek> arosales: I read that as a reason to nack a charm if it is doing something illegal or wrong.
<jose> but the policy is unclear
<lazyPower> arosales: so, what if the charm were to deploy say - a fully pre-loaded XXX photo distribution hub
<arosales> my question is how do multiple different reviewers consitantly grade a charm against this line in a similiar manner?
<lazyPower> i think thats where the follows the "ubuntu philosophy' comes into play
<jose> I would do the same as Matt over there
<arosales> shouldn't we say that then?
<lazyPower> probably
<jose> we need to make it more clear, define it
<lazyPower> explicit seems to work better than implicit, there's less room for interp.
<jose> I believe we can change that to follows the CoC - not doing anything that could lead to illegal actions
<arosales> a good question for your charmers is should policy be explicitly true or false, or maybe
<arosales> like read this for policy
<arosales> "A charm should follow the ubuntu spirit"
<arosales> or
<arosales> A Charm must not contain or deploy any illegal software"
<arosales> the latter I can clearly check off
<jhobbs> in what jurisdiction? :)
<arosales> the former is open to my interpretation
<arosales> jhobbs: US where the charm store resides
<jhobbs> cool
<arosales> but valid point
<mbruzek> arosales: The problem with that is it may not contain any illegal software, but what if it contains software that allows someone to *DO* something illegal.
<lazyPower> mbruzek: thats dangerous - thats like shooting teh protocol of bit torrent because you *can* send illegal content over it
<mbruzek> arosales: You could write rules like that all day and someone will find a way around the wording
<arosales> mbruzek: well now you just took it tooo far :-)
<arosales> do we sell knives still ?
<mbruzek> guns don't kill people, people kill people
<arosales> mbruzek: lazyPower: jose: pehaps something to discus in your charmers meeting and send to the list
<arosales> my suggestion would be for a policy review and to make a decision on clear true/false or explictly leave items ambiguous for the charm author to decide.
<mbruzek> arosales: My only problem with your "illegal" wording is that software may be "legal" but we might still might not want it in the charm store.  And there could be different reasons for "illegal software", what if I someone didn't have the legal authority to include the software in a charm.
<mbruzek> ?
<mbruzek> arosales: If they are all yes or no questions, what do you need us for?
<arosales> someone has to check those yes/no
 * mbruzek welcomes our new robot ~charmer overlords
<lazyPower> mbruzek: we are the charminators of policy - we stamp out immutable config
<jhobbs> i have more questions on the policy
<jhobbs> "Must also be valid for the charm and/or bundle format defined in Juju's documentation" - what does this mean?
<arosales> mbruzek: be interesting to hear what your use case is for "legal" software that we don't want in the charm store
<lazyPower> jhobbs: we should really encapsulate these issues in a mail and hit the list with them so the community has an opportunity  to pipe in with these
<jhobbs> is that just "you can't upload arbitrary non charm stuff to the store"
<lazyPower> i added an addendum to our charmer meeting next week for our pre-discussion about it - but i imagine this will be a long running thread on the list for anyone that wants to participate in policy dicussion
<jhobbs> lazyPower: i can do that - what list should i send them to?
<lazyPower> jhobbs: the general user mailing list - juju@lists.ubuntu.com
<jhobbs> lazyPower: ok
<lazyPower> thanks for bringing up these points though and capturing them :)
<lazyPower> appreciate it jhobbs, arosales
<mbruzek> jhobbs: I believe that means it must be in a charm or bundle format so it works with Juju.
<arosales> jhobbs: to answer your question though, yes the charm or bundle needs to be in a valid form (directory) in order for it to be recognized by the charm store
<arosales> jhobbs: appreciate the feedback
<jhobbs> np, thanks for the detailed responses
<mbruzek> arosales: I don't have a good example, but illegal software draws a strange / arbitrary line in the sand.  Someone will work around, or cross the line at some point.
<arosales> mbruzek: fair point
<arosales> mbruzek: for that point we should be careful with the wording
<mbruzek> arosales: Yeah like "ubuntu philosophy" and not being against it
<jhobbs> i think the guidance should focus on good people who are trying to do the right thing. like you say, bad people will always try to work around. there should be some net rule for that like "we reserve the right to reject any charm store submission if we feel it is bad."
<mbruzek> jhobbs: good point
<jcastro> ubuntu philosophy is things like the "don't be a jerk" rule for charms IMO.
<mbruzek> jcastro: Can you give an example?
<jcastro> My charm deletes user data without asking
<jcastro> or ... says it does something but really does something else
<jose> same I understand
<jcastro> or sends your data to a third party without your knowledge, etc. etc.
<jose> basically, follow CoC when writing your charms
<jcastro> basically, it's a catchall "don't be a jerk" so that our policy on what is acceptable and not acceptable isn't a huge book
<mbruzek> jcastro like to amazon?
<jcastro> well this is cloud software so like, everything talks to other services
<lazyPower> i seem to remember having this conversation with marco before, and that was his reasoning for the vague terminology
<mbruzek> jcastro: https://www.youtube.com/watch?v=DXnfa0H30L4
<jcastro> but like, if I install a "bruzek" charm and it phones home to the author so he can spam me, that sucks
<seal> is there an easy way to check machine creation status? something similar to juju pprint?
<jcastro> mbruzek, his opinions are based on an incorrect assumption, the dash is an online search engine, it's supposed to do that, and it says it does that clearly and it's easy to turn off
<mbruzek> seal talk with katco in #juju-dev she did some work on the juju status
<seal> mbruzek: thanks
<mbruzek> jcastro: I know
<dalek57> I'm trying to build a rails deployment with juju, and when trying to start the server I keep getting "no pg_hba.conf entry for host". But looking at the postgres instance, there is an entry in pg_hba.conf that contains all the correct fields. I tried exposing the postgres instance, and no luck. When I run "psql" from a shell on the rails server with all the stuff from my config, I can get to the database. There is only 1 pg_hba.conf on the postgres instance.
<jcastro> but if a charm is named "aws-analytics" or something and does report data to AWS for the purpose of analytics, then yeah, I'd expect that
<jcastro> if the fields are correct then the rails instance would have had a working connection to the db already right?
<dalek57> jcastro: yeah, which is why I'm so baffled. The database.yml looks good to me. When I copy out all the fields and use them as arguments to psql, I get the connection
<jcastro> hmph
<tvansteenburgh1> cory_fu, kwmonroe: wildfly charms promulgated
<cory_fu> Thank you
<cory_fu> You're the best
<cory_fu> Does anyone know how the tomcat charm is intended to be used?  https://manage.jujucharms.com/charms/trusty/tomcat
<cory_fu> Specifically, how does one give a site (war, etc) to it to serve?
<jose> cory_fu: it should, web, if it's opening port 80
<cory_fu> No, I mean that it doesn't support any clearly defined way to get a WAR into it (particularly from another charm) to get tomcat to serve it.
<cory_fu> I was wondering if I'm missing something
<cory_fu> mbruzek: I just noticed you're the maintainer.  ^^
<mbruzek> cory_fu: Yes I am
<cory_fu> Can you answer that question?
<mbruzek> cory_fu: I wrote openmrs charm too
<mbruzek> cory_fu: subordinate charm.  Check my openmrs
<kwmonroe> mbruzek: over the implicit juju-info interface?
<cory_fu> mbruzek: We're reviewing http://bazaar.launchpad.net/~miqe/charms/trusty/openbook/trunk/view/head:/README.md
<mbruzek> kwmonroe: cory_fu: correct juju-info interface
<mbruzek> cory_fu: kwmonroe: I am busy right now, but I can take a look later
<cory_fu> So juju-info is the *recommended* way to do that?  Me no likey
<mbruzek> cory_fu: the interface was named "tomcat-war"  but it is simply juju-info relation
<asanjar> mbruzek: it was mutable config issue
<asanjar> :)
<mbruzek> asanjar: The root of all EVIL
<asanjar> mbruzek: lol
<dalek57> cory_fu: what is the best way to get the host address with charm helpers? It looks like there's some promising stuff in charmhelpers.core.host; do those come with deterministic ordering?
<lazyPower> cory_fu: if you're co-locating with a subordinate, and provide an implicit interface to exchange the data for the WAR to the parent service - i think thats a more acceptable pattern
<lazyPower> but i'm also just starting to explore this territory and the pattern might turn out to be complete tripe
#juju 2015-01-17
<charlie___> hey guys, I am working with mmcc in #ubuntu-solutions, I need to add utopic images to maas. Can someone point me in the right direction?
<sarnold> charlie___: I think this is it: http://maas.ubuntu.com/docs1.5/install.html#import-the-boot-images
<charlie___> I have a utopic maas and am trying to get utopic images
<charlie___> right now all I have are trusty images
<lazyPower> there's a file to edit to get the utopic images charlie___
<lazyPower> its in /etc/maas/, and i dont recall the rest of it from there unfortunately. I'm not within ssh range of my maas server :(
<blr> when testing a charm deployment, is there a faster method of redeploying other than destroying and re-bootstrapping the local environment?
<lazyPower> blr: juju destroy-machine --force, juju upgrade-charm, juju add-unit
<lazyPower> it may yield odd behavior now and again but it works for rapid prototyping 90% of the time
<blr> lazyPower: excellent, thank you!
<lazyPower> blr: np - just understand what its doing - you're removing the existing unit so you dont eat resources, upgrade sends the new charm code to the state-server on basically a non-existant service, then adding a unit deploys the new charm code, its pretty much a hack
<lazyPower> which explains the weird behavior now and again :)
<blr> hah ok, I'll try not to panic if it misbehaves :)
<jobot> Hi, I have an issue with my charm (suitecrm). It deploys ok, but once I deploy mysql, suitecrm is no longer accessible via the webbrowser. i.e I can't complete the full install. Install hook: http://paste.ubuntu.com/9765951/ , debug-log: http://paste.ubuntu.com/9768861/
<jobot> I did ssh to suitecrm and changed the permissions all to 777, and it was still inacessible. Only after completely destroying the services and re-deploying (without mysql) am I able to go through the installer again (of course unable to pass the database part).
<jobot> gotta go afk, but thanks in advance for any help.
#juju 2015-01-18
<jobot> Oh as per previous question, I solved the issue partially. Due to a malformed config.php file generated by the relation to mysql. Thanks.
<lazyPower> jobot: i showed up a bit late to help - but glad you got it sorted
<lazyPower> if you need anything i'll be around for another hour or so
<alexis7> hello everyone
<alexis7> somebody to know speak spanish
<jose> alexis7: yes?
<jose> alexis7: do not PM me.
<jose> read the docs. jujucharms.com/docs
<alexis7> i few words
<alexis7> in few words
<alexis7> do you speak spanish
<jose> read the docs.
<jose> I do, but can not help you if you don't read them.
<jose> or use Google Translate. they are not available in other languages at the moment.
#juju 2016-01-18
<jamespage> gnuoy, do you have a few minutes for https://code.launchpad.net/~james-page/charm-helpers/optimize-dkms-headers/+merge/282927 ?
<jamespage> gnuoy, will help towards https://git.launchpad.net/~james-page/charms/+source/openstack-on-lxd-bundle/tree/
<gnuoy> looking
<jamespage> gnuoy, btw I have an entire openstack cloud running on my laptop under LXD
<jamespage> including overlay networks, multiple nics and nested KVM...
<gnuoy> inc the gateway ?
<jamespage> yikes!
<gnuoy> fmd
<gnuoy> that's fantastic
<jamespage> yeah I said something similar
<jamespage> gnuoy, a few oddities - I'm using the ZFS backend for LXD - but ceph no like that with direct io enabled
<gnuoy> the two wise Chris' will have that fixed in two shakes of a lambs tail I'm sure
<jamespage> gnuoy, yeah
<jamespage> gnuoy, anyways...
<gnuoy> approved
<jamespage> gnuoy, awesome
<jamespage> gnuoy, how are we looking for end-of-the-month?
<gnuoy> jamespage, early to say. We are feature frozen and tracking here: https://docs.google.com/spreadsheets/d/1K1iR2-HlVEePsG_wOo6_zlL0d4ZDiBh3VaiLsb7qbXc/edit
<frobware> jamespage, is is possible to poke around the dellstack setup? I wanted to understand the dns-namserver snafu we saw in /etc/network/interfaces. We ran into this again last week but on on 1.25 which has since been fixed but I cannot repro this on my local setup.
<jamespage> frobware, possibly but thedac did tear everything down
<jamespage> frobware, the only diff we could see what that I built ontop of 14.04 and he was building in 15.10 - which would mean different go versions....
<frobware> jamespage, difficult to understand why go would make the difference unless a later go (15.10) uses its own resolver library/implementation...
<jamespage> frobware, any compiler version conditional logic in the codebase?
<frobware> jamespage, not sure. but, if this happens with a maas node deploy that takes go/juju out of the equation. curtin/maas version combo?
<frobware> jamespage, but I will try a maas 1.9.0 install on 15.10 out of completeness.
<jamespage> frobware, well that could be quite possible
<jamespage> frobware, oh the MAAS install was on 14.04 always
<jamespage> just the juju build was different
<frobware> jamespage, oh. ok.
<frobware> jamespage, that's still worth trying anyway. a little quicker for me than maas on 15.10
<frobware> jamespage, do you know if the bootstrap node was trusty or wily?
<jamespage> frobware, trusty
<frobware> jamespage, thx
<bdx> mbruzek, lazyPower: I want to run something by you concerning layer-tls ..... After giving a lot of thought to layer-tls, I feel like I might of initially taken the wrong impression about how it could be used and implemented ...
<bdx> mbruzek, lazyPower: initially when looking over k8s.py I was strucken with the idea to use layer-tls as a supporting layer to web applications to help generate crts and keys, and get them in the right places
<bdx> mbruzek, lazyPower: I am now feeling like layer-tls would/could be better/more efficiently used if it was deployed as a standalone charm, and other services/charms that need certs could relate to it and get their cert/keys generated and passed to them via unitdata
<bdx> mbruzek, lazyPower: I feel like the latter is how you were intending it to be used ... what are your thoughts on this?
<mbruzek> bdx: That is an interesting idea that I had not thought of.  The current layer-tls charm does not pass around the private keys, so I like that part.  If you had a separate charm the keys would be have to be passed back to the units and in theory could be intercepted
<mbruzek> bdx: We have 2 charms consuming the tls layer and that seems to work, but if it does not work for your case we can iterate on the design.
<bdx> mkruzek, no, it works, I just feel like having a centralized ca that issued the certs out to requesters would be far more lightweight and more easily consumable. Is this not what you were going for?
<bdx> mbruzek: other critical data is passed via relation ...
<lazypower> bdx That makes sense in a lot of ways
<lazypower> bdx And I had considered that, pairing this down and co-locating the CA's with the model controllers
<lazypower> bdx using relations to the CA pki on the mc, you could then relate all over your model, and get self signed certificates supporting whatever endpoints react to the interface tls.available, i think it warrants some later investigation
<lazypower> bdx as it stands, we only have a single relation, which is the peering relationship to exchange the csr/keys. It would be cool to see that logic teased apart into a provides/requires role and then refactor peering to use the common code (lib?)
<bdx> lazyPower: my thoughts exactly .... I cant help but think that it would be overkill to include/install that layer on every openstack service, or every webapp .... just seems like a centralized ca would really sweeten the deal here
<lazypower> bdx: we <3 contributions - you can start with just the tls layer and the tls interface - all the breadcrumbs you really need are right there
<lazypower> bdx: bonus points if you bundle up some examples once you have the CA working as a stand alone service
<lazypower> we're about to move into the next focus area of log infrastructure and backups
<bdx> lazyPower, mbruzek: I am currently trying to redesign our webapp deployment process to be juju deployed, we have a bunch of django/rails webapps with nginx front ends that all need certs and keys, the tls-layer will be a crucial part of this, so I think I can justify the time
<bdx> lazyPower: ^^Nice, thats definitely needed
<bdx> lazyPower, mbruzek: thanks for your insight on this
<lazypower> bdx anytime :) we'll happily lend a hand where we can and do some CR along the way
<asanjar> kwmonroe: happy new year
<asanjar> lazypower: you too :)
<lazypower> asanjar \o/
<lazypower> happy new year asanjar
<asanjar> not to immutable mbruzek
<lazypower> he's gone to immutable lunch
<asanjar> then immutable bathroom run
<lazypower> oi
<asanjar> lazypower: I will send you a meeting invite for sometimes next week, I like to discuss the work you have done with Juju and Docker
<lazypower> asanjar thats crunch week for me, final prep for belgium
<lazypower> but i can squeeze in 30 minutes or so on tuesday
<asanjar> lazypower: then I'll see after Belgium
<lazypower> ok, whats the focus area?
<lazypower> launching big data containers?
<asanjar> lazypower: yeap.. trying to convenience bigtop community to use Juju instead of vagrant and puppet to manage their docker containers
<lazypower> asanjar - If their containers are already baked, and you have say a docker-compose file - send me that and i'll send you a charm to deploy their stack
<asanjar> lazypower: will do,
 * aisrael waves to asanjar 
<mbruzek> Hey asanjar I just got back from lunch.  How are you doing?
<asanjar> hi aisrael Happy New Year, how are you my friend
<asanjar> mbruzek: miss me :)
<aisrael> asanjar: Very good, thanks, and you?
<bdx> mbruzek, lazyPower: am I on the right track here -> https://github.com/jamesbeedy/interface-tls/blob/add_provides/provides.py ?
<mbruzek> bdx looking
<mbruzek> bdx: It looks like a great start!  I like this approach too.
<mbruzek> bdx: I think you might have the term "service" overloaded here.  "We expect multiple, separate services to be related.
<mbruzek> No two services should share the same key, cert."
<mbruzek> Unless I don't understand what you meant, this would be units.  $ juju deploy -n 3 mysql
<bdx> mbruzek: exactly, and we would want all 3 units to have the same client key right?
<mbruzek> mysql/0, mysql/1, mysql/2  <- Those are units, "mysql" is the service
<bdx> mbruzek, exactly
<mbruzek> bdx: Yes the units _could_ have the same client credentials, but what if each unit needs their own cert, key
<bdx> mbruzek: yea, I've been going back and fourth examining use cases ...
<mbruzek> service = hookenv.remote_service() ...
<mbruzek> key = '{0}_signed_certificate'.format(service)
<mbruzek> This would give you one signed certificate per _service_ I think you want one per _unit_
<bdx> mbruzek: take for instance, 3 nginx frontends behind an haproxy, if nginx[0] dies, we don't want to have to re-add the cert to our cache to be able to access the site again
<mbruzek> bdx: That is true, but in the Kubernetes case each unit has its own api server that needs a key and cert.  I *think* they have to (should) b different certs and keys than the other servers
<mbruzek> haproxy is a special case, in that case would haproxy request the cert/key ?
<bdx> in the context of per unit key,cert pairs nginx[1] would need to prompt users to re-auth against the different cert,key pair
<bdx> ok
<bdx> mbruzek: I'm not sure, a use case I was just looking at involves all web front ends having the same client key,certs
<bdx> behind haproxy
<bdx> I'm sure there are other ways
<mbruzek> bdx: In that scenario I would have haproxy request the key/cert. In the swarm case different cert/keys are generated for each unit.
<bdx> mbruzek: entirely
<bdx> mbruzek: ok, I'll revise my work per ^
<bdx> mbruzek: this will highly impact how tls is implemented/used by the openstack service charms
<mbruzek> I am happy to iterate on this.  We could build the meaty methods that do the generation and discuss use cases for certs and keys later?
<mbruzek> bdx: Yes if we get a good solution everyone will want to use it.
<bdx> mbruzek: totally, but in the instance of HA openstack service endpoints and proxying to them
<bdx> mbruzek: oooh, nm, it looks like individual (key,cert) is generated per unit for the same service if using ssl
<bdx> currently
<lazypower> bdx what about 2 interfaces
<lazypower> bdx one that distributes "shared cert/key" and one that does per-unit cert/key?
<bdx> lazyPower: great idea
<bdx> lazyPower, mbruzek: I feel it would mimic what the current layer-tls does with 'tls.server.certificate', to 'tls.client.certificate', and 'tls.client.key' ...?
<bdx> errr current interface
<lazypower> Yep, same events signal'd the difference is what keypair its generating/syndicating
<bdx> lazyPower: entirely
<bdx> lazyPower, mbruzek: this would then allow layer-tls to be extended to set the client.{cert,key} in unitdata, and other relating charms to be able to get it
<mbruzek> bdx that sounds awesome
<bdx> totally, props to lazyPower for the needed bump in the right direction!
<lazypower> I'm just operating the rudder :)
<bdx> Yes.... a lazy, yet powerful position. very fitting
<bdx> lazyPower, mbruzek: its rough, but getting close I think
<bdx> lazyPower, mbruzek: here is interface-tls-gen -> https://github.com/jamesbeedy/interface-tls-gen/blob/master/provides.py
<bdx> lazyPower, mbruzek: and here is how I am looking at integrating it into layer-tls -> https://github.com/jamesbeedy/layer-tls/blob/add_tls_gen/reactive/tls.py#L224-L266
<lazypower> I'm not sure the duplication of this method body is required
 * lazypower will need to look closer later
<bdx> oh.... so thats what I had a question about ....
<bdx> I'm not sure I need to wrap the create_certificates in the  @when('tls-gen.key.cert.requested')
<bdx> ok, thanks
<lazypower> bdx it may be required i'm not super focused on the review
 * lazypower will look in the am
<lazypower> i'm currently teasing apart some interface code from the ETCD charm, and refactoring
<bdx> np, thanks
#juju 2016-01-19
<stub> tvansteenburgh: I got another lxc failure from CI, same as last time - ERROR there was an issue examining the environment: cannot use 37017 as state port, already in use
<stub> (there had been successful runs in the interim, so it seemed to survive ok for a few days).
<vahid> Hi. We have a juju environment (manual provisioning version 1.20.4) with over 140 machines and several services on each one.
<vahid> We are using this for over 9 month and now it's getting completely unstable.
<vahid> Problem started after I remove a subordinate service and juju-agents crashed on over a thirds of machines (about 43 of them) and they didn't remove and keep reporting error:
<vahid> "ERROR juju.worker.uniter.filter filter.go:116 tomb: dying"
<vahid> "panic: runtime error: invalid memory address or nil pointer dereference"
<vahid> After few days juju agent on machine-0 became completely unstable and it goes down after few minutes, so we couldn't even get status of the system.
<vahid> We decided to upgrade juju so we blocked all machines api request to machine-0 with iptables to make stable and then run upgrade-juju command.
<vahid> But after that we encounter another bug (again!):
<vahid> "some agents have not upgraded to the current environment version 1.20.14: machine-803"
<vahid> machine-803 have had a problem while adding and its agent state froze on pending. I tried to force remove this machine but the machine is still there
<vahid> Any body knows what we can do in this situation?
<vahid> Somehow we managed to run upgrade-juju with "1.22.8", command successfully finiched but we lost juju agent on machine-0!
<vahid> Now we receive this error on machine-0:
<vahid> exited "state": cannot log in to juju database as "machine-0": unauthorized mongo access: auth fails
<icey> did juju deployer change to require sending deployment name (machines, relations, series, services) recently? Is there a way to deploy the bundle.yaml as specified otherwise?
<icey> that moment when google can find a charm in the charm store but the search on the charmstore does not
<icey> :-/
<xnox> hello, I am using local provider, and then I did $ juju ssh 0
<xnox> however i'm getting permission denied (publickey,password)
<xnox> was i meant to setup an ssh key somewhere before hand?
<xnox> are xenial charms published yet?
<xnox> is juju ssh 0 supposed to work with juju local on wily?
<asanjar> kwmonroe: hey
<mbruzek> asanjar: You are back!
<kwmonroe> hey asanjar!
<jose> oh, hi asanjar!
<lazypower> vahid thats troubling!
<lazypower> vahid have you filed a bug report with what you've described above?
<icey> so, juju won't let me provision on d2 instance types, says invalid type and gives me a list of valid values
<lazypower> icey using the alpha?
<icey> lazypower: 1.25.0-elcapitan-amd64
<lazypower> icey https://bugs.launchpad.net/juju-core/+filebug
<icey> lazypower: https://bugs.launchpad.net/juju-core/+bug/1535838
<mup> Bug #1535838: Juju won't let me use some instance types on AWS <juju-core:New> <https://launchpad.net/bugs/1535838>
<lazypower> thanks icey
<lazypower> icey can you add juju version to the bug?
<lazypower> i think there's work thats been done / is being done - to remove this static map and update with streams or something
<icey> sure thing
#juju 2016-01-20
<lazypower> blahdeblah o/ hey there
<blahdeblah> \o lazypower
<lazypower> blahdeblah I understand you had some questions about how to get the public-address off every unit related to a subordinate service
<blahdeblah> :-)
<lazypower> Can you re-state the question and I'll do my best to answer it for you
 * blahdeblah goes to cut & paste them
<blahdeblah>  I have a subordinate charm which needs to know the public-address of every primary charm with which it and its peers are related during the update-status hook. i.e. Every subordinate needs to have a full list of the primaries.
<blahdeblah> What is the right way to achieve this?
<blahdeblah> Do I need to gather the public-address from the related primary on each subordinate (during the relation-joined hook), then send that data across the peer relation and store it for use during the update-status hook?
<blahdeblah> This feels like a really good way to get inconsistent data on each subordinate, but I couldn't think of another way to do it.
<blahdeblah> Hope that makes sense
<lazypower> I think you can break this apart into 2 phases if you think about the communication that needs to happen
<lazypower> 1) all units tha thave this subordinate need the primary address, so thats inherent, but they need somewhere to send it. so on a peer relationship sounds correct
<lazypower> you want to correlate that data,  do subordinates get leaders?
 * lazypower deploys one to find out
<blahdeblah> If it makes the problem easier, we can say that only the leader of the subordinates needs to do it (at least initially).
<lazypower> i dont think subordinates get a leader
<lazypower> it wouldn't really make sense for a subordinate to ever declare itself as a leader, it really falls in lign with the parent service its co-locating with
<blahdeblah> Makes sense I guess
<lazypower> just happens to have its own agent, config, and settings bucket
 * lazypower ponders
<lazypower> i dont think you've got any amenities to you that really help solve this
<blahdeblah> In that case, working out in the subordinate whether it's running on the leader primary probably makes the problem harder, not easier.
<lazypower> you're going to emit massive amounts of data on one side, and need to correlate that on the other.
<lazypower> well no, is-leader is very simple. truthy things in bash are powerful at short circuit operations
<blahdeblah> I'm not following you
<lazypower> well, if you had a way to know that one is the primary communication node, and it uses leader-set to broadcast its array of public ips
<blahdeblah> So the subordinate will still have access to all the leader functionality of its primary?
<lazypower> the cluster could feesibly just emit that list of public-ips from the leader. so the update-status hook has a read-only copy of all the nodes coming from that leader, which by nature of the peer relation has all this data which comes in via relation-set
<lazypower> leader controls state of this data, collects, and emits it. The cluster itself uses the data coming from leader-get's dictated data-store
<lazypower> functionality like this was paramount when mbruzek and I were working on the tls layer bits in a peering fashion
<blahdeblah> I'm following you even less now
<lazypower> have a look at layer-tls
<lazypower> blahdeblah do you follow the TLS key exhcnage pattern? where server generates a CSR, CA responds with signed CSR
<blahdeblah> Slow down
<blahdeblah> Are "cluster" and "emit" jargon terms here? Or is "cluster" just generically referring to the group of peer units of the primary charm, and "emit" meaning the data sent on the relation between the primary and subordinate?
<lazypower> yeah, i'm throwing in slang, and i apologize for that
<lazypower> its late and i'm thinking more about dinner :) but i do want to sort this out.
<blahdeblah> So, if those aren't jargon terms, and I'm understanding you correctly, the primary charm would need to be modified to gather the public-address data from its peers and then send it across the relation to the subordinate, right?
<lazypower> yep
<blahdeblah> This is something I want to avoid, so that I don't have to modify the primary.
<blahdeblah> (This is the whole reason for it being a subordinate.)
<lazypower> i understand, the other side to this is to look at conversation scopes
<blahdeblah> i.e. So I can use a vanilla cs: charm
<blahdeblah> lazypower: If you want to head to dinner, go for it; this is totally non-urgent.
<lazypower> blahdeblah https://jujucharms.com/docs/devel/developer-layers-interfaces#communication-scopes
<lazypower> give that a read, and lets re-convene on this topic
<blahdeblah> no worries
<blahdeblah> thanks for your time
<lazypower> blahdeblah i think you can do this with peering, and unitdata.kv and some clever comparison
<blahdeblah> That certainly matches my current understanding; the comparison need not even be that clever.
<lazypower> every registry of that hook, you db.set() the ip in say a dictionary.
<blahdeblah> I'll get some test code going next week and see how it goes.
<lazypower> then where you need that data, just build it from whats stored in the unitdata.
<lazypower> ok, i feel better, i somewhat answered the question. cheers blahdeblah o/
<blahdeblah> Yeah; it just seems a bit wrong to be storing stuff in a non-deterministic way that juju must surely store deterministically.
<blahdeblah> thanks lazypower
<stub> blahdeblah: subordinates do get leaders just like any other charm
<stub> blahdeblah, lazypower : And the leader is not necessary cohosted with the primary service's leader
<blahdeblah> Interesting
<lazypower> stub good to know :) thanks
<hackedbellini> Hello! I'm trying to upgrade the charm of my postgresql deployment on juju, but it gives me this: ERROR cannot upgrade service "postgresql-devel" to charm "cs:trusty/postgresql-39": would break relation "postgresql-devel:replication"
<hackedbellini> the weird thing is. That relation is the service with itself, and I never created it myself
<hackedbellini> I already tried to destroy the relation with "juju destroy-relation postgresql:replication postgresql" but it gives me "ERROR no relations found"
<hackedbellini> anyone have any light for me?
<lazypower> hackedbellini looks like between charm revisions, the peer relationship was removed
<lazypower> I think juju is doing the right thing by blocking your upgrade. the charm has become backwords incompatible
<hackedbellini> lazypower: I see... So, there's no way for me to upgrade the charm on my deploy?
<lazypower> hackedbellini not safely, no.
<lazypower> hackedbellini i'm fairly certain you can juju upgrade-charm --force --switch {{charm_string_here}} but this would be marked as unsupported as it may exhibit weird behavior
<lazypower> i believe the pattern is to deploy the new postgresql charm and migrate the db's, but i may be wrong. stub would have more info here
<stub> IIRC this was deemed a juju bug. I'm not sure if it is fixed or in what version.
<stub> I've got tests that confirm upgrade works from r127 to trunk - I'm not sure how that maps to cs: version numbers.
<stub> (with Juju 1.25)
<lazypower> stub so the upgrade-charm --force --switch should work?
<lazypower> as in the replica peer relation going away wont have any detrimental effects?
<stub> Just plain upgrade-charm should work IIRC. upgrade-charm should not block if a relation is removed, or it becomes impossible to ever remove a relation.
<lazypower> yeah that behavior was changed in 1.25 i think
<stub> How old is cs:39 ? I only trust upgrades at all since bzr r127 (since that is what I have tests for) :)
<stub> But that said, no problems at all if you aren't using replication. If you are using replication, it might take me some research on what will happen.
<stub> If it is the leadership version, should be no problems. If it is pre leadership, there will be problems.
<hackedbellini> stub, lazypower: correct me if I'm wrong, but you are saying that on 1.25 I should be able to upgrade-charm, is that correct? When I type 'juju version' it gives me '1.25.0-trusty-amd64'. But the charms are on 'agent-version: 1.20.12.1'. Is that the reason I cannot do that upgrade?
<lazypower> hackedbellini thats a big part of it
<lazypower> hackedbellini you should be able to juju upgrade-juju and jump those agents up to 1.25, and then your upgrade charm operation *should just work*
<lazypower> man 1.20 to 1.25 though? thats a pretty big leap in terms of agent capability
<stub> You have to upgrade to at least 1.24 anyway to use the modern PostgreSQL charm - it requires leadership and other features.
<lazypower> i'm asking in #juju-dev ot see if we have evidence of 1.20 => 1.25 upgrading without issue
<lazypower> i'm a little concerned as i recall 1.22 in that mix being a problem child
<lazypower> and it caused some headaches with env upgrades, so before i send you off on that path i want more data :)
<stub> hackedbellini: Do you have a single PostgreSQL unit in the service, or do you have multiple units in the service?
<hackedbellini> lazypower: hrm I see. Thank you, that information will help a lot! :)
<lazypower> hackedbellini well, they just confirmed that 1.20 is our jumping / reference point for all upgrades
<lazypower> so you're g2g on doing a juju upgrade-juju
<hackedbellini> stub: I have 2 deployments, each one with 1 unit
<hackedbellini> lazypower: nice! :)
<lazypower> wait.. so juju is blocking you on a single node upgrades because a peer relation breaks?
 * lazypower facepalms
<stub> hackedbellini: That will make it easier. I'd still grab a backup just in case since you will have a rather old version, but should work.
<lazypower> thank you legacy behavior
<stub> lazypower: I think it was a regression, which is why no problems occurred when the rename actually happened.
<lazypower> ah
<lazypower> makes sense
<lazypower> stub man, you're like omnipresent on teh bugs i find
<stub> I'm not sure though. Can't change history anyway.
<lazypower> i must be traveling the same path, a few months behind you
<stub> Dude, I *wrote* half of the bugs.
<lazypower> stub will it make you unsettled if i make a t-shirt "Stub Wannabe #1"
<lazypower> I think it would be brilliant to follow you around a conference w/ the tee on
<stub> lazypower: You'll need a hippy wig
<lazypower> that can be arranged
<hackedbellini> lazypower: yes, it was a single node deploy
<lazypower> hackedbellini: yeah, i would do as stub suggests. grab backups if you care about the data
<lazypower> then juju upgrade-juju
<lazypower> once that's settled and every agent has reached 1.25, then tackle the pgsql upgrade
<hackedbellini> stub: yes, I'll make a backup first. Luckily the machine I'm deploying (it is a local juju installation) is using btrfs, so I can just make a snapshot. Do you know if I should snapshot anything else other than /var and the place where '.juju' resides?
<stub> hackedbellini: I'd go for the pg_dump output (probably cronned to ~postgres/backups)
<stub> hackedbellini: If you want a filesystem snapshot, ~postgres or ~postgres/9.x/main
<stub> hackedbellini: But the logical dump from pg_dump is your parachute in case everything else burns completely to the ground.
<hackedbellini> stub: I mean the "master" machine itself. My deploy is a local one, around 10 charms deployed on 10 different lxcs (forgot to point that). That machine is using btrfs, so if I snapshot /var, all lxcs will also be snapshotted so I can restore everything if anything goes wrong.
<stub> hackedbellini: Yeah, but I'd still have a logical dump cause I have trust issues ;)
<hackedbellini> I know that the lxcs are inside /var and there are important things on the ~/.juju of the user that runs it. But are there other places that I should also snapshot?
<cmars> i'm getting an install hook error in my layered charm, https://paste.ubuntu.com/14582988/
<hackedbellini> stub: hahahaha I know what you mean :)
<cmars> anyone seen this?
<hackedbellini> will surely do one also!
<stub> I like having multiple escape routes dealing with real data ;)
<lazypower> cmars  > Detected a distutils installed project ('six') which we cannot uninstall.
<lazypower> interesting
<cmars> same charm-tools 1.11.0 i've been using
<lazypower> cmars - clean machine? series, substrate?
<cmars> lazypower, lxd provider, same trusty image i've been using
<lazypower> schenanigans. I'm not sure where the copy of six is coming from :/
<lazypower> cmars have you rm -rf'd your built charm dir, rebuilt, and then deployed?
<cmars> lazypower, oh yeah, that's my typical workflow
<stub> charmhelpers will install the python{,3}-six package if it somehow got imported before charms.reactive's bootstrap got invoked.
<stub> But you would have to try hard to do that.
<stub> six 1.5 sounds old enough to be coming from the Ubuntu package.
<kiko`> async@riff:~$ juju sync-tools
<kiko`> ERROR tools upload failed: 400 ({"Tools":null,"DisableSSLHostnameVerification":false,"Error":{"Message":"cannot get environment config: invalid series \"centos7\"","Code":""}})
<kiko`> lazypower, any clue on why I'm getting the above?
<marcoceppi> kiko`: what are you trying to do?
<kiko`> marcoceppi, uhh, juju sync-tools in order to do an upgrade-juju
<kiko`> juju package is 1.25.0
<marcoceppi> kiko`: what kind of environment is this?
<kiko`> local
<kiko`> lxc
<marcoceppi> weird, I've not seen that error before
<marcoceppi> not sure why it's trying to do something with centos7
<kiko> https://bugs.launchpad.net/juju-core/+bug/1510688
<mup> Bug #1510688: sync-tools tries to upload agents that are not permitted by the state server <bug-squad> <sync-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1510688>
<kiko> damn
<kiko> this may be a deal-breaker for my upgrade
<kiko> cherylj, rick_h_ ^^
<hackedbellini> lazypower, stub: unfortunately, we could not upgrade our juju installation, as you can see on what kiko said above
<cherylj> kiko: hmm, I thought we had done some work around that recently.
<cherylj> kiko: what series is it complaining about?
<lazypower> cherylj "centos7"
<cherylj> bleh
<cherylj> ok
<cherylj> lazypower, kiko what version are you on now?
<kiko> cherylj, 1.20.14
<kiko> err actually
<kiko>     agent-version: 1.20.12.1
<cherylj> kiko: okay, let me dig around and refresh my memory of that code path
<kiko> cherylj, it really does look like that bug is still alive and well :)
<cherylj> kiko: well, what I thinking of was very recent, so it wouldn't be in 1.20.
<kiko> cherylj, https://bugs.launchpad.net/juju-core/+bug/1510688
<mup> Bug #1510688: sync-tools tries to upload agents that are not permitted by the state server <bug-squad> <sync-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1510688>
<kiko> cherylj, it's basically when you have a newer client installed (I have 1.25.0) and you try and do a sync-tools
<kiko> it will also break upgrade-juju as soon as 1.26/2.0 is out
<kiko> this sucks
<kiko> is there a workaround? I need to get off 1.20
<cherylj> kiko: yeah, it does.  Let me see if I can work out a workaround for you
<beisner> thedac, rmq mitaka amulet test enablement MP passing, ready to land if you will:  https://code.launchpad.net/~1chb1n/charms/trusty/rabbitmq-server/next-amulet-mitaka-1601/+merge/282497
<thedac> beisner: I'll take a look shortly
<cmars> stub, lazypower it looks like python-six is already installed on the 14.04 cloud image: https://paste.ubuntu.com/14583863/
<cmars> stub, lazypower so is this breaking the reactive install hook?
<aisrael> WARNING failed to find 1.25.2 tools, will attempt to use 1.25.0
<aisrael> This is on aws. Shouldn't amazon have the latest tools?
<rick_h_> aisrael: try hitting up QA in the other channel?
<rick_h_> aisrael: you'd think so but not sure how wide it's gone and curious what region/etc?
<aisrael> rick_h_: ack, #juju-dev or is there a separate channel for q?
<aisrael> ya
<aisrael> qa*
#juju 2016-01-21
<Muntaner> hello to everyone...I have a problem with a bootstrap, is this the right channel?
<Muntaner> marcoceppi, ping
<Muntaner> I'm trying to bootstrap juju with two maas machines, that actually are two VM into VMWare...  I installed the Maas controller on another machine, and the bootstrap seems to go well, it installs the OS cloud into the first of the two machines but when it comes to MongoDB replica stuff, it fails. I have under my hands the logs that I see in this situation
<wesleymason> Unable to install my charm after rebuilding it this morning: https://github.com/juju-solutions/reactive-base-layer/issues/27
<beisner> jamespage - can you review/land these liberty, xenial amulet test enablements?:  tia
<beisner> https://code.launchpad.net/~1chb1n/charms/trusty/glance/next-amulet-mitaka-1601/+merge/282496
<beisner> https://code.launchpad.net/~1chb1n/charms/trusty/keystone/next-amulet-mitaka-1601/+merge/282493
<beisner> https://code.launchpad.net/~1chb1n/charms/trusty/rabbitmq-server/next-amulet-mitaka-1601/+merge/282497
<beisner> jamespage, +this one:
<beisner> https://code.launchpad.net/~1chb1n/charms/trusty/neutron-api/next-mitaka-amulet-1601/+merge/282835
<beisner> uno mas, jamespage.  it's raining test extensions...
<beisner> https://code.launchpad.net/~1chb1n/charms/trusty/cinder/next-amulet-mitaka-1601/+merge/282519
<wesleymason> marcoceppi: is the base layer not pinning the wheels it vendors?
<wesleymason> specifically pip in this case
<marcoceppi> wesleymason: I tried to pin it in the base layer
<marcoceppi> wesleymason: but it's still getting pulled in by charms.reactive which does not have it pinned
<marcoceppi> wesleymason: I'm going to try to patch there
<marcoceppi> but I'd really like cory_fu_ to weigh in on the MP there
 * wesleymason nods
<wesleymason> marcoceppi: for the record there's 2 of us sat here with different charm layers stuck on it ð
<marcoceppi> wesleymason: there's more than two, that's for sure
<marcoceppi> wesleymason: everyone is blocked which makes it a priority patch
<wesleymason> ð
<marcoceppi> wesleymason: would you be willing to try a patched layer?
<wesleymason> marcoceppi: sure
<marcoceppi> wesleymason: okay, so this actually needs changes in charm-tools
 * wesleymason gets popcorn
<marcoceppi> wesleymason cmars kjackal I've updated https://github.com/juju-solutions/reactive-base-layer/pull/26 when tested, only pip-7.1.0 was included in the wheelhouse which shouldn't present these problems
<wesleymason> ð
<marcoceppi> once I have cory_fu_ or bcsaller feedback I'll push a 1.11.1 release almost immediately after
<kjackal> thank you marcoceppi
<icey> gah bundletester is failing because of uncommitted changes in charms that it is checking out!
<geetha> @mbruzek: Hi, I have got comment for WebSphere Base product where its mentioned that we should add configuration options for profile options like profile name, path, and admin username and password. But once user installs Websphere product and if he changes any of those values using juju set, It will not create profile again with new values. So what is the benifit of giving config options for these profile options?
<icey> I'm seeing a strange issue in bundletester; I'm using `bundletester -e amazon -l DEBUG -vF` to run tests and it looks like bundletester is pulling down other charms from launchpad and then failing because the machine I'm running bundletester on has no ssh key to access LP?
<icey> all tests give me this error: bzrlib.errors.ConnectionReset: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<D4RKS1D3> Hi
<D4RKS1D3> Someone has problemas installing odl-controller within juju?
<D4RKS1D3> problems*
<lazypower> cmars - the issue with pyyaml
<lazypower> did you find a work around? i just ran into it
<lazypower> nvm i see in the scrollback this is being triaged already - https://github.com/juju-solutions/reactive-base-layer/issues/27
<bdx> charmers: Has storage support for openstack provider been considered? .. or possibly already exist?
<bdx>  core^
<narindergupta> D4RKS1D3: no one has issues with odl-controller make sure you provide the url and profile correctly based on which ODL r u targetinh
<arosales> tych0: I am not sure what you'll need to test exactly but I think I have a way for you to bootstrap xenial on AWS, may also work on GCE
<arosales> and to deploy Xenial workloads
<tych0> arosales: oh, sweet
<arosales> tych0: how was the ride?
<tych0> arosales: good. unusually fast, actually, must have slept well last night :)
<arosales> bdx: re storage provider, definitely something considered and may already be on the roadmap
<arosales> bdx: may need to ping in #juju-dev on free node to get a more exact answer though
<arosales> tych0: and solid weather :-)
<tych0> arosales: yeah, for sure
<arosales> well and the whoosh of carbon wheels, right
<tych0> arosales: ha yeah. you have to be better than me to actually get an advantage from them. but they sure sound cool :)
<arosales> I am sure you take advantage of them
<arosales> tych0: so you need xenial on a cloud?
<tych0> arosales: yeah, if you have a way. that would save me from having to ssh to the node and add a lxd ppa
<arosales> I currently have a bootstrap and deploying the ubuntu charm on AWS onto of xenial with 1.26 alpha juju
<tych0> sweet
<tych0> what's the magic sauce?
<arosales> tych0: I can add you ssh keys if you would like, but the sauce was as follows
<arosales> for AWS, I have to check GCE
<arosales> installed the -devel version of juju (for 1.26)
<arosales> confirmed the daily stream has xenial
<arosales> https://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:aws.json
<arosales> in my ~/.juju/environment.yaml I updated image-stream: "daily"
<arosales> under the AWS stanza
<arosales> the then juju bootstrap --upload-tools
<arosales> given aws is your default environment
<arosales> oh
<tych0> ah
<tych0> maybe i can't set the image-stream for GCE?
<tych0> i don't see it in the code :\
<arosales> and I am on a Xenial Ubuntu desktop from which I am running the client
<arosales> I think juju looks at the juju version and desktop client to build the appropriate tools, because I couldn't get it to work from my trusty machine
<tych0> yeah
<tych0> i think you're right
<tych0> cool, thanks
<tych0> do we happen to have any company AWS accounts? or should i just sign up for my own?
<arosales> also for the aws stanza I also set  `default-series: xenial`
 * arosales checking GCE for daily stream
<arosales> ya looks like no daily stream for GCE
<bdx> arosales: great, thanks
<arosales> also if others are following the xenial conversation I also set `default-series: xenial` for my amazon/aws stanza and I was able to bootstrap and deploy xenial instances
<arosales> I did have to deploy local charms with the directory structure ./xenial/<charm-name>  but seems to be working on AWS
<arosales> bdx: ping if you don't get response and I can also digg on that
<lazypower> that makes sense that you'd have to do local only
<lazypower> i dont think any of the charm store has been ported over to xenial yet
<arosales> yup, that was my take lazypower
<bdx> arosales: sweet, will do!
<arosales> I didn't say, but `default-series: xenial` in the environment.yaml file, in can folks were wondering
<lazypower> hey tych0 whats your TZ again?
<lazypower> i'm doing some slides for fosdem, and it would be really helpful if i could poke you for some specifics of how LXD is doing things
<tych0> lazypower: nominally mountain time
<tych0> lazypower: but really any time as long as i'm at the keyboard :)
<lazypower> :) Is your schedule tomorrow crazy? i only  need a few irc pokes here and there
<tych0> lazypower: not at all, any time should work
<lazypower> awesome. thanks tych0, as always you da man :)
<tych0> i usually start around 7
<tych0> lazypower: well, let's not go that far :)
<lazypower> one word
<lazypower> "doom"
<tych0> :)
#juju 2016-01-22
<jamespage> gnuoy, can I get a review of https://code.launchpad.net/~james-page/charm-helpers/handle-called-process-exception-for-git/+merge/283583 ?
<gnuoy> sure
<jamespage> that's breaking odl-controller on a ch resync right now
<gnuoy> jamespage, +1
<jamespage> gnuoy, ta
<philip_stoev> Hello. What would be the canonical way to determine that a given host is the first one in a set of peers within the install() hook. That is, as juju starts  N nodes concurrently, how can the install() hook be different for the first of those nodes ?
<D4RKS1D3> Hi jamespage , I am trying to install odl, but always fail, could you help me?, thanks
<jamespage> D4RKS1D3, can you check /var/log/juju/unit-odl-controller-0.log for an error pelase
<D4RKS1D3> jamespage, this is my configfile http://paste.ubuntu.com/14597039/ and the error in unit-odl-controller is this. http://paste.ubuntu.com/14597058/
<D4RKS1D3> Thanks for help me
<jamespage> D4RKS1D3, the install-url is not accessible
<jamespage> 2016-01-22 11:30:29 INFO install charmhelpers.fetch.UnhandledSource: No handler found for source https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribution-karaf/0.3.3-Lithium-SR3/distribution-karaf-0.3.3-Lithium-SR3.tar.gz
<jamespage> wait
<jamespage> actually
<D4RKS1D3> but this link works
<jamespage> D4RKS1D3, where are you getting your charm from?
<jamespage> I just fixed this bug this morning
<D4RKS1D3> https://jujucharms.com/u/sdn-charmers/odl-controller/trusty/8
<jamespage> D4RKS1D3, oh please don't use that one
<jamespage> D4RKS1D3, that's old...
<D4RKS1D3> Could you send me the link of the new charm?
<jamespage> yes - one second
<D4RKS1D3> Thanks
<jamespage> D4RKS1D3, https://jujucharms.com/u/openstack-charmers-next/odl-controller/trusty
<jamespage> thats the latest development goodness
<D4RKS1D3> Thanks jamespage
<D4RKS1D3> i am retry
<jamespage> I have another branch in flight with some other features, but its not ready to land just yet
<D4RKS1D3> Okey, thanks for help me
<D4RKS1D3> jamespage, sorry for disturb, now i have a crc problem http://paste.ubuntu.com/14597388/
<D4RKS1D3> this is the same error i received with the obsolet charm
<D4RKS1D3> you know how to solved it?
<icey> is it possible for a stop hook to be called in a context besides the destruction of the unit?
<icey> can somebody help me with testing an action? my python fu is not strong enough apparently
<jamespage> D4RKS1D3, that would indicate that the archive you are downloading is corrupt - are you going via a proxy?
<jamespage> it might have a bad copy
<nottrobin> would anyone have any idea why my juju might not be honouring $JUJU_REPOSITORY? http://pastebin.ubuntu.com/14597757/
<nottrobin> oh never mind, I hadn't `export`ed it
<D4RKS1D3> yes jamespage
<D4RKS1D3> We are behind to a proxy
<D4RKS1D3> but is a transparent proxy
<icey> can anybody provide an example charm that tests actions? I've looked through a few of the openstack charms and, while they do have actions defined, they have no tests that perpform those actions
<icey> ah, looks like swift-proxy actually tests actions
<lazypower> icey : your findings on the topic would make an excellent blog post
<icey> agreed lazypower, may take some time this afternoon to write up about adding actions with tests to a charm :)
<icey> if I get to that, I'll send you a URL
<icey> have a couple of posts to write now, layer charm being one :)
<lazypower> \o/
<lazypower> roll that beautiful blog footage icey
<icey> haha lazypower
<cory_fu_> jose: Hey, you around?
<bdx> anyone else having issues with adding the lxd stable repo in xenial?
<bdx> I'm hitting this: https://github.com/juju/docs/issues/820, I've already pinged the lxcontainers about this, just thought I would post here too ..
<jose> cory_fu_: yes, what's up?
<cory_fu_> jose: We were doing RQ and admcleod1 wanted to discuss your comment on https://code.launchpad.net/~talligent/charms/trusty/openbook/trunk/+merge/280525 but he went ahead and added his own comment because he had to EOD
<cory_fu_> jose: The store seems to accept any tags, not just the ones on the list, though of course consistency is good
<cory_fu_> And we weren't sure how big of a deal the literal mdash was
<cory_fu_> Again, the charm store seems to render them ok
<jose> hmm. from the wording on the docs it didn't seem like it and I didn't want to break anything. preferred to be safe than sorry
<cory_fu_> Yeah, I agree that the wording on the docs implies that you should *only* use those tags, but that seems overly restrictive to me, and looking at https://jujucharms.com/u/talligent/openbook it seems to work ok
<jose> hmmk
<jose> thanks for letting me know
<cory_fu_> We were leaning toward those two items being worth addressing, but not blocking the MP, but your +/-1 has more weight than admcleod1's since you're a ~charmer.  ;)
 * lazypower snickers
<lazypower> cory_fu_   - you sir, are awarded 15 internet points
<bladernr_> Hey, can you guys point me to some documentation somewhere on how to bootstrap into a container locally BUT deploy services to metal elsewhere?  Basically, I want to bootstrap into an LXC container on a MAAS server, and then use MAAS to deploy nodes w/ services on it.
<rick_h_> bladernr_: manual provider is all I can think of. We don't have cross provider in Juju currently
<bdx> core, dev, charmers: whats up with this ---> https://bugs.launchpad.net/charm-helpers/+bug/1534819
<mup> Bug #1534819: FetchHandler charmhelpers.fetch.giturl.GitUrlFetchHandler not found <Charm Helpers:New> <https://launchpad.net/bugs/1534819>
<icey> lazypower: https://chrismacnaughton.com/blog/2016/01/22/adding-actions-to-a-juju-charm/
<lazypower> Nice!
<icey> lazypower: just for you :)
<lazypower> will syndicate after daily :)
<icey> syndicating on insights.ubuntu.com?
<lazypower> icey - i dont have that level of authority
<lazypower> but i'll tweet it out :)
<icey> lazypower: apparently I don't either :-P
<lazypower> icey do you have a twitter handle?
<icey> https://twitter.com/ChrisMacN
<arosales> bdx hello
<arosales> bdx did you get past the xenial lxd issue -- thanks for updating the docs for all btw
<arosales> bdx: re your bug 1534819 marcoceppi looks to be the author there and is currently at scale conf, but I am sure he will get this ping and comment in the bug when he is back at a computer
<mup> Bug #1534819: FetchHandler charmhelpers.fetch.giturl.GitUrlFetchHandler not found <Charm Helpers:New> <https://launchpad.net/bugs/1534819>
<arosales> thanks for submitting it. :-)
<bdx> arosales: no, I haven't been able to find a way around it, other than grabbing the source from github and building locally
<bdx> arosales: totally, thanks
<arosales> bdx was that in reference to the lxd/xenial issue or the charm helper fetch issue?
<bdx> arosales: the lxd issue ... I've got it figured out now
<arosales> bdx cool, so just the charm helper fetch -- gotcha
<arosales> marcoceppi: should catch that when he gets back in front of a computer thanks for logging it
<bdx> perfect, thanks!
<lazypower> > build: The top level layer expects a valid layer.yaml file  - is there ever a time when building that you wont have a layer.yaml file? as thats pretty much the map to the world of what you're trying to do.
<cory_fu_> lazypower: That message should probably be changed to suggest that you're probably not building in the right directory or are missing an arg or something
<lazypower> cory_fu_ yeah, it surprised me it was yellow, and didnt halt execution. Not being in the TLD makes sense why it would yellow and attempt to continue
<lazypower> yellow = warn in my  mind.
<cory_fu> ORLY, it wasn't fatal?  It definitely should be.
<cory_fu> Though I could maybe see having it check up a dir or two for a layer.yaml
<cory_fu> lazypower: Also, I think the "top level layer" bit is misleading and confusing.  It should just say something like, "Can't find layer.yaml; are you building from the correct directory?"
<lazypower> heh yeah, i dropped into charmbox cory_fu and promptly started building a charm of my $HOME
<cory_fu> ha
<lazypower> it may have been still checking / and/or /home for layer.yaml when i nuked the process + container
<tych0> lazypower: hi, i'm going to flip the script here and ask you a question (although you don't have to know the answer :)
<lazypower> tych0 nice
<tych0> but suppose i wanted to write a charm. i saw a lightning talk recently (don't remember where) that someone had implemented a thing where you could just put in the charm's config what series it was for, vs. having to have a trusty/ and xenial/ version of everything
<tych0> is there some docs about where to use that feature?
<tych0> or did i completely misunderstand the lightning talk?
<lazypower> ah series in config
<lazypower> nope, thats a new thing :D
<lazypower> *series in metadata
<jose> lazypower: ping
<lazypower> jose: pong
<tych0> lazypower: a new thing in that i'm crazy and it doesn't exist? or that i have to build from source? (i don't mind using a source build so long as i can figure out which config bits to put in)
<jose> lazypower: hey, Matt tells me you have docs for layers but I can't find them on /docs, do you by chance have a link handy?
<lazypower> jose jujucharms.com/docs/devel
<jose> ah
<jose> gotcha
<jose> thanks
<lazypower> np :)
<lazypower> jose actually - the front page of the getting started guide tours you through layers - https://jujucharms.com/docs/devel/developer-getting-started
<jose> just stumbled upon that one, thank you!
<jose> I guess it's time to rewrite the owncloud charm to a layered one
<lazypower> You'll enjoy it :)
<lazypower> are you going to do a bash or a python layer jose?
<lazypower> tych0 i'm looking btw - 1 sec
<jose> lazypower: not even sure how these work, so I'm reading a bit first. I'd be more inclined to bash, but if I can do python I'll do it.
<tych0> lazypower: cool, thanks, no worries
<jose> I think the fact that the current charm is in bash makes it easier to port
<lazypower> tych0 this is in 2.0-alpha1
<lazypower> so its in -devel ppa
<lazypower> tych0 https://lists.ubuntu.com/archives/juju/2016-January/006365.html if you want the release notes
<lazypower> > Juju 2.0's new features and behaviours will confuse older Juju clients. - and that explains about the last 2 hours of my day
<lazypower> whoops :P
<tych0> :)
<tych0> yeah, i was hitting that earlier today as well
<lazypower> bindmount $JUJU_HOME in a container running 2.0
<lazypower> then drop back in my native env w/ stable and it gets weeeeiiirrrdddd
<tych0> ah, multi series charms
<tych0> cool
<tych0> lazypower: ok, here's another juju noob question. is there a way to alias machines somehow? so i can do juju ssh some-machine instead of juju ssh 1?
<lazypower> only if there's a service on it
<tych0> yeah, i think there will be
<lazypower> juju deploy ubuntu/1
<lazypower> s/deploy/ssh/
<tych0> right, ok. but if all of the machines have the same service, it's the same
<lazypower> each unit has an id, that is serially assigned
<lazypower> juju ssh ubuntu/12
<lazypower> but no, without a charm deployed on the machine, there is no other alias than the machine id
<lazypower> :(
<lazypower> jose in here please :)
<tych0> ok, cool, np :)
<jose> let me copy and paste
<jose> <jose> so, I don't get it. I need to write an owncloud charm and include that alongside the http/mysql/basic layers?
<lazypower> Good question. So you've got an existing owncloud charm right? Recall how you had to stand up apache, setup php, all that fun business befor eyou could even start modelling owncloud?
<jose> eeeh not actually. I just did another iteration
<jose> I'll have a read at the charm code first
<lazypower> with layers you are correct, you pick up the HTTP interface for free, the Apache-PHP layer, and write your new layer which sits nicely on top of all that.
<lazypower> the overall code of your charm will slim down to ~ 3 files, and maintenance becomes easier for you :)
<jose> hmmk
<jose> lazypower: ok, so I think I've got the basics. I'm gonna take a further look later in the night, need to run!
<jose> I hope to have it done by later though
<lazypower> cheers jose  o/
#juju 2016-01-23
<catbus1> Hi, I hit this issue: https://bugs.launchpad.net/charms/+source/neutron-api/+bug/1535374, is there a way to update the keystone charm without redeploy?
<mup> Bug #1535374: keystone hook failed: "shared-db-relation-changed" - Invalid service requested: 'neutron' <oil> <neutron-api (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1535374>
<catbus1> how do I tell the unit to update the keystone charm from the keystone/next?
<arosales> catbus1: I am on my way out but saw your question.  Have you take a look at charm upgrade?
<arosales> re the bug you referenced the suggestion was to try the next development release of the charm and not the stable one.  But not that around Jan 28 there should be openstack charm release to pull this in
<arosales> catbus1: references to look at:
<arosales> https://jujucharms.com/docs/1.25/authors-charm-upgrades
<catbus1> arosales: but the charm upgrade is from the same place keystone/stable, right? I need it from keystone/next
<arosales> correct you would need to branch the charm locally and then specify that in your charm upgrade
<arosales> here are a couple of other references
<arosales> https://jujucharms.com/docs/1.24/commands (search the page for upgrade-charm
<catbus1> arosales: ok, great, thank you!
<arosales> and a few other forum posts
<arosales> http://marcoceppi.com/2015/01/force-upgrade-best-juju-secret/
<arosales> https://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes/OpenStackCharms
<arosales> https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/ReleaseNotes1510
<arosales> if you are running in production I would suggest to wait for the stable release so you are on a stablel to stable path
<arosales> but at least you can read over these options and perhaps give you some things to consider
<arosales> hope that helps.
<arosales> have a good weekend
 * arosales grabs some dinner
<catbus1> arosales: it does help. thanks, have a weekend.
<arosales> cool
 * D4RKS1D3 Hi
#juju 2016-01-24
<D4RKS1D3> Hi, juju servers are in maintenanceÂ¿
<arosales> D4RKS1D3: hello, no maintenance just must be a lot of folks not looking at IRC. there is scale conf this week too
<urulama> D4RKS1D3: yes, there's a storage outage making charms inaccessible atm. our guys are working on the issue
<urulama> arosales: ^
<arosales> oh so there is, thanks urulama
<arosales> D4RKS1D3: ^ fyi
<D4RKS1D3> Thanks arosales and urulama
<urulama> D4RKS1D3: resolved now, everything should be back to normal
<D4RKS1D3> Thanks urulama
<arosales> to
<arosales> thanks urulama
<lazypower> tych0 ping
<D4RKS1D3> jamespage, Are you here?
<D4RKS1D3> I am having problems to add ml2_odl into the ml2_conf.ini
#juju 2017-01-16
<ejat> pmatulis: owh .. so just link the landscape client to the openstack services ?
<pmatulis> ejat, nope. forget the landscape client stuff for now. within landscape server there is a cloud installer section, which is called "autopilot"
<ejat> so setup maas n landscape server 1st ?
<ejat> then later use the cloud installer section
<kjackal> Good morning Juju world!
<deanman> morning
<Spaulding> gday!
<junaidali> Hi, I have a failed machine (a controller instance in HA), I have run 'juju enable-ha' to ensure HA again but now I can't remove the failed machine
<junaidali> it is giving error 'ERROR no machines were destroyed: machine <machine number> is required by the model'
<junaidali> Any idea, what I'm missing here. Juju HA is already ensured.
<kjackal_> Hi junaidali, you might have more luck asking at #juju-dev . Since it is a day off in the US you might want to also send an email on the list, so that your question gets answered
<junaidali> sure, thanks kjackal_
<Michel_> Hi Guys, Trying to run the kubernetes juju, so im creating a bootstrap, but halfway it fails because it looks for the Gateway IP?
<kjackal> hi Michel_ you are saying juju bootstrap is failing?
<Michel_> Yes
<Michel_> Its trying to SSH into the DG
<Michel_> Im trying to give the containers a IP on our network, because we're trying to set up a Kubernetes cluster
<Michel_> howeer, when setting up lxd, if i set up a local 10.X.X.X bridge, it works, however, trying to put it on the local network doesn't
<kjackal> Just a sec Michel_ let me try to understand. I am not sure I follow. Can you show us the output of "juju bootstrap --debug"
<Michel_> Sure
<Michel_> http://paste.ofcode.org/39bkLRyByg4GgrYGsKM4TpW
<Michel_>  I have ens18 - Network adatper. br0 - Bridge created and its bridge_port is set to ens18
<Michel_> When running bootstrap, it tries to go into the DG
<kjackal> Michel_: are you following something like this: https://insights.ubuntu.com/2016/11/21/conjure-up-canonical-kubernetes-under-lxd-today/
<Michel_> Hi am
<Michel_> But it doesnt give no networking information
<kjackal> I know that kubernetes on LXD needs some special configuration so the recomented way to deploy it is through conjure-up
<Michel_> Because the VM itself is on a 172.30.16.X network, when i create the lxdbridge, it goes on a 10.X address, if i put it on a 172.30.16 address, it doesn't work.
<Michel_> Im trying to find sources on the configs but nothing :(
<Michel_> When i deploy the kubernetes master, it gets a 10.X address, and not a 172.30.16 address which is what the VM is on. (so when i try to reach to the master GUI, i cannot access a 10.X.X.X address on my network because its in a 172.x.x.x address and the 10.X is a network for the containers only
<kjackal> Michel_: I do know if that helps, the kubernetes configuration done by conjureup is here: https://github.com/conjure-up/spells/tree/master/canonical-kubernetes
<Michel_> Thanks man let me take a look D
<Michel_> :D *
<SimonKLB> does anyone know how to recreate the certificates for the kubernetes bundle?
<SimonKLB> running the upgrade-charm hook on etcd seem to be a good start
<Michel_> Also, one more issue, i cannot delete 1 controller, the VM hangs
<Michel_> i deleted the lxc container by accident corresponding to that controller
<Michel_> but now it just hangs when i use juju destroy-controller *name* --destroy-all-models
<SimonKLB> Michel_: if all else fails, use `juju kill-controller`
<Michel_> Thanks
<SimonKLB> Michel_: `juju remove-machine X --force` could also be helpful
<Michel_> Thank you
<Spaulding> jlug
<bdx> hows it going all?
<bdx> I would like to introduce everyone to Ronald Haynes, @rahworks here on freenode. Ronald will be joining me in maintaining and charming creativedrive infrstructure, and will be going to the charmer summit in my stead this year.
<rahworks> Hello All, looking forward to using juju and learning more about it
<rick_h> bdx: howdy, we'll miss you!
<rick_h> rahworks: welcome to the party
#juju 2017-01-17
<rmcadams> when you deploy juju, against maas - (juju bootstrap maas controller01) is there a way to specify what server from maas it uses?
<stormmore> you could tag the machine in maas and then use --constraints as part of your juju deploy command
<rmcadams> duh, why didnt I think of that
<rmcadams> good call stormmore
<rmcadams> thank youv ery much
<stormmore> no prob
<rmcadams> watching juju deploy openstack is actually kind of mind bending for anyone who's ever deployed it
<stormmore> I remember my first time doing that :)
<rmcadams> I can't tell you how many times I've built/rebuild clusters (Piston, RedHat, Canonical etc...) and to watch juju do this... is insane.
<stormmore> I am building a kubernetes cluster right now using it
<rmcadams> nice
<kjackal> Good morning Juju world!
<junaidali> Good morning kjackal
<kjackal> hello junaidali
<cjwatson> I have a weird deployment issue that I don't understand.  Can somebody help?  Freshly-deployed lxd controller fails to deploy with https://pastebin.canonical.com/176151/ even though a different local charm seems to deploy fine; the charm in question is still a work in progress but looks like http://paste.ubuntu.com/23815957/
<cjwatson> I believe the "cannot interpret as local bundle" bit is normal (it's not a bundle, and I see this with a successful deployment too).  The weird bit seems to be that it POSTs the charm to its local store and then claims it's not found.
<rick_h> cjwatson: is the other one a nested directory like that?
<cjwatson> rick_h: Roughly the same structure, but this is the source code structure rather than what the actual charm looks like, and I guess the latter would be more useful to you
<rick_h> cjwatson: this seems close, but not from the charmstore, to https://bugs.launchpad.net/juju/+bug/1628786
<mup> Bug #1628786: Resources can't be downloaded <rteam> <juju:Fix Released by natefinch> <https://launchpad.net/bugs/1628786>
<cjwatson> http://paste.ubuntu.com/23815984/
<cjwatson> that looks a bit different, it's not getting as far as uploading resources here AFAICS
<rick_h> cjwatson: yea, agree. Local charm, charm isn't found vs resource.
<rick_h> cjwatson: the only thing I can think to "try" is to see if you can deploy the charm form the charm directory "juju deploy . --resource ../....."
<cjwatson> I could try without the resource first as well I guess
<rick_h> cjwatson: but it what you have should be fine, unless something went wrong in the post that's in the controller logs
<cjwatson> what should I be looking for in controller logs?
<rick_h> cjwatson: fair enough, just to try to narrow down what's up
<rick_h> cjwatson: something around getting this post and rejecting it for any reason.
<rick_h> 11:36:34 DEBUG httpbakery client.go:246 } -> error <nil>
<cjwatson> I see stuff like http://paste.ubuntu.com/23815994/
<rick_h> that's about the cookie jar bits used with the macaroon auth
<rick_h> cjwatson: so perhaps something is up with auth...not sure
<cjwatson> error <nil> looks like AOK though
<cjwatson> and I see that in my control case of a successful deployment too - <cjwatson@niejwein ~/src/canonical/launchpad-buildd/charm/charm>$ env -u http_proxy juju deploy --debug --resource=launchpad-buildd=/home/cjwatson/src/canonical/launchpad-buildd/charm/charm/dist/resources/launchpad-buildd/launchpad-buildd.deb ...
<cjwatson> ... --resource=python-lpbuildd=/home/cjwatson/src/canonical/launchpad-buildd/charm/charm/dist/resources/launchpad-buildd/python-lpbuildd.deb /home/cjwatson/src/canonical/launchpad-buildd/charm/charm/dist/xenial/launchpad-buildd
<cjwatson> oops
<cjwatson> http://paste.ubuntu.com/23815999/
<rick_h> ah ok cool
<rick_h> ignore me then there
<cjwatson> deploying from charm directory with no resources, same failure: http://paste.ubuntu.com/23816005/
<rick_h> cjwatson: k, yea have to file a bug and see if folks can trace what's different there. Nothing jumping out.
<cjwatson> it feels like there must be something wrong with the structure of my charm, but I can't see what
<rick_h> cjwatson: has this worked before on other controllers?
<cjwatson> this is a new charm, trying it for the first time - so no
<rick_h> cjwatson: gotcha, you tried charm proof on it?
<cjwatson> no icon.svg but it's otherwise happy
<rick_h> k
<cjwatson> is there any controller-side debugging that I can quickly bump up to maximum?
<stub> cjwatson: Just a wild arse guess, but is there a metadata.yaml in the charm directory and the name: is launchpad-importd ?
<cjwatson> there is
<cjwatson> aha
<cjwatson> 2017-01-17 12:17:01 ERROR juju.worker.dependency engine.go:539 "mgo-txn-resumer" manifold worker returned unexpected error: cannot resume transactions: The dotted field 'launchpad.tar.gz' in 'meta.resources.launchpad.tar.gz' is not valid for storage.
<cjwatson> so I need to call the resource something else
<cjwatson> I reckon charm proof should complain about that - sound reasonable?
<rick_h> cjwatson: +1
<cjwatson> https://github.com/juju/charm-tools/issues/300
<cjwatson> there, deploy starts doing something once I fix that \o/
<Zic> hi here, after rebooting a machine which is part of canonical-kubernetes charms master, "juju status" displayed that its flannel units is in error, I saw that '/run/flannel/subnet.env' is missing if I run a juju debug-log
<lazyPower> Zic - Sorry you encountered this, this was a bug in that release of CDK. its been patched in master and is pending a release
<Zic> lazyPower: oh, you again, I owe you a pizza :p
<lazyPower> Zic - you can resolve the unit in error by juju ssh'ing into that node, and restarting the flannel service manually before executing 'juju resolved kubernetes-worker/#'  where # is the unit # on the node.
<lazyPower> simple phaux paus of not enlisting the service as part of the startup chain.
<Zic> thanks, I have error in my Grafana endpoints and I presume it was about this Flannel error in my juju status :)
<Zic> I confirm it works, and my Grafana is totally repaired :)
<Zic> I owe you 2 pizzas lazyPower
<lazyPower> Zic Glad we could get it fixed up :)
<lazyPower> again, really sorry you were bit by that. regression in our release as of the last CDK publication.
<Zic> I was randomly rebooting some etcd & master/nodes to test all was rights since the last time you help me with my etcd quorum which was blocked :) all is working now, restarting Flannel is not a big problem
<Prob> juju doesnt work
<Prob> says: "Unable to find /home/Peter/.local/share/juju/accounts.yaml"
<lazyPower> Prob - Is this a first-run error message? Have you added credentials/bootstrapped a cloud?
<Zic> btw, I notice that with the nginx of kube-api-load-balancer, if I poweroff a kubernetes-master, there is no mechanism to pull it down from the upstream at /etc/nginx/sites-enabled/apilb for now?
<lazyPower> Zic yeah, we are investigating replacing nginx with haproxy for proper round robin / latency based load balancing
<lazyPower> we haven't started the work yet, but there's some early planning docs around it. the current charm in its current form is a stop gap and will be migrated to the haproxy based replacement when its ready.
<Zic> lazyPower: oh, it sounds great, I saw an issue in your GitHub which talks about replacing it by HAProxy but I didn't see it was really planned, great!
<Zic> when a Juju bundle charms is used, if the mainterner of this bundle switch a technology in one of the charms which compose the bundle, how it works for users?
<Zic> maintainer*
<lazyPower> Zic well, its up to the charm author to migrate data on charm upgrade. as a user you should only ever have to do juju upgrade-charm $charmname, and potentially at *most* tune some config or run an action to restore services.
<Prob> lazyPower, i just followed the steps on the website. i didnt set up anything other than than running the commands here: https://jujucharms.com/canonical-kubernetes/
<jcastro> can you do a `juju --version` and tell me what version of juju it is?
<lazyPower> Prob ^
<Prob> 2.0.2-xenial-amd64
<jcastro> does ~/.local/share/juju exist?
<Prob> yeah
<jcastro> stokachu: any idea here? ^^^
<lazyPower> Prob jcastro - one moment, let me spin up a fresh VM and try to reproduce. Our readme instructions changed last week to focus on the conjure-up installation method.  this might be an early-step thing that's unresolved/uncaught.
<Prob> just try it yourself, i bet nobody ever tested the localhost deployment
<jcastro> https://bugs.launchpad.net/conjure-up/+bug/1656229
<mup> Bug #1656229: conjure-up fails on fresh ppc64el xenial machine with 'Exception: Unable to find: /home/ubuntu/.local/share/juju/accounts.yaml <conjure-up:New> <https://launchpad.net/bugs/1656229>
<jcastro> I use the localhost one all the time
<jcastro> can you check /var/log/conjure-up/combined.log
<jcastro> and see if you get that ipv6 error?
<Prob> yeah i have the same error as the one in the bug report
<jcastro> sudo dpkg-reconfigure -p medium lxd
<jcastro> and choose no for ipv6, sec, I have a bug for this
<jcastro> https://github.com/conjure-up/conjure-up/issues/495
<Prob> i dont understand this weird GUI, what in the world is it doing
<Prob> it looks like im supposed to click on configure or deploy
<Prob> but i guess not because it says "bootstrapping juju controller in the background ..."
<jcastro> yeah use the arrow keys to the deploy buttons
<jcastro> and hit enter
<jcastro> then when the controller is done deploying it will move on to the kubernetes components
<Prob> the blocks keep jumping around
<jcastro> yeah that's a progress meter
<Prob> no i meant the gui in general
<Prob> ok its doing something now
<Zic> can I edit /srv/kubernetes/server.[crt|key] to replace it with mine which is signed by a public CA? or juju auto-deploy/replace it?
<lazyPower> mbruzek ^
<lazyPower> mbruzek - did we add support for self supplied certs? I think we did. but thats been a while ago... and we haven't tested it
<lazyPower> since then
<mbruzek> Yeah I am not sure that would work, we may have to take a look at the EasyRSA charm.
<lazyPower> Zic - i'm going to tentatively say not without some potential issues. we can bug that and get some cycles on testing that path
<lazyPower> Zic and if you would bug that, it would be great to get you updates via the bug.
<Zic> I can either replace /srv/kubernetes/server.[crt|key] or edit the /etc/nginx/sites-enabled/apilb to an other path which is not managed by EasyRSA, but I imagine this 'apilb' vhost is also "juju-ified"
<mbruzek> Zic: https://github.com/juju-solutions/layer-easyrsa/issues please file here.
<Zic> thanks
<lazyPower> Zic - yeah, all that is under management by the charm.
<Prob> how did you make a terminal interface with all these colors and complex gui?
<Zic> was just for "fancy", I doesn't really need a publicly-signed cert here, I will just open an issue for wishlisting and see for a next release, thanks anyway :)
<Zic> I prefer to not break what Juju do, I am always in PoC-mode and do not want to be too far from upstream configuration
<mbruzek> Zic: We modeled the self signed certificate creation and operation of the certificates with the easyrsa charm.
<mbruzek> Zic: We may need to modify some of that logic if you bring your own CA
<Zic> ok, and last question, I saw that in case I loose the machine or if I destroy (accidentally) the EasyRSA charms, the PKI/CA will be lost, what can I backup to preserve from this?
<jcastro> Prob: is it churning through the install now?
<mbruzek> Zic: You are correct if you lose the easyrsa charm you do lose pki. You can run some juju ssh or juju scp commands to save the certificates in /var/lib/juju/agents/easyrsa-unit-0/charm/EasyRSA directory. We have not done this work before, so there may be some trial and error needed here
<mbruzek> Zic: But I believe it is technically possible.
<lazyPower> Zic - can you file a bug rquesting backup capacity for the PKI on easyrsa?
<lazyPower> that would be a great contribution
<jcastro> I'll file it
<mbruzek> Zic: That sounds like a great idea of something to do, we just have not got around to it yet. That could be done with an action. If you file the request here: https://github.com/juju-solutions/layer-easyrsa/issues   We could follow up
<Zic> ok, thanks for you answer. jcastro do you file it so? I'm a bit of oldish style and do not have a GitHub account, I maintain my own code on my GitLab locally... but I will be glad to create one just for reporting issue anyway :p
<jcastro> filing now!
<Zic> thanks
<jcastro> but you should make an account so you can follow up, make sure the design of the feature meets your needs, etc.
<Zic> I will create an account anyway, as I add #juju as one of my permanent IRC channel :P
<Zic> yeah
<errr> if I make a charm that uses ansible, can I have the charm run from my ansible master machine that I call my deployment host where all my playbooks are or does it just install a copy of ansible on the host Im trying to provision and run a playbook on what would end up being localhost?
<Prob> I HAD TO ABORT THE INSTALLATION BECAUSE MY DISK WAS FULL AND NOW WHEN I TRIED TO RESTART IT NOTHING HAPPENS AND IT'S LOCKED FOREVER
<Prob> I CANT DEAL WITH THESE CONSTANT PROBLEMS WITH UBUNTU ANYMORE IM FLIPPING OUT
<pmatulis> Prob, ?
<errr> http://www.popfi.com/wp-content/uploads/caps-lock-key.jpg
<jcastro>  https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/196
<lazyPower> errr - we piloted ansible integration in charms, the incantations we came up with are using ansible against localhost
<errr> lazyPower: is that the only way or is it possible to have the playbooks run from my ansible master machine?
<lazyPower> errr to date, thats the only way. there's an opportunity to hack on  a POC and engage around that style of integration. but i'm not certain what dragons be in that path.
<errr> thanks lazyPower :)
<lazyPower> errr no problem :)
<Prob> for the love of god, throw this weird terminal interface away and make a real one
<Prob> a normal one
<Prob> the mouse is blinking but nothing happens. how am i supposed to know what is going on?!
<Prob> here is a suggestion: write the log in the current directory, so i dont have to search for it. call it installer.log.
<pmatulis> Prob, at a very high level, what are you trying to do? are you in the correct IRC channel?
<Prob> pmatulis: I'm in the conjure-up installer for kubernetes-canonical
<Prob> the installer is REALLY weird
<Prob> i click around and then stuff starts to happen
<pmatulis> Prob, sounds normal. maybe open a bug with specifics
<Prob> my problem is that the installer is horrible in general
<Prob> it looks nice on first glance but it's a usability nightmare
<pmatulis> again, "horrible" is too vague. just cool down and open a few bugs. do you know where to do that?
<Prob> im not gonna open any bugs, you wont fix them anyway
<errr> as a software developer who mostly does opensource work I can say thats not how I work and I highly doubt this team does that either
<stormmore> How do you know if you don't file the report?
<stormmore> (disclaimer: I don't work for Canonical but do believe in speaking up if you have a problem - no IRC isn't ideal for that, just a good place to determine where)
<errr> you should take a break, go have a cup of coffee and calm down, then come back and trying asking for some help agian and without bashing the work of the people who will be helping you..
<pmatulis> Prob, here you go: https://github.com/conjure-up/conjure-up/issues/new
<Prob> what am i supposed to say, "hey, it's not clear whether i should use the mouse or keyboard". The problems start at step -1000
<errr> yeah.
<errr> dont start with "the installer is horrible"
<errr> "Its a bit unclear if this is an interactive installer that requires the use of my keyboard or my mouse.. Does anyone know or should both work?"
<errr> try to remember you are talking to other people.. not machines.
<errr> there is an old saying my grandpa used to use "you cath more flies with honey than vinegar"
<stormmore> shame dear old grandpa didn't learn that you apparently catch more with manure ;-) but otherwise that idiom is awesomely correct
<errr> well on the ranch and farm manure is a good thing :)
<perrito666> actually you just atract them with manure, honey will make them stick
<stormmore> and that is how problems are solved ;-)
<perrito666> anyhow, Prob I understan your frustration, software has driven me to the point of wanting to go postal on the devs but please do understand we are doing our best here, which sometimes is not enough, most people here is willing to go along the way to help you solve your problem and perhaps gain some insight on what we did wrong to improve, but please lets not set aside politeness and basic human relation codes
<jcastro> I use the arrow keys and enter to navigate the UI
<jcastro> it's similar to the curses UI of debconf and other TUI tools
<stormmore> but anyway Prob be a detailed as you can, otherwise expect to get questions asking for more detail
<Prob> the errors keys dont work properly at all
<Prob> i press the sideways error to get to the "deploy" option and it switches to a different screen? what the hell?
<Prob> i didnt even press enter yet
<jcastro> what terminal are you using?
<Prob> bash i guess
<jcastro> no like your terminal program, is it the default gnome-terminal or something else?
<marcoceppi_> Prob: Since you've had a tough time of it on LXD, we can provide some AWS credentials that allow you to spin up a few machines using conjure-up / juju and offload the stress from your mahcine to the cloud
<Prob> i created this issue now: https://github.com/conjure-up/conjure-up/issues/584
<marcoceppi_> Prob: we will absolutely be fixing the install experience, but I want you to try kubernetes
<Prob> i dont see how that would help a lot, i still have to use this weird installer
<marcoceppi_> Prob: well, there are alternatives, as there are to many things
<vmorris> does juju-deployer work with juju 2?
<marcoceppi_> Prob: if the installer workflow doesn't work for you, you can just use the raw commands underneath that installer
<lazyPower> vmorris - its been updated to work with juju-2, yes.
<marcoceppi_> Prob: we'd want the installer to make as much sense to everyone, including you, so your feedback thus far has been fantastic
<vmorris> lazyPower, thanks
<lazyPower> np
<Prob> i only made the bug reports because you all seem interested enough to fix it, but i wont be using this juju stuff for now. Doesnt seem to work at all and i dont want to get locked into ubuntu exclusive stuff anyway, i just wanted to quickly try this out and nothing worked, so that's it
<tvansteenburgh> vmorris: fyi the latest juju-deployer is in ppa:tvansteenburgh/ppa
<jcastro> Prob: do you have a disk with more space on it?
<vmorris> tvansteenburgh: oh heh, okay.. going to get this updated soon? https://pypi.python.org/pypi/juju-deployer/
<tvansteenburgh> vmorris: yeah, can do
<bdx> Prob: you didn't try Juju specifically though, you used a wrapper program that unfortunately gave you grief
<bdx> Prob: I suggest just giving juju itself a try, I think you will find it quite pleasant
<Prob> i thought this is juju
<bdx> Prob: conjure-up is a wrapper around Juju
<bdx> Prob: and is a really neat tool, its unfortunate you didn't get the same experience I had with it
<Prob> idk it seems like a poorer version of kubernetes, id rather just manage to install kubernetes
<errr> the naming in juju and around it remind me of sorcerer linux
<bdx> Prob: ehhh ..... if you have your machine provisioned correctly (adequate disk, cpu, and ram), the Juju kub experience is really awesome
<errr> was anyone who came up with the name of juju or its other parts like charms and conjure sorcerer linux users?
<lazyPower> errr that would be SABDFL himself
<bdx> Prob: I can `juju deploy kubernetes-bundle`
<lazyPower> i dont think he was.
<lazyPower> but who knows, he's had a long walk in life with linux. he potentially did use sorcerer linux.
<errr> just the whole casting spells to install stuff is what made me think of that
<Prob> bdx, what's the point if i cant run the same thing in production anyway. i just wanted to try kubernetes real quick but in reality i would need to dig deeply into this stuff i think
<bdx> Prob: you can though ...
<Prob> i typed "juju deploy kubernetes-bundle" and nothing happens for 3 min now
<bdx> Prob: my bad ... `juju deploy cs:bundle/canonical-kubernetes-19`
<lazyPower> correction on that last one too
<lazyPower> juju deploy canonical-kubernetes
<lazyPower> is all you need
<Prob> that doesnt exactly bode well.. would be nice to know what it is doing
<lazyPower> unless you're targeting LXD, in which case that deploy will fail fantasticaly, because there are profile edits on the lxd containers conjure-up is tweaking
<mbruzek> Prob: It can do different things on different clouds. I am able to use those commands on AWS and GCE, and Azure, but on your local laptop it requires a few more commands which conjure-up is wrapping. So if you targeted LXD you need to use conjure-up to deploy that bundle. And as you mentioned it does take up disk space to deploy locally.
 * rmcadams yawns
<stokachu> Prob, im one of the main developers on conjure-up
<stokachu> Prob, feel free to file bugs if you have problems and we'll get them addressed
<Prob> mbruzek, I'm not targetting anything, im running a console command with no clue what it's doing
<stokachu> Prob, i assume https://github.com/conjure-up/conjure-up/issues/584 is you?
<stokachu> we've answered those bugs within 3 minutes of you posting it
<rmcadams> I <3 Juju
<lazyPower> rmcadams we <3 you too
<Prob> i still dont get what exactly juju does, is it replacing ansible or kubernetes, is it using docker or lxc? kubernetes only works with docker i think
<rick_h> Prob: Juju is doing the work to bring up the components needed to run and operate kubernetes on any substrate that Juju supports, which includes public clouds, private clouds (MAAS/OpenStack), and locally for development/testing (lxd).
<rick_h> Prob: if you go through the kubernetes install/setup steps, it's a baked alternative to that how-to basically
<rick_h> Prob: it does not replace Kubernetes, it's getting you one that you can use up and running.
<rmcadams> +1
<Prob> rick_h: that would be good, but it's lock-in right? i can only use this on ubuntu?
<rmcadams> CentOS, Windows etc..
<rmcadams> RHEL
<rick_h> Prob: no, the Juju client works on Ubuntu, OSX, and Windows. You can initiate the deploy from many platforms. If you want another one, it's a compiled Go binary and not too painful to build.
<rick_h> Prob: for the deployment end, yes, the current charms (the things doing the deploy/operating of the component) are on Ubuntu.
<rick_h> Prob: someone could come along and write those for centos/window if they were inclined
<rmcadams> https://cloudbase.it/juju/ is pretty slick
<rick_h> Prob: so there's a different between being locked into Juju and locked into Ubuntu. Juju is definitely built and most use is on Ubuntu, but it's far from locked in.
<rick_h> Prob: and at the end of the day, you're ending up with VMs on clouds running software. If you decide you want to change/move things it's all there with your ssh access to it.
<rick_h> Prob: we think that Juju brings a lot of value in operating things, but it's not like you lose access to your VMs if you decide not to use Juju.
<Prob> yeah but now i cant google the kubernetes docs because now it's hidden behind some juju stuff, that's always a danger when you abstract away i guess
<jcastro> sure you can, the kubernetes docs include juju
<jcastro> once your cluster is up and running you don't really need to use juju unless you're adding hardware or doing backups
<rick_h> Prob: yes, abstractions on the one hand help simplify things, and on the other hand feel like they're taking control away. However, Juju as an abstraction hides less than it seems due to the transparency of the charms (open them up and see what they do) and the root level access to the VMs you retain
<rick_h> Prob: I mean are you less "locked in" than with kops or puppet, or other install/operation tools
 * rick_h runs to a call but let me know if you have any questions or concenrs Prob. Happy to help.
<Prob> "juju deploy canonical-kubernetes" does absolutely nothing for me, i added 40gb more to my ubuntu VM now btw
<cory_fu> tvansteenburgh: Did you see my update last week on https://github.com/juju/python-libjuju/pull/46 ?
<cory_fu> I'd really like to get that simplified example working cleanly
<tvansteenburgh> cory_fu: yeah i saw
<cory_fu> tvansteenburgh: Any thoughts on why I still get errors?
<bdx> Prob: do you have the local lxd provider bootstrapped?
<Prob> bdx: no idea
<tvansteenburgh> cory_fu: well to put it simply, because it's not a clean shutdown. i was working on it Friday but ran out of time
<tvansteenburgh> task.cancel itself is async. it'll return immediately even thought the task may not be stopped yet
<tvansteenburgh> so the loop gets stopped while a task is still being exec'd by run_until_complete, which causes a RuntimeError
<tvansteenburgh> i have other async programs that shutdown cleanly with Ctrl-C though, so it's not like it can't be done
<Prob> juju finally errored out: pc@ubuntu:~$ juju deploy canonical-kubernetes ERROR unable to connect to API: websocket.Dial wss://10.91.98.135:17070/model/4429dd01-9b51-4722-88f6-43dac626c571/api: dial tcp 10.91.98.135:17070: getsockopt: no route to host
<Prob> i can reach websites just fine
<cory_fu> tvansteenburgh: Yeah, that's kind of what I thought.  I was wondering if you could point me to your other example that works cleanly?
<rmcadams> Prob: sounds like your LXD configuration may be not working
<Prob> i barely know what LXD is and I certainly didnt configure it to do anything
<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> I got this when trying to do a juju add-unit
<rmcadams> Prob: sorry feeding the kid, be back in a few
<lazyPower> spaok what version of juju?
<errr> fyi the link in the /topic for the Summit doesnt work http://downforeveryoneorjustme.com/http://summit.jujucharms.com
<spaok> lazyPower: 2.0.2-xenial-amd64
<ryebot> Is there any means of changing the juju process's runtime environment variables?
<ryebot> i.e., I'd like to add LANG=blah to the environment during charm installation
<lazyPower> ryebot - only if you add it via config, and set the charm to add that at runtime. Elsewise you'll have to set that ENV var in your layer code.
<jrwren> ryebot: afaik, the charm would need to be updated to support this. There are probably some hacks you could do to work around it if you need it only one time.
<lazyPower> afaik theres no support for abritrary env vars via model-config or other mechanism than charm hacks.
<ryebot> hmm, I -think- I need it outside the charm logic, since I need it set during installation of python packages
<ryebot> (from wheelhouse.txt)
<lazyPower> ryebot seems like we could add support for that, but it would likely need to be in layer-basic
<ryebot> lazyPower: yeah, was just looking in that very direction
<ryebot> some kind of "env" config?
<lazyPower> yeah, and since thats more than a build time construct, you'd want to add that to config and funnel it down
<lazyPower> eg: why do i also get EN if i'm IT
<lazyPower> s/also/always/
<bdx> lazyPower: can you apply the lxd profile edits needed for kubernetes to deploy to lxd to the lxd profile manually?
<bdx> lazyPower: such that you could run `juju deploy canonical-kubernetes` in the model to which you have applied the profile edits needed for kub the kub bundle to deploy to lxd
<lazyPower> you can do it manually, but thats a big ask for end users
<lazyPower> the template is available in teh spell, 1 sec while i grab you the link
<bdx> lazyPower: thx
<lazyPower> https://github.com/conjure-up/spells/blob/master/canonical-kubernetes/steps/lxd-profile.yaml
<lazyPower> bdx ^
<mmcc> bdx: you could probably run the 00_pre-deploy script manually
<bdx> mmcc: nice
<mmcc> it's in the same dir, that's all conjure-up is doing
<bdx> thx
<mmcc> it expects an env var "JUJU_PROVIDERTYPE" but just set that to "lxd"
<bdx> ok
<bdx> mmcc: thx
<mmcc> it also expects that the currently selected juju controller/model is the one whose lxd profile you want to change
<bdx> entirely
<spaok> is there a way to tell juju to add a specific machine as a unit? like if I was doing juju add-unit compute -n1 normally, does juju add-unit --to "MAAS system_id"  work?
<mskalka> spaok, the --to works with add unit the same way it does with deploy
<spaok> mskalka: I tried to --to against a system_id but it didn't allocate and deploy the node, I've done it before with the hostname but that was 1.25 juju
<spaok> I think we found the problem I was having so I'm going to wait for support to call
<beisner> spaok, in the past, i've used maas tags and juju constraints to make sure applications landed on the intended metal.
<beisner> there may be other ways, but that is an explicit and effective approach
<spaok> ya we normally do that, but because I wanted to test not using LACP and only configured one node, and I have a pool of 11 others in ready state, I was trying to target just the one with the active-backup config
<spaok> I could mark all the others as broken
<beisner> spaok, or add a FOO tag to the 1 machine in maas as a temp/bespoke exercise.
<spaok> ya true, good idea
<beisner> it seems like there is maas machine uuid 'way' to do this though (i may be dreaming)
<spaok> I figured the id was the way since the juju status doesn't show hostnames anymore
<spaok> just system ids
<jhobbs> the only way to do it on juju2 is with tags
<beisner> thx jhobbs :-)
<jhobbs> for bootstrap you can use --to <hostname>, but not for anything else
<mskalka> huh, TIL
<jhobbs> we tag all our machines with their hostnames
<beisner> curious jhobbs, do we have a LP bug to track that, even if as a wishlist/feature req?
<jhobbs> i don't know beisner, i've been told repeatedly by rick_h it's not a bug
<beisner> any time the same object has the same value set to two properties, there be funk.
<beisner> i consider that a bug
<jhobbs> they don't want to support constraints that only apply to a single provider
<beisner> i see
<beisner> jhobbs, so i'd ask then:  isn't "tags" a maas-only provider constraint?
<jhobbs> https://bugs.launchpad.net/juju/+bug/1554120 we do have a bug for it
<mup> Bug #1554120: juju 2.0 bundle support: Missing constraint support for maas names to support bundle placement <juju-release-support> <oil> <juju:Triaged> <https://launchpad.net/bugs/1554120>
<jhobbs> feel free to pile on
<jhobbs> i agree with you, i think the two fields that need the same value thing is a bigger problem
<jhobbs> if they find it's a common enough pattern maybe they'll support it
<beisner> right.  i see three power users with the need atm.  thanks jhobbs
<stokachu> make that 4
<stokachu> but i understand why they dont do it b/c of resuability
<stokachu> juju knowing to much about the provider
<stokachu> but yes it'd make our use case a lot easier
<vmorris> tvansteenburgh, beisner: trying to get juju-deployer to work with a manually bootstrapped cloud, not having much luck getting started. i did add ppa:tvansteenburgh/ppa but juju-deployer doesn't seem to want to update
<vmorris> does "apt" not work with ppa's? need to use "apt-get"?
<jrwren> no, apt works with PPA
<jrwren> vmorris: if you didn't use -u with apt-add-repository, you'll need to apt update to refresh package cache
<vmorris> jrwren, okay thanks.. no it's not that, now i'm seeing that the version number is just wrong i think
<vmorris> i did install from the ppa after all, but the version number in the command output shows juju-deployer==0.6.4
<spaok> beisner: Danny got me fixed, issue was we added new networks to MAAS and the spaces show there but juju didn't know about them
<spaok> had to add them
<beisner> spaok, sweet.
<mmcc> jhobbs: thanks for the pointer to that bug about maas name constraints, I've added the conjure-up perspective (cc stokachu )
<jhobbs> cool mmcc
<stokachu> mmcc, nice
<beisner> jhobbs, ha!  oops, sorry didn't mean to remove your lp tag there
<bdx> fyi, you can add network spaces to your controller model, and use them as constraints when you `enable-ha` -> http://paste.ubuntu.com/23818671/
<lazyPower> ^
<lazyPower> oh, i had a scrollback issue, was ^'ring at beisners comment.
<lazyPower> and what bdx said, because thats handy info
<rmcadams> is there an easy way to restart a service container with juju?  ie:  RabbitMQ
<lazyPower> rmcadams - juju run --application rabbitmq "shutdown -r now"
<rmcadams> have I told you that, you are indeed a hero lazyPower ?
<lazyPower> rmcadams - dont put me on a pedestal, there's nowhere to go but down from there ;)
<lazyPower> but i'm happy i can help.
<rmcadams> :)
<rmcadams> for some reason, in my lab, this openstack deployment, rabbit is not happy
<lazyPower> rabbit does seem to be one of the more finicky charms in the stack. I may be recalling old threads, but it was the one that warranted the most curse words iirc.
<Prob> i just dont get it, the juju gui has an option to detroy an application. I click it. It says "this application has been marked to be destroyed on the next deployment". Ok fine, so I write "juju deploy cassandra" butu it says ERROR cannot add application "cassandra": application already exists"
<Prob> btw i did not find a cmdline option to destroy an pplication
<cmars> Prob, in the CLI, you'd do `juju remove-application cassandra` to get the same effect
<Prob> yeah i tried that, didnt do anything
<Prob> i also dont understand why it's called "remove" instead of "destroy" like the others
<cmars> Prob, when you remove an application, it fires off some events as a result of the change in the model: relations depart and the stop hook eventually fires.
<cmars> Prob, sometimes it takes a little bit for the application to completely go away as a result. you can watch `juju status` to see this in action
<Prob> why does it say "on next deploy"? what does that even mean?
<cmars> Prob, that could be better. it should say "marked to be destroyed when changes are committed" imo
<Prob> well i did that already
<cmars> Prob, yeah, removing applications in the GUI is awkward, i don't disagree with you. would you be willing to open a bug? https://github.com/juju/juju-gui/issues
<cmars> Prob, i see what you mean, you have to deploy to destroy? lol wut? :)
<cmars> i think we meant to say "commit" there
<Prob> it's not just that either, why is it called "application" but on "juju status" it's called "App"
<cmars> well, terminals are only so wide... brevity? :)
<Prob> it still isnt deleted, it just wont delete...
<Prob> it wont install successfully either, just btw. it stays on "maintenance"
<cmars> Prob, any errors when you run `juju status`?
<Prob> no
<cmars> Prob, that's weird. which charm was this, exactly? do you have the charm URL, or the command you typed to deploy it?
<bdx> Prob: sometimes, if applications get "stuck" you might need to result to the command line to resolve removing the application sometimes
<bdx> newrelic-sysmond primary I just busted out for controller monitoring https://jujucharms.com/u/creativedrive/newrelic-sysmond-primary/1
<bdx> it allows you to do this http://paste.ubuntu.com/23818941/
<cmars> Prob, there is a way to hulk-smash an application into oblivion as well. force remove the assigned machine and then the application will surely die
<cmars> should be done with care... if you've co-located other applications on that machine, you wouldn't be happy
<bdx> Prob: something like `juju run --machine <#> "sudo rm -rf /var/lib/juju/agents/unit-<application-name>-<application-number>"
<bdx> Prob: then `juju resolved cassandra/<#> && juju remove-application cassandra`
<cmars> Prob, i've opened https://github.com/juju/juju-gui/issues/2331 for ya
<Prob> bdx: that worked, but maybe wrap that in a "force remove" button and cli option.. would be good
<bdx> true true
<rmcadams> yah, Rabbit is really not a happy charm ;)
<bdx> rmcadams: it gets so much love though
<rmcadams> oh it's not a matter of love, I've deployed the OpenStack bundle now a few times and the only thing I ever have trouble with is Rabbit
<bdx> right ...
<bdx> rmcadams: are deploying multiple rabbit units on lxd across multiple host using the maas provider?
<rmcadams> using maas - it deploys on 4 physicals using lxd for rabbit
<bdx> rmcadams: "it" - ?
<rmcadams> juju
<rmcadams> I'm using Juju against maas.  Juju queues up 4 physical boxes and then slices them up into containers for the services.
<bdx> I know there has been alot of work that has gone into making rabbit ha work nicely
<bdx> I feel your pain though ... rabbit ha has bitten a few of my deploys ... is it still acting up for you, with the latest version of the charm and maas and juju?
<rmcadams> it is
<rmcadams> destroying and rebuilding now, to see if I missed something, but I'm 99% sure it's not even HA in the latest version of the bundle
<rmcadams> I'm just using the default bundle
<rmcadams> for my lab
<bdx> rmcadams: my fix, when I was hitting issue with rabbit ha, was to only initially deploy 1 unit of rabittmq, and then add the other units by hand post deploy
<bdx> ahh gotcha
<bdx> you might want to ensure the bundle you are using has the latest version of rabbit pinned to it
<bdx> can you link me to your bundle?
<rmcadams> https://jujucharms.com/openstack-telemetry/
<rmcadams> sure enough, it's 1 instance of rabbit
<bdx> rmcadams: what happens (and what is happening here), is that the bundles aren't always updated with the latest versions of the charms ...
<bdx> that bundle might fall behind to some extent bc its not the primary openstack bundle I don't think
<bdx> but either way
<bdx> pull down the bundle.yaml to your local machine
<rmcadams> sure, I've got it
<bdx> and make sure the charm versions match the current stable release versions
<bdx> e.g.
<bdx>     charm: cs:xenial/rabbitmq-server-54
<bdx> should be
<bdx>     charm: cs:xenial/rabbitmq-server-57
<bdx> you should do this for all of the charms
<bdx> and we should get bundles added to the openstack charm release cadence
<bdx> such that they are kept up to date
<bdx> beisner: ^
<rmcadams> Yah, that would be nice, for sue.
<rmcadams> errr sure
<rmcadams> too bad there's not a button on Juju to say "pull latest charm versions"
<rmcadams> or "show out of date charms"
<bdx> rmcadams: yeah, in the gui there is an 'upgrade-charm' signification of some sort
<bdx> but upon initial deploy ... yeah, it would be cool to just say "use latest"
<beisner> bdx, we rev up the bundles with each ~quarterly stable release.  beyond that, the "-next" dev bundles will always pull dev/bloody charms
<rmcadams> yah, I think you can pick the version after its deployed right?
<bdx> beisner: gotcha, nice
<bdx> beisner: how does one deploy the -next bundles?
<beisner> so that'd be openstack-charmers for stable, and openstack-charmers-next for development (next), in terms of charm store name spaces.  ex:
<beisner> https://jujucharms.com/u/openstack-charmers/  vs  https://jujucharms.com/u/openstack-charmers-next/
<rmcadams> So here's an interesting question, can you pull down the latest charm on the canvas and just drag/drop it in place and will it assume all of the appropriate relations?
<bdx> rmcadams: you can, but you might want the updates from the latest charm for the features that could facilitate the initial deployment of the charm as well
<rmcadams> editing the yaml is fine, I'm just curious
<rmcadams> also, beisner - how do you pull -dev?
<beisner> rmcadams, see bundle yamls @ https://jujucharms.com/u/openstack-charmers-next/
<rmcadams> look at that!
<beisner> fwiw, we don't leverage charm store channels with the openstack charms yet, as we must continue to test and support production deploys on 1.25.x, and 1.25.x isn't channel-aware.  so, our long-standing use of these two charm store namespaces will be around for some time.
<rmcadams> ahhh, that makes sense - we're looking  @ Canonical for one of our next clusters, hence my tinkering... good to know
<beisner> keep in mind, -next are dev versions, and as such, are subject to pain.
<bdx> beisner: ahh, I see ... so rabbitmq has rev'd 3 times since the last charm release from 54 to 57, thats why 54 is still in the stable bundles?
<rmcadams> pain is good ;)
<beisner> bdx, correct.   but:  we intend to eventually rev up the stable bundle any time a stable charm revs up.  everything else is auto-magic wrt the charm revs in cs:... just not the stable bundle.
 * beisner -> eods
<beisner> o/
<rmcadams> so given that the bundles are 'zips' which include files other than the yaml, what's the best way to update and import a bundle?
<bdx> beisner: nice, thx
<bdx> rmcadams: its not a zip ... it just will download as one
<rmcadams> ahh, got ya
<bdx> the bundle  is basically the bundle.yaml
<rmcadams> sure, as an example, openstack has neutron-ext-net neutron-tenant-net and novarc files
<rmcadams> so what's the best way to get all that back into a canvas (or command) to make it all work appropriately?
<bdx> yea .... those are just helpers for the end user to use to facilitate openstack network provisioniner
<bdx> provisioining once openstack is deployed
<rmcadams> ahh, roger
<rmcadams> just making sure, the whole juju deployment process is new for me, hence my tinkering
<rmcadams> I've deployed OpenStack many, many times... just making sure I dont break something by doing it with juju
<bdx> I'm not sure how to make the charmstore aware that its a bundle and not a charm ..
<rmcadams> I honestly can't imagine how much work has gone into all of this
<bdx> rmcadams: possibly the charmstore just recognizes the bundle.yaml and assumes a bundle
<rmcadams> having done these deployments myself, as I said yesterday the way it works with juju is mind melting for me
<bdx> rmcadams: alot of people care alot about making Juju awesome - thats how
<rmcadams> Yah it's pretty obvious, theres a ton of dedication that's gone into this
<bdx> rmcadams: yea, I've deployed openstack in a miriad of ways too ... Juju takes the cake hands down
<rmcadams> Piston was the easiest openstack I've ever deployed, but it was very "curated"
<rmcadams> which made it a pain... but it orchestrated everything for you from the hardware up
<bdx> rmcadams: I'm sure you will start to see and appreciate some of the finer aspects of the Juju openstack once you dig in a little deeper
<bdx> rmcadams: the openstack charms handle openstack upgrades
<rmcadams> oh I'm a big fan of what I've seen so far, the fact that maas handles all that ti does has saved me countless trips up and down the stairs
<rmcadams> if only maas could handle multiple hosts running virsh, it would be perfect!
<bdx> rmcadams: having the capibility to spin up and down new units of an openstack service at will in lxd containers across your hardware is so key too
<bdx> rmcadams: it does
<rmcadams> actually it does not, I confirmed it in #maas and we opened a bug
<bdx> really?
<bdx> link?
<rmcadams> https://bugs.launchpad.net/maas/+bug/1656091
<mup> Bug #1656091: Power Settings for virsh are not per node, they are global <docteam> <MAAS:New> <https://launchpad.net/bugs/1656091>
<bdx> ehh, I don't have a maas at my disposal atm, but this seems strange, I'm sure I've done that before ... possibly it was with an older maas though ....
<Prob> why does nothing work out of the box here, i cant even log in: charm push . "test"> ERROR cannot retrieve current username: cannot get discharge from "https://api.jujucharms.com/identity/v1/discharger": cannot start interactive session: cannot get user details for "https://login.ubuntu.com/+id/JTArhzd": not found: not found
<bdx> do you use the "add chasis" ?
<bdx> Prob: you need a launchpad account
<Prob> on the ubuntu page it's telling me that i cant change my username because i have to change it on my launchpad account, so i assume i have one
<bdx> Prob: `charm whoami`
<Prob> not logged into https://api.jujucharms.com/charmstore
<bdx> Prob: `charm login`
<Prob> ERROR login failed: cannot get user details for "https://login.ubuntu.com/+id/JTArhzd": not found: not found
<bdx> Prob: https://launchpad.net
<bdx> create an account there, then use those creds for `charm login`
<bdx> rmcadams: from what I remember, if you add a chasis (and specify the virsh creds for that chasis), maas will pick up all the vms provisioned on that chassis* and add them to your nodes
<Prob> i did: https://launchpad.net/~trustthesky
<Prob> thats me
<Prob> created 2011
<bdx> rmcadams: I could be entirely off here though too
<bdx> Prob: use that username when you `charm login`
<Prob> i used the same email
<Prob> its not asking for username on 'charm login'
<bdx> oooh
<Prob> its asking for some kind of 2-factor, i dont have that i think
<bdx> Prob: just hit enter to accept the default of 'none'
<Prob> yeah i did
<Prob> i think it's broken
<bdx> Prob: rm ~/.go-cookies
<bdx> Prob: ensure you can sign into https://jujucharms.com
<bdx> Prob: if you can sign in there^ then the charm command will authenticate
<rmcadams> I'll check it in a few, helping son build his trains :)
<Prob> bdx: ok suddenly it worked, maybe it was the cookies removal
<Prob> and me logging into the launchpad agian
<Prob> idk
#juju 2017-01-18
<rmcadams> ok bdx - back - so you think doing an 'add chassis' might be the differentiator to fix this eh?
<bdx> rmcadams: possibly
<rmcadams> deploying these two big nodes right now to test it out
<bdx> rmcadams: a quick search turns up http://askubuntu.com/questions/663771/how-to-configure-maas-to-be-able-to-boot-virtual-machines-via-vmware-type
<bdx> see the first answer
<bdx> rmcadams: do you know how to use cloud init with virsh?
<bdx> rmcadams: its worth looking into .... you can create a user-data file, and use that in combination with an ubuntu cloud image to create your vms on demand, instead of installing the os etc etc
<rmcadams> honestly we havent done much with cloud init and virsh, I know you can boot instances with it etc... but we typically boot the virsh instances up to RedHat OSPD right now.
<bdx> nice nice
<rmcadams> it is nice, but it doesnt afford me the opportunity to "do more" like maas ;)
<bdx> ahhh yeah , I was just thinking if you are wanting to create vms on those hosts on demand and check them into maas
<bdx> http://blog.oddbit.com/2015/03/10/booting-cloud-images-with-libvirt/
<bdx> ^ is a nice read if you are interested
<bdx> rmcadams: possably we are talking about different things .. my impression was that you wanted to deploy 2 hardware nodes with maas, then create a bunch of virtual machines on those hosts to check into maas
<rmcadams> I do
<rmcadams> so as an example, rather than spending a bunch of $ on hardware
<bdx> exactly, ok
<rmcadams> we build 4 infrastructure nodes
<rmcadams> and build the application vms we need
<rmcadams> like openstack director
<rmcadams> sdn controllers etc
<bdx> totally, I use to have a test lab that had a few of different setups that were just like that
<bdx> you can totally do that
<bdx> where I found some pain points was
<bdx> getting the virsh vms all created and checked into maas
<rmcadams> I wrote an ansible script for that
<bdx> you need to ensure you provision the vms on a bridge that maas can provide dhcp through
<bdx> ok
<bdx> on top of that copying images around is messy, and creating the vms from isos is time consuming
<rmcadams> you know it!
<rmcadams> is that blog post above yours?
<bdx> by using the cloud init userdata as a mounted iso, you can go from 0 to running instance in a fraction of the time
<bdx> I didn't write it, but I remember it was the same post I found that led me to the solution I was after when I was figuring all this out
<rmcadams> ya
<bdx> the only gotcha about using the user-data, is you have to create a different config.iso specific to each instance, bc the meta-data contains instance-id: my-instance-id
<bdx> local-hostname: my-host-name
<bdx> Y
<bdx> when you gen the config iso, you have to feed it the user-data and meta-data, so you end up with a config.iso for each vm
<rmcadams> another thing that would be super nice, is if you could copy and paste config templates from 1 node to another node
<rmcadams> since most of us deploy with repeatable hardware
<bdx> yeah ... another thing you could try to make this faster
<bdx> juju bootstrap your maas
<bdx> deploy those two hardware nodes with juju
<bdx> then just add a bunch of kvm to them with juju
<rmcadams> so yah, I thought about that
<rmcadams> one of my Canonical sales engineers told me that
<bdx> then add the chassis in maas once it hass all the vms
<bdx> idk ...
<bdx> ha
<stormmore> I am still trying to figure out the best way to bootstrap an einvironment so that the maas-region and maas-rack controllers become part of the platform instead of separate
<pmatulis> stormmore, back up a bit. at a higher level, what are you trying to do?
<stormmore> put the maas controllers on managed hosts probably in LXD containers on the admin model
<stormmore> pmatulis I know the steps just wondering if there is a better way
<pmatulis> stormmore, MAAS should already be set up, you then connect juju to MAAS
<pmatulis> stormmore, or are you trying to install MAAS with juju?
<stormmore> that is what I am thinking might be ideal... the end state would be not to have a dedicated machine for maas in the environment
<pmatulis> stormmore, and how have you tried installing MAAS with juju?
<stormmore> right now the plan is to bootstrap using a dedicated maas controller, then bootstrap juju, deploy maas-region and maas-rack charms, mitgrate the db and decon the machine
<pmatulis> stormmore, what command will you use to install MAAS with juju?
<stormmore> tbh haven't really tried too much since I am using the maas controller install direct from the ISO
<pmatulis> stormmore, that's what i am getting at. i don't believe there is a maintained juju way to install MAAS
<stormmore> there is a charm for maas-region, doesn't look official but it does mean to bootstrap an environment becomes a multistep process for now
<pmatulis> well, i would advise to stay away from it
<pmatulis> there is no obvious benefit to balance the risk and heartache
<stormmore> I disagree since having the maas services spread in the cluster removes the need for dedicated hardware for something that is not necessarily used that much
<stormmore> ideal I would move the maas-rack-controller components onto the switch hardware and put the maas-region-controller components on the same node as the juju-controller
<rick_h> stormmore: so I think the way you can get around this a bit is to basically setup control nodes with manual lxd containers and get the components going, a juju controller, install maas, register those lxd containers into the maas, and then go from there
<rick_h> stormmore: there's some thoughts longer term about being able to share a controller on the metal, the cloud put onto that metal, etc. So that you've got one control plane for several layers as long as they're on the same physical network
<rick_h> stormmore: but it's not there atm
<stormmore> rick_h: right now I am thinking of dedicating a bootstrap machine for maas services and as part of the overall environment bring up move all the services using juju deploy <charm> even if I have to write a charm for it ;-) then I can "reboot" the bootstrap system and add it too
<stormmore> I want to get to the point that the region and rack controllers are in different spaces and thus remove a NAT rule on my router
<rick_h> stormmore: do us a favor and write to the juju list on how the experiment goes. I'm always curious how folks are looking to put parts together.
<stormmore> rick_h for sure :) I still like the idea of putting the rack controller on the switches but that is me just daydreaming and I know it
<rick_h> well I think that's still the goal in life. A world of snap enabled switches and maas as a snap :)
<rick_h> I think it'd be pretty cool to run a small home router with maas on the router myself
<rick_h> need those ubuntu/snap devices to go forward
<stormmore> yeah that would be kinda cool :) I am just not sure about storing the db on the switch/router
<rick_h> yea, but at the same time how much data is in there really?
<rick_h> $backups$ :P
<stormmore> rick_h do you know if there is any thought being put into 'multi-region' maas or am I missing something
<rick_h> I thought maas was multi-region already?
<stormmore> it is but not in the same way aws is as far as juju is... either that or I am missing something in my configuration
<stormmore> juju sees*
<rick_h> https://bugs.launchpad.net/juju/+bug/1600061 is what got me thinking
<mup> Bug #1600061: Expect multi-region MAAS clouds <maas-provider> <juju:Triaged> <https://launchpad.net/bugs/1600061>
<rick_h> there was some work around this in the new add-clouds interactive bits in 2.1beta
<stormmore> well it is on the backlog then :)
<rick_h> but not sure if juju now supports fully that
<stormmore> oh I can work around it for now... happy it is at least in the backlog
<stormmore> oh and I agree for a home setup putting the db on the router makes sense, (still not sure i would want to run postgres on a router) but for a multi-dc environment with other postgres dbs, not so much
<rmcadams> my switches are all cumulus
<rmcadams> x86
<rmcadams> probably a way to put something on there, that's an interesting concept, but yah... it's interesting
<rmcadams> I wanted it part of the environment too, not standalone
<stormmore> I thought about cumulus, not quite ready to make that jump yet
<stormmore> it just seems like even the smallest of the smallest server would still be overkill for the controllers (especially once you move postgres off)
<stormmore> oh and the switch seemed logical since you could ship it basically preconfigured with pxe, tftp, etc.
<stormmore> you could call me crazy but I do likely to daydream about the ideal in the modern age
<rmcadams> I love cumulus quite honestly, its so simple... and with knowledge of linux and some ansible skills you never touch it
<rmcadams> so bdx - I'm not sure that MAAS "Chassis" are going to fix the virsh issue
<rmcadams> yah, so when I add a 'chassis' (virsh box) that has 5 compute nodes configured, none of them are added to the MAAS, in addition, if they boot and come up the virsh settings are still global :(
<rmcadams> thanks for the try bdx
<rmcadams> oh boy, scratch that bdx - it worked
<rmcadams> wow
<rmcadams> Well that does it, 6 Compute Nodes, 4 Infrastructure nodes and 4 Storage nodes through virsh with two hosts... thanks to bdx
<kjackal> Good morning Juju world!
<arosales> kjackal: good morning
<arosales> Just a reminder: There will be a Juju Show Hangout today @ 2pm USA Eastern time
<lazyPower> arosales where do i buy tickets to the show?
<arosales> lazyPower: here, it will only cost you code commits :-)
<setuid> Any experts with numa/hugepages about, specific to customizing a charm to pin vms to node 0?
<setuid> IOW, how to define in the charm, that both vms will be pinned to node 0, and not balanced across node 0 and 1
<bdx> can I add users to my models on the juju beta hosted controller?
<bdx> `$ juju users` shows "ERROR unknown object type "UserManager" (not implemented)"
<bdx> is there something I'm missing here?
<rick_h> bdx: I don't think you need to add the user since it's backed by SSO
<rick_h> bdx: have you tried just granting an sso user email?
<bdx> oooo
<bdx> no
<bdx> I haven't, I'll try that now
<rick_h> bdx: maybe bac can confirm/deny
<bdx> rick_h: you have to use the users launchpad email, not username?
<rick_h> bdx: not sure on that one. 50/50 shot?
<bdx> rick_h: http://paste.ubuntu.com/23823403/
<bdx> it must be email then
<bdx> rick_h: users lp email worked
<bdx> still can't list users though ... http://paste.ubuntu.com/23823423/
<rick_h> bdx: if you show-model is that there?
<bdx> rick_h: yeah ... and it says "users: {}"
<rick_h> bdx: it should like users of the model in that output
<rick_h> oh hmmm, well so much for that :/
<bdx> http://paste.ubuntu.com/23823432/
<bdx> even though I just successfully added a user via lp email
<bdx> rick_h: ahhh, the user hasn't signed up for juju beta yet, or he just did like right now
<bdx> do you think the user must be registered for juju beta in order for me to add them to my model?
<rick_h> bdx: I don't think so? but I'm not sure.
<rick_h> bdx: I'm reaching out to see if we can get someone deeper in that side of things to help us out here
<bdx> if so, can I just give them my register command (as it seems like a generic address) so they can register now, and don't have to wait on the email response back from canonical
<frankban> bdx: have you tried juju granting user@external?
<frankban> bdx: like "juju grant simonbacquie@external admin prm-demo", assuming simonbacquie is the proper usso name
<bdx> frankban: I ran this command, which seemed to succeed "juju grant users-launchpad-email@myemailserver.com admin common-infrastructure"
<bdx> ahhh, <lp-username>@external
<bdx> I'll try that
<frankban> bdx: no, please try juju grant {usso-username}@external admin {model-name}
<frankban> bdx: yeah
<bdx> frankban: http://paste.ubuntu.com/23823475/
<bdx> here's `juju users --debug` -> http://paste.ubuntu.com/23823479/
<frankban> bdx: that's ok, possibly something we need to improve when showing models in jimm
<frankban> mhilton: ^^^
<frankban> bdx: but now that user should be able to admin your model
<bdx> frankban, ok, can I have that user run `juju register jimm.jujucharms.com` ?
<frankban> bdx: yes
<mhilton> bdx, frankban: I think that's a known limititation, but I'll make sure its on the bug list.
<frankban> thanks mhilton
<rick_h> jcastro: marcoceppi_ arosales tvansteenburgh mbruzek lazyPower and other folks the hangout url for the show is https://hangouts.google.com/hangouts/_/ytl/EVQjb5MECk3bIol40w_4rT0ibocCKyiqpk3QAkWjBEE=?eid=103184405956510785630&hl=en_US&authuser=0
<rick_h> and the youtube viewing link is http://youtu.be/Lsbo7f7yMxY
<mbruzek> thanks rick_h
<arosales> rick_h: thanks
<arosales> Getting ramped up for the Juju Show
<mskalka> pardon my ignorance but what is the Juju Show?
<rick_h> mskalka: http://youtu.be/Lsbo7f7yMxY check it out
<bdx> mskalka: find out -> http://youtu.be/Lsbo7f7yMxY
<mskalka> thanks!
<sparkiegeek> woop woop, Juju Show time - missed the first few minutes
<tvansteenburgh> https://github.com/juju/python-libjuju
<tvansteenburgh> https://pythonhosted.org/juju/index.html
<sparkiegeek> QUESTION: how will libjuju versioning work? Specifically will it release 1:1 with associated Juju versions? What about bugfixes?
<arosales> sparkiegeek: per tvansteenburgh answer of loading the desired juju version be good to start a juju mail list thread and get folks opinion on it
<sparkiegeek> arosales: sure. But the code generation that it uses can't be loaded from the API AFAIK
<tvansteenburgh> correct
<arosales> sparkiegeek: good to discuss that with tvansteenburgh
<arosales> but perhaps on the list of pro/cons to get others input
<arosales> for folks following along python-libjuju examples @ https://github.com/juju/python-libjuju/tree/master/examples
<tvansteenburgh> sparkiegeek: what do you think of the idea i proposed?
<tvansteenburgh> (for versioning)
<sparkiegeek> tvansteenburgh: it's a nice idea - I'm just concerned about the generated code would work. You'd need N versions of the generated "blob"s for each Juju version you wanted to support
<sparkiegeek> tvansteenburgh: I think a good change would be to instead split by facade - have separate generated blobs for each facade
<sparkiegeek> tvansteenburgh: then negotiate with the API and do a negotiation on the facade version that libjuju supports and that it supports
<sparkiegeek> tvansteenburgh: bigger font please
<sparkiegeek> rick_h: LOL
<bdx> tvansteenburgh: datadog/newrelic juju plugin using all watcher to report events back to your monitoring
<bdx> chef/puppet already have these types of plugins .. all watcher would be perfect for for implementing the juju version of this
<sparkiegeek> tvansteenburgh: arosales: FYI libjuju versioning thread started
<tvansteenburgh> sparkiegeek: cool thanks
<arosales> sparkiegeek: thanks
<rick_h> sparkiegeek: hah, not waiting on causing trouble :P
<bdx> tvansteenburgh: is there a better way for me to access the units of an application than what I'm doing here https://gist.github.com/jamesbeedy/dad808872e5488b43cf3fa5d5f2db87c#file-simple_juju_action-py-L37
<bdx> tvansteenburgh I am only finding examples where you can deploy the application, then get the units similar to https://github.com/juju/python-libjuju/blob/master/examples/action.py#L32
<tvansteenburgh> bdx: looking
<sparkiegeek> app_web = model.units["app-web/2"] ?
<tvansteenburgh> yes :)
<tvansteenburgh> quick learner this guy
<bdx> tvansteenburgh, sparkiegeek: ehhh, what if I don't know what units an application has?
<sparkiegeek> and/or [unit for unit in model.applications["app-web"].units]
<bdx> sparkiegeek: ahhh nice, thats what I was looking for thanks!
<sparkiegeek> bdx: np!
<CoderEurope> marcoceppi_: ping
<marcoceppi_> CoderEurope: o/
<CoderEurope> Cool beans - got the computer - ready to do Discourse in juju ?
<CoderEurope> marcoceppi_: Can you jump on here for a second ? https://meet.schrodingersscat.com/LoyalOctopodesDiscussFinely
<marcoceppi_> CoderEurope: I'm 2 mins away from a vacation. Can we schedule an official chat time next week?
<marcoceppi_> CoderEurope: Like, this time Tuesday?
<CoderEurope> Okay suppose so ... shame but I guess.
<marcoceppi_> CoderEurope: yeah, super sorry about that
<CoderEurope> I shall put it into my ubuntu phone :D
<marcoceppi_> CoderEurope: sweet, I'll make sure it's in my calendar, if you grab me this time next week on Tuesday, you'll have my full undivided attention!
<CoderEurope> cool beans
<CoderEurope> have a good vacation :D
<bdx> sparkiegeek, tvansteenburgh: much better now -> https://gist.github.com/jamesbeedy/dad808872e5488b43cf3fa5d5f2db87c
<tvansteenburgh> bdx: for unit_name, unit in model.applications['app-web'].units.items():
<tvansteenburgh> that way you don't have to create the Unit object
<bdx> tvansteenburgh: ooh, because the unit objects are already available via the units dict?
<tvansteenburgh> yep
<bdx> nice
<bdx> awesome, thx
<bdx> tvansteenburgh: this is what I've got now https://gist.github.com/jamesbeedy/dad808872e5488b43cf3fa5d5f2db87c
<bdx> soo much cleaner ... wow .... thanks again
<bdx> sparkiegeek: ^
<tvansteenburgh> bdx, one bug there
<tvansteenburgh> "for unit_name, unit in" (line 47)
<tvansteenburgh> otherwise looks good!
<bdx> oooh, entirely, thanks
<petevg> cory_fu: does the cwr-ci charm just fetch matrix from github?
<cory_fu> petevg: Yes
<petevg> cory_fu: cool. When you get a chance, would you look at the PR at https://github.com/juju-solutions/matrix/pull/69, so that I can confirm that it works in the charm, and push the charm side of the PR for review?
<cory_fu> petevg: So, I understand the desire to avoid having to pass the output dir through BT, but on the other hand, we eventually will want to add crashdump support to BT (for picking up logs prior to doing an env reset), at which point it's going to need the output directory as well.  And CWR already has the output directory passed in to it, so it seems like it wouldn't be much more of a change to add the arg pass-through to BT.
<petevg> cory_fu: bundletester and matrix have a lot of conflicts in argument names, so it felt more foward facing to separate their arguments somehow.
<petevg> cory_fu: another solution would be to do as tox does and have a delimiter that passes arguments after the delimiter to matrix.
<cory_fu> petevg: I don't understand what you mean about conflicts in argument names?  I'm not suggesting a special arg for matrix in BT.  I'm saying, BT needs its own output dir option, and it should then be passed through to matrix as well.
<cory_fu> And that BT output dir option would eventually be used to know where to put the crashdump output for the model that BT manages
<cory_fu> *also be used
<petevg> cory_fu: I understand that. I'm saying that, looking forward, we might actually want to pass multiple things through bundletester, to matrix, and maintaining a kind of manual translation table of arguments feels clunky. I'd rather have a way of talking around bundletester, through to matrix, than have to hard code translations inside of bundletester.
<petevg> cory_fu: maybe it's just something we have to live with, given that we've decided to have bundletester drive matrix.
<cory_fu> I can see that for things that are matrix specific, but I feel like the output dir is something that makes sense to pass through, since all three components are going to put things there, and we shouldn't have to pass it in three different ways
<cory_fu> petevg: At any rate, this approach is easier and doesn't require touching BT and CWR, so we can go with it for now and consider refactoring when we have to add the output dir option to BT anyway
<petevg> cory_fu: ty
<bdx> frankban, rick_h: concerning credentials and the hosted controller ....
<cory_fu> petevg: Merged
<petevg> awesome. thx
<bdx> I can add a model with a credential on my own controller and deploy ubuntu -> http://paste.ubuntu.com/23824224/
<bdx> but when I try the same thing on the hosted controller deploying anything fails
<bdx> ahhh shoot ... nix that
<bdx> its working
<petevg> cory_fu: unfortunately, that's card isn't done done :-p (we actually do some manipulation of the output dir somewhere in either the guts of cwr or jenkins, and I'm testing a change that puts the matrix.tar.gz into a place where jenkins can actually surface it; PR coming.)
<cory_fu> Ah, sorry.  :p
<petevg> No worries. I just noticed it myself :-/
<gQuigs> I can specify zesty as the series in a bundle, but I haven't been able to figure out how to force it to override the charms?
<gQuigs> juju deploy bundlefile-reduced-zesty.yaml --series zesty --force
<gQuigs> ERROR Flags provided but not supported when deploying a bundle: --force, --series.
<lazyPower> gQuigs right, you can set the series in the bundle, per charm or as a whole for the bundle.
<lazyPower> those --force and --series flags are intended for charm deployment, eg:  juju deploy ./etcd --series=zesty --force
<lazyPower> as etcd only supports xenial in its metadata.yaml, those flags would tell juju to ignore those warns, and force deploy on zesty.
<gQuigs> I'm trying to override about 10 charms (openstack) to try them on zesty
<gQuigs> but I want to use a bundle for them..
<lazyPower> gQuigs - i dont think theres an easy way to do that without using local charms with the series modified. rick_h might prove me wrong though, as he's kind of the bundle wizard of juju. he's clued me in to some neat features I didn't know about
<mskalka> lazypower, even if you edited the bundle.yaml would juju throw errors for the charms that didn't support zesty?
<mskalka> deploying from local that is
<lazyPower> only if the metadata.yaml specifies series support
<gQuigs> lazyPower: right, I'll fall back to editing each charm in turn
<lazyPower> if its missing the series key, it should "just work" when you tell it in the bundle, as the bundle becomes the source of truth then
<mskalka> so you'd have to ostensibly edit each metadata.yaml and change/remove the series and tell the bundle to deploy all local charms to completely avoid conflict?
<rick_h> gQuigs: lazyPower if the charms don't devalre they support zesty it's not something the bundle can force sorry.
<lazyPower> rick_h - if its  alocal path charm?
<lazyPower> oh you're answering the first question. right
<rick_h> gQuigs: lazyPower but the cahrm says it doesn't support it in the metadata?
<gQuigs> rick_h: thanks for the answer :)
<rick_h> I'm surprised they don't have something in testing and the like though.
<lazyPower> rick_h how does a charm say i dont support somthing? I thought if its listed it supports it, if it has no series key in metadata, you can tell it whatever.
<rick_h> beisner: do you all have anything for zesty in dev?
<rick_h> lazyPower: you can, but the bundle does take that I don't believe.
<lazyPower> hmm
<rick_h> lazyPower: as you noted you have to manually force it with the --series flag
<rick_h> It's like a --force
<lazyPower> ok, i was kind of goign from hazy info anyway. i've done some weird things with local charms/bundles
<gQuigs> lazyPower: thanks, I forgot about local branching and juju-deployer makes that trivial...
<lazyPower> gQuigs np, we aim to have you not need to do that, but corner cases and all that
<beisner> hi rick_h - not much yet.  we plan to enable the zesty series in the charms after the 17.02 openstack charms stable release.
<rick_h> beisner: ah ok
<rick_h> beisner: any trick youve thought of or used to try something on a new series before the charms are updated?
<beisner> rick_h, if one uses juju-deployer, and the git branches instead of cs: values, one can deploy any charm to any series.  so, a friend said ;-)
<beisner> rick_h, aiui, there is a --force with juju 2 native deploy, though, right?
<rick_h> Gotcha
<gQuigs> beisner: the --force doesn't work with bundles
<rick_h> beisner: yes but only on deploy and not.on bundles
<beisner> gQuigs, rick_h - ack, that would be for individual charm deploys wouldn't it?
<gQuigs> would supporting --force series to bundles be a welcome feature to add?  (/me wouldn't mind giving it a shot)
<beisner> gQuigs, rick_h - the reason we haven't yet enabled zesty metadata in the charms is because the openstack charms will release a stable update from master in Feb, in alignment with openstack upstream's new release cadence.  but that will be ~2 months ahead of zesty's release and we don't want that series declared in stable charms while zesty is still in dev on the Ubuntu side.
<beisner> gQuigs, seems like a valid --force use case ;-)
<rick_h> gQuigs: the reason it didn't get added as it's very special. What charms do you want to use it on? What if one of the 10 is windows...Or you know won't work. It's just a very narrow use case feature.
<rick_h> The bundle has to be perfect for it to be useful
<rick_h> gQuigs: I think having the bundle respect what's entered in the series for the charm would be better.
<rick_h> E.G. If the series in the application section of the bundle says zesty, use that even if the charm says it's only trusty.
<gQuigs> rick_h: hmm.. will take a look at the code around that
<gQuigs> thanks all!
#juju 2017-01-19
<surf> Hi all, I added my openstack cloud to juju clouds and credentials also. while doing juju bootstrap to that cloud i am getting following error.
<surf> Error log pasted here http://paste.openstack.org/show/595548/
<surf> please someone help
<axw> surf: what's the version of openstack?
<surf> axw: liberty
<axw> surf: can you share your clouds.yaml?
<surf> axw: yeah 1 sec
<surf> here is my clouds.yaml file http://paste.openstack.org/show/595553/
<axw> thanks
<axw> surf: I'm a little suspicious that we're not doing v3 properly. can you try changing the endpoint from v3 to v2, see if that makes a difference?
<surf> axw: ok
<surf> awx: still no difference
<axw> surf: did you set anything for "domain-name" in the credentials?
<surf> yeah it is "default"
<axw> surf: I have to admit to being completely ignorant of v3 auth, I've never used it. can you please try commenting that out of your credentials.yaml to force v2 auth?
<axw> if that doesn't work, might need to wait for someone with better openstack debugging skills
<surf> axw: still i am getting autentication problem
<kjackal> Good morning Juju world
<axw> surf: is the debug output any different at all when using the v2 endpoint?
<surf> axw: here is the debug log with v2 http://paste.openstack.org/show/595565/
<axw> surf: sorry, I am out of ideas
<surf> axw: ok thanks for your i nfo
<surf> Hi all, I am doing bootstrap juju to the openstack cloud
<surf> is it necessary the both juju and openstack cloud on same node
<surf> or can i bootstrap juju on to the openstack cloud from different machine, where juju is installed
<surf> hi all, I followed this doc https://jujucharms.com/docs/devel/howto-privatecloud
<surf> to bootstrap juju on openstack cloud
<surf> i am getting the error authentication failed.
<surf> here is the debug log http://paste.openstack.org/show/595606/
<anrah> surf: are you deploying whole openstack or just creating controller to existing openstack tenant?
<kjackal> Hey cory_fu do you happen to be around?
<BlackDex> hello there, is it possible to have some charms wait during a bundle deployment for after a specific other charm is finished?
<tvansteenburgh> BlackDex: "waiting" logic like that would need to be in the charm itself
<tvansteenburgh> for example, you could wait to start the service that the charm provides until after it had successfully joined a relation with another charm
<tvansteenburgh> e.g. a web app charm that's waiting for a database
<BlackDex> well for instance if i deploy a system with a lot of LXD containers, or even deploy mysql and wordpress onto a physical system without containers they both will install packages
<BlackDex> since just one instance of apt-get can run, one will wait
<BlackDex> if the juju deploy (using a bundle) is smart enough to wait to add one untill the first is finsihed, that would be better i think
<tvansteenburgh> BlackDex: is this theoretical or are you hitting a problem in a deployment?
<BlackDex> hitting a problem
<BlackDex> i just received an lxd container within a 10.x.x.x network, will the network is 192.168.x.x
<BlackDex> so i needed to re-deploy
<BlackDex> also, i'm currently trying to deploy an HA OpenStack
<BlackDex> it seems like to much is running at the same time
<BlackDex> some hooks fail
<BlackDex> and if i run those hooks via debug-hooks there seems to be nothing wrong, or causeing errors
<tvansteenburgh> BlackDex: anything useful in `juju debug-log` output?
<BlackDex> i have to check that a bit better
<BlackDex> but not really
<BlackDex> i this case i see that mysql isn't able to connect
<BlackDex> but it is strange if i do it manually it works
<tvansteenburgh> BlackDex: which bundle are you deploying?
<BlackDex> percona-cluster
<tvansteenburgh> BlackDex: so not a bundle, just the percona-cluster charm?
<BlackDex> no a whole bundle
<BlackDex> the basic openstack-bundle
<BlackDex> and i changed it to be HA
<BlackDex> the base works fine
<BlackDex> but after ha it stops deploying even the basic charms them selfs
<BlackDex> it looks like some limits or something
<BlackDex> or race-conditions
<BlackDex> ill go and try the default bundle now again
<BlackDex> and see what that does
<jhobbs> it looks like juju 1.25 is at least sometimes setting up /etc/apt/apt.conf.d/99no-recommends to set apt to not install recommended packages
<jhobbs> is there a setting to enable/disable that? why is that happening?
<jcastro> that seems like really wrong behavior to me
<jhobbs> yeah
<jhobbs> it seems crazy
<jhobbs> we're seeing breakage because base layer just installs python3-pip, which ends up bringing python3.5-dev in via recommended packages if apt is allowed to
<jhobbs> but with no recommends set it doesn't, and then pip install of pyaml fails because it wants to build a cpython module
<jcastro> I'm not a policy expert but that seems like a bug to me
<jrwren> jhobbs: where are you seeing this no-recommends set? could it be a different colocated charm? Is something integrating with a charm before its deployed? I've never seen this, but I always wanted it :)
<jhobbs> the file says it was created by juju
<jhobbs> but it may be a lie
<jhobbs> i just checked the juju source and don't see it listed
<jrwren> jhobbs: what charm?
<jhobbs> ah ok
<jhobbs> it's IS's basenode that is doing this
<jrwren> jhobbs: is there an exec.d dir in the charm root dir or in the charm hooks dir?
<jhobbs> sorry for the false juju alarm
<jhobbs> i will take it up with them
<jcastro> whew!
<bdx> question concerning juju beta hosted controller
<bdx> the "Access  Last connection" doesn't seem to populate corrrectly see -> Access  Last connection
<bdx> oops
<bdx> http://paste.ubuntu.com/23828205/
<bdx> juju-gui shows https://cloud.githubusercontent.com/assets/5590546/22111375/f9e80a5c-de13-11e6-92d3-1672174dd3b4.png
<bdx> I'm wondering if this has to do with the permission level I have as a user of the controller ...
<BlackDex> tvansteenburgh: With the old juju i used the juju-deployer and that waited with adding units after the first unit whas running, it also waited with adding the relations untill the end.. Since juju 2.0 it deployes better like juju-deployer, but it laks the waiting part. I think that is a plus
<BlackDex> the waiting part i mean, that is better, it doesn't hogg the system all at once
<tvansteenburgh> that may be true for a local lxd deploy, but it's irrelevant for a typical cloud deploy
<BlackDex> why? because all the HA services are within an LXD
<BlackDex> all services are within an lxd container on several nodes
<BlackDex> thats the same from my point of view
<tvansteenburgh> lxd containers are totally isolated from each other, so there shouldn't be any conflict (like using apt at the same time on multiple containers). and if the node hosting the lxds can't handle running them all at once (i.e. the system is overloaded), then the node is under-provisioned to begin with
<BlackDex> well, there are a lot of tweaks needed by default to run lxd's like open-files, inotify, max-pids etc...
<BlackDex> those arn't set by default high enough sometimes
<BlackDex> it happens most on bare-metal systems
<BlackDex> so multiple charms bare-metal on the same system.
<BlackDex> i think i have found a way
<BlackDex> i deploy it with hacluster charms, but i don't add all units yet. I created a small script to add those afterwards
<kjackal> kwmonroe: petevg: this is a fix for the path. Please, review, merge re-push to store. Apologies: https://github.com/juju-solutions/layer-cwr/pull/41/files
<kwmonroe> lol..  i love it.  python nested in bash functions that are called by trapping the exit from our bash defined in a jenkins job xml.  more of this please!
<kwmonroe> merged
<kwmonroe> kjackal: petevg:  cs:~juju-solutions/cwr-30 is released (includes latest matrix, jenkins, and xml branches)
<petevg> thank you!
<aisrael> Anyone have experience with juju failing to remove a unit (log shows "cleanup failed for removed Unit("unitname"): transaction aborted")
<kjackal> kwmonroe: agreed lets keep the python scripts under scripts. Thank you for releasing cwr
<lazyPower> aisrael - i've only seen that deadlock when a remote relation has failed or a sub relation has failed
<lazyPower> sounds like perhaps the agent cleanup is what failed?
<aisrael> lazyPower: Yeah, it seems like it. status shows the agent is stuck "executing".
<lazyPower> aisrael  if you juju ssh into that unit and recycle the jujud process, does it unstick it?
<aisrael> lazyPower: No, but it does show me a few things possibly broken in its networking, so that could be a clue
<lazyPower> weird
<lazyPower> i'm at a loss for why its doing this :( sorry
<aisrael> no worries, man.
 * aisrael breaks out strace
<kwmonroe> aisrael: sounds like you need more mongos
<aisrael> I think I need eleventy of them, right?
<admcleod_> i read that as mangos. everyone needs more mangos
<aisrael> hah. I rebooted the unit and it cleared something up because the destroy finally finished
<aisrael> Huh. Cleanup failed with an unexpected error:  unknown operation kind run-action
<lazyPower> aisrael - did it have actions queue?
<lazyPower> it might be that we've hit a not as well tested path with teh agents where an action is scheduled, yet cleanup attempt ran before the action was completed, and now its fighting for what should be happening
<lazyPower> i'm guessing here, but it sounds reasonable
<rmcadams> in the juju bundle yamls, when you build them, can you use 'tags' as constraints for machines?
<admcleod_> rmcadams: yes
<rmcadams> https://www.irccloud.com/pastebin/uRqlOAh1/
<rmcadams> so under constraints, I can put  tag=compute
<rmcadams> as an example?
<admcleod_> rmcadams: yeah, heres an example: https://github.com/ubuntu-openstack/zopenstack/blob/master/bundles/zkvm/xenial-mitaka-2-machine-control-plane-next.yaml#L25
<admcleod_> tags=
<rmcadams> nice
<rmcadams> building my own derivative of the openstack bundle to build a big configuration of six compute, six storage and then some infrastructure nodes
<admcleod_> cool :)
<rmcadams> just trying to learn the bundles, seems important ;)
<admcleod_> hah yeah, you dont want to be deploying that stuff manually
<lazyPower> its like deploying kubernetes charms manually, only with more relations and components
<lazyPower> rip
<lazyPower> i concede, openstack is the final boss of charming
<lazyPower> beisner - i pay homage to my fore-fathers publically ^
 * beisner ^5s that k8s work, good sir
<lazyPower> <3
<kwmonroe> won't somebody stand up for the elephants in the room?
<kwmonroe> big data is where it's at.
<admcleod_> thats more of a balrog
<admcleod_> soz
<lazyPower> kwmonroe you do make a good point
<lazyPower> kwmonroe but i would have expected you to be the champion and remind me of my roots :P
<lazyPower> java is *always* the final boss
<kwmonroe> k8s and the 'stack are great, but when you want to actually do real work (like wordcount), hadoop is where it's at.
<mbruzek> Did someone say Java?
<kwmonroe> lol
<lazyPower> kwmonroe https://cdn.meme.am/cache/instances/folder481/53692481.jpg
<kwmonroe> that's awesome lazyPower
<lazyPower> i cant take credit, its from an old monitorama talk https://jamessdixon.files.wordpress.com/2015/06/image.png
<admcleod_> ï¿¼course, if you wnna do .. something like wordcount which isnt wordcount, but is very similar, then bigdata on openstack with lxd is where its at. right. right?
<admcleod_> right
<beisner> Java Java jav
<beisner> a
<beisner> yeah, because:  bopensdata.
<mbruzek> beisner: You know that pings me right?
<beisner> Java
<admcleod_> java
<lazyPower> RIP bruzer's notifications and productivity
<mbruzek> you guys!
<kwmonroe> java 2 se for workgroups
<lazyPower> y u guys make fun of yava?
<admcleod_> java - only slightly more stupid than rocket league
<beisner> my 6 yo is addicted to rocket league
 * lazyPower smirks
<lazyPower> so is admcleod_, dont let him fool ya
<beisner> raising a proper geek here
<lazyPower> heck yeah beisner
<lazyPower> i approve of this message
<admcleod_> haha good one
<admcleod_> yeah like ive even played it once, ever
<beisner> this hour, you mean?
<lazyPower> admcleod_ - my new obsession is ARK
<lazyPower> cross between dayz, turok, and minecraft
<admcleod_> guys,. plz. RL sux lol
<lazyPower> oh no admcleod_ has reverted to internet gibberish
<lazyPower> he must be having a RL withdrawl
<justicefries> ARK is so fun
<lazyPower> justicefries ^^^^^^ OMG YOU'RE HERE
<justicefries> o/
<lazyPower> how goes it?
<admcleod_> actually i havent played for a week or so
<lazyPower> admcleod_ back in EU so our ping doesn't suck?
<justicefries> quite well! taking a slow WFH day
<admcleod_> lazyPower: back weds
<lazyPower> ack, we'll have to link up and pwn scrubs on weds
<admcleod_> lazyPower: then i will backboard second hit airdribble you into oblivion
<admcleod_> i mean yeah pwn scrubs
<kwmonroe> these new juju nouns are great.
<kwmonroe> juju airdribble-controller --oblivion
<admcleod_> haha
<lazyPower> admcleod_ we call that the mr miyagi
<lazyPower> its an advanced move, but totally cool when its pulled off
<admcleod_> yeah. i mean. obviously i dont play RL, but if i did, i would also have been watching tactics vids.
<justicefries> oh lazy question on the CDK, took a cursory glance and couldn't find it - what's the default cert expiry on what easyrsa is issuing?
<lazyPower> 10 years, mbruzek fact check me?
<lazyPower> yeah, he confirmed on the hangout
<justicefries> cool
<kwmonroe> java_max_int for sure
<mbruzek> yes 10 years by default and you can make them longer
<lazyPower> 10 yars
<lazyPower> *years
<beisner> http://www.2600online.com/assets/cart_yarsrevenge.jpg
<lazyPower> classic
<lazyPower> @beisner bring back the door games
<lazyPower> time for some L.O.R.D.
<lazyPower> or TradeWars 2002
<lazyPower> also beisner  did you know you can play atari in your browser? http://www.virtualatari.org/soft.php?soft=Yars_Revenge
 * beisner can't click that right now, please leave a message
 * lazyPower leaves that right here in channel for safe keeping
<admcleod_> *visions of all CI breaking for weeks*
<mbruzek> beer proof keyboards
#juju 2017-01-20
<om2> Hi, trying to juju bootstrap to openstack private cloud...
<om2> I get this error, ERROR cmd supercommand.go:458 failed to bootstrap model: cannot package bootstrap agent binary: no prepackaged agent available and no jujud binary can be found
<om2> Any ideas how to move forward?  Juju bootstrap is looking for jujud inside my local juju bin directory and not finding it, but cannot find any info on jujud.
<om2> som more debug:  https://paste.pound-python.org/show/fNCbbes8Fv2Ul6wQx6rs/
<surf> Hi all, I want to know about juju charm deployment on openstack instance
<surf> please someone help
<cacasmacas> anyone have a working RackSpace openstack Kilo juju controller setup?  I keep getting credentials not found and no credentials needed for that cloud
<cacasmacas> any pointers or example yaml files appreciated for juju 2.x
<kjackal> Good morning Juju world
<kjackal> cacasmacas: you might have more luck asking at #openstack-charms
<kjackal> hi surf. What exactly you want to know?
<Zic> hi here, if I deployed the canonical-kubernetes bundle charms with only private ethernet interfaces on my kubernetes-worker and if I add after this deployment public interface, wil Juju do something? does it ever need to?
<Zic> s/wil/will/
<anrah> om2: you're missing simplestream metadata service for your cloud
<zeestrat> BlackDex: We're running into the same issues when deploying OpenStack HA services on LXD on MAAS nodes. The nodes are pretty beefy, but deploying them all at the same time really bogs it down.
<BlackDex> yea, i now told the bundle to use hacluster with a count of 3, and all the HA services like cinder, glance etc... i just deploy one unit. And afterwards i just do `juju deploy -n2 cinder --to lxd:1,lxd:2`
<BlackDex> the cluster won't start untill there are 3, so this works for now
<BlackDex> but if i'm correct, the juju-deployer package waited before atleast one was deployed, and after that it added the remaining units for that service/app
<zeestrat> I came straight into juju 2.x so I haven't really tried juju-deployer.
<zeestrat> It might be worth sending a mail to the mailing list to explain the issue and hear if anyone has some suggestions on deployment or performance improvements in Juju
<anrah> I saw this clearwater+zabbix demo about autoscaling, is there any hint how that was achieved?
<anrah> juju client + user installed to zabbix server and then using shell commands to scale the application?
<anrah> I'm interested whether there's some "approved" way to implement autoscaling features?
<BlackDex> zeestrat: where is your bootstrap located? Also an LXD?
<junaidali> Hi, should auto_peers for ntp be true, if we're going to use ntpmaster?
<junaidali> auto_peers config in ntp charm*
<junaidali> if we're *not* going to use ntpmaster**
<surf> hi all, how to boostrap juju on openstck cloud?
<junaidali> surf: you should check https://jujucharms.com/docs/2.0/help-openstack
<junaidali> I have created a guide over this (not a clean one though :) ), http://paste.ubuntu.com/23833150/
<deanman> surf, Did you mean how to deploy a workload using juju on top of openstack ?
<surf> deanman: yes i got the way to do.
<anrah> there is couple things to be extra careful :)
<deanman> ok great, i did it recently on Mitaka and could help if you want but i think junaidali's snippet is straightforward :-)
<lazyPower> bdx - got your doc comment, and briefly glanced at the reactive code linked. I'd need to dive deeper in this context with a deploy to see if we cant do it another way
<lazyPower> but it looks very similar to what we were referencing lastnight
<blahdeblah> junaidali: I've changed the readme recently to hopefully explain this better; see https://git.launchpad.net/ntp-charm/tree/README.md for latest
<blahdeblah> junaidali: I have to run now, but feel free to drop questions here and I'll do my best to answer.
#juju 2018-01-15
<elmaciej> Hi! Can someone quickly explain me how to write my charm - I want it to connect to existing spark client, copy jar file to spark master and run a spark job. It has to be a charm actually not a script . Can someone advise me how to start it - I'm reading documentation and honestly it totaly confused me
<kwmonroe> elmaciej: you mentioned a req for being a charm, but the spark charm has a 'spark-submit' action that may do what you want. the  readme talks about the spark-submit action here: https://github.com/apache/bigtop/tree/master/bigtop-packages/src/charm/spark/layer-spark#actions
<kwmonroe> you can pass a jar (local, remote, hdfs -- whatever spark-submit accepts as it's jar param),  give it runtime options, and schedule it to run with cron if needed.
<kwmonroe> elmaciej: if that doesn't work for you, the tengu team has written a subordinate charm called 'spark-job' that sits on a deployed spark charm.  it takes a job url and runs that on the spark cluster: https://jujucharms.com/u/tengu-team/spark-job
<kwmonroe> elmaciej: if that doesn't suite your needs but you still want to take the subordinate charm approach, i suggest modelling your charm off of their source: https://github.com/tengu-team/layer-python-spark-job
<kwmonroe> elmaciej: and if that's still not the route you'd like to go, the spark interface has a short client snippet for charms that need to "require" spark:  https://github.com/juju-solutions/interface-spark
<kwmonroe> all this is predicated on some knowledge of charm authoring -- if you're just starting out, i'd recommend trying a hello-world with help from https://jujucharms.com/docs/stable/developer-getting-started, and asking specifics here -- we can def help you!
#juju 2018-01-16
<kjackal> Hi, is there support for availability zones in openstack?
<balloons> kjackal, yes there is
<balloons> kjackal, use "--to" juju bootstrap --to zone=blargh for example
<ejat> hi ..
<ejat> http://paste.ubuntu.com/26398830/
<ejat> trying to add heat after conjure-up openstack
<kwmonroe> ejat: what does "juju show-action-output 9b053e45-6f73-486e-8cb9-acb5757ce6f3" show?
<kwmonroe> ejat: also might be helpful to paste "juju debug-log -i heat/0 --replay"
#juju 2018-01-17
<armant> hi all :)
<armant> sort of a quick question, couldnât resolve this using documentationâ¦.got an error when trying to register a conroller spawned on azure
<armant> $ juju register 13.89.190.XXX
<armant> Enter a name for this controller: mycloud
<armant> ERROR try was stopped
<armant> can someone point me to the documentation on how to set up an existing controller?
<armant> hello?
<armant> is there anybody out there?
<rick_h> magicaltrout: ping, just wanted to let you know that the jujushell should work around the LE challenge shutdown now.
<rick_h> magicaltrout: curious to get your feedback on the setup
#juju 2018-01-18
<ejat> <ejat> i just tried the canonical-kubernetes-elasticsearch bundle
<ejat> <ejat> got error at the elasticsearch
<ejat> <ejat> https://paste.ubuntu.com/26408473/
<ejat> <ejat> log from elasticsearch/0
<ejat> <ejat> in trusty only have jdk 7 in repo?
<ejat> <ejat> then when i tried manually install openjdk 8 n set it as default java ,
<ejat> <ejat> get this:
<ejat> <ejat> sg: OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000085330000, 2060255232, 0) failed; error='Cannot allocate memory' (errno=12)
<ejat> anyone tried n working?
<kjackal_bot> Hello, we are behind a proxy and when doing juju deploy ssl authentication is failing
<kjackal_bot> is there a way to bypass this?
<tylerderosagrund> Hi all I need some help! I am trying to bootstrap juju on a openstack cloud and I am getting ERROR fetching hosted model spaces: subnet exist. What flags can I use to fix this?
<tylerderosagrund> Tried searching through the docs but nothing is really clear
<kwmonroe> admcleod: does ^ that ring any bells?
<kwmonroe> tylerderosagrund: i haven't run into that, but i'm also a simple man and don't get too fancy with bootstrapping.  it might help if you could pastebin the output of your juju bootstrap command, preferably with  the --debug flag.
<tylerderosagrund> Right on let me do that real fast.
<admcleod> kwmonroe: hmm nope
<admcleod> tylerderosagrund: you may also want to ask in #openstack-charms
<tylerderosagrund> Ah didnt know that channel existed
<tylerderosagrund> I'll ask there too
<admcleod> tylerderosagrund: is it your own openstack cloud or someone elses?
<tylerderosagrund> It's rackspace's
<admcleod> tylerderosagrund: ah then #openstack-charms may not be so helpful to you.
<tylerderosagrund> The actual error is ERROR fetching hosted model spaces: adding subnet "192.168.2.0/24": subnet "192.168.2.0/24" already exists
<admcleod> tylerderosagrund: what juju version are you using?
<tylerderosagrund> I just dont know what to use to change the subnet
<admcleod> tylerderosagrund: i see a similar issue here: https://bugs.launchpad.net/juju/+bug/1699930
<mup> Bug #1699930: Subnets are not associated with VPCs when using AWS <juju:Fix Released by wpk> <juju 2.2:Fix Released by wpk> <https://launchpad.net/bugs/1699930>
<admcleod> tylerderosagrund: juju --version ?
<hml> tylerderosagrund: i wonder if youâre hitting this bug: https://bugs.launchpad.net/juju/+bug/1733266
<mup> Bug #1733266: Autodetection of subnets prevents bootstrap when there are duplicate subnet ranges <network> <openstack-provider> <juju:Triaged> <https://launchpad.net/bugs/1733266>
<hml> tylerderosagrund: for rackspace - there is a lot of overlap with the openstack provider
<tylerderosagrund> Sorry all I got disconnected
<tylerderosagrund> The juju version is 2.3.1-xenial-amd64
<tylerderosagrund> And yes I think I am running into that bug hml
<hml> tylerderosagrund: is it possible to change the subnets on your racksapce config?  as a work around
<tylerderosagrund> I am going to see if that might work. I am also going to try a different region too
<hml> tylerderosagrund: or have a user that can only see one of the networks?
<gunix> is this support channel for conjure-up too ?
<tylerderosagrund> so hml, changing it to a different region seemed to work
<hml> tylerderosagrund: okay - the network config must be different there
<tylerderosagrund> Yea, each tennant has its own networks so when I look 192.168.2.0/24 doesnt exist there
<tylerderosagrund> sorry g/tennant/region/
#juju 2018-01-19
<kwmonroe> ejat: you mentioned yesterday that you were having trouble with cdk-elastic (https://jujucharms.com/canonical-kubernetes-elastic/ giving you https://paste.ubuntu.com/26408473/)
<kwmonroe> off the bat, i think it'll be best to start by getting those elastic charms up to their latest versions (which are on xenial vs trusty).  i'll open an issue and update that bundle.yaml asap.
<ejat> kwmonroe: thanks ..
<cory_fu> Cynerva: when you have a chance, please check out https://veriny.tf/asyncio-a-dumpster-fire-of-bad-design/
<Cynerva> okay
<cory_fu> Cynerva: I'm curious if curio addresses the complaints that you had about async Python or of the issues were more fundamental
<Cynerva> cory_fu: i don't think it addresses my main complaint, since it still uses explicit async/await syntax
<Cynerva> i'm a much bigger fan of coroutine implementations like Lua's that don't divide the world into "functions" vs "async functions"
#juju 2018-01-20
<diemac10pleny> the battle continues for a free market in 2018!!!
<diemac10pleny> ladies and gents, I give to you the largest music exchange on the planet
<diemac10pleny> a free exchange with no middleman
<diemac10pleny> I've just returned from the future
<diemac10pleny> 2023
<diemac10pleny> and boy I can tell you this shit is hot
<diemac10pleny> the largest music exchange on the planet and your finding out about it early on
<diemac10pleny> here and now
<diemac10pleny> a great fortune unto you
<diemac10pleny> I give to you
<diemac10pleny> VOISE
<diemac10pleny> the south korea turmoil in regards to authorities shutting down crypto exchanges has caused a huge correction to happen for all cryptocurrencies on the market
<diemac10pleny> now is the time to strike with everything you've got as everything is on sale right now at a huge discount
<diemac10pleny> livecoin.net - best service, intuitive interface, trustworthy, secure
#juju 2018-01-21
<gabeduke> hey all - i've exhausted my google-fu I'm hoping someone has a pointer to get me unstuck. i've deployed a k8s cluster to a box on my local network and exposed it via bridge network. Some services seem to resolve external dns without issue but others have trouble. would this be a cluster issue or a pod issue? the container itself can resolve dns when i run it as a standalone docker container
<gabeduke> for example: the nginx-ingress-lb is able to resolve `google.com` when i curl from inside the container. The python container that im deploying, however, cant resolve google.com
#juju 2020-01-13
<thumper> https://github.com/juju/juju/pull/11095 for someone
<thumper> and another, https://github.com/juju/juju/pull/11096
<tlm> taking a look
<thumper> tlm: happy to answer any questions here if it helps
<tlm> thumper, first PR lgtm, second one looks good as far as code but don't have enough context around it for logic. Happy to approve first one if you want?
<manadart> Forward merge - only 2 patches: https://github.com/juju/juju/pull/11098
<flxfoo> Hi all
<flxfoo> Quick question...
<flxfoo> about permissions
<flxfoo> through python-juju (script) If I connect with user credential and cert pem, is there restriction for that user to run even a simple "run('uname -a')" on a remote machine?
<manadart> flxfoo: Only admin users can execute "juju run...".
<flxfoo> manadart: ok thanks...
<flxfoo> manadart: If I have an admin user, that should be fine right? (I want to have a script to do backup cron based or so)
<manadart> flxfoo: Yes, I believe so.
<flxfoo> manadart: many thanks
<nammn_de> achilleasa: in for a quick rev? https://github.com/juju/charm/pull/302
<achilleasa> nammn_de: sure
<nammn_de> achilleasa: good point! What do you think about fallback to "path" in case that happens?
<achilleasa> nammn_de: why do we need abs path in the first place?
<nammn_de> achilleasa: Last time I introduced the "path" as  this helps debugging in case something bad happens. We had some cases where fde or customers were confused that charm had not version output. Showing the path should help
<nammn_de> at least was discussing that with rick_h as far as i can remember :D
<nammn_de> but now debugging it myself I realized that some paths can be relative.
<nammn_de> and I do think using absolute ones would help in those cases at least imo
<achilleasa> nammn_de: I believe that you should return the error if you cannot figure out an abs path. It probably means that the thing you passed into filepath.Abs is garbage
<nammn_de> achilleasa: hmm makes sense as well, was too conserative
<achilleasa> nammn_de: approved
<achilleasa> are you targeting 2.7 for these changes?
<nammn_de> achilleasa: doesnt need to be, but I planned to do so
<nammn_de> anything I need to look out for?
<hml> achilleasa:  quick review pls?  https://github.com/CanonicalLtd/juju-qa-jenkins/pull/364. :-)
<hml> achilleasa: iâm tempted to move the restore-backup tests as well, though they need improvements.
<achilleasa> hml: looking
<nammn_de> achilleasa want to look at the corresponding 2.7 merge? https://github.com/juju/juju/pull/11104
<nammn_de> *pr not merge
<achilleasa> n
<achilleasa> nammn_de: looking
<lucidone> Hi, is it possible to offer an application (e.g mysql) as a CMR in a way that it can be consumed by a model on a separate network?
<lucidone> Mainly wondering if it can be done through the machines public IP address instead of using a VPN
<babbageclunk> lucidone: I *think* so - wallyworld will know for sure?
<babbageclunk> thumper: forwarder metrics: https://github.com/juju/juju/pull/11109
<wallyworld> lucidone: so long as the traffic is routable between machines... any consuming app has to be able to reach the offer, and the consuming controller needs to be able to reach the offering controller
<lucidone> Right, in this case the traffic isn't routable as mysql offers itself using the private IP of the LXC container afaik. Should it be possible to expose mysql and then offer it using that exposed interface?
<wallyworld> you don't expose an interface - juju expose opens any ports specified by the charm to 0.0.0.0
<wallyworld> what we need here is a way to put into relation data the offered apps "public" ip address
<wallyworld> and i don't think that's possible currently since that public ip addtess is obtained from the host machine's address
<wallyworld> one way would be to use a charm which has charm config to allow the user to override the advertised ip
<wallyworld> so instead of the charm using the ingress address info from the network-get hook command, it would use whatever the user has configured it to use
<tlm> could also setup the lxd network to use real routable addresses. That way what it reports is not a NAT address?
<lucidone> I saw this in the mysql charm too. So looks like it explicitly builds the connection string from the private address  https://github.com/juju-solutions/charm-mysql/blob/master/hooks/db-relation-joined#L51
<wallyworld> ueah, and unit-get private-addres is way deprecated
<wallyworld> the mysql charm is a bi orphaned
<wallyworld> i think percona-cluster charm is more up to date
<lucidone> Ah right, ideally we sort out the postgres charm anyway - so the charm specific stuff isn't a huge issue. Was just thinking there would be some juju magic that would make things work, but guess the solution here is to patch networks together with VPNs?
<wallyworld> juju can't guess network rouability etc, so needs to be suitable configured, and that falls on the charm. so yeah, whatever works
<wallyworld> postgresql charm is being sorted, but not sure of the time frame. soon i hope
<lucidone> Sweet, cheers for that. Also side question about juju expose <app> .. Is it possible / are there plans to support opening up to specific IP/ranges instead of 0.0.0.0/0 ?
<wallyworld> yes :-)
<wallyworld> this cycle i think
<wallyworld> cmr already suports that
<lucidone> Sweet :D
<wallyworld> but general charms not yet
<wallyworld> juju set-firewall-rule is used to set a CIDR list for cmr offer firewall rules
#juju 2020-01-14
<thumper> babbageclunk: a few questions on the metrics thing
<babbageclunk> thumper: thanks, looking
<babbageclunk> thumper: take another look?
<thumper> babbageclunk: ack
<babbageclunk> ta
<thumper> I have to say, this new model summary watcher driven by the cache is turning out to be real smooth
<babbageclunk> thumper: the main reason I wasn't going to include timings for errors was that the worker bounces when it gets an error, so they're kind of outside the normal request handling. Unlike in the store, where errors are reported back to the client, so errors are part of the usual workload. Might be wrong though - want me to add them in?
<thumper> ah... so if we get one, it has a very small likelihood of every being observed in the metrics?
<babbageclunk> yup
<thumper> ok, I'm fine with us not having that then
<thumper> we have a worker start count
<thumper> which gives an indication
<thumper> hmm...
 * thumper thinks about getting worker starts as an engine metric
<babbageclunk> ha
 * babbageclunk hits merge
<babbageclunk> easy test review for someone? https://github.com/juju/juju/pull/11108
 * thumper looks
<babbageclunk> thanks
<thumper> babbageclunk: lgtm
<babbageclunk> thanks again!
<babbageclunk> kelvinliu: haven't quite finished reviewing your pr yet, sorry! it's looking great though - will finish it tomorrow morning..
<kelvinliu> babbageclunk: no rush, take ur time, thanks!
<Bandu> Hi
<nammn_de> manadart achilleasa: I keep getting it wrong with the facades, could one help me out and take a quick look in regards to the facade bumpings? Seems to be correct to me. The code itself still needs to be tested, but cannot seem to get the correct facade versions https://github.com/juju/juju/pull/11088
<manadart> nammn_de: Looking.
<nammn_de> manadart: ahhh sorry it seems to work now!
<nammn_de> manadart: looks like I was having too many controller running at once and accidentally upgraded the wrong one and got confused, sorry again!
<manadart> nammn_de: I was going to say, it looks right. You also need to mask the new method for the old facades, so something like `func (api *APIv5) ShowSpace(_, _ struct{}) {}`
<nammn_de> manadart: ahh great soo looking still helped me :D
<achilleasa> The formatters used by jujuc cmds seem to append a line-feed. Anyone knows whether I can somehow suppress this?
<achilleasa> jam: This confuses my storage implementation as it assumes that data is available and tries to unmarshal it. I can probably trim the last LF (payload may contain linefeeds) as a workaround but it's an ugly hack (plus I would need to detect the os LF char)
<jam> achilleasa: there has been a fair bit of discussion around line endings. in bash, it auto-trims the (foo=$(relation-get bar) just returns the contents), and it is a lot friendlier for human consumption
<jam> achilleasa: I think you're hitting this because you're doing pure bytes instead of str
<jam> achilleasa: ideally, we wouldn't use pickle for this
<jam> IMO
<achilleasa> jam: for now I will just call '.rstrip()' assuming that the payload is encoded and not just plain-text
<jam> achilleasa: hml: so we talked for a while on the 'should process-hook always be called', I think we're back at "yes", and I'll talk through the details we talked about a bit later. (my EOD)
<hml> jam:  I can be available a 1/2 before standup tomorrow to chat?
<hml> 1/2 hour
<mruffell> Hi. Any chance I can get some eyes on my promulgation request for the wordpress charm? https://discourse.jujucharms.com/t/promulgation-request-for-wordpress-charm/2494
<thumper> cory_fu: do you know who is currently handling promulgation requests?
<cory_fu> thumper: Anyone in the charmers group can do it with `charm promulgate`
 * thumper goes to see who is in the charmers group
<cory_fu> thumper: But if there's a pending request, I'm happy to do it
<cory_fu> Oh, I see there is.  One sec
<thumper> cory_fu: thanks
<cory_fu> thumper, mruffell: Done, but there was one hiccup.  The old charm was trusty only, and the new one is xenial and bionic.  So now trying to deploy on trusty with either cs:wordpress or cs:trusty/wordpress will fail, and it also reset the rev number down to 0
<cory_fu> I don't know how much of an issue that will be, and the old rev was only 5, so it wouldn't be hard to fast-forward past that.
<thumper> it is weird that the rev number dropped to 0
<mruffell> cory_fu: I couldn't support trusty, as wordpress has moved past the php version in trusty's repos
<mruffell> this charm is all good for xenial, bionic, and focal when it comes out
<cory_fu> thumper: Because it's technically a different name (cs:wordpress vs cs:trusty/wordpress)
<cory_fu> mruffell: +1, I doubt anyone is going to be doing any new deployments onto trusty these days anyway
<thumper> cory_fu: ah... ok
<mruffell> anyway, thank you very much thumper and cory_fu. I will let customer know that wordpress is good again. Plus it makes the documentation where wordpress is used as an example make sense too.
<evhan> thumper: Are you able to invite other users to that openstack tenant? Management > Project Users > (there should be an Invite User button). If not, I might have to add some role.
<thumper> evhan: I'm not sure I'm seeing the same thing you are
<thumper> the Projects element in the Identity section gives me a 403
<evhan> Hrn, that'll be related, 1s caller...
<evhan> thumper: Perhaps now?
<thumper> stil 403
<evhan> Hm, and I don't suppose if you navigate directly to https://dashboard.cloud.catalyst.net.nz/management/project_users/ it'll work?
<thumper> different type of 403, rather than top level 403, which I get for /identity, I get the page rendered with header and side bar, but contents says  "You are not authorized to access this page Login"
<evhan> Curse you, web stuff.
<evhan> Alright, I'll have to check about that and get back to you, soz.
<babbageclunk> review for a backport of my test tweak to 2.7 (now that 2.7.1 is approved)? https://github.com/juju/juju/pull/11115
 * anastasiamac looking
<anastasiamac> babbageclunk: +1
<babbageclunk> thanks!
<Bandu> hi
#juju 2020-01-15
<thumper> ugh...
<thumper> testing parallism is hard
<babbageclunk> review for a small merge to develop anyone? https://github.com/juju/juju/pull/11116
<thumper> babbageclunk: lgtm
<babbageclunk> thanks!
<babbageclunk> and anastasiamac!
<anastasiamac> \o/ same minute :)
<anastasiamac> i was telling u on irc that m looking but it erred on me ;(
<thumper> lucidone: what was the ubuntu sso issue with launchpad?
<thumper> lucidone: do you have a launchpad ID?
<lucidone> I have an ubuntuone login, and logging in to launchpad presented an ubuntuone login form which didn't accept my email/password combination
<thumper> lucidone: what is your login?
<kelvinliu> wallyworld_: https://github.com/juju/juju/pull/11112 got this PR to add MutatingWebhookConfiguration support, could u take a look when u got time? thanks!
<wallyworld_> yup, after meeting
<kelvinliu> ty
<Bandu> hi
<nammn_de> manadart achilleasa pr (show-space) is ready to be reviewed. I still need to run qa on aws. Maas qa seems to be fine. Output and design doc is linked. I still need to match the output a little by adding a custom parser. Though codewise is mostly done: https://github.com/juju/juju/pull/11088
<nammn_de> so I am happy for the first in review :D
<nammn_de> and would be great if you have some error cases in mind as you have a lot of knowledge in spaces
<nammn_de> rick_h:^ for the output of the command. Im thinking about having a --long output which includes subnets sub information and without
<manadart> nammn_de: Finished reviewing.
<manadart> For review: https://github.com/juju/description/pull/71
<achilleasa> manadart: looking
<nammn_de> manadart: great thanks for the review! Almost done, just don't understand this comment: https://github.com/juju/juju/pull/11088#discussion_r366786850
<nammn_de> do you mean rename it to EntityParams?
<manadart> nammn_de: Sorry, I meant `params.Entities`.
<nammn_de> manadart: I have written some tests for applications and machinecount before I moved the methods out of space to a shim to decouple them. The tests itself are a little big and I wouldn't call them unit test as they are using state quite a lot.
<nammn_de> https://github.com/nammn/juju/blob/0f681aff1d504fe2323a082e9ecbaa20cf027259/state/spaces_test.go#L81
<nammn_de> What do you suggest doing with them? Moving them? Changing them?  Removing altogether? TestApplications and TestMachineCount
<nammn_de> hml: i tried to incorporate your feedback on creating stubs and did it the following way: https://github.com/juju/juju/pull/11088/files (under apiserver/...). The tests itselfes still needs to be added. Just want to know if thats what you meant]
<hml> nammn_de: looking
<nammn_de> hml: I tried to not import state in apiserver
<hml> nammn_de:  the common apiserver code is used to pull in common functionality for the apis to use.  not for use by the apiserver side code itself.
<hml> nammn_de: Life() is a good example. and used all over.
<hml> nammn_de: there is a common LifeGetter.
<hml> nammn_de:  pulling the machine common into network common looks odd to me.
<hml> nammn_de:  in apiserver/â¦/spaces/ you can add a Machine interface to be used by the stateShim.  it only needs to implement AddressesBySpaceID() at first glance
<achilleasa> hml: got one question for utils/306
<hml> achilleasa:  just a sec
<hml> achilleasa:  sure, whatâs up?
<achilleasa> hml: just a comment about whether that func must be public
<hml> achilleasa:  yeah, it doesnât have to be, i was following the precendent in the pkg already
<hml> achilleasa:  I could go either way on that
<achilleasa> hml: I think having one entrypoint and delegating to different impls based on the args is cleaner. In this case, the two functions have almost (variadic vs slice for certs) the same signature
<hml> achilleasa:  sure, i can do that
<achilleasa> hml: as I will EOD in a couple of min, do you want to take a stab at the install hook for k8s? Unless I'm mistaken, it should be a matter for removing an if block somewhere...
<hml> achilleasa:  sounds like fun!  :-) a nice change from docs
<nammn_de> hml, : thanks I will keep that in mind, I am still sometimes in a state of figuring out which package is meant for what
<hml> nammn_de: https://pastebin.canonical.com/p/xC2zxW8DBV/
<hml> nammn_de: itâs interesting figuring those bits out.
<nammn_de> hml, : great! yeah it is, asking a lot and reading it up helps me a lot, thanks again
<hml> nammn_de: also put a hint about using collections/set NewStrings() in your pr too.
<hml> itâs very useful!
<nammn_de> hml,: will do :)!
<kelvinliu> wallyworld_: a quick one, forward port webhook pr to 2.7
<kelvinliu> https://github.com/juju/juju/pull/11118
<kelvinliu> thanks!
<wallyworld_> kelvinliu: lgtm
<kelvinliu> ty
#juju 2020-01-16
<kelvinliu> wallyworld_:  https://github.com/juju/juju/pull/11120. +1 plz
<lucidone> Is there a full spec for the charm metadata.yaml somewhere?
<lucidone> Specifically after info for oci-image resources - https://discourse.jujucharms.com/t/charm-metadata/1043 says '"file" is the only type supported currently' ..which is outdated
<thumper> wallyworld_: ^^
<thumper> lucidone: I'm not sure if there is a full spec defined anywhere... there should be
<thumper> but I bet many people just read the code (which isn't the right answer)
<lucidone> Yea, looking at some code it looks like you provide the default image with resources.X.upstream-source ? .. I would expect a "default" key like in config.yaml though
<evhan> lucidone: I think resources: is a hash that the charm can do whatever it wants with.
<lucidone> Ah right, that works too I guess :D I wonder what type=oci-image does if that's the case?
<thumper> lucidone: wallyworld_ or kelvinliu could probably explain the oci-image type resource
<kelvinliu> sorry, just finished standup.
<evhan> AFAICT it's to indicate that it's a reference to an image on a registry (as opposed to a file, meaning it's not a filename).
<kelvinliu> lucidone: oci-image is the container image path.
<thumper> yes, that is right
<lucidone> Ah right, so I guess the main difference in handling is because it's _not_ type=file ?
<kelvinliu> if u defined the docker image path in metadata.yaml file then u can set it in deployment time like `juju deploy x-charm --resource mysql_image=mariadb
<lucidone> So I should have resources.X.oci-image=python:buster?
<lucidone> Ah, that's nice behaviour
<kelvinliu> the charm then can fetch the resource like `layer.docker_resource.fetch('mysql_image')` then set the podspec
<lucidone> How would that look with the operator framework?
<kelvinliu> lucidone: so the format of is same like file resource, https://pastebin.ubuntu.com/p/7Qrt6TX7F4/
<kelvinliu> sorry, i m not familiar with the new operator framework yet.. but i think the metadata format should be same.
<lucidone> Yea, that looks right - I'm just wondering where the default image would fit .. actually looks like OCIImageResource (resources.py) looks for registrypath in the yaml, so that's likely it
<kelvinliu> but the way to fetch the resource in charm might use a different helper function.
<evhan> lucidone: I'm currently translating it into the Python {'containers': {'imageDetails': {'imagePath': 'YOUR_IMAGE_HERE'}}}, which seems to be what the pod model expects.
<kelvinliu> lucidone: https://github.com/johnsca/charm-gitlab-k8s/blob/master/metadata.yaml
<kelvinliu> lucidone: jam have shared u an example charm, right?
<kelvinliu> lucidone: here is how u can fetch the oci-image in charm https://github.com/johnsca/charm-gitlab-k8s/blob/master/src/charm.py#L38
<kelvinliu> lucidone: sorry, missed ur question, how to set default oci-image, so u can attach a resource to charm, then u doesn't have to set --resource in deployment time.
<kelvinliu> here is the doc #charm attach https://discourse.jujucharms.com/t/using-resources-developer-guide/1127
<lucidone> Great thanks for that - yeap, working things out with a mix of that gitlab charm, operator framework source and discourse
<lucidone> And you lot of course :)
<kelvinliu> np :)
<kelvinliu> wallyworld: did u wanna talk to me? sorry, clicked the btn too quickly..
<wallyworld> kelvinliu: all good, jut tanked for for the PR review - all the bakery stuff now landed :-D
<wallyworld> *yhanked
<kelvinliu> wallyworld: awesome, nice work!
<wallyworld> so over it - never want anything from a bakery again
<kelvinliu> haha,
<kelvinliu> wallyworld: got this PR to fix the annoying error messages of worker restarting, https://github.com/juju/juju/pull/11121/files
<wallyworld> looking
<kelvinliu> ty
<wallyworld> kelvinliu: we dont' want to restart the entire agent - we just need to internally restart the watcher
<wallyworld> thomas thinks there may be a new api we can use
<kelvinliu> ok
<wallyworld> kelvinliu: forgot to ask - is the snap integration done and tested now?
<kelvinliu> wallyworld: ah, it should have been done. Im testing the microk8s side with juju now
<kelvinliu> wallyworld: free to HO?
<wallyworld> kelvinliu: sure
<wallyworld> one sec
<flxfoo> Hi all
<flxfoo> quick one, I have a unit in failed state, because of a missing relation... can I remove the relation (which actually does not exists)?
<manadart> flxfoo: What is the unit?
<manadart> Need a review for migrating remote app macaroons. This should be the last piece for migrating CMRs. https://github.com/juju/juju/pull/11122
<flxfoo> manadart: thanks for asking, but I created a new unit... thanks
 * manadart nods.
<achilleasa> manadart: looking
<nammn_de> manadart: i've added your review feedback. Ready for another round: https://github.com/juju/juju/pull/11088
<manadart> achilleasa: I had green tests for that, but CI-run is knocking it back. Might have to rebase...
<manadart> nammn_de: OK, will look in a mo'
<nammn_de> manadart: thanks! I will rebase after successful rev
<achilleasa> manadart: code LGTM. I will run the QA steps next
<nammn_de> manadart: should I wait for rick_h for ux of the cli (adding additional option/changing output)?
<nammn_de> manadart: feel free to bug me if you see the need for me to add additional tests
<achilleasa> manadart: got a small typo in consume command for the QA steps; should read "juju consume cmr-source:admin/default.dummy-source"
<manadart> achilleasa: Ack. Fixed.
<rick_h> nammn_de:  go ahead with it for now to land in edge, please shoot me an email with the notes and I'll try to test it out over the weekend
<rick_h> nammn_de:  I don't want to hold you up but not in a position to poke at stuff atm
<nammn_de> rick_h: okay :-), will do!
<nammn_de> rick_h: can always update /adjust
<rick_h> nammn_de:  <3
<nammn_de> rick_h: just one thing. Do we want to put in under a featureflag?  Some of those are under "PostNetCLIMVP"
<rick_h> nammn_de:  it's only in the develop branch right? As long as it doesn't break things (and a show-* command shouldn't) it's ok
<nammn_de> rick_h: right, it does not break anything and is only on develop
<nammn_de> rick_h: did you mean, it's ok not to put under a featurebranch, as it is in develop and does not break things?
<nammn_de> *featureflag
<rick_h> nammn_de:  yea sorry, it's ok to not be flagged
<nammn_de> rick_h: ð¦¸
<nammn_de> manadart: I replied to 2 comments with some open questions https://github.com/juju/juju/pull/11088
<achilleasa> hml: approved the utils PR. Please ping once you update the toml file on 11094
<hml> achilleasa:  i need to update names.v3 as well a quick pr
<achilleasa> hml: sure, send it my way
<hml> achilleasa: rgr
<hml> achilleasa:  iâm going to have to fix the job dependencies before i can merge
<achilleasa> hml: don't forget to update title for 11119 ;-)
<hml> achilleasa:  :-)
<intrepidsilence> Hi everyone!  I have spent many hours on the web looking for an answer to this and I am stumped.
<intrepidsilence> I have a new install of juju on an lxd/lxc node
<intrepidsilence> juju bootstrap deploy the gui as part of the controller
<intrepidsilence> "juju gui" properly spits out the web address of the GUI server
<intrepidsilence> including the credentials
<intrepidsilence> however, since the juju controller is using a private bridge interface the IP of the controller is private and not accessible remotely
<intrepidsilence> since the controller is "hidden" from lxc/d i cannot expose it using a proxy
<intrepidsilence> since it is the controller I also cannot use juju expose to expose it since it is not technically an application
<intrepidsilence> i even tried ssh tunneling to the private IP and port but that did not work either
<intrepidsilence> so I have no idea how I am going to access the GUI on the remote/private controller
<intrepidsilence> any ideas will be welcomed with open arms and great thanks
<intrepidsilence> fyi - i also tried to deploy juju-gui but that fails with python problems inside of the container it tries to deploy so i am kinda guessing that is not preferred anymore
<intrepidsilence> does anyone know if you can tell juju to use the zfs storage pool that you are already using with lxd as the default pool?
<intrepidsilence> i cannot seem to find an option for that in bootstrap
<thumper> I don't recall, but it certainly seems like a reasonable request
#juju 2020-01-17
<lucidone> How would I log from a k8s charm using the operator framework? (So that the logs show up in the pod logs e.g kubectl -n test-k8s logs -f test-charm-operator-0)
<lucidone> Is that something debugf in ops/main.py will handle (function definition is currently just 'pass')
<lucidone> Ah scratch that, looks like print() does show up in logs - a separate issue meant that chunk of code wasn't getting hit :)
<thumper> Here is a relatively boring PR for someone: https://github.com/juju/juju/pull/11124
<thumper> lucidone: oh, I don't know if we have any way to write into the pod logs
<thumper> wallyworld, kelvinliu: do you know?
<thumper> lucidone: we have a juju-log command that has things show up in the juju debug-log
<thumper> but I don't know if there is a specific one for the pod log
<wallyworld> you can also use kubectl log
<thumper> wallyworld: from the charm?
<wallyworld> not really
<wallyworld> kubectl is for outside the cluster
<thumper> wallyworld: do you think that we should have juju-log commands for k8s models go into the pod log?
<evhan> I think just writing to stdout does the right thing.
<wallyworld> they do go to pod log
<wallyworld> the juju logs to go both the k8s log and the juju log
<kelvinliu> didn't find a juju-log helper method, but you can do this https://github.com/canonical/operator/blob/dd2a0d4537ff9ef2f19354a3fd7a9598e4b4c076/ops/model.py#L605
<evhan> lucidone: For debug-log you can use charmhelpers.core.hookenv.log from https://pypi.org/project/charmhelpers/, works fine with operator.
<evhan> In case it hasn't been reported elsewhere, https://discourse.jujucharms.com is down from here.
<wallyworld> seems to be back now
<tlm> last job!!!!
<wallyworld> whoot
<tlm> i have run them all seperate wallyworld like we discussed to avoid the wait
<wallyworld> tlm: i'm still seeing red dots?
<tlm> yeah that was the job from this morning
<tlm> if you click through you can see the latests ones
<tlm> no way to re run something in jenkins and have latest result trickle up
<wallyworld> ah, didn't realise that
<tlm> but
<tlm> 2.7.1 is released
<tlm> I think
<wallyworld> tlm: snap store thinks so!
<wallyworld> i'll check simplestreams also
<tlm> party time
<wallyworld> and we should check the ppa manually too
<wallyworld> using apt query blah
<tlm> ok i'll jump on one of my ubuntu boxes
<wallyworld> tlm: seem to be missing released simple streams http://streams.canonical.com/juju/tools/streams/v1/
<wallyworld> metadata is in proposed but not released
<wallyworld> maybe there's one more job still to run
<tlm> it's all green when I check
<wallyworld> maybe it takes a few minutes to wash through
<wallyworld> needs to have a job run on jerff
<tlm> ah that guy. It passed
<tlm> https://jenkins.juju.canonical.com/job/release-juju-request-streams-update/120/
<nammn_de> manadart: so i created the initial mocking for apiserver/spaces test https://github.com/juju/juju/pull/11088/  your comment https://github.com/juju/juju/pull/11088#discussion_r367868986 I could not 100% realize. I cannot remove all of my changes from StubNetwork, because it needs to implement Backing so I just left it there. Which can be fixed
<nammn_de> later when we move more and more tests from stubs to gomock
<manadart> nammn_de: I think we could wrap the StubNetwork with with empty stubs for those methods, and remove them. They won't be called from the old tests.
<manadart> Remove them from StubNetwork that is.
<nammn_de> manadart:  how would you do that?  My initial idea would be to just remove all of the code I added and just add those 2 stub methods :
<nammn_de> AllEndpointBindings  AllMachines without any logic and just return
<manadart> nammn_de: Yes.
<nammn_de> manadart: the other "problem: i've encountered was: because we already have a test lying in spaces_test package I could either: put the new test based on macks in a newfolder or let it be in spaces for now, I put it in spaces for now
<manadart> nammn_de: In the spaces package is OK. As long as it is suffixed with _test.go, it will only be built for tests. We do this in other places.
<manadart> spaces_mock_test.go would follow the convention.
<manadart> That's the mock. The tests can stay in spaces_test and import the mock.
<nammn_de> manadart: what i found out from looking at the other packages is the following: mocks are under ../mocks/ and follow the naming of <interface/topic>_mock.go and the test itself is under <api>_test.go, but as we have both (stub and mock tests) I need to choose a new name. This would lead to spaces_mock_test.go, right?
<nammn_de> and later when we have moved all from spaces_test, spaces_mock_test will be spaces_test
#juju 2020-01-19
<palaueb> hello
<palaueb> now I have my maas working with the machines in Ready state, any tutorial to follow that gives me more inside of how to deploy an openstack?
<palaueb> Thanks!
<anastasiamac> tlm: kelvinliu: a really trivial review plz :D https://github.com/juju/juju/pull/11125
<tlm> looking
<kelvinliu> lgtm
<anastasiamac> \o/
<tlm> drats :)
<anastasiamac> :)
<kelvinliu> lol
