#juju 2011-12-12
<_mup_> Bug #903014 was filed: relation-broken runs in inappropriate context <juju:In Progress by fwereade> < https://launchpad.net/bugs/903014 >
<_mup_> Bug #903016 was filed: relation-broken hooks will not always be fired <juju:In Progress by fwereade> < https://launchpad.net/bugs/903016 >
<_mup_> Bug #903017 was filed: unit workflows stop/start inappropriately <juju:In Progress by fwereade> < https://launchpad.net/bugs/903017 >
<_mup_> Bug #903018 was filed: charm upgrade is dangerous <juju:In Progress by fwereade> < https://launchpad.net/bugs/903018 >
<EvilBill> I keep seeing that the juju client is in macports - yet it's not listed on the macports site, and a "port search juju" comes up empty. Am I missing something?
<EvilBill> I found something on itâ¦ https://trac.macports.org/ticket/30237
<EvilBill> Not directly installable though.
<SpamapS> EvilBill: its pure python, so once you have libzookeeper, I believe you can just use setup.py to install it
<EvilBill> SpamapS: Hm, I'll try that.
<EvilBill> grabbing libzookeeper from macports now
<SpamapS> EvilBill: actually you'd also need txzookeeper too
<EvilBill> I'll try that :)
 * SpamapS thinks at some point we need to have releases to coordinate these ports/targets
<EvilBill> I agree.
<EvilBill> things need to coalesce a bit.
<EvilBill> documentation too.
<EvilBill> blah, txzookeeper isn't in macports, and libzookeeper failed to build.
<EvilBill> Will look at this later, then
<SpamapS> EvilBill: there's also virtualbox. :)
<EvilBill> True :)
 * SpamapS has been native on his macs for over a year now. :)
<EvilBill> I've got other linux machines around here too.
<SpamapS> I still flip back to OS X to update the OS on my iphone tho. :-P
<EvilBill> regular lab environment.
<EvilBill> But I use a Mac as my "desktop" environment to protect myself from myslef.
<EvilBill> If I am on a linux desktop, I tend to try out new stuff constantly
<EvilBill> in search of the newest shiny
<EvilBill> and eventually I break it.....
<EvilBill> and then my main desktop environment is screwed up, and I spend time not working to FIX it.
<SpamapS> yeah I used to have that running Debian sid on my workstation.. my laptop was always the more stable box. :-P
<SpamapS> Now I have my smaller laptop (MacBookAir 11") on Ubuntu 11.10, and my dev laptop (MBP 15") is precise.. works pretty well.
<EvilBill> Yep.
<EvilBill> Nice.
<SpamapS> the Air, running Unity 2D, gets 5.5hrs battery life.. just barely less than it did in OS X (about 6hrs)
<EvilBill> NICE.
<EvilBill> I need to setup a ubuntu machine with a gui again.
<EvilBill> I have a bunch of server-type stuff
<SpamapS> marcoceppi: btw, thanks for the updates, merged
<SpamapS> EvilBill: I'm kind of addicted to apple's hardware. Having an apple store 1 block away from the house is really 90% of the problem. ;)
<EvilBill> SpamapS: I'd be SO broke if that happened.
<SpamapS> Yeah like, when it came time to buy a new, smaller laptop.. I could have probably gotten a much better deal on a Lenovo .. but the air is *so* pretty.. and *so* thin.. and I *so* just got to walk out of the store with it. ;)
<EvilBill> Yep.
<EvilBill> I have way too much apple gear too.
<EvilBill> Hell, I have a CUBE.
<niemeyer> Good mornings!
<koolhead11> hi all
<niemeyer> koolhead11: Hey there
<koolhead11> niemeyer: hello.
<koolhead11> i upgraded my juju from PPA
<koolhead11> sudo add-apt-repository ppa:juju/pkgs && sudo apt-get update && sudo apt-get upgrade juju
<koolhead11> but i can still not see the details error log
<koolhead11> *detailed
 * koolhead11 is yet not able 2 deploy the simplest charm he wrote :(
<niemeyer> koolhead11: Sorry, I'm out of context.. why isn't it working?
<koolhead11> niemeyer: https://code.launchpad.net/~koolhead17/charm/oneiric/boa/trunk
<koolhead11> i am trying to execute it vila LXC
<niemeyer> koolhead11: You mean via the local provider?
<koolhead11> niemeyer: yes
<koolhead11> niemeyer: also http://paste.ubuntu.com/767706/
<koolhead11> why is it searching 4 example inside oneiric :(
<niemeyer> koolhead11: Because that's the default Ubuntu series.. you've provided none, so it picked the default oe
<niemeyer> one
<niemeyer> koolhead11: local:foo is the same as local:oneiric/foo when "oneiric" is the default
<koolhead11> niemeyer: i have directory structure like this /home/atul/example/oneiric/charm
<koolhead11> so when i say juju deploy --repository=example local:boa
<niemeyer> koolhead11: So it looks like you're passing the wrong path in the command line
<koolhead11> it means /home/atul/example/oneiric/boa
<niemeyer> koolhead11: --repository=/home/atul/example is probably what you want
<koolhead11> niemeyer: ok let me try that way
<koolhead11> niemeyer: no luck . :( http://paste.ubuntu.com/767711/
<kickinz1_> quit
<koolhead11> kickinz1_: /quit will work :D
<niemeyer> koolhead11: Can you please paste "cat ~/example/oneiric/boa/metadata.yaml"?
<koolhead11> sure
<koolhead11> niemeyer: http://paste.ubuntu.com/767715/
<niemeyer> fwereade: Morning
<fwereade> heya niemeyer
<fwereade> niemeyer, nice weekend?
<niemeyer> fwereade: Sorry for being slow on the stop stuff.. I've been thinking about it, and would actually like to talk to you today at some point
<niemeyer> fwereade: It was ok.. was traveling back home from SF
<fwereade> niemeyer, don't worry about it, it emerges that there's enough subtlety to the general restart problem that I've been quite occupied already ;)
<fwereade> niemeyer, sounds like a fun conference
<niemeyer> fwereade: It was really nice
<fwereade> niemeyer, and ofc I'd be happy to talk about it whenever makes sense for you, but be warned I'm a bit slow/stupid today, I was up late massaging the restart-transitions branch into digestible chunks
<niemeyer> fwereade: Ah, same thing here.. I woke up at 6AM, which is around noon in the timezone I was a couple of days ago, so my body has no idea about what's happening whatsoever.
<fwereade> niemeyer, heh :)
<niemeyer> koolhead11: That's quite weird..
<niemeyer> koolhead11: It looks fine
<koolhead11> niemeyer: exactly :D
<niemeyer> koolhead11: What does "dpkg -l juju" say?
<koolhead11> 1 sec
<koolhead11> niemeyer: ii  juju           0.5+bzr427-1ju next generation service orchestration system
<koolhead11> am using Oneiric as local LXC for my work
<koolhead11> interesting thing is the same directory i have kept mysql charm and it runs without any error
<niemeyer> koolhead11: I think you're hitting a bug in the charm detection logic, but I can't quite spot where yet
<koolhead11> niemeyer: would you suggest me to ask a question under launchpad section for the anser?
<koolhead11> *answer
<koolhead11> also was wondering do i need to install any pkg on barebone machine to get DEBIAN_FRONTEND=noninteractive working?
<niemeyer> koolhead11: No, that's just a hint for the packaging infrastructure to not ask any questions
<niemeyer> koolhead11: Can you please run "which juju", just in case?
<koolhead11> niemeyer: /usr/bin/juju
<niemeyer> Ok
<niemeyer> koolhead11: I guess we'll have to debug it..
<niemeyer> koolhead11: Hmm
<niemeyer> koolhead11: I have a guess, actually
<koolhead11> niemeyer: you want me to pastebin all steps and infos so it becomes easy to reproduce?
<koolhead11> and on other side my  default mysql charm is working prefectly
<niemeyer> koolhead11: Can you please add this to your metadata.yaml:
<niemeyer> revision: 0
<niemeyer> koolhead11: Right below "name:" (not that it makes a difference.. we just put it there usually)
<koolhead11> niemeyer: ok. BTW i created a blank revision file inside that boa charm
<koolhead11> am adding as u suggested
<koolhead11> niemeyer: http://paste.ubuntu.com/767737/
<niemeyer> koolhead11: Cool, at least we know it's looking at it
<koolhead11> niemeyer: am confused earlier it said sumthing else in error
<niemeyer> koolhead11: let's try this: please open a python prompt
<niemeyer> koolhead11: and type this:
<niemeyer> from juju.charm.provider import get_charm_from_path
<koolhead11> k
<niemeyer> koolhead11: Now run:
<koolhead11> hmm
<niemeyer> d = get_charm_from_path("/home/atul/example/oneiric/boa")
<niemeyer> print d
<koolhead11> niemeyer: http://paste.ubuntu.com/767746/
<koolhead11> i have a empty file with name revision created there as well
<niemeyer> koolhead11: Ok, we got it
<niemeyer> koolhead11: Can you please file a bug pointing out that this error is being eaten up silently?
<niemeyer> koolhead11: The revision file should have an int in it
<niemeyer> koolhead11: You can use 0 there
<koolhead11> niemeyer: in the file simply write 0 ?
<niemeyer> koolhead11: Yep
<koolhead11> niemeyer: and what will be the bug description i will file?
<koolhead11> empty revision file results in this
<koolhead11> niemeyer: your so damm right. i can execute the charm for Boa
<koolhead11> :D
<niemeyer> koolhead11: Sweet
<koolhead11> SpamapS: hazmat yay!! my simplest charm is working !! :D
 * fwereade cheers
<koolhead11> fwereade: :D
<koolhead11> niemeyer: i am not sure what i should write in bug description. Its just my foolishness of not mentioning anything in revision file i suppose :D
<niemeyer> koolhead11: No, it wasn't your fault at all
<niemeyer> koolhead11: It can't silently say that the charm isn't found when it's clear that there's a charm in that location
<niemeyer> koolhead11: As a hint, the summary may be "juju fails silently with empty revision file"
<koolhead11> niemeyer: ok doing right away.
<niemeyer> koolhead11: Them copy both the pasted where you run the command and get a "no charm" error, and then python prompt dump
<niemeyer> s/and then/and the
<koolhead11> k
<niemeyer> koolhead11: Thanks a lot
<koolhead11> niemeyer: thanks 2 you as well :D
<_mup_> Bug #903149 was filed: juju fails silently with empty revision file. <juju> <juju:New> < https://launchpad.net/bugs/903149 >
<TheMue> Oh, just found out how nicely Emacs integrates with Bazaar.
<H3llGhost> Hello
<TheMue> niemeyer: Just comparing EC2 in Py and Go. What does var _ juju.Environ = (*environ)(nil) do? AFAIK I would say it create an unnamed nil reference to an environment. But why is that needed?
<niemeyer> TheMue: http://golang.org/doc/go_faq.html#guarantee_satisfies_interface
<TheMue> niemeyer: thx, ic. never checked it this way, only later when using an interface implementation.
<jrgifford> EvilBill: you have a CUBE?! whoa.
 * jrgifford </end-offtopic-stuff>
<TheMue> niemeyer: Could you shortly describe the state of the Go port compared to the Py code? I'm currently comparing the EC2 providers (trying to understand the bootstraping).
<niemeyer> TheMue: It's in its early infancy at the moment
<niemeyer> TheMue: We're just catching up some momentum in the last couple of weeks
<TheMue> niemeyer: How's the roadmap of the Go port? Do we first provide some supporting tools do we start from ground e.g. with initializing and bootstrap?
<niemeyer> TheMue: Yeah, we have to get it to the point of initializing and bootstrapping
<niemeyer> TheMue: After that it's a lot easier to fork off development
<TheMue> niemeyer: Btw, tutorial worked fine immediately, as expected. ;)
<niemeyer> TheMue: That said, there are already areas that may be explored in parallel
<TheMue> niemeyer: OK
<TheMue> niemeyer: I started with bootstrap just to keep the order of the steps I've done during the tutorial.
<niemeyer> TheMue: Started in which sense?
<TheMue> niemeyer: I'm trying to understand the bootstrap and how the first instance is setup. So I followed the Py code to the EC2MachineProvider. And here I also wanted to see, how far I can find similar in the Go port.
<niemeyer> TheMue: Aha, cool
<niemeyer> TheMue: The Go code is lacking at that point already
<TheMue> niemeyer: Yep, I've seen
<niemeyer> TheMue: rog actually has logic for that
<niemeyer> TheMue: But we stepped back one of his branches, and now we're moving forward in slower increments with better testing
<TheMue> niemeyer: The Py code is using generators very much. Nice.
<niemeyer> TheMue: I don't find it so nice, but we're fixing that.. :)
<TheMue> niemeyer: Hehe, it's not everyones logic.
<TheMue> niemeyer: Btw, I would like some more verbose naming for public types, funcs etc. ReadEnvironmentsFile() instead of ReadEnvirons().
<niemeyer> TheMue: It's not a generator really.. it's manual coroutine-like yielding
<TheMue> niemeyer: Old Smalltalker school.
<niemeyer> TheMue: Our convention is somewhere in the middle
<niemeyer> TheMue: Long names do really help readability if you go overboard with them
<niemeyer> TheMue: I can show you snippets with that convention being used where it ends up looking like reading a book
<TheMue> niemeyer: I found them always helpful during long term maintenance of code. It depends on the visibility.
<TheMue> niemeyer: Inside of funcs or even loops I often use simple one char vars too.
<niemeyer> TheMue: Depends on a lot of things.. If we use Environs everywhere, calling it Environments doesn't help much, for instance
<niemeyer> TheMue: I appreciate readable code, though.. so let's see if we can get to agreement as we go
<TheMue> niemeyer: Don't think it will be a problem.
<_mup_> txzookeeper/trunk r46 committed by kapil.foss@gmail.com
<_mup_> [trivial] update pypi license metadata
 * koolhead11 finds db-relation-changed most tricky part of writing charm!! :P
<hazmat> g'morning
<koolhead11> hola hazmat
 * hazmat catches up
<hazmat> koolhead11, congrats on the charm
<_mup_> Bug #903213 was filed: need supporting code to help upstartify services <juju:In Progress by fwereade> < https://launchpad.net/bugs/903213 >
<koolhead11> hazmat: thanks!! :)
<fwereade> hazmat, if you have the appetitie for it, I have a horrifying pipeline of reviews
<fwereade> hazmat, um... think how much worse it would be if there were fewer than 9 branches ;)
 * fwereade hangs head in shame
<fwereade> hazmat, it's basically the monster that grew from restart-transitions broken into 4; the upstartify-agents followup broken into 2; and then the other branches I'd already had dangling off those 2
<fwereade> hazmat, for convenience, they go in this order: http://paste.ubuntu.com/767923/
<hazmat> fwereade, thanks, the roadmap is very helpful
<hazmat> as are the small branches
<fwereade> hazmat, I also ended up writing a short essay clarifying just what the hell I was doing in restart-transitions
<fwereade> hazmat, http://paste.ubuntu.com/767947/
<fwereade> hazmat, it's a general discussion of all 4 initial branches
<fwereade> hazmat, or, what *became* the 4 initial branches
<niemeyer> Lunch time..
<jcastro> marcoceppi: hi!
<jcastro> mainerror: wow, looks like nijaba was busy while I was away
<marcoceppi> jcastro: Morning!
<jcastro> I meant marcoceppi
<marcoceppi> Yeah he was
<jcastro> oh cool, freeciv.
<jcastro> looks like I have a bunch of blogging to do
<mchenetz> Hi everyone...
<mchenetz> I was playing around with Juju this weekend and i had a few observations...
<jcastro> marcoceppi: is roundcube ready?
<marcoceppi> jcastro: It's in the "charm store" nijaba has some improvements to it that I have yet to review. Primarily the peer relation thing
 * jcastro nods
<jcastro> man, your awesomeness knows no bounds.
<jcastro> mchenetz: just ask!
<hazmat> fwereade, That's awesome, minus the branch review that should get into the internal docs.
<mchenetz> The, "add-relation haproxy:reverseproxy wordpress:website" command does not actually work that with local provider. It creates server entries in haproxy that forward to local host instead of the server.
<mchenetz> I am thinking there has to be better differentiators from when something is actually hosted remotely vs local
<mchenetz> I am working on some charms for Security... IPS with Snort, Event correlations engines, etc...
<jcastro> that sounds great
<mchenetz> That is just the start. I am very excited about Juju. :-)
<jcastro> https://juju.ubuntu.com/Charms
<mchenetz> Right now i am working on getting my openstack servers running...
<jcastro> there's a link there to the spreadsheet, if you want to claim a charm and update it's progress
<jcastro> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoW1nhI7IMt3dFRvSFdkZmNqQ0t3RjZ2QTR2Z19teWc&hl=en_US#gid=0
<mchenetz> Okay, i will do
<jcastro> we're doing that so people don't spend like a day doing something that someone else is working on, etc.
<jcastro> marcoceppi: and limesurvey, done?
<mchenetz> That makes sense...
<marcoceppi> jcastro: mhumm
<jcastro> marcoceppi: heh, it would be cool to get some other team in the project to run a survey
<marcoceppi> jcastro: What?
<mchenetz> Added snort to the spreadsheet
<jcastro> marcoceppi: I'll find a team in ubuntu that needs to run a survey, and have them try the charm
<marcoceppi> Ohh, that would be awesome
<TheMue> jcastro: Thx for the shared folder.
<koolhead11> jcastro: owncloud2 is still not in our repo, in order to write its charm, can i use it from source/github?
<jcastro> sure
<koolhead11> jcastro: i have added my name against it there in the spreedsheet
<jcastro> IMO having a config to use the latest stable upstream version should be a feature of every charm.
 * jcastro hopes SpamapS doesn't hear
<koolhead11> jcastro: :P
<nijaba_afk> jcastro: hard to do if there is no way to get she sha1 or md5 of the latest tarball.  Sourceforge does not help in that way....
<jcastro> ah bummer
<m_3> morning
<jcastro> m_3: welcome back!
<SpamapS> jcastro: wait the spreadsheet should not be the canonical source of who is working on what. launchpad bugs should be. The spreadsheet is just an easier way to gather the new charm efforts.. or so I thought.
<m_3> jcastro: you too
<jcastro> SpamapS: you are correct.
<SpamapS> jcastro: oh, and welcome back. :)
<jcastro> mchenetz: hey can you file a bug on each of the charms you want to work on?
<SpamapS> jcastro: perhaps we need to change the process for the new-charm tag so that people can file a bug with that tag on it immediately, and then we'll review when they change the status from New to Confirmed...
<nijaba> heya SpamapS
<jcastro> SpamapS: I don't think we have enough people doing that to warrant a new tag
<jcastro> but yeah
<SpamapS> jcastro: we should have an explosion of "I'm working on X" in the next couple of months.
<SpamapS> jcastro: so I'd like to make sure if nothing else that we all agree on what people should do. I didn't even know the spreadsheet was public. ;)
<SpamapS> Figured it was just shared with a few of us charmers or something.
<SpamapS> nijaba: good morning. :)
<nijaba> good morning marcoceppi
<marcoceppi> morning nijaba
<jrgifford> marcoceppi: hey, you're back!
 * marcoceppi curses IRCCloud
<jrgifford> don't suppose there are any decent alternativess for irc cloud yet?
<nijaba> SpamapS: so, you think that sharing an sshkey via zk, then sending a private key via ssh is more secure than sharing the private via zk directly?
<nijaba> SpamapS: I figured that if I can get access to the ssh key in zk, it is the same than getting access to the ssl private key, no?
<nijaba> SpamapS: at leas this is the way I implemented it in roundcube charm (waiting for review/promulgation)
<jcastro> jrgifford: I have a charm for alice IRC, but it's broken right now, waiting on upstream to stick it in cpan
<jrgifford> jcastro: awesome.
<SpamapS> nijaba: I'm concerned about *storing* the private key in ZK, vs storing the public key there.
<SpamapS> nijaba: at least if its just the public key, they can only MITM future connections, they can't decrypt past traffic.
<nijaba> SpamapS: ah, so the pub key would be used to accept conection from a master to get the key.  smart...
<nijaba> SpamapS: I'll change that then
<SpamapS> nijaba: granted, the public ssh key could be used to login and steal the private key, so I may be overthinking it.
<hazmat> mchenetz, re local vs. remote.. the idea is to minimize the differences, that particular problem is a bug in the wordpress charm.. there's an additional cli hook api for resolving the public/private addresses in a provider agnostic manner
<SpamapS> nijaba: this is why, IMO, juju cannot be trusted for secure work until we have *tight* ACL's on the data.
<nijaba> SpamapS: well, not to login, but to get logged in.  So one would have to insert a host as a juju "slave" and generate a peer-joined event to get the key.  not 100% secure, but harder than just grabbing it from zk
<SpamapS> nijaba: quite trivial actually. All nodes have full access to ZK right now.
 * SpamapS wonders how that bug got bumped down in priority given the production focus for this cycle
<mchenetz> hazmat: No problem... Just an observation.
<SpamapS> mchenetz: could you report that as a bug, https://launchpad.net/charm/+source/wordpress/+filebug
<mchenetz> Spamaps: no problem, I will report it
<SpamapS> mchenetz: thanks!
<mchenetz> Spamaps: you had asked me the other day about my observations about Local Provider vs Vagrant... Here you go..
<mchenetz> Vagrant: Able to easily deploy on multiple OSs
<mchenetz> Vagrant: Able to maintain state after reboots
<mchenetz> Vagrant: Base OS is accessible on creation
 * SpamapS puts an extra layer of asbestos on juju
<mchenetz> Local-provider: Easy to create on linux (Other OS's require work)
<mchenetz> Local-Provider: Base OS is not accesible until initial charm is installed (At least not to my knowledge)
<mchenetz> Local-Provider: Does not maintain state (on this version)
<negronjl> SpamapS: approved lp:~clint-fewbar/charm-tools/add-tests
<SpamapS> mchenetz: THANKS, great thoughts, quite helpful
<SpamapS> negronjl: w00t
<zirpu> negronjl: did you post your slides from mongosv?
<negronjl> zirpu: not yet but, I will. Trying to figure out the best way to do that ... any suggestions ?
<zirpu> slideshare? it's pretty common now. i think it accepts pdfs.
<fwereade> hazmat, jimbaker, bcsaller: standup?
<SpamapS> mchenetz: So, to address some of the things..    multi-OS .. somebody just needs to write a provider that uses virtualbox and we'll that bit.. but agreed, we're targetting Ubuntu right now. :)
<SpamapS> mchenetz: The base OS is meant to be very "standard" because charms do all the customization, so I'm not sure thats a problem in juju.
<SpamapS> mchenetz: the ability to reboot is landing in a series of reviews right now actually
<mchenetz> Spamaps: I am just think of what a development team would use... Most the devs i see work on a mac or pc and then will push stuff to the cloud.
<mchenetz> So they could be working on windows or osx... Having the Vitualbox image allows them to work in a similar environment..
<mchenetz> The one nice thing they did was expose the inited directory to the VM so that users can easily copy files into the OS directory and they can be seen on the VM.
<mchenetz> I think that is a great feature for people that don't know that much about VMs and then really don't have to.
<SpamapS> yeah containers are nice that way
<mchenetz> Any quick tip on, "pty-allocation-request-failed-on-channel-0"
<jimbaker> fwereade, works for me
<bcsaller> yeah, I'm around too if there are things we have to cover
<m_3> mchenetz: I've been able to recover from that by wiping my lxc cache
 * m_3 looking for the cache
<fwereade> hazmat, jimbaker, bcsaller: I think I've invited you all
<mchenetz> m_3: how do i go about doing that?
<m_3> mchenetz: I'd start with a 'juju -elocal destroy-environment'
<mchenetz> m_3: i just created the environment. :-(
<m_3> mchenetz: then rm -Rf /var/cache/lxc/
<mchenetz> m_3: okay i will try. Thanks...
<m_3> mchenetz: might not be the same problem you're seeing, but that worked for me
<m_3> mchenetz: I'd have a local env that gets corrupted after a couple of weeks of solid usage... clearing the lxc cache resets me to working local env
<m_3> mchenetz: remember that the first 'juju deploy' after a cache wipe is going to take a _long_ time
<marcoceppi> What's the policy for charm-contributors again? "Open" group, right?
<m_3> marcoceppi: code of conduct signed
<mchenetz> m_3: sounds good trying now
<marcoceppi> m_3: o/ and thanks
<zirpu> is the 1st environment in ~/.juju/environments.yaml the default?
<marcoceppi> zirpu: No, if you have multiple environments and don't have a default: key set or use the -e flag juju will throw an error
<m_3> zirpu: there's a 'default:' top-level entry in environments.yaml...  I see code that gripes if there're multiple envs w/o a default
<zirpu> you mean an environment var set?
<zirpu> like: export JUJU_ENVIRONEMTN=foobar
<zirpu> (minus typos)
<m_3> zirpu: at the moment you have to explicitly set a default through the e
<m_3> 'default' key in environments.yaml or via the command line option '-e' on all commands
<EvilBill> Jrgifford: Yeah, I have a cube. Hotrodded with an Nvidia gfx card and 1.5GB RAM. Though I don't use it and it sits in the garage...
<m_3> zirpu: a shell env variable such as JUJU_ENV was discussed on the list... dunno if it's going to be implemented though
<mchenetz> Spamaps: Bug report submitted
<mchenetz> Bug id:903312
<mchenetz> m_3: that worked... Thanks
<mchenetz> Although, that corruption error could be a potential problem and/or bug for local provider
<m_3> mchenetz: yes agree... filing the bug now so we at least have a place to capture the lxc cache reset
<mchenetz> m_3: sounds good
<_mup_> juju/ssh-known_hosts r437 committed by jim.baker@canonical.com
<_mup_> Added support for ssh_keys in format_cloud_init
<_mup_> Bug #903318 was filed: juju ssh fails on local provider: pty-allocation-request-failed-on-channel-0 <juju:New> < https://launchpad.net/bugs/903318 >
<m_3> mchenetz: ^^ is the bug... please verify what you did to get it working again.
<mchenetz> m_3: exactly... I would attempt to perform an SSH to a service/0 or whatever and i would get pty-allocation-request-failed-on-channel-0
<m_3> mchenetz: thanks
<mchenetz> The fix would be to do, juju detroy environment, and rm -Rf /var/cache/lxc/
<niemeyer> WOohay.. lbox submit works
 * SpamapS confirms that bug and marks it High
<jcastro> marcoceppi: do you have a snippet/function handy for the config switch to pulling an upstream version handy?
<marcoceppi> The phpMyAdmin implementation for doing a switch is crazy ugly. You can look at it for ideas, it's implemented in lib/common.sh
<marcoceppi> In a nut shell install_phpmyadmin is called during config-changed which, depending on the current installed version and the value in each hook, will call install_upstream or install_apt
<marcoceppi> Then there are two environments in env/ which load the appropriate variables for each case :\
<marcoceppi> At one point it does a barrel roll, then viola!
 * SpamapS would have liked to see an immelman
 * marcoceppi does an Immelman turn
<jcastro> thanks!
<marcoceppi> Np, I'd like to make this a lot more cleaner but still trying to hash out the best way to do it
<marcoceppi> and by a lot more cleaner, I mean a lot more clean
<jcastro> SpamapS: I think I am getting this bug: https://bugs.launchpad.net/juju/+bug/891419
<_mup_> Bug #891419: Juju fails test suite when building on precise <juju:Fix Released> < https://launchpad.net/bugs/891419 >
<jcastro> when trying to bootstrap, my precise is up to date as of today
<jcastro> SpamapS: nevermind.
<SpamapS> jcastro: mind never'ed
<EvilBill> jcastro!
<jcastro> hiya bill!
<EvilBill> how's it going?
<jcastro> about to test the limesurvey charm so I can blog it
<EvilBill> cool
<EvilBill> btw
<EvilBill> stop saying that you have a macports client.
<EvilBill> there isn't one that usable that I can find
<EvilBill> I just checked out the SVN version of macports, and its' not in there.
<jrgifford> EvilBill: speaking of mac clients, i haven't found anything either.
<EvilBill> hey jrgifford
<jcastro> lynxman: heya, mac client?
<EvilBill> I see this:
<EvilBill> https://trac.macports.org/ticket/30237
<EvilBill> but that isn't something can can be "port install'd"
<lynxman> jcastro: waiting on approval...
<lynxman> EvilBill: it can be port installed :)
<EvilBill> lynxman: Great! How?
<lynxman> EvilBill: just download the Portfile from there and add a local repository on your machine
<EvilBill> I tried that last night, it blew up on some zookeeper dependency.
<lynxman> EvilBill: because it depends on several portfiles, one of them being zookeeper
<EvilBill> I'm putting ports on this new mac here at work, and I'll try it on this
<lynxman> EvilBill: there's 7 tickets open for this :)
<lynxman> EvilBill: so you'll need to fill all the dependencies, unfortunately
<EvilBill> awesome, how can I get onboard to add my voice to the crew?
<lynxman> EvilBill: I've been talking with the #macports guys for a while, but it's a very very very slow process
<EvilBill> Great.
<EvilBill> I see that the juju portfile you submitted has been there for two months.
<EvilBill> and the version it refers to is 0.5+bzr398
<lynxman> EvilBill: if you want to get all portfiles, tickets 30221 30222 30223 30236 31570 30237
<lynxman> EvilBill: that's the one in Oneiric release
<jcastro> I thought there was some new sexy replacement for macports all the kids are all excited about
<EvilBill> ok
<marcoceppi> How hard would it be to build it into a "native" mac osx application?
<hazmat>  jcastro there is.. homebrew
<EvilBill> marcoceppi: I have no idea. My guess is you'd need to package up all the dependenciesâ¦ like zookeeper, twisted, yaml, etc, into one monolithic bundle.
<EvilBill> yeah, homebrew is up and coming, but no idea how well that thing works.
<marcoceppi> EvilBill: sounds like a pain :\
<EvilBill> marcoceppi: Yeah, I tend to agree.
<lynxman> marcoceppi: quite difficult, specially following all the packaging guidelines and meeting all requirements
<lynxman> marcoceppi: and I'm in no way a OSX packaging expert :)
<hazmat> homebrew does /usr/local installs afaicr, while macport/fink use sandbox dirs off /opt i believe
<lynxman> hazmat: correct
<hazmat> hm..homebrew chilling with 400 outstanding pull requests, its the most active of the bunch that i know
<hazmat> and it already has zookeeper and zookeeper python
<hazmat> https://github.com/mxcl/homebrew/blob/master/Library/Formula/zookeeper.rb
<hazmat> the rest of juju is basically pure python libs
<jcastro> https://bugs.launchpad.net/charm/+bug/903361
<_mup_> Bug #903361: Charm needed: Alice IRC <new-charm> <juju Charms Collection:New for jorge> < https://launchpad.net/bugs/903361 >
<jcastro> my charm is finally ready!
<jcastro> (for review)
<jcastro> spent this whole time wrestling building the thing from source, ends up it was in the archive as of 11.10. :-/
<hazmat> hmm.. given that.. maybe the osx story just becomes use pip/easy_install to get juju
<hazmat> post homebrew install zookeeper
<jcastro> ok so who wants to put this in homebrew?
<jcastro> we need something for OSX people
<EvilBill> in my experience, macports is still the thing people go to
<EvilBill> our guys around here use it a lot
<EvilBill> I say lean on the macports guys
<EvilBill> if it's ready to go, it shouldn't be a big deal to get it in
<mchenetz1> I feel homebrew is the new macport
<jrgifford> maybe out west. around here, most of them are homebrew people.
<mchenetz1> I use brew now
<mchenetz1> Macports is old school
<hazmat> EvilBill, https://trac.macports.org/ticket/30237
<hazmat> that's the juju portfile
<EvilBill> hazmat: thanks
<hazmat> it doesn't seem like we've addressed some of the original upstream comments
<hazmat> er. distributor
<mchenetz1> Maybe its because I do a lot of rails development and brew seems big in the rails world
<lynxman> hazmat: they have been addressed, I had to open a new ticket
<lynxman> hazmat: the whole process is a bit of a pain though :/
<SpamapS> mchenetz: would be nice if there was just one. :)
<SpamapS> lynxman: is anybody even responding to these? they're all so old
<marcoceppi> Looks like Pecl and Pear's queue for acceptance. Dead
<EvilBill> lynxman: hey, you submitted byobu. Awesome.
<EvilBill> ok, here I go trying to build juju via macports.
<EvilBill> and libzookeeper failed to build
<EvilBill> *headdesk*
<mchenetz1> Evullbill: tell me what you did after your done and I will try it too...
<EvilBill> mchenetz1: I can't even get that far. Libzookeeper (a dependency, but one that macports knows about) blows up on build.
<mchenetz1> I will try to figure it out when I get home...
<mchenetz1> If I figure it out before you then I will tell you what I did...
<EvilBill> Thanks.
<EvilBill> I'm going to get a sandwich before my next meeting.
<_mup_> Bug #903392 was filed: Vagrant as a cross-platform local provider? <juju:Triaged> < https://launchpad.net/bugs/903392 >
<mchenetz1> Vagrant as a local provider would be great... I think the two projects will work well together..
<m_3> mchenetz1: might be lightweight ways to just wrap the current local provider
<m_3> but either way... something there
<m_3> lower that barrier to people getting to take juju out for a spin
<mchenetz1> Sounds good... I am very interested in this piece of juju
<mchenetz1> I think that is one of the biggest issues right noe
<mchenetz1> Now
<EvilBill> looks like I picked the wrong week to quit sniffing glue...
<_mup_> juju/ssh-known_hosts r438 committed by jim.baker@canonical.com
<_mup_> Tests pass with dummy provider - a start
#juju 2011-12-13
<rog> mornin'
<koolhead11> hi all
<mpl> 'lo rog, koolhead11
<koolhead11> how are you mpl
<mpl> fine enough, thank you.
<sanderj> Do anyone know if the juju openstack version have a webinterface for managing vm's? something like horizon?
<koolhead11> sanderj: no it does not
<sanderj> :(
<koolhead11> sanderj: horizon is too new and because of rapid development packaging it becomes difficult. am sure once Essex comes you will have it all :D
<uksysadmin> you promise koolhead11 ? ;-)
<TeTeT> I thought dashboard is the openstack web management console?
<sanderj> koolhead11, will it be horizon which will be the userinterface?
<uksysadmin> sanderj, Horizon is the Web UI of choice for managing a private OpenStack cloud environment
<uksysadmin> there are alternatives though
<uksysadmin> that one is one of the projects under the OpenStack banner though
<koolhead11> uksysadmin: +1 :D
<uksysadmin> I use Hybridfox under Firefox - nice way of managing multiple clouds (although there is no direct connection between your private and public cloud per se)
<uksysadmin> It isn't closely knitted to OpenStack though like Horizon - but functional enough if you manage a small private OpenStack cloud and a small amount of public instances
 * koolhead11 smiles
<sanderj> I've tried to set up horizon, without luck.
<uksysadmin> it is a pain in the ass - in fact I've just posed a q in #openstack on the best way of installing it
<sanderj> Unable to log in, just get directed to some nova url
<uksysadmin> currently it seems the best way is manually through bzr
<koolhead11> uksysadmin: horizon is back on bazar?
<uksysadmin> sanderj, iirc there is some issue with authentication - something to do with deprecated auth
<uksysadmin> I thought it always was, koolhead11 ?
<koolhead11> uksysadmin: no they moved everything to github
<uksysadmin> ah - its in git - not bzr
<koolhead11> uksysadmin: you have to select correct branch
<koolhead11> :P
<uksysadmin> there's a fine art in selecting the correct branch
<uksysadmin> the point is that it shouldn't be hard
<koolhead11> hmm, i am not touching horizaon now
<koolhead11> waiting for essex
<koolhead11> :P
<uksysadmin> yeah I gave up too
<uksysadmin> its good for showing demos to team leads and C level execs though - they expect nice interfaces
<sanderj> Yeah.. That's why I want it up and running..
<sanderj> uksysadmin, in which component is it an issue with authentication?
<uksysadmin> There was something I needed to change in /etc/nova/api-paste.ini
<uksysadmin> see the NOTE sections
<koolhead11> you need keystone running too
<uksysadmin> BUT - I've not looked at Horizon for a while
<sanderj> I got keystone running
<sanderj> which horizon branch should I select?
<koolhead11> diablo/stable
<TeTeT> is horizon sort of the middleware below dashboard?
<koolhead11> :P
<koolhead11> dashboard to horizon
<koolhead11> TeTeT: no they have renamed
<TeTeT> ah, thx koolhead11
<sanderj> koolhead11, I choose nova trunk
<sanderj> We're not running diablo
<niemeyer> Yo all!
<koolhead11> hola niemeyer
<koolhead11> sanderj: you can use the stackx code than
<koolhead11> uksysadmin: is it called stackx or what
<uksysadmin> what's stackx?
<koolhead11> uksysadmin: i think that bash script for rackers for one step install
<uksysadmin> thought this was a juju channel? bash scripts not needed! ;-)
<rog> niemeyer: hi!
<niemeyer> rog: Hey!
<niemeyer> rog: Good timing.. looking at cloudinit right now
<rog> niemeyer: cool.
<rog> niemeyer:  if you could have a look at go-juju-ec2-operations that would be nice too...
<niemeyer> rog: Yeah, I'll clean everything up today
<rog> niemeyer: BTW i'm not quite sure how i managed all.bash to appear twice
<rog> niemeyer: i muddled up something and confused lbox i think
<niemeyer> rog: I was curious as well, but not a big deal
<niemeyer> rog: submit works, btw
<niemeyer> rog: Not sure if you've seen the announcement
<rog> niemeyer: yes. i'm just updating now.
<rog> niemeyer: BTW i think perhaps -prep=false should be -mail=false. i.e. the mail should only be done when you explicitly ask for it
<niemeyer> rog: I think "lbox propose" should actually propose
<rog> niemeyer: lbox propose -cr -for x -mail
<rog> reads well to me
<niemeyer> rog: It reads well, but "lbox propose" should actually propose
<rog> niemeyer: ... unless you use -prep ?
<niemeyer> rog: Yep.. then you said "I'm just preparing for now" explicitly
<rog> niemeyer: in my workflow, i *always* prepare before mailing
<niemeyer> rog: It's easier to code than lbox prepare-proposal
<niemeyer> rog: That sounds fine
<rog> niemeyer: so it's nicer to have the default being the thing that doesn't do anything non-retractable
<rog> niemeyer: it's fine, i can always hack my local version :-)
<niemeyer> rog: Your default and my default differ.. there's no way out..
<rog> niemeyer: i guess i'm just used to the way that Go's "hg change" etc work
<niemeyer> rog: Yeah, that's probably it
<rog> niemeyer: but i do think the principle of making the default action the least drastic is a good one in general.
<niemeyer> rog: There's nothing drastic about making a propose command propose..
<rog> niemeyer: sending mail can be drastic!
<niemeyer> rog: You're going to the quotes page for that one :-)
<rog> niemeyer: in Go code reviews, the number of times i did "hg change" then "hg mail" immediately without another "hg upload" is pretty small
<rog> niemeyer: it's nice to see exactly *what* you're proposing before actually making the proposal
<niemeyer> rog: That sounds completely fine. I'm not trying to change your workflow in any way. Please feel free to create local "rog-propose" commands.
<rog> fair 'nuff
<niemeyer> rog: Many people review their changes before they commit locally, for instance.
<rog> niemeyer: i do that too, but there's nothing quite like seeing the final thing
<rog> niemeyer: (given the number of heuristics in lbox...)
<niemeyer> rog: Piece by piece, creating change logs that show the evolution towards the solution.
<rog> niemeyer: i agree entirely. my remarks are about notifying people at the right moment, not hiding change logs.
<niemeyer> rog: That's cool.. I'm not trying to convince you. Just explaining the other side of the picture.
<niemeyer> rog: My key point is that "lbox propose" should propose. That's all.
 * nijaba waves from rainy paris
<niemeyer> nijaba: Hey man
<nijaba> SpamapS: marcoceppi: would love to get a review on my merge proposal for roundcube.  Now with ssl cert copied via scp in peer relation
<nijaba> niemeyer: how are you doing? as you can see, I am thanking juju for giving me something to do while it's raining outside.
<niemeyer> nijaba: Hah, neat :)
<niemeyer> niemeyer: Pretty good here..
<niemeyer> nijaba: Pretty good here..
<niemeyer> nijaba: Trying to catch up after being away for a few days
<niemeyer> rog: One review out
<rog> niemeyer: the comments of the form "// apt_update_upgrade" refer to the cloudinit file that the option was taken from.
<rog> niemeyer: they're there to facilitate cross-checking with the original source.
<TheMue> rog: Could you please send the dependency graph we spoke about to me? Thx.
<rog> TheMue: just looking for it...
<rog> TheMue: http://paste.ubuntu.com/768876/
<rog> TheMue: it's a little idiosyncratic
<rog> TheMue: the script that generated it is at the top
<niemeyer> rog: Ok, can you please drop the comments?
<niemeyer> rog: now that you have the code?
<niemeyer> rog: It doesn't make sense for a reader, and they'll likely be wrong in a bit, even if they are right today
<TheMue> TheMue: Thx, so the modules on the left depend on the modules right of them?
<rog> niemeyer: i'd like to drop them, but i fear that when i come back to add some more options, i won't remember which ones have been done. would it make more sense if they were file names (more obvious that they referred directly to the cloudinit source, which is organised in that particular modular way)
<rog> TheMue: yes
<niemeyer> rog: The name of the option is in the Go code.. how would you forget?
<rog> TheMue: BTW if you want to massage the script (i built it up incrementally), you should know that "9 sed" refers to the plan9port version of sed, which understand egrep-style regexps
<rog> niemeyer: yeah, grep "option" should be sufficient, i guess
<niemeyer> rog: Now that TheMue has some free cycles, it would be nice to get started on the state logic front
<niemeyer> rog: I'm trying to recall the details of our conversation at UDS, but I don't have full clarity
<niemeyer> rog: Maybe we can recover that conversation together
<rog> niemeyer: i don't remember that much either!
<niemeyer> rog: So let's figure the approach again.. this time it should be easier
<niemeyer> rog, TheMue: Google+?
<rog> niemeyer: hangout?
<niemeyer> rog: Yeah
<rog> niemeyer: i'd like to quickly finish these updates to cloudinit, if that's ok
<TheMue> niemeyer: I would have to do some preparations before hangout.
<niemeyer> rog: Ok, please ping when you're ready then
<niemeyer> TheMue: Sounds good
<niemeyer> rog: Btw, I think we should rename the juju directory/package to "environ"
<rog> niemeyer: i'm not sure.
<niemeyer> rog: Everything in the repository is juju.. juju/go/juju is confusing, and incorrect
<rog> niemeyer: i think using "juju" as a package identifier works well
<rog> niemeyer: i think eventually it will be launchpad.net/juju
<niemeyer> rog: It doesn't to me.. everything in there is juju
<niemeyer> rog: Precisely.. it will be launchpad.net/juju/{log,charm,...}
<niemeyer> rog: now we'll build state
<rog> niemeyer: yes, but this is the code environment, and in go code, seeing juju.EnvironProvider works well
<niemeyer> rog: the things under the juju directory are about the environments
<rog> environ is a very generic name for a package
<niemeyer> rog: Again.. it makes sense for _everything_ to be under juju.
<rog> niemeyer: i'd thought of that package as the way in for all the top level juju entry pointer
<rog> niemeyer: e.g. deploy, add unit, etc
<niemeyer> juju.Log, juju.Charm, ...
<rog> juju.Log can be used like usual log. "charm" is sufficiently distinctive in itself
<niemeyer> rog: environ too
<niemeyer> rog: It's completely analogous
<rog> niemeyer: "environ" is a highly generic name, used in many places besides juju
<rog> and juju is nice and short
<niemeyer> rog: it is.. juju.Charm is nice too :)
<rog> niemeyer: i think it makes sense to have at least one package with the "juju" identifier
<niemeyer> rog: Heh
<rog> niemeyer: and given that this is the central place, why not this one?
<TheMue> I would like a package below "juju" for each major entity or service. Importing "launchpad.net/juju/envronment" seem ok for me.
<TheMue> Here the env gets its context by the containment in the juju package.
<TheMue> So, changed place and took headset
<niemeyer> rog: I don't buy the "we _need_ a package with this name" argument
<rog> TheMue: in my plan, the juju package is not only about the environment, it's also about control of juju.
<niemeyer> rog: That won't work.. we'll have a state package now, that is unrelated to the environment
<niemeyer> rog: and that's where good part of the "control" will lie
<TheMue> rog: I would only place a juju command inside this package.
<rog> niemeyer: i was thinking (as we discussed before i think) that the juju package would encapsulate an API interface to the "control" commands
<rog> niemeyer: so you could do: e, err := juju.Open("myenviron"); e.Deploy("wordpress")
<niemeyer> rog: I'm not sure.. that's exactly the conversation we're supposed to have
<rog> niemeyer: ah, i thought we were going to talk about the nitty-gritty of state updating
<niemeyer> rog: That sounds interesting, but the bulk of the environments implementation do not have to be within a juju package
<niemeyer> rog: and it is now
<niemeyer> rog: I'm happy to have the juju package as the entry point
<niemeyer> rog: That's not what it is today
<rog> niemeyer: ok. that depends on whether we manage to factor it out without circular dependencies.
<niemeyer> rog: There's no reason to have circular dependencies if juju is only the entry point
<TheMue> Right now I don't see them too.
<niemeyer> rog: But I guess we're in agreement.. I'm happy to have juju, and happy to have entry points there.. let's just move the bulk of the environment implementation in its own package under what we today have as go/
<niemeyer> rog: In the future, we move go/juju/* onto go/, and rename go/ to juju/
<TheMue> juju as a starter, additionally there will be some foundation packages like environment or misc utilities and then the service packages
<niemeyer> rog: Sounds good?
<rog> niemeyer: my reluctance, i think, is that there's hardly anything to the environ package. it's essentially just a couple of type definitions and a registry hook.
<rog> niemeyer: i don't know that it deserves its own package
<niemeyer> rog: Check out the log package..
<rog> niemeyer: that's different - it needs to be its own package to avoid circular dependencies
<rog> niemeyer: i'm not dead set against the idea, BTW. i'm just not sure about it.
<niemeyer> rog: So you're happy to have a package named log with two functions, but don't want to have an environment-specific package with hundreds of lines and multiple subpackages?  The reasoning is pretty weak.
<TheMue> I only can get it if I would say, juju IS our environment.
<niemeyer> TheMue: Everything there is juju.. the "go/" thing in the path makes this point less clear, but it's there just because we can't own the main namespace today
<TheMue> From this point of view all environment logic for sure could be inside juju
<niemeyer> TheMue: Again, everything is inside juju..
<TheMue> niemeyer: I know, but the environment.yaml is the local starting point
<niemeyer> TheMue: It's juju/charm, juju/log, juju/schema, etc
<niemeyer> TheMue: This isn't clear because we have a go/ prefix in the way, but that's how the package is intended to be used for real
<rog> i guess i don't believe that just because something *can* be factored out means that it *should* be factored out
<TheMue> TheMue: I know, I only tryed to understand rogs motivation
<niemeyer> rog: I'm not suggesting to factor anything out.. I'm saying the package is clearly misnamed.
<niemeyer> But I'll stop arguing now and will do something more relevant
<rog> at the moment, because it's early stages, all there is in the juju package is the environment, so it looks like it's misnamed, i think.
<TheMue> niemeyer: Btw, what is schema? The juju environment schema?
<niemeyer> TheMue: bzr branch lp:juju/go ls go/schema
<niemeyer> TheMue: bzr branch lp:juju/go; ls go/schema
<TheMue> niemeyer: No, wrong question, I got it here.
<TheMue> niemeyer: I asked for the semantics, because w/o context schema is as meaningless as yaml or xml) as file extension.
<niemeyer> rog: No, there's a lot in the juju package.. there's juju/schema, juju/log, juju/charm, juju/environs, juju/state, ...
<TheMue> niemeyer: So, which schema is schema?
<rog> niemeyer: aren't those all separate packages?
<rog> niemeyer: just as io/ioutil is a separate package to io
<TheMue> rog: I would say so, as I understand niemeyer
<niemeyer> rog: Yes, they are, and each encapsulate a well defined part of the problem that juju solves. I'm fine with your idea of using juju as an entry point, but now that I agreed with you you're changing the argument so we continue to disagree..
<TheMue> rog: And that's looking fine to me
<rog> niemeyer: i don't want to disagree!
<rog> niemeyer: i just think that the entry points and the environment stuff can live in the same package
<niemeyer> rog: So stop doing so.. you want juju as an entry point.. let's do this, and let's keep implementation details of environments clearly organized in their own package. Best of both worlds
<rog> niemeyer: won't that mean that anyone that actually wants to use the juju API will have to import both juju/environ (to read the environment) and juju/control (to actually do anything)?
<niemeyer> rog: Open dummyprovider_test.go and tell me with a straight face that this pertains to a top-level package.
<rog> s/juju\/control/juju/
<niemeyer> rog: Why? func Open(name) *environ.Environ ?
<rog> niemeyer: yeah that would probably do the trick
<rog> niemeyer: sorry for my reluctance - it just shifted my world view :-)
<TheMue> Do we have an outline about the contents and the structure of the API?
<niemeyer> rog: Well, no need to be sorry.. no feelings hurt. I'd rather having you arguing than having you silent. :-)
<niemeyer> TheMue: We have an evolving idea about that
<niemeyer> TheMue: We debated some high-level approaches about how to move forward in terms of the state integration at UDS
<TheMue> niemeyer: Any kind of living wiki document to collect the ideas?
<niemeyer> TheMue: No.. the living collection of ideas is the code base
<TheMue> *sigh*
<niemeyer> TheMue: ?
<niemeyer> TheMue: Go has very good ways to define APIs, document them, and read that documentation
<mpl> niemeyer: just curious, have you ever gotten any complaint from other users in the channel that you were flooding it?
<niemeyer> TheMue: If we have ideas about how APIs should look like, the code base is a _much_ better place to put that documentation than any wiki
<niemeyer> TheMue: rog has added a full skeleton of the environment API, despite it being pretty much unimplemented
<rog> TheMue: i've done a few forward-looking ideas for how i imagine some things looking
<TheMue> I surely see the importance of code. But especially when designing an API I like a good doc of the evolution so that anyone can not only see how it has been done but also why it has been done this way.
<niemeyer> TheMue: Again, this is a great idea!
<niemeyer> TheMue: And the code is the place to put it
<TheMue> It can be created in parallel and doesn't has to be a novel.
<niemeyer> TheMue: You seem to see the code as a poor place for documentation.. we disagree in that regard
<rog> TheMue: at this point, i think the most important thing is how the API looks
<TheMue> Yep, we do
<TheMue> It is the most important, here we do agree
<rog> TheMue: that is, how the types are named, and what the entry points look like
<rog> TheMue: if you've been following the recent Go activity, you'll see that much of the stuff has been proposed in the form of godoc output
<rog> TheMue: i thought it worked pretty well
<TheMue> rog: Yep, it's most important how it looks. It's good for the user.
<rog> TheMue: and it means that when you come to actually implement stuff, you just need to fill in the bodies of the types and functions
<TheMue> rog: But for the maintainer some infos about the motivation for decisions are helpful too.
<niemeyer> The "code" is where the project really lives.. around it we have revisioning of content, static analysis of names, reviewing workflows, automatic documentation generation, etc etc.
<rog> TheMue: i think that can go in the code too.
<TheMue> rog: I'm not only talking about implementing s/w the first time but also maintin it the whole lifecycle
<rog> TheMue: me too.
<niemeyer> and me too
<niemeyer> Even more important in maintenance, in fact
<rog> TheMue: documentation external to the code always lags...
<niemeyer> Code documentation far from code == quick bitrot
<niemeyer> rog++
<mpl> yep
<TheMue> Don't get me wrong, I want both. I can show you 20yrs code of mine with good comenting and naming.
<rog> which isn't to say that there shoudn't be some explanatory comments in the code about some particular decisions, if they're not obvious
<rog> the nice thing about proposing stuff with a Go API is that it keeps things concrete
 * niemeyer perceives ethos in the rhetoric..
<rog> where several paragraphs of text can be very ambiguous
<niemeyer> FWIW, I'd laugh (or cry) about my code from 20 years ago
<rog> TheMue: here's my original skeleton API (well out of date now) but if you look in juju/conn.go, the commented-out method give an idea for where i was aiming: lp:~rogpeppe/juju/go-too-much-too-soon
<rog> i'm still using some small pieces of code i wrote 20 years ago...
<TheMue> Hehe, just digged around in some Pascal code from 1990. Looked neat.
<rog> TheMue: the thing is, we're not redesigning juju - we're specifying the API and the internal structure. the design already exists and is implemented. so design documents aren't really appropriate here IMHO.
<TheMue> Hmm, I need a shortcut to checkout links from here in XChat directly into my project directory ...
<TheMue> So, in only few words, how will our API look? One major type providing many methods? Is this an interface and do we work with factories? Can the user expect transactional behavior (or at least a searialization of jobs)? Or do we have many small types the API user instantiaties on his own?
<niemeyer> rog: Very good point.. high-level (non-code) design documents are here: http://juju.ubuntu.com/docs
<niemeyer> TheMue: In only a few words? It will look great! ;-)
<TheMue> niemeyer: h5
<TheMue> Gooooood answer
<niemeyer> TheMue: More seriously, the domain space is fairly intricate.. such statements ("we'll use factories") are a solution in search of a problem. We'll try to do the inverse.. understand the problem and then figure how to best design the solution.
<TheMue> niemeyer: I know, has only been an example question regarding a design principle of e.g. separating service interfaces and providers handled in a kind of internal container (goroutine able to encabsulate jobs performin on those services).
<niemeyer> TheMue: Again, all of those things are solutions in search of a problem.. one can't tell whether something is appropriate in isolation of the actual problem being solved.
<rog> TheMue: i try to start from "this is the API i want to provide", then move to "how can i implement that API"
<rog> TheMue: luckily in this case, the problem itself is already specified (otherwise i'd start there)
<niemeyer> TheMue: Depending on what we're trying to accomplish, we can go in one direction or the other
<rog> TheMue, niemeyer: i've done most of the cloudinit changes. am ready for G+.
<niemeyer> rog: Kind of.. there are open problems in terms of API organization that we're trying to solve as well
<rog> niemeyer: it might be useful to make a list of some of the most pertinent of those problems.
<TheMue> This API organization is what I want to see. In a higher level than code, but less than a novel.
<TheMue> rog: YES!
<niemeyer> rog: I've been doing that.. but you're already aware of them in the context we're debating
<TheMue> rog: That's the doc I'm referring to. A list of what we want to provide which evolve into how we do it.
<rog> TheMue: method stubs work well. no bodies necessary, but a type signature and a comment.
<niemeyer> rog: or were, anyway
<rog> lol
<rog> maybe i am.
<niemeyer> rog, TheMue: Invite sent
<rog> niemeyer: one mo, i'm just being banished upstairs
 * hazmat yawns and digs into reviews
<jcastro> SpamapS: Hey so in your review of limesurvey I like how you tested the haproxy bits.
<jcastro> SpamapS: can I get a blog post out of that? I'd like a post highlighting that you can just add proxy things to charms and that we like that because it let's you addunit something fierce.
<mchenetz> currently building py27-txzookeeper for juju port on macâ¦ Next we will see if the juju port command will work. ;-)
<hazmat> mcclurmc, :-)
<hazmat> ugh.. keep doing that
<hazmat> mchenetz, cool, i'm curious to see how it goes, i've got an old mac pro i can setup if something needs debugging
<mchenetz> no probâ¦ I think i can handle the debugging. If i can't i will let you know. Thanks
<mchenetz> I will right some instructions up if it works
<hazmat> mchenetz, awesome
<hazmat> robbiew, thanks for posting the lisa keynote talk, interesting stuff .. http://www.youtube.com/watch?v=3KpPBnEtRj4
<hazmat> pretty high level stuff
<robbiew> hazmat: np...I missed Wednesday and was just looking to see which videos had been posted...luckily this one was
<robbiew> m_3: ping
<m_3> robbiew: yo
<m_3> g+?
<robbiew> m_3: yup
<robbiew> m_3: invite sent...I think
<m_3> doh... from me too just now... lemme look for ytours
 * koolhead11 wondering if robbiew going 4 hangout. :P
<rog> niemeyer: http://paste.ubuntu.com/769110/
<mpl> hazmat: the most interesting part was at 1h06m20s :)
<rog> niemeyer: any way i can reset the CL state, or do i have to create a new CL?
<niemeyer> rog: Yo
<rog> niemeyer: hiya
<niemeyer> rog: Let me check that paste
<niemeyer> rog: Curious
<mchenetz> I think i am going to create a macport repo on one of my servers for Juju so that other people will not have to go through what i am going through...
<niemeyer> rog: So, do you have any idea of what was the story there?
<niemeyer> rog: The file definitely looked weird.. I'm not sure about where to start looking
<rog> niemeyer: i think the sequence went something like this:
<rog> niemeyer: the wrong version of all.bash went in initially
<rog> niemeyer: i changed it. i might even have done bzr rm all.bash
<rog> niemeyer: then i added it again
<rog> oh, somewhere in the middle, it went wrong, so i couldn't view anything on the web site ("CL is uploading" or something like that)
<rog> and then somehow i got it back again
<rog> but... with two all.bash files visible
<rog> niemeyer: sorry it's not a very reproducible scenario
<niemeyer> rog: Ok, no worrie
<niemeyer> s
<rog> niemeyer: but currently i can't upload my changes, so the CL is stalled
<niemeyer> rog: Can you please retry with -debug?
<SpamapS> jcastro: ack.. in the server team meeting right now..
<rog> !
<rog> it's worked now
<rog> niemeyer: dunno what went right this time
<rog> niemeyer: BTW, i'm not sure what to do about all the comments for the various options
<niemeyer> rog: Have you touched the branch in any way in between? (commit/whatever)
<niemeyer> rog: let's figure what the options do.. smoser can help us
<rog> niemeyer: nope
<rog> niemeyer: i could make a guess at the docs but, yeah, some knowledgable help would be good
<smoser> what options are you talking about, negronjl
<smoser> oops
<smoser> niemeyer,
<rog> smoser: cloud-init options
<rog> smoser: https://codereview.appspot.com/5444043/diff/20003/cloudinit/options.go
<smoser> which options? most options for cloud-config are documented at http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt
<niemeyer> Sweet!
<rog> smoser: "user" ?
<rog> smoser: thanks BTW
<smoser> thats the 'user' that things are done to (like ssh-import-id, other stuff... its assumed that that user already exists in the image)
<smoser> ie, 'ubuntu'
<rog> smoser: hmm. i'm trying to think of a good way to phrase that.
<rog> smoser: "SetUser sets the user that things are done to" doesn't quite get there for me :-)
<smoser> many cloud-config things operate on a user account.
<rog> smoser: "SetUser sets the remote user name that will be used"?
<smoser> (import keys being the most obvious)
<rog> smoser: is it essentially just setting the home directory?
<smoser> they read the cloud-config user 'user' for which user to operate on
<rog> smoser: or do some things set uid to the user too?
<rog> smoser: yeah, i've seen a few get_cfg_option_str(cfg,"user","ubuntu")
<smoser> its possible they get the uid for the user and use it, but i'm not usre.
* niemeyer changed the topic of #juju to: http://j.mp/juju-florence | http://j.mp/juju-docs | http://j.mp/irclog | #juju-dev | Office Hours (1600-1900UTC)
<niemeyer> New #juju-dev channel, for low-level development-related topics
<rog> smoser: yeah, byobu does sudo user.
<rog> (whatever byobu is :-])
<rog> smoser: "SetUser sets the user name used for byobu, set_passwords, ssh_import_id and ssh_import_id"?
<niemeyer> rog: byoby == screen with a configuration file from Dustin
<rog> (maybe enumerating the various things that uses it is easier that trying to say what it is)
<hazmat> next version of byobu is tmux based
<hazmat> quite nice actually
<hazmat> er.. i guess it supports both, but i tried out the tmux version
<rog> the docs say of apt-mirror, "Add apt repositories" but it only has one string argument
<rog> is the URL point to a list of apt repositories?
<rog> s/is/does/
<rog> smoser: what does apt_old_mirror do?
<rog> darn it, i've got to go
<rog> smoser: thanks for the help.
<rog> anyone: feel free to add any docs to the above page (https://codereview.appspot.com/5444043/diff/20003/cloudinit/options.go) by double-clicking on a line
<rog> see y'all tomorrow
<niemeyer> rog: Have a good evening
<hazmat> bcsaller, jimbaker, fwereade standup?
<hazmat> bcsaller re standalone needs review,  https://code.launchpad.net/~hazmat/juju/upgrade-config-defaults/+merge/84710
<SpamapS> new charm-tools/charm-helpers uploaded to precise.. now with unit tests.. w00t. :)
<m_3> SpamapS: thanks
<marcoceppi> SpamapS: woo \o/
<mchenetz> Finally got juju working on OSX, using Port, Brew and PIPâ¦ It was hard and it was uglyâ¦ I am going to work on fixing the port file and maybe even create a brew repo
<SpamapS> except.. the tests fail on the buildds.. hrm
<m_3> mchenetz: +1 for a brew repo
<mchenetz> m_3: I like brew a lot better and i think it already had a lot of the dependenciesâ¦ So, i think it would be the way to go...
<m_3> much easier to publish and maintain imo... just pull requests
<mchenetz> I haven't looked into it. But that is always what i hear. I will be looking at it shortly. :-)
 * m_3 will have to break out the old osx drive for his mbp to test
<mchenetz> okay, after all of thatâ¦ during bootstrap: ERROR, no module named aptâ¦ hehe it's not linux
<mchenetz> Now to look at the juju code
<mchenetz> Okay, so this seems to be a local provider issue under pkg.py
<mchenetz> I think we could do a little magic to use brew or something else in the pkg.py script
<mchenetz> okay, so now i am thinking that a standardized repo for juju is quite important. We need to have similar packages for osx and linux. So someone, maybe me, needs to start a  repo that includes the packages required to allow the charms to function correctly
<nijaba> SpamapS: marcoceppi: I would really appreciate if one of you would have time to review my mess :)
 * SpamapS points nijaba to m_3
<marcoceppi> nijaba: I'm a bit strapped this week between deadlines and "in-laws" visiting
<SpamapS> nijaba: I'm way behind on other things today.. but m_3 might have a few moments to poke at it.
<nijaba> marcoceppi: SpamapS: ok, understood, specially for the inlaws ;)
<SpamapS> mchenetz: by packages, do you mean ports or brew or something else?
<mchenetz> I am thinking brew for osxâ¦ But, i am starting to thing that it might be good if juju had it's own package repo
<jcastro> mchenetz: I would be in favor of anything that improves our story on osx.
<jcastro> that would be a really great contribution
<mchenetz> I am trying to think about the best way to do it. It could just be that the scripts call apt on ubuntu and brew on osxâ¦ However, i think there needs to be a standard and there may need to be repos setup for compatibility with juju (missing files)
<mchenetz> The only advantage to Juju having it's own package management is that other flavors of linux could theoretically be brought into the fold because it wouldn't rely on a certain package distribution method
<mchenetz> just thinking out loud here: Naming of packages may become an issue with different package management software (e.g. apt and brew). They may not be called the same thing in both repos so there may need to be provision for different package names dependant on architecture.
<marcoceppi> mchenetz: The systems's package manager could be made available in an environment variable, say "SYSTEM_PKG_MGR" so charms could be setup to swtich between them. But I'm also just thinking outloud. It's easy enough to create a charm as it is. So for those running charms on different systems they could fork a charm from the charm store, modify the few lines about apt-get * and then deploy
<mchenetz> marcoceppi: I agreeâ¦ The just have to know that in order for it to be cross platform, a package needs to be available in both repos. This may require custom repos if one or the other does not contain those files.
<marcoceppi> mchenetz: I think what will likely happen is a distribution setting up it's own charm store, Juju is _technically_ cross platform, but there is no guarantee for a charm to be cross platform. That would be way too much work up front for a charm author. So, if a charm isn't written for your distribution, you can always just write one :)
<marcoceppi> Though, just talking out loud.
<mchenetz> But, actually, once juju is installed, it will most likely be  a linux container. So, it is just the initial setup of juju that could require additional packages. :-)
<mchenetz> Which brings me back toâ¦ I still think Vagrant would be very beneficial to integrate into jujuâ¦ I may work on that too. It does not seem like it would take to much
<mchenetz> marcoceppi: The only reason why it's not truly cross platform compatible right now (That i can see) is that it needs some programming logic in the local provider section to not only use apt, but brew or macport
<m_3> nijaba: I'll look at what you have in the queue
<hazmat> mchenetz, not worthwhile to support local provider
<hazmat> mchenetz, that code shouldn't be imported if its not being used in the config
<mchenetz> hazmat: What do you mean not worthwhile? We should use something else?
<hazmat> local provider is using linux only tech, a vagrant provider is significantly heavier weight, but would definitely be of use to osx
<mchenetz> hazmat: maybe i will start working on a Vagrant povider
<hazmat> mchenetz, yeah, not worthwhile as it in won't work, and if its going their is going to be a virtualbox provider its a separate provider
<hazmat> its not really vagrant, its just talking to virtualbox api, all vagrant really is a some policies around a virtualbox api wrapper
<m_3> scripts really, right?
<hazmat> mchenetz, the virtualbox sdk has a control console in python that i found helpful when trying to understand the api
<mchenetz> hazmat: i will take a look at the virtualbox sdkâ¦ i just have to think of some of the features i liked in Vagrant and see what would be good to add to Juju
<hazmat> mchenetz, cool, i'd be interested in hearing what those are or feel free to file a bug report
<mchenetz> hazmat: no probâ¦ I am going to start to outline it
<hazmat> mchenetz, fwiw.. i filed a bug 826498 about vbox/osx a while working on the local provider impl
<_mup_> Bug #826498: virtualbox machine provider for osx local dev <juju:New> < https://launchpad.net/bugs/826498 >
<mchenetz> hazmat: i will check it out
<mchenetz> Wow you can do quite a bit with their sdk.
<nijaba> m_3: thanks a lot.  Would like to know if I am going the right way before I start on something else :)
<mchenetz> This is probably good to look at for virtual box integration as it is programmed in Python: http://code.google.com/p/vboxweb/
<_mup_> juju/sshclient-refactor r432 committed by kapil.thangavelu@canonical.com
<_mup_> merge latest robust-zk-connect from jim
<_mup_> juju/sshclient-refactor r433 committed by kapil.thangavelu@canonical.com
<_mup_> merge trunk
<negronjl> SpamapS, m_3, hazmat:  Do you guys know how to get the unit name ( ie: mongodb/3, mongodb/2, etc. ) from within either the install hook or any of the relation-* hooks?  I need that information sometimes and have no idea how to get that information.
<tekonivelo> hi
<SpamapS> negronjl: JUJU_UNIT_NAME ? I seem to recall needing it in a few places too.
<negronjl> SpamapS: is that an environment variable ?
<SpamapS> negronjl: yeah, I use it in ceph a lot
<negronjl> SpamapS: thanks ... I'll try that out
<tekonivelo> juju deploy is spawning me new machines on AWS EC2. But i'm on el chÃ©apo free AWS t1.macro plan, so i would like to have everything on the one machine
<robbiew> tekonivelo: right now that feature isn't available, however we are in the process of adding it for the 12.04 release.
<tekonivelo> robbiew: ok
<robbiew> if you are just playing with juju, may I suggest the local option?
<SpamapS> tekonivelo: you can spawn your own t1.micro, and use the 'local' provider...
<tekonivelo> robbiew: so it's not a completely out-of-the-model -idea in juju?
<SpamapS> tekonivelo: but the 700MB of RAM is not going to be enough to do much at all.
<robbiew> tekonivelo:  nope...especially because we leverage juju in ubuntu orchestra for bare metal deployments
<robbiew> where you will surely want more than one thing on a machine ;)
<SpamapS> tekonivelo: https://juju.ubuntu.com/docs/provider-configuration-local.html
<tekonivelo> thanks!
<tekonivelo> i'll continue my adventures in juju-land :)
<tekonivelo> thanks, the "the ancients of juju" :)
<tekonivelo> sorry "the justified ancients of juju" ;)
<m_3> nijaba: ping
#juju 2011-12-14
<nijaba> m_3: pong
<m_3> nijaba: so in the peer relation hook, it doesn't look like the key's being gen'd
<nijaba> m_3: humm which one?  the ssh or des?
<m_3> des
 * nijaba looks
<m_3> I'm still testing, but gotta make some changes locally before I get further
<m_3> config-changed barfs if you just use default config params (trying to do stuff with ssl certs even though do_https is off)
<nijaba> m_3: hmm. the des key should be generated the first time get-des-key gets called
<nijaba> m_3: uhhh did not do much test with default params, you are right.
 * nijaba juju bootstraps
<m_3> wondering about a couple of strictly '-lt's in the peer hook
<SpamapS> we should offer Juju boot straps in the ubuntu store
<m_3> doesn't look like that'd be called for the master... that the key's being gen'd from a set-des-key calling get-des-key
<nijaba> m_3: it is called the first time peer-relation-joinded is invoked, afaics
<m_3> nijaba: adding a 'do_https' guard around 'set-ssl-cert' in config-changed to get it deployed
<nijaba> m_3: drat, you are right.  I should have guarded this.  do you want me to work on it with default params a bit more and signal you back.  I was a bit too much concentrated on distributing those certs that I forgot the basic test case
<m_3> nijaba: the part I'm trying to get to test is the peer-relation-all in the master case.  I'm wondering if:
<m_3> if  [[ $LOCAL_UNIT_ID -lt $REMOTE_UNIT_ID ]] && [[ $LOCAL_UNIT_ID -lt $FIRST_UNIT_ID ]] ; then
<m_3> sorry for the bad paste, but I'm wondering if this is ever true
<m_3> [[ "0" -lt $SOME_UNDEFINED_VARIABLE ]] && echo "yes" || echo "no"
<nijaba> m_3: it is, according to my logs.  done tests all the way, removing a master, middle and end nodes
<SpamapS> looks like we need a charm helper for peers and leader detection
<SpamapS> I did something very similar in ceph
<m_3> SpamapS: yes, agree... there're multiple impls already
<m_3> nijaba: cool...  I'll bang on it
 * m_3 is sticking with my primary skills
<nijaba> m_3: the theory is that the unit I am on is never in the the list.  So if my id is less than the remote and the first unit id in the list, then I am elected master
<m_3> nijaba: right
<SpamapS> relation-list shows all parties, IIRC
<nijaba> drat, my chmods in set-ssl-cert are at the wrong place, hence the issue you found when they are not set
 * SpamapS honestly doesn't remember, but I think in ceph I had to account for my own ID being in the list
<m_3> I'll test it carefully to see what's going on... my guess was that this wasn't executing, but the key was still generated 'lazily' by set-des-key
<nijaba> SpamapS: I never ever saw this happen so far.  maybe implementation has changed?
<m_3> set-des-key with and empty arg actually calls get-des-key which gens
<m_3> s/and/an/
<SpamapS>     relation-list > $units_file
<SpamapS>     echo $JUJU_UNIT_NAME >> $units_file
<SpamapS> nijaba: you are correct .. it is actually only the "other" units
<m_3> totally need an i_am_leader helper fn
<nijaba> m_3: yes, this was intended.
<nijaba> m3: (set-des-key calling get-des-key when called with no param)
<SpamapS> m_3: ch_peer_leader
<SpamapS> and ch_peer_i_am_leader
<nijaba> m_3: that would have helped me A LOT.  had to fight a few hours to understand the logic
<SpamapS> nijaba: as did I. We will have to combine the best of those two implementations into a charm helper version.
<nijaba> m_3: just pushed a fix for the config-changed set-ssl-cert that seems to work better :)
<m_3> that's ok, I reimplimented facter while writing varnish... doh!
<m_3> nijaba: I'll pull in a bit... I just commented them out to get to teh peer relations
<nijaba> SpamapS: mine is actually already inspired from you ceph charm, but it did not look like we had exactly the same case.  ceph seems to need keys to all other peers, I just need to push the keys of the current master
<SpamapS> nijaba: yeah there are two different things needed. One is a generic system for agreeing on who is the leader. The other one is a generic system for transferring a file from the leader to all non-leaders in a peer relation.
<nijaba> SpamapS: right.
<nijaba> I can try to genericize in ch_helper if you want.  It's quite fresh in my head atm
<SpamapS> Go for it!
<SpamapS> nijaba: please add tests for it in tests/helpers
<nijaba> SpamapS: k
<SpamapS> nijaba: I named the file 'helpers.sh' but I think it should have been 'net.sh'. Since what you are doing is really, I think, unrelated to net.sh, you should maybe call it peer.sh
<nijaba> SpamapS: remind me where the branch is please
<SpamapS> lp:charm-tools
<nijaba> m_3: I really did not test without cert sets. /me slaps myself
<m_3> nijaba: peer keys seem to be generated just fine... sorry for the noise
<m_3> pulling your latest
 * m_3 on to the next test scenario
<mchenetz> yeah... Stackops server1 is up... Now for another compute node
<mchenetz> or openstack
<nijaba> SpamapS: I am not seeing any helpers.sh file, only helper/sh/net.sh...  not sure what you meant
<nijaba> SpamapS: Can I use bash, or you tink sh is very important?
<SpamapS> nijaba: in tests/helpers, there is helpers.sh
<SpamapS> nijaba: write the tests first. ;)
<nijaba> SpamapS: ah? really? I usually do the opposite...
<SpamapS> nijaba: I use posix shell only, if you guys feel strongly that bash is important, we can make them bash specific, but they need to be called .bash, not .sh
<SpamapS> nijaba: TDD, write test, then write code.
<nijaba> SpamapS: aye sir
<SpamapS> nijaba: you're welcome to do it your wya. :)
<SpamapS> way even
<SpamapS> but typically tests written after the fact are more shallow and have more assumptions in them.
<nijaba> SpamapS: good to know.
<SpamapS> nijaba: to be fair, I do it "the right way" only about 50% of the time, because usually I'm too busy to write tests first. :)
<m_3> the biggest thing that gets me with sh -vs- bash is the ${VARIABLE%%.xml} expasion stuff
<m_3> saves having to exec cut
<SpamapS> m_3: that stuff is awesome.. and available in all shells.
<SpamapS>      ${parameter%%word}    Remove Largest Suffix Pattern.  The word is expanded to produce a pattern.
<m_3> and really lots more than just cutting (regexp subs)
<SpamapS> from man dash
<m_3> was having problems in dash
<m_3> in particular, the substitution one... ${VARIABLE//\/*}
<nijaba> SpamapS: what were you expecting "ch_peer_leader"? return the leader unit name?
<SpamapS> nijaba: echo $leader .. yeah
<m_3> even unit sequence id would be great
<nijaba> m_3: which do you prefer?
 * nijaba put a param :)
<m_3> but go with the whole unit name I'd think, it can be trimmed by the user
<SpamapS> oh yeah another one that wouldn't be peer related at all is just "ch_my_unit_id" and "ch_unit_id"
<m_3> with the ${//} above :)
<SpamapS> Even though those are basically just 1 liners
<SpamapS> m_3: I tend to go with ## or #
<SpamapS> But I can't explain why ;)
<m_3> right
<m_3> didn't know dash was supposed to impl it
<m_3> I'll check and see if a bug is appropo
<m_3> you'd think that'd be in the test suite tho
<SpamapS> Yeah I believe there's an actual POSIX test shell test suite somewhere out there
 * m_3 relocating... coffee shop -> home
<nijaba> m_3: drive safely :)
<nijaba> SpamapS: how can I simulate a call to relation-list? relation-list is a bad function name in sh
<nijaba> SpamapS: charm_tools waiting for a merge :)
 * nijaba -> bed
<SpamapS> nijaba: alias relation-list=my_relation_list
<TheMue> rog: Ready for a worklow question?
<rog> TheMue: sure
<TheMue> rog: In my past I've worked with svn and hg, so some questions about the workflow here with bzr.
<rog> TheMue: go on
<TheMue> rog: If I wonna start something new, like we yesterday talked about, I first create a branch with a kind of name describing what I'm doing?
<TheMue> rog: E.g. bzr lp:juju/go go-add-state
<rog> TheMue: yeah. actually i rarely know what the change will be until i'm nearly ready to submit, so i often just name it something fairly generic to start with
<TheMue> rog: ok
<rog> s/bzr/bzr branch/ but yes, that's right
<TheMue> rog: Oh, eh, yes. ;)
<TheMue> rog: So let's asume I've then got something I want to submit, what are the next stepts?
<TheMue> steps
<rog> in your case, i think that rather than starting with a branch, i might write down how you envisage the API
<rog> and put it forward for comments
<rog> but anyway
<rog> ok if you want to submit something
<rog> you'd use gustavo's lbox tool
<rog> (have you installed that?)
<TheMue> yep
<rog> there's been a new version very recently, so you might want to update, BTW
<TheMue> done this morning ;)
<rog> ok, so you'd commit your changes (bzr commit)
<rog> then you'd do lbox propose -cr -for lp:juju/go
<rog> and that should get you to edit a file to which you can add the description
<rog> of the changes
<rog> and it'll put the merge request onto launchpad and codereview
<TheMue> ah, ic
<rog> then if you need to make some changes in response to the review, you commit and run lbox propose again (with no args this time)
<rog> then when you get a LGTM, it's time to do the actual merge
<rog> to do that, i make sure that i have a trunk branch that's up to date (e.g. cd my-repo-dir/go-trunk; bzr pull)
<rog> then go to that directory and merge in your change
<TheMue> ok, got it
<rog> bzr merge ../go-add-state
<rog> then build and make sure that everything tests ok
<rog> then, assuming that's all ok, you can do: bzr push
<rog> to actually commit the changes
<TheMue> who's giving the LGTM? only gustavo or are always at least two people needed?
<TheMue> fine, helps a lot, will write it down in my Getting Started document
<rog> TheMue: only one LGTM is needed, but you might want to resolve discussions if there's some other comments
<TheMue> so of anyone says it's ok that's enough. got it.
<rog> the other thing that caught me out was when i had some branches in a sequence
<rog> TheMue: generally you want a LGTM from gustavo - he's the man
<TheMue> rog: ok
<rog> once you've pushed a branch, if you want to work on the next branch in a sequence of changes, you'll want to merge trunk into that branch before continuing
<rog> oh yes, once you've merged, you need to commit the merge
<TheMue> ok, sound reasonable
<TheMue> thx for your help, will write it down now
<mpl> TheMue: jsyk the bzr online help pages + the tips on launchpad are pretty complete already.
<mpl> hi all
<TheMue> mpl: hi and yep, they are looking good.
<TheMue> mpl: justed wanted to know how we doing branching and merging here. had different policies in other companies.
<mpl> TheMue: ok. for now I've just followed gustavo's blog post about lbox, it was enough to get started.
<koolhead11> hi all
<niemeyer> Hello all.. how's that jujuer life coming?
<jelmer> it's.. charming
<niemeyer> :-)
<rog> niemeyer: mornin'
<niemeyer> rog: yo
<niemeyer> rog: How're things going there?
<rog> niemeyer: not bad. distracted by watching that devops video this morning. lots of i have no idea about :-)
<rog> s/lots of/lots of stuff
<niemeyer> rog: It was pretty interesting indeed
<_mup_> Bug #904201 was filed: need supporting code to model machine constraints <juju:In Progress by fwereade> < https://launchpad.net/bugs/904201 >
<niemeyer> rog: After about the middle it got a bit boring, with the guy going over the history of a lot of people without much context for how it made any sense to bring these up
<TheMue> ..ooOO( Reminder: Look that video, too. )
<niemeyer> rog: But otherwise really good
<rog> yeah
<TheMue> I'll participating a DevOps talk at the OOP too. Looking forward.
<TheMue> niemeyer: Getting a better understanding of the existing state code. There's nothing yet like the state.State we yesterday talked about?
<niemeyer> TheMue: You can see state.State a _bit_ like the sum of all the StateManager classes
<niemeyer> TheMue: We should clean these interfaces up while joining, but that's the direction at least
<TheMue> niemeyer: Understand, ok
<_mup_> juju/trunk r432 committed by kapil.thangavelu@canonical.com
<_mup_> [merge] robust-zk-connect,sshclient-refactor juju commands will now
<_mup_> wait for juju to be running post bootstrap, so using juju commands immediately
<_mup_> after bootstrap is viable. [a=jimbaker,hazmat][r=fwereade,jimbaker,hazmat]
<_mup_> [f=849071]
<rog> niemeyer: https://codereview.appspot.com/5444043/
<rog> niemeyer: hopefully i've remembered everything
<niemeyer> rog: Thanks!
<niemeyer> rog: Before submitting cloudinit, would you mind to do a quick godoc test?
<niemeyer> rog: I suspect that SetOutput will format improperly
<niemeyer> rog: The documentation, that is
<rog> niemeyer: i'll have a look
<niemeyer> rog: Also, it'd be good to clarify AddRunCommand with smoser
<niemeyer> rog: It's unclear (the "first?", and also which shell script)
<rog> gokpgdoc FTW: http://gopkgdoc.appspot.com/pkg/launchpad.net/~rogpeppe/juju/go-cloudinit/cloudinit
<niemeyer> rog: Wow :-)
<niemeyer> This is awesome
<rog> ain't it just?
<rog> niemeyer: yup, you're right about SetOutput
<niemeyer> Ok, I'll add the comments there
<smoser> link?
<smoser> ah. runcmd are only executed on first boot of an instance.
<rog> smoser: and bootcmd?
<smoser> i have to check.
<smoser> you're adding them to cloudconfig, right?
<smoser> as opposed to a multipart part
<rog> smoser: yup
<rog> (erm, actually i don't know what you mean by "multipart part" there...)
<niemeyer> rog: Sent another round
<niemeyer> smoser: Yeah, cloud-config
<niemeyer> rog: cloud-init actually supports multiple kinds of input
<smoser> rog, cloud-inti can take multipart mime input. and one of the types is "boothook".
<smoser> bootcmd runs every boot.
<niemeyer> smoser: What's boothook?
<smoser> which is actually not what was originally intended.
<niemeyer> rog: ^ info will be useful for the review
<rog> smoser: ah, so the doc in that cloud-init.txt is misleading
<niemeyer> rog: How so?
<smoser> it should follow "Cloud Boothook" at https://help.ubuntu.com/community/CloudInit
<rog> smoser: it implies that the only difference between runcmd and bootcmd is the stage in the boot process that the commands get executed
<smoser> but right now, it doesn't even put the INSTANCE_ID in environment.
<smoser> i will change it to have that in environment.
<smoser> rog, i'll update that documentation also.
<smoser> rog, that link there also hopefully describes multipart, but its probably information only for you. i think your approach with cloud-config is fine
<rog> smoser: it would be useful if you could take a brief look at the other comments in the docs linked above and let me know if they look right.
<rog> smoser: (if you have a moment, of course!)
<smoser> SetDisableRoot: disables ssh login to the root account via the ssh authorized key found in metadata
<smoser> rog, looks reasonable.
<rog> smoser: great, thanks a lot
<rog> smoser: when you say "the ssh authorized key found in metadata", do you mean one of the ssh keys specified with ssh_authorized_keys ?
<rog> smoser: or is there different key that this refers to?
<smoser> different.
<rog> smoser: which metadata is the key found in?
<rog> smoser: (i'd like to document it if i can)
<smoser> only the metadata source's [public-keys are put into both user and root
<smoser> ie, in ec2, the ec2 metadata service has a 'public-keys' entry (that is populated when you launch an instance with '--key mykey')
<rog> ah, the EC2 metadata!
<rog> so i'd be correct if i said this:
<rog> // SetDisableRoot sets whether ssh login is disabled to the root account
<rog> // via the ssh authorized key found in the instance's EC2 metadata.
<rog> // It is true by default.
<rog> ?
<rog> smoser: ^
<smoser> that is good. yeah.
<rog> great, thanks
<smoser> but it isn't necessarily EC2 metadata specific.
<rog> hmm
<smoser> as there are multiple DataSources, EC2 is one of them.
<smoser> the others are "nocloud" (directory, and there is OVF).
<smoser> which can also provide that stuff
<rog> smoser: what does SetDisableEC2Metadata do on non-EC2 cloud providers?
<rog> smoser: (and is that referring to the same metadata?)
<rog> smoser: does this make sense to you:?
<rog> // SetDisableRoot sets whether ssh login is disabled to the root account
<rog> // via the ssh authorized key associated with the instance.
<rog> // It is true by default.
<rog> maybe "instance metadata" would be better there
<rog> niemeyer: is there a way of running lbox propose that doesn't edit the description?
<niemeyer> rog: Not at the moment.. feel free to save the text unchanged, though :-)
<niemeyer> rog: I can add a flag if that bothers you
<rog> niemeyer: yeah, i do. (well, i add a blank line because of my slightly strange editor set up)
<rog> niemeyer: but it would be nice to be able to upload changes only
<rog> niemeyer: i usually only edit the description once at the beginning
<niemeyer> rog: Note that it doesn't actually upload the description if you don't change it
<rog> niemeyer: sure. it's just i'd like to take out one more interactive step.
<niemeyer> rog: I personally find it useful since its a nice reminder to update an out-of-date description after the changes made
<niemeyer> rog: But I can add a flag if you don't care
<rog> niemeyer: i do care - but i always check on codereview anyway
<rog> niemeyer: a flag would be great, please.
<niemeyer> rog: Will do
<niemeyer> rog: I see submit worked for you! :-)
<rog> niemeyer: yup, yay!
<rog> niemeyer: BTW what things are fixed by the first call to propose? can i, for instance, change the prereq later?
<rog> niemeyer: or the bug number, etc
<niemeyer> rog: Launchpad doesn't allow changing the prereq, so there's nothing we can do about it
<niemeyer> rog: -bug always works
<niemeyer> rog: It doesn't _change_ the bug, though
<niemeyer> rog: It associates the given bug with the merge proposal (and blueprint, in case it was used)
<rog> niemeyer: if you use -prep, is the bug created then? or later?
<niemeyer> rog: Works in either case
<niemeyer> rog: Sorry
<niemeyer> rog: I misinterpreted your question
<niemeyer> rog: The bug is created and associated whenever -bug is used
<niemeyer> rog: Erm
<niemeyer> rog: The bug is associated whenever -bug is used
<niemeyer> rog: The bug is created and associated whenever -new-bug is used
<rog> niemeyer: -new-bug?
<rog> cool
<niemeyer> rog: So propose can be called repetitively at will
<niemeyer> rog: and associate/create/update stuff as one goes
<rog> niemeyer: if you do new-bug twice, will you get two bugs with the same text?
<niemeyer> rog: You'll get as many bugs as you call -new-bug with, with whatever text was used
<rog> niemeyer: cool, just checking
<niemeyer> rog: This is probably a bad behavior, though.. we can do better
<rog> niemeyer: presumably lbox propose doesn't remember the new-bug option
<niemeyer> rog: We have metadata about it at the server side
<niemeyer> rog: Since we associate with the merge proposal
<mchenetz> Good morning
<SpamapS> mchenetz: ahoy
<mchenetz> Spamaps: Back at ya. :-)
<niemeyer> I'm heading to lunch
<mchenetz> Is there any diagram of the Juju solution? I am starting to integrate Virtualbox into Juju and i wanted to see if there was any good documentation on Juju dev
<TheMue> mchenetz: You've already visited https://juju.ubuntu.com/docs/?
<TheMue> mchenetz: Here you'll find many informations about juju.
<mchenetz> TheMue: I was just wondering if there was a general flow diagram or something... But i will look through it
<TheMue> mchenetz: And feel free to ask.
<mchenetz> TheMue, thanks
<SpamapS> mchenetz: at one point I had one that showed the architecture.. but I don't know if it will be all that helpful.
<mchenetz> Spamaps: If it's still relevant then i would like to see it... If not, then don't worry about it.
<SpamapS> mchenetz: for providers, you should only need to add a file to juju/providers and maybe config stuff in juju/environment/config.py
<mchenetz> What about inside the virtualbox image? Any daemeons that i need to inject into the image on create? Or, do i pre-create images?
<SpamapS> mchenetz: boot the cloud image, it will get things right
<m_3> need to touch some other stuff throughout the code too (like unit/address.py)
<mchenetz> These are the things i need to know... I guess i will start and as i hit a roadblock, i will just ask questions. I will look at the local provider python code as an example of what i need to hook into
<SpamapS> mchenetz: cloud-images.ubuntu.com
<SpamapS> mchenetz: no, the local provider is going to confuse you a lot I think.
<SpamapS> mchenetz: because the LXC stuff is "special" .. and isn't done as a provider, its done as a container technology to run inside VMs.
<mchenetz> Spamaps: okay... Then i am not sure... I will just do my best
<SpamapS> mchenetz: probably easier to copy the dummy provider actually. :)
<mchenetz> Spamaps: Okay, i will do that... Thanks
<marcoceppi> Could I use juju to deploy on Ubuntu Cloud Live?
<fwereade> mchenetz, just a note: I tried to make the docstrings for MachineProviderBase helpful, do take a look at those
<mchenetz> fwereade: thanks, will do
<jimbaker> hazmat, thanks for merging in the branches to enable juju commands immediately after bootstrap
<jimbaker> (enable their effective, error free use)
<m_3> whoohoo!
<jimbaker> m_3, yes, it's a very nice change. glad that was able to make it in. also i'm feeling better today :)
<m_3> jimbaker: good... missed you at the goat yesterday
<jimbaker> unfortunately my wife is now sick with whatever i had earlier this week
<mpl> jimbaker: that's true love and dedication ;)
<jimbaker> mpl, indeed ;)
<drt24> juju eureka isn't in the ppa yet?
<robbiew> drt24: I think it is...but SpamapS can probably answer best
<robbiew> oneiric or precise?
<robbiew> (ppa)
<drt24> both
<drt24> or I could be reading it wrong.
<drt24> I suspect that I am wrong and was confused by the ppa not being linked from the juju project page but only form the juju hackers page.
<jcastro> juju logo sideways! http://www.stumbleupon.com/
<m_3> yeah, I've seen a couple of pipes logos out there
<hazmat> jimbaker, bcsaller, fwereade standup?
<jimbaker> hazmat, sure
<fwereade> hazmat, sounds good
<TheMue> Aargh, layer 8 error detected. Using the right command to do something is helpful. *sigh*
<TheMue> rog: Why do we have an own log package instead using the Go log package?
<rog> TheMue: i think it's so that we have a central place to set up logging (it's not possible to set up the normal log package so it prints to anything other than stderr, i think
<rog> )
<TheMue> rog: It can, log.SetOutput(w io.Writer)
<rog> TheMue: also, we want to layer it on top of gocheck, but you can only layer log onto io.Writer
<rog> TheMue: oh yes
<TheMue> rog: The package is not yet optimal but quite flexible.
<rog> TheMue: but the latter point remains
<TheMue> rog: How about letting gocheck implement the Writer interface?
<rog> TheMue: the writer interface is not really record-oriented
<TheMue> rog: The Go log is standard and used by other packages too. How do we handle logging of used package that we don't develop on our own?
<TheMue> rog: And an own writer impl could do intelligent stream parsing too.
<rog> TheMue: i had this discussion with niemeyer before, and i lost. you'll have to convince him, not me.
<TheMue> Maybe we should talk about it in Bud.
<niemeyer> TheMue: Note that we're not replacing the log package in any way
<TheMue> rog: Another topic. Currently we use Makefiles. You once talked about the migration to use goinstall. How is the status here?
<niemeyer> TheMue: We're building on it
<niemeyer> TheMue: rog had the same feeling originally, but it isn't the case
<rog> TheMue: we use both Makefiles and goinstall
<TheMue> niemeyer: OK, we will do so. Currently it's only fmt based.
<rog> TheMue: currently you can't avoid Makefiles if you want to use gotest
<niemeyer> TheMue: and I can certainly understand why both of you had that feeling.. the entry point of logging is a different function, and we now have a package named "log"
<niemeyer> TheMue: Not really.. we don't format the actual log
<m_3> marcoceppi: ping
<marcoceppi> m_3: pong
<niemeyer> TheMue: What we do is trivial fmt.Sprintf
<TheMue> rog: Yep, I hope this will be fixed soon, already before Go1.
<niemeyer> TheMue, rog: => #juju-dev please
<rog> i was just going to suggest that
<m_3> marcoceppi: can you please change ownership of lp:charm/roundcube to ~charmers?
<marcoceppi> m_3: yes
<marcoceppi> Did I progumate wrongly?
<m_3> marcoceppi: dunno... needs to end up owned by charmers... perhaps it's a bug in charm promulgate
<m_3> marcoceppi: it happens to me too.. have to go manually change ownership to charmers afterwards
<jcastro> marcoceppi: it's god punishing us for creating a command called "promulgate"
<m_3> rofl
<marcoceppi> m_3: haha, changed :)
<jcastro> awesome, so roundcube is done?
<jcastro> and phpmyadmin was mostly done right?
<m_3> marcoceppi: gracias
<marcoceppi> jcastro: Yeah, I need to test the apt->upstream->apt->upstream to make sure there isn't anything ugly lurking
<marcoceppi> Otherwise it was ready for review. So, if I get time today *crosses fingers*
<jcastro> marcoceppi: nitpick on using "aptitude" in your function for installing from the archive btw.
<jcastro> perhaps "repository" or something would make more sense? </bikeshed>
<marcoceppi> Ah, I was like NO WAY I USE APT I SWEAR
<marcoceppi> repository would be better <3
<m_3> jcastro: roundcube is in... still have a couple of test scenarios, but they'll just be bugs against trunk if those fail
 * jcastro nods and will just give those a couple of days
<nijaba> SpamapS: marcoceppi: could some of you have a look at lp:~nijaba/charm-tools/peer-scp and tell me how I can write a test function for it? alias scp and build a state test function?
 * marcoceppi recommends rsync <3
<nijaba> marcoceppi: already done with scp, easy to allow for the option
<SpamapS> nijaba: or start your own sshd on a random port and actually do the scp. ;)
<SpamapS> marcoceppi: re ubuntu cloud live, yes that should work. I've been meaning to try juju against it for a while.
<SpamapS> Hmm, looks like there's a test that looks for a very specific error message which sometimes shows up differently...
<SpamapS> https://launchpadlibrarian.net/87459690/buildlog_ubuntu-oneiric-i386.juju_0.5%2Bbzr432-1juju2~oneiric1_FAILEDTOBUILD.txt.gz
 * hazmat peeks
<hazmat> hmm
<SpamapS> hazmat: when I run that test locally on precise it passes
<SpamapS> hazmat: so I'm wondering if its just something weird running in the buildd chroot
<hazmat> SpamapS, there's no external interaction, the error is being setup by the test via a mock
<SpamapS> hazmat: so is this a case where something else is causing said error?
<hazmat> SpamapS, no.. its the error reporting not matching the expected error text
<hazmat> SpamapS, the error is coming back with some additional traceback information that the test doesn't like
<hazmat> SpamapS, splitting the expected strings and asserting both are in the output would suffice to resolve and maintain the expectation
 * hazmat digs up a trivial patch
<hazmat> it is odd that the error representation would change for buildd but not for local usage
<hazmat> here's the trivial patch http://paste.ubuntu.com/770590/
<SpamapS> hazmat: I'm trying the test in a local sbuild chroot to see if it is different
<SpamapS> hazmat: fails in a clean chroot, so some python module is changing things on our local machines
<SpamapS> or lxc maybe?
<hazmat> SpamapS, interesting.. i'd suspect a change to the logging module or twisted
<SpamapS>     test_watch_new_service_unit ... No handlers could be found for logger "juju.agents.machine"
<SpamapS> I see that, but that is much earlier
<hazmat> SpamapS, that's not particular indicative of anything in this context, except a test didn't care about log output, and didn't setup a default logger
<hazmat> ie. its harmless
<SpamapS> hazmat: in oneiric, none of the modules have changed...
<SpamapS> well shoot, WTF has been failing since 431
<hazmat> hmm
<hazmat> oh..
<hazmat> ah
<hazmat> and functional tests since 429
<SpamapS> hazmat: your trivial in 431 changed this text
<hazmat> SpamapS, yup
<hazmat> i'll commit the trivial fix then
<SpamapS> yeah
<SpamapS> it looks good to me, +1
<hazmat> niemeyer, wtf functional tests are failing with.. Bootstrap aborted because file storage is not writable: Error Message: You have attempted to create more buckets than allowed
<hazmat> for the last few revs
<SpamapS> hazmat: wait, can you push it to a branch and I'll try it in a chroot?
<hazmat> SpamapS, sure
 * SpamapS realizes its already been pastebinned..
<SpamapS> hazmat: if you haven't pushed it already, belay that.. I can do it here
<hazmat> SpamapS, un momento new patch coming
<hazmat> SpamapS, http://paste.ubuntu.com/770604/
<SpamapS> yeah the 1st one didn't work ;)
<SpamapS> hazmat: confirmed, that fixes it
<SpamapS> hazmat: if you want to test in a chroot (highly recommended) its pretty easy.. install ubuntu-dev-tools, run 'mk-sbuild oneiric', and then 'schroot -c oneiric-amd64 -u root' to get a clean oneiric chroot to play in (that gets cleaned up on exit)
<SpamapS> apt-get build-dep juju will pull in all the build deps
<SpamapS> .. obviously ;)
<hazmat> SpamapS, why not just lxc?
<hazmat> SpamapS, thanks i'll try that out
<SpamapS> hazmat: because this is nearly identical to the buildd
<nijaba> SpamapS: ok, will try, thanks
<nijaba> marcoceppi: first version with rsync as an option: lp:~nijaba/charm-tools/peer-scp/
<nijaba> SpamapS: (context: start my own scp)
<nijaba> sshd even
<_mup_> juju/trunk r433 committed by kapil.thangavelu@canonical.com
<_mup_> [trivial] fix provider unit test regression from r431, from overly exact error output check [r=clint-fewbar]
<niemeyer> hazmat: I noticed that, and cleared them today
<niemeyer> I'm heading out for the day.. cheers everybody!
<hazmat> niemeyer, cheers
 * hazmat debates heading out to a nodejs meetup
 * SpamapS dist-upgrades his precise box with fingers firmly crossed
<hazmat> smoser, do you  know if cloud-init is installed on the rackspace cloud instances by default
<hazmat> apparently not
<_mup_> juju/ssh-known_hosts r439 committed by jim.baker@canonical.com
<_mup_> Inject keys as part of cloud-init for ZK instances
<_mup_> juju/ssh-known_hosts r440 committed by jim.baker@canonical.com
<_mup_> Merged trunk & resolved conflicts
#juju 2011-12-15
<hazmat> woah.. that's awesome..
<hazmat> job requirement -> An infrastructure management nut: Chef or Juju preferred.
<SpamapS> hazmat: nice
<m_3> we've arrived
<jimbaker> http://careers.stackoverflow.com/jobs/15084/devops-infrastructure-engineer-surveymonkey has the detailed requirement. very cool indeed
<jimbaker> and apparently one other: http://www.dovajobs.com/job-details.html?jobid=4405192&jobtitle=devops+engineer+-+mountain+view%2c+ca&joblocation=mountain+view&jobcountryid=222
<jimbaker> ironically, juju.com is a job search engine; doubly ironically, one of the local python users works for them (remotely)
<SpamapS> jimbaker: haha
<SpamapS> jimbaker: I used to work for a job board company. Its a weird space.. so dominated by monster and linkedin at this point. :p
 * hazmat picks up a book on ITIL
<_mup_> juju/ssh-known_hosts r441 committed by jim.baker@canonical.com
<_mup_> Properly handles key injection
<fwereade> niemeyer, sorry, I never followed up on the start hook guarantee discussion
<fwereade> niemeyer, you had more thoughts?
<niemeyer> fwereade: I have some, and it'd be nice to catch up about the subject at some point
<niemeyer> fwereade: Right now is not a great time for me, but maybe later today?
<fwereade> niemeyer, sure, just ping me when it works for you
<niemeyer> fwereade: Sounds great, thanks!
<fwereade> niemeyer, offhand: when will we find out dates of UDS in April?
<fwereade> niemeyer, (or who should I be asking who might know ;))
<niemeyer> fwereade: Marianna might be the best bet
<niemeyer> fwereade: But the page is generally updated as soon as she knows it, IIRC
<fwereade> niemeyer, cool, thanks
<niemeyer> "We are excited to announce our new South America (Sao Paulo) Region."
<niemeyer> Brilliant!
<therve> niemeyer, finally fast AWS for you? :)
<niemeyer> therve: Finally :)
 * hazmat yawnsw
<hazmat> another day, another ec2 region
<hazmat> hmm.. the sao paulo region appears to be the most expensive of the bunch
<oarcher> hi all. After deploying a charm, all was ok. But after rebooting the nodes, juju status say that 'state: down' for all services, and 'state: not-started ' for bootstrap. But all services are working fine ... Does anybody know how to say juju that everything  is ok ?
<oarcher_> why 'juju status' bring my node to state 'down' after a reboot ? Everything seems to work well !
<niemeyer> oarcher_: Which provider are you using? Local?
<oarcher_> yes, i'm using local
<niemeyer> oarcher_: Ok.. it still doesn't work over reboots
<oarcher_> Is it a bug report that i can follow ?
<hazmat> oarcher_, its a known problem with work addressing already in progress
<lynxman> hey guys o/ I'm writing a charm for a service that generates a certificate on the server side, I'd like to know if there's any best practices in order to transfer the certificate to the client charm (needed for bilateral auth)
<lynxman> any charm I can have a look that would give me an example of that?
<mchenetz> lynx man, betâ¦ installed your port install of juju yesterday and got it working. However, juju did not work for local provider because of apt issues
<lynxman> mchenetz: yeah I couldn't include apt in my build since OSX was lacking it :)
<mchenetz> hehe
<lynxman> mchenetz: happy to hear all the rest worked though, I need to find a way around that
<mchenetz> lynxman: i am working on a solution with virtual box as a provider
<lynxman> mchenetz: oooh schweet
<mchenetz> i will probably create a brew repo after that
<lynxman> mchenetz: let me know when you do so I can give it a ride :)
<mchenetz> most defintiely
<hazmat> lynxman, via relation data
<lynxman> hazmat: any example I can have a look at? :)
<hazmat> lynxman, no.. but you'd just encode the cert you want to transfer and set it on the relation... via relation-set
<lynxman> hazmat: cool!
<hazmat> lynxman, one qualification to doing that its available to all related units of the remote service
<lynxman> hazmat: yeah it should be intended to work like that in this case so it's more than fine
<hazmat> er.. all units of the related service
<hazmat> cool
<rog> is anyone else having problems with launchpad?
<rog> i'm consistently seeing this message: http://paste.ubuntu.com/771240/
<rog> hazmat, fwereade: ^
<fwereade> rog, I've seen it once or twice in the past, it usually goes away again quite quickly
<rog> fwereade: i hope so - i've mucked up lp:juju/go and i need to restore it before anyone notices :-)
<fwereade> rog, and it's happening for me too ATM
<rog> good. i thought it might be something i'd done locally
<rog> fwereade: thanks
<fwereade> rog, don't worry, probably nobody else could see it... until you confessed :p
<rog> fwereade: they might have noticed that it had lost the last 2 revisions...
<rog> "Warning: criss-cross merge encountered.  See bzr help criss-cross."
<rog> yay
<fwereade> rog, that's *usually* less painful than it sounds, were there any actual conflicts?
<rog> fwereade: actually, no. i reckon they shouldn't write that message if there are no conflicts...
<fwereade> rog, I dunno, I think it's quite handy to be notified when you're merging weirdly, but the message could probably use some work
<SpamapS> fwereade: o/ ahoy there!
<SpamapS> rog: ^^
<rog> SpamapS: hi
<fwereade> heya SpamapS
<SpamapS> nijaba: hey, I need to use the ch_peer_* stuff in a charm I'm working on ... are you going to have time to update with the stuff I mentioned in my review?
<hazmat> nijaba, btw that stuff is awesome (ch peer*)
<hazmat> glad its there
<SpamapS> Yeah, its going to make peer relations much easier to read. :)
<SpamapS> and write
<SpamapS> hazmat: hopefully ch_peer_leader will be able to just call 'relation-leader'  at some point. ;)
<hazmat> anyone seen this error while running unit tests.. OpenSSL.SSL.Error: [('system library', 'fopen', 'No such file or directory'), ('BIO routines', 'FILE_CTRL', 'system lib'), ('SSL routines', 'SSL_CTX_use_certificate_file', 'system lib')]
<SpamapS> hazmat: where would we even be using OpenSSL.SSL ?
<hazmat> SpamapS, it gets invoked as part of the digest auth impl cert checking by twisted
<SpamapS> what cert checking do we do? :p
<rog> meeting?
<hazmat> rog, invites out
<hazmat> SpamapS, niemeyer, m_3, jcastro, jimbaker, bcsaller, TheMue, fwereade.. its that time of the week
<jimbaker> hazmat, indeed
<rog> hazmat: i see no invite
<TheMue> Yep, no invite yet
<hazmat> hmm
<SpamapS> hazmat: joining shortly
<hazmat> TheMue, rog resent to you individually
<hazmat> i tried using a circle this time around, but it seems a little flakey
<rog> hazmat: got it now
 * SpamapS adds sa-east-1 to the regions allowed
<m_3> be on late... might miss this one
<niemeyer> Nothing here either.. and I
<niemeyer> have a meeting in ~17 mins
<niemeyer> Ah, got the invite now.. joining
<niemeyer> Interesting that it didn't send a notification
 * robbiew can't attend...but also knows he's the least important in the "room"...and has NO problem with that reality :P
<niemeyer> It's really bad today for some reason
<niemeyer> I can't hear a single thing :(
<niemeyer> Now it says "The server connection has been lost"
<niemeyer> hazmat: Am I the only one having issues?
<hazmat> niemeyer, yes
<hazmat> niemeyer, let me try inviting again.. not sure what else to do
<niemeyer> hazmat: The invite isn't the issue.. I can see it
<niemeyer> hazmat: It's just so laggy that I can only hear noise
<hazmat> niemeyer, i'm taking notes i'll send out
<hazmat> niemeyer, sometimes killing all flash on the system i've found helpful
 * SpamapS runs test suite for 4th time a/ sa-east-1 added
<niemeyer> Doesn't really work.. and Chrome seems to be leaving processes behind when I close it
<niemeyer> Will try reinstalling the beta
<niemeyer> Downgrading didn't help either
<niemeyer> I'm giving up this time around..
<hazmat> niemeyer, i had that problem once i had to shutdown both browsers, and hand kill the processes, to clear out all the flash players
<hazmat> er. chrome /firefox
<hazmat> twas strange
<hazmat> m_3, is that github mirror stuff automated?
<niemeyer> hazmat: Yeah :/
<m_3> hazmat: it's partially so atm... should be fully automated by tonight
<m_3> hazmat: and I'd rather trigger from pushes, but it's cron atm
<m_3> putting tests and notifications in place b/c git-bzr-ng is... um... problematic at times :)
<robbiew> m_3: ping...you see my email re:objectives? :)
<SpamapS> hm, test suite failing on trunk
<SpamapS> http://paste.ubuntu.com/771484/
<SpamapS> hazmat: any ideas? ^
<jimbaker`> SpamapS, you need to clean your checkout of pyc files
<jimbaker`> SpamapS, so in particular, juju.providers.ec2.tests.test_connect is gone
<SpamapS> AHH
<hazmat> hmm
<hazmat> indeed
<SpamapS> so, I think we need to fix bug #893176
<_mup_> Bug #893176: do not limit ec2 region to static list of regions <juju:New> < https://launchpad.net/bugs/893176 >
<SpamapS> seems like Amazon brings on a new region every 6 - 8 weeks
<SpamapS> What about just changing it to a free-form string
<SpamapS> btw do you guys have a good way to speed up the test suite? ;)
<jimbaker`> SpamapS, not fast enough for you?
<SpamapS> takes 10 minutes
<jimbaker`> maybe we could use zk's chroot functionality
<jimbaker`> so we could run chunks in parallel don't know
<SpamapS> 10 min is still quite managable.. just wondering if there are any tricks. :)
<jimbaker`> SpamapS, the other question is, are you running w/ a ssd?
<jimbaker`> because my time is much better. too slow, i'd like to run it on every change. but fast enough that i'm not certain what it is right now :)
<SpamapS> jimbaker`: well the .py and .pyc's are all in cache, and the ZK is on tmpfs.. so it shouldn't matter really
<SpamapS> hm actually /tmp is just / ... so not tmpfs. Hrm.
<hazmat> SpamapS, it takes under 5 with an ssd
<hazmat> SpamapS, you can do partial runs by passing in either a package or filename to ./test
<m_3> robbiew: yup, sure did
 * m_3 reading them now
<robbiew> m_3: lol...okay
<SpamapS> hazmat: at this point, I always run the whole thing. :)
<jimbaker`> SpamapS, i agree with that sentiment
<SpamapS> hazmat: I do partial runs while developing, but always the full run before commit. :)
<SpamapS> and now, the full run, in a clean oneiric chroot
<jimbaker`> ok, i just reran test on my laptop - 2m50s
<hazmat> nice
<hazmat> jimbaker`, out of curiosity which ssd do you have
<m_3> robbiew: sounds perfect... thanks!
<robbiew> m_3: awesome...3 down...too many more to go! :P
<jimbaker`> hazmat, it's the vertex whatever you recommended. i have two, one in my desktop, one in my laptop
 * m_3 has objectives now!
<SpamapS> hrm, why would SSD matter that much? Just for ZK?
<jimbaker`> thanks for the recommendation!
<hazmat> we should clean up the status tests, their dogs, they setup entire universes to test a little piece, that will shave at least a 1.5 m off
<hazmat> SpamapS, yeah.. primarily.. you could also try a tmpfs mount
<jimbaker`> SpamapS, everything in ZK is logged persistently
<SpamapS> m_3: If one of them isn't "make clint a sandwich" ... you may want to revise.. ;)
<m_3> SpamapS: ha
 * m_3 revises objectives
<SpamapS> hazmat: I always thought /tmp was tmpfs.. but it isn't.. remounting it soon :)
<hazmat> SpamapS, 38s in.. http://www.youtube.com/watch?v=H7PJ1oeEyGg
<hazmat> actually 35s in
<hazmat> his whole speil is get an ssd
<hazmat> gotta run to airport, bbiab
<SpamapS> so.. weird.. when hazmat pushed to juju trunk the other day, _mup_ noted it. But I just pushed, and no note from _mup_
<SpamapS> is _mup_ only watching by *user* ?
<therve> SpamapS, it's a client side bzr config afaict
<SpamapS> as in, they're somehow pinging mup?
<therve> yeah, it's a postcommit hook
<SpamapS> that seems rather silly
<SpamapS> I suppose its more efficient than the bot polling all the branches.. but really.. hrm.
<m_3> SpamapS: there was talk of moving mup over to juju-dev... perhaps that's halfway done?
<SpamapS> I think the thought was to just have it *also* in juju-dev
<hazmat> SpamapS, its a per user client side thing
<hazmat> SpamapS, i think a bot polling would be more useful
<hazmat> that sounds like a nice funtime project
<SpamapS> hazmat: another thing to consider is to just have WTF do it (jenkins has an awesome irc bot.. )
<niemeyer> Woohay.. new lbox built
<zirpu> what's an lbox? lxc?
<niemeyer> zirpu: Nah, just a tool some of us use for development
<niemeyer> zirpu: It's not so exciting really.. it's exciting because I can now do something else ;)
#juju 2011-12-16
<adam_g> SpamapS: around?
<SpamapS> adam_g: yeah, whats up?
<adam_g> SpamapS: nvm.. was about to start with "am i losing my mind or...."  turns out i am :)
<SpamapS> adam_g: welcome to the club!
<SpamapS> adam_g: wait till you attend one of our parties
 * hazmat signs out
 * nijaba is back after an unwanted rm -rf which included a mount --bind /usr/bin
<nijaba> SpamapS: I'm finishing sc_peer_copy (rsync/scp)
<nijaba> SpamapS: the hardest part is the test function
<nijaba> SpamapS: should be almost there
<nijaba> hazmat: thanks :)
<shazzner_> hello
<shazzner_> does anyone know how to write juju charms?
<shazzner_> I'm working on one and had some questions
<shazzner_> try to make a charm of gitolite: http://sitaramc.github.com/gitolite/
<robbiew> shazzner_: it's pretty late for most of the team, so you might be better off asking tomorrow or posting to the list juju@lists.ubuntu.com
<SpamapS> shazzner_: agreed with robbiew, I'm about to head to bed myself. Note that the instructions on that first page are basically your 'install' hook, and the "mirroring" instructions look like they might be good for peer relations (so you can scale out your gitolite servers on demand)
<shazzner_> thanks guys, i'll try again tomorrow
<rog> mornin'
<fwereade> heya rog
<mpl> hi all
<rog> mpl: hiya
<mpl> hi rog
<mpl> rog: btw, did you guys get man answer to gustavo (about the zk/ssh thing) a couple or so days ago? I thought I sent it, but I'm a bit distracted these days. and since I haven't gotten any reply...
<mpl> s/man answer/my answer/
<rog> mpl: yes, we did thanks
<rog> mpl: well, i did anyway
<rog> mpl: i hadn't noticed ssh.Client.Dial...
<mpl> rog: ok, and did I seem to have understood correctly gustavo's plan?
<rog> mpl: i think so.
<mpl> rog: I hadn't noticed it either, Dave had to point it out to me :)
<mpl> imho it's not obvious enough in the documentation that this is the way to achieve ssh port forwarding.
<mpl> one way at least.
<heyho> hello there
<koolhead11> heyho: hi
<heyho> i've a problem with juju bootstrap can you give me a hand?
<koolhead11> don`t ask just ask :)
<heyho> ok, i'm getting the error: dict object has no attribute read
<koolhead11> heyho: you will have to tell me your environment and yaml config along with error. please pastebin it
<fwereade> heyho, I've heard a couple of reports of something similar
<fwereade> heyho, you're running against orchestra, right?
<heyho> yeah.. the problem is also that I'm using juju in a virtual machine and I can't copypaste it..
<fwereade> heyho, apt-get install pastebinit :)
<fwereade> heyho, but I'd be most interested to know what OS and cobbler version you're running on the orchestra VM
<heyho> i'm using ubuntu 11.10 oneiric server x64
<heyho> my environment.yaml is this: http://pastebin.com/SWiNejBc
<fwereade> heyho, the environents file looks fine
<fwereade> heyho, sudo cobbler --version
<fwereade> heyho, (no idea why it wants superuser powers to get the version)
<heyho> i also think i'm using the latest version of orchestra (2.26)  and cobbler (2.1.0)
<heyho> is there any limitations if i'm running orchestra as a VM?
<fwereade> heyho, orchestra should be just fine in a VM
<heyho> ok..I also configured cobbler and added new systemz but, while in my previous attempts I received an ssh error by juju status but the bootstrapped worked, recently i reinstalled completely orchestra and juju and now i get the error on juju bootstrap
<fwereade> heyho, it doesn't look like that issue's been captured in a bug yet
<fwereade> heyho, am I correct in thinking that the only difference you're aware of between that, and your previous setup, is the orchestra version?
<heyho> I managed to get the full error I receive on bootstrap http://pastebin.com/JcF4989s
<heyho> I think so
<fwereade> heyho, thanks very much for the error log; I'm quite sure I've seen someone else reporting that here, I'll make a bug and try to get onto it as soon as I can
<heyho> yes
<heyho> I saw an irc log with my same error
<fwereade> heyho, would the local provider be an OK workaround for you in the meantime?
<heyho> I didnt understand your question..
<heyho> is  maybe the problem related in the interaction beetween juju and the cobbler ks_meta?
<fwereade> heyho, I mean that -- since orchestra doesn't work and I can't immediately supply a fix -- it may be possible for you to experiment with juju using the local LXC provider instead of orchestra in a VM
<fwereade> heyho, it certainly is
<fwereade> heyho, but tracking down the precise cause and fixing it may take a little time
<fwereade> heyho, and so I'm keen to find you some way to be able to work with juju despite this bug
<fwereade> heyho, hence the local provider suggestion
<heyho> I imagine and I thank you for your alternative, but I'm not aware how to use Juju as you suggested me.. What's the local LXC provider
<fwereade> heyho, let me try to find you a writeup -- basically it runs the "machines" as LXC containers, which are a bit like chroots
<fwereade> heyho, https://juju.ubuntu.com/docs/provider-configuration-local.html
<niemeyer> Good morning all
<fwereade> heya niemeyer
<fwereade> heyho, btw, where did you get juju from?
<heyho> from juju pkgs
<fwereade> heyho, thanks
<heyho> I'm reading your link right now
<koolhead11> heyho: you can also see http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage :D
<koolhead11> hello niemeyer
<heyho> that's even better thanks
<heyho> do i have to install juju on a physical machine I presume..but do I add pkgs repository or no?
<heyho> hello to niemeyer
<koolhead11> heyho: you can use the default pkg from oniric repo and it works too :)
<_mup_> Bug #905286 was filed: orchestra: dict has no attribute read <juju:New> < https://launchpad.net/bugs/905286 >
<heyho> I'm getting this error at local juju bootstrap http://pastebin.com/b3JxLRKu
<heyho> I previously rebooted networking service..do I need to reboot the entire system?
<nijaba> SpamapS: your comments for ch_peer stuff should have been addressed.  Let me know
<fwereade> heyho, I'm sorry, I don't recognise that error -- probably best to just try a reboot, according to koolhead11's link, anyway :)
<koolhead11> heyho_: You may also need to set net.ipv4.ip_forward=1 in you /etc/sysctl.conf
<koolhead11> and then reboot the system
<heyho> hello, I rebooted twice (first time I removed my bridge in interfaces) but I'm getting the same "network is already active" error . I also configured ip4 forward
<koolhead11> heyho: am running juju on my physical machine running oneiric. I had same error you mentioned and i followed exact steps as given in askubuntu and it worked for me
<fwereade> niemeyer, re constraints spec... I'm becoming concerned about the overlap between ec2-instance-type and arch/cpu/mem
<niemeyer> fwereade: It crossed my mind too
<heyho> ok I'll retry again
<niemeyer> fwereade: Are you finding any practical issues?
<fwereade> niemeyer, so far, only in thought experiments
<niemeyer> fwereade: Ok, anything in specific that you're concerned?
<fwereade> niemeyer, well, consider an environment in which you specify cpu/arch/mem, and then try to set service constraints to an ex2-instance-type which is below those specs
<niemeyer> fwereade: Ok?
<fwereade> niemeyer, according to the spec, the harshest constraints win, which will be the env-level "mem=16G" rather than the service-level "ec2-instance-type=t1.micro", for example
<fwereade> niemeyer, I feel this rather violates the principle of least surprise
<niemeyer> fwereade: That's not what I had in mind when we talked about that
<fwereade> niemeyer, ah, sorry, I must have misinterpreted you :(
<niemeyer> fwereade: What I had in mind is "the most specific constraint wins", which would highlight ec2-instance-type in this case
<fwereade> niemeyer, most specific in terms of scope?
<niemeyer> fwereade: most specific in terms of the provider
<niemeyer> fwereade: If we know the instance type, everything else is more vague
<fwereade> niemeyer, so I can't override an env-level m1.small with a service-level mem=16G?
<fwereade> niemeyer, I suppose it's reasonable
<niemeyer> fwereade: The interaction between several levels is a good question
<fwereade> niemeyer, I suppose it's reasonable to say that once you've specified m1.small you need to override with m2.xlarge
<niemeyer> fwereade: Maybe we should take the most specific on each level
<fwereade> niemeyer, ok, I think that could work
<fwereade> niemeyer, looks like lunchtime, I'll ponder a bit longer :)
<niemeyer> fwereade: So in your example, mem on the service would win
<fwereade> niemeyer, if the user expresses that they want service machines to have 16G, I feel we should prbably give them service machiens with 16G regardless of underlying env constraints
<heyho> I'm still getting the same error after 3 retries. I'm taking a break now..after that I'll try on another oneiric machine (this one had libvirt and virtual bridges already installed for virt-manager..I removed them but maybe there's still some configurations left that are causing the problem)
<hazmat> fwereade, for provider specific vocabularies, its not going to be clear what the default is  in many cases
<hazmat> the juju default is, since its a detail of the provider
<niemeyer> fwereade: Right
<fwereade> hazmat, the spec has defaults for all the constraints, what's not clear?
<fwereade> hazmat, ok, the defaults are often "unset"
<hazmat> fwereade, for provider specific vocabularies its not very clear what a reset to default implies, what's the default ec2-region, what's the default rack, what's the default cpu-firmware
<fwereade> hazmat, I imagined the default to usually be "don't filter on this at all"
<fwereade> hazmat, but the default ec2-region is us-east-1
<hazmat> yup, but unset is can still a imply default value for the provider, but its internal to the provider
<hazmat> and not per se documented or discoverable
<hazmat> not much to be done about it i guess, i'm just curious/concerned about discoverability of these default values
<fwereade> hazmat, it seems to me that, tautologically, people who don't care about cpu firmware or rack placement... don't care about cpu or rack placement, and so they can get what they're given and like it ;)
<fwereade> hazmat, and indeed, as you say, maybe not much can be done anyway
<heyho> Hello again. So I managed to bootstrap juju successfully (I had to disable previous installed virtual bridges); how can now deploy charms (ex: mysql) ? I need a local repository? I used charms getall and created a directory named jujulocal but i get this error "ERROR Charm 'local:oneiric/mysql' not found in repository /home/stefano/jujulocal"
<fwereade> heyho, is there a charm at /home/stefano/jujulocal/oneiric/mysql?
<fwereade> heyho, if they're just flat inside jujulocal, it won;t find them
<heyho> No, It would be in /home/stefano/jujulocal/mysql without oneiric dir..
<heyho> do I need to change that in environment.yaml and bootstrap again?
<fwereade> heyho, (sorry, I'm semi-lunching) repository structure is: repo contains a dir for each series; each series dir contains charms for that series
<fwereade> heyho, so if you move everything from jujulocal to jujulocal/oneiric, you should be fine
<heyho> that's what I just did. And I also changed data-dir in environments adding /oneiric
<heyho> Now i successfully deplyed mysql and wordpress and I get this with juju status http://pastebin.com/zTCRXz84  Why are them in pending state (and not started)?
<hazmat> heyho, if its the local provider, it has to build the container via debootsrap
<hazmat> when you first deploy
<hazmat> it takes a few minutes depending on the speed of your hard disk and net connection
<hazmat> its a one time operation, the packages and a template container are cached on disk
<hazmat> so subsequent deploys or add-unit are fast
<heyho> so I deployes 3 services but they are still pending just because they need time, right?
<heyho> how does juju assign a public ip to the services?
<hazmat> heyho, you should be able to see the activity of the container creation with lxc-ls which shows extant containers and runing containers
<hazmat> heyho, all containers/services deployed with local provider are only accessible from the host machine
<hazmat> heyho, effectively their services under local provider are behind a NAT, the only public ip is the hosts
<hazmat> heyho,  of course other providers don't have this issue, but local provider in particular was intended for development and prototyping
<heyho> hazmat, I think something went wrong because the report of my juju status http://pastebin.com/fUSyUL1Z is missing services' relations and ip assigned to them
<m_3> heyho: it looks like they're still installing... takes a _while_ for the first local install
<hazmat> well.. its been an hr..
<hazmat> so not that long
<m_3> wow... ok
<heyho> exactly..
<hazmat> heyho, there's some logs in the $data-dir variable you specified in environments.yaml
<hazmat> that would hold additional error information
<heyho> it contains only charms directories
<heyho> maybe i should destroy environment and create a new one?
<m_3> I'd recommend a cleanup ( destroy-environment, wipe lxc cache /var/cache/lxc )
<m_3> maybe deploy a single service next time around... once that's 'started' then you know the lxc template has been built out
<heyho> ok I'm doing this
<m_3> from there you should be able to bring things up quickly... or debug that single lxc instance
<heyho> I get this error with destroy-environment "INFO Destroying unit containers... lxc-wait: bind : Address already in use"
<m_3> you can watch the lxc images get built out on the filesystem at /var/lib/lxc I think
<m_3> hmmm... ok, then something more complicated is going on here
<heyho> maybe I should remove the images in /var/lib/lxc?
<m_3> Do you have a stock libvirtbin install?  i.e., with dnsmasq serving up the 'default' network for virsh?
<m_3> when my local env is destroyed, /var/lib/lxc is empty
<heyho> I had virt-manager installed but i removed it and installed libvirtbin again.. ok, i'm removing images in that directory
<m_3> the local provider docs and inststructions definitely assume you haven't tweaked your libvirt setup... I'm a tweaker and've been hit by that before :)
<m_3> cool... with a purge and re-install of libvirtbin you should be golden
<m_3> easy enough to check that `ps auwx| grep dnsmasq` is running and `ip addr show` shows virbr0 correctly
<heyho> ok I purged libvirt-bin.. dnsmasq is runnig and ip addr shows vbr-default-0
<m_3> vbr-default-0 looks strange
<heyho> yep
<m_3> virsh net-list --all
<heyho> it's something like name:default state:active autostart: yes
<m_3> /etc/libvirt/qemu/networks/default.xml contains the name of the bridge
<m_3> yours might've been added by something else, hence the strange name
<heyho> and "ip addr show" contains, besides lo and eth0, these two things: http://pastebin.com/9AsXFqVj
<heyho> i should remove them?
<m_3> heyho: I'd `/etc/init.d/libvirt-bin stop` and then remove any bridge interfaces that're there
<m_3> heyho: then check the contents of /etc/libvirt/qemu/networks/default.xml to look like stock (http://paste.ubuntu.com/772295/) and restart libvirt-bin
<heyho> i removed them with "virsh net-destroy default" and after that I tried to do "service libvirtd restart" with response libvirtd: unrecognized service!
<m_3> don't remember the name of the service... looking
<m_3> libvirt-bin
<m_3> you'll need a default net for libvirt though
<m_3> (BTW, I'd recommend EC2 over local provider at this point if that's an option)
<hazmat> so.. removing /var/cache/lxc isn't generally useful its just the debootstrap cache
<hazmat> the error about lxc-wait bind, is because there is already an lxc command currently running on the system
<hazmat> that device vbr-defat-0-nic is odd
<heyho> ok I think i removed them
<m_3> even the vbr-default-0 is odd too
<heyho> now ifconfig looks clean
<heyho> i reinstalled libvirt-bin
<hazmat> heyho, does the output of `groups` contain libvirtd for you?
<heyho> i still have installed libvirt-0.. do you know what's that?
<heyho> yes it contains it
<m_3> libvirt0's ok to be there
<hazmat> its the libvirt runtime library files
<heyho> ok so i basically have eth0 and lo.. but not virbr0 comparing in ifconfig.. is that ok?
<hazmat> yup
<hazmat> heyho, there was no files in your data-dir?
<heyho> actually there were, now i deleted them.. In environments.yaml I should write the data-dir path excluding the distribution subfolder right?
<heyho> like /home/stefano/jujulocal and not /home/stefano/jujulocal/oneiric
<heyho> i tried another juju bootstrap resulting in this error http://pastebin.com/jzd6xz1i
<_mup_> Bug #905366 was filed: local provider needs a dedicated network <juju:New> < https://launchpad.net/bugs/905366 >
<hazmat> m_3, re last bug, how many bridges can you attach to a physical device
<heyho> i'm trying to reboot the machine again, brb
<m_3> heyho: grab the default.xml from http://paste.ubuntu.com/772295/ and then something like `virsh net-define default.xml`
<m_3> i.e. the default net's gotta be created
<m_3> hazmat: unknown
<m_3> hazmat: it's actually not attaching to a physical device though, right?
<m_3> there are bridges that do that, but not the virbr's we're using
<hazmat> hmm..
<hazmat> yeah.. i thought there was a reason it was problematic .. but its not clear why.. if we're not attaching it
<m_3> I've had 4 virtual bridges working at the same time w/o any problems (other than iptables spaghetti)
<m_3> in addition to a physical-bridge
<m_3> (sad attempt at euca HA)
<heyho> ok, I succeded in juju bootstrap
<heyho> now i need to getcharms and then deploy one of them right?
<m_3> yes, get a charm and deploy a single service to to kick off the lxc template build
<m_3> that'll be 'pending' for a few minutes while it installs
<heyho> ok..and i also need to create a oneiric subfolder in my localdir right?
<m_3> 'charm get mysql' is faster than 'charm getall'
<m_3> yeah, so I 'mkdir -p ~/charms/oneiric'
<m_3> 'cd ~/charms/oneiric && charm get mysql'
<m_3> then your deploy lines will need a repo like 'juju deploy --repository ~/charms local:mysql mydb'
<m_3> i.e., charms don't need to live in the local provider's 'data-dir'
<heyho> well, that's a very effective explanation thanks
<jcastro> m_3: let's do a quick charm update later today even though we've been gone
<m_3> jcastro: cool man.. we've got a colorado-canonical-crew holiday lunch, so maybe a mobile hang-out on the drive up?
<jcastro> that would be perfect
<jcastro> I'm thinking it's 5 minutes, tops
 * SpamapS is having breakfast right now with the los angeles canonical crew... 
 * m_3 proscribes thorazine for that
<m_3> whoops... s/proscribes/prescribes/ :)
 * SpamapS proscribes rhymes
<m_3> forgot your gang-sign
<heyho> guys thank you very much for your support! With your help I managed to fix the configuration issues
<m_3> heyho: woohoo!!
<heyho> yeah!
<SpamapS> heyho: was there something wrong with your system, or is there something we could do to make this process easier?
<heyho> next big step will be for me to use juju on ec2 and orchestra!
<heyho> there was a previous configuration of libvirt (because I used virt-manager) that I think it may have caused problems
<heyho> even if i removed that
<SpamapS> heyho: that sounds like something we could fix in juju
<heyho> yeah, with my issues i think i made you think about a couple of things to improve.. expecially in Orchestra with that dict read problem
<heyho> I found another guy had my same exact error reading a previous irc log
<SpamapS> yeah I believe the fix for that is pending
<fwereade> SpamapS, heyho: I'll be on hat one just as soon as I can, I think it's a pretty serious problem
<fwereade> heyho, thanks for the extra information :)
<heyho> No problem! And if you have other questions that could be useful to you, shout
<heyho> As you surely have noticed, I'm  pretty a beginner in the cloud computing world.. Do you think it would be better if I start trying to configure and use Openstack the hard way, or If I use orchestra to make, maybe, things go smoother?
<SpamapS> heyho: orchestra is, I would say, the most complex target for juju.
<SpamapS> heyho: local is second, and then ec2 is the simplest.
<heyho> I also tried ec2 and juju bootstrap worked like a charm actually :D ... but I had issues in the juju status step.. But it's a big story that I maybe be explaining another time mainly because it's 17:52 pm here and I'm about to go home :D
<koolhead11> heyho: was that ssh error during status
<koolhead11> ?
<SpamapS> heyho: well thanks for sharing all your troubles with us. :)
<heyho> yeah ssh error problem
<heyho> and thank you for your help
<koolhead11> heyho: u need to generate a keypair :) and it will work
<koolhead11> cheers!!
<koolhead11> SpamapS: i was looking at owncloud, our repository still has owncloud1
<koolhead11> there newest release is owncloud2
<heyho> kollhead11, actually i generated it but had problems however.. I'll explain in details another time.. for now, cheers!
<koolhead11> cool
<SpamapS> Maintainer: Kubuntu Developers <kubuntu-devel@lists.ubuntu.com>
<SpamapS> Original-Maintainer: Jonathan Riddell <jriddell@ubuntu.com>
<SpamapS> koolhead11: yeah, maybe file a bug? ;)
<koolhead11> SpamapS: doing right away
<mchenetz> Finally have a fully functional openstack environmentâ¦ 2 servers with 6 cores eachâ¦ Seems to work pretty wellâ¦. Now for the development of virtualbox as a provider in Jujuâ¦ :-)
<SpamapS> mchenetz: how did you manage only 2 servers?
<mchenetz> SPamaps: That is the minimumâ¦ You can run everything but compute on one node and then compute on the other
<SpamapS> mchenetz: so did you do that manually, or figure out some way to trick juju into installing more than one thing onto one box? ;)
<mchenetz> I used stackps.org distro (Ubuntu 10 derivative) to installâ¦ Super easyâ¦ It was great to learn onâ¦
<mchenetz> stackops.org
<mchenetz> used 2 nicsâ¦ One for the service network and the other for public
<mchenetz> now i am just setting up the Juju environment for EC2 compatibility and see if i can deploy to it...
<koolhead11> jelmer: i think you helped me with the bzr thing
<jelmer> hi koolhead11
<lynxman> hazmat: ping
<koolhead11> jelmer: i will trouble you again in sometime. :)
<SpamapS> lynxman: hey, you expired from charmers. I assume you'd like to stay in it right? (new memberships are getting much longer periods than we initially gave people.. not sure why we did that. ;)
<lynxman> SpamapS: yeah would love to stay in :)
<lynxman> SpamapS: if that's okay, of course!
<SpamapS> lynxman: yeah, you've been quite active. :)
<lynxman> SpamapS: trying to, right now doing some juju client hackery that will make hazmat shriek ;)
 * SpamapS makes sure everybody expires "never" :)
<lynxman> SpamapS: lovely, thanks man :)
<SpamapS> I figure we can start expiring people when we get to 20 charmers. :)
<SpamapS> medberry: aplogies to you, the one guy I did let expire. ;)
 * koolhead11 listens
 * koolhead11 rushes 4 home
<koolhead11> laters
<medberry> SpamapS, nope, I pulled myself off the list. You didn't let me expire. :^)
 * medberry still had a day left at that point
<hazmat> lynxman, pong
<lynxman> hazmat: trying to do something a bit crazy, even if I know this will fail, would just like to try the concepr :)
<lynxman> hazmat: I'm writing an stunnel client charm, I'd like to deploy that using juju client then once its deployed connect to the zookeper node through the stunnel
<lynxman> hazmat: how do you see that? :D
<hazmat> lynxman, sounds interesting, the client is going over ssh now, but a generic stunnel charm would be interesting, its seems to me like its better targeted as a subordinate/plugin charm
<hazmat> since you'll need some local per charm state about the endpoint its setting up
<lynxman> hazmat: yeah, I think so, I'd like to try the basic concept for now and expand on that
<lynxman> hazmat: so my questions are, 1. how can I use juju client to deploy a charm without zookeper being present? 2. How do I tell the client where to find zookeper
<hazmat> 1) does not compute ;-) 2) its in the provider storage under a special named key 'provider-state'
<SpamapS> lynxman: is there a reason you are shunning SSH?
 * SpamapS shhhould shun sh words
<hazmat> re 1) it would have to be incorporated into juju's bootstrap
<lynxman> SpamapS: the idea is to be able to setup a machine in a remote location, then use stunnel to connect back to zookeper to tell it "I'm here and available"
 * hazmat grabs some lunch
<SpamapS> lynxman: ahh, you want what I was thinking.. a "just run the agent somewhere" provider
<lynxman> SpamapS: exactly! we talked with sabdfl also about it last week, be able to just run a charm in "standalone"
<lynxman> hazmat: enjoy :)
<SpamapS> lynxman: I think with orchestra you could cheat and do this by defining a machine in orchestra, and then running the late command manually.
<lynxman> SpamapS: hmm how so?
<SpamapS> lynxman: just put it in orchestra... tell juju to claim it, and then run the "late command" that gets shoved into ksmeta
<SpamapS> lynxman: you still need zookeeper though
<lynxman> SpamapS: hmm thats the thing, I really don't fancy having a local zookeeper, that's plan B
<SpamapS> Thats far too ingrained into juju to mock out. :)
<SpamapS> lynxman: I'm 99% sure that its just not going to work without ZK
<lynxman> SpamapS: so maybe I can mock up something through cloud-init, of the sorts "install this stuff, then run the command to join zookeeper"
<SpamapS> lynxman: you can certainly run ZK wherever you want and just point the client at it.
<lynxman> SpamapS: that'd be a good concept imho :)
<SpamapS> as hazmat said.. just change the data stored in the provider state bits.
<lynxman> SpamapS: cool, will investigate into that then ^^
<lynxman> SpamapS: hazmat: thanks for the feedback guys :)
<SpamapS> lynxman: very interested in this, as it would be nice for the scaled-down services.
<lynxman> SpamapS: that's the direction I'm taking indeed :)
<lynxman> SpamapS: I'm keeping this under wraps for now, but #siteam will show something awesome in the next month if all goes right
<SpamapS> lynxman: w00t
<_mup_> juju/ssh-known_hosts r442 committed by jim.baker@canonical.com
<_mup_> End-to-end
<koolhead17> jelmer: hi again
<jelmer> hi
<_mup_> juju/ssh-known_hosts r443 committed by jim.baker@canonical.com
<_mup_> Merged trunk
<koolhead17> jelmer: i modified a file and before that i did  "bzr lp-login" and then bzr commit -m "added revision number in revision file"
<koolhead17> i got message Committing to: /home/atul/bazaar/boa/trunk/
<koolhead17> modified revision
<koolhead17> Committed revision 2.
<koolhead17> so does that mean this committed file is still in my local system? i need to push it again
<koolhead17> ooh it was bzr push :D
<koolhead17> got it.
<jelmer> koolhead17: yes, commit only does the change locally - you have to push to get it onto launchpad
<jelmer> koolhead17: you can make "bzr commit" automatically propogate the change to launchpad by "binding" your local branch to the one on Launchpad
<jelmer> koolhead17: see "bzr bind"
<koolhead17> jelmer: cool . let me check
<koolhead17> SpamapS: ariund?
<koolhead17> *Around
<SpamapS> koolhead17: sort of :) whats up?
<koolhead17> SpamapS: could you tell me that command for modifying the juju documentation, i want to remove "revision" part from yaml file, as user will get deprecated warning thing.
<SpamapS> koolhead17: recently the docs were split out of the trunk..
<SpamapS> hazmat: are the online docs built from lp:juju/docs ?
<hazmat> SpamapS, no.. thats the last item till i can close that ticket out and announce
<SpamapS> hazmat: still not sure of why we can't just pair the docs with the trunk. ;)
<SpamapS> but I'd rather just see it move forward so koolhead17 and others can start updating them
<hazmat> SpamapS, exactly
<hazmat> SpamapS, if it doesn't work out in by precise release, we change it back to the old model
<SpamapS> I think I do see one benefit
<SpamapS> which is that it will have its own review queue
<robbiew> SpamapS: hey, so would you (or hazmat) know anyone who could port our juju client to OSX?
<SpamapS> hazmat: my prediction is that it will eventually be split into lp:juju/docs-precise lp:juju/docs-q
<robbiew> or anyone else in this channel :D
<EvilBill> robbiew: I don't know of anyone, but I second the request.
<SpamapS> robbiew: I have 3 macs here (all running ubuntu.. but.. I can reboot ;).. I can probably figure it out. ;)
<hazmat> it should just work, just a question of getting it installed
<hazmat> python-zookeeper being the only non-trivial dep
<SpamapS> hazmat: somebody recently found a dependency on python-apt that broke for obvious reasons on osx ;)
<robbiew> lol
<hazmat> SpamapS, they where using the local provider i thought
<SpamapS> oh well thats just not gonna work ;)
<hazmat> SpamapS, the local provider clearly won't work on osx, and the code is not imported otherwise
<SpamapS> yeah I think it should "just work" but we need to pick a single thing, macports or homebrew, and get it working
 * hazmat looks for the wires to plug his mac
<SpamapS> Probably need to focus on Lion
<SpamapS> actually I can run Lion in a VM on either of my macs
<SpamapS> so I don't even have to reboot
<SpamapS> robbiew: sounds like something that needs a bug. :)
<robbiew> btw...I wasn't suggesting either one of you add this effort to your plate ;)
<SpamapS> robbiew: seems like users who are on OS X will pick it up if we can help them out.
<shazzner_> hello everyone
<SpamapS> from what I see, the macports that lynxman submitted have been ignored
<hazmat> i guess bug 826498 sort of assumes the client works, but nothing explicit
<_mup_> Bug #826498: virtualbox machine provider for osx local dev <juju:New> < https://launchpad.net/bugs/826498 >
<SpamapS> so maybe need to go with brew
<hazmat> +1
<SpamapS> another (evil) way to go is a direct installer
<hazmat> and they already have python-zookeeper (in their zookeeper dist)
<hazmat> after that its just pure python libs
<SpamapS> hazmat: oh then maybe setup.py will work after brew installing that?
<hazmat> hmm..
<SpamapS> we could at least have a juju.ubuntu.com/OSX page then
<mchenetz> I am working on a virtualbox provider and brew repo for juju
<shazzner_> I tried last night but everyone was asleep, I'm working on a charm for gitolite: http://sitaramc.github.com/gitolite/
<hazmat> SpamapS, it won't we don't have deps marked explicitly
<SpamapS> mchenetz: RIGHT and you are also working on being *our hero*
<SpamapS> ;)
<mchenetz> hehe
<hazmat> :-)
<robbiew> welcome back shazzner_
<shazzner_> I figured out one issue but still have one question
<shazzner_> hello :)
<shazzner_> so part of installing gitolite requires a copy of your public key
<hazmat> SpamapS, easy to fix that though, so it is easy_installable
 * SpamapS must feed himself, but is interested to help upon return.
<shazzner_> and I'm not sure how to do this with the juju script
<shazzner_> I know juju  requires a key, but I'm not sure how to send this
<shazzner_> or possibly to copy it from authorized keys on the server
<shazzner_> just trying to figure out the best way to do this
<_mup_> Bug #905467 was filed: Allow juju to be easy_installed <juju:New> < https://launchpad.net/bugs/905467 >
<hazmat> shazzner_, juju will use a public key it finds by default from the user's ~/.ssh dir
<hazmat> shazzner_, a separate one can be specified
<hazmat> oh..
<hazmat> econtext
<hazmat> shazzner_, you could have it as a config setting of the gitolite service
<hazmat> but i would assume it would have a better method if its multi-user
<shazzner_> ah ok, that's what I was thinking
<shazzner_> yeah
<shazzner_> I wasn't sure to add a config setting for something that's only used once, but if several hosts are setup it makes sense
<shazzner_> it's enough to get this newbie on track, thanks hazmat
<robbiew> mchenetz: you get juju working on mac...and you'll get first dibs on juju shirts and sponsored invite to the next UDS ;)
<hazmat> SpamapS, the disk image install sounds pretty intriguing
<mchenetz> Robbiew: It's a deal... I will work on it. I don't think the brew repo willtake a lot, but it wont support local provider. So, i was planning on getting a virtualbox provider working first
<robbiew> fantastic ;)
<shazzner_> juju on mac would be nice :)
<hazmat> mchenetz, i'd go with the brew stuff first, that at leasts gets it out into people's hands.. but whatever works
<mchenetz> I have it working with a combo of port packages from lynxman, brew, and pip. It is currently running on my macbook
<mchenetz> I can do the brew stuff first
<shazzner_> I suppose it's better to use the official package in the repository than to clone it from git
<EvilBill> I'm happy to try and help with the juju on OS X effort.
<EvilBill> I can't run with it myself, but I can certainly help and test and such.
<mchenetz> EvilBill: Thanksâ¦ I think i will have a brew repo up very shortly
<EvilBill> mchenetz: awesome :)
<EvilBill> that won't conflict badly with macports, will it?
<EvilBill> (I have to run macports stuff for work)
<mchenetz> They don't recommend it, but i have both installed and they seem to work okay so far
<mchenetz> Brew has a lot of the same stuff as port
<mchenetz> I actually got the port version working with some help from pip too
<mchenetz> I needed to use pip to install tx-zookeeper
<EvilBill> yeah, tx-zookeeper was blowing up for me when I tried.
<mchenetz> yupâ¦ I think some dependencies changed since it was submitted
<mchenetz> after that, everything else was good
<SpamapS> nijaba: around?
<robbiew> SpamapS: he's on holiday now
<SpamapS> ahh right
<koolhead17> SpamapS: owncloud uses sqlite mysql both
<koolhead17> do i have to write charm saperately 4 both
<SpamapS> koolhead17: no, you can just make the mysql requirement optional
<SpamapS> requires:
<koolhead17> SpamapS: cool
<SpamapS>   db:
<koolhead17> k
<SpamapS>     interface: mysql
<SpamapS>     optional: true
<koolhead17> ok
<SpamapS> koolhead17: you do need to think *hard* about how to migrate the data from the local sqlite to the mysql database.. or warn the user that by relating to mysql, they will lose all their data in the sqlite db.
<koolhead17> SpamapS: yes. actually am testing by basic install script/bash to do all the needful and which does not use mysql.
<koolhead17> SpamapS: also how does this database schema gets created? any easy charm you will suggest me to look at to understand it well
<SpamapS> koolhead17: it different always. Just turn the install instructions into scripts.
<koolhead17> SpamapS: let me check from our available charms as how its been done
<mchenetz> Here are some quick instructions for installing juju on OSX before i get the Brew Repo working: https://idserver.inventivedigital.com/wiki/people/82L0T5Y7X/blog
<hazmat> mchenetz, umm.. zkpython?
<mchenetz> zookeeper python bindings
<hazmat> mchenetz, there in the brew zookeeper pkg
<mchenetz> ??
<mchenetz> hazmat: The python zookeeper didn't seem to work without that
<hazmat> mchenetz, hmm.. https://github.com/mxcl/homebrew/blob/master/Library/Formula/zookeeper.rb#L66
<mchenetz> i know its thereâ¦ It's part of my install, but it didn't seem to work until i used the pip install zypython command
<hazmat> mchenetz, the zkpython on pypi does look like it will compile with brew correctly, but its a little suspect on versioning, zkpython is distributed with zk
<mchenetz> it seems to work. :-)
<mchenetz> If you find that it works without it. I would be more than happy to change the instructions
<mchenetz> I am now working on the brew packaging
<mchenetz> This was just a quick way to get poodle to checkout juju
<mchenetz> people, not poodleâ¦ Damn word replaceâ¦ :-(
<hazmat> mchenetz, fair enough.. i'm just concerned because older version of zkpython have known bugs that can cause problems, but i guess the client doesn't exercise the lib to the same degree that the server side does
<hazmat> the bugs tend to segfault or exception, so its fairly obvious when its a problem
<mchenetz> i am still testingâ¦ I will fix the instructions if i find bugs. But, again, my main intention is to build the brew repo now
<hazmat> mchenetz, i think you need to specify the option when installing zookeeper via brew to get the python bindings
<mchenetz> let me check it out.. I forgot about this options
<mchenetz> those
<hazmat> amusing copyright on apple javascript.. http://pastebin.ubuntu.com/772706/
<hazmat> er. license.. by visiting the page on non osx, you violate the license
<robbiew> nice :/
<mchenetz> heheâ¦ I remove zkpython and I tried the brew install zookeeper --python and it installed everything, but it did not like it when i ran juju
<mchenetz> I think i ill keep it for now as it seems to be running good
<mchenetz> I will worry about it when i create the formula for brew
<koolhead17> SpamapS: would you like to test owncloud charm? half-baked though :P
#juju 2011-12-17
<SpamapS> koolhead17: why is it "half baked" ?
<koolhead17> SpamapS: because i dont have juju in my current setup and the charm i have written as of now uses only sqlite and i have few more TODO left :)
<SpamapS> koolhead17: and local doesn't work?
<SpamapS> oh
<SpamapS> you don't even have juju? huh?
<koolhead17> SpamapS: am too lazy to move to oneiric
<SpamapS> koolhead17: VM
<koolhead17> SpamapS:  i have virtualbox and system has only 2GB RAM.
<SpamapS> koolhead17: you only need about 500MB of RAM to run one thing.
<koolhead17> SpamapS: so i should try juju on one of the oneiric instance running on virtualbox?
<SpamapS> well its worth trying
<SpamapS> honestly though.. 2GB .. you need more RAM ;)
<SpamapS> or more machines. :)
<koolhead17> SpamapS: i dont want to take risk. i will upgrade my lappy soon. :)
<SpamapS> Cool. Good luck with that. :) Ok, time for the weekend
<koolhead17> SpamapS: cheers!! :)
<_mup_> juju/ssh-known_hosts r444 committed by jim.baker@canonical.com
<_mup_> Clean up of bootstrap
<hazmat> new version of charm browser out into the world
<_mup_> juju/ssh-known_hosts r445 committed by jim.baker@canonical.com
<_mup_> sshforward needs to use per env known_hosts
<nijaba> SpamapS: thanks for merging my stuff.  Just proposed for merging a new version which implements "ch_peer_scp" & "ch_peer_rsync"
<_mup_> Bug #905674 was filed: --config is not part of juju deploy autocomplete <juju:New> < https://launchpad.net/bugs/905674 >
<mchenetz> Creating Brew packageâ¦ :-)
<m_3> jcastro: https://idserver.inventivedigital.com/wiki/people/82L0T5Y7X/blog
<mchenetz> yes?
<mchenetz> rebooting currently
<mchenetz> damn osx serverâ¦ arggg
<mchenetz> It's so buggy
<mchenetz> last phase of troubleshooting the juju.rb on brewâ¦ I am hoping to provide a test brew repo today. :-)
<nijaba> SpamapS: around?
<mchenetz> Please try out the Brew repo on this page and tell me if it works: https://idserver.inventivedigital.com/wiki/people/82L0T5Y7X/blog
<mchenetz> I am thinking that i am going to make a pure easy_install config, because it would be a lot easier for OSX users to install and it doesn't require xcode
<mchenetz> Please comment at the blog link if i am not online
<mchenetz> btw, you can do a single line install with easy_install by doing this:
<mchenetz> easy_install argparse txaws pyyaml txzookeeper zkpython pydot https://launchpad.net/ubuntu/+archive/primary/+files/juju_0.5%2Bbzr398.orig.tar.gz
<mchenetz> The only requirement is you need Xcode installed
<mchenetz> Lastly, you could put your dependencies in the setup.py and you could run the, "python setup.py easy_install" and it should install all dependencies
<mchenetz> okay, going to the mall to shop for gifts nowâ¦ Be back later
<SpamapS> nijaba: I'm here now, but I'm guessing you aren't. ;)
<SpamapS> mchenetz: +1 for not requiring Xcode
<shazzner_> hello
<SpamapS> shazzner_: how's gitolite going?
<shazzner_> hey
<shazzner_> I finished the script
<shazzner_> but for some reason I can't connect to my ec2 instance
<shazzner_> I think I did too many bootstraps and destroy-environment
<shazzner_> :(
<shazzner_> any ideas?
<koolhead17> hi SpamapS
<koolhead17> shazzner_: i dont think doing to much will have any effect :p
<shazzner_> welp, I can do juju bootstrap, then juju status and it just hangs while trying to connect
<shazzner_> I left it on trying to connect overnight and it gave me a python error saying something like too many open files
<shazzner_> no idea
<koolhead17> ok
<koolhead17> so juju -v bootstrap
<koolhead17> tell me what u get
<shazzner_> ok one sec
<shazzner_> looks like it completed fine
<shazzner_> juju -v status?
<shazzner_> I'm getting a bunch of of 'server refused to accept client'
<shazzner_> looks like it's shifting through a bunch of ports
<shazzner_> I'll try it again in 5 mins
<shazzner_> yeah this is what I keep getting: ZOO_ERROR@handle_socket_error_msg@1603: Socket [127.0.0.1:48091] zk retcode=-4, errno=112(Host is down)
<koolhead17> shazzner_: pastebin juju -v status
<koolhead17> and are you using in on AWS?
<shazzner_> koolhead17: yep, one sec
<shazzner_> http://pastebin.com/94CwaPs6
<koolhead17> shazzner_: would you mind pasting your juj config yaml file
<koolhead17> ?
<shazzner1> hey
<shazzner1> sorry something crashed my system
<koolhead17> shazzner1: ooh
<koolhead17> shazzner1: are yo using oneiric currently
<shazzner1> yep
<koolhead17> on your local system
<koolhead17> shazzner1: 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 >
<koolhead17> try this one, its been tested :P
<koolhead17> its 5 am for me i really need 2 sleep now :)
<koolhead17> good luck
<shazzner1> ok no problem man, thanks for your help :)
<koolhead17|zzZZ> welcome
#juju 2011-12-18
<shazzner1> http://askubuntu.com/questions/88576/why-am-i-unable-to-connect-to-my-ec2-instance-with-juju
<mchenetz> back, any one try my repo yet...
<nijaba> SpamapS: what about now?
<nijaba> Maybe someone else will have an idea.  My current test script for ch_peer_copy requires to be executed as root so that I can start a second sshd server.  Anyone knows how to run a sshd server without being root (not only starting, but able to do authentications)?  Or is it possible to have sudo in dh_auto_test?
<shazzner_> ok
<shazzner_> just a heads up, I fixed my connection problem by regenerating my environments.yaml file
<shazzner_> does juju-log give everyone errors?
<shazzner_> hello
<shazzner_> anyone up? :)
<SpamapS> nijaba: I think we're just on different time schedules. :)
<SpamapS> shazzner_: I am, not sure how long I can stay though. :)
<shazzner_> hey SpamapS
<shazzner_> so I fixed my connection problem, and tested my gitolite script
<shazzner_> however
<shazzner_> dispite everything I can't see to use git from it
<shazzner_> *seem
<shazzner_> essentially you run a gitolite script and pass it your public key
<SpamapS> shazzner_: does it work over ssh or http/https ?
<shazzner_> hmm, now that you mention it I odn't think I've tried https
<SpamapS> shazzner_: actually, do you have the charm somewhere I can take a look?
<shazzner_> sure one sec
 * SpamapS suggests bzr push lp:~your-username/charm/oneiric/gitolite/trunk ;)
<shazzner_> ah let me try that, never used bzr before
<shazzner_> here's it in a zip for starters: http://ubuntuone.com/2VWmIN7m7ZMgLVb8gvVqBN
<shazzner_> now, if you look at the install script I commented out the public key copy
<SpamapS> shazzner_: if you'd like to share the gitolite charm with other people you'll need to use bzr to propose it for the charm store.
<SpamapS> shazzner_: https://juju.ubuntu.com/Charms
<shazzner_> yep, I plan on it let me see if I can't push it out
<SpamapS> shazzner_: reading your zip
<SpamapS> shazzner_: so, your config.yaml is never actually used in the charm
<SpamapS> shazzner_: you need a config-changed hook
<shazzner_> right, it's only used for the install
<SpamapS> which will be a problem because then you can't use 'juju set' to change the values
<SpamapS> and in the version you sent me, everything is commented out
<shazzner_> and I commented it out, but if you want to the full experience you would need to comment in all the lines
<shazzner_> and add your name and pub key to the config
<shazzner_> yeah, I need to add a config-change script
<shazzner_> in case you want to create another instance with a differnt admin I suppose
<SpamapS> shazzner_: what if you want to retire the key?
<shazzner_> I think you can do that within gitolite, but yeah there are plenty of uses cases for changing the key
<shazzner_> regardless, I still can't connect to it for some reason it might be an issue with gitolite and permissions maybe
<shazzner_> like running gl-setup shazzner.pub, then trying to git clone shazzner@<serverip>:gitolite-admin
<shazzner_> gives me a 'premission denied (pubkey)' everytime
<shazzner_> even though my key is in the .ssh/authorizedkeys and gitolite adds its crazy key
<SpamapS> shazzner_: is gl-setup meant to be run as the connecting user, not as root ?
<SpamapS> shazzner_: I don't see where you even created a user
<shazzner_> well, that's a question I'm not sure of and the gitolite documentation isn't exactly clear
<SpamapS> looks like you need to create users
<shazzner_> I've done this before, where adding a user with a differnt name works as long as the key is the same
<SpamapS> but what user have you added?
<shazzner_> *adding it to gitolite I mean
<shazzner_> when you run gl-setup user.pub it adds it its git repository
<shazzner_> and when you connect it checks that
<SpamapS> when you're connecting, with git via ssh, you are using the username shazzner
<SpamapS> when the charm runs, it runs as root
<shazzner_> right
<SpamapS> so when did you 'adduser shazzner' ?
<SpamapS> and after that, you'd need to copy the gl-setup key to shazzner's user
<shazzner_> ok
<SpamapS> actually
<SpamapS> ok reading the quick install
<SpamapS> it specifically says to create a user called 'git'
<SpamapS> and run gl-setup as that user
<SpamapS> and gl-system-install
<shazzner_> I think gl-setup runs the next script gl-system-install
<SpamapS> shazzner_: http://sitaramc.github.com/gitolite/index.html#qi
<SpamapS> shazzner_: that documentation is pretty clear
<shazzner_> huh weird
<SpamapS> http://sitaramc.github.com/gitolite/install.html
<SpamapS> that one is pretty clear too
<shazzner_> I'd had always skipped the git creation part
<shazzner_> with no issues
<SpamapS> even tells you the difference between a git clone of gitolite and using the debs
<shazzner_> ok well let me work off that
<SpamapS> shazzner_: automation often has to work differently than "the way you always did it" because you can't assume persmissions or users.
<shazzner_> very true
<SpamapS> shazzner_: its something we're trying to solve w/ juju by making the charms so simple
<shazzner_> ok, let me work on this. Thanks for helping this idiot :)
<SpamapS> shazzner_: from one idiot to another, its my pleasure. ;)
 * SpamapS has just been an idiot longer, thats all.
<SpamapS> Ok, time to go tire my 2 year old out for nap time
<SpamapS> shazzner_: good luck!
<shazzner_> thanks! :)
<jelmer> hah, wrote my first charm. That was easy :)
<koolhead17> jelmer: cool
<koolhead17> :P
<nijaba> SpamapS: yep...  specially when I am off :P  anyway, if you've got time to take a look at my questionning for https://code.launchpad.net/~nijaba/charm-tools/peer-scp/+merge/86136 I would appreciate your input. A bit locked at the moment
<_mup_> Bug #906008 was filed: way to set default charm repository <juju:New> < https://launchpad.net/bugs/906008 >
<nijaba> SpamapS: bug #906030 needs your help :)
<_mup_> Bug #906030: [regression] unbound variable CH_DOWNLOAD_DIR <Juju Charm Tools:Fix Committed by clint-fewbar> < https://launchpad.net/bugs/906030 >
#juju 2013-12-09
<teleyinex> hi there
<teleyinex> I'm trying to learn juju and to connect it to my rackspace cloud
<teleyinex> I'm generating the environments.yaml
<teleyinex> and I think I've everything fine, but I'm getting this error:
<teleyinex> ERROR required environment variable not set for credentials attribute: Secrets
<teleyinex> the Secrets variable is not even in the environments.yaml file
<teleyinex> so I don't know how to fix it
<teleyinex> any idea why is asking for that variable=
<teleyinex> any idea why is asking for that variable?
<aquarius> I'm told by jcastro that I can set a backup dir with the postgres charm using some of the backup variables at https://jujucharms.com/fullscreen/search/precise/postgresql-52/?text=postgresql#bws-configuration. How do I set them?
<ashipika> ERROR juju.state.open.go:92 TLS handshake failed: x509 certificate has expired or is not yet valid
<ashipika> any clues where to start looking?
<ashipika> anybody?
<mgz> ashipika: are you using a self signed cert?
<ashipika> this is what i get when i run juju bootstrap..
<mgz> sure, but against *what*
<ashipika> but i see now that it might be a "user" problem.. since it appears that juju bootstrap was ran as another user
<mgz> juju has multiple providers, and we know that say, ec2, has a valid cert
<ashipika> null environemnt
<ashipika> environment
<mgz> ashipika: and can you say, curl something from bootstrap-host without it complaining about the cert?
<ashipika> curl to boostrap-host from another host?
<mgz> ashipika: or ssh, probably more appropriate
<mgz> check the host you're actually conecting to at any rate
<marcoceppi> aquarius: It'll automatically backup to /var/lib/postgresql/backups, but you can `juju set postgresql backup_dir=/path/` to change configuration
<aquarius> marcoceppi, oh, that's already happening? sweet!
<aquarius> so I don't need to change anything
<marcoceppi> aquarius: nope! Charms should always do the right thing(tm) by default
<aquarius> that's excellent.
<marcoceppi> aquarius: in this case it'll have the last 5 days of backups in that directory
<aquarius> I should probably have a separate thing to send the backups elsewhere, mind :)
<marcoceppi> aquarius: a great case for a suborindate charm
<aquarius> not sure that's a charm; it's a one-liner in my crontab ;)
<marcoceppi> aquarius: sure, I was just trying to slyly convince you to write a subordinate charm for backups ;)
<aquarius> yeah, that's not happening ;)
<aquarius> I barely understand how to do it myself
<aquarius> trying to write a thing which keeps every sysadmin in the world happy is nowhere near my priority list :P
<marcoceppi> eh, worth a shot
<aquarius> :)
<X-warrior> How does a subordinate charm works? I have an logstash-agent charm, then I deployed it... later I add a relation logstash-agent service2, now logstash is subordinated to service2. If I add a relation to logstash-agent (let's say redis). Will it update de service2 logstash-agent?
<marcoceppi> X-warrior: yes, it will
<X-warrior> marcoceppi: ty still trying to get this logstash to work
<X-warrior> :D
<X-warrior> btw, why when I use upgrade-charm I get an "already running latest charm", but I just updated one of the files...
<X-warrior> oh forgot, just found my error
<sinzui> bac, gary_poster staging.jujucharms.com is sending connection refused messages about mongo. I am going to investigate
<bac> thanks sinzui.  let me know if i can help
<gary_poster> ty sinzui
<sinzui> bac, gary_poster mongodb filled the disk with logs. I deleted some and restarted mongo. I see staging is happy
<bac> yay
<bac> sinzui: can we turn down the log level?  logrotate?
<sinzui> bac, I think we need to update the charm to handle rotation. Te log-level also seem to be permanently on spew
<bac> sinzui: ok, i'll make a card for us
<mxc> good morning
<mxc> getting this error on Azure when bootstrapping:
<mxc> 2013-12-07 04:23:00 ERROR juju supercommand.go:282 POST request failed: BadRequest - The affinity group name is empty or was not specified. (http code 400: Bad Request)
<mxc> juju bootstrap --show-log --upload-tools  6.01s user 5.05s system 12% cpu 1:28.15 total
<mxc> i'm running everything out of west us but trying to run the juju command from a non-azure machine.
<mxc> back
<sarnold> hey mxc, sorry, no responses while you were away
<mxc> sarnold: thanks for the heads up
<mxc> http://askubuntu.com/questions/388419/juju-bootstrap-fails-in-azure-badrequest-the-affinity-group-name-is-empty-or  <- would appreciate if anyone could take a look
<jcastro> mxc, natefinch is who you should keep an eye out, he's the azure guy afaict
<mxc> jcastro: thanks!
<arosales> mxc,  did you have the mail to the list on juju bootstrap failing?
<jcastro> http://askubuntu.com/questions/388419/juju-bootstrap-fails-in-azure-badrequest-the-affinity-group-name-is-empty-or
<arosales> mxc if you run "apt-get update && apt-get install juju-core" on your stand along machines does that give you 1.16.4?
<mxc> was that a bad use of the list?
<mxc> if so, apologies
<arosales> mxc, no it was a great use
<mxc> arosales: 1.16.4-saucy-amd64
<arosales> mxc, just wante to confirm mxc and the list  mail was the same subject
<mxc> oh, yeah, that was me
<arosales> cool, so an apt-get update gets you the latest juju
<arosales> mxc which reagion is your ubuntu stand alone instance?
<mxc> all west us
<arosales> mxc sounds like you are using an azure instance as the juju client (ie to issues juju deploys from)
<mxc> but also trying to get this working from a non-azure, plain old windows machine
<mxc> arosales: so, yes, that would be ok
<arosales> mxc, I was able to bootstrap from my ubuntu client outside of azure
<mxc> does the machine that I am running juju bootstrap from need to have certain ports open?
<arosales> I will see if I can reproduce your environment but bootstraping from within azure.
<mxc> i get this from inside and outside of azure
<mxc> is it possible to get even more debug output than just --show-log?
<arosales> --debug
<mxc> ty
<mxc> doesn't help much in this case
<mxc> ooh, a bit more
<mxc> }: mirror data for "com.ubuntu.juju:released:tools" not found
<arosales> mxc, can you pastebin your full --debug output?
<arosales> mxc, it should retry if a local mirror isn't found.
<arosales> mxc, hmm . . .  I don't know what port juju client
<mxc> http://pastebin.ubuntu.com/6548362/
<arosales> mxc, can you drop the --upload-tools
<mxc> sec
<arosales> mxc, it also looks like jujustorewestdocmunch may not be fully configured
<arosales> 2013-12-09 19:45:38 ERROR juju supercommand.go:282 cannot obtain storage account keys: GET request failed: ResourceNotFound - The storage account 'jujustorewestdocmunch' was not found. (http code 404: Not Found)
<mxc> oops, i accidentally copied way too much
<mxc> sorry
<arosales> ah I see you last attempt is at the bottom
<mxc> http://pastebin.ubuntu.com/6548391/
<mxc> sorry, here's the fixed on
<arosales> mxc, also be interesting to see what "juju bootstrap  --debug" returns
<mxc> same
<winael> Hi every one
<winael> utlemming: I just tried your tuto about quick start with Juju and I found a little "bug"
<utlemming> winael: k....
<arosales> winael, hello
<winael> hi arosales
<arosales> mxc, what metadata index does it read prior to the affinity error
<mxc> https://jujustorewestusdocmunch.blob.core.windows.net/juju-azure-private/tools%2Fstreams%2Fv1%2Findex.json?se=2023-12-09T23%3A25%3A35Z&sig=AYXhLWBbLAfaigM%2B%2BHq2OueWOCi7SU6o56l1JnOgejg%3D&sp=r&sr=b&sv=2012-02-12
<winael> utlemming: let's me explain, as i read your post, I undestand that it is a way to easly test Juju... but in the practice, ip forwarding doesn't work. So when you expose a service like Mediawiki, you can't access to it out of the vagrant box, unlike the Juju GUI
<utlemming> winael: that is correct....you need to follow the SSHuttle instructions
<winael> I think it could be a little confusing for people who want just give it a try but don't know linux very well and specially iptables rules
<arosales> mxc, can you paste bin this attempt (ie without --upload-tools).  I want to see if you are trying to hit "http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson"
<utlemming> winael: I wouldn't do IP tables. Just use SShuttle, which forwards everything for you.
<winael> Oh ok... that's not clear in fact. I think about none Ubuntu user, it a little bit confusing
<utlemming> winael: the big problem here is that every OS has some convoluted method of forwarding ports, and looking at it made my head nearly explode for Windows.
<winael> but the idea to use a vagrant image to easly deploy a Juju server I love it
<winael> yeah I can understand that. In fact, I think it will be more easly to just add a note into your post (if you want to test a charm you've just deployed, use sshuttle)
<winael> and make the sshuttle part non optional
<mxc> arosales: http://pastebin.com/AQArivJz
<mxc> ubuntu paste bin is super slow at the moment
<utlemming> winael: I'll take a look.
<utlemming> winael: thanks for the feedback
<winael> I said that because I talk about this at work, but if they tried and fail for that, they just think Juju doesn't work
<winael> And I imagine lot's of people can think the same
<winael> you're welcome :)
<mxc> is there a way to turn on HTTP request logging so that I can see every http request going out?
<utlemming> winael: updated, hopefully that helps
<winael> In fact this project inspire me. I am thinking about how I can try to bring Juju for my client which use VM on ESX, and I said to my self, wooooooooooh if I can have a QuickStart MaaS+Juju vagrant image as master, it'll fixe all my problems (it's just a fantasy, but...)
<arosales> mxc, taking a look
<arosales> mxc, thanks for the info
<mxc> ty
<mxc> oh, i've been using an ubuntu 13.10 machine to run juju from.  could that be part of the problem?
<jcastro> winael, the vagrant images are more for supporting local development, not so much for serving things in an environment
<jcastro> for your idea you're going to just use manual provisioning, which will be finished in january
<arosales> mxc, no running the juju client from 13.10 should be fine
<arosales> mxc I am still working on reproducing your error
<arosales> mxc I did confirm that if storage and instance were in different regions you would get a different error along the lines of
<arosales> The source image must reside in a storage account that has the same affinity group or location as the cloud service East US. (http code 400: Bad Request)
<winael> jcastro: I have to take a look on the Manuel Provisioning doc in deed
<arosales> and in those cases you should still hit cloud-images.ubuntu.com
<winael> I try very hard to push Ubuntu/Juju in my company but it's not easy
<winael> they prefere to try to re invent the wheel
#juju 2013-12-10
<arosales> winael, thanks for being a champion :-)
<arosales> keep posting your feedback here and to the list. It sounds like utlemming updated the docs too
<arosales> utlemming, was that the juju.u.c/docs ?
<utlemming> arosales: no, it was my blog post
<mxc> everything is in the same region
<arosales> mxc, looks like a post @ juju.provider.azure environ.go:406 picked tools is failing .  . . I am still investigating . . .
<arosales> mxc, ack and if it were different you would get a slightly different error
<arosales> utlemming, does it makes sense for the juju.u.c/docs?
<arosales> mxc and to confirm in your .juju/environments.yaml file you only have "admin-secret, management-subscription-id, management-certificate-path, and management-certificate-path " set
<mxc> yes
<mxc> i also have the and location set
<mxc> and storage-account-name
<arosales> ah yes my buffer missed the last ones
<mxc> are there any restrictions on the admin secret?
<mxc> and should that match anything?
<arosales> mxc, not that I know of.  You could set it or have "juju generate-config --show" make one for you
<winael> utlemming: I to the sshuttle thing but now to connect my service that Juju knows as 10.0.3.23 what can I do ?
<mxc> arosales: what version of ubuntu are you using?
<utlemming> winael: I don't follow the question....can you clarify?
<arosales> mxc, for the client or server?
<mxc> the machine that I run
<mxc> "juju bootstrap" on
<arosales> mxc, 13.04
<mxc> i've been trying 1310
<mxc> would 1204 or 1304 be a better option?
<winael> I use the sshuttle command as it's written on your post, and now, I just want to see my mediawiki in my browser
<arosales> you should be ok at 13.10
<arosales> in this case an API call to Azure is failing
<mxc> yes
<winael> As I understand I opened a ssh tunel for 10.0.3.0/24 network
<arosales> so your install looks ok, and you are at the latest
<mxc> is there anyway to get a stack trace of the error or having juju log every http request without recompiling
<utlemming> winael: are you using the browser?
<winael> my host machine browser yes
<utlemming> winael: if so, it should show you the IP address. To access it, just put the 10.0.3.xxx in your brower and it should should up
<arosales> mxc, without specifically inserting probe points in the code I am uncertain although we could ping the devs in #juju-core to confirm if there is an easy way
<winael> no just a chromium page saying that no data was received
<mxc> juju-core is empty
<winael> Well doesn't matter I'll take a look later. I have to sleep I have to get up in 4 hrs...
<arosales> winael, post to the list and we can try to get back there too
<arosales> mxc, sorry I didn't grok juju-core is empty
<winael> I'll try to do it tomorrow morning
<mxc> np
<arosales> mxc, were you trying to compile juju core?
<mxc> trying hard not to
<mxc> i gotta run
<mxc> thanks for your help
<mxc> the AU question is here: http://askubuntu.com/questions/388419/juju-bootstrap-fails-in-azure-badrequest-the-affinity-group-name-is-empty-or
<arosales> I'll catch you on the list mxc.
<arosales> I wasn't able to reproduce from a stand alone instance in Azure either for other folks following . . .
<arosales> perhaps it is cert issue . .
 * arosales will follow up later
<ashipika> hi all..
<ashipika> ERROR missing CA cert or auth-key
<ashipika> where should i start looking?
<ashipika> where should these two things be defined?
<Luca> ls -latr
<ashipika> @luca: where?
<Luca> ashipika: focus was in the wrong window :)
<ashipika> sorry :)
<Luca> np :)
<marcoceppi> ashipika: is this the machine you originally bootstrapped the environment with?
<ashipika> marcoceppi: no worries. i found the error.. mistakenly named null.jenv as null.yaml..  totally my mistake
<marcoceppi> ashipika: you shouldn't need to touch the .jenv files at all
<ashipika> well.. in my case..
<ashipika> ERROR: cannot put charm: ... x509: certificate has expired or is not yet valid.. does that imply that mongodb certificate on the bootstrapped host is not valid?
<X-warrior> What am I supposed to do when a service is being listed on juju status, but the machine that the service was, is destroyed? :S
<X-warrior> What am I supposed to do when a service is being listed on juju status, but the machine that the service was, is destroyed? :S
<X-warrior> marcoceppi:
<marcoceppi> X-warrior: juju destroy service?
<marcoceppi> X-warrior: was the machine removed outside of juju?
<X-warrior> marcoceppi: nope
<X-warrior> I used, destroy-service and then it showed up as "    life: dying"... I wait for a while... and nothing changes... then I used juju destroy-machine ... and the machine was destroyed... but the service is still showing as  "life: dying "
<X-warrior> :S
<marcoceppi> X-warrior: what version?
<marcoceppi> Someone had a similar issue
<X-warrior> marcoceppi: 1.16.3
<marcoceppi> X-warrior: 1.16.4 was released, but I don't think it addresses this issue.
<X-warrior> uhmm
<X-warrior> is it possible to deploy a charm with another name?
<marcoceppi> X-warrior: yes
<X-warrior> I mean I'm receiving "2013-12-10 16:49:51 ERROR juju supercommand.go:282 cannot add service "logstash-indexer": service already exists"
<marcoceppi> juju deploy <charm> <alias>
<marcoceppi> X-warrior: can you pastebin your entire juju status?
<marcoceppi> I might know what's going on
<X-warrior> marcoceppi: http://pastebin.com/g74FKzdK
<marcoceppi> X-warrior: can you `juju remove-relation logstash-indexer elasticsearch`
<X-warrior> I will try again, but I already tried that
<marcoceppi> oh :\
<X-warrior> marcoceppi: same result : (
<X-warrior> btw, using juju deploy --repository=charms/ --constraints="mem=1G cpu-power=1 arch=amd64" local:precise/logstash-indexer ALIAS gives me error: invalid service name "ALIAS"
<marcoceppi> X-warrior: don't use all caps?
<X-warrior> oh it can't have - or numbers on it I guess
<X-warrior> I updated the name and it worked
<X-warrior> x)
<X-warrior> what is the folder on machine that has the charm files?
<X-warrior> found it ty
<X-warrior> ;D
<webbrandon> Is this critical?  I am running "juju set amazon" and getting :ERROR Get : 301 response missing Location header.
<webbrandon> oh yeah its critical
<webbrandon> cant bootstrap
<webbrandon> what in the heck did I do?? I didn't touch anything to the configuration!!! garr.. breathe.... now fix....
<jcastro> http://askubuntu.com/questions/369231/juju-mysql-adding-units-vs-adding-new-service-with-relation
<jcastro> I have a bounty on this question if someone wants 200 points!
<webbrandon> im getting a bug issue that appeared a year ago https://bugs.launchpad.net/juju-core/+bug/1083017
<_mup_> Bug #1083017: Cannot bootstrap with public-tools in non us-east-1 region <ec2> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1083017>
<webbrandon> I am getting when trying to read the environments.yaml file it seems
<jcastro> marcoceppi, hey so what was the tldr on that IS rewrite of the squid charm?
<mgz> webbrandon: can you get the actual response body, so we see the url that's failing and why?
<webbrandon> mgz: http://paste.ubuntu.com/6552412/
<mgz> webbrandon: yeah, you need a better tool, as our logging there seems to suck
<mgz> wireshark maybe?
<webbrandon> mgz: okay, I installed it.  Not familiar with this,  I assume I link a particular item up to the pipe?
<mgz> webbrandon: you should just be able to capture the interface, if there's not too much else going on, then rerun `juju set`
<marcoceppi> jcastro: no idea?
<jcastro> well it was in review last week
<jcastro> that's the one that was essential a rewrite iirc?
<marcoceppi> jcastro: let me check
<marcoceppi> I can only keep track of so many charms ;)
<jcastro> yeah
<jcastro> this one is just weird because if they're using the one not in store in production then we need to either merge their work, or drop ours and promote theirs
<jcastro> but having 2 is not good
<webbrandon> mgz: looks like I can't will keep looking into using it but maybe there is a bigger issue
<marcoceppi> jcastro: was it squid?
<marcoceppi> I don't see any merges for it recently
<jcastro> squid reverse proxy
<mgz> webbrandon: did you elevate?
<webbrandon> mgz:  Doc said it was supposed to be ran as root if installed though package manager but it wasnt.  started as root user. CAn now see interfaces
<mgz> webbrandon: or see /usr/share/doc/wireshark-common/README.Debian it seems
<mgz> but root is fine(ish) for a one-off
<marcoceppi> jcastro: I guess it was merged, the last merge was sidnei's branch in early November, the other two pending are < 20 lines of code
<jcastro> yeah but you would have remembered merging it wouldn't you have?
<jcastro> it was like 6000 lines
<sidnei> jcastro: what's the question?
<jcastro> so the IS guys are apparently using a forked version of the squid reverseproxy charm
<jcastro> and they had a MP a long long time ago that was essentially a rewrite
<jcastro> but I don't think it ever got merged
<jcastro> it looks like the main feature they want is SSL
<sidnei> jcastro: i think it's merged yes, i pushed most of it.
<jcastro> kirkland, ok so I think the issue here is probably why they can't get SSL working
<sidnei> jcastro: pushed the latest from webops into https://code.launchpad.net/~sidnei/charms/precise/squid-reverseproxy/trunk/+merge/198451
<sidnei> it's only a few small changes
<jcastro> k
<jcastro> sidnei, ok so we're not out of sync, they might just be running an older version of the charm?
<sidnei> jcastro: they being? sorry im missing some context.
<jcastro> I'll send you an email
<sidnei> k
<webbrandon> mgz: Is this what you were looking for http://paste.ubuntu.com/6552655/ ?  That is the result of running "juju set amazon"
<webbrandon> paste bin is acting funny right now.  you need to give it a moment or it will look like there are 8k of blank lines
<mgz> webbrandon: urgh, I'm silly, https means this approach isn't enough. will have to add better logging to a juju binary for you
<webbrandon> mgz: not sure I follow.  What are the https issues I have?
<mgz> I can't see the response that gives the error, because of course it's encrypted :)
<webbrandon> ahhh.  I see
<webbrandon> this all happened after I started and stoped a bootstrap.  Did nothing to the setup or system between bootstrap events
<webbrandon> why can't scratching my head fix it
<mgz> it may well be a weird config thing
<webbrandon> I can I make sure all of juju is removed and try a reinstall?  I tried this once but something muct be left behind
<webbrandon> how can I make sure
<webbrandon> ?
<mgz> webbrandon: I doubt it's juju itself
<webbrandon> rebooting
<mgz> you may want to try moving your ~/.juju dir out of the way and recreating your configuration though
<webbrandon> I changed nothing though between a working bootstrap.
<webbrandon> mgz: tried that already
<mgz> it could also be not your end
<webbrandon> I doubt my rsa need to be reset but gona try a full reinstall and new rsa
<mxc> quick question, if I want to deploy a charm from a local repository, does that repository have to be on the machine I'm running the juju commands from or the "machine 0" that is managing the juju cluster?
<webbrandon> okay nothing worked. gonna submit bug
<mgz> webbrandon: thanks
<mgz> please mention region/other provider config that's not standard
<webbrandon> yeah fixed
<lazypower> mxc: did you get an answer to your charm deployment question?
<mxc> yeah
<lazypower> mxc: the way I understand it is, the repository has to be on the machine you're executing the juju commands from - this triggers a sequence of caching on Machine0 - which caches all the charms in use in your juju landscape. Sorry if this is a duplicate answer or incorrect, but its how I understand it to work.
<lazypower> ah ok. my bouncer must have missed the answer in its cache. Glad you got it sorted *hattip*
<mxc> the problem was that my local charm wasn't in a precise directory
<lazypower> aahhh ok.
<lazypower> yeah, release directories are important.
<lazypower> I found that out the hard way too
<aquarius> marcoceppi, ping about postgresql backups in discourse
<marcoceppi> aquarius: ack
<aquarius> wait, ignore me
<aquarius> ha!
<aquarius> postgres is backing up
<aquarius> on the postges machine
<aquarius> which is not the discourse machine
<aquarius> heh :)
<marcoceppi> aquarius: all of these statements are correct!
<aquarius> marcoceppi, the stuff in /var/lib/postgresql/backups/ is .dump files -- can I just scp them to another machine?
<aquarius> they're not some sort of live backup?
<marcoceppi> aquarius: you can scp them
<marcoceppi> it's safe
<marcoceppi> aquarius: they're snapshots
<webbrandon> pretty sure I found a bug in juju-local.  Run it by here before I submit it.  I am getting with "juju status" after launching charm instance on machine 1: agent-state-info: '(error: container "mind-local-machine-1" is already created)'.  > The whole status at http://paste.ubuntu.com/6553558/
<marcoceppi> webbrandon: are you on 1.16.4 ?
<marcoceppi> webbrandon: nvm, you are!
<webbrandon> yes
<webbrandon> :)
<marcoceppi> webbrandon: this looks the local environment wasn't cleaned up from last time
<marcoceppi> webbrandon: what happens if you juju destroy-environment then reboostrap?
<webbrandon> I went into var/lib/juju/containers and made sure everything was removed before bootstrapping
<webbrandon> It does it again
<webbrandon> marcoceppi: its like it is creating the mind-local-machine-1 for both my bootstrap and my charm
<marcoceppi> webbrandon: that's a bug
<webbrandon> figured
<webbrandon> I will report it
<webbrandon> hmm.  just need to find the juju-local branch
<webbrandon> lol
<marcoceppi> webbrandon: there is no juju-local
<marcoceppi> report it against juju-core project
<webbrandon> just figuring that out.  thank you marcoceppi. again.......
<webbrandon> marcoceppi I am noticing it says its running 13.04 and I am on 13.10.  COuld this be my issue maybe?
<webbrandon> So why was juju gernate-config created if juju init does the same?  Is it the extra freatures like --show?  Just trying to learn random info, no reason.
<aquarius> OK. My postgres machine, deployed with juju, backs up things into /var/lib/postgresql/backups, which is great.
<aquarius> I would like those backup files to also end up on another machine somewhere. How should I do that?
<aquarius> I could, for example, generate a new ssh key on the postgres machine, for the postgres user, and then run "scp --newer /var/lib/postgresql/backups/* othermachine:/backups-from-juju" in a cron job. But then I've generated an ssh key *on that machine* -- if I scale postgres out with juju, or redeploy or something, then I won't have any backups.
<aquarius> I could run that cron job on othermachine and scp *into* my juju machine to copy the backup files back, but I hardly know what the name of my juju machine *is*, because I don't have to
<aquarius> how am I meant to set this sort of thing up?
#juju 2013-12-11
<marcoceppi> aquarius: subordinate
<aquarius> marcoceppi, the thing I don't understand is: I'm meant to write a whole charm? and put my ssh keys in it?
<InformatiQ> I am working on a local charm and have updated the charm contents to fix a bug, now when i rerun the charm it still picks the buggy version
<InformatiQ> how do i force new code in?
<ashipika> mysql charm problem: http://paste.ubuntu.com/6555177/
<InformatiQ> how do i force new code of local charm to get pushed to new deploys?
<InformatiQ> noodles775: hei
<noodles775> Hi InformatiQ.
<InformatiQ> I am kinda stuck developing a charm, it seems it is caching an old code version so keeps failoing in deploying that local charm
<InformatiQ> noodles775: how do i force new code into the failed deploy?
<InformatiQ> or to a new deploy even
<noodles775> InformatiQ: That will happen if you remove the 'revision' file which was created. juju deploy increments it each time you deploy. If you remove and recreate it, you'll effectively tell juju to deploy a revision for which it already has a copy. Does that make sense? Athough, that shouldn't effect a new deploy (ie. a new environment).
<InformatiQ> noodles775: i have destryed many envs but strsil lsame issue
<InformatiQ> trying the revision thing
<noodles775> InformatiQ: if you have a freshly bootstrapped environment, I cannot see how it could even know about old versions of your charm. But maybe others will know.
<InformatiQ> noodles775: ok removing the revion file didn't help either
<InformatiQ> but new deploy did not create that file and it started at 12
<InformatiQ> something is fishy
<noodles775> InformatiQ: I wasn't suggesting removing the revision file - rather that removing the revision file can cause the behaviour you saw (with an existing environment). So given the above info, I don't understand why you'd be getting a cached version of your charm in a freshly bootstrapped environment. We'll need to wait for someone else to find out more I think.
<jam> InformatiQ: you can do "juju deploy --upgrade local:foo"
<InformatiQ> thanks jam that seems to have remedies the issue
<noodles775> jam: for my own learning, why/how is there a cached version of the charm if the environment is freshly bootstrapped?
<jam> noodles775: if you destroy-environment, I would expect it to destroy the charm cache, but I don't quite know for sure. The above conversation sounded more like InformatiQ was destroying the *service* which doesn't delete the cached charm
<jam> and doing "juju destroy-service foo; juju deploy local:foo" will reuse the charm that was uploaded unless you do "juju deploy --upgrade local:foo"
<noodles775> Right - I'd understood that the environment had been re-created (rebootstrapped). Thanks.
<InformatiQ> jam: I was doing destroy-environment
<InformatiQ> FYI that is local environment (lxc)
<jam> InformatiQ: I'm not personally 100% about where the files are going and what may or may not be cleaned up. It *sounds* like a bug if destroy-environment isn't destroying the charm cache
<marcoceppi> aquarius: the subordinate charm, they can be super simple, it's just a way to bolt on additional stuff to existing charms without having to fork a charm
<aquarius> marcoceppi, I don't think I understand how that ought to work. I mean... charms live in the charm store, right?
<marcoceppi> aquarius: no
<marcoceppi> aquarius: charms live either locally, or in a personal branch in the charmstore, or in the offiicial charm store
<aquarius> marcoceppi, so... I should write a whole new charm, and hardcode my ssh key into it?
<aquarius> and then th charm deploys that key and sets up the rsync backup?
<aquarius> I was hoping that someone had already done something like that...
<marcoceppi> so you can mkdir -p ~/charms/precise; juju charm create aquarius-psql-backups ~/charms/precise; hack on that code a little; juju deploy --repository ~/charms local:aquarius-psql-backup
<marcoceppi> or, bzr push lp:~aquarius/charms/precise/aquarius-psql-backup/trunk; then juju deploy cs:~aquarius/aquarius-psql-backup
<marcoceppi> of course, naming the charm whatever you want, you don't have to put you name in the charms name
<marcoceppi> I was just trying to make a personalized example
<marcoceppi> then, during the install hook have it copy the SSH key you want, then drop a file in cron.d
<marcoceppi> which I think is the extent of your backup stuff
<marcoceppi> no need to make configuration options, no need to go crazy and make it useful for anyone else if you don't want to
<aquarius> that's basically my plan, indeed :)
<marcoceppi> aquarius: we had plans to write a backup charm, but the permatations are so plentiful it's hard to do it and do it right
<aquarius> yeah
<marcoceppi> aquarius: the last think you'll want to do, is edit the metadata.yaml file and makesure "suborindate" is true
<aquarius> I'd have to generate an ssh key and then teach the destination machine about it
<aquarius> maybe it'd just be easier to have the destination machine pull the stuff, rather than the source machine to push it :(
<aquarius> I am wary of sshing anywhere as root.
<aquarius> man, I hate being a sysadmin.
<Felipe_C> HI, Anyone could answer a couple of questions regarding JUJU - Manual provisioning?
<marcoceppi> FourDollars_: it's best to just ask, instead of asking to ask
<marcoceppi> oops, sorry FourDollars_; wrong ping
<jcastro> marcoceppi, I seem to still have 1.2.0 of charm tools
<marcoceppi> jcastro: what's `dpkg -l charm-tools` show?
<jcastro> ii  charm-tools    1.2.0-0ubunt all          Tools for maintaining Juju charms
<jcastro> nm, I found the problem
<jcastro> marcoceppi, I can confirm the right readme template this time. \o/
<jcastro> nice work
<marcoceppi> jcastro: try this, go to a charm, run `juju charm add tests`
<jcastro> marcoceppi, that worked
<marcoceppi> jcastro: now go write a bunch of tests
<oatman> hey, can someone help me with an agent-state-info error I'm getting
<oatman> ?
<oatman> "agent-state-info: '(error: container "oatman-local-machine-1" is already created)'"
<marcoceppi> oatman: this was brought up last night
<oatman> marcoceppi, yeah?
<oatman> it's been working all day, I don't understand what broke
<marcoceppi> oatman: yeah, seems like a new bug that came up recently
<marcoceppi> oatman: do you have anything in /var/lib/cache/lxc?
<marcoceppi> I think that's the path
<marcoceppi> one min
<oatman> no folder called cache in /var/lib
<marcoceppi> webbrandon: juju init and juju generate-config are the same. they're aliases of each other
<oatman> marcoceppi, I have /var/cache/lxc
<oatman> I have
<oatman> âââ cloud-precise
<oatman>     âââ ubuntu-12.04-server-cloudimg-amd64-root.tar.gz
<marcoceppi> oatman: that's fine
<marcoceppi> oatman: I think /var/lib/lxc is what I wanted. Could you pastebin the tree of that?
<oatman> sure could
<oatman> it is 29k lines, that ok?
<oatman> I could tree -d it
<oatman> https://pastebin.canonical.com/101822/
<oatman> had to -d it marcoceppi
<oatman> 30k lines crashed my browser last time ;-)
<marcoceppi> oatman: okay, yeah, I got what I wanted
<marcoceppi> oatman: juju destroy-environment
<marcoceppi> then make sure /var/lib/lxc/oatman-local-machine-1 is removed as well
<oatman> ok
<marcoceppi> bootstrap and try again
<marcoceppi> oatman: also, when you got a second, what's juju version say?
<oatman> so I still have this in the local machine folder:
<oatman> config  fstab  rootfs  rootfs.hold
<oatman> 1.16.5-raring-amd64
<marcoceppi> interesting, when you destroy-environment everyhthing in /var/lib/lxc that's related to a local-machine should be removed
<oatman> should I blow it away manually?
<oatman> I've blown it away anyway, I'm so close to finishing what I was doing!
<oatman> I'll let you know if it works
<marcoceppi> oatman: yeah, blow it away
<oatman> marcoceppi, fixed!
<oatman> thanks so much
<marcoceppi> oatman: awesome, glad that worked out for you
<marcoceppi> oatman: if after you destroy this, it still lingers, open a bug against juju-core as that's a regression
<oatman> will do
<oatman> I think I see the old bug report
<oatman> it's interesting that I've done about 50 bootstraps today, and it's only the last one that caused issues
<lazypower> So, before I get crazy and really manage to foul things up - can I mix mode my juju deployments? As in manually provision a machine under the amazon environment and consume it?
<marcoceppi> lazypower: you *can*
<marcoceppi> lazypower: you can turn on an amazon machine, then juju add-machine <ip>; so long as that machine as your ssh key on it
<marcoceppi> then you can juju deploy --to <machine-num>; after the machine is enlisted in juju status
<marcoceppi> lazypower: it's still betaware though, use at your own risk
<marcoceppi> the next release of juju, 1.17, should have better support for this
<lazypower> marcoceppi: so, if I get really fun and add a machine from a different provider, juju is basically blind to this and doesnt care
<marcoceppi> lazypower: as long as the machine can talk to the bootstrap node, yes, juju is blind to it
<marcoceppi> lazypower: so you may need to open ports in the firewall to have access to the bootstrap node exposed
<lazypower> Ah Yeah, I didn't consider that juju uses the internal IP structure for cross communication
<oatman> marcoceppi, I spoke too soon, now my instance-state is "missing"
<oatman> it did work once
<oatman> marcoceppi, oh gods, I was just impatient
<oatman> marcoceppi, it's come up now :-)
<marcoceppi> :)
<lazypower>  /window 8
<arosales> marcoceppi, woot \o/ Charm Tools 1.2.3 released :-)
<marcoceppi> aquarius: heh, yeah, just building the windows tools now
<marcoceppi> arosales: *^
<arosales> marcoceppi, cool
<arosales> marcoceppi, remember to get an rt for signing
<marcoceppi> arosales: yeah
<arosales> marcoceppi, thanks
<marcoceppi> Cool, powershell isn't working :(
<lazypower> marcoceppi: which version of windows, and/or powershell?
<lazypower> And do you need a third party to test it? i've got a fleet of VM's here we can toy with.
<marcoceppi> Windows Server 2012, and I can't get it to give me a prompt
<lazypower> shoot me the instructions and i'll fire up a test for you. I've got a meeting in 30 minutes, but i can help until then.
<arosales> marcoceppi, reading your release announce for 1.2.3 charm tools
<arosales> "juju charm add tests` will create an example Amulet test file based on metadata.yaml information for the charm provided (or cwd, if cwd is a charm)"
<arosales> sorry for being dense here but what is "cwd"
<arosales> in this context
<marcoceppi> current working directory
<marcoceppi> bascially you either do `juju charm add tests /tmp/precise/charm` or `cd /tmp/precise/charm; juju charm add tests`
<arosales> marcoceppi, so the default is not provided is the cwd
<arosales> sorry if no charm path is given is the cwd, and hopefully that is a charm path
<marcoceppi> arosales: right, it'll check if the current directory is a charm, if you didn't give it a path
<arosales> marcoceppi, ok I  follow thanks
<arosales> marcoceppi, thanks
<marcoceppi> arosales: a lot of the commands that take a path do this, I don't know why I felt the need to highlight it
<arosales> marcoceppi, no is good info I just read it wrong
<youngnico> Hey guys, working on a node deploy (https://juju.ubuntu.com/docs/howto-node.html) and can't seem to get the node app to respond. I've related the charms and exposed haproxy, but when I go to haproxy's public URL I can't get a response. Any thoughts or ideas to point me in the right direction?
<freeflying> youngnico, 1 you don't have to do expose haproxy, 2 can you show us result of juju status
<marcoceppi> freeflying: you do have to expose haproxy if you want to get to it outside of the network
<youngnico> http://pastebin.com/QQ8NXCrM
<marcoceppi> youngnico: you're haproxy unit is in an error state
<youngnico> Ahhh..
<marcoceppi> youngnico: I just patched the haproxy, as there was a problem with it earlier
<youngnico> config-changed?
<freeflying> marcoceppi, you're right, youngnico's case is public cloud, then he has to :)
<marcoceppi> youngnico: yes, so for this problem in particular, just run `juju resolved haproxy/0`
<marcoceppi> youngnico: that will push past the error, and on the next go-around it should recieve the relation information and work
<marcoceppi> youngnico: finally, if you're just testing the node app, you don't neccisarily need haproxy at all :). If it still gives you grief after a few mins, run juju expose node-app; then go to the node-app's URL
<youngnico> After resolving the error, should I re-relate the charms? Or run a restart of some sort?
<marcoceppi> haproxy, and all proxies, are there if you have more than one unit. For testing and playing, it's just a machine you don't need
<marcoceppi> youngnico: no, it'll continue on it's way. There are a bunch of events queued to run, but can't because it's in an error state
<jcastro> marcoceppi, ok found another template problem
<marcoceppi> jcastro: sweet, I want to squeeze a few more things in to the 1.2 tree, so open a bug/merge req
<jcastro> charm proof gives me E: README.md Includes boilerplate README.ex line 11 for like, all the headings, etc.
<jcastro> ok
<marcoceppi> jcastro: ah, yeah, that makes sense
<marcoceppi> I'll drop the boiler plate checking
<jcastro> https://bugs.launchpad.net/charm-tools/+bug/1260073
<_mup_> Bug #1260073: charm proof is too strict <Juju Charm Tools:New> <https://launchpad.net/bugs/1260073>
<jcastro> FYI
<marcoceppi> jcastro: ack, thanks
<marcoceppi> glad I didn't get too deep in to the Windows stuff
<youngnico> marcoceppi: / freeflying - thanks guys! So I pushed past the errors, and the server is resolving a 502 (Bad Gateway) - http://pastebin.com/apUAJTcP
<youngnico> Is this just a problem with the node-app example?
<marcoceppi> youngnico: I just noticed that the mongodb service is still in an installed state, IE, not started yet
<youngnico> Oh, nevermind it was just starting up!
<youngnico> Takes a bit, I need to be more patient!
<marcoceppi> youngnico: yeah, it can take a few mins to come up :)
<marcoceppi> youngnico: I'll have the fix for haproxy land soon so you won't run in to that the next time
<jcastro> it'd be nice to have splash pages there instead of nginx errors
<marcoceppi> jcastro: file a bug ;)
<jcastro> "yo, I will error out until you connect a database to me"
<jcastro> marcoceppi, is that per charm?
<arosales> marcoceppi, i think david c. had identified some issues with haproxy too
 * arosales grabs bug #
<marcoceppi> arosales: yeah, that's what I patched last night
<marcoceppi> I caught him online when he found the problem, which youngnico ran in to
<arosales> https://bugs.launchpad.net/charms/+source/haproxy/+bug/1257062
<_mup_> Bug #1257062: config-changed fails <haproxy (Juju Charms Collection):In Progress> <https://launchpad.net/bugs/1257062>
<arosales> ah ok I think I saw the merge now doing a search
<marcoceppi> Oh yay, dave ack'd it
<marcoceppi> let me merge it now
<arosales> https://code.launchpad.net/~marcoceppi/charms/precise/haproxy/cfg-changed-fix/+merge/198491
<youngnico> Thanks a bunch guys, you have no idea how much help this is!
<arosales> marcoceppi, does merge 198491 resolve bug 1257062?
<marcoceppi> arosales: yes
<marcoceppi> arosales: they're attached
<arosales> or are there still issues with version 19
<marcoceppi> youngnico: you're welcome! Let us know if you have any other questions
<arosales> marcoceppi, cool could you drop a note in the bug so the bug reporter, darryl sees the current status.
<youngnico> Will do!
<arosales> I think he may still be under the impression the work around needs to be deployed (ie deploy version 18)
<marcoceppi> arosales: yeah, I'm writing him now, that he should be able to use haproxy-22, and do an upgrade charm
<arosales> marcoceppi, cool another bug fixed
<marcoceppi> squish'em squash'em
<arosales> another bits the dust
<arosales> another one bits the dust, that is.
<youngnico> So I'm trying to deploy my own node application now, using the node-app charm. I made a configuration file with the location of my app on Github, and ran juju deploy --config ./config.yaml node-app (config.yaml has the git repo pointer), but it throws: error: no settings found for "node-app".
<youngnico> Am I passing the configuration yaml file incorrectly?
<youngnico> I'm trying to pass my configuration like: https://juju.ubuntu.com/docs/charms-config.html
<marcoceppi> youngnico: what's your config.yaml file look like?
<youngnico> I just copied the example at: https://github.com/charms/node-app/blob/master/config.yaml
<youngnico> And changed the repository to my own. Does the repo need to be public?
<youngnico> Or can it forward my keys to pull to the remote?
<youngnico> Actually, even if I just copy the config exactly, it still throws that error
<marcoceppi> youngnico: yeah, you need to format it like so: https://juju.ubuntu.com/docs/charms-config.html#config-deployment
<marcoceppi> the config.yaml and the configuration file you're writing are two different things
<marcoceppi> I'd recommend naming int deployment.yaml, then you want to change mediawiki to node-app, and the key: values to the ones you wish to change
<marcoceppi> s/int/it to/
<webbrandon> marcoceppi: Sorry didn't see your response.  I understand they are but why?  I know there is some concept behind it, I am just trying to understand.
<youngnico> Ahhh, okay the top level key needs to be the charm name.
<marcoceppi> youngnico: right, you can actually put multiple services configurations in one file
<webbrandon> The way I think is there should only be one command for a event, why two in this case?
<marcoceppi> webbrandon: it was first called generate-config, but that's so long, we decided init was a shorter name
<marcoceppi> we kept the old one for backwards compat
<lazypower> Has anyone recently setup MMS Monitoring with the MongoDB charm? I'm not finding the MMS Token it's looking for, it appears they ahve updated the MMS Service to use an Auth Key and Secret Key for configuration now.
<webbrandon> ohhh. makes sense now.  SO it will eventualy get depreciated
<youngnico> Handy! So the config just sets values, the config.yaml when authoring a charm is more for defining the structure of those values... I'm getting closer, thanks!
<marcoceppi> youngnico: exactly!
<marcoceppi> webbrandon: maybe/probably. There's some clashing, as some people don't like the name init, others don't like the lenght of generate-config
<marcoceppi> lazypower: I have no idea. negronjl wrote the charm, maybe he has some insights?
<marcoceppi> repeating the message, with ping, so it's easier to read
<lazypower> I'm thinking about opening a bug on launchpad for this - i'm not done digging though.
<marcoceppi> negronjl: lazypower asks: "Has anyone recently setup MMS Monitoring with the MongoDB charm? I'm not finding the MMS Token it's looking for, it appears they ahve updated the MMS Service to use an Auth Key and Secret Key for configuration now."
<marcoceppi> lazypower: +1 on opening a bug, even now, if you find the answer then you can just document it there, if not it's atleast there
<negronjl> marcoceppi, lazypower: a bug would be the thing to do here.  As I remember it, I didn't setup the mongodb charm for monitoring :/
<negronjl> marcoceppi, lazypower: I can work on that soon(ish) :)
<marcoceppi> negronjl: in your infinite free time of course ;)
<negronjl> marcoceppi, ROFL
<lazypower> negronjl: Actually - you're fine the way you are. Looking over the charm this was for the configuration flags
<negronjl> lazypower, you see ... I'm awesome ... I fixed it even before I knew I needed it :P
<lazypower> this has been depecriated but not removed from teh default config - https://jira.mongodb.org/browse/SERVER-8055
<negronjl> j/k :P
<lazypower> I'll open a bug report against this and issue a merge request later if you dont mind
<youngnico> marcoceppi: one last question, and I think I'll have this working: When I set everything up on my own app, the node-app status is errored with "'hook failed: "install"'".
<negronjl> lazypower, not at all ...
<youngnico> How would I go about debugging that? Is there a "redeploy" command or something with a verbose flag I can see what's causing the error?
<youngnico> I'm sure I need to customize a hook or something to start my app differently than the example, but I'm not quite sure where/how to debug. If there's some documentation that I'm missing please point me in the right direction!
<marcoceppi> youngnico: you can do a few things, you can `juju ssh node-app/0` then look at the charm logs in `/var/log/juju/unit-node-app-0.log`
<marcoceppi> youngnico: alternatively, you can run `juju debug-hooks node-app/0`, then in another terminal run `juju resolved --retry node-app/0` and you can interactively debug hooks
<marcoceppi> youngnico: the latter is a little more complex, but super powerful, there's a charm school we did on it, let me find you the video
<youngnico> Great! That sounds like enough to keep me busy with debugging ;) is there documentation around that somewhere, or just man pages? I hate being a pest in IRC with questions, just don't know where to look.
<marcoceppi> youngnico: https://juju.ubuntu.com/docs/authors-hook-debug.html
<negronjl> bac: MP:198633 Approved and merged
<marcoceppi> youngnico: that page is a little dry, sadly
<youngnico> No worries, I'll take a look. Trying to figure out how to set SSH keys now... the one Juju is trying to use is no good =/
<lazypower> negronjl: Thank you for the quick response. I've opened the bug report and should have a PR for you later this evening.
<negronjl> lazypower, np
<lazypower> Another question that may be off topic. Is it typical to gate pull requests through the original charm maintainer or is it better practice to just assign the charmers group and go through the documented channels?
<marcoceppi> lazypower: always assign to ~charmers
<lazypower> Aye aye captain.
 * arosales waves at lazypower
 * lazypower waves back at arosales 
<lazypower> Greetings Program
<Informat1Q> marcoceppi: can you help me get my charm into launchpad
<Informat1Q> there is already a bug
<Informat1Q> and I am subscribed to it
<Informat1Q> how do i merge my code there
<Informat1Q> marcoceppi: the thing is i did not start from that bug from a new repo
<marcoceppi> Informat1Q: happy to help, going to need some links for context though
<Informat1Q> marcoceppi: trac bug https://bugs.launchpad.net/charms/+bug/795480
<_mup_> Bug #795480: Charm needed: Trac <bitesize> <Juju Charms Collection:In Progress by ahmedelgamil> <https://launchpad.net/bugs/795480>
<Informat1Q> my code https://code.launchpad.net/~rhanna/charms/precise/trac/trunk
<marcoceppi> Informat1Q: cool, so you want to merge ~rhanna/charms/precise/trac/trunk in to lp:charms/trac?
<Informat1Q> marcoceppi: i think this is the correct path, or is it not?
<marcoceppi> Informat1Q: sounds good so far
<marcoceppi> Informat1Q: OHHH
<marcoceppi> Informat1Q: This is a new charm
<Informat1Q> marcoceppi: yup that is the problem
<marcoceppi> Informat1Q: Okay, no problem, what you want to do is assign the bug to you. The click on "Link a related branch" and link to your lp:~rhanna/charms/precise/trac/trunk branch; Then move  the bug status to "Fix Committed". That'll put it in the review queue for a charmer to review and provide feedback, then eventually put it int he store for you
<Informat1Q> marcoceppi: thanks
<Informat1Q> marcoceppi: you're the man
<marcoceppi> Informat1Q: after you do that, in about 10 mins you'll it listed in the review-queue: manage.jujucharms.com/tools/review-queue
<marcoceppi> https://manage.jujucharms.com/tools/review-queue
<Informat1Q> done
<Informat1Q> waiting for my first charm review
<marcoceppi> Informat1Q: Awesome!, given the size of the queue we might not get to it this week
<marcoceppi> Informat1Q: check the page again in about 5 mins, you should see it right below the haproxy entry
<Informat1Q> cool i'll get some sleep now
<Informat1Q> good night all
<marcoceppi> Informat1Q:  thanks for the submission! o/
<marcoceppi> Informat1Q: confirmed, it's in the queue!
#juju 2013-12-12
<lazypower> negronjl: I'm not sure that just stripping the configuration flags is the proper route to go with the modifications I filed. Do you want to retain MMS support in the mongodb charm, or does it make sense ot break it into another charm, possibly a subordinate, now that the MMS service is a python application?
<lazypower> I'm fine with either method, and would love to contribute to the effort of integration.
<negronjl> lazypower, one option would be for you to make the subordinate charm and we can then see about taking the functionality out of mongodb
<lazypower> negronjl: Challenge accepted
<negronjl> lazypower, rofl .. cool!
<lazypower> Let me get some other high priority things out of my queue and I'll get a subordinate prototype in your hands soon
<lazypower> I'm working on charming up the Errbit exception catcher - It's going to provide an airbrake interface the way its layed out in my head. I'm a bit confused if it should be a provides: relationship, or be a peer relationship.
<lazypower> I initially call peer, but at the end of the day other charms will have to require it to hook into the server stack (it provides api keys and other fun configuration magic) so - it should probably be a provides: and requires: <optional> on the related charm yes? or am I misunderstanding the relationship categories?
<negronjl> lazypower, If I understand your reasoning correctly, then your theory is correct :)
<lazypower> Scope creep like a pro. Love it
<Felipe_C> Hi All, Could anyone confirm what JUJU - Manual Provisioning is? Will that give me the possibility of using a
<Felipe_C> Hi All, Could anyone confirm what JUJU - Manual Provisioning is? Will that give me the possibility of using, for instance, a VPS ( purchased from whatever provider but running Ubuntu)  and deploying services there using only my SSH root account?
<axw_> Felipe_C: that's correct. It's not quite ready yet, but that is one use case for it
<Felipe_C> Thanks axw_ - Would I assume correctly that this, in itself, could potentially be the single most valuable tool for (not fully cloudfied) web developers, server admins, etc?
<axw_> Felipe_C: we Juju developers like to think so :)
<axw_> it certainly should take a lot of the pain out of deploying apps to VPSes
<Felipe_C> axw_ - with the added benefit of being burstable to a PaaS of your choice, such as AWS - provided of course, it allows easy collocation of services on the same machine, which currently is only available using the command line - am I right?
<axw_> Felipe_C: right, AFAIK, the GUI does not support "placement directives" (--to on the CLI)
<oatman> morning! I have a mongo error when bootstrapping juju, could someone help me with this?
<oatman> sudo juju bootstrap
<oatman> ERROR unauthorized: cannot create log collection: unauthorized mongo access: unauthorized db:juju ns:juju lock type:1 client:127.0.0.1
<oatman> huh, turns out my mongodb server hadn't come up at boot time, starting it fixed it! Odd error though, for no db connection
<oatman> wait
<oatman> that doesn't fix it
<oatman> ...
<mthaddon> mgz: you seen oatman's problem before? ^ (local provider)
<mgz> oatman, mthaddon: doesn't look familiar
<oatman> mgz, do you think I could wipe my mongo setup?
<mgz> we should be spinning up a seperate mongo, but it's poissible if you had existing mondgo config it would confuse the local provider
<mgz> purging the package then reinstalling it might be a big-hammer option
<oatman> mgz, I think my mongo is crashing, everytime I sudo start mongodb, I get a different pid
<mgz> oatman: check the logs, they're er... somewhere
<oatman> heh
<oatman> huh, nothing in them
<oatman> wc /var/log/mongodb/mongodb.log
<oatman> 0 0 0 /var/log/mongodb/mongodb.log
<oatman> how on earth did my mongo server get broken while my machine was off during the night?!
<jam> oatman, mgz: Are you trying to start a mongodb for Juju or you have mongodb in your system and you also have a juju local environment?
<jam> I've heard there is a bug with mongodb, in that if you start a juju local instance
<jam> it also starts a 'mongod' process
<jam> and then the global mongodb says "oh, I'm already running, I'll just exit"
<oatman> jam, thanks for helping, I'm just using system mongo
<jam> even though we're trying to have 2 mongod's running
<oatman> I think you're right
<oatman> ps -e | grep mongo
<oatman>  1190 ?        00:00:15 mongod
<oatman> (fenchurch2)â  ~VIRTUAL_ENV  status mongodb
<oatman> mongodb stop/waiting
<oatman> I'll nuke juju's mongo and spin mine up?
<jam> status juju-db
<jam> ?
<jam> oatman: you should be able to "stop juju-db" and then "start mongodb"
<oatman> OATMAN SHELL PROXY STARTED
<oatman> subprocess.check_call(
<oatman>         ['a2dissite', '000-default']
<oatman>     )
<oatman> sorry, bad paste
<oatman> status: Unknown job: juju-db
<oatman> ^
<jam> oatman: if this is local provider, then I think we name it differently, 1 sec
<oatman> yes, lxc
<jam> oatman: juju-db-$USERNAME-local
<jam> so "stop juju-db-oatman-local" for example
<oatman> status juju-db-oatman-local
<oatman> juju-db-oatman-local stop/waiting
<oatman> sudo stop juju-db-oatman-local
<oatman> [sudo] password for oatman:
<oatman> stop: Unknown instance:
<jam> oatman: what does psgrep mongod give you?
<oatman> I'm not familiar with that command
<oatman> ps -e | grep mongod
<oatman>  1190 ?        00:00:17 mongod
<jam> oatman: so you do have a mongod running, if you use ps -efwww you can probably figure out who started it and who its running for
<oatman> yep, it's juju
<oatman> ps -efwww  | grep mongod
<oatman> root      1190     1  1 10:28 ?        00:00:18 /usr/bin/mongod --auth --dbpath=/home/oatman/.juju/local/db --sslOnNormalPorts --sslPEMKeyFile /home/oatman/.juju/local/server.pem --sslPEMKeyPassword xxxxxxx --bind_ip 0.0.0.0 --port 37017 --noprealloc --syslog --smallfiles
<jam> oatman: so I'm surprised juju-db-oatman-local doesn't realize it is running, but you can try just "sudo kill 1190" and see if that lets you start your normal mongodb
<oatman> yep, that low-tech method allowed me to start my local mongo
<oatman> lets see if that fixes my juju
<oatman> jam, mgz killing the rogue juju mongo process fixed it :-)
<mgz> oatman: ace
<noodles775> I'm unable to ssh/debug-hooks - it instead seems to look up the address for the unit indefinitely: http://paste.ubuntu.com/6560877/, anyone able to help?
<ashipika> hi.. can somebody please explain relation hook names? i.e. if in the metadata.yaml i have
<ashipika> peers:
<ashipika>  peers-relation:
<ashipika>    interface: somename
<ashipika> which hooks need to be implemented?
<noodles775> fwiw, I can't say it's related, but I'm now able to ssh/debug-hooks with the unit above after switching environments, exiting the debug-hooks session I had going in the other (openstack) environment, switching back to my local environment and running juju debug-hooks...
<noodles775> ashipika: I've not yet worked with peer-relations, and right, the docs seem a bit sparse in that respect.
<bloodearnest> ashipika: peers-relation is the name in your charm of the relation. So you want to add peers-relation-relation-joined, for example (and also probably not include 'relation' in the relation name :)
<ashipika> noodles775: thnx for reply! i kind of figured it out.. but i still need to test it, which should be.. interesting :)
<ashipika> bloodearnes: yes.. figured it out :) my mistake.. *dubmdumb*
<bloodearnest> noodles775: are there yet any semantics to required/provides/peer relation types?
<ashipika> docs could use a bit of polishing :)
<noodles775> bloodearnest: idk - just reading up on peer relations.
<bloodearnest> ashipika: name of relations is hard (2 hard problems, etc) - my advice is to be very specific
<jam> noodles775: I actually thought "juju debug-hooks" didn't work at all in a local environment, because we don't have proper IP address detection yet
<bloodearnest> e.g. we have some relations called cached-website and some called website-cache, difficult to clearly remember which way round they are
<noodles775> jam: works well for me :-) Soo much faster.
<ashipika> bloodearnes: but i.e. peer_ip=`relation-get ip` should work in the relation-changed hook, correct? given that the relation-joined hook says relation-set ip=$IP
<bloodearnest> ashipika: yes, that should work in both -joined and -changed hooks AFAIK. But not sure about -broken or -departed
<ashipika> bloodearnest: thnx.. trying to figure it out one step at a time :)
<bloodearnest> ashipika: ah wait, I misunderstood your question
<bloodearnest> ashipika: you do "relation-set ip XXX" in -joined, and you want to do "relation-get ip" in changed? Not sure that will work.
<bloodearnest> but it might :(
<bloodearnest> :)
<ashipika> bloodearnest: then who sets these variables?
<ashipika> auto-juju-magic? :D
<bloodearnest> ashipika: the other side of the relation, usually :)
<bloodearnest> ashipika: ip address is automatically provided by juju for example
<bloodearnest> ashipika: you shouldn't have to set it
<ashipika> ip is just an example.. any variable.. i suppose relation-set should be used somewhere.. if i interpreted it correctly it should be in the relation-joined hook?
<bloodearnest> ashipika: yes, joined and changed usually (can often be identical)
<bloodearnest> ashipika: relation-set is for sending data to the other side of the relation. So one peer would set some value to other peers
<ashipika> bloodearnest: peer relations.. are these supposed to be relation between two units of the same service?
<bloodearnest> ashipika: I believe so
<ashipika> bloodearnes: so i gues, both units will run both hooks: joined and changed.. am i correct?
<bloodearnest> ashipika: the squid charm uses them for cache peering, for example
<bloodearnest> ashipika: yes
<ashipika> excellent!
<ashipika> why do i get
<ashipika> Permission denied (publickey, password)
<ashipika> ERROR exit status 255
<ashipika> when i try juju debug-log?
<marcoceppi> ashipika: because there was a problem uploading your ssh key
<marcoceppi> ashipika: because there was a problem uploading your ssh key
<marcoceppi> Do you have an ssh key generated?
<ashipika> user's ssh key?
<marcoceppi> ashipika: your ssh key
<marcoceppi> ashipika: do you have one?
<ashipika> yes
<marcoceppi> ashipika: can you `juju ssh 0`
<ashipika> nope :(
<ashipika> same error
<ashipika> is there a requirement on permissions to my ssh keys?
<marcoceppi> ashipika: wait, do you have your .pub as well?
<marcoceppi> or just the private key
<ashipika> .ssh/id_rsa.pub?
<ashipika> .ssh contains id_rsa (private) and id_rsa.pub (public)
<marcoceppi> ashipika: huh, yeah that's what you need.
<marcoceppi> .pub should be 0644
<ashipika> both have permission 600
<marcoceppi> eh, 600 should be okay too
<ashipika> aaah.. ok ok
<marcoceppi> ashipika: are you using local provider?
<ashipika> null
<ashipika> manual
<ashipika> one question: in juju status it says cpu-cores=1 even on a multi-core machine..
<marcoceppi> jcastro: we need a video on troubleshooing and debugging charms
<marcoceppi> ie: juju debug-hooks
<jcastro> marcoceppi, ok
<jcastro> wanna make one like tomorrow or something?
<marcoceppi> jcastro: yeah, just like a quick 10-15 min video
<marcoceppi> juju debug-hooks, juju ssh + tailing logs, juju debug-log
<jcastro> ok we'll do it tomorrow
<jcastro> maybe bust out two or so?
<marcoceppi> jcastro: yeah, sounds good
<ashipika> any clues as to why juju ssh 0 would not work?
<ashipika> or where to start debugging it?
<ashipika> (manual provisioning)
<marcoceppi> ashipika: if you're getting an ssh key error, it's because your ssh key wasn't copied during enlistement. Manual provider is still under development
<ashipika> ok.. thnx
<lazypower> Does the EC2 side of root-disk constraints populate in EBS flavor? I've added --constraint "root-disk=50G" to my provisioning request, and the root disk is still at 8gb, i thought maybe it went into the /mnt directory, but thats provisioned with 318GB of ephemeral storage. In either case, it doesn't appear to have taken hold.
<marcoceppi> natefinch: Does the EC2 side of root-disk constraints populate in EBS flavor? I've added --constraint "root-disk=50G" to my provisioning request, and the root disk is still at 8gb, i thought maybe it went into the /mnt directory, but thats provisioned with 318GB of ephemeral storage. In either case, it doesn't appear to have taken hold.
<marcoceppi> per lazypower
<natefinch> it should adjust the root (i.e. /  ) partition.   What version of Juju?
<mgz> natefinch: it probably doesn't work with EBS
<mgz> the ec2 provider hardcodes /dev/sda1
<natefinch> mgz, right, no it doesn't.
<mgz> and I'm pretty sure the root device comes up on something else when using EBS
<mgz> lazypower: ^
<natefinch> sorry, I neglected to pay attention to that part of the question, my bad.
<lazypower> Hmm... interesting
<lazypower> 1.16.4-unknown-amd64 is the version of juju i'm running. Latest package in BREW
<marcoceppi> lazypower: 1.16.5 was released a wee bit ago, brew should have been updated but there may have been a snag
<lazypower> Let me run another update, make sure i am indeed on -HEAD
<lazypower> Here comes 1.16.5 - it made it in.
<mgz> lazypower: if the issue is what it appears to be, nothing has changed in 1.16.5
<mgz> if you can not use an EBS image, everything should be fine
<lazypower> Well my concern is the volume for my MongoDB BSON data globs. Those need ot reside on a disk larger than 8gb. Let me poke around in the charm store and see if there's a related charm for mapping extra disk space.
<lazypower> I dont like the idea of having it live in ephemeral storage. If the box reboots, poof goes the data
<mgz> there are certainly charms that add extra (persistent) even storage though hacks for use with dbs etc
<mgz> I'm not sure of a good one to point you at, the ones I've seen are pretty hairy
<lazypower> Yeah thats why I avoided them initially
<lazypower> So i completely understand where you're coming from there.
<mgz> marcoceppi: have we got any charms/helpers that do sane things with persistent storage?
<lazypower> Ideally i can do this manually - but when someone comes behind me ot modify this tech stack, I'd like it to be as straight forward as possible. If there are hidden things that weren't performed by juju, chances are they will assume it comes that way out of the box.
<marcoceppi> mgz: not really, we don't have a consistent persistent stoarge story within juju. The best we have is using like NFS or gluster to string servers as storage
<jcastro> marcoceppi, when doing these README updates, should I care about line wrapping at 80 or not?
<marcoceppi> jcastro: no, it gets parsed either way
<marcoceppi> jcastro: I just noticed on the merges
<marcoceppi> why are you using h2 instead of h1 for headers in the README?
<marcoceppi> (## vs #)
<jcastro> # Looks too big
<jcastro> and the title on the GUI is like the H1
<lazypower> I did the same thing Jorge. Using h2's for my sub-headers and h1 for the charm title
<jcastro> like if you move to the other tabs in the GUI
<jcastro> for the non readme sections, they're H2ish
<marcoceppi> jcastro: cool
<jcastro> marcoceppi, when doing the audit on mysql I get this
<jcastro> W: config.yaml: option vip does not have the keys: default
<jcastro> I can probably fix that by setting the proper key right?
<marcoceppi> jcastro: yeah, vip needs a default key in the config.yaml, and it needs to be set to empty string ""
<jcastro> ok
<jcastro> since that changes something that isn't a readme I will MP that one
<marcoceppi> jcastro: ack, thanks
<marcoceppi> jcastro: that'll allow me to test to make sure "" is acceptable as a default
<jcastro> I think it's '' isn't it?
<jcastro> hmm, this file seems to use " and ' interchangeably
<marcoceppi> jcastro: it's interchangeable
<jcastro> ok
<jcastro> I wonder if we should standardize?
<jcastro> at least within the same file?
<marcoceppi> jcastro: we should have the GUI render everything in the README h1 tags smaller
<marcoceppi> IMO
<jcastro> yeah it wasn't something I did on purpose
<jcastro> it was just "oh, the readme will be part of a bigger page, so start as a subheading"
<marcoceppi> jcastro: meh, doesn't matter either way
<jcastro> well, decide now
<jcastro> because I've done 2
<marcoceppi> jcastro: Okay, well we can never assume the readme is going to be part of a larger page, it's its own document and should be formatted as such
<jcastro> also, am I going crazy or was `juju add readme` real?
<jcastro> ok, I'll update the 2 charms now then
<marcoceppi> everything else should bend to it's will
<marcoceppi> jcastro: it's being added, juju charm add readme
<marcoceppi> 1.2.4
<marcoceppi> jcastro: I'll patch the README too, no need to MR
<jcastro> the template you mean?
<jcastro> ok I'll do mysql and ubuntu
<marcoceppi> jcastro: yeah, the template
<marcoceppi> since I'm already there rummaging around
<jcastro> indeed
<mxc> so i finally "solved" my azure issue... migrated to AWS
<mxc> but, quick question about configuration, shouldn't:
<mxc> > juju get mongodb
<mxc> ERROR service "mongodb" not found
<mxc> show me the config file?
<marcoceppi> mxc: yes, is mongodb deployed and in juju status?
<marcoceppi> jcastro: 1.2.4 charm-tools uploaded to ppa, should be built soon
<mxc> ahh, no, not yet
<mxc> I was trying to get the scaffolded config file
<mxc> thanks marcoceppi
<marcoceppi> mxc: yeah, that queries the deployment, to get the config you'll need to either download the charm or look online
 * marcoceppi makes a bug to add juju charm config <charm>
<mxc> ok, got it.
<jcastro> hey
<jcastro> that sounds like an awesome idea though
<mxc> may be a good idea to add a note about that in the docs..
<jcastro> get config options even if it isn't deployed
<jcastro> juju info config
<jcastro> juju info readme
<jcastro> etc.
<mxc> please and thank you
<jcastro> sorry, I mean charm info config, charm  info readme
<mxc> if i wanted to work on that, i'd need to create a launchpad account, install bzr, and relearn bar rigt
<marcoceppi> jcastro: yeah, created this: https://bugs.launchpad.net/charm-tools/+bug/1260419
<_mup_> Bug #1260419: add config key for listing configuration of a charm <Juju Charm Tools:Triaged by marcoceppi> <https://launchpad.net/bugs/1260419>
<marcoceppi> mxc: for the most part, yes
<jcastro> yeah that way you can read up on the options, since you have to wait for the instance to fire up anyway
<marcoceppi> jcastro: def, probably going to make that a 1.3.0 feature
<mxc> part me of wishes canonical would surrender and move to github
<marcoceppi> since juju charm info <charm> already exists, I didn't want to make juju charm info readme <>
<marcoceppi> too much typing
<marcoceppi> mxc: I used to mirror charm-tools and amulet on github, but it's too much work to be able to accept merge proposals from both sources :\
<jcastro> we have mirrors of the charms in github currently
<mxc> marcoceppi: i know..  trying to have it both ways is a monstrous pain in the ass..  i just have this hopeless hope that shuttleworth gives up and moves everything to github
<mxc> is there a way to use a file besides .juju/environments.yaml to bootstrap?
<natefinch> mxc: no
<mxc> ok, thanks
<jcastro> hey marcoceppi
<jcastro> so I am unofficially going to also consider warnings as bugs as part of the audit
<jcastro> if I'm going to go through each one, might as well get bang for the buck
<marcoceppi> jcastro: yeah, warnings are bugs
<marcoceppi> errors means they shouldn't even be in the store
<jcastro> ack
<marcoceppi> jcastro: 1.2.4 has landed, feel free to update
<jcastro> ON IT
<jcastro> arosales, https://pastebin.canonical.com/101920/
<arosales> jcastro, thanks
<jcastro> bbiab, new kernel
<marcoceppi> jcastro: charm add readme workin' okay?
<jcastro> I haven't used it yet
<jcastro> the last 2 readmes I did were mostly complete
<jcastro> trying it now
<jcastro> marcoceppi, hey so
<jcastro> if we want to make new charms pass tests
<jcastro> where can I see where my charm's tests results are?
<jcastro> like, show me an example of a charm that is flunking its tests
<andre__> hi
<jcastro> marcoceppi, charm add readme works awesome btw
<marcoceppi> jcastro: no where, atm, but I'm not saying we should require to pass, we should have a policy that charms should have tests
<jcastro> true
<marcoceppi> we should have a testing infrastructure up early Jan
<jcastro> hey so what do you tell people now  when they submit but they don't have tests
<marcoceppi> mid-early jan
<Guest97524> I am trying to deploy using juju but I cannot do more than bootstrap
<jcastro> Guest97524, what happens?
<Guest97524> can anybody help me please?
<marcoceppi> jcastro: I'm saying, everything in the queue gets grandfathered, added to audit, and commented that tests will be a req. Everything else going forward, after udpating the docs, we fail review because of no tests
<Guest97524> so, appearentely juju bootstraps successfully
<jcastro> right
<jcastro> ok so what we need to do is propose "every new charm from now on must include tests" as policy
<marcoceppi> Guest97524: what happens when you try to deploy? can you run deploy with --debug --show-log
<jcastro> marcoceppi, but does it make sense to do that now before the infra is up?
<jcastro> maybe I can strongly hint that that's coming
 * marcoceppi shrugs at jcastro
<jcastro> ok
<jcastro> I'll send a strawman to the list for input
<marcoceppi> jcastro: cool
<Guest97524> but, when I try to run juju status, it keeps saying: connection refused (--debug flag)
<jcastro> basically, new charms will include tests, deal with it.
<jcastro> Guest97524, did you wait for the bootstrap to come up first?
<marcoceppi> Guest97524: that means bootstrap likely failed, what provider are you using
<jcastro> that usually takes a few minutes
<Guest97524> I mean, bootstrap doesn't report any errors, even with debug and show-log
<Guest97524> I'm using it to deploy on a MaaS environment
<marcoceppi> Guest97524: bootstrap is an asyncronous process, it could fail in certain ways
<marcoceppi> Guest97524: ah, do you see a node provisioned in you maas master?
<Guest97524> the MaaS controller allocates a random machine, but juju doesn't install anything on it
<marcoceppi> Guest97524: can you see if there is anything in /var/log/cloud-init* ?
<arosales> marcoceppi, jcastro I am a +1 for tests in charms and I acknowledge that existing charms should be grandfathered
<marcoceppi> on the maas machine
<Guest97524> and there's not even a juju log in /var/logs
<arosales> but we should promote the audit to have all charms with test and encourages maintainers to add tests
<arosales> going forward policy review should have a check for tests
<arosales> jcastro, to confirm you are going to propose to the list as policy, correct?
<jcastro> writing it up now
<marcoceppi> Guest97524: right, because it likely failed during provisioning. Is there a cloud-init log?
<arosales> jcastro, re your paste bin can we also get the Blueprint sync'ed up with the effort and process to reference in your post
 * jcastro nods
<Guest97524> there is a cloud-init log
<marcoceppi> Guest97524: can you pastebin that log to http://paste.ubuntu.com ?
<Guest97524> apparently without any errors
<jcastro> https://blueprints.launchpad.net/juju-core/+spec/t-cloud-juju-charm-audit
<jcastro> this one  right arosales?
<Guest97524> sure: http://paste.ubuntu.com/6563207/
<arosales> jcastro,  ya  I think that is our latest :-)
<marcoceppi> Guest97524: something's wrong. What version of juju are you using?
<arosales> jcastro, I would also specifically spell out in your post the main points to review in the audit and tools to help do so (ie charm tools)
<Guest97524> I am using version 1.16.5
<marcoceppi> Guest97524: and what version of MAAS?
<marcoceppi> Guest97524: Are you using the one from the cloud archive?
<Guest97524> my client machine is a saucy release, while the maas controller and machines are precise release
<arosales> jcastro, the points to review to ensure folks know what a readme should look like (include example usage), description about the charm, icons, tests, passes proof, etc
<Guest97524> maas version: 1.5.4
<jcastro> arosales, yeah, the issue is that the email is getting long
<jcastro> arosales, I was thinking of just adding all of those things to the review policy instead
<Guest97524> I got juju from ppa repository (ppa:juju/stable)
<jcastro> which is where it should be anyway
<arosales> jcastro, I'll fire up a pad
<arosales> jcastro, policy should have it for sure.
<arosales> perhaps put the details in the blueprint
<arosales> and reference it there. .  .
<jcastro> yeah
<jcastro> good idea
<jcastro> I'll do that
<arosales> jcastro, thanks
<marcoceppi> Guest97524: latest maas is 1.4
<arosales> jcastro, I am updating http://pad.ubuntu.com/bxNaItLUMi from your initial thoughts
<Guest97524> 'sudo maas --version' gives me 1.5.4, updated it today
<Guest97524> it is strange because MaaS allocates the machine, but nothing happens on it
<marcoceppi> Guest97524: It's not getting the user-data which drives cloud-init to complete the setup
<arosales> jcastro, I updated the perms on the ss to be open to all to edit.
<jcastro> marcoceppi, pretend I want to get started writing tests for my charm, you send me to ... ?
<marcoceppi> jcastro: the docs I'm writing
<jcastro> marcoceppi, when will you have those? ballpark?
<marcoceppi> eow
<arosales> jcastro, http://pad.ubuntu.com/bxNaItLUMi looks good
<arosales> jcastro, to confirm you are going to reconcile the blueprint,  propose testing to the list, and email the list on the Great Charm Audit of 2014, correct?
<jcastro> testing has been proposed
<jcastro> finishing up the pad now, will reconcile the blueprint and then send to list in about ~10
<jcastro> to finish up all those things
<arosales> jcastro, thanks!
<arosales> no escaping the The Great Charm Audit of 2014 now
<dpb1> jcastro: I would like to write some tests for my charms, but I'm having trouble finding out how to write a juju test at all.  I understand how to write python tests, but not how to write a juju test.  other than to come up with my own harness.
<jcastro> dpb1, heh, marco is in the process of writing that document right now
<jcastro> should be ready tomorrow
<jcastro> marcoceppi, do you have a TLDR for dpb1 so he can get started?
<lazypower> dpb1: there is ane xisting document about charm testing. Have you seen it? https://juju.ubuntu.com/docs/authors-testing.html
<lazypower> *existing
<marcoceppi> lazypower: dpb1 that docs just go over some bash stuff
<marcoceppi> dpb1: I can show you a few example tests I've written if that helps
<dpb1> marcoceppi: would love to see that.
<marcoceppi> dpb1: here's an example wordpress test https://gist.github.com/marcoceppi/7727543
<dpb1> lazypower: I'll look that over.  I've seen it before, but maybe it has more content now.
<marcoceppi> dpb1: there's also amulet.PASS and amulet.FAIL statuses you can raise to denote the state of the test
<dpb1> marcoceppi: I attemted to use amulet, but ran into issues with subordinates, btw.  I haven't narrowed down the cause yet.
<marcoceppi> dpb1: here's another example: https://gist.github.com/marcoceppi/6779616
<dpb1> marcoceppi: when I do, I'll let you know.
<marcoceppi> dpb1: which subordinate? ones you're deploying or the ones it creates?
<dpb1> marcoceppi: when i attempted to relate them.  It had some namespace type of issues.
<dpb1> the...
<dpb1> sentinels.
<marcoceppi> dpb1: yeah, juju broke amulet for a while
<marcoceppi> dpb1: that's been patched
<dpb1> ok... I'll give it another shot
<marcoceppi> I believe since 1.16.1
<dpb1> ok
<dpb1> jcastro: marcoceppi: I'll give it another shot.  But that was the first thing that came into my mind with the "line in the sand" email, is I didn't really know how to do it yet. :)
<marcoceppi> dpb1: yeah, I'm writing docs to dive in to amulet stuff more, as well as improving the generic testing page
<dpb1> cool
<jcastro> dpb1, yeah I wanted to get that discussion started too
<jcastro> so marco can go "see how easy it is?" as a follow up
<dpb1> OK, looking forward to the improvments.  I'll give it another shot and get you something specific back if I hit issues.  Thanks.
<jcastro> marcoceppi, actually, if you're not going to land that document today it doesn't hurt to reply to my mail with "here's a tldr" with those examples, and just let people know you'll have it ready tomorrow
<marcoceppi> dpb1: thanks! any feedback, bugs, whatever, is appreciated. I'm looking to pump a lot of the feedback in to amulet to make it better
<dpb1> marcoceppi: great! :)
<dpb1> marcoceppi: first question: how do I add the charm from my branch? "d.add('mysql')"
<marcoceppi> dpb1: just add it as you would, the framework intercepts it and will deploy from local for a matching name
<dpb1> marcoceppi: ok... let me try
<marcoceppi> dpb1: if you wanted to deploy a same name charm, you should use a full cs URL
<dpb1> marcoceppi: and to test something *on the unit*, I should call out to juju ssh?
<marcoceppi> dpb1: at the moment yes, there's an exec endpoint but it's not stable yet
<dpb1> ok
<marcoceppi> dpb1: let me check, I may have landed the exec already
<marcoceppi> dpb1: yeah, so the "run" api endpoint exists in the sentry, but it's not in the amulet library, I'll make sure that gets released tonight
<dpb1> marcoceppi: sweet, I'll look for it
<marcoceppi> dpb1: yeah, I'll mail the list when the new amulet version drops, docs will co-incide with that
<dpb1> k
<dpb1> marcoceppi: so, here is my first attempt:  I installed amulet via apt-get install amulet from the stable ppa  http://paste.ubuntu.com/6563839/
<marcoceppi> dpb1: is swap your charm? Looks like it's not loading from the local branch
<marcoceppi> dpb1: the test looks good though, let me file a bug and look into local branch switching
<dpb1> marcoceppi: yes, it's a new subordinate that just adds swap to a system
<dpb1> I put up a review for it, but was going to use it as a test bed for... writing an amulet test. :)
<marcoceppi> dpb1: yeah, I see the problem in the code. I'll have a new release out tonight. Thanks for being a guiena pig ;)
<dpb1> marcoceppi: np.  I'll circle back around tonight when I see it and give it some more testing.
<marcoceppi> dpb1: many thanks!
<mxc> is there a way to fine tune the security group settings on EC2?  For example, if i spin up some charms, juju defaults to opening up 22, 17070, and 37017 to 0.0.0.0
<mxc> i thought the "idea" of juju relations was that it only opens the ports it needs to and only to the other machine in the relation
<mxc> this seems to be the only option: http://askubuntu.com/questions/156715/can-i-specify-tighter-security-group-controls-in-ec2
<mxc> next question, has anyone deployed mongodb with juju and enabled the mongo monitoring service?
<marcoceppi> mxc: lazypower was looking in to that
<mxc> woohoo
<mxc> lazypower: if you;re around and want to chat MMS, i'd be happy to push any work I do on it back upstream
<lazypower> Surely. I'm working on another charm but i'm certainly available
<mxc> msg ok?
<lazypower> mxc: my thought was to build MMS into its own subordinate. Its a python app and not packaged as part of MongoDB core. It diverged earlier this year.
<lazypower> surely
<mxc> actually, never mind, this may be useful to others
<mxc> lazypower: i saw that it diverged.  the mongodb config though has placeholders for some mms-fields
<mxc> lazypower: i was kind of hoping that it was built in to the charm, but i see its not
<lazypower> According to Jira those are to be treated as leftover artifacts from the exploratory dev cycle.
<lazypower> The placeholder config options do nothing. The daemon actually skips them
<lazypower> Now, I can see why we would want to put it into the mongodb unit, however, the MMS service was meant to run from anywhere and monitor any MongoDB installation that you have valid connection credentials for. There are performance tuners that want every last drop of system resource to go to the MongoDB Daemon itself. My co-worker is like that. We ended up sticking MMS on one of our Jenkins slaves that doesn't power down.
<lazypower> </anecdotal>
<mxc> can you think of any similar, subordinate service charms to use as a skeleton?
<lazypower> Subordinates are surprisingly simple to write. I wrote a papertrail charm that sets up papertrailapp's gem for log monitoring. Its somewhat similar.
<lazypower> in a kinda not really sorta way
<lazypower> marcoceppi: can you think of any subordinate services that compliment a parent charm that mxc could use as a guide?
<mxc> papertrail could be close enough
<lazypower> mxc: preference between github or launchpad
<mxc> hugely for github
<lazypower> https://github.com/chuckbutler/papertrail-charm
<mxc> thanks
<lazypower> Wait, the readme is outdated here
<lazypower> let me see whats up with that
#juju 2013-12-13
<mxc> the mms charm will be at github.com/docmunch/mongo-monitoring-service-charm
<mxc> (mms charm seems potentially ambiguous)
<lazypower> Depends on how you present the information to the user. Maybe open a MR on the mongodb charm once the subordinate is approved by charm review to mention that it exists.
<lazypower> unless you mean just using the acronym, in which case, ideed. It could be installing soggy waffles for all i know.
<mxc> yea, i meant MMS may not be super clear
<lazypower> Agreed. Less of the jargon, more of the substance.
<lazypower> ooo you're a haskell guy huh?
<lazypower> *person
<mxc> yup
<mxc> docmunch is haskell in the back, typescript + angular in the front
<lazypower> I'll have to pick your brain someday
<mxc> are you a haskeller?
<lazypower> I'm a polyglot. I sit in many different camps :)
<mxc> very few haskellers write nothing but haskell
<mxc> we call them "academics"
<lazypower> I guess more to the point, not yet - but will be soon if my career continues on its current trajectory
<mxc> what do you mean?
<lazypower> I'm writing ruby and C# mostly for my day job, and we are starting to get into larger data sets. Ruby is losing performance and I really dont enjoy the MS Toolchain for licensing reasons. So I'll be looking for something more suited to what i'm doing. Haskell and Go come to mind.
<lazypower> Its that or find someone that knows R - but this is all offtopic.
<mxc> brb
<marcoceppi> lazypower: mxc Jenkins and Jenkins-lxc
<lazypower> For charm testing?
<marcoceppi> jenkins-lxc adds LXC container support to Jenkins, so it's complimentary
<lazypower> Ah! good call.
<lazypower> I have a question about best practices on charming - This particular application depends on MongoDB. Is it a good idea to have the charm by default install mongodb and consume the local resource, but also support using an external mongodb server through relation, that would strip the local mongodb server?
<lazypower> or should I pick a road and stick with it?
<mxc> marcoceppi: thanks
<mxc> marcoceppi: while I've got your attention, did you see my security group question from about 3 hrs ago?
<marcoceppi> mxc: I did, but I was just leaving
<marcoceppi> mxc: that answer wont work for juju > 1.0
<mxc> sorry to bother you then.  thanks for that heads up
<marcoceppi> mxc: no, I was leaving when you asked 3 hours ago
<marcoceppi> I'm back now
<marcoceppi> mxc: At this time there's no way to close sec group rules without doing so manually
<mxc> hm
<marcoceppi> You don't need to expose anything for units to talk to eachother in network, but by defautl we spawn ssh on port 22, and those other two ports are for the Juju API
<mxc> if i close juju-amazon, will juju try to reopen it?
<mxc> marcoceppi: my general plan was to run the juju commands from a machine that requires 2FA to ssh into but is in the same security group as the juju worker instances
<marcoceppi> mxc: it shouldn't, afaik it won't actively monitor rules, it simply opens or closes them on your command
<sarnold> since security group features vary so much from provider to provider it might be worth looking to providing your own host-based firewalling via a subordinate charm. yet another item on my too-long todo list :)
<mxc> sarnold: i've been thinking of writing a UFW charm too
<marcoceppi> sarnold: there was some discussion about moving to a machine based firewaller, not sure how far that's gone
<sarnold> mxc: that'd be my first attempt at it, too, hehe :)
<sarnold> marcoceppi: I don't know about _moving_ to it, it feels to me like security group and host-based are orthogonal or, at least, nicely belts-and-suspenders
<mxc> lazypower: so I'm not sure that a subordinate service makes sense for MMS
<mxc> since MMS can be on separate machines and a single MMS agent can monitor multiple mongo instances
<lazypower> But does it make sense to by default deploy the monitoring agent to its own machine?
<mxc> not necessarily
<mxc> if the mongo host dies, it may be better to have MMS on a separate machine to report said untimely death
<lazypower> once the MMS agent connection is severed it instantly goes into panic mode and dispatches notices via your configured channels.
<lazypower> But you bring up an interesting point. If you're running a cluster, and the host housing MMS dies, then you've effectively lost monitoring on teh other machines that are still active.
<marcoceppi> lazypower: can you run mms on multiple mongo machines?
<marcoceppi> rather, mutliple instances of mms?
<lazypower> You can. there's no limit to how many agents you deploy
<mxc> but, MMS is a bit odd in that you can only set the hosts that it monitors in the web console
<mxc> so, my plan is to instruct users to add a host with some internal name, like juju-mongo.internal
<mxc> and then add it to the config
<mxc> and when have the database-relationship-changed hook set the IP address in the /etc/hosts file
<mxc> lazypower: marcoceppi: if you're interested, here's the repo: https://github.com/docmunch/mongodb-management-service-charm
<mxc> i should get it done tomorrow
<marcoceppi> mxc: you can have the charm do that, if it's data you can post to a webform
<mxc> its complicated though, you'd have to log into the site, post the data etc
<mxc> i have a hard jan 1 deadline of getting everything deployed, so for now, i'm going to stick with my /etc/hosts hack
<marcoceppi> mxc: that works, always room to iterate
<mxc> yup
<sekjun9878> Hello
<sekjun9878> Does anyone know why this is happening, and how to fix?: "ERROR juju.state open.go:93 TLS handshake failed: x509: certificate signed by unknown authority"
<sekjun9878> I have tried deleting the environments folder, to no avail.
<ashipika> hi.. is it possible for different services to have relations as peers?
<benji> rick_h__: do you know where the prod .ini file for charmworld is stored?
<benji> hey bac
<benji> pfft
<andre118> Hi, I was here yesterday but meanwhile my internet connection broke...
<andre118> I cannot deploy using juju
<andre118> I can bootstrap a node on a MaaS infrastructure but it doesn't deploy any tools on it
<andre118> can anybody help me out please?
<rick_h__> benji: otp
<andre118> Juju does not show anything wrong using --debug flag while bootstrapping
<andre118> it downloads and uploads (to the bootstrap instance i guess) several tools but doesn't seem to install anything
<andre118> if someone had the generosity to help me I would be very thankful :)
<bloodearnest> any examples in current charms of cronjob setup? In particular the script run by cron would need access to some of the charm's config
<bloodearnest> I guess config-changed could update the crontab to pass some params to the script, but this is tricky in my case as some of the params can be arbitrarily large
<bloodearnest> So, maybe the config-changed needs to update both the crontab and the script
<bloodearnest> Or can I access the charm's config from the cron-executed script? I don't think I can...
<rick_h__> benji: did you find it? I think it's just in the charm
<rick_h__> benji: well, it's generated from the charm.
<rick_h__> using the overrides
<bloodearnest> lemme rephrase my question: can I use config-get outside of a hook?
<andre118> can someone help me with juju deployment?
<andre118> juju isn't installing any tools on the bootstrap node
<andre118> althought the MaaS controller allocates the node
<andre118> what could be wrong?
<marcoceppi> mgz: andre118 isn't getting userdata from juju to cloud-init in maas, where should we debug?
<andre118> after sync-tools, this is the output I get running juju bootstrap --show-log --debug: http://paste.ubuntu.com/6567396/
<andre118> nothing wrong on it
<andre118> is it possible that juju is telling MaaS to bring up a machine, but cannot access it afetwards
<andre118> *afterwards
<andre118> maybe a missconfiguration with the ssh keys?
<marcoceppi> andre118: juju talks to instances via userdata that cloud-init consumes. That userdata has things like the SSH key, what packages to install, etc
<marcoceppi> andre118: for some reason that isn't gettting to the instances, I've pinged some of the developers to see if they can help you debug further
<jcastro> marcoceppi, for fixing charm proof problems, like missing default values
<jcastro> as a general rule, do I just set defaults as blank?
<jcastro> for example in mediawiki it wants a default logo and default admin list
<marcoceppi>  jcastro that's a good general rule, but it still needs to be tested
<andre118> that's strange, as cloud_init log doesn't report anything wrong too, nor anything related to juju.
<andre118> ok, thank you
<marcoceppi> andre118: but it doesn't show that it's running the user data, the log should be a lot longer and very verbose
<jcastro> marcoceppi, ok so I can test by ... deploying and trying to set those configs?
<marcoceppi> jcastro: just deploy and make use it doesn't error our and actually worked as it did before you made the change
 * jcastro nods
<jcastro> my goal is to get all the ones charm proofed and at least bugs filed before you get to them
<marcoceppi> jcastro: <3
<jcastro> marcoceppi, what am I looking for in the deploy --debug to ensure the charm is being deployed from my disk and not the store?
<jcastro> or does the local:mediawiki take care of that for me?
<marcoceppi> local: takes care of that
<dpb1> marcoceppi: did you get anywhere on that amulet hotfix?
<marcoceppi> dpb1: yes, I'm preparing the 1.1 release atm
 * dpb1 nods
<marcoceppi> jcastro: did you change the maintainer for Ubuntu charm?
<jcastro> for which one?
<jcastro> marcoceppi, my local provider isn't destroying containers
<jcastro> it's leaving them behind again
<jcastro> I thought we fixed this?
<marcoceppi> jcastro: yeah, there's a bug, webbrandon ran it on this yesterday
<jcastro> ugh
<jcastro> seriouslhy
<jcastro> this totally breaks local testing for me
<marcoceppi> jcastro: hum, he said he was going to open a bug, I don't see one though
<jcastro> I saw sinzui reopened the original bug
<marcoceppi> oatman had this problem too, but he was able to just delete the /var/lib/lxc/* stuff and it chugged a long
<marcoceppi> it might be a race condition
<lazypower> In several ways I'm sorry to see this, but happy to know its not something i did. My local containers were affected by this bug too when they were left in an error state, and resolved.
<lazypower> the containers refused to be destroyed unless i wiped the entire environment.
<noodles775> marcoceppi: Hi. I'm trying to deploy a charm with amulet, but get "No such file or directory: 'precise/relation-sentry/metadata.yaml'". Any tips for a work-around? (that's on trunk)
<noodles775> http://paste.ubuntu.com/6567514/
<marcoceppi> noodles775: if you branched from lp, LP is no longer the source of trunk
<marcoceppi> noodles775: branch from github, https://github.com/marcoceppi/amulet
<noodles775> k, yes I did branch from LP. I'll try from github. Thanks.
<marcoceppi> noodles775: thanks, I'll move the project under juju/amulet in due time, but marcoceppi will contintinue to mirror the source
<noodles775> marcoceppi: ok, that gives me a different error :P. I'll check back next week. http://paste.ubuntu.com/6567698/
<noodles775> hrm, hangon, let me force python3
<marcoceppi> noodles775: yeah, python3 only :)
<noodles775> marcoceppi: so that gets me back to my original error: http://paste.ubuntu.com/6567724/ :/
<marcoceppi> noodles775: I can't seem to replicate that
<marcoceppi> noodles775: I noticed that it's installed in python2.7
<noodles775> marcoceppi: what's installed in python2.7? juju-deployer?
 * noodles775 checks for a python3-juju-deployer
<marcoceppi> noodles775: oh, sorry
<marcoceppi> noodles775: you're right
<marcoceppi> noodles775: we're shelling out to deployer atm
<marcoceppi> noodles775: do you have latest juju-deployer from ppa:juju/stable?
<noodles775> marcoceppi: the ppa:juju/stable version of juju-deployer isn't newer than the saucy archive one is it? http://paste.ubuntu.com/6567774/
<noodles775> Actually, there is no saucy version of juju-deployer in the ppa. The ~ubuntu13.04.1~juju1 version is apparently Raring.
<noodles775> https://launchpad.net/~juju/+archive/stable/+packages?field.name_filter=deployer&field.status_filter=published&field.series_filter=
<noodles775> er, right. There's no 13.10 one there :) (13.04 is raring)
<marcoceppi> noodles775: i think deployer is sync'd directly to saucy
<marcoceppi> so you should have latest
<noodles775> Yep, as per the paste above 0.2.5-0ubuntu1
<marcoceppi> noodles775: can you pastebin /tmp/amulet-juju-deployer-7pyrwu.json
<jcastro> hey marcoceppi
<marcoceppi> hey jcastro
<jcastro> the mediawiki is missing a start hook
<jcastro> is this something that I can just make a blank file or is there something it should be doing for start?
<jcastro> "I've worked so long without a start hook!"
<marcoceppi> jcastro: yeah, because apache is started during installed, and restarted every other time. Is it a W or an I?
<marcoceppi> technically all hooks are optional, so they should all be INFO not WARN
<jcastro> it's a W
<jcastro> should I file a tools bug?
<marcoceppi> jcastro: yes, it's part of a bigger bug though
<marcoceppi> jcastro: https://bugs.launchpad.net/charm-tools/+bug/1172458
<_mup_> Bug #1172458: proof does not distinguish between poorly-written and unusable charms <charmbrowser> <Juju Charm Tools:Triaged by marcoceppi> <https://launchpad.net/bugs/1172458>
<marcoceppi> can you just update that bug with this information
<marcoceppi> jcastro: I'm going to get that fixed in 1.2.5
<jcastro> ack
<fcorrea> hey there. Anyone here using the postgresql charm with an attached volume? A nova volume in this case
<fcorrea> As far as I could trace it, the charm fails to migrate data from the local storage to the attached nova volume storage because it can't stop the postgres service
<marcoceppi> fcorrea: do you have logs from /var/log/juju/unit-postgresql-*.log ?
<noodles775> marcoceppi: sure - http://paste.ubuntu.com/6568142/
<marcoceppi> noodles775: there should be a /tmp/amulet* directory (actually probably a few, since they don't get cleaned up
<marcoceppi> ...yet
<noodles775> marcoceppi: plenty of them, yes, but it's the /tmp/sentry_* you'd want to see isn't it? It doesn't have the metadata.yaml, as per the error: http://paste.ubuntu.com/6568157/
<noodles775> Or is there something else that might be useful?
<marcoceppi> noodles775: well, that explains that, but I can't duplicate that on this end :\
<marcoceppi> noodles775: something else might be silently failing
<noodles775> marcoceppi: OK, it may be worth trying on a new instance. Otherwise, I'll take a closer look on Monday and send you a pull request :)
<marcoceppi> noodles775: I'm pushing up a few more things for 1.1 and building an apt package for it tonight
<marcoceppi> noodles775: I'd recommend running the packaged version first instead of trunk.
<noodles775> marcoceppi: heh, well I only switched to trunk because the packaged version didn't work. But I'll try the new one (of if it'd help, I can install the current one again and show the error).
<marcoceppi> noodles775: ah! well I want to make sure packaged works for sure. Please ping me if you run into anything
<fcorrea> marcoceppi, I might have as soon as I finish re-deploying my stack :)
<noodles775> marcoceppi: will do. fwiw, here's the (same) error using the current package http://paste.ubuntu.com/6568199/
<marcoceppi> noodles775: thanks, I'll spin up a VM, my workstation is pretty dirty
<marcoceppi> noodles775: I'm running in to other problems now anyways :\
<xnox> i am having trouble with juju-gui =/
<marcoceppi> xnox: what trouble exactly?
<xnox> i'm trying to add: cs:~cjwatson/quantal/wanna-build and cs:~cjwatson/quantal/sbuild/cross charms to canvas.
<xnox> but i fail to get two boxes, up instead both of them are wanna-build charms, and not wanna-build & sbuild
<fcorrea> marcoceppi, from the very beginning up to the failure: http://paste.ubuntu.com/6568257/
<marcoceppi> fcorrea: does the volume appear mounted?
<marcoceppi> xnox: are you deploying those with the gui?
<fcorrea> marcoceppi, yup. It even have some postgresql structure in there
<xnox> marcoceppi: well, it needs postgres as well, so yeah. I was going to make a bundle and then launch it on private openstack.
<fcorrea> marcoceppi, http://paste.ubuntu.com/6568278/
<marcoceppi> xnox: are you using the jujucharms.com sandbox?
<xnox> marcoceppi: but without being able to add three charms, join them, and package as a bundle i'm not sure how well this will play out.
<xnox> marcoceppi: yes, i'm on that web-site.
<xnox> in the build tab.
<marcoceppi> xnox: have you tried clearing cache and reloading the page? If so I'll grab someone from the GUI team to help get debug information from you
<xnox> marcoceppi: actually i think something weird with the charm.
<marcoceppi> xnox: oh?
<xnox> marcoceppi: when i select sbuild charm it redirects into a wanna-build charm.
<marcoceppi> xnox: I don't see cs:~cjwatson/quantal/sbuild in the gui
<xnox> marcoceppi: let me fork the charms and check what's going on.
<marcoceppi> fcorrea: unfortuantely the log doesn't say where exactly it failed, let me look at the hooks
<xnox> marcoceppi: yeah, why isn't it?
<marcoceppi> xnox: no idea, is the branch name lp:~cjwatson/charms/quantal/sbuild/cross or lp:~cjwatson/charms/quantal/sbuild/trunk ?
<fcorrea> marcoceppi, exactly. While debugging the config-changed hook, I could check that if fails while trying to stop the server so the data can be migrated
<marcoceppi> fcorrea: but the output of that log shows it stopped successfully
<fcorrea> marcoceppi, for some reason, I can't stop the server with "sudo service postgresql stop" for example
<marcoceppi> which is odd
<xnox> marcoceppi: /trunk does not exist, /cross is the right one.
<marcoceppi> xnox: I think charmworld only imports charms that end in /trunk let me find someone from that team to confirm
<xnox> marcoceppi: also there doesn't seem to be saucy series for charms =(
<fcorrea> marcoceppi, right, which I guess is misleading it was still up. And now there only way to stop the service is by killing it
<fcorrea> marcoceppi, lemme check the upstart logs
<marcoceppi> fcorrea: cool
<marcoceppi> xnox: you should be able to push to lp:~user/charms/saucy/charm/trunk
<marcoceppi> I just dont' think we have any saucy charms
<marcoceppi> xnox: we tend to recommend people write charms for LTS
<marcoceppi> so the majority are in precise
<xnox> marcoceppi: bzr push lp:~xnox/charms/saucy/sbuild/trunk
<xnox> bzr: ERROR: Permission denied: "~xnox/charms/saucy/sbuild/trunk/": : No such distribution series: 'saucy'.
<xnox> And here: https://launchpad.net/charms/+series
<xnox> there is no saucy series.
<marcoceppi> xnox: let me add that series
<fcorrea> marcoceppi, nothing in the logs. I'm wondering if the upstart job is getting confused with something data that could have changed while moving the data out to the nova volume and it fails when it tries to kill it
<marcoceppi> jcsackett: does charmworld import personal branches that don't end in /trunk? IE: lp:~cjwatson/charms/quantal/sbuild/cross ?
<xnox> marcoceppi: ok, make sure you don't break ubuntu series though ;-)
<fcorrea> marcoceppi, it's easy to replicate though. Just deploy postgres, attach the nova volume, juju set postgresql volume-map="{postgresql/0: vol-000001}", juju set postgresql volume-ephemeral-storage=False, juju resolved --retry postgresql/0
<fcorrea> marcoceppi, after that you should end up with a die hard postgresql server
<fcorrea> impossible to stop it
<marcoceppi> why are you running resolved --retry ?
<fcorrea> marcoceppi, the unit goes into an error state if I change the volume-map and the volume-ephemeral-storage is still True
<marcoceppi> fcorrea: ah, well I can help you there
<fcorrea> marcoceppi, then when I set it to False, I retry it but then it goes into error state on config-changed because of the problems described above
<marcoceppi> juju set postgresql volume-map="{postgresql/0: vol-000001}" volume-ephemeral-storage=False
<marcoceppi> fcorrea: you can send multiple key/val pairs at once
<fcorrea> marcoceppi, ahh
<marcoceppi> maybe that's why it's in this weird locked state?
<fcorrea> well, I'll find out in a sec
<marcoceppi> fcorrea: cool, if so, file a bug against the charm, there should be some safe guards in place to prevent this
<jose> marcoceppi: hey, I'm trying to work on the postfix charm now
<fcorrea> marcoceppi, will do
<marcoceppi> jose: awesome
<marcoceppi> fcorrea: if it doesnt' work still, stub, the author, might be able to help
<fcorrea> marcoceppi, awesome. will ping him for sure if I still have issues with it
<fcorrea> marcoceppi, thanks btw :)
<xnox> marcoceppi: after pushing a new branch, how long does it take to appear in jujucharms / manage.jujucharms.com ? i pushed lp:~xnox/charms/trusty/wanna-build/trunk lp:~xnox/charms/trusty/sbuild/trunk but http://manage.jujucharms.com/~xnox is empty
<marcoceppi> xnox: every 15 min on the nose
<marcoceppi> xnox: so in about 8 mins
<jose> marcoceppi: hey, in my charm, what are cacert.pem and cakey.pem?
<marcoceppi> jose: you tell the user to generate them as part of the instrucitons, they're the SSL certs
<jose> can they be transmitted as base64 strings too?
<xnox> marcoceppi: are trusty charms imported at all?
<marcoceppi> jose: yeah
<marcoceppi> xnox: I hope so.. jcsackett^?
 * xnox is failing to find any trusty charms
<jose> xnox: hey, note that your name as displayed on your IRC info is still the old one :)
<jose> (real name string)
<xnox> jose: ha, should fix it. thanks.
<sarnold> :)
<xnox> jose: sarnold: not sure, i think my znc proxy must reconnect to update it. but i don't want to loose uptime =)
<xnox> meh, will restart it on a sunday or something.
<jose> :P
<jose> marcoceppi: hey, do you know if there's a way to see if a script has been ran at least one time?
<xnox> marcoceppi: looks like they are on manage.jujucharms.com now, but not in jujucharms.com
<xnox> marcoceppi: clicking on any of the two on http://manage.jujucharms.com/~xnox ends up with 404
<jcastro> marcoceppi, mediawiki done
<jose> marcoceppi: fix pushed
<marcoceppi> hey benji, so is trusty not in the GUI as a series yet?
<marcoceppi> GUI/manage.jujucharms.com
<fcorrea> marcoceppi, sending multiple key/values worked....like a charm. Thanks
<benji> marcoceppi: that may be the issue
<fcorrea> marcoceppi, it would be nice if those two config parameters could only work together so that when a user passes a single value, it noops. But anyways
<marcoceppi> fcorrea: thanks, can you open a bug against postgresql that it should error out if one is set and not the other?
<fcorrea> marcoceppi, heh, indeed
<marcoceppi> fcorrea: https://bugs.launchpad.net/charms/+source/postgresql
<marcoceppi> benji: when you're looking, could you make sure both trusty and saucy are valid GUI/manage.jujucharms.com series?
<benji> marcoceppi: from a cursory investigation, it doesn't look like the GUI has any hard-coded series, so that shouldn't be the source of the issue
<marcoceppi> benji: so the API has the trust charm, https://manage.jujucharms.com/api/3/charm/~xnox/trusty/sbuild
<marcoceppi> xnox: oh, it's showing now. Maybe it was just a cached response: https://manage.jujucharms.com/~xnox/trusty/sbuild
<marcoceppi> xnox: https://jujucharms.com/fullscreen/search/~xnox/trusty/sbuild-0/?text=sbuild
<marcoceppi> benji: this might be a moot point then
<xnox> execcelnt
<xnox> marcoceppi: not sure why it's polling instead of doing push updates, it's not like charms are updated at hundreds per second.
<marcoceppi> rick_h__: while you're here, can you confirm that charmworld won't ingest charms that don't end in /trunk ? IE: lp:~cjwatson/charms/quantal/sbuild/cross
<rick_h__> marcoceppi: I believe that's the case
<marcoceppi> rick_h__: thanks
<marcoceppi> xnox: LaunchPad doesn't have push notifications
<xnox> marcoceppi: oh, right.
<xnox> marcoceppi: well there are branch rss feeds, but no notifications of new branches indeed.
<xnox> marcoceppi: is there a way to "save" config changes without deploying?
<xnox> or is deploy, actually "save changes"
 * xnox tries.
<marcoceppi> xnox: in the GUI? yeah, saving will deploy and save
<marcoceppi> it's all async'y
<xnox> deploy where?
 * xnox is using website without any providers.....
<marcoceppi> xnox: to the GUI sandbox
<marcoceppi> it creates a mock provider to allow you to stage stuff as if it were an environment
<xnox> ah, i see.
<rick_h__> marcoceppi: xnox it's there, just took a few min for ingestion to get it http://comingsoon.jujucharms.com/sidebar/search/?text=sbuild
<marcoceppi> rick_h__: ta!
<rick_h__> we just got impatient on it, didn't realize it was so new
<xnox> marcoceppi: i think i managed to add postgres, wann-build and sbuild and connect them together.
<marcoceppi> xnox: \o/ see, wasn't that hard ;)
<xnox> marcoceppi: when connecting wanna-build with postgresql it did ask me if I want "db - db-admin" or "db-admin - db-admin" relationship.
<xnox> marcoceppi: now, i'm not sure what that means. i've picked the later one.
<xnox> now i guess all I need to do is launch that bundle into a provider \o/
<marcoceppi> xnox: that means there are multiple relations that are supported between those two charms
<marcoceppi> typically the readme will illuminate which you may want
<xnox> well, wanna-build requires "db-admin: interface: pgsql" so i've picked db-admin/db-admin
<xnox> ah both db & db-admin use smae interface - pgsql
<xnox> right, makes sense that both are offered.
<marcoceppi> xnox: yeah, you made the right choice
<xnox> marcoceppi: bundle exported =) can I commit it into a branch or something?
<marcoceppi> xnox: yes! https://juju.ubuntu.com/docs/charms-bundles.html#creating
<xnox> coool. now back to making another cup of tea to wait for that to propagate =)
<jcastro> marcoceppi, can you vote to dupe this please: http://askubuntu.com/questions/368783/did-not-find-expected-hexadecimal-number-when-bootstraping-juju-on-windows
<xnox> what's the difference between deployer and quickstart?
<jcastro> quickstart is the easy to use frontend that calls deployer
<xnox> ... then why are they in two different packages from two different PPAs?
<jcastro> because both are still in progress in beta with no real releases yet
<marcoceppi> xnox: because they're developed as too seperate tools
<jcastro> though they should both be in ppa:juju
<hatch> quickstart also deploys the gui, opens it and logs in
<marcoceppi> xnox: right quickstart is more...user oriented. deployer is this awesome powerhouse tool that a lot of juju/charm tools tap in to
<jcastro> marcoceppi, I am out of AU votes, I am flagging all the old abandoned pyju questions, can you make sure they get actioned?
<marcoceppi> jcastro: yeah
<jcastro> as a user I hope to never have to use deployer, or even see it
<xnox> hatch: marcoceppi: jcastro: if jujucharms.com clearly gives me instructions to use it, you have users, so you can't pretend it's "in-development" or "beta" or whatever.
<marcoceppi> yeah, it's too featurful for general user consumption imo
<xnox> please make them all available from one ppa, from one package.
<marcoceppi> xnox: I've filed bugs about this, I wish they would stop referring to it
<jcastro> xnox, you are preaching to the choir. :)
<xnox> (e.g. juju-bundle-tools which depends on both)
<marcoceppi> xnox: well quickstart will be in ppa:juju/stable when it's stable, deployer is already in there (and in distro)
<hatch> xnox just because something is public doesn't mean that it's not beta :)
<marcoceppi> quickstart package should just depend on juju-deployer
<jcastro> xnox, mid/early -januaryish is when quickstart should be in the ppa
 * marcoceppi goes to the gui instructions
<jcastro> and closer to being finished
<marcoceppi> xnox: well, to be honest, it shows both ways
<marcoceppi> xnox: it doesn't say you have to install both
 * marcoceppi complients the gui team on cleaning those instructions up
<xnox> marcoceppi: but also failed to say that it is available on my release.
<marcoceppi> xnox: ?
<xnox> marcoceppi: i don't need any ppa's, i can just $ apt-get install juju-deployer.
<xnox> which i found out from this channel =)
<marcoceppi> xnox: well, we can't know that you're on saucy
<marcoceppi> it's only in saucy+, for everyone else you need ppa
<xnox> right, i guess Precise is the better assumption still.
<xnox> local provider is charming =)
<xnox> http://paste.ubuntu.com/6568920/
<xnox> i guess i should be root when deploying? same as for local bootstrap?
<xnox> i think the trusty should be quiried for "daily" images, not "released"
 * xnox ponders where/how to set the cloud image chaanel.
<benji> l8r bac
<jcastro> marcoceppi, ok I've flagged almost every single one, if you close those and vote today all our questions should be up to date
<jcastro> xnox, you only need root to bootstrap
<jcastro> everything else do as non-root
#juju 2013-12-14
<maxcan> lazypower: mms charm.  not fully tested and fails the charm proof, but it does kind of work: https://github.com/docmunch/mongodb-management-service-charm
#juju 2013-12-15
<lazypower> Would anyone have any idea why a command refuses to excute via chef-solo in directory other than whats specified in the recipe?
#juju 2014-12-08
<stub> where do bugs on jujucharms.com go now?
<marcoceppi> stub: https://github.com/CanonicalLtd/jujucharms.com
<stub> marcoceppi: Ta. I also found the charmworld project on Launchpad, configured for accepting bugs, so added it there.
<marcoceppi> stub: charmworld was the old jujucharms.com
<marcoceppi> it's switched teams and what not
<stub> marcoceppi: More bugs to file then :) It is still linked in the footer, and the LP project should point to the external bug tracker.
 * stub files bugs
<marcoceppi> stub: good point, thanks!
<ejat> hi all
<ejat> http://paste.ubuntu.com/9426602/
<ejat> can some one help
<marcoceppi> ejat: have you changed anything in the environments.yaml
<ejat> marcoceppi : nope
<marcoceppi> ejat: fwiw, 1.20.14 was released recently
<ejat> ok ..
<marcoceppi> errr
<marcoceppi> sorry, is being proposed for release
<ejat> let me try update 1st
<marcoceppi> I don't see anything regarding that in the bugfix log though
<marcoceppi> one sec
<ejat> ok ..
<ejat> marcoceppi : another thing ... did juju jitsu still working ?
<ejat> to export n import to another environment ?
<marcoceppi> jitsu hasn't worked for over a year, that's for juju < 0.7
<ejat> opss .. my bad ..
<marcoceppi> ejat: you can still export an environment, it's called bundles
<ejat> so its mean need to load the bundle file using juju-gui ?
<marcoceppi> ejat: yeah, that's the new "export/import" feature
<ejat> need to up the juju-gui at the another environment 1st then import the bundle ?
<ejat> brb.,,
<ejat> marcoceppi: so now .. no automatic way to transfer the bundle to another environment?
<marcoceppi> ejat: no
<ejat> ok noted :)
 * ejat catching up things back 
<ejat> marcoceppi: im using 1.21-beta3-utopic-i386
<ejat> should i file a bug?
<ejat> sinzui : thanks
<ejat> marcoceppi: http://curtis.hovey.name/2014/06/12/migrating-juju-to-hp-clouds-horizon/
<ejat> its because of the region .... poor me ..
<icerain_> hi there
<icerain_> does anyone has experience with setting up openstack via juju
<marcoceppi> icerain_: a bit, what's up?
<icerain_> we try to set up an openstack using the multiinstall script
<icerain_> but the process always get stuck due bootstrapping juju
<icerain_> always get permission denied cause of the ssh keys
<icerain_> first we set up a ubuntu server and then a maas
<icerain_> commissioned a node for juju
<icerain_> and thats it
<icerain_> Remote host authentication has changed is the error message
<icerain_> actually i think we make an error between installing maas and juju
<icerain_> we have 6 nics per node and use eth4 for external and eth5 for internal coomunication
<marcoceppi> icerain_: I think it might be best if you summarize your setup, what you've done so far, the errors  you're getting and either post on http://askubuntu.com or email them to juju@lists.ubuntu.com
<marcoceppi> I'm not too experienced with openstack and juju, but by having them recorded I can help find the people who can answer your questions
<icerain_> kk, thank u anyway
<hackedbellini> hi! Can someone help me with a little problem? I have a relation between one unit a postgresql one. The machine where postgresql is in changed ip. Juju recognized it, but the relation is still getting the old one, making that service upadate it's config file to the old connection ip
<hackedbellini> how can I force the relation to receive that new ip?
<lazyPower> hackedbellini: thats dependent on how its receiving the address - is it looking at remote-get private-address?
<hackedbellini> lazyPower: let me take a look on the charm code, just a src
<hackedbellini> sec*
<hackedbellini> lazyPower: it's using relation-get
<lazyPower> hackedbellini: which provider is this?
<lazyPower> hackedbellini: and juju version would be helpful as well
<hackedbellini> juju version 1.20.1
<hackedbellini> provider? It's a relation between postgresql (last charm version) and gerrit (a local one I cloned before canonical-ci became private)
<hackedbellini> lazyPower: it gets the hostname by using charmhelpers relation_get: relation_get('host', rid=relid, unit=unit)
<lazyPower> hackedbellini: ah that sounds like its using a cached config thats being sent over the wire - and it may be sending a full postgresql connection string - i'm not 100% familiar - are you in a debug-hooks session and can verify?
<lazyPower> if youare - just running `relation get` in the relationship context will give you teh full output of whats coming over the wire, and give us a good frame of reference for debugging
<lazyPower> to isolate if this is a juju bug or a postgresql charm bug
<hackedbellini> lazyPower: how can I enter a debug-hooks session?
<lazyPower> hackedbellini: juju debug-hooks service/#
<lazyPower> this will place you in a tmux session - you'll want to open another terminal and issue the command `juju resolved --retry service/#`
<lazyPower> assuming it wsa the relationship hook that failed - it should place you in the context of that relationship hook.
<hackedbellini> lazyPower: it's not failing the service, unfortunately
<lazyPower> hackedbellini: ok - so we have to go a bit deeper - do you have time to run through a another deployment of your service thats consuming postgres?
<hackedbellini> lazyPower: what do you mean?
<lazyPower> hackedbellini: adding another unit - attaching a debug-hooks session to that unit thats under deployment to obtain the data.
<lazyPower> actually 1 moment, there may be a quicker way to do this
<lazyPower> let me check the manpages
<lazyPower> hackedbellini: looking over the code it appears this is coming from some kind of cached config - i'm having trouble locating where master_host is getting set as its a parameter, but thats whats being assigned to the host= var
<lazyPower> hackedbellini: and this is with relation to postgresql clustering - it appears it does an internal quorem and sets this ip - which is the culprit - so its a bug against the postgresql charm
<hackedbellini> lazyPower: hrmmm, I see. I'll take a look at the postgresql charm too to see if I can help you find where it's storing the cache
<lazyPower> hackedbellini: can you file a bug against the postgresql charm about this? as I can foresee this being a major thorn in the side of any postgresql admins that experience an outage.
<lazyPower> if we can't get to it, i bet stub can iron this out in a an iteration or two
<hackedbellini> lazyPower: now that I saw, not only that... postgresql still have the gerrit's old ip on its pg_hba
<stub> If changing the machine's ip does anything, it will call the config-changed hook. I don't think relation-changed hooks get triggered, so the new ip will never be published
<stub> db_relation_joined_changed is calling hookenv.unit_private_ip() to get the ip, so it isn't cached afaict.
<lazyPower> ah ok
<hackedbellini> stub: so what can I do in this situation to force postgresql and gerrit to get their new ips?
<lazyPower> i didn't get very deep in the code - i'm multi-tasking this, sorry about the red herring - your analysis is sound stub.
<lazyPower> i can see that being the case.
<stub> I may be out of date though. Last I heard, you can't change a units ip address for any service.
<hackedbellini> stub: really?
<stub> hackedbellini: like I said - I might be out of date.
<stub> if you change the relation at the client end, it will invoke the server's relation-changed hook and the new host will be published.
<hackedbellini> stub: hrm ok. But well, some ips changed =P. How can I change the "cache" that's holding those ips?
<jcsackett> lazyPower: hey man, do you happen to know of any way to retrieve an environment password if you've lost your jenv files &c? this is on a a machine i still have non juju ssh access to (manual provider).
<stub> juju run --unit=client/0 relation-set -r db:42 something=whatever
<lazyPower> jcsackett: oo good question - I think its stored in mongodb but i dont have the foggiest idea where that document would be.
<lazyPower> jcsackett: and i would imagine its salted in the database
<hackedbellini> stub: hrmmmm, lets try that
<stub> hackedbellini: Or you can just explicitly set the host attribute on the relation using juju run too
<jcsackett> lazyPower: yeah, that's what i was afraid of. i have a whole owncloud and other stuff setup i don't want to get rid of, but i now have no juju access to it...had an HD die a few weeks ago and just now realized that juju env files weren't part of my backup...
<stub> If I am out of date and you can change a units ip address after deployment, please file a bug :)
<lazyPower> jcsackett: Really sorry to hear that - a core dev might be able to help you recover that info though.
<hackedbellini> stub: the "-r db:42". What does that mean?
<jcsackett> lazyPower: good point. i'll bug core. thanks.
<hackedbellini> stub: juju recognized the ip change, but the realation is still getting the old one... maybe I need to run relation-set
<hackedbellini> it shouldn't, but it's an acceptable solution atm =P
<stub> hackedbellini: db:42 is an example relation id. 'juju-run --unit=client/0 relation-ids db' or 'db-admin' will list them
<hackedbellini> stub: hrmmm, nice! Let me try that and I'll give you a feedback to say if that worked
<stub> hackedbellini: Worst case, you can use juju run like this to override any values in the relation you like... just try not to blow your foot off :)
<lazyPower> stub: you just dropped some science on me about -r relation:id
<stub> lazyPower: Just test before repeating - I'm knee deep in something else and doing this by memory ;)
<stub> launchpad.net/juju-relinfo if you want a plugin to reduce the typing for the relation-get/relation-sets
<hackedbellini> stub: I think it worked! Thank you!
<hackedbellini> and thank you lazyPower for taking the time to see that with me
<stub> np
<lazyPower> hackedbellini: no worries :) I'm happy we didn't traverse the original route i was proposing
<lazyPower> that would have been long winded to determine blame
<stub> Is there some way of telling amulet to deploy cs:precise/storage under trusty? Since I need to relate the subordinate to a trusty service?
<lazyPower> stub: you'll need to make a local copy
<stub> :-P
<lazyPower> cd ~/charms/trusty && charm get cs:precise/storage -- that will effectively make a local trusty charm - and you'd deploy it like any other local charm.
<lazyPower> ymmv if deps have changed between precise/trusty
<stub> I'll try a custom branch via the charm store. I don't want to embed a copy of the storage charm in my charm just for running tests.
<stub> Or do lp: urls work? Hmm...
<stub> We should probably promulgate it to trusty anyway, since I think we are already running it in production :-/
<marcoceppi> stub: personal branch in cs is best way
<stub> lp: branch is working, with one less point of failure.
<stub>         deployment.add('storage', 'lp:~stub/charms/trusty/storage/trunk')
<PariahVi> Hello.  I am just starting to fully look into Juju charms rather than Juju-core and I had a question about the charms.  Would you run the charm's install script again if you wanted to update the package if it was not installed via apt-get?
<thumper> PariahVi: normally there would be an upgrade hook that would do that
<PariahVi> thumper: Okay.  Thank you.  This points me in the correct path of documentation reading. :)
<thumper> np
<drbidwell> I have a juju bootstrap that runs with a MAAS.  The bootstrap looks like it completed successfully and ends with "comamnd finished", but maas never changes the machine to a "deployed" state.  Any ideas why this might be?
<johnmce> Hi guys. I just tried to get SSL enabled for the keystone charm. It doesn't work, and I note that there's no [ssl] section in any of the templates, nor does it appear in the keystone.conf on the target machines. Can anyone confirm that this is known to be broken?
<johnmce> Obviously I've provided an SSL key and cert. The endpoint URLs show https, but that appears to be the only evidence of any attempt at SSL.
<hatch> johnmce: If no one pops in with an answer to your question you might have better luck asking on askubuntu.com, the juju mailing list, or by contacting the charm maintainer
<marcoceppi> johnmce: the SSL stuff is handled by a charm helper, I'm not sure the specifics of that charm as it's maintained by the Openstack Charmers team
<marcoceppi> like hatch mentioned mailing the mailing list (juju@lists.ubuntu.com) is a great way to get in touch with them. When I see it come in I can make sure it gets their attention
<marcoceppi> drbidwell: try running juju bootstrap with the --debug flag
<marcoceppi> drbidwell: also which versions of maas and juju are you using?
<drbidwell> marcoceppi: maas 1.7.0 and juju-core is 1.20.13 for U14.04.1
<drbidwell> I have the debug output also
<marcoceppi> drbidwell: debug output is good, could you put it on http://paste.ubuntu.com
<drbidwell> marcocceppi: http://pastebin.com/3LDxnQyy
<dpb1> tvansteenburgh: does bundletester provide facilities for archiving logs?
<dpb1> tvansteenburgh: specifically the unit logs
<tvansteenburgh> dpb1: no
<dpb1> tvansteenburgh: k, thx
<tvansteenburgh> it would be a great feature though
<tvansteenburgh> would like to add it eventually
<dpb1> tvansteenburgh: yes, I'd like something like that, we have a script that does the same.  I might think of how to incorporate it.
<tvansteenburgh> dpb1: great!
<dpb1> tvansteenburgh: is tests/test.yaml used?  I put some 'packages' in there and it doesn't seem to influence anything
<tvansteenburgh> dpb1: yep
<dpb1> tvansteenburgh: http://paste.ubuntu.com/9433320/
<dpb1> tvansteenburgh: does that look right?
<tvansteenburgh> yeah
<tvansteenburgh> keep in mind your venv probably isn't seeing sys pkgs
<tvansteenburgh> and we don't have a way to pip install via that yaml file (yet)
<tvansteenburgh> so a 00-setup.sh that installs pkgs is probably the best solution when running in a venv right now
<tvansteenburgh> dpb1: hope that helps, i gotta EOD
<dpb1> tvansteenburgh: yes, that helps
<dpb1> and matches what I'm seeing
<Micromus> So, is Juju as good as it looks from the website??
<LinStatSDR> Micromus: It absolutely is.
<Micromus> I don't believe it :P
<LinStatSDR> I got a full private cloud running with under 10 commands.
<Micromus> I was looking to deploy cloudstack for testing, figured openstack was still immature, but canonical just released a new version quite recently, no? with a lot of juju magic integrated with it?
<LinStatSDR> Micromus: You should, that's the future of things. IoT, Cloud yada yada
<LinStatSDR> You can install Openstack on a single system in under an hour
<Micromus> Sure, installing something is one thing, but maintaining and using it is another
<sarnold> Micromus: openstack is deployed on hundreds of thousands of systems, if not millions
<LinStatSDR> I don't find clicking and dragging to be terribly difficult to manage.
<Micromus> doesn't mean it's a fit for us though
<LinStatSDR> oO
<Micromus> hehe, I just spent several days trying to configure a Ceph cluster, and giving up in the end, so everything that shines is not gold
<LinStatSDR> I have not found a solution such as OpenStack and Juju that is more effecient, powerful, reliable and FREE than said solutions
<Micromus> that said, I'm really looking forward to trying the new ubuntu openstack "thingie"
<LinStatSDR> What is your background with computing?
<Micromus> I bought 9 used serverblades on ebay privately to start testing cloud stuff
<Micromus> about 10 years of network and system administration
<LinStatSDR> There is a lot of research and knowledge, as nice as I made it sound you do have to have a wide range of system knowledge
<LinStatSDR> Oh okay, anything on the Unix / Linux side? Most of it can be handled through ssh
<Micromus> mostly networking, but networks often need some servers and other stuff to have a purpose
<LinStatSDR> It would be most beneficial to have a strong background in Linux type systems.
<LinStatSDR> For troubleshooting at least.
<Micromus> run 50 linux servers yes
<LinStatSDR> Ah no worries then.
<LinStatSDR> Micromus: Now your type of deployment is different if you got 9 blades you're going to use for it.
<Micromus> familiar with googling and troubleshooting, even if that is not what i enjoy spending my time doing
<Micromus> I'll probably use 3 of the blades for testing openstack
<LinStatSDR> Micromus: So you would most likely want to use MaaS and manage them through landscape or something.
<LinStatSDR> Micromus: Specs on those blades pretty good?
<Micromus> At work we are looking to replace VMware, so the more  of our new services, and legacy stuff, we can get on a "cloud" solution the better
<Micromus> nah, bought used on ebay for $2500, combined :P
<LinStatSDR> That would be a great replacement, Juju and openstack platform
<Micromus> 48gb ram, 2x1tb disk, 6 core cpu
<LinStatSDR> Total? or each?
<Micromus> Each
<LinStatSDR> You bought 9 blades with those specs 2500?
<sarnold> nice
<Micromus> Yep :D
<LinStatSDR> You lucky...
<Micromus> Shipped them with container to norway, installed in the basement
<LinStatSDR> Seems like you're bottle neck is the HDDs
<Micromus> probably, there are 2 free slots for each blade tho
<LinStatSDR> Not to be too blunt, but at least in my particular experience it is very heavy on the IOPS
<Micromus> What is?
<LinStatSDR> Openstack Platform and such, especially Juju
<Micromus> When deploying stuff, or continously?
<LinStatSDR> Raid 1 at minimum, raid 5,6 or 10
<Micromus> I just deployed a 3 node cluster of HBase in the weekend, using Ambari for deployment, very good stuff
<LinStatSDR> In general, but it depends on the number of users you'll have, for testing, it may seem fine but add a few users, depending on network congestion, cpu, ram and hdd utilization at the time you'll find it will slow down considerably
<Micromus> Yep, thats why it's good to have some hardware to play with and set stuff up and test actual workloads on
<Micromus> Before we go buy hardware for production, without knowing what to optimize for
<LinStatSDR> My testing environment isn't the best but after establishing performance baselines with expected vs actual I have came to that conclusion
<LinStatSDR> Are you using MaaS at all?
<Micromus> Never heard of MaaS
<LinStatSDR> Are you using Ubuntu or debian?
<Micromus> debian today
<Micromus> and centos6 for ambari/hadoop-cluster, since debian is not supported yet
<LinStatSDR> I use Ubuntu but I suppose it doesn't matter. https://maas.ubuntu.com/ You should check it out. MaaS is very, very nice and Juju can orchestrate that very well
<Micromus> I like the review of Charms etc
<Micromus> I believe one of the problems with FOSS is lack of accountability, and actual review of stuff before it is "passed on"
<LinStatSDR> The only gripe I have about Juju is that there are far more charms and bundles than what show up when "Searching"
<Micromus> So as a receiver/consumer of FOSS products, you get a lot of surprises  on docs, quality, whatnot
<LinStatSDR> Micromus: Accountability? Why?
<Micromus> What I mean is, there are too many morons releasing too much crap
<LinStatSDR> Only add PPA's that are stable.
<Micromus> Making it hard to actually believe when something great, like Juju seems to be, actually appears :)
<Micromus> I will definetely look at maas/juju/ubuntu openstack for our new DC deployment which I hope wll get budgeted for next year
<LinStatSDR> Juju is wonderful, simple and easy. Juju along with the associated platform/platforms requires a significant amount of knowledge about not only their software products but in every area.
<Micromus> Also seeing a fairly large, and very welcomming, irc channel is also a huuge plus for any product/ecosystem
<LinStatSDR> Micromus: The Canonical Dist for OpenStack, http://www.ubuntu.com/download/cloud/install-ubuntu-openstack
<Micromus> Indeed, that is why it is such a big commitment to go down one road, with regards to asociated platforms etc
<Micromus> And why it's so important that the system can be set up for testing in minimal amount of time, since maybe one has to test multiple alternatives
#juju 2014-12-09
<Micromus> if each one takes days or weeks just to test...
<LinStatSDR> Micromus: Have you thought about using VMWare Horizon 6?
<LinStatSDR> I'm not sure about what you're current production system does but
<Micromus> No, I have looked at pricing of vmware vsphere and it's extremely expensive
<Micromus> currently we have the cheapo vmware essentials for 3 nodes
<Micromus> which is basically free at $200 a year or something
<LinStatSDR> Do you deploy or do any Virtual Desktops?
<Micromus> No, I work for an ISP
<LinStatSDR> Oh okay, scratch that then.
<Micromus> So we don't need that much performance, but we need the safety of clustering and ease of deploying new stuff, and saved time by automation
<LinStatSDR> Hmm, if you don't mind me asking, what are you clustering and/or deploying / automating?
<Micromus> So definetely, the cloud is the future, but right now it's hard to pick which vendor/implementation to go with
<LinStatSDR> Just SDN stuff? Like deploying new networks using Openstack?
<sarnold> Micromus: one neat thing is that juju can deploy multiple 'levels' of your system -- you could use juju to deploy openstack on your hardware and then manage all the vms in openstack by hand, or you could deploy openstack by hand and then use juju on top, or use juju for both the openstack deployment -and- the services that run on top of openstack
<LinStatSDR> i.e OpenStack Neutron.
<Micromus> A range of services, caching DNS for customers, authorative DNS for domains, webservers, customer e-mail platform, voip platforms, broadband provisioning systems, network monitoring systems, and systems monitoring the other systems
<Micromus> sarnold: I like that
<Micromus> I dislike the all-or-nothing approach
<Micromus> Risk is lower when stuff is modularized
<sarnold> Micromus: yeah :)
<sarnold> Micromus: .. and it's also neat that if you like the tool, it can work for you on multiple kinds of tasks, too
<LinStatSDR> Well, technically it's not all or nothing. The features are there but if you're looking for a minimalistic approach you could always go knee deep into linux from scratch
<Micromus> And usually, when vendors bundle stuff together like that, it's because there is some stuff you cannot live without, but some of the stuff is utter shit
<sarnold> Micromus: oh yes, so true..
<LinStatSDR> Micromus: Yep, nothing like having to have bloatware on production systems.
<LinStatSDR> Always a good time...
<Micromus> So I'm always wary against "all-or-nothing" stuff, not because it's always bad, it's just likely to be bad based on prior experience and statistics :P
<LinStatSDR> That's why we have Dev systems
<Micromus> Yes, and the time to get the dev system up and running itself is not so costly that you basically have to go further with the project even if the pilot goes south, which very often is the case, sadly
<LinStatSDR> I always go for the minimalistic approach but sometimes I have issues with having such an environment when/if I need to scale out the services.
<LinStatSDR> Micromus: The only thing that's costly is them paying you for all the time do troubleshoot, install, deploy and manage it.
<Micromus> I spent a week writing a tutorial on setting up opentsdb when going from dev to production, https://peritusconsulting.github.io/articles/2014-06-02-next-generation-monitoring-using-opentsdb.html
<Micromus> They also pay me to do the research/testing of the systems before install and deploy ;)
<Micromus> So this is actually my step 2 of that, after skimming the webpages ;)
<LinStatSDR> I'm in the same boat, I ONLY do R&D now but I have others do the documenting for me.
<Micromus> So far; website awesome, community seems good (or I might just be lucky now), next step is downloading and installing later this week
<LinStatSDR> I have a wiki, because no one ever reads the documentation
<Micromus> Yep, that tutorial is now broken, due to new incompatible versions of stuff, so not worth the time spent from a pure documentation point of view
<LinStatSDR> Micromus: It's really a niche community here.
<sarnold> Micromus: you are a touch lucky now, irc isn't always this responsive; the juju team does a good job keeping up on questions in askubuntu though, so when viewed as an average-per-day it works out alright, but there are times when irc is .. thin.
<Micromus> Internally we use wiki as well
<LinStatSDR> sarnold: We get a lot of OpenStack / Juju questions in #Ubuntu and #Ubuntu-Offtopic
<Micromus> sarnold: hehe, the opentsdb channel for example, usually goes weeks between any activity, so I'm guessing it's all relative
<LinStatSDR> But please, no #ubuntu-offtopic questions. That's the place to relax
<sarnold> LinStatSDR: oh, interesting, I hadn't heard of #ubuntu-offtopic, and #ubuntu is like drinking from a firehose, so I'm not often there :) hehe
<sarnold> Micromus: nice, hehe
<LinStatSDR> #ubuntu is a scary place with 1,800 users in it. The OT channel has like 220
<Micromus> I usually dont go to chat or forums to ask questions, I can usually google my way to the source and solutions pretty quickly
<Micromus> I may throw the occational fit when I spent hours on some problem that is just stupid though  :o
<sarnold> Micromus: this seems like something you might enjoy reading about; I don't know how far along alan is yet.. http://linux-ha.org/source-doc/assimilation/html/index.html
<Micromus> Hah, I know, discovered that a few days ago actually
<Micromus> Chatting with Alan right now on #assimilation :)
<sarnold> Micromus: hah, nice :)
<LinStatSDR> Micromus: Just be glad you're not using Lync for the voip and video traffic
<sarnold> it could just be my alanr fanboyism, he gives a hell of a good talk, no matter what he is talking about..
 * LinStatSDR shutters
<Micromus> Just wondering, why did you think I would enjoy reading about it?
<Micromus> Because using graph databases for CMDB etc is something I have been thinking about for about a year
<sarnold> Micromus: you sound curious and your opentsdb read like you enjoyed learning about it :) hehe
<Micromus> spot on ;)
<sarnold> \o/
<Micromus> Anyway, it's 1.20 in the morning here and i should be asleep loong ago, thanks for the intro, I'll stick around and hopefully try some stuff later this week :D
<LinStatSDR> Always good to be excited about new technology. I remember a deadzone for a few years
<sarnold> gnight Micromus, see ya later :)
<LinStatSDR> Night Micromus, nice talking to you
<Micromus> :)
<LinStatSDR> sarnold: You wouldn't happen to know if this channel is logged would you?
<sarnold> LinStatSDR: yeah: http://irclogs.ubuntu.com/2014/12/09/%23juju.html
<LinStatSDR> That's literally dated tomorrow
<LinStatSDR> I see. I'm a fool. Don't mind me
<sarnold> hah, so it is :)
<sarnold> I was just surprised that it was so far behind..
<LinStatSDR> It starts at 00:00 so
<LinStatSDR> It's as intended
<LinStatSDR> Thank you sarnold. I appreciate it.
<sarnold> LinStatSDR: sure thing :)
<jose> stub: ping
<stub> jose: pong
<jose> stub: in which moments would you expect an IP change?
<stub> jose: I don't know. I had a query here recently from someone whose postgresql unit had an IP address change, and we needed to manually trigger some hooks to get things back online.
<jose> stub: if you want to do such checks, you could add a sentinel file to your charm
<jose> so do 'unit-get public-address' or private-address and echo/cat it into a file, then to check if it's changed compare the output of the same command with the info on the file
<LinStatSDR> stub: lease expire or user command?
<stub> LinStatSDR: I have no idea. I'm usually only working in the local provider, so it doesn't happen here :)
<LinStatSDR> Ah.
<LinStatSDR> stub: last time I had that happen to me someone was trying to change it manually and I had to trigger a hook to get it to work
<stub> jose: last I heard, the whole system would fall over since the controller node would lose track of the units. But if that has been fixed, and the controller node follows the ip address changes of the units, then my charm needs to handle that too.
<jose> stub: unfortunately the bootstrap node isn't aware and has no way to check IP changed
<LinStatSDR> I don't mind hooking but don't want a db full of misc. ips
<stub> jose: That answers my question then :)
<jose> stub: IF you want some info on how to get that fixed, lemme grab a link for you
<LinStatSDR> MaaS can make the node aware.
<LinStatSDR> iirc
<jose> LinStatSDR: yeah, but bare in mind we're also dealing with aws, hpcloud, local, manual and many many more
<jose> stub: http://blog.dasroot.net/reconnecting-juju-connectivity/
<LinStatSDR> jose: Yeah, that's true.
<stub> I'm sure it will happen one day. I think all providers provide some sort of unchanging key for each container.
<stub> (cloud providers, not juju providers)
<LinStatSDR> I was going to say stub lol
<jose> stub: seen that last email? \o/
<stub> yeah, and responded ;)
<jose> \o/
<jose> looks like my watch was faster than my PC fetching it
<jrwren> I tried to follow http://blog.juju.solutions/cloud/juju/2014/11/26/debug-hooks-ext-plugin.html and no where does it say to add ~/.juju-plugins to PATH. To make it work, I had to add it to PATH. Is this intentional? Can post be updated or at least "read the README for more"?
<marcoceppi> jrwren: you must follow the instructions of the plugins
<cory_fu> jrwren: You're right that I should have mentioned that in the blog post.  There's also a requirement on python-jujuclient that I didn't mention.
<marcoceppi> jrwren: https://github.com/juju/plugins#fetch-source
<marcoceppi> cory_fu: you may just want to link to the repository readme, I'm about ot write one of those lame curl | bash scripts for the plugins archive
<marcoceppi> to do an interactive install or whatever
<cory_fu> Ok.  Should I bother submitting a PR to add the python-jujuclient requirement to the README, then?
<marcoceppi> cory_fu: go ahead
<cory_fu> Ok
<marcoceppi> no idea when this pipe dream of mine will come true
<marcoceppi> heh, get it, PIPE dream
<marcoceppi> man, I crack myself up
<cory_fu> ...
<jrwren> *groan*
 * marcoceppi sees himself out
<cory_fu> marcoceppi: PR for plugins and blog are submitted
<mbruzek> cory_fu: marcoceppi I can take a look
<cory_fu> mbruzek: Thanks
<lazyPower> :( nobody ack'd my big data post
<lazyPower> https://github.com/juju-solutions/juju-solutions.github.io/pull/16
<marcoceppi> lazyPower: /me nacks
<marcoceppi> ;) <3
<lazyPower> huzzahhh
<marcoceppi> not sure I agree with voice of artcile
<marcoceppi> but that can be tuned later
 * hatch waves at stimms
<stimms> howdy
<stimms> so we're looking at deploying a bunch of ubuntu machines to "the field". The field being a bunch of drilling rigs. They're going to be disconnected for the most part or connected over a really slow line.
<hatch> stimms: hey I pm'd you :)
<stimms> we would defer updates to when the devices are connected over a good connection
<stimms> probably once every 4-6 weeks
<hatch> we can take this to pm if you prefer
<stimms> no, no nothing secret or proprietary here
<hatch> ok sounds good :)
<hatch> then plz continue :)
<stimms> yeah so I was wondering how good of a fit this scenario would be
<stimms> for the most part all the devices will be the same but they would be in different states of update
<hatch> well typically Juju is used to orchestrate services in an environment - deploy, scale-up/down etc
<hatch> so juju would be really nice for actually deploying the applications to the various machines
<hatch> and for updating them when they come online
<stimms> that was my impression
<hatch> now the question is, are we talking about multiple physical machines?
<hatch> or just a single one that will be virtualized
<stimms> Yes, they're little micro ATX thingies
<hatch> ahh ok so you also probably want to take a look at MAAS
<hatch> as well
<stimms> that being said we could deploy a core os to the physical device and then layer a VM on top
<hatch> hmm
<stimms> or deploy into a container
<sarnold> juju is neat stuff, but if these machines are so .. disconnected .. I don't really see the need for it
<hatch> stimms: so I suppose there are a few different ways to do this
<stimms> being able to manage the machines and see what versions they are on from a central location would be handy
<hatch> it's actually a pretty interesting problem
<stimms> we live in an age of polyglot deployment
<hatch> indeed
<sarnold> it is interesting, nearly everything assumes ubiquitous networking :)
<hatch> stimms: I'm trying to think of a good approach for the intermittent connectivity
<hatch> I'm not sure if machines can pop in/out of an environment
<hatch> assuming having a single env for all the rigs
<stimms> how do you deal with network partitions?
<hatch> you could of course have a new env for each rig
<hatch> which would probably be best
<sarnold> from hearing about this so far, I think something like canonical's landscape might make more sense, but I know part of the landscape client sends ping messages back to the control server on a fairly regular basis; you probably wouldn't want that much overhead on a modem or worse, satellite link
<hatch> stimms, so each rig would have it's own juju environment which, when connected, you'd be able to log into and view the environment/machines/services etc
<hatch> stimms: I'm just thinking here...
<hatch> :)
<hatch> I love juju for the absolute trivial deployment story for services
<hatch> so if you could script the deployment of the applications that need to be installed on each machine you could easily deploy them to each rig's environment with a couple commands
<hatch> then when it came time to update any of those services it would also be as trivial as running a single juju command per environment
<hatch> stimms: so I suppose the question is - would you want to script the deployment of the services you need to install?
<stimms> oh for sure I would want it scripted
<stimms> I'm not manually deploying things to 100 boxes
<hatch> lol no, you probably wouldn't want to do that
<stimms> this isn't windowsland
<hatch> so yes I'd probably use a MAAS + Juju setup
<hatch> I think you need a minimum of 2 machines to run MAAS
<stimms> lanscape looks like it would also be a good tool for us
<hatch> MAAS would handle getting the hardware set up, os installed, registered for Juju's use
<hatch> and yes landscape would be very helpful as well
<stimms> and MAAS is (wasn't it the thing that made you walk faster in Mech Warrior 2?)
<hatch> lol
<hatch> https://maas.ubuntu.com/
<stimms> Metal as a Service is a great name
<hatch> haha I know right?
<stimms> although it is a bit close to terminator for me to be completely comfortable with it
<stimms> well this gives me some avenues to explore, thanks!
<hatch> stimms: yeah there are so many different approaches to this
<hatch> it will be a fun project for sure
<stimms> I'll be delighted if I get to work on it for more than an hour a week
<hatch> darn - well might be best to start looking at something like my Ghost blog charm
<hatch> it's written in JS but is very basic
<hatch> so it'll give you an idea of how a charm is structured
<hatch> https://github.com/hatched/ghost-charm
<stimms> every time I talk to you I hear about that charm
<hatch> lol
<lazyPower> stimms: he's the author, dont let it jade you :)
<hatch> haha shush
<lazyPower> stimms: alternatively - if you have charm-tools installed there are several templates available for boilerplate based exploration
<hatch> it's just very basic and doesn't rely on any external libs or anything
<hatch> so easy for new ppl to understand
<hatch> and yes that too
<lazyPower> to date there are 2 flavors of python template, a chef template, and a bash template - with more on the way and a possible restructuring of how we do charming once charm-helpers is a solified project
<lazyPower> *solidified - it moves pretty quickly at present, we're adding and extending it all the time.
<hatch> lazyPower: deploys environments all day so he would also be a great resource :)
<lazyPower> hatch: your work to have a js based charm would make an excellent charm template btw
<lazyPower> if you want help doing that lmk
<hatch> lazyPower: until node has a synchronous exec() command js charms are funky to write
<lazyPower> and thats newcommer friendly? :P
 * lazyPower ducks
<hatch> hahaha - well for js dev's it is
<hatch> lazyPower: do you know of a really basic python charm?
<lazyPower> hatch: the one created by charm create -t python_basic
<hatch> lazyPower: we should commit that to a repo somewhere for people to explore
<hatch> I could probably do it
<hatch> but then it'll be under my gh namespace :)
<hatch> and we don't want that :P
<lazyPower> hatch: actually we have a long running card to do many different avenues of going from zero to charm along the different devel paths
<lazyPower> if you're a chef based user, bash, python, etc.
<hatch> oh nice
<lazyPower> then having that be part of the charm author docs
<lazyPower> but time has been short with all the demo's and other fringe work coming up standing in between the docs and the eco team
<lazyPower> some day, we'll perfect cloning and get more evilnic's
<Micromus> Is there a separate channel for MAAS stuff?
<Micromus> Would provisioning a glusterfs SAN with MAAS/juju be possible? And would it be a good idea?
<sarnold> Micromus: there is a #maas
<sarnold> Micromus: I didn't much care for the look of glusterfs when I read the code, but I haven't actually run it myself
<Micromus> I've looked at ceph, but it's a pain to set up, and probably worse to operate
<jcastro> we do have a glusterfs charm
<lazyPower> it may be a bit long in the tooth - its still targeting precise
<hatch> stimms: if you have any more questions or anything feel free to ping me or ask here
#juju 2014-12-10
<rsynnest> Hi guys, I'm wondering if someone can help me figure out why my service is stuck in "agent-state: pending"
<rsynnest> right now it is just the juju-gui
<rsynnest> just not sure where to look
<marcoceppi> rsynnest: sure, happy to help
<marcoceppi> rsynnest: which environment is it? amazon, local, joyent, azure, etc?
<rsynnest> cool thanks
<rsynnest> it's onlinelabs
<rsynnest> https://github.com/online-labs/juju-onlinelabs
<rsynnest> not one of the big ones unfortunately
<rsynnest> they are ARM servers which may be something to do with it
<marcoceppi> rsynnest: it's fine, I'm somewhat familar actually
<rsynnest> oh cool
<marcoceppi> so this is using the manual provider
<rsynnest> yeeah
<marcoceppi> can you pastebin using http://paste.ubuntu.com the output of juju status?
<rsynnest> http://paste.ubuntu.com/9449401/
<marcoceppi> rsynnest: ah, I think i know the issue
<marcoceppi> what command did you issue to deploy the gui?
<rsynnest> juju deploy juju-gui
<marcoceppi> yeah, so 99% of the time, that works great
<marcoceppi> unless you're using the manual proider (so onlinelabs and digital-ocean atm)
<rsynnest> ah ok
<marcoceppi> Typically, juju uses the cloud provider like amazon, openstack, blah blah to requisition you a machine and it then puts the service on that machine
<marcoceppi> since this is manual provider and juju doesn't know the API look ups for those two clouds
<marcoceppi> you have to use a slightly different command
<marcoceppi> what you'll want to do is juju destroy-service juju-gui
<marcoceppi> then, to save space (juju gui is actually designed to run on node 0, it's kind of special)
<marcoceppi> rsynnest: you can just type `juju deploy --to 0 juju-gui`
<marcoceppi> however, for all other services
<marcoceppi> you'll want to do the following
<marcoceppi> juju onlinelabs add-machine
<rsynnest> ohhh that's right, I actually thought I did deploy it on the bootstrap node now that I think about it
<marcoceppi> this will provision a new machine for juju to use and enlist it in the pool of available machines
<rsynnest> but that does appear to have done the trick
<rsynnest> thanks!
<marcoceppi> rsynnest: no worries
<marcoceppi> you'll still need to provision more machines using `juju onlinelabs add-machine` (`-n #`, like -n 3 to add three machines)
<marcoceppi> before using gui or juju deploy
<rsynnest> right
<marcoceppi> the onlinelabs add-machine will provision machines with onlinelabs, add the to juju's pool of machines for usage, and everything works from there
<marcoceppi> awesome, cheers rsynnest
<wgrant> Can I convince the local LXC provider to use my local Ubuntu archive mirror?
<marcoceppi> wgrant: you can
<marcoceppi> wgrant: what version of juju do you have?
<wgrant> 1.20.10 on vivid
<marcoceppi> wgrant: you should just be able to set APT_PROXY environemtn variable and on bootstrap it'll use it
<marcoceppi> wgrant: there's also an environment variable you can set
<marcoceppi> but I need to find it
<wgrant> marcoceppi: Ah, I can set that to a mirror rather than a proxy?
<marcoceppi> wgrant:oh, wait
<marcoceppi> wgrant: what doy ou mean by mirror?
<wgrant> The containers always use archive.ubuntu.com, which is very slow from here.
<wgrant> I have a local mirror of archive.ubuntu.com.
<marcoceppi> wgrant: right, if you serve that up on a transport
<marcoceppi> then you can use APT_PROXY
<marcoceppi> not sure how that would look exactly
<wgrant> marcoceppi: That didn't seem to change anything. How does archive.ubuntu.com normally get overridden on public clouds? Through cloud-init?
<marcoceppi> wgrant: I'm not 100% sure, I'd suggest emailing the list with the queries. I'll make sure to find someone who can help answer it tomorrow
<wgrant> marcoceppi: Thanks.
<rsynnest> Is it possible to run a precise charm on a trusty machine?
<marcoceppi> rsynnest: yes, but you first have to fork the charm
<rsynnest> cool, would I then need to change the config?
<rsynnest> I'm still pretty new, I'd like to try writing a basic charm just to have a better idea about whats going on  in there
<lazyPower> rsynnest: depends on the charm, but no just forking it into the trusty series in your local charm repo would be enough
<lazyPower> rsynnest: if you want to get your hands dirty in a template, install charm-tools and charm create -h will give you an overview of whats available to you for exploration
<rsynnest> nice
<rsynnest> are there any plans to have juju run on non-ubuntu machines?
<mwhudson> rsynnest: which bits?
<mwhudson> the client is available for several platforms
<rsynnest> charms
<mwhudson> ah
<mwhudson> there is some support for centos and windows iirc
<rsynnest> debian seems like it wouldnt be too far off
<jcastro> someone needs to just do the work
<jcastro> the store supports series
<jcastro> so doing jujucharms.com/wheezy/blah or whatever is doable
<rsynnest> interesting
<rsynnest> I wonder if an ubuntu docker container is too many layers
<rsynnest> since that could theoretically run on any distro
<marcoceppi> jcastro: I've gotten juju to bootstrap once on debian
<marcoceppi> but it was super hacky
<rsynnest> I guess it doesn't make a difference what distro is used now that I think about it
<rsynnest> windows would be interesting
<rsynnest> but also sounds like a hellish nightmare
<marcoceppi> rsynnest: well the goal of Juju is to eliminate that nightmare :)
<mbruzek> marcoceppi: this is the problem that Yael was seeing when trying to run the amulet test on its own. http://pastebin.ubuntu.com/9467254/
<mbruzek> I recognize this as juju-deployer version on the system being old/out of sync, is that a correct assesment?
<mbruzek> marcoceppi or tvansteenburgh or hazmat Could you tell me how to update deployer on the system to avoid this error?
<tvansteenburgh> apt-get install juju-deployer
<mbruzek> tvansteenburgh: sudo apt-get install juju-deployer
<mbruzek> juju-deployer is already the newest version.
<tvansteenburgh> then pip install
 * marcoceppi burns hearing this
<marcoceppi> mbruzek: add ppa:juju/stable
<tvansteenburgh> or that
<marcoceppi> there's a more updated version of deployer and jujuclient in there
<tvansteenburgh> on pypi too!
<marcoceppi> we can't recommend customers just pip install stuff because it makes troubleshooting and updating near impossible
<mbruzek> marcoceppi: juju/stable is already installed.
<marcoceppi> mbruzek: then something is wrong
<marcoceppi> 0.4.1 is latest in ppa
<mbruzek> marcoceppi: This is ppc64le, I remember there being a dependency issue.
<marcoceppi> fuuuuuuuuuuuuuuu
<marcoceppi> there's no ppa builders for ppc64le
<mbruzek> marcoceppi: is there a 0.4.1 for ppc64le?
<mbruzek> marcoceppi: thus why the ISV/partner was having this problem.
<marcoceppi> oh there
<marcoceppi> is
<mbruzek> marcoceppi: link?
<marcoceppi> mbruzek: https://launchpad.net/~juju/+archive/ubuntu/stable/+packages
<mbruzek> When I expand juju-deployer-04.1-1  I do not see a ppc64le deb
<marcoceppi> because ppc64el and le are the same thing
<marcoceppi> bleh
<marcoceppi> sorry
<marcoceppi> I was looking at juju-core
<marcoceppi> let me see if I can get a build for ppc64le
<marcoceppi> mbruzek: I re-uploaded juju-deployer
<marcoceppi> lets see if that builds ppc64le
<mbruzek> OK thank you marcoceppi
<mbruzek> I found a bug on this very topic already, so I added myself the the list:
<mbruzek> https://bugs.launchpad.net/juju-deployer/+bug/1389755
<mup> Bug #1389755: juju-deployer is not working on ppc64le <juju-deployer:New> <https://launchpad.net/bugs/1389755>
<marcoceppi> mbruzek: it doesn't appear that ppas have access to ppc64el
<mbruzek> *sigh*
<mbruzek> How does a python code care about that?  Can't the builders spit out debs in any architecture?
<rick_h_> marcoceppi: you have to request them special I'm told
<rick_h_> marcoceppi: because they run on limited hardware and such
<rick_h_> marcoceppi: but I'm told it can happen
<marcoceppi> rick_h_: any idea who I need to talk to?
<rick_h_> marcoceppi: launchpad folks/webops?
<marcoceppi> mbruzek: I didn't build the package, so I cant' say why it's arch aware
<marcoceppi> typically you just get an _all arch
<mbruzek> marcoceppi: I am happy to chase this down if you let me know who to talk with on webpos
<rick_h_> mbruzek: start with asking vanguard or mthaddon and they should help get you pointed from there
<mbruzek> rick_h_: in #is?
<rick_h_> mbruzek: #webops
 * mbruzek adds #webops to his channel listing
<marcoceppi> thanks rick_h_
<rick_h_> marcoceppi: np, hopefully kicks things off for you
 * rick_h_ checks out for the day
<mbruzek> Thanks rick_h_ have a nice day
<rsynnest> soo, I git cloned precise/meteor and tried to deploy it as trusty/meteor, and the install hook failed
<rsynnest> not sure how to debug, I don't see anything in juju debug-log
<rsynnest> http://paste.ubuntu.com/9467597/
<rsynnest> the service is up and relations appear to be working, but the unit itself is down
<marcoceppi> rsynnest: you can do `juju debug-hooks meteor/0` then in a seperate terminal, run `juju resolved --retry meteor/0` this will allow you to re-run the install hook on the unit and watch the output
<rsynnest> ah awesome, thanks
<marcoceppi> rsynnest: https://jujucharms.com/docs/authors-hook-debug
<noodles775> I'm trying to get the private IPs for units of a service. I can do this with `juju run --service myservice "hostname -i"`, which works, but I'm assuming I shoud be using unit-get private-address instead? (which gives me a private dns, which I then need to convert in python, on the unit, using socket.gethostbyname - so much simpler with hostname -i).
<noodles775> Any reasons not to use hostname -i?
<thumper> noodles775: sorry, but I have no idea...
<noodles775> np, thanks. I'll just use hostname -i for now :)
#juju 2014-12-11
<jumpkick> Is there a way to tune juju's mongodb instance to reduce the amount of syslog spamming?
<Slaan> Hi !
<Slaan> I use MAAS 1.7 and juju
<Slaan> All work fine, it's magic :)
<Slaan> i have one machine with maas, and one node bootstrapped by juju
<Slaan> i want to add a new node now. Maas can show it, and the commissioning is fine
<Slaan> did u know how can i add it to juju now ?
<Slaan> f i start "juju add-machine negligible-band.maas", i got " error: malformed container argument "negligible-band.maas"
<Slaan> and for "juju add-machine ssh:negligible-band.maas", i got : " ERROR rc: 255 (ssh: Could not resolve hostname negligible-band.maas: Name or service not known) "
<schkovich> slaan: juju add-machine --constraints "cpu-cores=2 mem=2048M"
<schkovich> you should not use maas to spin up new node
<Slaan> not use maas ? I don't need a boot from pxe ?
<schkovich> unless you are manually provisioning a machine with ssh
<schkovich> in that case juju add-machine ssh:user@10.10.0.3
<Slaan> mm ok. I don't understand why when i bootstrap juju for the first time, and if i have 2 node one maas, Juju choose one random node and install all only on this
<Slaan> why juju don't bootstrap whithin all the node ?
<schkovich> what's the output of juju status?
<schkovich> i have two environments maas and manual (rackspace)
<schkovich> manual environment is working fine
<schkovich> when i switch to maas environment all juju commands just hang
<Slaan> this : http://pastebin.com/QQ8ffxwZ
<schkovich> any idea how to debug or force destroying manual environment
<schkovich> sorry maas environment
<Slaan> i have to add the second node manualy ?
<schkovich> how did you deploy services? looks as if you deployed everything to single machine in separate containers
<schkovich> you could spin up new node with juju add-machine (with or without constrains)
<schkovich> then deploy desired service to that machine
<Slaan> i deploy service on LXC container within one machine
<Slaan> i want to deploy another service within a second node that i have added after the first juju's bootstrap
<schkovich> as far as i can see there is only a single machine running "0"
<Slaan> yes, so, i have to do a "juju add-machine ubuntu@ip"
<schkovich> juju add-machine ssh:user@ip
<Slaan> " ERROR rc: 255 (ssh: connect to host 192.168.1.17 port 22: No route to host) "
<schkovich> is your network up and running?
<Slaan> the node are down. When i boot it, MAAS shut down it
<schkovich> that is expected behaviour
<Slaan> Juju don't wait that the node boot ? like a bootstrap ?
<schkovich> why don't you try just juju add-machine?
<schkovich> with no arguments
<schkovich> and see what is going to happen :)
<schkovich> how many nodes do you have defined in maas?
<Slaan> okay :)
<schkovich> is the state of all nodes ready?
<Slaan> yes, the first node are deployed
<Slaan> the second, the new, are "Ready"
<Slaan> but shutdown
<schkovich> ok
<schkovich> when you run juju add-machine
<schkovich> that node should change state to allocated to root
<Slaan> oh yeah
<Slaan> you'r right
<Slaan> good
<schkovich> you should be able to ssh to it with juju ssh (node number from juju status)
<schkovich> then you could juju deploy --to 0 mysql
<Slaan> yeah, the new node are "deploying", and boot now
<schkovich> sorry --to 1
<schkovich> if that is the number of the new node
<schkovich> 0 should be juju bootstrap node
<Slaan> cool, i just have to "add-machine" alone
<Slaan> Cool, now the node is "deployed" on maas, and "pending" on juju status
<Slaan> many thanks :)
<schkovich> no mention slaan
<schkovich> i hope that i will find someone to help me :)
<schkovich> WARNING unknown config field "network-bridge"
<schkovich> any ideas?
<schkovich> in maas enevironment
<schkovich> hi guys im getting following error: WARNING juju.environs.config config.go:968 unknown config field "network-bridge"
<schkovich> i did not change/alter environment
<schkovich> warning started to appear after update of kvm/maas/juju
<marcoceppi> schkovich: did youupgrade juju?
<marcoceppi> schkovich: that's the answer, juju dropped that config field
<arbrandes> marcoceppi, can we still configure the local network bridge, somehow?
<marcoceppi> arbrandes: network-bridge for maas or local?
<arbrandes> marcoceppi, local
<schkovich> i see
<schkovich> deleting that field would resolve the problem
<marcoceppi> arbrandes: probably, let me check
<marcoceppi> schkovich: are you doing maas or lxc?
<arbrandes> Any love for #1377262?
<mup> Bug #1377262: please expose network-bridge to manual provider also <cts> <cts-cloud-review> <maas-provider> <network> <juju-core:Triaged by niedbalski> <https://launchpad.net/bugs/1377262>
<marcoceppi> (not sure if you two are working together)
<schkovich> maas kvm
<arbrandes> marcoceppi, nope, completely unrelated :)
<marcoceppi> schkovich: well you can just delete the field from ~/.juju/environments/maas.jenv
<marcoceppi> or whatever the name of your maas environment is
<marcoceppi> arbrandes: it may have been removed from maas but not the local provider
<arbrandes> marcoceppi, great, thanks
<marcoceppi> For instance, it may have been a global option that was instead moved to a few specific providers
<marcoceppi> arbrandes: need to validate that statement though, one sec
<schkovich> i had yet another problem after update yesterday: vms that where marked to autostart did not start including state machine
<marcoceppi> arbrandes: just confirmed it's in the local provider environments still
<schkovich> is that also known problem?
<marcoceppi> schkovich: that's interesting, but sounds like a maas issue, what version of maas do you have?
<arbrandes> thanks, marcoceppi
<schkovich> could be maas issue
<schkovich> how do i get maas version?
<schkovich> maas --help is not helpful ;)
<marcoceppi> schkovich: on the maas machine run `dpkg -l | grep maas`
<schkovich> ah that one
<schkovich> give me a moment
<schkovich>  1.5.4+bzr2294-0ubuntu1.2
<schkovich> client
<cory_fu> Can someone tell me where the juju agent for machine 0 caches copies of the charm during deployment?
<schkovich> marcoceppi: everything is on the same version 1.5.4
<marcoceppi> cory_fu: typically to the storage for the environment
<marcoceppi> cory_fu: so it depends on the environment
<cory_fu> local provider, in this case
<marcoceppi> schkovich: huh, I'm not aware of a bug in that version matching your description
<marcoceppi> cory_fu: ~/.juju/local
<marcoceppi> where local is the name of your local environment
<Spads> cory_fu: Sorry I missed the services framework call the other day.  Did you discuss how the RelationContext classes have both name and interface, but never seem to use interface?
<cory_fu> Is there any chance that persists across destroy / bootstraps?
<marcoceppi> cory_fu: it's possible
<schkovich> marcoceppi: sorry, i can't provide more information. i been going through logs for a few hours but i found nothing
<cory_fu> Spads: Not specifically.  There is at least one case where both are needed, but I can't recall it off the top of my head.  I think it has to do with provide_data
<Spads> heh
<schkovich> anyway im going to flag vms to autostart reboot the server and see what's going to happen :)
<cory_fu> Spads: You do need both to uniquely identify a relation
<Spads> I just lost a couple hours to "Oh wait, it's not actually using interface here..."
<cory_fu> Yeah, I agree that it's confusing and it's definitely something we want to clean up
<Spads> I had assumed that interface would be the relation interface it'd hook onto, and name would just be kind of internal
<Spads> but it feels the other way around, at least for the stuff I was working on
<cory_fu> marcoceppi: So where would that storage be, so that I can check it?
<cory_fu> Oh, you already said ~/.juju
<cory_fu> Where would it be from the point of view of machine 0, though?
<cory_fu> Ah, nevermind.  I can't ssh into 0 in local provider anyway
<marcoceppi> cory_fu: yeah, 0 is your machine
<rsynnest> jumpkick: not sure if someone answered you but this may help https://jujucharms.com/precise/mongodb#verbose
<niedbalski> arbrandes, seems that the network-bridge directive has been removed
<arbrandes> niedbalski, not from lxc, apparently.
<arbrandes> niedbalski, still, I would like to see it in the manual environment, and it was never there to begin with. :)
<niedbalski> arbrandes, ack, i could help with that then.
<arbrandes> niedbalski, #1377262 would be nice.  But if there's an alternative way to get Juju to use a certain bridge for LXC on manually provided nodes that you know about, I'd sure like to hear it. ;)
<mup> Bug #1377262: please expose network-bridge to manual provider also <cts> <cts-cloud-review> <maas-provider> <network> <juju-core:Triaged by niedbalski> <https://launchpad.net/bugs/1377262>
<arbrandes> My next step was to just re-use lxcbr0 for my manually created bridge.
<niedbalski> arbrandes, as far as i know, there is no a possible workaround, different to use lxcbr0
<arbrandes> Ok, that's what I'll do, then! :D
<marcoceppi> lazyPower: I think your issue #55 on amulet is actually this: https://github.com/juju/amulet/issues/57
<lazyPower> marcoceppi: echo $JUJU_REPOSITORY - returns nothing though :(
<marcoceppi> lazyPower: your issue is a different one
<marcoceppi> and I know how to fix it
<jrwren> I'm getting some VERY strange behavior from amulet which I cannot explain. I looked at the python code. it makes no sense. http://pastebin.ubuntu.com/9480773/
<jrwren> line 97 is the shutil.rmtree line. shutil is python's built in shutil afaik.
<lazyPower> jrwren: wat
<lazyPower> its referencing a nil object?
<lazyPower> tvansteenburgh: ^ this is weird, but i haven't looked @ jrwrens code either.
<jrwren> the code that triggered the fail: http://pastebin.ubuntu.com/9480848/
<tvansteenburgh> such are the pitfalls of __del__. i need to refactor that code, i've seen these errors on jenkins too
<jrwren> i'm guessing on line 37, but could have been line 38
<jrwren> __del__ considered harmful.
<tvansteenburgh> yes
<jrwren> at least ever since python 2.4
<tvansteenburgh> it's an easy refactor just haven't gotten around to it
<jrwren> no worries. If it is a known thing, then I'm happy.
<tvansteenburgh> jwren: https://github.com/juju/amulet/issues/58
<jrwren> oh, it is on github. I was looking on lp
<Saviq> hey all, I quickstarted a manual environment in a container, with nested containers enabled, but juju-gui says that sub-containers are not supported, can't find much info on that, what am I doing wrong?
<lazyPower> Saviq: containers in containers are not officially supported as far as I know
<lazyPower> while it may be possible, we're not testing that scenario, and should be considered purely experimental quality experience.
<Saviq> lazyPower, I'm fine with that, doing experiments here in the first place
<Saviq> lazyPower, IIUC, as long as lxc works, juju should be able to create sub-containers no problem?
<lazyPower> Saviq: with that being said, you might have to use the CLI to run your deployments in that scenario, i'm not 100% on what the gui is sniffing and blocking, a gui team member like  perhaps hatch or rick_h_ would have more info
<Saviq> lazyPower, thanks, will try the CLI
<hatch> a who what
 * hatch pokes head in
<lazyPower> hatch: containers in containers (yo dawg) - does the gui sniff for this and prevent deployment?
<hatch> yeah
<lazyPower> i figured as much. thanks for confirmation
<lazyPower> Saviq: ^
<hatch> Saviq: so we disable containers in the GUI for environments where networking is not supported between containers
<hatch> because trying to relate them will silently fail
<hatch> you can force it to allow you though
<hatch> by appending /:flags:/containers
<hatch> to your url
<hatch> ^ Saviq
<Saviq> hatch, I think my case is simpler actually, I don't want to deploy to nested containers, but my machine 0 is already a container
<Saviq> hatch, so IIUC networking should work fine?
<hatch> Saviq: when you say it's a container, are you running locally?
<hatch> lxc?
<Saviq> hatch, it's a vps in lxc
<lazyPower> hatch: and to note, its manual provider
<Saviq> hatch, but to experiment, I've nested a "juju" container and want to do everything inside there before moving to the "parent"
<Saviq> hatch, fwiw, CLI deploy seems to be doing just fine
<hatch> I believe you should be fine then
<hatch> ok great
<hatch> we do that to avoid the silent failure issues :)
<Saviq> hatch, thanks
<hatch> Saviq: if you hit Shift+/ or ? then a menu will pop up which shows "Custom GUI Settings"
<hatch> you can also use that to enable the containers
<Saviq> hatch, hah, cheat codes!
<hatch> haha yup :)
<hatch> next up - konami code!
<lazyPower> hatch: would be cool to play pong with the charm icons :)
<hatch> lol
<hatch> that would be very cool
<Saviq> hehe
<hatch> lazyPower: https://bugs.launchpad.net/juju-gui/+bug/1401687 :)
<mup> Bug #1401687: force enable container support from machine view <juju-gui:New> <https://launchpad.net/bugs/1401687>
<lazyPower> hatch: +1
<Saviq> hatch, the "{Discard,Save} changes" button panel on bottom left when editing config overlays the bottom of the config pane, is that known?
<hatch> hmm, that was fixed at one point
<hatch> let me check dev
<hatch> Saviq: this is definitely a reintroduced bug
<Saviq> hatch, want me to file one?
<hatch> I'd love that
<hatch> https://bugs.launchpad.net/~juju-gui
<hatch> :)
<hatch> wait that's the wrong link
<hatch> lol
<hatch> https://bugs.launchpad.net/juju-gui
<hatch> there we go
<Saviq> yeah it looked weird
<hatch> (off by one character error) ;)
<Saviq> hatch, bug #1401697, let me know if you need a screenshot
<mup> Bug #1401697: Controls panel overlays bottom of config pane <juju-gui:New> <https://launchpad.net/bugs/1401697>
<hatch> Saviq: I know what you mean but whomever gets assigned the bug may not so a screenshot would be helpful
<hatch> thanks thanks for filing the bug!
<Saviq> ok, a piece of a screenshot added, hopefully clear
<hatch> yup very, thanks
#juju 2014-12-12
<tvansteenburgh> rsynnest: ping
<rsynnest> tvansteenburgh: hey!
<rsynnest> was the github outdated?
<tvansteenburgh> hey, see my email?
<tvansteenburgh> yeah, updating now...
<rsynnest> awesome, thanks man
<tvansteenburgh> rsynnest: my pleasure! just pushed the changes if you wanna have another go
<rsynnest> tvansteenburgh: no luck :/
<rsynnest> would running in a python virtualenv have any effect on the charm?
<rsynnest> like maybe python dependencies aren't accessible?
<tvansteenburgh> rsynnest: same traceback?
<rsynnest> not sure, I'll check. It did fail on install hook
<tvansteenburgh> rsynnest: if it's the same, while you're in debug hooks, try running `add-apt-repository -y ppa:chris-lea/node.js`, since that appears to be where it failed the first time
<rsynnest>  add-apt-repository: command not found
<rsynnest> both software-properties-common and python-software-properties are installed
<tvansteenburgh> wha...
<tvansteenburgh> apt-get install apt-file -y
<tvansteenburgh> apt-file search add-apt-repository
<rsynnest> dope, i forgot the debug-hook runs on the unit's machine
<tvansteenburgh> :)
<rsynnest> i have add-apt-repo local but not on the machine
<rsynnest> that did the trick
<rsynnest> XD
<rsynnest> thanks for the help!
<tvansteenburgh> so what did you have to do?
<tvansteenburgh> install add-apt-repo?
<rsynnest> just installed software-properties-common to the meteor machine
<tvansteenburgh> okay, cool, i'll get the charm updated
<tvansteenburgh> thanks for helping make the charm better rsynnest!
<rsynnest> np, thanks for being so responsive
<rsynnest> errr hang on
<rsynnest> next hook is failing lol
<tvansteenburgh> k, paste me a trace when you have it
<rsynnest> how did you know it was the add-apt that was causing the issue?
<tvansteenburgh> saw it in your traceback in the email
<rsynnest> http://paste.ubuntu.com/9484186/
<tvansteenburgh> hrm, did you run the install hook again after installing those deps?
<rsynnest> yeah
<rsynnest> im still in the same debug-hook shell
<tvansteenburgh> `which mrt`
<tvansteenburgh> rsynnest: what's the output of `which mrt`
<rsynnest> oh, it returns nothing
<rsynnest> wasn't sure if that was you thinking you were in termie :)
<rsynnest> ls
<tvansteenburgh> ha
<tvansteenburgh> i'm not sure how install succeeded if we don't have that
<rsynnest> ahhhh sorry
<rsynnest> i re-ran install and it does fail at the end, i missed it
<rsynnest> Unusable architecture: armv7l
<rsynnest> Meteor only supports i686 and x86_64 for now.
<rsynnest> dang
<tvansteenburgh> doh!
<tvansteenburgh> bummer :)
<rsynnest> well, if anyone asks now you know
<rsynnest> sorry for the wild goose chase :P
<tvansteenburgh> np at all, it was helpful
<tvansteenburgh> hope you stick around juju anyway!
<rsynnest> welp, time to go bug the meteor folks ( Í¡Â° ÍÊ Í¡Â°)
<tvansteenburgh> hehe
<tvansteenburgh> time for me to call it a night, cya around rsynnest
<rsynnest> peace man, thanks again for the help
<tvansteenburgh> you bet!
<Saviq> hey all, I seem to have my mysql unit stuck in "installed" (and now in "dying" after trying to destroy it), what could I do to debug?
<Saviq> forced the machine out, trying again
<Saviq> so yeah mysql permanently gets into "installed" state for me
<Saviq> oh now it ran!
<Saviq> ok /me shuts up
<jcastro> hey everyone, we're a video game: http://www.jujuandpeyo.com/
<lazyPower> Congrats tvansteenburgh on your first charm promulgation since becoming a ~charmer!
<lazyPower> may the users of meteor rejoyce in happyness as you have delivered their nectar
<tvansteenburgh> \o/
<lazyPower> mbruzek, marcoceppi_, dpb1, niedbalski ^ :)
<mbruzek> cheers tvansteenburgh
<niedbalski> tvansteenburgh, congrats!
<ejat> congrats
<jose> congratulations, tvansteenburgh!
<lazyPower> oo sorry about the miss jose ;D i thought you were at uni
<jose> lazyPower: told ya, I'm on vacation until April
<lazyPower> nice
<ejat> jose : have u finish the limesurvey charm test ?
<jose> ejat: I'm poking on some critical stuff right now, but I did take a peek yesterday. looks like it's more than just that dependency, but I'll see what I can do
<ejat> ok thanks :)
<jose> marcoceppi_: hey, your seafile tests will depend on a fix that I'm pushing for review now
<jose> marcoceppi_: also, the revq is not deleting some of the old closed/deleted MPs/charms
<thebozz> Hey guys, we're trying to install Juju + Openstack on top of MAAS. The auto-install fails with this error log: http://pastebin.com/EWAwCEuN ... what could be wrong? We can SSH into our nodes.
<aisrael> sebas5384: what platform are you using sshuttle on?
<sebas5384> aisrael: using redir or iptables because sshuttle is too slow :(
<aisrael> sebas5384: I have a workaround for sshuttle, but I've only tested it with OS X/Vagrant
<thebozz> Hey guys, we're trying to install OpenStack on top of MAAS using the ubuntu tutorial (http://www.ubuntu.com/download/cloud/install-ubuntu-openstack).  We're currently on step 4, but it keeps failing with this error: http://pastebin.com/EWAwCEuN
<lazyPower> thebozz: interesting - seems like possibly the keys didn't make during the bootstrap - have you retried teh provisioning? and is it consistent?
<thebozz> lazyPower: we haven't reprovisioned. Yes, the error is constant. Should we try with a reprovision?
<lazyPower> thebozz: i would give that a go and see if its intermittant failure, or if there are larger issues at play here.
<thebozz> lazyPower: wait, you mean the SSH keys you configure on MAAS? We can connect to each node using SSH using the ubuntu user, so if that's what you meant then it's working fine.
<lazyPower> thebozz: thats what i was referring to
<thebozz> Hmmm. Then the keys are fine. What else could cause this? What user does juju try to connect to the nodes as?
<lazyPower> thebozz: the ubuntu user
<thebozz> lazyPower: so the login itself shouldn't be an issue either. I'm completely stumped with this one.
<lazyPower> this is troublesome to me, as juju loads its own set of ssh keys with maas that it then uses to connect to the nodes.
<lazyPower> thebozz: i'm not 100% familiar with the new 'autopilot' installer however
<lazyPower> teh last time I did this, it was still a mostly manual process until you got to juju being bootstrapped.
<lazyPower> thebozz: I would recommend pinging in #maas as well, someone may have some insight as to what the problem might be - but i beleive its after hours for them, quite a few of them are UK based.
<thebozz> Still worth a try, though. Thanks!
<dannf> is there some kind of 2 minute timeout during an install hook - e.g. between lines of stdout? i have a git clone that always fails around then, but if i juju ssh in, i can clone just fine
#juju 2014-12-13
<X-Rob> OK, This IS CRAZY. How have people even written this code, and, more importantly, HOW ARE THESE TESTS PASSING?
<X-Rob> https://github.com/juju/juju/blob/master/utils/ssh/ssh_test.go#L80
<X-Rob> that is NOT the syntax for SSH commands.
<X-Rob> it's 'option=var'
<X-Rob> it's all throughout the code, and, unsurprisingly, it doesn't work
<X-Rob> Now I'd love to go 'you guys are all on drugs, how did you even write that'
<X-Rob> but before I do, I want to try to figure out if _I_ am the one on drugs.
<X-Rob> https://www.irccloud.com/pastebin/rpia1Knc
<X-Rob> Oh, man, they're quoting it
<danialbehzadi> Hey all,
<danialbehzadi> I have a VPS and want to run some services like Open-VPN on it and access them remotely, and I want to rn them via juju. Which method should I choose to bootstrap? local(lxc) or Maas?
<lazyPower> dannf: you dont want to use local(lxc)
<lazyPower> sorry dannf, misping
<skay> lazyPower: hey, do you know any juju devs who would like to come and give a talk to my linux user group in Chicago?
<skay> I've been learning it, and would like to talk to people about it, but it would be cooler if an experienced person gave a talk
<lazyPower> skay: i would ping the list with that question. Chicago is a bit of a drive for me but there are a few team members in the midwest that could probably make that trip :)
<skay> lazyPower: oh, right. I'll try the mailing list
<skay> we are going through topics we'd like to hear about in the coming months, and I'm making a case for juju, among other things
 * skay is in the tail end of the meeting at the moment
<skay> :)
<lazyPower> skay: when are you looking at having the talk?
<lazyPower> i can bring it up next week at our standup
<lazyPower> and make sure someone at bare minimum responds to the mailing list post
<skay> lazyPower: we meet about once a month. The next meeting might be at the end of january (depends)
<lazyPower> yeah, for sure that wont work for me, i'll be giving back ot back talks here in teh burgh and headed to brussels
<lazyPower> skay: but yeah - hit the mailing list, and i'll circle back on it after i've spoken to my team.
<skay> okiedokie. just mailed
<lazyPower> ta
<skay> I could try to see if some companies here might be willing to cover travel costs
<skay> probably not enough for overseas flights though
<lazyPower> well, we'd be sending someone close to local
<lazyPower> mbruzek lives in minnesota and jcastro is from michigan, both of which are close enough :)
<mbruzek> lazyPower: what are you talking about?
<lazyPower> mbruzek: skay was asking about local's we could send for a meetup - he's posted to the list about it.
<lazyPower> i gave myself a todo to follow up on it on monday
<mbruzek> lazyPower: Be happy to meet up with other Juju users
#juju 2014-12-14
<noodles785> In an email to #juju-dev, sinzui mentions that "and are more
<noodles785> reliable than aws were we often see instances not available"
<noodles785> I was wondering if there was any known work-around for the ec2 issue, as I'm hitting that pretty consistently at the moment.
<noodles785> Out of 9 units, usually one stays pending in juju and the ec2 console shows that it was terminated by ec2 due to an error.
<hatch> hey do we have any haproxy experts around today?
<X-Rob> hatch: I'm not an expert, but ask your question anyway
#juju 2015-12-07
<gnuoy> jamespage, coreycb, fyi https://github.com/juju/charm-tools/issues/69
<jamespage> gnuoy, urgh
<gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/+source/interface-rabbitmq/+git/interface-rabbitmq/+merge/279743 does that address your concerns?
<jamespage> gnuoy, yes
<jamespage> gnuoy, newer odl versions appear to have a way to determine whether they are up or not
<jamespage> https://github.com/openstack/networking-odl/blob/master/devstack/odl-releases/lithium-snapshot-0.3.2#L28
<gnuoy> \o/
<gnuoy> Christmas has come early
<gnuoy> jamespage, why wouldn't I put every possible key the service I'm joining with could throw back at me in auto_accessors ?
<gnuoy> "you would" being the reply I'm hoping for
<jamespage> probably
<jamespage> gnuoy, I'd put auto_accessors in for any key that will be eventually consistent across all remote units
<gnuoy> jamespage, so we should remove 'private-address' then I guess
<jamespage> gnuoy, yeah I guess so
<jamespage> gnuoy, and pick on from the list of hosts for 'host' in the adapter
<gnuoy> jamespage, got a sec for https://code.launchpad.net/~gnuoy/charms/trusty/openvswitch-odl/duplicate-controllers/+merge/279251 ?
<jamespage> gnuoy, I'll peek in a bit
<lazypower> aisrael marcoceppi tvansteenburgh - http://paste.ubuntu.com/13792602/ i appear to have whiffed on making my module extension. Can I bother one of you for help debugging this?
<aisrael> lazypower: the magic is in charms/__init__.py
<lazypower> aisrael https://github.com/juju-solutions/charms.docker/blob/master/charms/__init__.py
<aisrael> and then your code in charms/docker/* will be properly namespaced
<aisrael> That's a bit odd, then. cory_fu might be better suited to help with this. He came up with the original pattern (I think)
<lazypower> aisrael: i'm not entirely convinced, that I have some hinky package setup in this module
<lazypower> fair, ta
<marcoceppi> lazypower: link to your setup.py?
<lazypower> marcoceppi https://github.com/juju-solutions/charms.docker/blob/master/setup.py
<marcoceppi> lazypower: you're missing a packages declaration
<lazypower> Ah!
<lazypower> thanks :)
<lazypower> marcoceppi: I need to declare both 'charms' and 'charms.docker' corect?
<marcoceppi> lazypower: im not sure. it seems wrong, tbh
<lazypower> Declaring both packages in the setup.yaml?
<lazypower> er .py
<marcoceppi> lazypower: yes, seems wrong to me
<marcoceppi> does it work with just charms.docker as the package?
<lazypower> yep
<lazypower> i just veriified in a venv
<marcoceppi> you found your answer :)
<mbruzek> lazypower: and marcoceppi is this package declaration a pip thing, or a pypi thing?
<lazypower> Pip thing
<marcoceppi> It's a python thing.
<lazypower> ^ that
<mattyw> so In my charm's amulet test I do self.d.add("mycharm")
<mattyw> shouldn't that work out what charm it's in and use that?
<mattyw> because I'm getting charmworldlib.charm.CharmNotFound: API request failed: Request failed with: 404
<mattyw> also - if it's using layers, do I have to build the charm first?
<marcoceppi> mattyw: yes you have to build the charm first, for now (?) we've not thought that far
<marcoceppi> mattyw: we'd need a full traceback and the version of amulet you're using
<mattyw> marcoceppi, ok, but there'll be spoilers
<marcoceppi> mattyw: spoilers?
<mattyw> marcoceppi, http://paste.ubuntu.com/13793744/
<mattyw> marcoceppi, you'll know what charm I'm working on ;)
<marcoceppi> WELL NOW THIS LOOKS FAMILAR :)
<mattyw> lol
<mattyw> marcoceppi, 1.12.1
<marcoceppi> mattyw: don't use the charm= commmand
<marcoceppi> mattyw: just d.add('minecraft')
<marcoceppi> charm= overrides the autodetection behaviour, since you've explicitly given it a charm to use
<mattyw> marcoceppi, nope, I get the same thing
<marcoceppi> mattyw: bleh
<mattyw> sorry :(
<marcoceppi> mattyw: Ah
<marcoceppi> have you tried tests/01-listening
<marcoceppi> instead of doing it from within the tests directory
<mattyw> that works
<mattyw> but unit: minecraft/0: machine: 1 agent-state: error details: hook failed: "leader-settings-changed"
<mattyw> is that the charm-tools bug?
<mattyw> actually
<mattyw> ignore me
<mattyw> actually yeah, that does seems like the problem I see now
<lazypower> cory_fu: ping for when you have a moment
<marcoceppi> mattyw: yeah, so amulet assumes the tests is executed from CHARM_DIR, since that's a requirement of all test runners
<marcoceppi> mattyw: what's the error for that say?
<mattyw> marcoceppi, nah - might be me actually
<bloodearnest> marcoceppi, hey there. My code in reactive/foo.py cannot import code from reactive/bar.py, due I think it not being a normal import, rather using manual load_source
<bloodearnest> marcoceppi, if I have some library code for my charm's reactive hooks, where should that live in the charm?
<bloodearnest> fwiw, the code foo can import bar perfectly fine when running unit tests
<marcoceppi> bloodearnest: what are you trying to import?
<bloodearnest> marcoceppi, my own code, just in a different file in the charm
<cory_fu> lazypower: Ok, just finished.  What's up?  Hangout?
<bloodearnest> I can stick it all in the same file, but it would be nicer separate
<lazypower> cory_fu: sure, point the direction
<cory_fu> lazypower: https://plus.google.com/hangouts/_/canonical.com/big-data-sync
<marcoceppi> bloodearnest: well, we've adopted a convention of putting code you want shared between layers in lib/<module>.py
<marcoceppi> eg, the nginx layer produces a lib/nginxlib.py, django has a lib/charms/django.py, etc
<marcoceppi> lib is in the import path for charms, so it works around the entry_point issue
<bloodearnest> marcoceppi, right, sounds like that's what I want. My code is not really for sharing between layers, more for organisation with a layers (and testing usage)
<mbruzek> cory_fu: Getting an error with the wheelhouse, http://paste.ubuntu.com/13794767/
<cory_fu> mbruzek: File "/var/lib/juju/agents/unit-k8s-0/charm/reactive/k8s.py", line 44
<cory_fu> def leader-settings-changed():
<cory_fu> Can't use dashes in function names
<mbruzek> I fixed that in the code, and re-installed
<cory_fu> mbruzek: Also, the error at the bottom indicates that your wheelhouse still contains actual wheels.  Are you on the newest charm-tools?
<mbruzek> cory_fu: possibly not
<cory_fu> marcoceppi: When will the point release of charm-tools be available?
<lazypower> mbruzek: which version of charm-tools are you using?
<mbruzek> charm-tools 1.10.0
<cory_fu> mbruzek: You might need to rebuild your charm from the layer from scratch, or manually remove wheelhouse/*.whl
<marcoceppi> cory_fu: whenever you want me to cut it
<marcoceppi> I was going to wait until 3pm EST but can move to get it out before 2PM
<cory_fu> I think we should probably get it out, since charms being built now are broken because of the newline.
<marcoceppi> cory_fu: ack, will cut asap
<cory_fu> marcoceppi: You're the best.  :)
<mattyw> marcoceppi, has there been a new release of charmhelpers over the past couple of days? install_remote keeps failing for me with TypeError: must be str, not bytes
<mattyw> wasn't doing that last week
<jrwren> mattyw: sounds like its python3 now when it was python2 before?
<mattyw> jrwren, could be - but the charm was working on friday
<mattyw> jrwren, and today it isn't
<jrwren> mattyw: oh, same charm. nevermind.
<lazypower> mattyw: charm-tools revved to 1.10.0 on Friday evening
<lazypower> mattyw: and the base layer was updated in sync w/ that charm tools rel, the hooks are now python3 by default
<mattyw> lazypower, makes sense
<mattyw> lazypower, might be a problem with install_remote then
<mattyw> lazypower, I'm cheating for now
<mbruzek> jcastro: Is the tag named "adoption" no other hyphens or prefix ?
<mbruzek> jcastro: https://bugs.launchpad.net/juju-core/+bug/1495978
<mup> Bug #1495978: Juju does not deploy CentOS images in LXC <adoption> <centos> <containers> <juju> <lxc> <system> <juju-core:Triaged> <https://launchpad.net/bugs/1495978>
<jcastro> mbruzek: yeah
<mbruzek> jcastro: thanks
<jcastro> arosales: I need some graph help if you have a minute
<arosales> jcastro: yo, for sure
<jcastro> https://plus.google.com/hangouts/_/canonical.com/eco-wx?authuser=1
<jcastro> arosales: ^^^
<mbruzek> lazypower: cory_fu found an empty sections on the proposed docs. http://52.0.202.26:8000/en/developer-layers.html  Should "Layer Encapsulation" have a paragraph describing that?
<lazypower> ah yeah, i didnt know what to put there
<lazypower> i forgot to remove the section title/link
<cory_fu> mbruzek: Which branch should I be using?  developer-guide or mbruzek-developer-guide?
<mbruzek> developer-guide
<lazypower> Actually
<lazypower> i dont see encapsulation in the navigation.tpl
<lazypower> :-/
<cory_fu> mbruzek: https://github.com/mbruzek/docs/pull/40
<cory_fu> Hopefully that's on the righ tbranch now
<krondor> what's the story with charmhelpers.fetch.giturl?  Was working earlier in the week, and now fails GitPython does not support Python 3.
<krondor> ahh nevermind I see mattyw seeing similar issues with python 2 to 3 switch.  Any chance we'll see fetch git working again or should I work around?
<cory_fu> krondor: It looks like that assertion is no longer true and GitPython should work fine on Python 3
<cory_fu> In fact, according to https://github.com/gitpython-developers/gitdb/issues/4 it's been supported for 2 years
<cory_fu> Sorry, 1 year
<krondor> cory_fu:  That's the error that fetch threw, but I see now there is an new charm tools as of this afternoon for me.  I'll update again and see if anything has changed.
<marcoceppi> cory_fu gnuoy cmars axw_: charm-tools 1.10.1 is out
<cmars> marcoceppi, thanks!
<marcoceppi> Thanks for the report!
<cory_fu> krondor: It won't have: https://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/fetch/giturl.py#L25
<cory_fu> marcoceppi: Thanks!
<cory_fu> krondor (and also marcoceppi): https://code.launchpad.net/~johnsca/charm-helpers/python3/+merge/279817
<krondor> cory_fu:  Thank you, I'll test
<krondor> cory_fu:  I think it's going to be more involved than that.  giturl tries to apt install python-git which depends on 2.7.  from git import Repo fails with No Module Named 'git'
<cory_fu> Ah.  Shoot
<cory_fu> And there isn't a python3-git packages
<cory_fu> *package
<krondor> cory_fu, right kind of a bind
<bcsaller> iirc our deps on git stuff are very thin and could be handled with subprocess, we don't really inspect the data very much
<cory_fu> True.  I was just hoping it would be a trivial change.  But I guess not
<krondor> bscaller: yeah I'm going back to subprocess at least for the interim
<marcoceppi> +1 on subprocess, the sooner we can drop bzrlib the closer we get to Python3 support
<jrwren> charmers: kindly requeue http://review.juju.solutions/review/2357 please.
<jcastro> krondor: I ran into a snag in magento so you might end up beating me on this
<TheJeff> good day charmers!
<TheJeff> run into an issue deploying things, hopeing you can clarify
<TheJeff> ack in just a few minutes because fire.
<TheJeff> alright I'm back -- so I'm following this here guide:
<TheJeff> https://help.ubuntu.com/lts/clouddocs/en/Installing-OpenStack.html
<TheJeff> I'm at the point where I source novarc
<TheJeff> # nova endpoints <-- execute this, got Invalid Openstack Nova credentials
<TheJeff> now, I'm sure I need to change the novarc file - it's mostly autopoulated
<TheJeff> from that script
<TheJeff> assume its the OS_password variable
<mgz> TheJeff: if you add --debug you can see the actualy request json you send to keystone
<TheJeff> where would one obtain said password?  Is it the one I set in the keystone portion of the openstack-config?  Otherwise its all default afaik, and it's still not working
<mgz> password is what is set up for that user in keystone
<TheJeff> seems that throws the same error though
<TheJeff> assuming its what i set as admin-password: in my yaml when I spun it up
<mgz> nope
<mgz> hm, I can't remember all the details here,
<TheJeff> and nova endpoints --debug throws an error that --debug isnt a valid flag
<TheJeff> can I reset this somehow?
<TheJeff> I'm less concerned with where it went sideways than setting it right side up
<mgz> it's `nova --debug endpoints`
<TheJeff> Could not find user, admin.", "code": 401, "title": "Unauthorized"
<TheJeff> is this perhaps my maas user?
<mgz> TheJeff: see https://bugs.launchpad.net/charms/+source/keystone/+bug/1435906
<mup> Bug #1435906: provide stable mechanism to retrieve admin credentials <keystone (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1435906>
<mgz> look in that file for the real password, /var/lib/keystone/keystone.passwd
<mgz> and yeah, looks like you have the user name wrong too?
<mgz> that's `admin-user` in the charm config
<TheJeff> mgz: admin-user huh
<TheJeff> that's not anywhere in this yaml
<TheJeff> nor this doc :(
<TheJeff> and this workaround you linked states 'use juju-set' -- but that's not a command I've got
<mgz> the default should be 'admin'''
<mgz> TheJeff: it's `juju set`
<mgz> see the help for that, takes a service and config key/value pair
<TheJeff> aha
<TheJeff> so is it OS_PASSWORD I'm setting?
<TheJeff> as is in the nova.rc
<TheJeff> is that the key?  can I list keys?
<TheJeff> juju list|grep user && juju set {} <password>
<TheJeff> ^some way of this???
<marcoceppi> TheJeff: hey
 * marcoceppi reads scroll
<marcoceppi> TheJeff: did you run the script here? https://help.ubuntu.com/lts/clouddocs/en/Installing-OpenStack.html#configuring-access-to-openstack
<TheJeff> marcoceppi: yep
<TheJeff> that populated nova.rc fine
<marcoceppi> TheJeff: does the .novarc file look right?
<marcoceppi> cool
<TheJeff> but it says invalid creds
<TheJeff> actually just sat back down nothing has changed since my last message above^
<marcoceppi> still trying to read through the backlog
<adam_g> TheJeff, the keystone charm generates admin password for you, unless one is configured. try: juju set keystone admin-password=foo
<adam_g> let it run its config-changed hook and that should now be the admin password
<TheJeff> ooo
<TheJeff> ok
<adam_g> update OS_PASSWORD in your envirnment accordingly
<TheJeff> ok ok wait so i actually just ran that shell script again
<TheJeff> and it punched back keystone admin token
<TheJeff> is that it?
<TheJeff> yeah ok so thats a neat thing
<TheJeff> I ran juju set admin-user=admin
<TheJeff> warning: already set
<TheJeff> ran juju set admin-password=<password>
<TheJeff> warning already set (and matches
<TheJeff> source nova.rc
<TheJeff> nova endpoints
<TheJeff> invalid nova credentials :(
<TheJeff> oh.  there's all kinds of bad looking stuff in my juju status
<TheJeff> keystone:      message: 'Missing relations: database'
<TheJeff> rabbit saying           message: 'hook failed: "shared-db-relation-changed" for mysql:shared-db'
<TheJeff> swift saying
<TheJeff>       message: Not enough related storage nodes
<TheJeff> ugh
<TheJeff> related?
<TheJeff> yeah keystone saying           message: 'hook failed: "shared-db-relation-changed" for mysql:shared-db'
<TheJeff> alright, I'm starting over.
<TheJeff> is there a doc that's up to date?  The one I'm following (canonical) mentions deploying quantum-gateway, which juju states is end of life, and deploying openstack-dashboard for example complains there's no config
#juju 2015-12-08
<TheJeff> hey #juju - what's 'Insufficient peer units' mean?  am I falling short here
<jrwren> charmers: kindly requeue http://review.juju.solutions/review/2357 please?
<marcoceppi> TheJeff: what service is saying that?
<jrwren> charmers: i see the requeue happened, but I am unsure about the results. Can someone help me interpret? http://juju-ci.vapour.ws:8080/job/charm-bundle-test-aws/1694/console
<marcoceppi> jrwren: we recently migrated to a new server for all of Juju QA, including charm-testing. This seems to be an issue related to that
<Icey> can you have multiple base layers with install hooks?
<stub> Icey: Yes. You don't know the order they will run though (only that all of the @hook('install') handlers will run before the general handlers)
<marcoceppi> Icey: yes
<Icey> so, new layer charm, any idea why I'd be getting http://pastebin.ubuntu.com/13824394/
<Icey> for some reason it isn't setting up charmhelpers
<marcoceppi> Icey: can you give the entire trace?
<Icey> that's really it: http://pastebin.ubuntu.com/13824600/
<Icey> just pulled out paths
<Icey> I was following the debug log since deploy, that's the first line
<Icey> do I need to actually include charmhelpers in the lib to make sure it's available? most of the other layers aren't doing that so I didn't think it was necessary but it seems to not have charmhelpers available even though I'm suing the basic layer
<Icey> (in another layer)
<Icey> http://pastebin.ubuntu.com/13824666/ is the file with the referenced line failure
<marcoceppi> Icey: can you pastebin hooks/install
<Icey> http://pastebin.ubuntu.com/13824666/ is hooks/install
<Icey> marcoceppi ^^
<lazypower> hmm.. whats this line do? @translate_exc(from_exc=OSError, to_exc=NotImplementedError)
<lazypower> i see it decorating a method in charmhelpers, and its not obvious to me what its doing
<lazypower> i'm guessing if the subprocess.check call is invoked and errors, it acts as a try/catch block and instead throws a different error?
<marcoceppi> Icey: do you have a wheelhouse directory?
<Icey> marcoceppi negative, just wheelhouse.txt
<marcoceppi> Icey: well, that's the problem
<Icey> with requests and shell
<marcoceppi> Icey: what version of charm-tools do you have ?
<Icey> shouldn't the charm build make that?
<marcoceppi> Icey: oh, what does your layer.yaml looks like?
<Icey> charm version charm-tools 1.8.0
<marcoceppi> Icey: do you have a link to your layer?
<marcoceppi> Icey: you need to upgrade
<marcoceppi> charm-tools is currently 1.10.1
<Icey> upgrading now
<Icey> odd thing is I've made a different layered charm that worked
<marcoceppi> Icey: it depends on if it wheelhouses or not
<Icey> ah, I suppose one of the layers I'm using does then?
<Icey> what is wheelhouse?
<Icey> and is it architecture dependant?
<marcoceppi> Icey: yes
<marcoceppi> Icey: no
<Icey> apparently it requires python3 to build now, installing...
<marcoceppi> Icey: the point is a wheelhouse is a better way to bundle dependencies for hooks without having to install the dep in the tree like before but also makes sure that the dep is installed on the system architecture
<Icey> sure, just annoying to have to change build environment so often :-P
<marcoceppi> Icey: well we're still stabilizing the tool
<marcoceppi> Icey: this is us ramping up to a 2.0
<Icey> marcoceppi my client just went wonky, back now (I think)
<lazypower> cory_fu: have we written any interface layers using peer relation(s) that you are aware of?
<lazypower> i scanned the list and didnt see any. i think mbruzek and I are at a point where we're going to pilot this if it hasn't been piloted before
<cory_fu> No, I haven't.
<cory_fu> Sorry, I mean, no I'm not aware of any
<lazypower> ack, *fingers crossed* lets traverse into the dark without a torch
<lazypower> tvansteenburgh marcoceppi : could use a quick review on this one when you get time - https://code.launchpad.net/~lazypower/charm-helpers/payload-tracking/+merge/279927  - it adds the payload tracking bits from the 1.25 release to charmhelpers.core.hookenv
<lazypower> I'm not sure i did this right, i tried to model it off of the leader bits which i know have requirements on which version of juju to use
<lazypower> *min version required
<cmars> i'm noticing a lot of extra packages getting installed in the install hook, in charms built with 1.10.1. can we apt-get install python3-pip --no-install-recommends, would that still work?
<cmars> really don't want g++ on all my charms...
<marcoceppi> tvansteenburgh: still seeing charm testing failures http://juju-ci.vapour.ws:8080/job/charm-bundle-test-aws/1702/console
<tvansteenburgh> marcoceppi: ugh, back to the drawing board
#juju 2015-12-09
<Prabacha> Hi Team, After deploying mariadb charm, i am not able to access the database running the below command.
<Prabacha> i ran "juju deploy mariadb" and sshd to the container
<Prabacha> and ran mysql -u root -p$(sudo cat /var/lib/mysql/mysql.passwd)
<Prabacha> i was getting error statin "ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)"
<Prabacha> could someone help me on this?
<Prabacha> Hi Team, After deploying mariadb charm, i am not able to access the database running the below command.
<Prabacha> and ran mysql -u root -p$(sudo cat /var/lib/mysql/mysql.passwd), i was getting error statin "ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)". could someone help me on this?
<jrwren> charmers: may I please have a rerun once the docker test env is fixed? "Error response from daemon: Unknown filesystem type on /dev/mapper/docker-253:16-9412611-76217dce5f7b552422b80917c9234a0da3415990afc0afb82c07b3c46c13865a-init  http://review.juju.solutions/review/2357
<tvansteenburgh> jwren: queued
<jrwren> tvansteenburgh: thanks!
<apuimedo> lazypower: is there a way to retrigger a hook afer doing "resolved" ?
<lazypower> apuimedo: juju resolved --retry
<apuimedo> :-)
<lazypower> apuimedo that will re-execute the last failed hook, but if you've simply juju resolved, it will progress on
<lazypower> you'll have to trigger the hook via conventional means, such as changing config or changing relations
<apuimedo> cool
<apuimedo> that's what I usually do, use the conventional means
<apuimedo> lazypower: can I just do a suggestion for the cli team?
<apuimedo> I don't know who's the right person
<apuimedo> but basically
<apuimedo> juju ssh name-of-the-charm should resolve when there is only one unit
<apuimedo> instead of complaining that the unit name does not exist
<apuimedo> I can't typo anymore
<lazypower> apuimedo: protip: dhx solves that for you
<lazypower> but a bug against that would be totally appreciated
<lazypower> thats a bite-sized bug
<stokachu> hi all, i wrote an email discussing ways to cater more to the application developer, https://lists.ubuntu.com/archives/juju/2015-December/006186.html
<stokachu> please have a look and provide your feedback
<beisner> hi marcoceppi, tvansteenburgh - can you re-trigger tests for this?  i get 404 for results.  or lmk if i can retrigger somehow via review.juju.solutions.   tia!   http://review.juju.solutions/review/2348
<tvansteenburgh> beisner: done
<beisner> tvansteenburgh, thx!
<cory_fu> mbruzek, lazypower: So, bcsaller pointed out to me that there is a much simpler way to model your leader vs follower roles for the TLS layer
<lazypower> cory_fu: we tried it that way
<lazypower> theres still no good way to hand back a CSR via just leadership
<lazypower> ben and i had drinks over this in seattle
<cory_fu> lazypower: You don't need to pass CSRs around at all
<lazypower> how else is the leader going to sign the services cert?
 * lazypower is not understanding
<cory_fu> lazypower: Just make the leader solely responsible for creating and signing CSRs and it only needs to send the signed cert over the relation
<lazypower> you still need the server.key from that remote unit to generate a proper csr
<lazypower> if that were the case, you wouldn't ever need to submit a CSR to a commercial CA
<lazypower> you would just buy, receive, and drop in apache
<cory_fu> lazypower: Except that in our case, we control both ends.  So the leader can create the server.key and send it along with the signed cert
<lazypower> hmmm
<lazypower> maybe
<lazypower> i haven't tested that, but i' gonna say spidey sense says there be dragons there
<cory_fu> Obviously, it wouldn't work with if the leader were instead a public CA, but since it's just a unit of our service, then it can be in charge of both the server.keys and the signing.
<cory_fu> Let's say the leader were sending out CSRs to a public CA instead of self-signing.  It can still create a server.key and CSR for each follower, send the CSR to the public CA, and then give the server.key and signed cert to the follower
<cory_fu> I think the only case where that would break down is if you wanted to re-sign with the same server.key after a leader change
<cory_fu> But that's only an issue because "data sent from leader to follower" doesn't persist after a leader change.  You could work around that by storing the server.keys in the leader data, but you'd have to create your own mapping of followers to server.keys
<lazypower> tbh, i dont think thats any simpler/easier
<lazypower> its not very redundant
<lazypower> the fact we're generating csrs on the unit, and then shipping @ a leader, seems to me like its the 'right way' to do it
<lazypower> and as long as that CA cert doesnt expire/change, we're in the clear with what was prototyped
<cory_fu> Why does it need to be redundant?
<lazypower> i dont know, it sounded like a great supporting adjective?
<cory_fu> lazypower: I'm not saying that the way you have it now won't work, but I do think it would be simpler (at least in the interface layer) if it were just the leader telling the followers what they need to know (removes the back-and-forth aspect)
<cmars> speaking of certs... is anyone working on a layer for let's encrypt yet? that would be *awesome*
<marcoceppi> cmars: not yet, but mbruzek and lazypower are working on a general TLS layer
<lazypower> cmars: i'm willing to sponsor you with a pizza if you want to write that layer
<lazypower> cmars: the catch is you have to consume the tls layer matt and I are writing....
<marcoceppi> lazypower: no idea if there's a hostname charm-helper or not
<lazypower> marcoceppi: you read my mind
<lazypower> ta
<jhobbs> when i deploy a charm on wily in an lxc, charms.reactive gets installed for python3.5, but my install hook from 'charm build' is using 'python3' in the shebang, which by default points to python3.4 on wily, causing it to not be able to find charms.reactive
<jhobbs> is there a good way to fix this (better than hand editing my generated install hook)?
<jhobbs> bug filed: https://github.com/juju/charm-tools/issues/78
#juju 2015-12-10
<apuimedo> jamespage: I just stumbled upon a weird neutron-api behavior on kilo
<jamespage> apuimedo, oh yes
<apuimedo> for some reason, it was failing with an ml2 message
<apuimedo> when the plugin configured was midonet
<apuimedo> I did `sudo service neutron-server restart` and it worked
<apuimedo> jamespage: http://paste.openstack.org/show/481451/
<apuimedo> also, the public network was not created
<apuimedo> http://paste.openstack.org/show/481452/
<jamespage> apuimedo, that first error normally indicates that the db was not syncs when the daemon was started
<apuimedo> jamespage: is that a known issue when deploying with bundler?
<jamespage> apuimedo, no
<apuimedo> I'm not running from master, it's backport from a month or two back
<apuimedo> jamespage: do you envision any possibility of a race between mysql and neutron?
<jamespage> apuimedo, we have had issues with grants in HA configurations in the past but those where resolved issues - they materialized as db syncs failing, not failing daemons
<apuimedo> jamespage: non-ha deployment
<jamespage> def not then
<apuimedo> I'll try to reproduce it
<apuimedo> on a clean env
<jamespage> thedac, gnuoy: landed the haproxy configuration and defaults bump
<gnuoy> jamespage, tip top, ta
<jcastro_> https://aws.amazon.com/blogs/aws/new-aws-price-list-api/
<jcastro_> https://bugs.launchpad.net/juju-core/+bug/1524823
<mup> Bug #1524823: Support AWS price API <juju-core:New> <https://launchpad.net/bugs/1524823>
<jcastro_> FYI folks
<mbruzek> cory_fu: I have a question about reactive
<mbruzek> cory_fu: Going back to the peer situation where there are more than one unit of the service.  If one peer sets a state X and have a method react to that state, and at the end remove state X.  Will the other peers have a chance to react to the state X ?
<cory_fu> mbruzek: States are entirely a local construct.
<mbruzek> cory_fu: hrmm... So if a leader sets state X the followers will not see that right?
<cory_fu> mbruzek: That is to say, states set on unit A are only ever visible on unit A, but they can be set on unit A "in respect to" unit B if they are set from a relation class in response to information coming over the relation
<cory_fu> Correct
<mbruzek> cory_fu: thank you for the explanation
<cory_fu> mbruzek: Data comes in to the leader over the relation, and the leader says to itself, "Ok, from my perspective, unit B is now in state 'foo' which means it has sent me a CSR and is expecting me to sign it."  The charm layer can then go, "Ok, for all followers that I consider to be in state 'foo', give me their CSR and I will sign it and send it back"
<mbruzek> cory_fu: I was looking at a much more straight forward case.  When the leader changes the CA I was looking at setting a state for the followers to react to, but it is not needed because I can handle this logic in leader_settings_changed()
<cory_fu> mbruzek: This is confused somewhat in your case because the peer relation is *also* handling the follower case, so it also has to implement the follower saying to itself, "Ok, I now see a leader, so I'm in state 'connected' which means to me that I need to create a CSR to send to the (one) leader"
<cory_fu> mbruzek: You know, leader settings is kind of like its own relation, that you could model as a GLOBAL scope pseudo-interface
<jcastro_> hey jose, how would you feel about redoing the owncloud charm in reactive? It should be way simpler than what it currently is
<jose> jcastro_: I don't know reactive (but I guess I can learn soon), it may take a bit. I can work on it after finals maybe?
<jcastro_> yeah no rush or anything
<jose> cool
 * jose rushes to university
<jcastro_> like, I just think the old charm fundamentally won't be interesting to owncloud
<jcastro_> but with the new framework and attached CI, etc. it's way more compelling.
<apuimedo> jamespage: could you take a look at https://code.launchpad.net/~celebdor/charm-helpers/midonet/+merge/274543
<thedac> jamespage: thanks for landing the haproxy timeout fixes
<jamespage> thedac, no problemo
<jamespage> apuimedo, took and initial glance - some unit tests for the new context and the kilo specific behaviour would be nice ;-)
<apuimedo> jamespage: understood. Can you please put it on a review comment?
<apuimedo> otherwise when I get to it I might forget :P
<jamespage> apuimedo, done
<apuimedo> thanks a lot jamespage
<beisner> o/  tvansteenburgh - ping re: pending tests for http://review.juju.solutions/review/2348 ... if it's just a wait-in-line thing, no prob.
<beisner> tvansteenburgh, so if i intend to do that review, should i have the padlock locked?
<lazypower> beisner: yeah if you're working a review
<lazypower> sign into the RQ, and click the lock button next to the item so nobody else snipes it out form under you
<lazypower> i've done that to jose on more than 10 occcasions now
<beisner> ha, thanks
<beisner> lazypower, well, i'm re-running tests in uosci, and have the same pending in charm ci, so it'll prob be tomorrow before i revisit.  should i still lock?
<lazypower> I would
<beisner> ack, thx sir
<lazypower> if someone wants ot review it, they will ping ya asking if its ok
<lazypower> i tend to get these long drawn out reviews for new stack items, and the big data team always laps me on the RQ. so i get pings now and again asking if i'm actually reviewing something or if i'm playing the "lock the review and pretend" game
<lazypower> which i'm good at too
<tvansteenburgh> beisner: re pending tests, it's b/c the revq went offline last night and the celery jobs haven't brought things up-to-date yet.
<beisner> tvansteenburgh, np at all.  i'll revisit tomorrow.  thx for the update.
<tvansteenburgh> beisner: here's the lxc jenkins log if you need it in the meantime http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/1757/console
<beisner> woot DEBUG:runner:KeyError: 'rabbitmq-server/0'
<beisner> tvansteenburgh, basicall all openstack charm tests will hit that, as we destry/bootstrap on every iter.
<beisner> tvansteenburgh, i saw a bug with plans to parse that instead of returning key error.  is that going forward?
<tvansteenburgh> https://github.com/juju/amulet/issues/111
<beisner> yeah that ;-)
<tvansteenburgh> yeah, just needs to get dove
<tvansteenburgh> done
<tvansteenburgh> wanna do it? :D
<beisner> want > bandwidth
<beisner> ok so, no expectation for that charm test to pass in charm ci, but should be expected to pass in uosci since each test gets a fresh bootstrap.
<cfx> lazypower: Been awhile since I've been summoned to IRC. :)
<lazypower> cfx o/
<lazypower> hey there
<cfx> hola
<lazypower> Its a classic, thats for sure :)
<cfx> Truthy statement.
<cfx> I feel as though I've been a big, big nuisance through all this.
<cfx> But you've been tremendously welcoming.
<lazypower> Not at all, you've been curious, and I just so happen to have some answers for you :)
<cfx> :D
<lazypower> We appreciate the review on teh docs as well. big thumbs up on diving into that
<mbruzek> Hello cfx
<cfx> Plenty willing to keep going. I'm booked really solidly through Sunday but this is super high priority for me.
<cfx> mbruzek: yo!
<TheJeff> hey #juju
<mbruzek> cfx It will take some time to action on the feedback you gave me, as I am working on something else right now, but we will get to it soon
<mbruzek> Hello th
<lazypower> cfx: looking over that last correspondence, it looks like there's a lot of overlap between what we already have charmed up in the charm store, with some additional proxy charms for the CDN, and charming up wowza
<lazypower> should be pretty straight forward, I'm willing to bet we could get you moving in a month or less
<mbruzek> hello TheJeff
<lazypower> TheJeff o/
<TheJeff> lil help?  I've run through the openstack juju deploy guide (this has taken me quite some time over the past few days)
<cfx> mbruzek: oh sure, take your time. I'm just playing the part of the highly-confused newbie.
<lazypower> TheJeff: please state the nature of your IT emergency :)
<TheJeff> openstack-dashboard is up, seems my  units are running (juju status)
<TheJeff> i'm presented with a login, I log in using creds from my config yaml
<TheJeff> and it boots me over to an error page
<cfx> lazypower: I'm sure I can get a little extra leeway if my boss knows I'm engaging experts. :)
<lazypower> so far so good
<TheJeff> `Something went wrong!
<TheJeff> An unexpected error has occurred. Try refreshing the page. If that doesn't help, contact your local administrator.`
<TheJeff> BUT THAT IS ME!
<cfx> TheJeff: Hate it when that happens. :(
<TheJeff> so, looked at the apache logs on the openstack-dashboard unit, looks fine - 302s and 200s flowing like fine wine
<lazypower> beisner ddellav: when logging into horizon, whats the best route to go debug login errors that are not 401 unauthorized?
<TheJeff> but where do I find logs that can lead me with delicious bread crumbs to where my problem lies?
<lazypower> TheJeff: nice use of adjectives. I approve
<TheJeff> some app level issue I assume, can't hit this or that
<lazypower> I'm not sure why, but i'll see if we cant get an openstack expert to lend some eyeballs
<TheJeff> :(
<TheJeff> I have to demo an openstack install via juju at 3.
<TheJeff> ugh
<TheJeff> Toronto time
<cfx> I'm gonna head to lunch here in a sec. lazypower, you pretty much know the score. I'd like to have something to SAY by Sunday. I'd like to be UP by the beginning of the year if at all possible. Completely open to what to do next.
<lazypower> cfx: lets model your infra in juju :)
<cfx> Right now I'm planning on continuing reading as I can, and continuing with the feedback. That seems like progress in itself.
<lazypower> cfx: i'm going to head to lunch. first step is figure out what we have provided that you'll need up front, and build a bundle with those services
<lazypower> we can do a planning session to fill in the gaps with services we dont yet have charmed
<cfx> lazypower: lunch indeed. reconvene in a bit?
<cfx> what's the first URL I'm going to stare crosseyed-at?
<lazypower> then we'll do a charm school, write those layer(s), and talk deploy strat :)
<lazypower> http://jujucharms.com/demo
<cfx> iloveyousomuchrightnow
<lazypower> or just jujucharms.com and click over in teh store
<lazypower> O_O
<lazypower> and on that note, time to feed my face
<cfx> lol
<lazypower> TheJeff: sorry i'm not much mor ehelp than pinging. but if they can they'll lend a hand
<jcastro_> TheJeff: please start posting on juju@lists.ubuntu.com, that'll help get other eyeballs to bear if you're time constrained
<beisner> lazypower, TheJeff -  i'd start by checking `juju stat --format tabular` for sane "Unit is ready" extended workload status
<beisner> that will be an indicator that all required relations are made
<beisner> lazypower, TheJeff - horizon logs will be on the openstack-dashboard unit(s) in /var/log/apache2/  ... keep in mind that horizon heavily queries nova-cloud-controller, so logs on that unit in /var/log/nova may also be indicative.
<Prabakaran> Hi kwmonroe, I was referring azuls zulu8 java layer charm, apart from reactive directory which does actual installation of zulu8 i noticed that some additional directories and code files like hooks, wheelhouse,  .build.manifest,  .gitignore, Makefile, tox.ini, etc  .... i was wondering should i include all these layered specific files even for ibm java charm also.. could you please explain about these files and advise on the same?
<mgara> gents
<mgara> I'm using my openstack installation and I want to bootstrap juju using that installation ... I made sure to put all required configs .. but when I run juju bootstrap it returns some error .. that it may looks familiar to you :
<mgara> ERROR failed to bootstrap environment: index file has no data for cloud {RegionOne http://172.16.45.11:5000/v2.0} not found
<mgara> do I need to modify something in my config ?
<mgz> mgara: how did you tell it which image to use?
<mgara> that's the thing .. i dont get where to put the image i want ...
<mgz> mgara: you need to generate an image stream, and set image-metadata-url to point to it
<mgara> ok cool ill try to digg more  thanks mgz !
<mgz> marlinc: see `juju metadata help generate-image`
<mgara> thank you !
<mgz> that creates a dir structure with some json, which you then need to host somewhere both your client and the openstack install can see
<mgz> swift will do if you can expose over http or similar
<mgz> mgara: see https://jujucharms.com/docs/1.25/howto-privatecloud for more
<mgz> the tools you can just get from streams.canonical.com if you have a route out to it.
<mattrae> hi i'm using juju 1.25.. i'm seeing that 'juju status <service>' is hanging forever
<mattrae> juju status <service> used to work a few min ago..
<mattrae> now only 'juju status' works
<mattrae> any ideas what might be wrong?
<mattrae> i've also noticed that when 'juju status <service>' does work, it is about 10 times longer responding than just running 'juju status', depending on how many units are deployed
<lazypower> weird
<lazypower> mattrae: is your model controller under high load? (eg: node 0)
<mattrae> lazypower: we're using ensure-availability with 3 nodes. i checked at least 2 and didn't see a high load.. they're also 20 core machines
<lazypower> yeah that seems beefy enough to run a pretty sizeable infra
<lazypower> as i understand it, when you're querying an individual node, its just poking @ the mongo data store to return status data....
<lazypower> mattrae: I would certainly file a bug about this, it may be a regression in our HA as of 1.25
<lazypower> we may need to extend test coverage around that
<lazypower> i'm sure we have it but it could probably be perf tested as well
<mattrae> i tried restarting the juju machine agent and juju-db. now i'm redeploying and i'll see if i run into the same issue. i also collected the logs from /var/log in case that is helpful
<mattrae> lazypower: cool i'll collect some more information and file a bug
<lazypower> mattrae: thanks for the debug effort, sorry you ran into that :-/
<mattrae> sure no problem :)
<mattrae> thanks for the help
<mattrae> lazypower: looks like the bug is reported in lp:1516989 and should be fixed in 1.25.2
<lazypower> mattrae: nice work
<mattrae> thx :)
<cfx> drac, boot, system setup, PXE, MAAS, drac, boot, system setup, PXE, MAAS...
<cfx> mass maas commission! bwahaha
<cfx> ahem.
<cfx> lazypower: so, since a search on demo.jujucharms.com for the software package we were discussing before doesn't appear to exist... the most I was able to do was add hardware to the sandbox and sit here, confused :)
<cory_fu> stub: You around?
<cory_fu> Oh, nm, of course not
<lazypower> arosales allow me to introduce you to cfx
<arosales> cfx: greetings! I was just commenting to lazypower on the great comments @ https://github.com/mbruzek/docs/issues/41
<arosales> cfx: thanks for taking some time to give feedback on making the docs better
<cfx> arosales: Oh any time. Since the feedback has been so positive I plan on continuing.
<cfx> Headed home to tackle the next section, actually!
<arosales> cfx: excellent, I just wanted to thank you for your contributions to the community and working to make developing charms easier for everyone
 * cfx salutes crisply!
<cfx> My pleasure.
<cfx> bbiab
<Icey> in the ruby juju layer, any opposition to using https://github.com/postmodern/ruby-install instead of building from source?
<lazypower> Icey: i've used the brightbox ppa's, and rbenv - i'm not opposed to anything at this point wi th ruby to be completely honest
<lazypower> what may be a good idea is to kind of get a pulse with the ruby community by pinging their mailing list, and asking what they're using
<Icey> I figure, with ruby-install, we can allow the user to choose a ruby version still and build as needed, but if there's a binary already out there, then we get to skip the 15 min compile time...
<lazypower> i'm + for that
<Icey> and it doesn't mean leaving a lot of stuff around on prod boxes as much
<lazypower> i like how its senses the env and uses whatever native package manager is
<Icey> yea :)
<lazypower> then uses build as a fail-safe fallback
<lazypower> i'm +1 to this
<lazypower> all the way
<Icey> I'll take a look at it soon, build time for this charm is quickly getting annoying enough to give that a priority :)
 * lazypower anoints Icey with the juju 
 * Icey ewwwww
<lazypower> so, what that translates to Icey  since you went there with it, is I took the juju logo and beat you about the head and shoulders with it
 * Icey collapses unconscious into the dust
<Icey> lazypower lazier version, download the binary ourselves from https://rvm.io/binaries/ubuntu/14.04/x86_64/ ?
<lazypower> You've immediately lost compat on centos
<Icey> well
<lazypower> which not a *Terrible* loss, but a loss all the same
<Icey> https://rvm.io/binaries/
<lazypower> i tend to favor cross platform solutions if they are avail
<Icey> fair enough
<Icey> it looks like ruby-install will still be building on the box
<Icey> RVM will let us get premade binaries
<lazypower> blurg
<lazypower> cory_fu: you were looking to see if there's an easy way to discern over a relation if a unit is talking to the leader?
<cory_fu> Any way, but yes
<lazypower> more eyeballs here :) thats all, migrating the topic
<cory_fu> I suppose the leader could set a flag on the relation saying that it's the leader, but is there a way built in to Juju?
<marcoceppi> cory_fu: I think the only way would be `relation-set captian="i am, now"`
<marcoceppi> where the leader announced over peer, unit-get leader might be a good way around this
<marcoceppi> cory_fu: oh
<marcoceppi> cory_fu: leader-set unit="$JUJU_UNIT_NAME"
<marcoceppi> use leader settings to define it
<lazypower> marcoceppi: i'm guessing use that in tanem with $JUJU_REMOTE_UNIT
<lazypower> to determine if we are indeed talking to theleader
<marcoceppi> lazypower: yeah, so during leader-elected, have it set that, which should run before peer relations on first go
<lazypower> right
<marcoceppi> then you can do if [ `leader-get unit` == $JUJU_REMOTE_UNIT ]
<marcoceppi> not pretty, but it's better than peer setting the information
<lazypower> i agree 100%
<lazypower> peer setting the information seems like it could be messier in terms of when the leadership changes
<cory_fu> marcoceppi: So you're saying that leader-settings-changed would be guaranteed to run before peer-relation-joined?
<marcoceppi> cory_fu: no, but leader-elected will most certainly run /the first time/ before any relation does
<marcoceppi> since it's part of the standard hook lineup
<lazypower> yeah, thats true
<lazypower> install -> leader-elected => confg-changed => relations if applicable => start
<marcoceppi> once that hook sets the unit, any other hook on any unit that run will see the new value
<marcoceppi> well, config-changed -> start -> other
<lazypower> no idea why i changed hashrocket symbol after the first, but i digress
<lazypower> not always marco
<marcoceppi> lazypower: i balk, really?
<lazypower> if you add-relation before its stood up, it seems to run relations before start.
<marcoceppi> rofl, funtastic.
<lazypower> ^_^
<lazypower> seems legit
<lazypower> hook order is never garanteed *ice skates away*
<marcoceppi> I was under the impression `juju deploy` queued install -> leadership -> cfg -> start
<marcoceppi> yes, it's not, but I digress
<lazypower> to be 100% fair, i haven't tested that assertion since the 1.23 series
<cory_fu> I feel like, in this case, it might actually make more sense to send it over the peer relation.  In terms of the conversation flow, the leader would start the conversation by saying, "I need a CSR from you" to any peer that joined, to which the follower could reply.  I think that's cleaner than every peer telling every other peer that it wants that peer to sign a cert
<lazypower> it may have been patched
<cory_fu> lazypower, mbruzek: ^
<lazypower> cory_fu: that makes sense, its not like the units are having a gpg key signing party
<lazypower> which i never get invited to ;_;
<marcoceppi> lazypower: fosdem!
<lazypower> marcoceppi: we gonna GPG key signing?!
<marcoceppi> cory_fu: what's the problem with every peer getting a copy of the CSR?
<marcoceppi> lazypower: there's one every year
<lazypower> schwing!
<marcoceppi> lazypower: https://fosdem.org/2016/keysigning/
<mbruzek> cory_fu: thanks, that will take a bit of refactoring but I think that could be done
<marcoceppi> mbruzek cory_fu I still don't see the problem with every unit sending it's CSR
<marcoceppi> other than a bit more noise
<marcoceppi> peer-relation-changed is basically "am I the leader? Nope, I don't care exit 0"
<cory_fu> marcoceppi: Well, there's nothing really wrong with it, I suppose
<marcoceppi> and peer-relation-joined is basically BLAM BLAM BLAM HERE'S MY CSR
<mbruzek> marcoceppi: but every peer will send a csr to ever other peer
<mbruzek> marcoceppi:  think of the children!
<marcoceppi> but every peer will already make a connection with every other peer
<mbruzek> marcoceppi: Lets say there are 1000 peers
<lazypower> hide you kids, hide yo wife, we're generating tls certificates over hereeee
<marcoceppi> it's not really saving much more or less
<marcoceppi> data wills till be sent, hooks will still fire
<mbruzek> if 1000 peers are sending certs to the 1000 other peers
<marcoceppi> because each charm has a relation-joined and changed
<mbruzek> that is like 1000x100
<mbruzek> 0
<marcoceppi> mbruzek: but the thing is, that /already/ happens
<lazypower> marcoceppi: i think part of the concern here, is to reduce noise whend ebugging
<marcoceppi> also, it's a factorial
<lazypower> the csr => leader should be a one shot for each node, not a one shot and then dancing with the rest of the group
<lazypower> while its not critical that its happening, it does make sense to reduce that noise on the wire
<marcoceppi> sure, it would cut down a bit, but each peer would still ahve their relation-joined and relation-changed fired because juju implicitly sets the private-address
<marcoceppi> so you're not really reducing much noise
<lazypower> eh, i guess thats fair too
<lazypower> where's my marco meme images... this needs to be a meme
<marcoceppi> my point is, this level of complexity isn't really much of a save
<cmars> i'm seeing some weird behavior with my reactive charm. everytime the update-status hook runs, it also runs all my relation handling functions
<cmars> which is kind of bad, because those functions basically rewrite the config and restart the service
<cmars> any ideas what could be causing this?
<lazypower> cmars: this was recently changed, the update-status hook wasn't implemented in the previos editions of built charms
<lazypower> it was just added this week i do believe, so now its triggering all your state changes you haven't guarded against
<marcoceppi> cmars: because each hook runs the reactive bus
<marcoceppi> so those states match
<marcoceppi> cmars: you should create a state like "charm.done" where you can decorate @when_not('charm.done') to avoid it being processed multiple times
<cmars> ah, got it
<marcoceppi> <service>.ready is another, better name
<cmars> thanks
<marcoceppi> cmars: the update-status hook was debated on being added, and ultimately incldued because it helps illuminate this problem. Your relation stuff willa ctually run on each hook after the states are matched sicne states and hooks are evaluated on each hook execution
 * marcoceppi creates some docs on this point to help illuminate it more since it also caught me off guard
<marcoceppi> lazypower: about the keysigning, do you want to go? I didnt' go last time but kind of wanted to
<marcoceppi> web of trust, etc etc
<lazypower> Yeah man, i'm game
<marcoceppi> cool
 * marcoceppi submits his key
<mbruzek> marcoceppi:  is there a list for the kesigning party?
<marcoceppi> mbruzek: https://fosdem.org/2016/keysigning/
<marcoceppi> just follow the instructions
<cmars> marcoceppi, i still don't see how I can tell the difference between an actual change in the relation data vs. update-status just calling my handler
<marcoceppi> also, we should all sign each others keys the next time we sprint, help build that web of trust
<marcoceppi> oh, hum
<marcoceppi> cory_fu: ^
<lazypower> cmars: the relationship wont execute if the data is the same ;)
<lazypower> cmars: fire off a charm, relate it to something, then try to invoke a re-run using the same rel data, it wont happen
<cory_fu> cmars: You shouldn't care if you're in a relation hook or update-status.  If you need to know if the data changed, use the data_changed helper
<cmars> cory_fu, how do I use data_changed?
<marcoceppi> cory_fu: the point cmars was making, is that on each hook he's getting the relation state evaluated as true
<cory_fu> cmars: But, really, the interface layer should be managing the conversation flow and you should just be able to respond to the states it sets
<cmars> i saw mention of that in the base layer README, but didn't see docs
<marcoceppi> so I recommended a .ready state for the charm, but that won't trigger if there's relation data changed
<lazypower> marcoceppi you could remove the .ready state if the rel data has changed
<marcoceppi> lazypower: but the interface should do that
<marcoceppi> I shouldn't have to
<lazypower> not necessarily
<lazypower> your interface is talking about relation data comms, the charm.ready state has zilcho to do with that
<lazypower> thats you as teh charm authors responsibility to listen to those states coming from the interface layer, to determine if you need to alter state in your charm layer.
<marcoceppi> right, but now my layer has to watch for changed_data on the relation, which the interface should be doing
<cory_fu> cmars: https://pythonhosted.org/charms.reactive/charms.reactive.helpers.html#charms.reactive.helpers.data_changed
<lazypower> or, @when('interface.didsomething')
<lazypower> def destroy_state(): remove_state('things')
<cory_fu> cmars: Basically, give it a unique ID and the data
<cmars> cory_fu, ... and it'll track subsequent calls with that ID as a key into some lookup table?
<cory_fu> cmars: Also, your charm layer can set states to tell itself that it's already done a task and then use @when_not
<lazypower> marcoceppi: with what i've proposed, your'e still using hte interface states to determine if your charm layer has to do something. its not listening to the data coming over the wire.
<cory_fu> cmars: Yes
<cmars> cory_fu, ok, that'll work
<cory_fu> cmars: It computes a hash of the (serialized) data and stores that
<marcoceppi> cory_fu: ah, so you could just compute if the relation data has changed in your layer to take action, other wise just noop?
<cory_fu> Ye
<cory_fu> Yes
 * marcoceppi likes
<lazypower> seems wrong if your charm layer is doing communication state alteration. just sayin
<cory_fu> lazypower: What do you mean, communication state alteration?
<lazypower> data changing is related to the interface, not the charm layer.
<lazypower> if you're probing for data changed in teh charm layer, you're doing it wrong
<marcoceppi> lazypower: I disagree
<cmars> the problem is, i have handlers triggered on @when states change. those states are set by relations. yet suddenly update-status started calling them too
<cory_fu> lazypower: I'm not certain that I agree
<cmars> i think that's wrong
<lazypower> cory_fu: this was prety specific to marco's question. and i may be misinterpreting what he was saying.
<cmars> because those states aren't changing
<cory_fu> marcoceppi: Ha.  I told you people would get bitten by update-status calling their handlers.  ;)
<marcoceppi> lazypower cmars right, states are set and persist beetween runs, teh interface says "all the data required to satisfy this are now here"
<cmars> or are we supposed to be tolerant of bounces? i could see that.. "at least once" is a common thing you have to deal with
<cory_fu> cmars: The states aren't changing, but they are active.  As long as they remain active, the handlers will get called.  So your handler needs to tell the interface class that it handled that state if it's not intended to be persistent
<lazypower> so, you're telling me that if in your charm layer, you're checking against data thats coming from, lets say the interface is a data-bag, - and you're altering a state that the interface sets from yoru harm layer, that you're doing it right?
<cmars> cory_fu, and they'll get called on each hook execution?
<lazypower> you've broken encapsulation of what the interface is doing for your in the first place
<cory_fu> Yeah, what marcoceppi said
<marcoceppi> they're states, not events. So you could/should probably just unset the state when you're done?
<cmars> ah
<cmars> i see
<marcoceppi> cory_fu: would it make sense to do something like remove_state('database.available') ?
<cory_fu> The states from the interface are telling you that your relation conversation has progressed to a certain point.  It's up to you what to do with this information, and to only do it once if you care about that
<marcoceppi> cory_fu: in the layer
<cmars> i guess i was thinking "events", but its more like a handoff. you set a state, someone else has to clear it
<cmars> ok
<cmars> :)
<cory_fu> marcoceppi: I don't think the charm layer should be removing interface layer states.  Instead, it should tell the interface class that it's handled the state via a method which would then remove that state
<marcoceppi> cory_fu: that's what I figured
<cory_fu> Because the state is actually associated with a conversation, of which there could be more than one
<marcoceppi> cory_fu: none of our itnerfaces do that currently
<cory_fu> The one lazypower and mbruzek are working on does
<cory_fu> And at least one other one I wrote did.  Let me find it
<lazypower> cory_fu: that i agree with, as its a conversation exchange vbetween the charm layer, and the interface layer. Having the charm signal to the interface to remove a state is what i would say to be the correct way to do it.
<marcoceppi> cmars: which interface is this for?
<cory_fu> Yep
<cmars> mongodb
<lazypower> but just removing that state whollly during the charm layer execution, nah
<lazypower> thats wrong
<lazypower> you jsut took control of something that should be encapsulated and encouraging that behavior may have unintended side effects
<lazypower> such as data not being cleaned up, connections not closed cleanly, backups not made, etc.
<marcoceppi> right, I was trying to make that piont earlier
<cory_fu> marcoceppi: https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L50
<lazypower> marcoceppi: yeah i thought i might be misinterpreting what you were saying, which is why i was making a case against it. <3
<marcoceppi> but, tracking the relation data in the layer and asserting it has changed is not a mutation of the interface or the state
<lazypower> eh
<lazypower> ehhhhh
<lazypower> you in the charm layer, shouldn't give a fig about that tho should you?
<marcoceppi> cory_fu: but that's for provides, do you ahve the aternative? the requires side?
<lazypower> the interface should be responding to data changes and emitting states to that effect.
<cory_fu> marcoceppi: It's the same pattern, though?
<marcoceppi> cory_fu: otherwise {mysql}.available is always set
<marcoceppi> cory_fu: and will always be true on each hook execution
<cory_fu> marcoceppi: And that makes sense, because mysql has not gone away
<marcoceppi> cory_fu: yes, but then you'd have to do one of two things
<marcoceppi> cory_fu: either you create a new state, 'charm.done' and assert @when_not
<marcoceppi> hwoever, if MySQL updates the conversation there's no way to re-execute since it's still available
<marcoceppi> or you do what you said about asserting if the conversation data has changed in the method decorated with the @when {mysql}.available which lazypower doesn't agree with
 * lazypower tries to look intimidating
<marcoceppi> its eems there is almost a need for an "event" of "oh, hey yo data changed"
<marcoceppi> so I could see the itnerface layer tracking data internally, using the method you shared earlier
<lazypower> what i think it should do, and feel free to tell me otehrwise - is as you jsut said set a state that the data has been changed, and your charm layer, should signal back ot the interface that the state has been handled and to remove it
<marcoceppi> and on realtion-changed, and if after available was set, if the data has changed, set a {mysql}.data-changed that you could call a mysql.acknowledge() method on to remove later
<cory_fu> marcoceppi: I tried at one point to have the interface layer do the data_changed checking but ran into some obstacle because of the fact that there's multiple conversations.  But it might be worth revisiting
<lazypower> oh snap, cory_fu  - thats a good point
<lazypower> this does get hairy when you're doing multiple conversations on a unit scope
<cory_fu> It certainly does seem doable
<marcoceppi> cory_fu: potentially
<marcoceppi> cory_fu:what would that look like?
<lazypower> actually, i change my vote
<lazypower> i just advocated for 30 extra lines of code to accomplish what 2 could do
<lazypower> and i dont want to write 30 lines of code what 2 can do.
<marcoceppi> yeah, I think it's up to the interface author to make the call of how to handle data change
 * lazypower switches off and goes back to his editor
<lazypower> sorry for the noise, it sounded way better until i sktched what it looks like in pseudo code
<mbruzek> marcoceppi, lazypower, cory_fu:  I was heads down on the charm-helpers fix that we need for this charm to work.  If you could give a look at my merge proposal please:  https://code.launchpad.net/~mbruzek/charm-helpers/peers/+merge/280211
 * mbruzek reads the scroll back
<marcoceppi> mbruzek: lgtm
<mbruzek> marcoceppi:  tests pass
<cory_fu> marcoceppi: I think it would look something like this: http://pastebin.ubuntu.com/13908409/
<cory_fu> marcoceppi: But that's untested and I think it's wrong that MySQLClient is GLOBAL scope, because you might want to talk to two different databases for some reason
<cory_fu> Should be SERVICE scope
<marcoceppi> cory_fu: so for the first run
<marcoceppi> you'd get a .connected, .available, and .changed ?
<cory_fu> Yes
<marcoceppi> cory_fu: I like it
<marcoceppi> I agree with service scope as well
<cory_fu> I also like it
<marcoceppi> ANOTHER_CUP_SMASH.gif
<cory_fu> :)
<mbruzek> Thanks for merging the charm-helpers
<mbruzek> How long until it is on pipy?
<marcoceppi> mbruzek: I didn't publish it
<marcoceppi> guess I should
<mbruzek> is that process automated or do I need to grease some wheels?
 * mbruzek greases Marco's brakes
<marcoceppi> greases brakes, not the best idea
<marcoceppi> mbruzek: it's uploaded
<mbruzek> marcoceppi: is there any lag time after you upload to pipy ?  I rebuilt and deployed the charm again, but got the old version of hookenv.py
<cory_fu> mbruzek: You might need to clear out your wheelhouse/ directory.  Remember that build is additive, so it will put the new version in with the old one and it will be up to chance which one gets installed (last one wins)
<mbruzek> cory_fu: where is this wheelhouse directory?
<mbruzek> cory_fu: in the charm!
<mbruzek> cory_fu: that was my problem I have both charmhelpers-0.6.1.tar.gz and charmhelpers-0.6.0.tar.gz
<cory_fu> :)
<cory_fu> We really need to improve the handling of removed files during build
<mbruzek> OK that does it, EOD for me.
<mbruzek> I will check/test it tomorrow
<mbruzek> cory_fu: you still think the leader should set a state to ask for the csr?
<mbruzek> cory_fu: I saw you guys broke into some other stuff in the scrollback
<cory_fu> mbruzek: I think marco was right that it doesn't actually save any hook calls, so it's probably not worth putting the effort in
<cory_fu> I feel like it does make for a more conceptually clean conversation flow, though, so if you feel like doing it, then I certainly wouldn't object
<cory_fu> Anyway, I'm off to EOD as well
<lazypower> cheers dudes o/
<lazypower> thanks for the help today cory_fu
<cory_fu> np!
<mbruzek> cory_fu: or marcoceppi if anyone would like to review the implementation early please go here https://github.com/mbruzek/layer-tls and https://github.com/mbruzek/interface-tls
<mbruzek> I have not yet been able to test with the new charmhelpers, will do that tomorrow, but if you find some logic flaws, or have anyone has suggestions please add issues
#juju 2015-12-11
<stub> cory_fu: yo
<moqq> $ juju service add-unit papertrail  --to=10 >>> ERROR cannot add unit 1/1 to service "papertrail": cannot add unit to service "papertrail": inconsistent state
<moqq> anyone know how i might be able to resolve such a thing?
<moqq> juju status says literally everything is fine
<moqq> well i just waited awhile and it seemed to start working
<stub> lazypower: The best you can do is announce who the leader *was*, via leadership settings is easiest. By the time other units see it, it may no longer be true.
<stub> lazypower: I haven't found a use case for actually doing this.
<stub> if not leader_get('foo'): status_set('waiting', 'Waiting for leader to lead')
<Prabakaran> Hi kwmonroe, Thanks for the email on my query. I have few more doubts and issues while generating layered specific file for my charm using charm build command.
<apuimedo> marcoceppi: when deploying a charm, does it leave some trace on the machine where I execute the "juju deploy"
<rick_h_> apuimedo: it does not
<apuimedo> rick_h_: thanks ;-)
<stub> With the reactive HTTP handler https://github.com/juju-solutions/interface-http/blob/master/provides.py , how do I write a config-changed hook that updates the port? I think I need to call configure() on the HttpProvides instance for each unit, but I can't see how to get that set of instances.
<cory_fu> stub: You wouldn't use @hook('config-changed'), you would use @when('website.available') and then call website.configure(config('port'))
<cory_fu> If you wanted to, you could wrap that in a data_changed() condition, but I think that relation-set is basically a noop if called with the same data, so I'm not sure it's necessary
<stub> cory_fu: Yeah, I think I actually need to make this UNIT scope (I'm not using HTTP, just using it as an example trying to get my head around the relations stuff)
<stub> cory_fu: http://pastebin.ubuntu.com/13931316/ (maybe to be a layer) and http://pastebin.ubuntu.com/13931345/ (the charm bit) is what I have so far. I haven't tested it at all yet, but I seem to need to implement it as UNIT scope even though to me it should be GLOBAL
<stub> I need to hook into config-changed as that is how the operator changes the settings that need to propagate to the clients (or, in the simpler example, when the operator changes the HTTP port in the config)
<kwmonroe> anyone have the syntax for exposing a service in a bundle.yaml?
<stub> Similarly, I think we might need to propagate private-address changes (I think everyone is a little fuzzy on this, and nobody does it)
<cory_fu> stub: The interface layer shouldn't contain implementation, and the charm layer shouldn't have to deal with converstations.  Also, reconfigure_syslog should also be @when('syslog.available') and you wouldn't have to do the manual from_name
<tvansteenburgh> kwmonroe: expose: True
<cory_fu> You don't have to explicitly handle config-changed, though.  When config-changed is triggered, it will run any handlers whose conditions are valid and those handlers can just ask "am I connected to syslog?  If so, send it the (new) config value"
<tvansteenburgh> kwmonroe: (under the service)
<kwmonroe> heh.. awesome tvansteenburgh.  so simple it hurts.
<cory_fu> kwmonroe: I am surprised to see that our big data bundles don't expose any of the services by default.
<kwmonroe> like what services cory_fu?  i don't think we should expose namenode (you can browse hdfs from there, so ashley madison).  i also don't think we should expose notebooks by default (same reason, with the added bonus of hdfs actions).
<kwmonroe> that pretty much leaves benchmark-gui, and that has a big fat POST ME button, so maybe we shouldn't expose that one either.
<cory_fu> kwmonroe: Hrm.  Fair enough.  It just seems weird to deploy a bundle with zero exposed services.  Like, how do you expect to use that?
<kwmonroe> agreed -- i think it would be helpful to expose any service that has a service health dashboard.. maybe spark?  i dunno. as annoying as it is to be locked out by default, it's safer, and it's plenty easy to type 'juju expose'.
<cory_fu> stub: So this is more how I would structure your example: interface: http://pastebin.ubuntu.com/13932246/ charm: http://pastebin.ubuntu.com/13932247/
<cory_fu> That keeps the implementation in the charm layer and the communication protocol in the interface layer.  I'm not sure whether the log_line_prefix was supposed to come from the pgsql relation or config, but it doesn't matter, you'd just change the one line that sets that var (maybe remove the postgres condition on the when if it's not needed)
<cory_fu> You don't have to explicitly react to config-changed (or pgsql changed), you just react to whether or not you have the things you need (attached loggers and maybe available pgsql) and then act accordingly
<cory_fu> marcoceppi: That also touches on what we were discussing last night.  I'm back to thinking that it really should be the charm's responsibility to detect changes in values, because it may actually care about changes in state from multiple sources.
<cory_fu> Though, if we had a reasonable way to react to "any of a set of states" it might still be useful for the interface layer to expose a "changed" state, but that's hampered by the difficulty in dealing with the difference between a state being set vs not
<cory_fu> That is to say, if you say when_any(foo, bar) and only foo is set, then you can't get an instance of the bar relation because it might not exist
<cory_fu> I guess it could just pass in None and leave it up to you to handle that.  Hrm
<cory_fu> Or maybe @when_any should never provide values and you have to combine it with @when since you need that to have any reasonable assurance about what is available
<marcoceppi> I'm interested but have no really feedback
<mbruzek> Good morning cory_fu.  Question about interface layers.  I changed the code in the interface "peers.py" then re built the layer into a charm but I am getting the same error I saw before.  I realize that deleting the charm directory will likely solve my problem but I am certain that I fixed this before the re build and it was not picked up by new charm code that was built.
<cory_fu> mbruzek: I think you are running up against https://github.com/juju/charm-tools/blob/master/charmtools/build/tactics.py#L232
<cory_fu> mbruzek: That will be fixed by https://github.com/juju/charm-tools/pull/75
<mbruzek> cory_fu: I used the --force flag when I built, should that not be honored in this case
<cory_fu> mbruzek: It should be.  I think that line is in fact a bug.  Hence why I changed it in my PR
<mbruzek> OK thanks cory_fu.  I will delete the charm dir and build again
<mbruzek> as a temporary workaround
<cory_fu> Yep, that'll work
<cory_fu> mbruzek: Feel free to review that PR and offer your +1 if it looks ok to you
<cory_fu> I know I still didn't add doc strings, though, so you'll probably -1 it
<cory_fu> :)
<mbruzek> cory_fu: confusing code needs to be explained
<cory_fu> Yeah.  I need to spend some time going through that and adding a bunch of docstrings and comments
 * stub has a think
<roadmr> hey jujuers :) what's a good way to determine which version of the juju agent is running on units of a service?
<mgz> roadmr: juju status tells you
<roadmr> mgz: %) haha should have checked that first.
<roadmr> mgz: indeed it does! thank you so much!
<TheJeff> hey #juju
<TheJeff> me again... I've started over.  Attempting to load up juju inside an lxc container
<TheJeff> did deploy juju-gui --to lxc:0
<TheJeff> stuck on installing charm software :(
<TheJeff> logs to tail?
<TheJeff> also if i run debug-hooks there's no ./hooks :(
<rick_h_> TheJeff: should be a /var/log/unit/juju-guixxxxxxxx
<rick_h_> TheJeff: or if it didn't get that far the all machines log
<marcoceppi> TheJeff rick_h_ /var/log/juju/unit-juju-gui*
<rick_h_> marcoceppi: doh ty for the correction
<marcoceppi> also, /var/log/juju/machine-0.log
#juju 2015-12-12
<sectrgt> how do i setup juju to use a drifferent ip range than the default 10.0.3.0/24?
<ruflex> I would like to help me with a query. I have a dedicated server at GoDaddy , and I use my services to deploy virtualization (KVM ) , it's time that I have to upgrade my server and asked you installed ubuntu 14.04 clean , my question or problem that I wanted to deploy OpenStack , but still not clear to the concepts of cloud , I have looked juju , and I'm excited because I see that is easy to deploy OpenStack , my question is if I need to install MAAS , or LXC , or
<ruflex>  where to start, thanks
#juju 2016-12-12
<kjackal> Good morning Juju world!
<Teranet> hi everyone do we have any JUJU people here ?
<bdx> Teranet: how's it going?
<Teranet> good except my JUJU is not doing what is should do
<bdx> Teranet: what does `juju --version` return?
<Teranet> juju bootstrap     localhost  fails
<Teranet> 2.0.2-xenial-amd64
<Teranet> Errror is : ERROR failed to bootstrap model: waited for 20m0s without being able to connect: ssh: connect to host
<bdx> Teranet: ok, have you verified that lxd is configured correctly on your machine?
<Teranet> it get's an IP assigned but the container when I see it don't get the IP
<bdx> Teranet: can you launch a lxd instnace manually?
<bdx> Teranet: `lxc launch ubuntu:16.04 ubuntu-test`
<Teranet> LXD is running correctly and the the bridge is in place
<Teranet> ok let me try
<Teranet> sysadmin@sf2-maas00:~$ lxc launch ubuntu:16.04 ubuntu-test
<Teranet> Creating ubuntu-test
<Teranet> Starting ubuntu-test
<Teranet>  
<Teranet> looks like it just did
<bdx> Teranet: ok, can you try this command for bootstrapping lxd local `juju bootstrap lxd lxd-dev`
<bdx> Teranet: you can remove that test container with `lxd delete ubuntu-test --force`
<Teranet> ok will run it give it a sec
<Teranet> ok same result :
<Teranet> sysadmin@sf2-maas00:~$ juju bootstrap lxd lxd-dev
<Teranet> Creating Juju controller "lxd-dev" on lxd/localhost
<Teranet> Looking for packaged Juju agent version 2.0.2 for amd64
<Teranet> To configure your system to better support LXD containers, please see: https://github.com/lxc/lxd/blob/master/doc/production-setup.md
<Teranet> Launching controller instance(s) on lxd/localhost...
<Teranet>  - juju-141282-0 (arch=amd64)
<Teranet> Fetching Juju GUI 2.2.5
<Teranet> Waiting for address
<Teranet> Attempting to connect to 10.5.100.53:22
<Teranet> it's like not assigning the IP to the VM
<Teranet> 12: vethNL6O8E@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxdbr0 state UP group default qlen 1000
<Teranet>     link/ether fe:88:68:61:5d:72 brd ff:ff:ff:ff:ff:ff link-netnsid 0
<Teranet>     inet6 fe80::fc88:68ff:fe61:5d72/64 scope link
<Teranet>        valid_lft forever preferred_lft forever
<Teranet> 14: vethMBJXX9@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxdbr0 state UP group default qlen 1000
<Teranet>     link/ether fe:f1:f5:1e:81:dc brd ff:ff:ff:ff:ff:ff link-netnsid 1
<Teranet>     inet6 fe80::fcf1:f5ff:fe1e:81dc/64 scope link
<Teranet>        valid_lft forever preferred_lft forever
<Teranet> I do see IPv6 but no IPv4 Ip's assigned
<bdx> Teranet: did your ubuntu-test container get an ip?
<bdx> Teranet: it sounds like you might need to reconfigure your lxd-bridge
<bdx> `lxc list | grep ubuntu-test`
<Teranet> nope
<bdx> ahh, thats the issue
<Teranet> hold on
<Teranet> sysadmin@sf2-maas00:/etc/dhcp$ lxc list | grep ubuntu-test
<Teranet> | ubuntu-test   | RUNNING | 10.5.100.68 (eth0) |      | PERSISTENT | 0         |
<bdx> ahh, ook
<Teranet> the ubuntu test yes
<Teranet> stupid eth0
<Teranet> that shit has to be em1 grrr
<Teranet> my Server run's em1 and em2 as interfaces not eth0
<bdx> Teranet: are you using lxdbr0 for your lxd bridge?
<Teranet> let me verify
<Teranet> 4: lxdbr0:
<bdx> Teranet: `cat /etc/default/lxd-bridge`
<bdx> that should produce something similar to -> http://paste.ubuntu.com/23619976/
<bdx> for your ip space
<bdx> there are some critical configs in that file for the lxd-bridge
<Teranet> it did http://paste.ubuntu.com/23619977/
<Teranet> Ip's been assigned but SSH times out :-(
<bdx> oooh
<bdx> Teranet: its just being timely I think
<bdx> Teranet: is this running on a laptop with spinning disk?
<Teranet> nope
<Teranet> run's on a big DELL Server with SSD's
<bdx> well, ok then
<bdx> ha
<bdx> Teranet: has your bootstrap finished?
<Teranet> nope it's hanging
<Teranet> http://paste.ubuntu.com/23619986/
<bdx> Teranet: if/when you bootstrap again, it might be helpful to pass the --debug flag (my bad for not getting you that with the command initially)
<Teranet> like this
<Teranet> is ok let me redo it
<bdx> Teranet: I see the problem
<bdx> your gateway
<Teranet> why so ?
<bdx> ## IPv4 network (e.g. 10.0.8.0/24)
<bdx> LXD_IPV4_NETWORK="10.5.100.50/24"
<Teranet> sysadmin@sf2-maas00:/etc/dhcp$ ip r
<Teranet> default via 10.5.100.1 dev em1 onlink
<Teranet> 10.5.100.0/24 dev em1  proto kernel  scope link  src 10.5.100.250
<Teranet> 10.5.100.0/24 dev lxdbr0  proto kernel  scope link  src 10.5.100.50
<rick_h> y\
<Teranet> there should be no issue
<bdx> Teranet: Your not natting ivpv4
<bdx> ehh
<bdx> ipv4
<bdx> Teranet: `sudo dpkg-reconfigure -p medium lxd`
<Teranet> correct why should I it's the same network
<jrwren> you'd need something to bridge those two interfaces.
<bdx> Teranet because the container will not know how to talk to the internet
<jrwren> those are not the same network (unless there is other config). Those are 2 networks that happen to use the same address space.
<Teranet> correct on purpose
<bdx> jrwren: nice catch
<Teranet> because I don't want LXD to use a different network
<bdx> Teranet: then you need to create the bridge on the interface
<Teranet> which is
<jrwren> Teranet: in that case, you'll need to create your own bridge and add em1 to it and tell lxd to use it instead of lxdbr0
<Teranet> 4: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
<Teranet>     link/ether fe:55:75:16:41:9a brd ff:ff:ff:ff:ff:ff
<Teranet>     inet 10.5.100.50/24 scope global lxdbr0
<Teranet>        valid_lft forever preferred_lft forever
<Teranet>     inet6 fe80::84ba:caff:feba:ff95/64 scope link
<Teranet>        valid_lft forever preferred_lft forever
<jrwren> Teranet: http://jrwren.wrenfam.com/blog/2015/11/10/converting-eth0-to-br0-and-getting-all-your-lxc-or-lxd-onto-your-lan/
<Teranet> http://paste.ubuntu.com/23620012/
<Teranet> take a look
<bdx> Teranet: em1 needs to be in  'manual' mode
<Teranet> ok let me fix that
<Teranet> done now reboot again ?
<bdx> Teranet: did you add lxdbr0 to em1 similar to jrwren's blog post?
<jrwren> i never reboot.
<Teranet> lxd changes on network's won't go into effect without a hard reboot
<jrwren> ifup containerbr should be enough
<jrwren> That has not been my experience.
<Teranet> that's a fact
<jrwren> i've no wish to argue.
<bdx> Teranet: you can use brctl, and ifup/ifdown | ifconfig to accomplish these tasks w/o restarting
<Teranet> bdx not under newer ubuntu setup's just fyi
<bdx> Teranet: really ?
<Teranet> yes it's an open issue with Kernel 4 since they pushed it out and the fix is in the works
<bdx> Teranet: `sudo ifdown em1 && sudo ifup em1` doesn't do the trick?
<Teranet> some stupid register is not proper set which very often lets the interface restart hang or just emulate the restart but actually not doing a thing
<bdx> crazy
<jrwren> terrible! What kernel version? I want to be sure to avoid it.
<Teranet> yes it's a known bug in the 4.4 series
<Teranet> it's still in the latest 4.4.0-35
<Teranet> which I use right now
<Teranet> ok box is back up
<Teranet> stupid Dell init takes way to long :-(
<Teranet> but wait till you work on Supermicro boxes :-(
<Teranet> 10min reboot or longer even
<jrwren> somehow I'm on 4.4.0-45-generic, Wed Oct 19 14:12:37 UTC 2016 x86_64. Are you on x86_64?
<Teranet> Linux sf2-maas00 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
<jrwren> oh, -35 v. -53. a bit of discalulia
<jrwren> discalculia
<Teranet> LOL must had patched over night the box
<Teranet> sorry we have over 15000 Server here
<Teranet> often I get lost whats where
<Teranet> still looks to hang at the same crap ;-(
<bdx> Teranet: so now you need to unconfigure the lxd bridge from lxd's perspective
<bdx> Teranet: `sudo dpkg-reconfigure -p medium lxd`
<Teranet> I think I like to run this without a stupid bridge mode at all if possible
<jrwren> bridge is the only way to not have LXD use a different network. You can use the defaults and use routing and NAT, or you can use bridge, but I don't know of a way to use networking with LXD without one of those two things.
<Teranet> i think I might than have to yell at ubuntu again
<Teranet> LOL
<bdx> Teranet: all it takes is -> http://paste.ubuntu.com/23620112/
<Teranet> ok let me try with NAT
<Teranet> might solve the crap
<bdx> Teranet: ^ is direct bridging
<Teranet> even I don't like the NAT in a Corp network
<bdx> Teranet: ^ isn't nat
<Teranet> I do have to because we have around 300 networks and within those I must be able to reach each individual LXD when needed
<Teranet> so if network is not proper we have a bigger issue
<jrwren> bdx: if you bridge em1 onto lxdbr0 then the lxd-net service will provide DHCP service out that em1 interface. If you are plugged onto a LAN, you might make your neighbors angry.
<Teranet> we use a dedicated Management LAN and IPAM I reserved those blocks
<Teranet> so they won't collide
<Teranet> MAAS DHCP is 180-199 right now
<Teranet> and LDX only 51-69
<Teranet> so they won't collide in this test setup
<bdx> jrwren: not if lxd's networking is disabled
<bdx> jrwren: http://paste.ubuntu.com/23620112/ works for me when I have external dhcp and I want to extend that to my containers on my host
<bdx> which is what I feel like Teranet is trying to do
<bdx> Teranet: is that correct?
<jrwren> bdx: ah, nice.
<Teranet> let me check
<Teranet> I just adjusted to your settings bdx lets give me a sec
<Teranet> FYI my MAAS Cluster setup uses the em1 on all boxes as Management and em2 is the public TRUNK with 30 Vlan's later on which is the public facing network ranges so to speak
<bdx> Teranet: I must warn you, if this is a node in your MAAS, you are best off bootstrapping Juju to your maas, then letting maas configure the networks, and deploy containers ontop of them with juju using the maas provider
<Teranet> how would that be different ?
<Teranet> shouldn't that be the same procedure ?
<bdx> Teranet: trying to manually mangle MAAS provisioned interfaces will only bring you grief .... does this make sense?
<bdx> Teranet: MASS has built in container networking
<bdx> Teranet: If you bootstrap your MAAS, you can then `juju deploy ubuntu --to lxd:<machine-#>`
<Teranet> I have MAAS running and this is the Cluster Node on which I deploy
<bdx> Teranet: or even better, `juju deploy ubuntu --to lxd:<machine-#> --constraints "spaces=<my-mass-network>,<my-other-maas-network>`
<Teranet> dbx ??? now you lost me there
<bdx> Teranet: sf2-maas00
<Teranet> as far as I recall no matter if MAAS or not you deloy the first juju boot strap and all on the Cluster Master Node
<bdx> is sf2-maas00 a node in  your maas?
<Teranet> sf2-maas00 is the Master of the Cluster
<Teranet> no it's the Regional Controller of the MAAS
<bdx> ahhh, so your combined region/rack controller, ok
<bdx> Teranet: have you any machines checked into your maas?
<Teranet> I have 5 NODES ready
<Teranet> all same specs
<Teranet> Supermicro  24 core  32GB ram :-(  and 500GB SSD for starters
<bdx> Teranet: ok, do you have network spaces/subnets created, and associated with your node interfaces?
<bdx> in your maas
<Teranet> all are in em1 Management network 10.5.100.0/24
<Teranet> even their IPMI  is
<Teranet> the idea is to have OpenStack at the end doing al lthe work
<bdx> Teranet: have you created network spaces/subnets in the context of MAAS and configured your nodes interfaces to be attached to the networks?
<bdx> Teranet: I've been deploying openstack on maas for a few years now
<Teranet> could you skip stupid juju to get Openstack up ?
<bdx> Teranet: so without any networks configured in maas other than the mgmt net, containers deploy by default to the mgmt network
<Teranet> yes that's what they should for now
<bdx> Teranet: do you have juju bootstrapped to your maas?
<Teranet> ... not 100% sure if I did or not
<Teranet> how can I check ?
<bdx> Teranet: you would have to `juju bootstrap maas my-maas`
<bdx> https://jujucharms.com/docs/2.0/clouds-maas
<Teranet> I just had juju installed and try to get this piece working
<Teranet> so I think I do not have it tied to the MAAs yet
<bdx> Teranet: so your missing the juju <-> MAAS communication link
<bdx> Teranet: once you get juju bootstrapped to your maas, deploying containers and openstack itself becomes very easy
<Teranet> right but brings me back to juju bootshit to fail right from the  get go
<bdx> Teranet: work on bootstrapping your maas
<bdx> Teranet: bootstrapping your maas has nothing to do with containers or lxd bridge
<bdx> you just need to do this https://jujucharms.com/docs/2.0/clouds-maas
<bdx> once you have your maas bootstrapped, you can deploy containers to your nodes, and the networking bit gets handled by juju/maas, and you don't have to do any of it manually, its quite nice
<bdx> Teranet: once you have your maas bootstrapped you can just `juju deploy ubuntu --to lxd:<machine-#>` and your container should be reachable from your maas management network
<Teranet> ok now I go this : maas-prod          0                 maas        Metal As A Service
<Teranet>  
<Teranet> so I added the stuff
<bdx> so now
<bdx> `juju bootstrap maas-prod maas-prod-controller`
<Teranet> ok question so maas-prod I get but maas-prod-controller is than sf2-maas00 ?
<bdx> 'maas-prod-controller' will be the name of your juju controller
<Teranet> oh crap how can I check that again ?
<bdx> the juju controller will be selected from your available machines in your maas
<bdx> and then will be named `maas-prod-controller`
<bdx> your juju controller will be created upon bootstrap
<Teranet> http://paste.ubuntu.com/23620258/   ???
<bdx> ahhh
<bdx> one last step
<bdx> juju add-credential maas-prod
<Teranet> ok now it ask for credential name ??
<bdx> maas-admin
<bdx> (arbitrary - I think)
<Teranet> so the admin user of maas ?
<bdx> ehh ... yes
<bdx> that might be best for consistency .... in case you end up with multiple maas users
<Teranet> ok .... building now
<bdx> ooh, maas is bootstrapping now?
<Teranet> so far :
<Teranet> sysadmin@sf2-maas00:~$ juju bootstrap maas-prod maas-prod-controller
<Teranet> Creating Juju controller "maas-prod-controller" on maas-prod
<Teranet> Looking for packaged Juju agent version 2.0.2 for amd64
<Teranet> Launching controller instance(s) on maas-prod...
<Teranet>  - crcrbk (arch=amd64 mem=32G cores=24)
<bdx> excellent
<Teranet> Fetching Juju GUI 2.2.5
<Teranet> still fetching
<bdx> Teranet: can you see that one of your nodes has started to deploy in maas?
<Teranet> let me check
<Teranet> yes 1 NODE turned on and is deploying now
<Teranet> ok somehow I will need to write this shit down later on LOL
<Teranet> because our ubuntu docu is not working at all again :-(
<Teranet> do figure LOL
<bdx> Teranet: I compiled a ~200 page doc for my last company that details deploying openstack on maas with juju
<bdx> let me see if I can dig it up for you :-)
<Teranet> this I have to put back onto ubuntu.com manuals LOL
<bdx> Teranet: you can get a default vanilla deploy very easily just using the juju/maas docs I think, but you will want to start creating your own docs for this type of project for sure
<Teranet> think wrong :-) that's why I am here because someone F'd up the docu
<Teranet> LOL
<bdx> Teranet: can you point out to me where the doc is failing you?
<Teranet> so when I did install after MAAS the apt install juju
<Teranet> once that's in it directs you to a full bunch of BS
<Teranet> it should direct you for OS setup with juju just like you gave me the striped down version of commands
<bdx> Ahh, yes installing maas, has a few extra gotchas that need be addressed ... did you reference the MAAS 2.0 docs https://maas.ubuntu.com/docs/install.html?
<Teranet> correct that one is out of date as well
<Teranet> so we have it on the list to rewrite it
<Teranet> because with 16 its simpler now
<bdx> ahh, ok
<Teranet> good my workshop for this is in 3 weeks LOL
<Teranet> not today
<Teranet> gosh still building wtf :-)
<Teranet> ok crap now what :  ERROR failed to bootstrap model: bootstrap instance started but did not change to Deployed state: instance "crcrbk" is started but not deployed
<Teranet>  
<Teranet> debug again ?
<rick_h> Teranet: are the nodes all setup to boot from lan first and disk second?
<rick_h> Teranet: when I've had that I've not had the boot order in the bios setup right and so it couldn't deliver the image, reboot, and get the node on disk going
<Teranet> yes network first than USB if attached and than RAID SSD
<Teranet> and IPMI controlled
<bdx> Teranet: thats your issue
<bdx> Teranet: you have a preconfigured hardware raid?
<Teranet> yes
<Teranet> RAID is set and the boxes are all in READY status
<bdx> Teranet: can you configure your raid via maas please
<Teranet> it already is
<bdx> Teranet: oh
<bdx> rick_h: what is the status of raid support in maas?
<bdx> Teranet: I would advise you to get this setup in the most default/vanilla way initially
<Teranet> vgroot-lvroot
<Teranet> 479.0 GB
<Teranet> ext4
<bdx> ok
<bdx> Teranet: I ran into a few issues when setting up raid via maas, it had to do with how I was creating vgs and mounting filesystems
<bdx> Teranet: can you make the raid a secondary goal
<bdx> and kill it for now, for the sake of just getting up and running with minimal issues
<Teranet> so should I blow the hole MAAS box away and re add it or what ?
<bdx> Teranet: yea, if you could just reprovision the nodes to not use raid pls
<Teranet> ?? it's a HARDWARE Raid just FYI
<Teranet> so the box don't see it
<bdx> Teranet, yea, thats also an issue
<bdx> Teranet: if its a hardware raid, then you didn't configure it via maas
<bdx> Teranet: get rid of the raids, let maas manage your disks
<bdx> Teranet: you can use maas to create a raid of those disks for your /
<Teranet> I think you don't get it
<bdx> later, after you get everything standing vanilla
<Teranet> I won't change it because thats how it's default
<Teranet> RAID 1 is a must set and I won't change it
<bdx> Teranet: maas expects to manage your hardware
<bdx> Teranet: if you try to interfere, you will experience difficulties
<bdx> Teranet: you can still have those disks in raid1
<bdx> Teranet: you would just need to do it via maas, not your hba controller
<Teranet> and I won't let mass software control my hardware raid
<bdx> Teranet: maas doesn't control your raid
<bdx> Teranet: maas just configures it upon deployment
<Teranet> Maas don't see it as a Raid and that's how it has to be
<bdx> Teranet: Ok, I had the same thing going on .... I ended up switching my raid controllers into hba mode, bc it was just easier to let maas do it, but if you insist on using hardware raid, you might want to run the specs of your setup by the maas team so they can verify MAAS will work as intended on your hadware configuration
<Teranet> they are and I verified them myself
<Teranet> so that ain't the issue
<bdx> Teranet: conceptually, what you are thinking should work, I'm just trying eliminate extra things that might cause issues while getting you up and running initially
<bdx> Teranet: one thing you can do to troubleshoot, is to make sure the nodes deploy via maas, w/o juju
<Teranet> they do as I said all 5 nodes are in RAEADY mode
<bdx> e.g. just deploy the node from the maas gui, and make sure they deploy successfully
<Teranet> so they are deployed via MAAS alone no problem with IPMI
<bdx> if that checks out, then juju will be able to deploy them first
<bdx> ok, then do you release them before bootstrapping with juju?
<bdx> Teranet: if they deploy successfully via MAAS standalone, then juju bootstrap should work for sure .... so strange its not for you
<Teranet> no offense here bdx but this is not how it should work
<bdx> Teranet: how so?
<Teranet> I am certain some code has changed in juju again and now the BS don't work again
<Teranet> I saw some guys pushed code changes in without approval
<Teranet> worse comes to worse I need to roll back the code and ban those guys from doing changes to our code again
<cory_fu> kjackal, kwmonroe, petevg: New version of BT has been released, with matrix support, xunit reporting, and a few other fixes.
<petevg> cory_fu: sweet!
<kjackal> awesome, thanks cory_fu
<cory_fu> kjackal: Thank tvansteenburgh.  He merged and released it.  :)
<kjackal> then ... thanks tvansteenburgh!
 * tvansteenburgh waves
<cory_fu> tvansteenburgh: Man, you are on *top* of the PRs today.  :)
<tvansteenburgh> i try cory_fu
<tvansteenburgh> you do get special treatment though
<cory_fu> :)
#juju 2016-12-13
<stub> skay_: I don't think the snap layer should support private snaps. It would seem to be a major security problem, where if any machine running the private snap got compromised then it could be escalated to all machines running the private snap (if you can download a private snap, you can push updates to it)
<stub> skay_: I don't know about unpublished snaps. How do you install them normally? Do you just provide an explicit revision? I'd been thinking for that sort of use case people would use the Juju resource functionality. But I don't know your particular use case :)
<stub> skay_: The code is all at https://code.launchpad.net/layer-snap ( git+ssh://git.launchpad.net/layer-snap ), and a mirror on github at https://github.com/stub42/layer-snap
<stub> (please correct me if I'm wrong on private snaps, as we have avoided snaps for some projects because of the issue)
<kjackal_> Good morning Juju world!
<kjackal_> is https://jujucharms.com/store available on your side or is it only me?
<kjackal> Good morining Juju World!
<kjackal_> nm somethis was wrong with my vpn
<SimonKLB> is it possible to run the upgrade-charm hook when a relation-joined hook have failed?
<SimonKLB> or is it required that the relation-joined hook is fixed before it can continue?
<SimonKLB> and if so, how are you supposed to fix it without upgrade-charm?
<SimonKLB> (i've tried upgrade-charm --force-units)
<SimonKLB> forgot to add, the error occurs because of a lib in the wheelhouse, and therefore the upgrade-charm hook is required to install the new lib which includes the fix
<stub> SimonKLB: No hooks will run while the unit is in an error state. I think you are stuck with 'juju resolved' to clear the error state, repeating as necessary. Then dropping the relation and doing the upgrade (or doing the upgrade and then dropping the relation).
<stub> SimonKLB: You might be able to repair the relation, but you are probably better off dropping and recreating it
<SimonKLB> stub: yea, i fixed it by removing the relation, upgrading and adding it again - but is there a reason that the upgrade operation is part of the normal flow? is it due to race conditions between hooks and upgrades or something else?
<stub> I don't know the official reasons, but I would think that if a hook is in an error state then the system is in an indeterminate state and Juju isn't going to risk doing anything.
<SimonKLB> stub: okok, it's just frustrating that you have a fix that you want to apply but you cant upgrade the charm because of the error you're trying to solve :D
<SimonKLB> stub: btw, have you had any time recently to look at relative imports in reactive?
<stub> SimonKLB: My PR is still in the charms.reactive queue
<stub> https://github.com/juju-solutions/charms.reactive/pull/51
<SimonKLB> stub: yea, does it simply not have enough prio or is it something that is blocking it?
<stub> SimonKLB: I think it is in Corey and Ben's hands now. I havn't been nagging about that one, as I have a work around and other PRs I need landing first ;)
<SimonKLB> stub: haha yea, i really want to get rid of that hotfix in lib/reactive... :)
<stub> But yeah, six months without comments.... not exactly encouraging contributions :-(
<marcoceppi> SimonKLB: you can do `juju upgrade-charm --force-units` which will unpack the charm payload regardless of hook state
<marcoceppi> so if you patch a relation hook, and want to test with the failed state, just run that then a juju resolved
<marcoceppi> stub: ^^ fyi
<SimonKLB> marcoceppi: in case the fix is in the charm code yes, but if it's in a lib in the wheelhouse that doesn't seem to do it since the wheelhouse is only updated in the upgrade-charm hook
<marcoceppi> SimonKLB: that's a good point, you can however, if you have a debug-hooks session open
<marcoceppi> just run the upgrade-charm hook despite being in the relation context
<SimonKLB> marcoceppi: how do i execute a specific hook when im in the debug mode? ive only used it to catch a hook when it's firing
<marcoceppi> SimonKLB: right, so you breakpoint the hook execution ,after an upgrade-charmm --force-units
<marcoceppi> SimonKLB: you're now in the relation hook even
<marcoceppi> event*
<marcoceppi> SimonKLB: but you can just run `hooks/upgrade-charm` despite not being in that hook context
<skay> stub: I decided to forgo the concept of a private snap and will just upload the file as a release download on launchpad
<BlackDex> Hello there, can i prevent an lxd container from being connected to a specific network space?
<BlackDex> it doesn't seem to matter if i use --bind or not
<BlackDex> it always connects to all available networks
<SimonKLB> marcoceppi: so now i have a relation-joined error, i enter `juju debug-hooks` and execute `juju upgrade-charm`, and then `juju resolved`
<SimonKLB> marcoceppi: still i get into the relation-joined hook, not the upgrade-charm hook
<marcoceppi> SimonKLB: that's okay
<marcoceppi> did you do upgrade-charm with --force-units?
<SimonKLB> marcoceppi: yep
<marcoceppi> SimonKLB: so, if you now run `hooks/upgrade-charm` in your debug window
<SimonKLB> marcoceppi: how do i get from here to have the wheelhouse install again?
<marcoceppi> your new deps will be unpacked
<SimonKLB> aaah, perfect!
<SimonKLB> thanks
<petevg> cory_fu, bcsaller: filed the "failed status after reboot" bug here: https://bugs.launchpad.net/juju-core/+bug/1649637
<mup> Bug #1649637: Juju agent in a "failed" state after machine reboot on some charms <juju-core:New> <https://launchpad.net/bugs/1649637>
<petevg> cory_fu: https://github.com/juju-solutions/matrix/pull/43 LGTM
<petevg> cory_fu: do you want to keep your commits unsquashed?
<cory_fu> petevg: Oh, no.  I'll squash them.  thanks for catching that
<petevg> cory_fu: cool. I'll let you do the squash and merge on github, since you know which comments you want to keep :-)
<kwmonroe> hey cory_fu, i have a curiousity.  for a subordinate with use_venv=true and include_system_packages=false, how is python able to import sys prior to activate_venv?  https://github.com/juju-solutions/layer-basic/pull/80/files#diff-0afefcaa00589c20f3d956fa58ddbbe7R97
<cory_fu> kwmonroe: It gets run with the system Python, and the activate_venv re-execs it using the venv's python
<cory_fu> kwmonroe: So, you can import the standard modules but anything that's only installed in the venv will fail to import until after the activate_venv()
<kwmonroe> cory_fu: if i import stuff before reload_interpreter, will those imports still be known by vpy?
<cory_fu> kwmonroe: Also, anything installed in the system python (such as by the principal charm, if it's not also using venv) will be available before activate_venv, which is why hadoop-plugin is working by accident right now
<kwmonroe> ack cory_fu.  i'm kinda surprised at that one given hadoop-client (i thought) used a different major version of jujubigdata.
<cory_fu> kwmonroe: What actually happens, is that it runs through the lines up to reload_interpreter under the system python interpreter, which then reinvokes the program using the venv python interpreter.  That new interpreter then re-does everything from the start, but activate_venv includes a check to skip reload_interpreter if it's already using the venv interpreter
<kwmonroe> ah, neat
<cory_fu> kwmonroe: Another option would be to change the shebang lines on the actions to point to the venv: #!../.venv/bin/python
<cory_fu> kwmonroe: Then we could leave out the call to activate_venv entirely
<cory_fu> petevg: Oh, poop.  bcsaller went and merged before I could squash those commits
<bcsaller>  oh, sorry
<cory_fu> bcsaller: No worries.  The "wip" commits are yours anyway.  ;)
<petevg> Oh well. A few "wip" comments don't destroy the git log or anything :-)
<kjackal> kwmonroe: did you test the change you merged here: https://github.com/juju-solutions/layer-cwr/pull/11/files#diff-07490436a8da97cc3ca6df82ae11568eR31
<kjackal> kwmonroe: ^ ?
<kjackal> kwmonroe: from what I've seen https://github.com/juju-solutions/layer-cwr/pull/11/files#diff-794ba32b8d472d3963159bcfcf069f8dR19 needs a string without the "cs:"
<kwmonroe> kjackal: i did -- this works for me:  >>> yaml = cs.files('cs:~bigdata-charmers/hadoop-processing', filename='bundle.yaml', read_file=True)
<kjackal> kwmonroe: strange, but I trust you!
<kwmonroe> kjackal: i was wondering why you wanted to strip 'cs:' so badly.  i'll keep poking on it today with different bundle strings, but like i said, it works for me with a 'cs:' prefix.
<kjackal> kwmonroe: https://api.jujucharms.com/charmstore/v5/cs:~kos.tsakalozos/bundle/juju-ci-bundle-3/meta/manifest gives out a Message": "not found: URL without charm or bundle name: \"cs:~kos.tsakalozos\"",
<kjackal> but https://api.jujucharms.com/charmstore/v5/~kos.tsakalozos/bundle/juju-ci-bundle-3/meta/manifest is fine
<kjackal> kwmonroe: Thats with using postman, it might be that the charmstore lib is doing some cleanup
<tvansteenburgh> like url-encoding the : for example
<kjackal> I was trying the url format we initialy had on the actions.yaml (bundle:....), that did not work so I just went to see what the rest API of the charmstore
<kjackal> that says id/whatever
<kwmonroe> oh neat kjackal -- i can get your failure with the 'bundle:' syntax
<kwmonroe> kjackal: let's go with "~<user>/<bundle>" as the documented syntax, and strip cs: or bundle:.  that will keep theblues happy, and bundletester already handles ~bundle syntax, so we don't need to re-add a prefix there.
<kjackal> kwmonroe: if it works it is fine with me
<BlackDex> what does the * mean after some of the units in juju 2.0?
<jrwren> BlackDex: it is the elected leader.
<BlackDex> Ah :)
<BlackDex> If i want to upgrade juju i get the following
<BlackDex> juju upgrade-juju
<BlackDex> ERROR a hosted model cannot have a higher version than the server model: 2.0.2 > 2.0.1
<rick_h> BlackDex: the controller has to be the highest one
<rick_h> BlackDex: so have to upgrade the controller and then the model you're on?
<rick_h> BlackDex: a model can't use features the controller api doesn't know how to deal with
<BlackDex> show how do i upgrade the controller?
<anastasiamac> petevg: kjackal: kwmonroe: cory_fu: I think we have a zookeeper bug - https://bugs.launchpad.net/juju-core/+bug/1649637 ... any advice?
<mup> Bug #1649637: Juju agent in a "failed" state after machine reboot on some charms <juju-core:Incomplete> <https://launchpad.net/bugs/1649637>
<cory_fu> anastasiamac: You've got that backward.  It *doesn't* happen for ZK.  It does happen consistently for both mysql and mediawiki, and those were just the three we tested
<petevg> anastasiamac: zookeeper works. wiki and MySQL don't.
<cory_fu> anastasiamac: Also, I don't see any way that the payload could affect the agent, so I'm actually surprised that ZK did work
<petevg> Yeah. It's puzzling ...
<anastasiamac> cory_fu: interesting :) so if it works for latest zookeeper and not other charms, would it not mean that the other charms ned to be updated?...
<anastasiamac> need*
<cory_fu> anastasiamac: Updated how?  How are the charms supposed to influence the juju agent?
<cory_fu> anastasiamac: One difference is that both mysql and mediawiki are trusty.  Perhaps this is a trusty vs xenial issue?
<anastasiamac> cory_fu: ah... that is an **interesting** thought.. do they not have xenial versions? would b interesting to see if they can work
<cory_fu> anastasiamac: They do not
<anastasiamac> cory_fu: petevg: thank you :) i'll update the bug \o/
<cory_fu> anastasiamac: I'm testing it now with cs:ubuntu-8 on both trusty and xenial to confirm if the same charm behaves differently by series
<anastasiamac> cory_fu: u r amazing! tyvm :D
<cory_fu> It did.  Trusty failed and Xenial succeeded.  I also got an "action terminated" response from the `juju run ubuntu-xenial/0 'sudo reboot'` command but nothing from the one on trusty
<anastasiamac> cory_fu: it's great that we have a confirmation \o/ it's sad that it's happening.. I'll add all this to the bug unless u r keen to do it urself
<cory_fu> anastasiamac: Already typing it up
<anastasiamac> cory_fu: my hero \o/
<cory_fu> anastasiamac: :)  Posted
<anastasiamac> cory_fu: tyvm
<cory_fu> anastasiamac: np.
<petevg> Thx, cory_fu (also, thx anastasiamac, for looking at the bug quickly)
<cory_fu> petevg: I'm glad we have a reasonable explanation for the different behavior.  Also, the fact that I got "action terminated" from the xenial unit makes me think that the libjuju call wouldn't hang for those either
<petevg> Yeah. Explanations are nice.
<petevg> cory_fu, tvansteenburgh: are we trying to keep python-libjuju relatively dependency free? I'm working on fixing an issue with timestamps inside of unit.py, and I'm very tempted to just add python-dateutil as a dependency ...
<tvansteenburgh> petevg: the fewer the better imo
<cory_fu> petevg: Any idea why we're getting inconsistent formats for the status timestamps?  Does that depend on series as well, or is it perhaps a juju version thing?
<petevg> tvansteenburgh: The tricky thing is that I'm being tempted to hack in cross platform support for getting a timezone aware datetime object from a datetime string, and I'm thinking that the dateutils folks have already done it, and I can point at them rather than at my own foolishness if there are bugs ...
<cory_fu> petevg: Do you have a VM where you could test it under the latest beta?
<petevg> cory_fu: I think that what's happening is that you were chopping off the "Z" as part of chopping down the nanosecond, but sometimes we get a string with no nanoseconds, possibly just because it's exactly on the millisecond or something.
<petevg> cory_fu: and then the Z shows back up.
<petevg> cory_fu: I think that it unearths the fact that we're taking a UTC string and stripping the timezone info off of it.
<petevg> ... which isn't too horrible, because the other side can just assume UTC.
<petevg> But it makes me feel bad.
<petevg> *nanoseconds
<cory_fu> petevg: Odd.  I don't recall ever seeing the Z, but maybe I just blocked it out.
<petevg> cory_fu: It was too horrifying to contemplate :-p
<cory_fu> anastasiamac: Can we get confirmation if the times reported by juju status will *always* be in UTC?
<anastasiamac> cory_fu: u can :)
<cory_fu> petevg: I say we just chop it off and assume UTC, then.  :)
<petevg> cory_fu: the actual problem is the Python datetime object that gets created. Python doesn't have native support for timezones when it creates them with strptime.
<petevg> cory_fu: so the resulting datetime object has a timezone of None.
<cory_fu> petevg: But we're only using it for a delta anyway, right?
<cory_fu> As long as we compare it to utcnow() (which is also timezoneless, IIRC), are worry about the delta, we should be fine, right?
<petevg> cory_fu: we're returning it to anyone who asks for agent_status_since or workload_status_since in python-libjuju.
<petevg> cory_fu: so we're fine, but someone else using the API might not be.
<cory_fu> OIC
<petevg> ... except that things default to UTC anyway, I think.
<petevg> Bleh.
<cory_fu> petevg: Can we take the output from the strptime and re-package it with a UTC TZ?
<cory_fu> So that we return a TZ aware DT even though we're internally just assuming it to be UTC?
<petevg> cory_fu: that's where the hacky bit comes in. You can't just tell datetime that the timezone is UTC. You have to pass in a thing with an offset and other things that it expects.
<tvansteenburgh> i would just leave it naive
<tvansteenburgh> if a consumer wants to make it timezone aware, fine
<petevg> tvansteenburgh: that's def. the easiest thing to do.
<cory_fu> Yeah, just document that it will be UTC but naive and call it a day
<petevg> kk. I will discard the "Z" without a care.
<tvansteenburgh> but i wouldn't bother in the lib unless it's actually necessary
<petevg> tvansteenburgh: cool. If someone really wants the data, they can extract it themselves from data['since'], and do dateutils things to it.
<tvansteenburgh> petevg: yeah, and we may find down the road that we want/need to add pytz or python-dateutils. but i'm in favor of holding out for as long as possible ;)
<anastasiamac> cory_fu: so status does not convert times.. it just displays whatever it finds in db
<anastasiamac> cory_fu: mongo stores times in local times and we have to manually convert times to UTC
<anastasiamac> cory_fu: we try to do that consistently on reads, but there mayb places where it does not happen (altho we try really hard, I am sure)
<cory_fu> anastasiamac: OTOH, does the cloud image use UTC as the system time anyway?
<cory_fu> Though I suppose the charm could do something crazy and change the TZ
<petevg> cory_fu, anastasiamac: I guess the good news is that the "Right Thing" that I was going to do wasn't actually going to address some times possibly being local times. So the simpler code isn't more broken than the more complex code :-)
<anastasiamac> cory_fu: :D
<cory_fu> petevg: Well, if the TZ on the unit was changed, presumably the str representation would encode the new TZ, so the dateutils approach would pick that up, right?
<petevg> cory_fu: If the repr actually had the timezone encoded, yes.
<cory_fu> petevg: Isn't Z the encoded version of UTC?
<petevg> cory_fu: yes.
<anastasiamac> cory_fu: apparently, our cloud images use utc, but clouds are allowed to change them, for eg. gce does this... (thank you juju qa for confirmation!)
<cory_fu> anastasiamac: You're making my life more difficult by the (UTC) minute.  ;)
<anastasiamac> cory_fu: the feeling is mutual ;D
<cory_fu> ha
<anastasiamac> cory_fu: but m glad we r talking \o/
<cory_fu> anastasiamac: Actually, I guess I should say that you're making petevg's life more difficult.  >=D
<petevg> All I have to do is install a lib. It will just make tvansteenburgh sad :-)
<cory_fu> petevg: It sounds like we can't rely on the value to be UTC after all, so show tvansteenburgh's who's boss and add dateutils to the requirements.txt
<cory_fu> ha
<anastasiamac> cory_fu: petevg: had a question from the group, updated in the bug :D
<petevg> anastasiamac: recreating the issue. Will drop in a reply once I'm done.
<anastasiamac> petevg: brilliant \o/ thnx :)
<petevg> np
<cory_fu> petevg: I have it available already
<petevg> That's easier, then :-)
<cory_fu> anastasiamac: Updated
<anastasiamac> cory_fu: petevg: tyvm!!
#juju 2016-12-14
<CarlFK> marcoceppi:  hi!  ..  https://github.com/marcoceppi/charm-ubuntu   -  advice on how to set hostsnames ?
<marcoceppi> CarlFK: could you elaborate why? Curious your use case and where you're deploying
<marcoceppi> it'll help me get you the best answer
<CarlFK> sure - there is an ansible playbook that provisions 12ish machines (hardware, not VM or containers)... it was started, but hasn't been run ever.  I want to test it
<CarlFK> I don't care if the apps that get deployed actually run in the containers, I just want to A) sniff out the errors, and B) look at config files
<CarlFK> https://anonscm.debian.org/git/debconf-video/ansible.git/tree/setup_ansible.sh
<CarlFK> some machines were setup manually, then that playbook was written after the fact.  "No idea if it works, and  we haven't done the dynamic bits yet"
<CarlFK> so I want to hack on it on my 8gig laptop.
<CarlFK> marcoceppi:   here are the 12 hostnames:   https://anonscm.debian.org/git/debconf-video/ansible.git/tree/inventory/hosts
<marcoceppi> CarlFK: confused on the reference to the Ubuntu charm
<CarlFK> I don't mind cut/pasting those into some other file, but if there is something that will slurp them from that file, that would be handy
<CarlFK> I want to bring up 12 things I can tell ansible to deploy into, then ssh in and look at what got setup
<marcoceppi> CarlFK: there's two real ways for hostname setting on Ubuntu, `hostname` command and overwritting `/etc/hostname`. You'll need to do the latter for persistence between reboots
<marcoceppi> CarlFK: that's not in the charm, but the best way to add it into the charm would be something like this:
<marcoceppi> CarlFK: https://github.com/marcoceppi/charm-ubuntu/pull/1/files
<CarlFK> marcoceppi:  thanks!
<skay_> oh hey. for some reason I didn't know about config.changed.foo. that's nice
<skay_> I eavesdropped on you PR
<CarlFK> marcoceppi: I just started using juju a few hours ago.. just to do this.   I git cloned/checkout carlfk... how do I tell juju to use it?
<marcoceppi> CarlFK: you
<marcoceppi> CarlFK: you'll need to compile the charm, this involes installing charm-tools and then running charm build. I can just compile it for you and give you a URL to try it out with if it's easier
<marcoceppi> CarlFK: I've uploaded a version with the configuration patch to the charm store in the edge channel
<marcoceppi> CarlFK: `juju deploy ubuntu --channel edge` should get you the charm with the changes
<CarlFK> marcoceppi: ERROR cannot resolve charm URL "cs:xenial/ubuntu": cannot get "/xenial/ubuntu/meta/any?include=id&include=supported-series&include=published": unauthorized: access denied for user "carlfk"
<CarlFK> git... charm build ... seems to have worked.
<siva> I have one application running in a machine. Is there a way to remove the application without removing the machine?
<siva> In juju2.0 I find that when the application is deleted the machine is also removed
<CarlFK> marcoceppi: +    with open('/etc/hostname', 'wt') as f:
<CarlFK> t for text, cuz py 3
<siva> In juju2.0 I find that when the application is deleted the machine is also removed
<siva> Is there a way to remove the application without removing the machine?
<kjackal> Good morning Juju world
<kjackal> siva I do not think you can have direct controll over the resource provisioning. What you can do is juju deploy ubuntu, than juju deploy <your charm> --to <machine with ubuntu> and after that if you remove-application <your charm> the machine should remain because it holds the ubuntu charm
<BlackDex> How do i upgrade the juju controller? I want to update/upgrade to 2.0.2 and i currently have 2.0.1
<zeestrat> BlackDex: I think you have to switch to the controller model, run juju upgrade-juju, then do the same on your other models. But check locally just to make sure.
<BlackDex> and how do i switch to the controller model?
<BlackDex> the logic is lost for me atm :p
<BlackDex> juju switch is telling me i'm already there
<zeestrat> juju models should list which models you have and a star marked next to the one you're currently on.
<BlackDex> Model       Cloud/Region  Status     Machines  Cores  Access  Last connection
<BlackDex> controller  maas          available         1      2  admin   just now
<BlackDex> maas*       maas          available        25    192  admin   2 minutes ago
<zeestrat> Ok, so that says the maas model is active. "juju switch controller" should switch you to the controller.
<BlackDex> so the controller which is used for maas is seperated then?
<BlackDex> ah
<BlackDex> wait
<zeestrat> The wording is a bit confusing. You're on the same controller as the switch command switches between models on that controller. The default model name for controller is "controller"
<zeestrat> That caught me out the first time too :)
<BlackDex> because the juju controller can handle multiple models it is "separeted"
<zeestrat> Jupp. So if you setup multiple controllers with HA, they would show up in the list of machines in the "controller" model
<BlackDex> and i can add multiple models to one controller, so i don't have to bootstrap for every single environment?
<BlackDex> lets say, maas and openstack
<zeestrat> Multiple models per controller = Yes. However different juju substrates/clouds (AWS, MAAS, OpenStack, etc.) need their own bootstrapped controller.
<BlackDex> where are nice graphic reprecentations of this :p
<zeestrat> I hear you! Took me a while to parse the docs. A graphic would help explain a lot. I'll add a bug to the docs.
<BlackDex> But multiple times of reading the docs is making it a bit more clear
<zeestrat> Note, if you're upgrading a prod environment I'd recommend going through the upgrade process on a dev environment such as AWS or just locally with LXD so you get the feel for it.
<BlackDex> it's a prod/dev thingy, so no prob here :)
<zeestrat> BlackDex: Added a bug to the docs for that graphic https://github.com/juju/docs/issues/1575
<BlackDex> Thx :) I have subscribed to the bug! :) Thx
<junaidali> hey guys, is there any HA bundle available for juju 2.0?
<zeestrat> Hey junaidali, do you mean HA juju controllers?
<zeestrat> If so, check out https://jujucharms.com/docs/2.0/controllers-ha. Otherwise check out https://jujucharms.com/docs/2.0/charms-ha and https://jujucharms.com/hacluster/
<marcoceppi> CarlFK: hah, thanks for the catch. Not sure why edge wasn't shared, but it's now open to everyone
<SimonKLB> it looks like there is a race between the relations and the reactive relation states - for example it takes a while before the influxdb.available state is removed from the time you have removed the actual relation
<SimonKLB> that causes the relation data to be empty, even though you're expecting it not to when the available state is set
<SimonKLB> i could do an extra check that the relation data is actually there, but it would be better if the state was better synced so that charms could rely on them more
<jcastro> rick_h: invites out to you, I just realized that you should just be a coowner of the juju g+/youtube account
<jcastro> https://www.youtube.com/live_dashboard is the url you want after you add Juju to your youtube dropdown thing
<jcastro> from there you can schedule events, etc.
<rick_h> jcastro: cool yea I was going to ask you about that at some point
<rick_h> jcastro: do I get added to the youtube group some how?
<jcastro> yeah
<jcastro> youtube inherits the G+ permissions
<rick_h> oic
<rick_h> jcastro: ok, so I've followed Juju, do you then see me/grant access?
<junaidali> zeestrat: deploying a multi-controller OpenStack
<jcastro> yeah you need to add an account to the top right account google thing
<jcastro> then sign in, and you should see juju as an option in the dropdown
<jcastro> if that's a problem just lmk and we'll hop on a hangout
<rick_h> jcastro: yea, that'd be great. Evidently I'm an addiot
<rick_h> addiot? lol idiot
<rick_h> cccccceefhftjrkgvjfinhtcfjhrbfjdhtvhnruucudi
<jcastro> it's ok rick, it's just a youtube channel.
<jcastro> :)
<zeestrat> rick_h: Do I spot a yubikey?
<rick_h> zeestrat: maybe :P
<rick_h> nano is great but sometimes "bump"
<rick_h> jcastro: https://hangouts.google.com/hangouts/_/canonical.com/rick?authuser=1
<zeestrat> junaidali: There are some older docs at https://wiki.ubuntu.com/ServerTeam/OpenStackHA Otherwise I suggest asking in #openstack-charms or the official Canonical folks in here such as rick_h or jcastro
<zeestrat> rick_h: yeah, I've had opsec go out the window a couple of times when focus follows mouse ;)
<arosales> morning
<arosales> rick_h: per your reply, ref = https://lists.ubuntu.com/archives/juju/2016-December/008341.html
<arosales> are you saying local is not supported, or resources in bundles are not supported at all in bundles ?
<rick_h> arosales: local not supported and on the roadmap this cycle. You can reference resources in bundles via the revision of the resource in the charm store
<arosales> rick_h: so there is no new key in bundle.yaml. I just have to attach the resource to the charm when I upload to the store, and then be explicit about that version in the "charm:" key in the bundle.yaml, correct?
<rick_h> arosales: no, second let me get the example
<arosales> rick_h: ok thanks
<kwmonroe> arosales: what you said is what i thought rick meant (charm rev dictates the resource rev).  thanks for clarifying!  i'm fixin to learn something.
<rick_h> kwmonroe: arosales so I believe there is a key for the resources
<rick_h> https://github.com/juju/charm/blob/v6-unstable/bundledata_test.go#L27kwmonroe: arosales see
<rick_h> bah
<rick_h> that didn't paste right
<rick_h> https://github.com/juju/charm/blob/v6-unstable/bundledata_test.go#L27
 * arosales looks
<rick_h> arosales: kwmonroe so you can have the sub-key in the application for resources, and then for each resource "name" you can specify a revision number
<rick_h> arosales: kwmonroe and the goal for this cycle is to allow that revision to also be able to be a local path like a local charm path would be
<cory_fu> rick_h: If the bundle is referencing a local charm (and thus doesn't have a definite charm store entry), can you still indicate that it should be deployed with a resource from the store?
<rick_h> cory_fu: honestly, never tried that and no idea how that'll work. I'm guessing it'll fail because the charm id in the bundle is ./ and not resolvable via the charmstore to see what resources it provides
<cory_fu> rick_h: So, it would be nice for CI to be able to say, for a local charm in the bundle, use either this local URL for the resource, or this fully-qualified resource URL from the charm store.
<rick_h> cory_fu: rgr
<rick_h> cory_fu: I can take that as feedback that a local filepath, revision, or a fq cs url would be great for the bundle spec
<cory_fu> Yep
<cory_fu> Tahnks
<cory_fu> Thanks
<rick_h> thank you for the great feedback
<arosales> rick_h: +1 to cory_fu's comment, and not the _or_ there
<rick_h> arosales: rgr
<arosales> rick_h: as a charm developer I want to iterate on a charm that has resoruces locally.
<rick_h> arosales: understand
<cory_fu> Also, as a charm developer, I want to test a local build of a charm that does already have a resource in the store
<arosales> in a bundle testing context I need to specify both the resource url and/or the charm url. I could see a case where both bits are changing during development. A more common case though would be the charm is changing locally and the resource url hasn't changed.
<rick_h> arosales: rgr
<arosales> rick_h: thanks!
<arosales> kwmonroe: kjackal: I guess for now in charm ci if we want to accommodate charms with resources the charm has to be uploaded to the charm store
<arosales> kwmonroe: kjackal: for the 1st milestone we are working on I think we can assume that the charm doesn't have resources, but we should look at the work to accomodate a charm with resources until juju lands the above mentioned work
<kwmonroe> +1 arosales
<rick_h> jcastro: we need a hash tag for juju. #juju doesn't work well with the amount of Juju music stuff. ideas?
<arosales> rick_h: #jujudevops or #jujucloud or #jujuops ?
<arosales> just throwing some out there
<jcastro> We've used #jujucharms in the past, but that might be too long
<rick_h> arosales: yea, I want to start updating our 'join the mailing list, join irc..." with a hash tag setup as well I think
<rick_h> #use-juju? hate it being the second word though
<tvansteenburgh> #jujucharms imo
<rick_h> tvansteenburgh: k, let's try that and see if we can get any update. /me goes to add a search for jujucharms
<arosales> rick_h: pinged james donner and he has been using #jujucharms
<arosales> that seems fine and has prior art
<arosales> marcoceppi: ^
<rick_h> arosales: cool ty
<lazyPower> +1
<arosales> petevg: did you continue to see the agent dying in your testing? if so did you have those bug links hand?
<arosales> juju agent that is
<petevg> arosales: The juju agent isn't dying. But the controller marks trusty machines as failed after a reboot.
<petevg> arosales: bug here: https://bugs.launchpad.net/juju/+bug/1649637
<mup> Bug #1649637: Juju agent in a "failed" state after machine reboot on some charms <juju:Triaged> <https://launchpad.net/bugs/1649637>
<petevg> arosales: matrix will also deliberately kill an agent. It should come back up. If you're not seeing it do so, that might be a different bug.
<arosales> petevg: cory_fu: is 1649637 the main bug or are there others we should make juju-core aware of others
<petevg> arosales: that is the only bug that I am aware of. If there are others, they need to get filed.
<arosales> petevg: thanks
<petevg> np
<cory_fu> arosales: Yeah, I don't think there are any others that are blocking us at the moment
<arosales> cory_fu: it sounds like a bug didn't get filled for juju marking a machine as "destroyed" immediately in the api so further requests don't hit that same machine?
<petevg> arosales: Nope. That was a red herring. Destroying the machine doesn't break stuff. The API does the right thing.
<arosales> petevg: ah excellent to hear
<skay> why would mojo not be able to find a charm in the store but calling juju deploy from the command line does?
<skay> (I'm looking at the source code now, but if anyone knows, let me know)
<stub> skay: You are using a cs: URL in your manifest?
<cory_fu> tvansteenburgh: Updated https://github.com/juju/python-libjuju/pull/31
<skay> stub: yes, cs:~codersquid/submission-service
<stub> skay: That is codetree rather than mojo. Might make it easier to track down the issue.
<skay> stub: thanks
<skay> I'm looking at this stacktrace https://paste.ubuntu.com/23629882/
<stub> https://jujucharms.com/u/codersquid/submission-service gives me a 404
<skay> does this work? https://jujucharms.com/u/codersquid/submission-service/0
<stub> Nope
<skay> (I'm assuming it will give a 404 to you but might as well check)
<skay> arg this is confusing. I'm not logged in
<skay> I probably pushed it incorrectly, so I'll review the docs for making a release
<cory_fu> tvansteenburgh: Ugh.  Thanks for the catch.
<tvansteenburgh> cory_fu: :) np
<stub> skay: You might have missed the step granting read access to everyone?
<stub> (I don't know if codetree/mojo supports private charms on cs: URLs)
<skay> stub: you are right, I missed the grant step
<skay> stub: I added a resource (which should be optional) so that users of the charm can either use the snap store or attach a snap resource
<skay> when I try to do a release, I get an error, resources are missing from publish request
<stub> yes, that policy in the charm store is causing lots of people grief.
<stub> The work around is to attach 0 byte files as resources, but I haven't had a chance to see if that works with the snap layer yet
<stub> (it will be a minor fix if it doesn't)
<skay> I could try it out and see what happens. I tried attaching a snap as a resource for the charm, but I really don't want to do that
<stub> skay: If it fails, you can work around by having mojo deploy from a git branch rather than the charm store. I can sort the snap layer tomorrow (unless you beat me to it)
<anrah> Question about resources.. can I set them on bundle-file?
<anrah> i tried to use resources: and then list needed resources one by one but that did not work
<skay> anrah: I opened an issue for it https://bugs.launchpad.net/juju-deployer/+bug/1643692
<mup> Bug #1643692: add feature to support juju2 resources <juju-deployer:New> <https://launchpad.net/bugs/1643692>
<skay> I want to be able to use options too
<anrah> ok, thanks for that :)
<anrah> i'll guess that I have to use block when resource is not available
<skay> stub: it does cause a hiccup. is checking for a zero length file a good approach for it? https://paste.ubuntu.com/23630058/
<jcastro> rick_h: wanna fire this up early? the hangout I mean
<rick_h> jcastro: already there
<rick_h> jcastro: https://goo.gl/mgACZH for the HO
<rick_h> jcastro: http://youtu.be/FwLEMa7XE64 for the youtube watcher link
<skay> stub: https://paste.ubuntu.com/23630104/ I'm going to try this, but I don't know how to actually test changes I make for a layer
<rick_h> alexisb: cory_fu kwmonroe links above ^ use the HO link
<cory_fu> rick_h: Access denied
<rick_h> cory_fu: boooo, /me looks
<tvansteenburgh> cory_fu: i got that at first to
<tvansteenburgh> but refreshed and it worked
<tvansteenburgh> (too)
<rick_h> cory_fu: please try again, it let everyone else in
<rick_h> or did you offend the google gods?
<cory_fu> rick_h: I fixed it by removing the explicit authuser=0
<rick_h> ah ok
<rick_h> HEY EVERYONE! Juju Show #2 about to start if you're interseted
<rick_h> chat here: https://goo.gl/mgACZH and follow here: http://youtu.be/FwLEMa7XE64
<jrwren> jcastro: that is not funny. ;)
<kwmonroe> i need optional resources!  ibm-was-base, for example, takes an installer resource and a fixpack resource.  fixpack should be optional!  https://api.jujucharms.com/charmstore/v5/~ibmcharmers/ibm-was-base/archive/metadata.yaml
<cory_fu> http://svg.juju.solutions/
<kwmonroe> https://lists.ubuntu.com/archives/juju/2016-December/008312.html
<zeestrat> The controller/model upgrade procedure sure could use some better docs both in CLI and online. See https://bugs.launchpad.net/juju/+bug/1638714
<mup> Bug #1638714: Upgrading a juju model before the controller gives unhelpful error message <usability> <juju:Triaged> <https://launchpad.net/bugs/1638714>
<cory_fu> https://github.com/juju-solutions/matrix
<arosales> kwmonroe: is there a bundle in the charm store for cwr-bundle-ci?
<arosales> kwmonroe: or should folks just use https://github.com/juju-solutions/bundle-cwr-ci
 * arosales guesses the latter
<kwmonroe> arosales: yeah, there is a bundle, but it's in -edge.  you can juju deploy -c edge ~juju-solutions/cwr-ci
<kwmonroe> let me check our edge perms to see if i can give everyone read access
<arosales> kwmonroe: thanks
<lazyPower> rick_h <3 https://github.com/juju/docs/issues/1576
<kwmonroe> arosales, et al: ci bundle:  https://jujucharms.com/u/juju-solutions/cwr-ci/2;  same thing with revq in the mix:  https://jujucharms.com/u/juju-solutions/cwr-rq/3
<arosales> kwmonroe: thanks
<jrwren> rick_h: you would not like my machine name :)
<rick_h> jrwren: :P
<rick_h> one word or bust!
<jrwren> rick_h: oh, its one word... gogogogogogogo
<rick_h> lol
<jrwren> and yes, I get the number correct every time.
<rick_h> tab complete ftw
<jrwren> no tab complete. I just know the song to sing.  Also, its just "gogo" in my PS1. Does that help at all?
<sparkiegeek> cory_fu: https://github.com/juju-solutions/matrix/issues/46 FYI
<cory_fu> sparkiegeek: There is already a PR to address that: https://github.com/juju-solutions/matrix/pull/44  :)
<sparkiegeek> cory_fu: damn it, did you steal Guido's time machine again? (thanks)
<cory_fu> :)
<cory_fu> sparkiegeek: Feel free to review that PR for me.  ;)
<cory_fu> (Rendered view: https://github.com/juju-solutions/matrix/blob/ef7d2171635243fc0d8ed3e7adfaebd2026bdbe2/README.md)
<Merlijn_S> Happy holidays!
<jrwren> thanks rick_h
<jrwren> great demo Alexis
<marcoceppi> sad I couldn't join in, looking forward to watching soon
<rick_h> marcoceppi: we missed you!
<marcoceppi> NEXT TIME
<rick_h> Jan 4th
<rick_h> be there!
<sparkiegeek> cory_fu: looks like requirements.txt is asking for ubuntui >= 0.1.1 but that doesn't exist (on pypi)
<marcoceppi> bcsaller, petevg: Juju Show might run over making me late for the Matrix sync
<cory_fu> sparkiegeek: All the deps for matrix are bundled in the wheelhouse/ folder, but I will ping stokachu to get that version out to pypi. :)
<cory_fu> sparkiegeek: Hrm.  I see, the instructions say to install it from GH, which won't use the wheelhouse.
<skay> My charm uses a layer, and I have a fix for hte layer to disregard empty resources. I don't know how to test changes to a layer. helphelp
<cory_fu> stokachu: Can we get a 0.1.1 release of ubuntui?
<skay> change is here https://code.launchpad.net/~codersquid/layer-snap/+git/layer-snap/+ref/handle-empty-resources
<sparkiegeek> cory_fu: yeah I didn't quite follow those anyway - I just ran "pip3 install ." from a clone
<skay> I think stub will be around tomorrow and could take a look, but I would like to test it
<cory_fu> sparkiegeek: Fair enough.  If you add `-f wheelhouse` to that, it will work
<stokachu> cory_fu: yea
<cory_fu> stokachu: Thanks!
<stokachu> why is it so difficult to upload a resource to the charm store
<stokachu> http://paste.ubuntu.com/23630347/
<stokachu> what is the problem here
<sparkiegeek> cory_fu: oh, looks like bcsaller already merged it :/ still looks bogus to me - not your branch but contents of requirements.txt
<sparkiegeek> cory_fu: the next headache I got was "juju>=0.0.1,<1.0.0" pulling in pyjuju from PyPi and trying to install zookeeper (!)
<sparkiegeek> y'all should get some CI on your CI framework :P
<cory_fu> tvansteenburgh2: ^ is us hitting up against the already claimed "juju" project on pypi.  Can we prioritize reclaiming that or working around it with a different package name?
<tvansteenburgh2> that's why you need to install from the wheelhouse sparkiegeek
<tvansteenburgh2> the main dep isn't even released yet
<tvansteenburgh2> cory_fu: yeah, i'll look into that this afternoon
<cory_fu> tvansteenburgh2: Thanks.  Other option is for me to  update the instructions in the README, but I dislike not being able to install it the normal way
<cory_fu> tvansteenburgh: But if it's going to take some time, then I'll update the README
<tvansteenburgh> cory_fu: yeah i need to get this sorted asap anyway since i wanted to do a libjuju release next week
<sparkiegeek> tvansteenburgh: I'm trying. "pip3 install . -f wheelhouse/" lead to: http://paste.ubuntu.com/23630386/
<stokachu> cory_fu: https://pypi.python.org/pypi/ubuntui/0.1.1
<cory_fu> stokachu: Great, thanks!
<stokachu> np
<kwmonroe> stokachu: did you get the charm attach issue sorted?
<stokachu> kwmonroe: not yet
<kwmonroe> stokachu: have you run the exact same command again?  i know it sounds dumb, just run it again.
<stokachu> kwmonroe: http://paste.ubuntu.com/23630362/ my latest failed attempt
<stokachu> k running again
<petevg> sparkiegeek: does "tox -r" succeed? (We might have a dependency listed in a place that tox can spot, but pip can't.)
<stokachu> kwmonroe: still fails
<stokachu> i was just told new packages are being pushed to charm store
<stokachu> so ill try again later
<sparkiegeek> petevg: yes it does
<sparkiegeek> cory_fu: petevg: bcsaller: I'm going to reopen #46, since although the specific failure case is no longer happening after Cory's branch landed, it does still exhibit errors
<kwmonroe> ok stokachu -- i have seen that before, but running attach twice worked.  maybe it's just bad store timing.
<tvansteenburgh1> hazmat: can i take over the 'juju' package name on pypi? we have a new python client that we want to put there
<petevg> cory_fu: I don't get sparkiegeek's permission denied error when building zkpython, but I do get an error about a missing header file.
<sparkiegeek> petevg: yeah the permission thing is my local system being a bit screwy - http://paste.ubuntu.com/23630440/ was in a clean LXD
<sparkiegeek> in the (recently changed) README.md there's no use of the wheelhouse
<cory_fu> sparkiegeek: Also, your pastebin with the permission denied didn't include "sudo"
<sparkiegeek> cory_fu: indeed, deliberately so
<petevg> cory_fu: Yeah. But there's a build issue even if you're not sparkiegeek, and trying to build stuff in your system Python :-)
<sparkiegeek> a snap for it would be nice (and avoid this mess)
<petevg> True.
<sparkiegeek> sudo pip3 install git+https://github.com/juju-solutions/python-libjuju.git#egg=juju
<sparkiegeek> sudo pip3 install 'git+https://github.com/juju-solutions/matrix.git'
<sparkiegeek> in that order seems to be the right incantation
<sparkiegeek> (but it still ignores the wheelhouse)
<cory_fu> sparkiegeek, petevg, bcsaller: https://github.com/juju-solutions/matrix/pull/47
<cory_fu> sparkiegeek, bcsaller, petevg: I was missing the --no-index which was causing it to try the old juju lib from pypi
 * sparkiegeek spins up another clean LXD
<petevg> cory_fu: aha. That works for me in my virtualenv :-)
<sparkiegeek> cory_fu: :( so the install "worked" but actually running it fails miserably
<sparkiegeek> cory_fu: http://paste.ubuntu.com/23630574/
<cory_fu> sparkiegeek: Ah.  Missing the file from the manifest.
<sparkiegeek> cory_fu: I'll open a new issue
<sparkiegeek> https://github.com/juju-solutions/matrix/issues/49
<sparkiegeek> petevg: I guess you'll also be seeing https://github.com/juju-solutions/matrix/issues/49 ?
<petevg> sparkiegeek: ayup.
<petevg> Agree w/ cory_fu that it should just be a matter of adding the default .yaml to the manifest, though.
<cory_fu> petevg, sparkiegeek: https://github.com/juju-solutions/matrix/pull/50
<petevg> cory_fu, sparkiegeek: that branch seems to work for me.
<petevg> Matrix is running, at least ...
<petevg> Went ahead and merged it ...
<petevg> cory_fu: ... though it looks like maybe you didn't rebase from master, as I see a datetime related error.
<cory_fu> petevg: It definitely was rebased from master
<petevg> cory_fu: darn it. Looking at the trace ...
<petevg> Huh. Maybe it's grabbing the wrong version of libjuju ...
<petevg> cory_fu: yeah. Wrong version of python-libjuju. The file sizes are different. Maybe a merge clobbered my checkin.
<cory_fu> petevg: https://github.com/juju-solutions/matrix/commits/master/wheelhouse/juju-0.0.1-py3-none-any.whl looks fine to me
<petevg> cory_fu: I must have messed up the commit, then. Copied the wrong thing. :-/
<cory_fu> petevg: I'm running a test in a fresh venv.  I'll let you know if I see the same thing
<cory_fu> petevg: At what point did you see the error?
<sparkiegeek> I don't see timestamp issues per se, but I get a libjuju traceback trying to decode JSON from constraints
<petevg> cory_fu, sparkiegeek: I just pushed an updated python-libjuju build to matrix master. If you have trouble, pulling the new build should fix things.
<petevg> sparkiegeek: interesting. That's new. What bundle are you testing?
<sparkiegeek> petevg: https://jujucharms.com/u/landscape/landscape-dense/
<petevg> sparkiegeek: cool. I'll download it and see if it does the same thing on my machine.
<cory_fu> petevg: I didn't get any error wrt timestamps on the dep before you just pushed, but a new one won't hurt anything either.
<sparkiegeek> petevg: FWIW http://paste.ubuntu.com/23630680/ is relevant snippet from matrix.log
<petevg> cory_fu: Cool. I figured the new build wouldn't hurt anything (it's actually possible that I hadn't pull from master before I tested).
<sparkiegeek> petevg: naively reading the traceback, it seems libjuju might be expecting constraints to be JSON?
<sparkiegeek> *shrug*
<petevg> sparkiegeek: That's the root of the problem, but there's a trip to the plan builder API in there, and a bunch of annoying complexities. I think that this may be related to a bug that I squashed, but maybe didn't squash all the way ...
<petevg> cory_fu, sparkiegeek: looks like we need to do more of the thing that I did in https://github.com/juju/python-libjuju/blob/master/juju/constraints.py, but for resources. Will file a ticket.
<petevg> cory_fu, sparkiegeek: https://github.com/juju/python-libjuju/issues/35
<petevg> Not a fast fix, unfortunately :-/
<sparkiegeek> petevg: resources? there are no resources here?
<sparkiegeek> petevg: am I missing something?
<petevg> sparkiegeek: I thought that the thing under "options" in landscape-server was a resource. In any case, the planner says that we need to do something with "https://github.com/juju/python-libjuju/issues/35", and that's getting turned into a Value object in python-libjuju, and that's failing, because we need to parse it first.
<petevg> ... which is going to change in future versions of juju, because that's too much parsing on the client's part. But for now, it's what we have to do :-)
<petevg> sparkiegeek: actually. nevermind. I'm totally wrong. Misread the traceback. It's the constraints. Which are supposed to be fixed.
<petevg> yarr.
<petevg> sparkiegeek, cory_fu: https://github.com/juju/python-libjuju/issues/36
<petevg> That's easier to fix. I have to head out to an event in a few minutes, though, so I will have to fix it tomorrow (unless someone else grabs it).
<rick_h> cory_fu: kwmonroe ping, either of you free to help me out with something please?
<rick_h> lazyPower: as well ^
<cory_fu> rick_h: Sure, what's up?
<rick_h> cory_fu: can you join https://hangouts.google.com/hangouts/_/canonical.com/bs-squad?authuser=1 please? (adjust authuser)
<marcoceppi> I like the name bs-squad
<lazyPower> it clearly stands for "Bear suit"
<jrwren> is there a way to juju run on every machine? e.g. I don't know what contraints were used to deploy and so I want to cat /proc/cpuinfo and run free on every machine and collect the results.
<jrwren> nevermind. NOW I see juju run --all
<lazyPower> jrwren hey there's juju run --all
<lazyPower> (extremely latent)
<kwmonroe> next time someone brings up the elastic beats stack or prometheus or nagios, i'm gonna be like "juju run --all 'cat /proc/cpuinfo && free".  thanks jrwren!
<lazyPower> kwmonroe i think i lost context....
<lazyPower> [15:05:12] jrwren:	is there a way to juju run on every machine?  -- is the last of the log i have.
<kwmonroe> lazyPower: read the "e.g." on that same line
<lazyPower> hah, ok
<lazyPower> but unit profiling is different than unit instrumentation.
<kwmonroe> ugh.  can't you just give me a sensible chuckle and move on?  it was joke.
<lazyPower> hehe, that was *totally* clever kwmonroe. You should quit your day job ;)
<kwmonroe> :)
<teranet> do we have any juju expert on here
<lazyPower> teranet debateable ;)  What can we help you with?
<teranet> I try to figure out why certan charms and machine's are down
<teranet> I have a MAAS /  JUJU Enviroment which will alter has also Openstack
<teranet> but rihgt now I try to deploy the JUJU charms and it looks to me it's somewhere hanging
<teranet> for example is there a way to see what the spec for the a charm is like CPU . RAM DISK and so on ? Or isn't there ?
<lazyPower> teranet - Spec's are defined as 'constraints'
<kwmonroe> teranet: what version of juju are you running?  (output of 'juju version')
<lazyPower> constraints aren't really modeled in teh charm, they are instead modeled in the bundle you're using to deploy the solution.
<teranet> running juju 2.0.2 xenial
<teranet> http://picpaste.com/5830848bfd3851694ceb8e615e676610.JPG
<teranet> this is my status when I run juju status
<kwmonroe> teranet: how long have those machines been in the 'down' state?
<teranet> juju deploy cs:bundle/openstack-base-48   is what I had run
<teranet> and for over 12h now if not even longer
<kwmonroe> ahh.. ok.  i was going to say "give it a minute or 2".  but *hours* means something else is happening.
<marcoceppi> teranet: they've never seemed to have been allocated
<marcoceppi> teranet: how mnay maas nodes do you have?
<teranet> currently 6 all same hardware specs
<marcoceppi> teranet: how many have been allocated in the MAAS ui?
<teranet> all
<teranet> all 6 are deployed with Ubuntu 16.04 LTS   24 core  32GB Ram and 479GB Disk space
<marcoceppi> teranet: can you run `juju status --format yaml 23 25`
<teranet> my concerns is somewhere it's hitting limits but don't know exaclty where and what
<marcoceppi> teranet: well, machines are deployed that are no enlisted in juju
<teranet> ok let me upload the output hold on
<teranet> http://paste.ubuntu.com/23631220/
<teranet> here is the output of it
<marcoceppi> teranet: so the first block is interesting, because the machine is pending
<marcoceppi> teranet: meaning Juju really doesn't have a machine assigned
<marcoceppi> 25 is a failure to deploy from MAAS
<marcoceppi> teranet: what I would do, is destroy this controller
<marcoceppi> make sure maas returns all the machines to ready
<marcoceppi> teranet: then deploy again
<teranet> ouch that's some bigger work than
<teranet> ok so how do I destroy it ?
<marcoceppi> teranet: you've got all 6 machines as deployed in maas, but this install only sees two machines assigned to it, and one machine failed in juju's mind
<marcoceppi> teranet: `juju destroy-controller --destroy-all-models <controller-name`
#juju 2016-12-15
<teranet> k done : http://paste.ubuntu.com/23631252/
<marcoceppi> teranet: what does MAAS say now?
<teranet> 3 Ready  3 deployed
<marcoceppi> teranet: okay, so you've got 3 nodes doing something else?
<teranet> nope
<teranet> should I release those too ?
<marcoceppi> teranet: release those manually then
<teranet> 1 I know had a hardware issue which I fixed
<teranet> ok will do
<teranet> ok now they are all ready
<teranet> so now I should bootstap again ?
<teranet> correct ?
<teranet> ok bootstapping a controller again
<marcoceppi> teranet: yes, bootstrap and deploy again
<teranet> for juju-gui can I only deploy the gui to make it work or does the rabbitmq server has to be deployed too?
<teranet> and mysql sorry forgot that one LOL
<bdx> teranet: what I would do, when all your maas machines are in a 'ready' state, is `juju add-machine -n 6`
<bdx> teranet: and just make sure they all deploy successfully without any charms or bundles
<teranet> hmm ok will do that
<bdx> then once you verify that, the rest should fall into place
<teranet> how do I add later more to it ?? does juju does it automaticly once maas say''s they are ready ?
<bdx> teranet: yea, your `juju status` will show them as 'started'
<bdx> if you succeed in ^, the rest will work given you have your maas<->juju<->openstack networking aligned
<teranet> ok will check it
<marcoceppi> teranet: juju gui doesn't require anything
<marcoceppi> teranet: it's already deployed by default, just run `juju gui` command
<teranet> ah ok cool
<wetoolaguer> Hi everybody, I'm trying to use this bundle https://jujucharms.com/kubernetes-core/ but it's installing the latest version of kubernetes. How can I force it to use an older version? Thanks a lot!
<stub> skay: ta. I'll test and merge that and add some docs on the charm store publication workaround.
<stub> skay: released
<stub> kwmonroe: My issue on that is https://github.com/juju/charmstore-client/issues/103
<kjackal> Good morning Juju world!
<deanman> Hello, is it possible to auto-scale (regardless the infra) the worker node of a juju kubernetes deployment?
<deanman> or do you have to create a custom solution that monitors kube workers load and decides whether to request for extra resources (lxd, VMs) using the API of the underlying infra?
<voidspace> frankban: ping
<frankban> voidspace: hey
<voidspace> frankban: hey, hi
<voidspace> frankban: I have made a change to bundlechanges that I would appreciate you looking at
<frankban> voidspace: sure
<voidspace> frankban: https://github.com/juju/bundlechanges/pull/29
<voidspace> frankban: we need container placement to honour application constraints
<voidspace> frankban: this change implements that
<voidspace> frankban: but the bundlechanges package is new to me :-)
<voidspace> frankban: when you get a chance anyway
<frankban> voidspace: looking
<voidspace> frankban: for context, this is the juju bug https://bugs.launchpad.net/juju/+bug/1626597
<mup> Bug #1626597: Juju ignores constraints set in the bundle and deploys KVMs with default values <4010> <juju:Triaged by mfoord> <https://launchpad.net/bugs/1626597>
<frankban> voidspace: reviewed
<voidspace> frankban: your analysis of the bug seems correct and passing constraint only rather than application is reasonable, however also <shrug>
<voidspace> frankban: :-)
<voidspace> frankban: the new test, when the unit is located to "new", that can't be a container can it?
<frankban> voidspace: yeah that's the kind of "take it or leave it" suggestion, the branch is good, happy to see that bug discovered
<voidspace> frankban: a unit can only be located on a container if placement is specified
<voidspace> frankban: i.e. I'm not entirely sure what you mean by "new" :-)
<frankban> voidspace: it cannot, but since your change touches that it would be nice if that's exercised by a test anyway
<frankban> voidspace: "new" is a special placement meaning new top level machine
<voidspace> frankban: right
<voidspace> frankban: is that an explicit placement?
<voidspace> frankban: ah, I see it in the code - I will try and work it out
<frankban> voidspace: which is the default if no placement is specified, but for instance, IIRC, can be used in a multiple placement definition, like to: ["1", "new", "lxd:2"] or similar
<voidspace> frankban: ah, I see
<voidspace> frankban: understood
<frankban> cool
<voidspace> frankban: I may be able to remove that change - let me check
<frankban> voidspace: for instance https://github.com/voidspace/bundlechanges/blob/37e0752c3c530d1af168b3a2f90592dc9ce85549/changes_test.go#L286
<voidspace> frankban: I added the change there too because I saw a ContainerType
<voidspace> frankban: yep
<frankban> voidspace: I don't think that's a bad change, maybe that's required as well
<voidspace> frankban: right, it might actually be a different bug...
<voidspace> frankban: ok, I'll add a new test :-)
<frankban> voidspace: ty
<voidspace> the new machine should honour application constraints as well
<frankban> indeed
<CarlFK> juju deploy /home/juser/temp/charm-ubuntu/builds/ubuntu monitor - 27 of those, 25 started, 2 are State:pending
<CarlFK> it has been like that at least 5 hours.
<voidspace> frankban: I've added a new test for the case you suggested and made the change to explicitly pass constraints rather than the whole application spec
<voidspace> frankban: and I'm going to land the change
<frankban> voidspace: cool thanks
<voidspace> frankban: thanks for your help
<voidspace> frankban: is it the usual $$magic$$ to trigger the landing bot on that branch as far as you know?
<voidspace> frankban: if there's no landing bot I might will have to ask you to land it, as I don't have write access to that repo
<voidspace> frankban: it's alright, I found the magic...
<frankban> voidspace: sorry, on call, it's :shipit: probably
<voidspace> frankban: it is, and it's done - sorry for the noise
<frankban> np
<cory_fu> tvansteenburgh: I'm trying to see the delta between the latest and next-most-recent review rev of https://review.jujucharms.com/reviews/24 and it seems to include a bunch of stuff that was not specifically changed in the latest rev.  Am I missing something?
 * tvansteenburgh looks
<cory_fu> tvansteenburgh: nm, I was reading the diff wrong.  It's actually showing the right stuff
<tvansteenburgh> cory_fu: can you give an example of a something that's displayed but shouldn't be? like, name a file
<tvansteenburgh> oh okay
<teranet> ok quick question on juju network ranges
<teranet> I have my MAAS to use 10.5.x.x/24 but somehow now all of the sudden when I deployed juju charms those charms took 10.0.0.x IP's where do I can see and change that ?
<marcoceppi> teranet: that's odd, do you have multiple spaces configured?
<teranet> no not yet
<teranet> where could I see what spaces / ranges juju uses ?
<rick_h> teranet: it reads them from maas. You can use list-spaces to see what spaces it sees
<rick_h> teranet: and show-machine 0 to see details about the machine and what networks it's on
<teranet> ok that only shows what I  configured : http://paste.ubuntu.com/23634617/
<teranet> but below you can see my charm's somehow have also 10.0.0 in use .....
<rick_h> teranet: adjust the number of the machine to the one that your charm is deployed on
<teranet> can that be something within the charms ? even when I deployed the yaml none had any network setups in it
<rick_h> teranet: not really, the charms are handed a machine to run on so it's what maas has for network config and what you've done in Juju to specify deployment constraints
<teranet> ok updated
<rick_h> teranet: when you update the pastebin the link url changes
<rick_h> teranet: so can't see any changes with the other url
<teranet> http://paste.ubuntu.com/23634623/
<teranet> ups :-) there we go
<rick_h> teranet: does MAAS provide dhcp and is it providing dhcp on both subnets?
<rick_h> teranet: in Juju the containers should be getting their IP addresses from the MAAS dhcp server
<teranet> MAAs provides DHCP on the default which is 10.5.100...
<teranet> but only on eth0
<teranet> eth1 is reserved for public only
<teranet> any idea ?
<gQuigs> how do I tell juju2.0 to use a specific LXD image?
<gQuigs> that I installed into LXD manually
<gQuigs> or do I have no choice and I have to use simplestreams?  (the environment this is going in is completely offline, with manually syncing of everythng)
#juju 2016-12-16
<lazyPower> stokachu - i know its late, i discovered this and submit a patch https://github.com/conjure-up/spells/pull/23   LMK if i broke the spell or anything... I'm not super familiar with what the ExposeResult method does.
<stokachu> lazyPower: o/
<lazyPower> \o
<stokachu> lazyPower: trying to work through deis and helm
<stokachu> looking at your pr now
<lazyPower> ahhhhhhh :D
<lazyPower> that makes me excite
<lazyPower> i volunteer to pilot your spells
<stokachu> :D
<stokachu> lazyPower: i need a good name for it though
<stokachu> ive got 2 spells named Canonical Kubernetes and Kubernetes Core
<lazyPower> stokachu - why not just use the software name?  conjure-up deis
<stokachu> ah i like that too
<stokachu> sold
 * lazyPower hands stokachu a nicely wrapped deis with a bow
<lazyPower> that'll be 59.99
<stokachu> lol
<stokachu> lazyPower: small comment on the PR
<lazyPower> ack, taking a look
<stokachu> exposeResult just prints to the summary screen at the end of conjure-up
<lazyPower> actually, is there a way i can test a spell locally?
<lazyPower> disclaimer, in true lazy fashion, i have not read the docs
<stokachu> lazyPower: yea if you want to clone the spells github
<stokachu> and just do conjure-up -d path/to/spell
<stokachu> or cd into the spell dir and do conjure-up -d .
<lazyPower> aahhh ok
<lazyPower> thanks for the tip
<stokachu> np
<lazyPower> i'l give it a run before i resub
<stokachu> cool man
<stokachu> lazyPower: so with deis we've been trying to avoid installing binaries on the users host system
<stokachu> it's not a hard rule, but one other option we thought of was deploy an ubuntu charm
<stokachu> and installing deis/helm on that
<stokachu> or does it really make more sense for those things to be on the users system locally?
<lazyPower> that seems expensive
<lazyPower> a unit in cloud $X for just 1 bin
<stokachu> are they just binaries?
<lazyPower> i'll hvae to take another look
 * stokachu hasn't looked to deep in them yet
<lazyPower> but i thinkt hats the case
<stokachu> if they are just like go compiled binaries i think that should just be fine to put locally
<stokachu> like we do with the kubectl script
<lazyPower> yeah
<lazyPower> that ^
<lazyPower> its just like kubectl
<stokachu> cool ill do that then
<stokachu> i got the paas itch
<stokachu> hopefully it'll make a comeback
<lazyPower> stokachu - you're in good company, and the deis stack is pretty nice.
<lazyPower> stokachu oh hey, have you seen the new debug action on the kubernetes charm?
<lazyPower> debugging-info ++
<deanman> Good morning, could anyone check the following http://paste.ubuntu.com/23637511/ and let me know if their shell gets also frozen? Not sure whether it's a bug or my setup.
<narindergupta> how can i install juju-core of 1.25.5 as 1.25.6 is having issue on trusty?
<deanman> narindergupta, Try this, could work -> `apt-get install Â«pkgÂ»=Â«versionÂ»`
<narindergupta> deanman, no unfortunately it does not exist. I tried all combination. So i ended up download using wget and use dpkg -i but now need to upload 1.25.5 tools only. so figuring it out juju bootstrap command to upload old version of tool.
<narindergupta> deanman, do you have that handy?
<deanman> narindergupta, there is a way to explicitly state the tools you need to upload during bootstrap.
<deanman> `juju bootstrap --agent-version` https://jujucharms.com/docs/1.25/commands#sync-tools. Is that what you want ?
<deanman> or maybe this `--upload-tools (= false)` is more pertinent?
<narindergupta> deanman, thanks i think thats what i was looking for
<mgz> narindergupta: you probably don't need --upload-tools, jsut give the --no-auto-upgrade on bootstrap with the 1.25.5 client
<narindergupta> mgz, ok will try that thanks
<mgz> also, what's your issue with .6? tls version?
<narindergupta> mgz, correct thats the issue
<narindergupta> mgz, i wrote this issue but status is not won't fix
<narindergupta> mgz, also with maas 2.1 and juju 2.x i am finding it uses lxdbr0 which is private network for lxd so somehow all of my deployments with current codes are failing.
<narindergupta> i have stable with juju 1.25.6 and maas 1.9.x which fails due to tls issue
<narindergupta> and maas 2.1 with juju 2.0 failed because ips used in lxd machines are from lxdbr0
<gQuigs> can I manually specify an LXD image to bootstrap Juju with?
<gQuigs> *local only LXD image
<gQuigs> or do I have to use simplestreams?
<vmorris> bootstrapping into a manual provider, what's the ideal way to setup the lxd bridge on the machines so that they'll bridge out to the physical network?
<vmorris> ideally there would be (and maybe already exists) a way to specify which interface on the machine I want lxdbr0 to bridge to (no NAT), and a pool of IP addresses from which new units would pick from
<vmorris> this was all easy to do with MAAS as the provider, but i cannot use it for this currently
<Teranet> Good morning everyone
<cory_fu> tvansteenburgh: You still around to take a look at my BT PR?  https://github.com/juju-solutions/bundletester/pull/80
<sf> I need a help on this one
<sf> Is there a way to get the num-units deployed/added in my charms code?
<sf> Either juju deploy --n <num> or juju add-unit -n <num>
<sf> I want to dynamically fetch the number of units added in my charm code
<sf> How can I get that info?
<cory_fu> sf: Your charm will have a peer relation to itself, and you can count the number of units on the peer relation with relation-list
<sf> @cory_fu, thanks. How do I go it programmatically in python.  charm/hooksenv.py does not have relation-list function
<sf> @cory_fu, thanks. How do I get it programmatically in python.  charm/hooksenv.py does not have relation-list function
<cory_fu> sf: hookenv.related_units(rel_id)
<sf> @cory_fu. Thanks
<cory_fu> sf: np!
<sf> @cory_fu. it works but it doesn't include itself. say you have 3 units, the peer relation returns only 2
<cory_fu> sf: That's true.  It only counts the number of peers, so if you want the total, you have to add 1 for yourself
<tvansteenburgh> cory_fu: still around?
<cory_fu> tvansteenburgh: Yep
<tvansteenburgh> cory_fu: do you need a release of this bundletester patch?
<cory_fu> tvansteenburgh: It would help with my debugging, yes.
<tvansteenburgh> cory_fu: done
<cory_fu> Thanks!
<tvansteenburgh> cory_fu: np, going afk, text me if you need another one
<cory_fu> tvansteenburgh: Much obliged!
#juju 2017-12-11
<andrew> Or, can I set a service's container's hostname?
<andrew> For example, if a charm like keystone is set to have an os-public-hostname like 'keystone.maas', does it register that name with MAAS, or does it just assume DNS will get updated eventually?
<[Kid]> when i use Vsphere as a cloud provider, how can i specify which datastore the controller goes on when bootstrapping/
<[Kid]> when i use Vsphere as a cloud provider, how can i specify which datastore the controller goes on when bootstrapping/
<torontoyes> Is there any documentation for crating a charm to deploy windows 10 to baremetal or VMware vm?
<torontoyes> using MAAS?
<jose-phillips> hi
<jose-phillips> how i can run a modified charm from my hard drive
<jose-phillips> ?
<pmatulis> jose-phillips, point juju at it
<pmatulis> https://jujucharms.com/docs/devel/charms-offline-deploying
<jose-phillips> ok
<jose-phillips> and if in the status keep on waiting
<jose-phillips> what means?
<jose-phillips> nevermind :)
<jose-phillips> and another question
<jose-phillips> how i can upload my charm
<jose-phillips> to the jujucharms repo?
<pmatulis> jose-phillips, the docs are unclear on the subject. we're in the middle of rewriting stuff and there is conflicting information
<jose-phillips> oh k
<pmatulis> jose-phillips, see bottom of https://jujucharms.com/docs/2.3/developer-getting-started
<jose-phillips> because im testing a charm that i do for NetApp storage driver
<jose-phillips> for cinder
<jose-phillips> and im just making some tweaks
<jose-phillips> to make it work
<pmatulis> cool
<jose-phillips> another question i have a app that is on error state
<jose-phillips> i know what i need to change to make it work again
<jose-phillips> but now i can't remove the app because is on error state
<jose-phillips> exist a way to change the charms and re-deploy or remove on error state
<jose-phillips> ?
<jose-phillips> nevermind
<jose-phillips> i solved
<jose-phillips> :)
<torontoyes> pmatulis: can juju be used to deploy a custom windows 10 image?
<torontoyes> I mean. is this a practical use for juju?
#juju 2017-12-12
<pmatulis> tor...
<[Kid]> when i use Vsphere as a cloud provider, how can i specify which datastore the controller goes on when bootstrapping/
<rsam> Hi!
<rsam> Im following the tutorial from https://medium.com/intuitionmachine/kubernetes-gpus-tensorflow-8696232862ca, trying to set up a project for the first time, and I'm stuck deploying
<rsam> for some reason flannel never finishes (remains in Blocked status), and I'm not sure how to debug it
<rsam> could someone please help me debug what the issue is?
<rsam> I have tried changing the configuration of the instances. Currently trying 1 gpu p2 instance. But still getting stuck
<rsam> "(update-status) Missing flannel resource." might be the culprit
<rsam> updating revisions for all charms worked for me
<[Kid]> getting i/o timeout when setting up bootstrap in vmware
<[Kid]> but it creates the VM and gets to the point of setting up machine config
<[Kid]> are there any devs in here?
<akshay__> Hi All, one of our charms uploaded on charms store is not getting listed  on the portal. We have uploaded total 6 charms and only 5 are getting listed. Having said that we can see the missing charm by exact url.
<akshay__> Is it a know issue with jujucharms.com?
<akshay__> List of the charms can be seen at: https://jujucharms.com/q/hyperscale
<magicaltrout> akshay__: did you grant access etc?
<akshay__> Yes it is for everyone
<kjackal_> akshay__: can you share the link with the missing charm?
<akshay__> Sure give me a minute please
<akshay__> Here it is:
<akshay__> https://jujucharms.com/u/vtas-hyperscale-ci/hyperscale-controller
<akshay__> It shows version as 14...but from that onwards we have only released the charm on "edge" channel and hence the latest version can also be seen as #27
<kjackal_> I am sorry akshay__ I do not see anything wrong with the charm. You might have more luck asking the gui team at #juju-gui or #juju-dev
<magicaltrout> i blame the greeks
<kjackal_> makes sence!
<kjackal_> is it snowing over there magicaltrout?
<akshay__> Thanks for the prompt responses @kjackal_ and @magicaltrout, I will follow this up on suggested channels. Cheers!
<magicaltrout> has been kjackal_ mostly gone now, pretty icy this morning though
<soumaya> Hi all ...
<soumaya> We are integrating a vepc in opnfv and facing some issue regarding bootstrap ..
<soumaya> We are bootstrapping on openstack using https identity service ...
<soumaya> endpoint is https://192.168.23.222:5000/v3
<soumaya> but bootstrap is failing with following error ....
<soumaya> 07:41:20 INFO  juju.provider.openstack provider.go:144 opening model "controller" 07:41:20 DEBUG juju.provider.openstack provider.go:798 authentication failed: authentication failed caused by: requesting token: failed executing the request https://192.168.23.222:5000/v3/auth/tokens caused by: Post https://192.168.23.222:5000/v3/auth/tokens: x509: cannot validate certificate for 192.168.23.222 because it doesn't contain any IP SANs ERRO
<soumaya> anyone can help me regarding the same ...
<zeestrat> soumaya: If you don't get any traction here, I suggest creating a bug over at https://bugs.launchpad.net/juju
<soumaya> Thanks zeestrat
<bdx> charm store borked for everyone?
<bdx> search for "elasticsearch" in the search
<bdx> or anything
<bdx> but "elasticsearch" is triggering the error for me
<bdx> I can't deploy charms from the charm store atm either
<bdx> :( :(
<bdx> http://paste.ubuntu.com/26170583/
<gsamfira> bdx: store seems broken ATM. 500 errors on any charm
<bdx> right, I'm seeing the same
<gsamfira> they are probably working on it :).
<bdx> heh
<bdx> well lets be safe
<bdx> rick_h: ^^^^^^
<bdx> :)
<gsamfira> (unrelated to the above): is there any ppa where I can still get juju 2.2.6 ?
<gsamfira> version 2.3.1 seems to have issues with LXD containers :)
<bdx> gsamfira: what are the issues with lxd you are experiencing ?
<gsamfira> bdx: https://bugs.launchpad.net/juju/+bug/1737640
<mup> Bug #1737640: /usr/sbin/fanctl: arithmetic expression: expecting primary | unconfigured interfaces cause ifup failures <cdo-qa> <cdo-qa-blocker> <cpe-onsite> <foundations-engine> <juju:Triaged> <ubuntu-fan (Ubuntu):Confirmed for smb> <https://launchpad.net/bugs/1737640>
<gsamfira> this one
<gsamfira> http://paste.ubuntu.com/26170673/ <-- status from one of the containers
* urulama changed the topic of #juju to: Juju as a Service Beta now available at https://jujucharms.com/jaas | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms | Production issues, charm store and some other services DOWN
<bdx> gsamfira: hell of a bug, wow
<gsamfira> yup :). Version 2.2.6 works fine for my needs, and I would rather use a PPA than compile my own
<gsamfira> unfortunately the stable PPA only has 2.3.1
<bdx> gsamfira: darn, thanks for the heads up on this ... similar but different to one I'm hitting https://bugs.launchpad.net/juju/+bug/1736022
<mup> Bug #1736022: failed to bridge devices: bridge activaction error: bridge activation failed: Killed old client process <juju> <juju:Incomplete> <MAAS:Incomplete> <https://launchpad.net/bugs/1736022>
<gsamfira> bdx: no worries. Just trying to work around this for the moment
<bdx> gsamfira: the bug you hit/shared^ will bork a good number of my deployments out there that are running if upgraded to 2.3, really good information ... don't know how I missed that
<gsamfira> make sure you don't upgrade until that is resolved :)
<bdx> right
<bdx> rahworkx:^^^^
<narinder> charm pull of charms does not work facing issues mentioning invalid character
<narinder> ERROR cannot get archive: cannot unmarshal error response "<html><body><h1>503 Service Unavailable</h1>\nNo server is available to handle this request.\n</body></html>\n": invalid character '<' looking for beginning of value
<skay> hmm, jujucharms.com is down, maybe there should be a 503 json response that charm can parse nicely
<bdx> http://paste.ubuntu.com/26170903/
<bdx> skay, narinder: ^
<bdx> fatal: unable to access 'https://git.launchpad.net/layer-snap/': The requested URL returned error: 503
<skay> bdx: git launchpad is also down
<bdx> yeah
<skay> arg /o\
<skay> squirrel... I ran into that earlier and for a while thought I was mistyping my git command. I found out about git -c core.sshCommand="ssh -vvv"
<skay> hopefully they are back up soon
<skay> derp didn't see the topic update
<bdx> the squirrels are real
<narinder>  bdx ok thanks
<bdx> I wonder if all this infra runs in the same opentstack/datacenter
<narinder> bdx, is IS team working on fixing this issue?
<bdx> narinder: looks like it
<bdx> we should think about diverting traffic to a backup controller/charmstore hosted somewhere else when the primary is unreachable
<narinder> bdx, thanks
<bdx> there are ways to avoid this
<bdx> narinder: np
<bdx> seeing as JAAS is about to try and support uptime contracts and become a paid for service, possibly extra precautions should be taken to avoid this type of outage in the future
<urulama> bdx: not just possibly, it's a must ... and sorry for outage, but the bad news is it looks like it'll take a while
<bdx> having the capability to do something like ^^ would negate this type of liability for you guys once this all goes live and we have customers bitching etc etc
<bdx> urulama: right, thanks
<bdx> urulama: I've implemented a simple version of ^ with a nagios check and script that updates dns, I'm sure you guys can think of something more better though :)
<urulama> bdx: dynamic dns balancing should in place and 2 regions, there's no question about it. it's not atm, and, well, it should be very soon for all the reasons you've mentioned
<urulama> charmstore should be up
<urulama> also JAAS models over CLI
<bdx> urulama: back in business! many thanks for the quickness there
<urulama> web pages still down :D
<bdx> urulama: possibly just have to kick those web boxes
<urulama> bdx: https://www.youtube.com/watch?v=N9wsjroVlu8
<bdx> :)
<urulama> web kicked
* urulama changed the topic of #juju to: Juju as a Service Beta now available at https://jujucharms.com/jaas | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms
<bdx> urulama: niceeeeeee
<jose-phillips> HI is possible from a juju charm set a few config on a container?
<jose-phillips> also perform changes on another deployed computers/containers like run apt-get for get packages/
<jose-phillips> ?
<bdx> jose-phillips: use the layer-basic to define packages that you want apt installed
<bdx> in your layer.yaml
<jose-phillips> ok and what about to change the settings IF the package is deployed inside of a container
<[Kid]> when i use Vsphere as a cloud provider, how can i specify which datastore the controller goes on when bootstrapping/
<[Kid]> getting i/o timeout when setting up bootstrap in vmware also
<[Kid]> getting i/o timeout when setting up bootstrap in vmware also
<[Kid]> woops
<[Kid]> the i/o timeout happens after it has already built the VM and copied it
<[Kid]> it is when it is doing the startup script for the agent
<[Kid]> http://paste.ubuntu.com/26172380/
<zeestrat> [Kid]: If you don't get any action here, I suggest sending a mail to the mailing list (https://lists.ubuntu.com/mailman/listinfo/juju) or create a bug over at https://bugs.launchpad.net/juju
#juju 2017-12-13
<magicaltrout> is it me
<magicaltrout> or is the jujucharm store borked?
<magicaltrout> oh no
<magicaltrout> its me :)
<bdx> gsamfira: I think my bug is your bug too
<bdx> aha
<bdx> I didn't realize it yesterday
<gsamfira> bdx: looks like it :D
<bdx> gsamfira: does the fix in proposed work for you?
<bdx> testing it now
<gsamfira> bdx: we went with 2.2.6 for now. If it helps you out, I can test it as well, but for the moment we're good to go
<ybaumy> i just wanted to say great job on the current vsphere support
<bdx> gsamfira: I just added the proposed repo, deploying a few nodes now
<ybaumy> if anyone wants to hear that .. kubernetes and juju has now a chance again in our company
<bdx> ybaumy: 2.3.1 got some vsphere love eh?
<ybaumy> bdx i love it so far. we are currently using openshift from redhat but i want to push ubuntu and juju
<bdx> ybaumy: awesome. srry I'm a bit behind on the vsphere provider .... what changed?
<ybaumy> bdx last time it was not working at all for me :D so that changed .. i was using maas as cloud provider with vsphere and then juju to deploy kubernetes... i dont need maas anymore
<bdx> ybaumy: sweet!
<ybaumy> bdx its so easy to scale and roll out a cluster
<ybaumy> bdx: you should try it
<bdx> ybaumy: I can't think of any reason to use the vmware provider
<bdx> but if I ever do have a use case for it
<bdx> I'll ping you and get the dl
<bdx> glad to hear its purring along for you though
<bdx> ybaumy: on second thought I may have some deploys that will require esxi in the next year
<bdx> totally spaced it
<bdx> so yeah, really good to know
<bdx> gsamfira: http://paste.ubuntu.com/26178059/
<bdx> :) :) :) :)
<gsamfira> bdx: outstanding! that was a quick fix :D
<gsamfira> hopefully there was a CI test added for this case :P
<rick_h> gsamfira: looks like it was something that changed in the fan package used. definitely some room to make sure that the new versions of the fan are tested out
<gnuoy> has JUJU_REMOTE_UNIT gone ?
<gnuoy> http://paste.ubuntu.com/26178222/ <- I'm seeing this in a debug hooks session
<gnuoy> JUJU_VERSION=2.3.1
 * gnuoy looks for release notes
<gnuoy> argh thedac just put me right, I'm not in a relation hook
<McL0v1n_> Greetings! When i deploy to a host and lxc (im deploying the openstack bundle) my containers dont start up. Ive waited for hours thinking it was the image download but the only way i can get them to start up is if i log into each host and run lxd init. Shouldnt juju be starting them up on its own?
<McL0v1n_> Anyone around?
<thedac> I am seeing something similar: http://pastebin.ubuntu.com/26178643/
<thedac> McL0v1n_: what version are you running?
<thedac> I have 2.4-beta1-artful-amd64 snap installed but the controller is on 2.3-rc2. I am going to try with a new controller
<McL0v1n_> Im using the stable from the repo, not the snap
<McL0v1n_> Im at a clients office 2 hours away from my cabinet, so i cant look at it and im using IRC on my phone
<thedac> McL0v1n_: no worries, I'll try this new controller and file a bug
<McL0v1n_> Essentially maas from apt repo, juju from apt repo, ubuntu 16.04 image from maas
<McL0v1n_> Thanks, this have been bothering me for months now and i cant find anything that relates to it
<hml> iâm able run a container with openstack using 2.3.2
<McL0v1n_> Im not doing anything different from a standard deploy: a bunch of bare metal servers and maas
<McL0v1n_> Using openstack-base bundle #50 and now #51
<McL0v1n_> I can check the actual versions when i get back to my office
<McL0v1n_> This has been happening from back when i tried to do it all based of the exact instructions for autopilot. Exact same issue. So it has to be a juju thing
<zeestrat> McL0v1n_: you mentioned bridge activation issues? Something like this? https://bugs.launchpad.net/maas/+bug/1736022
<mup> Bug #1736022: failed to bridge devices: bridge activaction error: bridge activation failed: Killed old client process <juju> <juju:Incomplete> <MAAS:Incomplete> <https://launchpad.net/bugs/1736022>
<McL0v1n_> Different issue, but i ONLY get that when i manually log into each host and run lxd init
<McL0v1n_> If i dont the container never starts up
#juju 2017-12-14
<McL0v1n> thedac: My juju version is 2.3.1-xenial-amd64
<McL0v1n> thedac, maas version is 2.3.0-6434-gd354690-0ubuntu1~16.04.1
<jac_cplane> is there anyway to completly wipe a juju controller/env?   I made the mistake of trying to upgrade juju version - which corrupted the env.   while trying to recover/remove/clean I just released the bootstrap node and uninstalled juju apt-get remove juju.    then tried to start from scratch - install juju,etc.   the problem is there are still remnants of the old system.   I just want to wipe and start from scratch.   juju
<jac_cplane> kill-controller, destroy-controller all fail.
<jac_cplane> found this on the web - will this still work ?  "sudo apt-get purge --auto-remove juju"
<McL0v1n> jac_cplane that doesnt work, i tried
<jac_cplane> yep
<jac_cplane> I just tried.   btw- i guess there is no way to update juju
<McL0v1n> ops, i found the error with lxc's, This is in the logs:
<McL0v1n> ERROR juju.worker runner.go:392 exited "0-container-watcher": worker "0-container-watcher" exited: setting up container dependencies on host machine: could not find unused subnet
<McL0v1n> thedac ^^
<pmatulis> jac_cplane, can you open a doc issue on the wipe stuff please? https://github.com/juju/docs/issues/new
<jac_cplane> McL0v1n - looks like i found the way.    juju unregister <controller-name>
<jac_cplane> then create a new one - same name overwrites the prev.  then you can bootstrap it
<McL0v1n> ahh, forgot about that
<McL0v1n> also juju kill-controller
<jac_cplane> juju kill-controller does not work in this case i mentioned.
<jac_cplane> I'll add to tghe docs
<McL0v1n> any idea about why my lxcs are not provisioning? The error i posted above is in the host machine's logs
<pmatulis> jac_cplane, see it, thanks
<McL0v1n> I think it might have to be with: https://bugs.launchpad.net/juju/+bug/1665648
<mup> Bug #1665648: Juju 2.0.3 fails to deploy LXD container lxdbr0 overlapping subnets <juju> <maas> <juju:Fix Released by hduran-8> <juju 2.1:Fix Released by jameinel> <https://launchpad.net/bugs/1665648>
<McL0v1n> mup we posted at the same time
<McL0v1n> i'm using a /8 10. subnet
<mattyw> hey folks, can you have key names like "foo-bar" in config.yaml or do you need to use underscore (foo_bar) ?
<jam> mattyw: we do stuff like:
<jam> storage-default-block-source:
<jam>   value: maas
<jam>   source: model
<jam> so foo-bar seems fine in yaml
<mattyw> jam, ok great thanks
<jam> mattyw: yamllint.com likes it fine, too
<mattyw> jam, I've seen lots of charms use _, even going so far as converting them back to - in the charm code
<mattyw> jam, so maybe it was a problem and not anymore?
<jam> mattyw: being ok in yaml != being ok in Mongo docs
<jam> though I think it is ok there, too.
<mattyw> jam, charm config docs?
<jam> as we certainly use {"model-uuid": blah}
<mattyw> ok great
<mattyw> I'll go with - for now thanks
<ybaumy> when i bootstrap a controller to eg vsphere/dc1 and want another one in vsphere/dc2. what do i have to do
<ybaumy> i mean a failover controller
<ybaumy> or do i have to add another controller and move it with vmotion
<hml> ybaumy: here is some documention on juju high availablity: https://jujucharms.com/docs/2.3/controllers-ha
<hml> ybaumy: the juju enable-ha help page has info on specifying already created machines to be controllers.  not sure if the vsphere dcs are part of constraints or not.
<hml> ybaumy: youâd spin up a vsphere instance where you wanted it - then use juju add-machine ssh:â¦. to let juju know about it
<hml> ybaumy: but the âto or âconstaints flags would be better if possible
<ybaumy> hml i did now a enable ha and moved one controller to dc2
<ybaumy> hml couldnt find anything that relates to creating it in dc2 in the first place
<ybaumy> it also would make sense to distribute kubernetes etcd and master VM's to diffrent DC's
<ybaumy> but appart from that and some dns problems im happy so far with it
<hml> ybaumy: typically juju distributes between zones,
<hml> ybaumy: looks like juju considers a vsphere dc as a region
<hml> ybaumy: not sure if a region works with a placement directive or not.
<ybaumy> hml so i have to create yaml to create masters in region dc1  and then dc2 ... with constraints?
<hml> ybaumy: you donât specify a region with a constraint: https://jujucharms.com/docs/2.3/reference-constraints#vsphere-provider:
<hml> rick_h: any ideas on how to do juju ha across regions (or vsphere dc)?
<rick_h> hml: hmm, can you add-machine into the region and try to enable-ha --to ?
<rick_h> hml: I think it'll be on your to make sure the controllers are reachable on a network level there
<hml> rick_h: that was my thought too, just wonderingâ¦
<rick_h> hml: yea, not tried it but I think that should work
<hml> ybaumy: ^^^
<hml> rick_h: regions donât work with placement directives correct?
<rick_h> hml: no, they're model level when you add-model and such
<rick_h> hml: as all of the model is in the same region, otherwise there could be issue
<rick_h> hml: region->region would need to be a CMR setup and controllers don't do that atm
<hml> rick_h: right
<ybaumy> rick_h: hml thanks for clearing that up. but from a HA perspective its suboptimal
<rick_h> ybaumy: I'm sure there's ways to do it differently but my experience with clouds has been regions are for fallback and cross region coms can be slower/more $$ then inner region.
<rick_h> having a controller in different regions raises all kinds of questions about the workloads in that region/etc.
<ybaumy> rick_h: from your perspective its ok to handle it this way. from mine it doesnt since datacenters are only few kilometers away
<ybaumy> rick_h: so HA is something im looking for
<rick_h> ybaumy: understand, it's an interesting perspective and if the networking/latency is good I can see that. It starts to feel like regions should be zones in that situation as far as spreading all units of workloads out across them as well.
<rick_h> I mean if the region goes boom than any workloads the controller is managing goes with it
<ybaumy> rick_h: well im talking on premise cloud though
<rick_h> ybaumy: right, do you have zones in each region?
<ybaumy> rick_h: thats a different approach
 * rick_h is curious how it's setup 
<ybaumy> currently we spread masters and workers and etcd 's accross two datacenters. pods are also setup in a way to handle workloads if one DC is out
<ybaumy> kubernetes is what we are interessted in with juju
<rick_h> ybaumy: which on prem cloud is this? /me reads back
<rick_h> oic, vsphere
<ybaumy> rick_h: our companies vsphere
<ybaumy> rick_h: we are using openshift atm from redhat but it costs .. though im looking into other directions
<rick_h> yea, I'm not familiar with vsphere as much. I know in maas/openstack the we think of zones as you're doing dc's in vsphere. It's why we're hitting this mismatch as we obviously really care/want to have HA whereever possible in Juju and the workloads running.
<ybaumy> rick_h: we would really like to see that
<ybaumy> rick_h: first i made test with maas and vsphere and juju and then on top kubernetes but maas lets is also not what i want. 2.3 is really neat
<ybaumy> juju 2.3
<ybaumy> i like that its talking directly now with API
<rick_h> ybaumy: I'm glad you're finding Juju interesting. I wish I had better news on the cross zone HA setup. Like I was saying, you can work around it by manually adding machines I think, but then once you go deploy things they'll only go into the original region which isn't what you're going to want
<ybaumy> rick_h: maybe in the future. tomorow our architects will get a presentation with juju setup from me. i hope they like it
<ybaumy> as much as i do
<rick_h> ybaumy: in the long run it'd be interesting with 2.3 and cross model relations if the charms in k8s could treat relations across the models as a way to do its HA work and so you'd just deploy two k8s and relate them and they'd combine into a super k8s
<rick_h> ybaumy: cool, let us know if we can be of any help
<ybaumy> rick_h: i will give a feedback
<rick_h> <3
<ybaumy> im the canonical guy though .. most ppl think of canonical as desktop client OS and services
<ybaumy> i hope i can change that
<rick_h> ybaumy: same here, we've put a lot of time and effort beyond the desktop :)
<ybaumy> rick_h: in germany i tell you its really hard to find ppl who use ubuntu and other serivces professionaly
<rick_h> ybaumy: ah you're in germany? Yea, that's a tough nut there. Wasn't/isn't germany still very suse friendly as they were from there?
<ybaumy> rick_h: we use suse for SAP of course cause there is no competition in this case. we use redhat and centos for everything else. but you are right SuSe is really popular
<ybaumy> i tried their container platform lol
<ybaumy> and ceph storage
<ybaumy> its full of bugs
<ybaumy> you just cant use it
<ybaumy> SLES enterprise server is really stable for SAP and HANA
<ybaumy> anyways i call it a day. beer is waiting. ttyl
#juju 2017-12-16
<nadeem_> Hi guys, can anyone refer me to the person who is currently managing juju charms program?
<bdx> did --bundle-override get nixed?
<bdx> http://paste.ubuntu.com/26196180/ - ?
<stokachu> bdx: --overlay
<bdx> stokachu: thanks
#juju 2019-12-09
<xavpaice> thumper, are you aware of the 'situation' we have at Cisco with the failed juju upgrade there?
<thumper> xavpaice: a saw an email from elmo
<thumper> and that there is a situation
<thumper> did you want to discuss?
<xavpaice> just realised in the wrong channel, but yes
<timClicks_> wallyworld: what do you think of moving example/poc charms from ~juju to an account like ~example-charms?
<timClicks_> cs:~juju/mariadb-k8s looks like it's a charm that's officially supported/endorsed
<timClicks_> because it's so closely linked to the official account
<wallyworld> timClicks_: i can see merit in that. once we move to the new charm store it will be a flat namsapce so it sort of becomes moot. given that's happening this cycle not sure it's worth the effort to move stuff right now?
<bayar> Hi Everyone
<bayar> Please someone help me with this error :
<bayar> ceph-osd/0*               blocked No block devices detected using current configuration
<bayar> When I ssh to the cephalopods-odd/0 server
<bayar> ubuntu@s3:~$ lsblk
<bayar> NAME              MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
<bayar> sda                 8:0    0 136.1G  0 disk
<bayar> ââsda1              8:1    0 136.1G  0 part
<bayar>   ââvgroot-lvroot 253:0    0 136.1G  0 lvm  /
<bayar> sr0                11:0    1  1024M  0 rom
<timClicks_> wallyworld: it won't be moot, because the charm's webpage is more important that its url slug
<timClicks_> it will still look like they're official charms published by juju
<timClicks_> bayar: what does the output of "juju config ceph-osd osd-devices" say?
<lucidone> timClicks_, wallyworld: for what it's worth, my impression as a new member to the community was that mariadb-k8s was an officially supported charm, not just a example / poc
<wallyworld> good to know, ty
<wallyworld> mostly, just in people's namespaces (eg ~juju) tends not to be "official" but there are excpetions so it's confusing
<wallyworld> *stuff in
<lucidone> Ahh, right cs:maria-k8s vs cs:~juju/maria-k8s
<lucidone> I see "By juju" and "Stable" and jump to conclusions
<lucidone> But thinking more on it; it's on jaas.ai/u/juju, and I got to the charm through google - not the charm store. So really, most of that confusion is probably on me
<anastasiamac> wallyworld: PTAL https://github.com/juju/juju/pull/10995
<anastasiamac> wallyworld: PTAL https://github.com/juju/juju/pull/10997 :)
<achilleasa> manadart: small PR for fixing network-health-check https://github.com/juju/juju/pull/11000
<manadart> achilleasa: Looking.
<nammn_de1> manadart: up for a small review? https://github.com/juju/utils/pull/305
<nammn_de1> reason: be able to use `generations and branches` as featureflags
<manadart> nammn_de1: There shouldn't be 2 flags for that. I think someone has made an incomplete change.
<manadart> nammn_de1: In any case, the patch looks OK, but let's get CI what it needs to run the checks and add a PR description.
<nammn_de1> manadart: Right now, as you have pointed out, we 2.7 and develop, are different initially I wanted to make both to be the same. Then I was talking to rick_h and he suggested that we want to use branches and generations as featureflags .
<nammn_de1> yea i will update them
<nammn_de1> manadart: ci cannot run the checks, as grumpig is missing a lot of deps (we using a lot of processcalls). Locally they run just fine
<nammn_de1> manadart: should i just go onto grumpig and install those?
<babbageclunk> quick and easy review for someone? https://github.com/juju/names/pull/100
<wallyworld> thumper: you ok to merge the 2.7 forward port? finished the review?
<hpidcock> babbageclunk: LGTM
#juju 2019-12-10
<pmatulis> how do i remove a resource from an application (opposite of 'attach-resource')?
<anastasiamac> pmatulis: there is no such thing
<anastasiamac> pmatulis: why do u need it?
<anastasiamac> pmatulis: generally, u'd use resource, u would not "un-need' it...
<babbageclunk> thanks hpidcock
<thumper> wallyworld: sorry, back on it now
<thumper> wallyworld: it is all good and merging
<thumper> wallyworld: merged
<timClicks_> has anyone got a recommendation for a local DNS server that I can "snap install <dns>"? I would like to add an "external hostname" to things using a .local tld that resolve to my microk8s cluster
<timClicks_> (without using xip.io. ideally everything would be locally hosted)
<pmatulis> anastasiamac, what if things change and it's no longer required?
<pmatulis> kind of like any of the other "undoing" commands
<anastasiamac> pmatulis: we have not encountered "resource is no longer required" case. also 'attach-resource' command does attach but also update... this satisfies  cases we have heard of...
<anastasiamac> pmatulis: if u have scenario where it is required, plz file a bug and we'll prioritize :)
<pmatulis> anastasiamac, i imagine a user can also just make a mistake right? like attach a resource to the wrong application?
<anastasiamac> pmatulis: u can only attach a resource if ur charm declares it..
<anastasiamac> pmatulis: and u can always update
<pmatulis> well, i do have a use case for wanting to remove resources. i will open a bug later. thanks for the context anastasiamac
<anastasiamac> nws
<lucidone> Is it possible to change a controllers metadata-source after bootstrapping? The docs suggest not. Is it the case that bootstrapping with `--metadata-source ~/simplestreams/images` means that I'm locked into that set of images unless I destroy and recreate the controller? What are my options here with only user permissions in an openstack deployment?
<hpidcock> pr please https://github.com/juju/bundlechanges/pull/59
<nammn_de1> morning  manadart, stickupkid and i were talking about possible implementations of multiple featureflags:  https://github.com/juju/utils/pull/305 do you have a preference? Thankso
<stickupkid> nammn_de1, mine is number 2, let's see what manadart thinks
<nammn_de1> stickupkid manadart: another small one, unrelated to above. https://github.com/juju/cmd/pull/70 some feedback for it?
<manadart> stickupkid nammn_de1: I missed why we have 2 flags for the same feature...
<stickupkid> manadart, rick wants users to be able to target them both in 2.7
<stickupkid> manadart, i.e. generations and branches are the same thing
<nammn_de1> manadart: he said he would like to ease user experience from someone going from 2.7 to 2.8
<nammn_de1> e.g
<manadart> stickupkid nammn_de1: I am probably with stickupkid on the alias thing. Mostly because:
<manadart> 1) Checking whether to make some logic nascent based on these *multiple* flags is a poor question to pose. A feature:flag should be 1:1.
<manadart> 2) It is ambiguous anyway. Is it "or" or is it "and" for example.
<stickupkid> I'd love it if the feature flags was a type, then just make global functions
<stickupkid> https://paste.ubuntu.com/p/S8NpRRRtTp/
<zeestrat> Anyone have a rough ETA on next libjuju release? Is this side of new years realistic?
<stickupkid> zeestrat, hopefully, we're just wrapping up on the last PR
<stickupkid> manadart, forward port of 2.7 into develop https://github.com/juju/juju/pull/11007
<zeestrat> stickupkid: thanks, looking forward to it! it will make my ci lights finally go green.
<manadart> stickupkid: Back. Looking at your patch.
<stickupkid> nice
<nammn_de1> stickupkid: coming back to yaml/json output: https://github.com/juju/cmd/pull/69
<nammn_de1> added some tests and make it to return {}
<stickupkid> nammn_de1, gave some feedback, we need to work out what happens with an invalid format input error...
<nammn_de1> stickupkid:  afaict that is not possible as we register the command beforehand and this   happens to me:  juju models --format=yafdsfs
<nammn_de1> ERROR invalid value "yafdsfs" for option --format: unknown format "yafdsfs". But we still can look more into error handling just to be safe
<stickupkid> nammn_de1, let's replicate that error handling.
<stickupkid> nammn_de1, I'd like to write a guide of how to deal with errors, so others can follow
<nammn_de1> stickupkid: ho?
<stickupkid> sure
<nammn_de1> stickupkid: ahh ho for 2 min?
<stickupkid> sure
<nammn_de1> stickupkid : thanks for the feedback. Added it https://github.com/juju/cmd/pull/69
<stickupkid> nammn_de1, approved
<stickupkid> gr8 don't have green tick, sigh - nammn_de1 might be worth speaking to rick_h or jam about my lack of green tick POWER in juju/cmd
<jam> stickupkid: green tick POWER! :)
<jam> stickupkid: I added hackers to Write on juju/cmd
<jam> stickupkid: does that give you the GTP ?
<manadart> stickupkid: Patch for emitting redirects: https://github.com/juju/juju/pull/10989
<stickupkid> jam, yaep
<stickupkid> *yeap
<stickupkid> manadart, sorry it took so long, was busy in other stuff
<stickupkid> manadart, approved
<manadart> stickupkid: Giddyup. Ta.
<stickupkid> manadart, https://github.com/juju/juju/pull/10989#discussion_r356125073 this would be good at some point
<stickupkid> help with traceability etc
<manadart> stickupkid: Yep. Saw it. Let's talk tomorrow. About to finish up for today.
<stickupkid> manadart, peeeeeeeeeeeeeeeeerfect
<stickupkid> nammn_de1, CR'd
<nammn_de1> stickupkid: thanks! Lol, looks like I overlooked that some commands fail on init as well. Should I add them as well?
<stickupkid> erm, probably, propose a fix, let's see
<nammn_de1> stickupkid: ohhh man haha
<nammn_de1> :D
<nammn_de1> stickupkid: damn on cmd/main it is harder as we do not have access to supercommand, looks like i need to parse it myself
<nammn_de1> stickupkid: no access to commonflags, but then we are back to the discussion whether we want to add a ParseFlag(name, flags) function
<stickupkid> nammn_de1, let's look tomorrow, brain is fried today
<nammn_de1> stickupkid: haha no worries, i will open a pr tomrrow and we can talk about then
<lucidone> Is it possible to have relations between charms in different clouds? Use case is postgres in openstack related to an app in k8s
<rick_h> lucidone:  definitely, they're called cross model relations
<rick_h> https://jaas.ai/docs/cross-model-relations
<lucidone> Magic thanks, these are the docs I was looking for :)
<rick_h> lucidone:  and for the video inclined https://www.youtube.com/watch?v=NUx6kYE60Mc
<lucidone> Neat! Cheers
<hpidcock> wallyworld: https://github.com/juju/bundlechanges/pull/59
#juju 2019-12-11
<babbageclunk> Fun test fix: https://github.com/juju/juju/pull/11014
<lucidone> It doesn't look like the juju gui supports SAAS, and the UI crashes if you try to show relations on an application that is related to a SAAS application .. Is https://bugs.launchpad.net/juju-gui the place to report a bug?
<babbageclunk> lucidone: yes, that would be the right place to start (although it might turn out to be a juju bug under the hood)
<lucidone> babbageclunk: Cheers, this bug in particular is a js error "TypeError: Cannot read property 'serviceName' of undefined", so I imagine it's in the gui code. Supporting SAAS in juju gui itself feels more like a feature request
<babbageclunk> lucidone: yeah, that makes sense
<wallyworld> babbageclunk: state pr lgtm with a small fix to error processing
<babbageclunk> wallyworld: cool, thanks
<lucidone> Looked like there was more activity on github issues (and I was blocked by ubuntuone login not working on launchpad..) so I've posted to github https://github.com/juju/juju-gui/issues/4023
<babbageclunk> lucidone: oops, sorry for the bum steer there
<lucidone> babbageclunk: No worries! I did see a 2019 bug report there, so didn't appear to be totally defunct
<timClicks> is it possible to serve resources locally, or is the charm store required?
<lucidone> As in $ juju deploy /path/to/charm ?
<timClicks> lucidone: I am developing a charm that needs a resource
<timClicks> but I don't want to run "charm attach" yet to upload it to the charm store (it's not ready)
<lucidone> Ah right
 * lucidone reads the docs for resources
<timClicks> it looks like I can use `juju attach-resource`
<ec0> thumper: if you're around in about 30 minutes I should be free to catch up on that Cisco upgrade
<ec0> disregard
<babbageclunk> timClicks: I'm late to the party but I think you can use deploy with --resource to attach the resource at deploy-time as well (rather than doing it after the fact)
<timClicks> babbageclunk: yeah you can :)
<babbageclunk> phew
<pal> Good Morning Juju!
<nammn_de1> ptal, small one: https://github.com/juju/juju/pull/11011
<nammn_de1> *ptal, please? :D
<nammn_de1> stickupkid: morning, thats what i meant yesterday with forcing in init. Sadly we cannot use supercommand fields, thus no commonflags. https://github.com/juju/cmd/pull/71
<nammn_de1> stickupkid: wanted to discuss that before adding more tests ect.
<stickupkid> manadart, ping
<manadart> stickupkid: Pong.
<stickupkid> ho?
<manadart> OMW. 2 secs.
<nammn_de1> stickupkid: hows that comment? https://pastebin.canonical.com/p/xq2ShFXnvY/
<stickupkid> nammn_de1, ok, that'll do
<nammn_de1> stickupkid: great, updated pr
<nammn_de1> stickupkid manadart rick_h: just realized as i was going through the branches test why they fail on 2.7. Do we want to backport this? https://github.com/juju/juju/pull/10796/
<nammn_de1> nvm me, seems like they are..
<nammn_de1> stickupkid: for the pr https://github.com/juju/juju/pull/11011 i updated the comments+naming as you said, additionally i added the fix to make sure that there is no race condition for the acceptancetest test-branches
<manadart> nammn_de1: Yes, back-port it.
<nammn_de1> manadart: apologies, i just realised this already has been the case. Lucky me
<nammn_de1> while at it, manadart stickupkid: ptal https://github.com/juju/juju/pull/11011 ?
<nammn_de1> stickupkid: if you have time later we can talk/look at the init change here https://github.com/juju/cmd/pull/71 . Ping me up if you up for it
<nammn_de1> how do i enable all featureflags?
<nammn_de1> is it exporting `export JUJU_DEV_FEATURE_FLAGS="" `?
<nammn_de1> manadart: changed it, you will hate me, but i rebased as this change was more trivial, hope you don't mind:  https://github.com/juju/juju/pull/11011/files
<stickupkid> manadart, CR on this one please :D https://github.com/juju/description/pull/69
<stickupkid> ta
<nammn_de1> stickupkid: ping me if you are around for my python questions and/or the init cmd thingy
<stickupkid> nammn_de1, do it now?
<nammn_de1> stickupkid sure, daily?
<stickupkid> yeap
<manadart> stickupkid: https://github.com/juju/juju/pull/11020. I am heading to HO.
<nammn_de1> stickupkid: what was the output of doing it in init again? How do we want to proceed? https://github.com/juju/cmd/pull/71
<nammn_de1> rick_h: im a bit struggling to be able to connect to the allwatchersapi through python, any pointers for me?  `WatchAllModels` returns an id of  an allwatcher which iam supposed to use with something
<nammn_de1> just cant find something easiliy
<rick_h> nammn_de1:  sec, otp for a bit can help look afterwards
<nammn_de1> rick_h: thanks! stickupkid: is there a way to set a context for a facade connection?
<nammn_de1> as it seems the watcher_id is taken from a context param, which i cannot give for the watcher.next() call
<stickupkid> nammn_de1, have a look at what the go code, see how it uses it, that's generally what I'd do...
<nammn_de1> cr someone? https://github.com/juju/juju/pull/11021
<nammn_de1> stickupkid: they only api things  we can call through python have to be behind facades, right?
<stickupkid> yes
<nammn_de1> so this call https://github.com/juju/juju/blob/6ea20273f7c540d93b1075d77aafe39e70770b33/api/controller/controller.go#L186, which is returning the real watcher, is not directly possible and we might have a facade equivalent construct somewhere?
<stickupkid> nammn_de1, not at all, each go client knows about it's facade it's going to use. It just abstracts that information away, the python code has no such idea.
<nammn_de1> stickupkid: thanks and dammnit
<stickupkid> nammn_de1, see https://github.com/juju/juju/blob/6ea20273f7c540d93b1075d77aafe39e70770b33/api/controller/controller.go#L36
<nammn_de1> stickupkid: doesnt this suck in this case? Would need to add a new facade for this to work in python, right?
<nammn_de1> ah
<stickupkid> nammn_de1, nope, we export all facades for python to consume
<nammn_de1> stickupkid: i need to understand how the attributes are set in python
<stickupkid> nammn_de1, there is a set of facades we don't export https://github.com/juju/python-libjuju/blob/master/juju/client/facade.py#L21
<stickupkid> nammn_de1, maybe it's that one
<nammn_de1> stickupkid: this quick hack did it for me: https://pastebin.canonical.com/p/sBskSH7QdQ/
<stickupkid> nammn_de1, just remove "ClientFacade" from this https://github.com/juju/python-libjuju/blob/master/juju/client/facade.py#L21 and then follow this guide https://discourse.jujucharms.com/t/python-libjuju/1553
<nammn_de1> stickupkid: I will keep that in mind,ta
<timClicks> babbageclunk: ping, question in discourse for your perhaps? https://discourse.jujucharms.com/t/application-level-data-questions/2447
<babbageclunk> timClicks: thanks! I'll have a look in a bit
#juju 2019-12-12
<lucidone> On a k8s cloud (openstack magnum), am I responsible for deploying an ingress controller? (and cert-manager etc) are there charms for doing that?
<lucidone> `juju expose $app` isn't doing much without a controller - which makes sense
<nammn_de1> stickupkid: around to talk about the cmd init thing?
<stickupkid> nammn_de1, sure
<nammn_de1> stickupkid: need to get my coffee, meet in 5 min?
<stickupkid> sure
<nammn_de1> anyone ptal please? https://github.com/juju/juju/pull/11022 2.7 into develop
<stickupkid> manadart, that took some doing, external controllers can now be imported :)
<manadart> stickupkid: Sweet.
<stickupkid> manadart, i'm just cleaning up the github PR page, but it's read for review
<stickupkid> https://github.com/juju/juju/pull/11008
<stickupkid> manadart, I've added some qa steps etc
<nammn_de1> stickupkid: in jenkins, the parameters which are set, are those set as env?
<stickupkid> nammn_de1, depends
<nammn_de1> stickupkid: easy way to find out?
<stickupkid> nammn_de1, most if not all are set directly via parameter builds and others can be buildvars
<stickupkid> nammn_de1, yeah look at the job
<stickupkid> *job config
<nammn_de1> ah lol, I was looking at it. Thanks, I just realized why I got confused. We had some which used a `region` but never used it in the config
<nammn_de1> and then I had the thought, well someone might had something in mind doing it. Probably a env :D
<stickupkid> nammn_de1, most if not all should be parameters
<nammn_de1> stickupkid: got it
<nammn_de1> stickupkid manadart hml: the region addition thing: https://github.com/CanonicalLtd/juju-qa-jenkins/pull/348
<nammn_de1> while at it: https://github.com/juju/juju/pull/11022 just checked,  thumper https://github.com/juju/juju/pull/11019 merge does not include the other PR merges
<nammn_de1> thumper ff is around 20 hours old, while the pr i include are newer as it seems
<nammn_de1> reason is mostly only my test-branches change
<stickupkid> ah, feels good - 100% coverage https://pastebin.canonical.com/p/SbXGPvGZyC/
<nammn_de1> rick_h: https://github.com/juju/juju/pull/11024
<nammn_de1> works as described
<nammn_de1> now
<nammn_de1> stickupkid: https://github.com/juju/juju/blob/develop/cmd/juju/firewall/setrule.go#L33-L35 as wallyworld said before, we only support ssh right now. The others can be set but don't have an effect yet. How do we want to handle that? Removing them? Adding a pointer that they are not implemented yet, but eventually will be ?
<nammn_de1> rick_h^
<stickupkid> manadart, considering this folder is 100% independant from state, I wonder if we should move it to core https://github.com/juju/juju/tree/develop/state/migrations
<manadart> stickupkid: Maybe into the migration package at the root, as that stuff isn't used ubiquitously.
<stickupkid> manadart, legit
<rick_h> nammn_de1:  looking
<nammn_de1> rick_h: yes, it does exactly that :D
<stickupkid> manadart, you around?
<rick_h> nammn_de1:  ok
<stickupkid> rick_h, quick ho, I have a question around firewall rules...
<stickupkid> ?
<rick_h> stickupkid:  omw
<stickupkid> rick_h, solved it, I've made some clean up to simplify :D
<rick_h> woot
<timClicks> A good thread is emerging on discourse around the use of public charms: https://discourse.jujucharms.com/t/-/2446
<rick_h> yea, definitely points out we need to be ahead of the game a little bit with the snap store changes to namespaces and such
<rick_h> take some getting used to
<nammn_de1> rick_h: thanks!
#juju 2019-12-13
<thumper> wallyworld: https://github.com/juju/juju/pull/11027
<thumper> phew
<thumper> almost gave myself a heart attack there
<thumper> forgot that I had manually stopped the controller on two nodes
<thumper> and was then wondering why they didn't upgrade
<hpidcock> https://github.com/juju/juju/pull/11028
<thumper> hpidcock: trade ya
<hpidcock> done
<thumper> hpidcock: there was a pending forward port from nammn_de1
<hpidcock> Yeah it had outstanding conflicts
<thumper> hpidcock: does this bring forward the same one?
<thumper> ah
<thumper> ok
<hpidcock> I think anastasiamac looked at https://github.com/juju/juju/pull/11027 for you
<thumper> oh cool
<thumper> thanks anastasiamac
<hpidcock> So I guess I owe anastasiamac a PR now
<anastasiamac> hpidcock: from u, i'll take it with interest... 2 prs :D
<zeestrat> Morning! I have 2 charmhelpers PRs ready for review: https://github.com/juju/charm-helpers/pull/403 and https://github.com/juju/charm-helpers/pull/404
<nammn_de1> hpidcock thumper yup,  while i was away some things got merged and ola, new conflicts ;/
<nammn_de1> stickupkid: morning. ptal? https://github.com/CanonicalLtd/juju-qa-jenkins/pull/348
<stickupkid> nammn_de1, lovely jubbly
<stickupkid> manadart, ping
<manadart> stickupkid: Pong.
<stickupkid> manadart, quick ho, about my latest PR
<nammn_de1> rick_h: can you oing me if you are around? got 2 things
<stickupkid> nammn_de1, he's not online for another 3 hours
<nammn_de1> stickupkid: i know just heads up, maybe to early to be doing a headsup
<nammn_de1> stickupkid: see you are rewriting the firewallrules, how did you come across this?
<stickupkid> nammn_de1, I refactored it as we don't use the firewall service directly, instead we use the firewallDoc inside a txn.Op
<nammn_de1> stickupkid: roger
<stickupkid> CR anyone: I've had this locally for a few weeks, others might find it useful https://github.com/juju/juju/pull/11029
<nammn_de1> stickupkid: done
<manadart> stickupkid: This is the change I talked about in the HO. I have separated it from the big patch. https://github.com/juju/juju/pull/11030
<stickupkid> manadart, cool, let me check
<hml> achilleasa: review please https://github.com/juju/juju/pull/11031
<achilleasa> hml: will do after standup if that's OK?
<hml> achilleasa:  np
<rick_h> nammn_de1:  sure thing, hop into daily early or do post-daily?
<nammn_de1> rick_h stickupkid: just lookiung through that I realized, we already do have a local controller cache. I suspect we could just remove the caching there.
<nammn_de1> What do you think?
<nammn_de1> https://github.com/juju/juju/blob/ea5a7c89c9e0d4cacfc1f1da452a118877f34da8/etc/bash_completion.d/juju#L378
<nammn_de1> The only advantage I can see is, if juju process itself hangs and we want to access the controllers
<rick_h> nammn_de1:  if which process is hanging?
<nammn_de1> rick_h: apologies, maybe this pr makes it more clear what I meant https://github.com/juju/juju/pull/11032
<rick_h> nammn_de1:  looking
<nammn_de1> rick_h: the bash completion is far from perfect, but this change should make it a little easier to use/less prone to show some errors because of the cache
<nammn_de1> stickupkid: https://github.com/juju/juju/pull/11033 removing the not needed texts from set firewallrule
<nammn_de1> rick_h: so testing for me was fine the whole day. But happy to get others testing. If we want to take a more conserative approach i would suggest just to change the error message to be empty  or do a simple retry: https://github.com/juju/juju/blob/develop/etc/bash_completion.d/juju#L273 because
<rick_h> nammn_de1:  yea, just my own reservations as it's not something I play with much and has such an impact on filks
<nammn_de1> rick_h: more conserative approach would be that one: https://pastebin.canonical.com/p/sMWVC4S2gC/
<nammn_de1> it fails because it could not access the created cache in time and fill it. Kind of racy
<nammn_de1> condition
<rick_h> nammn_de1:  yea, that was my original thought was that if you hit a cache miss you prime the cache kind of thing but understand where you're going.
<nammn_de1> rick_h: was my initial thought as well, just thought that we already had one and thus could just remove it
<nammn_de1> but iam happy to propose this patch
<rick_h> nammn_de1:  my main concern is that IS has complained to thumper about juju tab completion taking time and I was worried about calling out to Juju for any completion. It's just the one controller call but I'm curious on delay/timing feelings for end users
<rick_h> nammn_de1:  that's why I'm just curious for other folks to try with different data in their controllers output to sanity check making a change that wfm but might have issues/delays for others with more data/etc
<nammn_de1> rick_h: makes sense to me, We can let the pr open and see how other folks prime in
<rick_h> nammn_de1:  kind of thing that tests well/fine with one or two controllers but might have unforseen issues with other folks
<rick_h> nammn_de1:  yea I think we could land it with a request to test given it'll only show in the edge snap
<rick_h> nammn_de1:  and recruit some feedback
<rick_h> nammn_de1:  I don't think it'll get much feedback otherwise since folks will need to adapt their local completion scripts
<nammn_de1> and if its too slow then maybe just remove/rewrite the "error message" could already help
#juju 2019-12-15
<timClicks> wallyworld: it looks like caas charms allowed you to specify an upstream image directly, rather than using a resource (https://github.com/wallyworld/caas/commit/713d0bd495a55b1b0fb40c5aa6421567e65b896d#diff-607c7737965c80fdf2ddb361f1fc823b). is that still supported?
<wallyworld> timClicks: resources is preferred, the other is deprecated
<wallyworld> no one uses it afaik
<kelvinliu> hi wallyworld: I don't think the review tool change has been released, i got the same error `confinement 'classic' not allowed with plugs/slots lint-snap-v2_confinement_classic_with_interfaces`
<wallyworld> kelvinliu: ah, damn, ok, let me check
<wallyworld> kelvinliu: the person i need to talk to is in US, so i can check again tomorrow. can you send me the snap you are trying to upload
<kelvinliu> wallyworld: same snap can not be pushed twice.
<kelvinliu> the revision tool expects each push should have different sha
<wallyworld> ok, i'll follow up tomorrow
<wallyworld> thanks for looking
<kelvinliu> thanks,
