#juju 2012-04-02
<shazzner> anyone here skilled with curl on the commandline?
<shazzner> ok figured it out :)
<_mup_> juju/states-with-principals r332 committed by kapil.thangavelu@canonical.com
<_mup_> replace security facade with usage of concrete classes
<_mup_> juju/states-with-principals r333 committed by kapil.thangavelu@canonical.com
<_mup_> remove extant refs to old node security adapter
<shazzner> anyone online? :)
<shazzner> have a quick question
<_mup_> Bug #971400 was filed: Juju should open up required ports on LXC deployments <juju:New> < https://launchpad.net/bugs/971400 >
<melmoth> Hola. i m reading the juju tutorial, and playing with it (with lxc vms locally). I m wondering, once i have deployed and exposed wordpress.. Wich url exactl shall i use to acces it ?
<melmoth> turial used is https://juju.ubuntu.com/docs/user-tutorial.html , i m using precise instead of oneiric though.
<melmoth> i can ssh into the wordpress machine, but i do not see where does it change the apache configuration to tell apache to change its htdocs to /somewhere/where/wordpress/is
<koolhead17> melmoth: pastebin juju status
<melmoth> koolhead17: http://pastebin.com/LUHLnZvB
<melmoth> i m also wondering why mysql "agent-state" set to pending btw.
<koolhead17> melmoth: it takes sometime i suppose
<koolhead17> melmoth: 192.168.122.129 this will give you the wordpress
<melmoth> the package installed in 192.168.122.129  only put stuff in /usr/share/wordpress/
<melmoth> not a single change in apacge
<melmoth> so apache is not actually serving those page
<melmoth> that s the part i dont get
<koolhead17> melmoth: juju charm takes care of everything for you :)
<melmoth> but what url to use ? If i use http://129.168.122.129, i end up wiht the apache defautl page
<koolhead17> melmoth: because all the charms are not initializew
<koolhead17> d
<melmoth> does it mean i have to wait (it been this way for sometimes) or that the wordpress charm is not finished ?
<melmoth> (like the install hook is only "apt-get install wordpress")
<koolhead17> melmoth: there is other hooks as well in charm apart from install hook i suppose.
<melmoth> ah, yep, a db-relation-changed one seems to make a syminks in /var/www
<melmoth> funny thing is, i do not even have a /var/www directory...
<koolhead17> melmoth: :P
<melmoth> ah, yes, i have one.. i was not looing in the right box
<koolhead17> melmoth: if you think its really too much time
<koolhead17> try juju destroy-environment
<koolhead17> and do a juju-bootstrap once again
<koolhead17> followed by deploying chars again
<melmoth> I m also a bit worried about the .mrconfig warning i have when deploying  aservice http://pastebin.com/7Rt3b0CY
<melmoth> is it something i should worry about or can safely ignore ?
<koolhead17> SpamapS: jcastro anyone around?
<koolhead17> melmoth: i remember someone asking same question sometime back
<koolhead17> melmoth:  what does juju status says now
<melmoth> looks better:
<melmoth> http://pastebin.com/3xcq9yEw
<melmoth> but still, the symlinks in /var/www has not been set
<melmoth> it s like the mysql-changed-thingy hook was not called
<koolhead17> i think you need to expose the service as well
<melmoth> ah did not do it this time. true.
<_mup_> juju/security-policy-with-topology r329 committed by kapil.thangavelu@canonical.com
<_mup_> merge states-with-principals
<koolhead17> melmoth: is it working finally
<melmoth> nope, still  no /var/www/wordpress something
<melmoth> i have a conf call now...Will try to figure out what s happening later....
<koolhead17> melmoth: dpkg -l juju
<koolhead17> k
<melmoth> 0.5+bzr504-1juju4~precise1
 * koolhead17 wonders why ask a question link https://answers.launchpad.net/ubuntu/+source/juju/+addquestion  lineked on juju project page
<melmoth> hmmm. I think i ll retry on oneiric just to see if i have the same 1) behaviour and 2) funny .mrconfig waring messages
<koolhead17> melmoth: https://answers.launchpad.net/ubuntu/+source/juju/+addquestion  <-- how about trying this
<koolhead17> because i think someone else had same issue
<melmoth> hmm, i havet browse the existing questions good idea.
<melmoth> there does not seem to be any question... I ll probably post one if i have the same behaviour on oneirirc then.
<_mup_> juju/states-with-principals r334 committed by kapil.thangavelu@canonical.com
<_mup_> security api cleanup
<jamespage> melmoth, koolhead17: the .mrconfig warning is not harmful (its just a file used when you use charm tools to grab all charms)
<jamespage> not sure why juju is trying to parse it...
<melmoth> good to know :)
<koolhead17> jamespage: and it gives a warning msg too
<jamespage> yeah - I think its worth a bug report
<koolhead17> melmoth: remove that file/directory and try a bootstrap again :)
<koolhead17> melmoth: and as jamespage suggested a bug report :D
<jamespage> melmoth, I'd def test the wordpress charm using an oneiric environment - it might work on precise but most charms currently target oneiric unless explicitly stated
<jamespage> http://charms.kapilt.com/charms/oneiric
<jamespage> http://charms.kapilt.com/charms/precise
<melmoth> on my way to try on oneirirc then.
<_mup_> juju/security-agents-with-identity r319 committed by kapil.thangavelu@canonical.com
<_mup_> merge parent
<andrewsmedina> hi
<andrewsmedina> Has anyone here ever used juju to OpenStack + keystone?
<jcastro> SpamapS: marcoceppi: m_3: hey we should chat about the contest today, it'd be nice to close it out by Wednesday
<marcoceppi> jcastro: sounds good
<melmoth> hmmm, on oneiric, mysql service still in pending state after like 30mn.
<marcoceppi> melmoth: what size instance/service?
<marcoceppi> provider*
<melmoth> m1.large in lxc container
<marcoceppi> not sure then, I know aws and t1.micros don't work well with MySQL
<melmoth> what i feel frustrating is, there s not that much occuring on the juju-debug console
<melmoth> i wonder what to do to "see" what could be happening (or not...)
<jcastro> melmoth: that happened to me this weekend
 * jcastro didn't investigate yet though
<melmoth> did you fix it, did it fix itself automatically ?
<melmoth> or did you just give up ? :)
<jcastro> I gave up and was going to follow up
<jcastro> though I thought it was just me
<koolhead17> melmoth: file a bug
<melmoth> i m trying again after a destroy-environment, and a new boostrap. will give it like .... 20mn, and file a bug if it  s still pending
<shazzner> if anyone wants to test it out, I finished (mostly) the charm for kusabax which is a 2-channel like imageboard: https://code.launchpad.net/~shazzner/charms/precise/kusabax/trunk
<melmoth> koolhead17: i m wondering if it could be https://bugs.launchpad.net/juju/+bug/907655
<_mup_> Bug #907655: hangs when lxc fails to start <local> <lxc> <juju:Confirmed> < https://launchpad.net/bugs/907655 >
<koolhead17> melmoth: k
<melmoth> however, i do not have any "ERROR lxc_start - failed to spawn " in /var/log/syslog
<melmoth> probably something else, i know nothing about lxc, but it looks like i can have acess to the mysql box console, so it s up
<_mup_> Bug #971664 was filed: deploying mysql service hang in "pending" state with lxc <juju:New> < https://launchpad.net/bugs/971664 >
<melmoth> well, #971664  is it then :)
<_mup_> Bug #971664: deploying mysql service hang in "pending" state with lxc <juju:New> < https://launchpad.net/bugs/971664 >
<jamespage> melmoth, are you running on precise?
<jamespage> melmoth, I think you might be getting some sort of distro skew
<jamespage> as you are using juju-origin: distro
<jamespage> juju in oneiric is way old
<andrewsmedina> I'm with a problem using juju with openstack and keytone, can someone helpme?
<jamespage> could you try it with juju-origin: ppa please?
<jamespage> melmoth, ^^
<jamespage> andrewsmedina, I can try - what are you having trouble with?
<koolhead17> melmoth: let me pastebin you my config.yaml
<koolhead17> i am using oneiric
<andrewsmedina> jamespage: I'm with a problem in juju bootstrap
<koolhead17> melmoth: http://pastebin.com/AsnUajqQ
<koolhead17> i am using juju on oneiric and that is how my enviornment.yaml look slike
<andrewsmedina> jamespage: juju use group info to get group owner id
<andrewsmedina> jamespage: but with keystone, openstack returns project id instead project name
<jamespage> andrewsmedina, OK - so you are trying to use juju against openstack?
<andrewsmedina> jamespage: yes
<jamespage> great - so ATM openstack integration is through the ec2 provider
<andrewsmedina> jamespage: The problem occurs when I use the keystone OpenStack
<jamespage> so it does not really know about keystone
<melmoth> jamespage: i had the problem on oneiric
<andrewsmedina> jamespage: ATM?
<jamespage> andrewsmedina: At The Moment
<andrewsmedina> jamespage: without keystone works fine
<melmoth> and yep i was using juju-origin distro, will try with origin:ppa in a couple of minutes
<jamespage> melmoth, I think that will fix it up - bear in mind that the version in the distro in oneiric is quite along way behind the version inthe PPA interms of features
<melmoth> i did not pay attention to my origin setting.
<melmoth> i just installed juju from a ppa and some charm from bzr
<melmoth> and used the environment.yaml that once worked.
<andrewsmedina> jamespage: The problem occurs in this line http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/providers/ec2/launch.py#L98
<melmoth> ok, deployement in progress.Let s wait a bit
<jamespage> andrewsmedina, ah - I see - so instead of the project_name you get an id back - which then does not work
<andrewsmedina> jamespage: yes, but the keystone way is returns the id instead name
<avoine> andrewsmedina: can you show me your .juju/environments.yaml file (without the passwords) and tell me what is the version of openstack your using?
<andrewsmedina> avoine: I'm using diablo
<avoine> ok
<avoine> andrewsmedina: and your using what as ec2-uri ?
<andrewsmedina> avoine: http://dpaste.org/NhKzW/
<avoine> andrewsmedina: your configured the right way
<avoine> andrewsmedina: I guess it's a bug in the keystone package
<jamespage> andrewsmedina, I suspect that this is a bug in openstack - keystone landed as a core package very late
<jamespage> and the ec2 API is not the most loved thing upstream
<jamespage> avoine, great minds think alike :-)
<avoine> hehe
<avoine> andrewsmedina: I'm using the last essex release and it works fine
<avoine> if you can, I suggest you to upgrade
<andrewsmedina> avoine: upgrade openstack?
<andrewsmedina> avoine: what openstack version you use?
<avoine> andrewsmedina: yes
<andrewsmedina> avoine: diablo is a stable one
<melmoth> agent-state: started \o/ Thanks jamespage and koolhead17
<avoine> andrewsmedina: I'm using essex release candidate but if you wait 3 days it's gona be stable
<avoine> andrewsmedina: http://wiki.openstack.org/EssexReleaseSchedule
<andrewsmedina> avoine: I will upgrade to essex version here
<avoine> andrewsmedina: yeah diablo is stable but keystone have a lot of improvement in the essex release
<avoine> andrewsmedina: if you need help with that, you can ping me
<jamespage> melmoth, \o/
<andrewsmedina> avoine: can you show your euca-describe-instances outuput?
<avoine> andrewsmedina: http://paste.openstack.org/show/12356/
<shazzner> are there any charms at the moment that depend on tomcat7?
<shazzner> I'd like to see how the relation is joined
<jcastro> hey shazzner, are you interested in reviewing charms at some point?
<jcastro> I'd like to grow the amount of reviewers on charms too
<andrewsmedina> avoine: thanks
<shazzner> jcastro: yeah sure :)
<shazzner> huh, nothing in the charm store depends on tomcat that I could see
<marcoceppi> shazzner: I've got some feedback for your kusabax charm
<shazzner> marcoceppi: awesome
<_mup_> juju/relation-hook-context r519 committed by jim.baker@canonical.com
<_mup_> Logging of setting changes are labeled if they are not on an implied relation; docstrings/comments
<smoser> hey..
<smoser>  http://paste.ubuntu.com/911936/
<smoser> what is calling hostname -f
<smoser> hazmat, SpamapS ^
<marcoceppi> It's probably the db-reltation-joined hook
<shazzner> how do domains work with juju?
<shazzner> in kusabax it requires you to set the domain in teh config file
<shazzner> but if you wanted to migrate to blah.com how would you set a hook for that?
<marcoceppi> shazzner: you could have it as a config option
<marcoceppi> the charm would automatically write the instance URL
<marcoceppi> then in config-changed have an option for site-domain or something
<shazzner> marcoceppi: ok, add it to the config.yaml that's what I was thinking thanks! :)
<marcoceppi> yup, there's a few other things that I'm writing up in the bug report that are blockers though :\
<marcoceppi> Sweet found a bug with wget
<andrewgauger> So I was installing Ubuntu 12.04 and it mentioned Juju.  I was wondering if there was any way to bring juju to the Mac so we can support our current developers.
<robbiew> andrewgauger: we have plans for that during the next cycle, 12.10, and will probably add it via our Backports archive to 12.04
<andrewgauger> Very exciting times.  Best of luck!
<hazmat> smoser, the unit agent is to identify the net address
<jimbaker> my oscon talk on "jython concurrency" was accepted
<imbrandon> andrewgauger: yes thats one of my main goals ( juju on the Mac )
<bkerensa> SpamapS: any news on the juju contest?
<shazzner> juju on mac would be interesting
#juju 2012-04-03
<bkerensa> jcastro: :D who won the contest?
<bkerensa> :D
<jcastro> niemeyer: are you accepting bugs on the store yet? Or is it still sort of in progress?
<niemeyer> jcastro: Certainly accepting them
<niemeyer> jcastro: What's up?
<jcastro> http://pastebin.ubuntu.com/913016/
<niemeyer> jcastro: Hmmm
<jcastro> the .charm file is 0 bytes
<niemeyer> jcastro: Yeah, just noticed that.. very weird
<niemeyer> jcastro: Theoretically it doesn't link the charm in the final location while it's not completed successfully
<niemeyer> jcastro: Will investigate, thanks
<jcastro> lynxman: mira, want to do a charm review?
<lynxman> jcastro: throw it my way :)
<jcastro> https://bugs.launchpad.net/charms/+bug/961819
<_mup_> Bug #961819: New "sbuild" charm for build environments <new-charm> <Juju Charms Collection:Confirmed> < https://launchpad.net/bugs/961819 >
<jcastro> and https://bugs.launchpad.net/charms/+bug/956259 needs a final review
<_mup_> Bug #956259: Charm needed: znc  <new-charm> <Juju Charms Collection:Fix Committed by patrick-hetu> < https://launchpad.net/bugs/956259 >
<imbrandon> oh noes, party over, someone call the strippers and tell em not to show up, jono's here
<jono> lol
<imbrandon> jono: on a real note i got some more css goodness for ya for accomplishments-system , just finishing up some of the tweaks now
<imbrandon> some pictograms and such
<jcastro> lynxman: you have promulgation powers right?
<jono> imbrandon, oh thanks so much, pal!
<imbrandon> :)
<lynxman> jcastro: I don't know if I do, if I don't I'll bug you ;)
<marcoceppi> I'll be around today to prog if needed
<jcastro> lynxman: ok when you finish these up ping me and marcoceppi
<marcoceppi> That's the fun part though, typing in promulgate and simultaneously hoping it works and wondering if there's a better word for that action
<jcastro> it'd be nice to ring the bell 2 times today
<lynxman> jcastro: sounds good :)
<jcastro> negronjl like nginx, we'll have him check the new drupal one. :)
<jcastro> marcoceppi: appflower needs a round #2 and it should be done
<marcoceppi> jcastro: perfect, if juju bootstraps then I'll give it a quick go
<jcastro> ditto for gitolite
 * marcoceppi really wants to try out gitolite
<jcastro> this week gentlemen, we promulgate!
<imbrandon> i would soo need that in bash completion
<imbrandon> :)
<marcoceppi> Thankfully it is
<imbrandon> prom<tab><tab><TAB!!! DAMMIT>
<imbrandon> lol
<imbrandon> jcastro: i dident mirror the drupal one to LP, let me know if i need to
<niemeyer> jcastro: fix on the way
<marcoceppi> imbrandon: it needs to be on LP to be promulgated
<imbrandon> kk, i'll do that now then
<jcastro> we'll need to figure out a way to autoimport github charms onto LP if we want that to scale.
<imbrandon> history dont matter does it, i can just bzr init it clean right ?
<jcastro> but m_3 is at a conference so we can deal with it later.
<imbrandon> yea i can help him with that too maybe a bit, for Penton I wrote the hg<-->git two way mirror for our repos
<imbrandon> we used hg internaly but all contractors used git :)
<imbrandon> git and hg shared hashes thou, not sure if bzr does
<marcoceppi> LP can already pull git repos
<imbrandon> oh really ?
<marcoceppi> it can only mirror the master branch though
<imbrandon> do i just need to import it ?
<imbrandon> thats fine
<marcoceppi> http://askubuntu.com/questions/13613/git-on-launchpad
<imbrandon> i forgot github has an svn interface too
<marcoceppi> So you can just push everything to github and every 4-6 hours it'll be imported on to LP
<imbrandon> nice, thast perfect, and i work in named branches and merge to master as the "gold" copy anyhow
<imbrandon> as most git ppl do
<imbrandon> so works out perfect
<marcoceppi> Hum, deploying from the store gives me an error
<jcastro> I just told niemeyer, he's on it
<marcoceppi> ah, cool
<jcastro> something something needs to be a zip file?
<niemeyer> marcoceppi: What's the error?
<niemeyer> marcoceppi: Just to make sure we're talking about the same thing
<niemeyer> jcastro, marcoceppi: Should be fixed in 5 minutes or so
<imbrandon> i get the same thing jcastro did a bit ago
<marcoceppi> niemeyer: http://paste.ubuntu.com/913053/
<niemeyer> marcoceppi: That's it, thanks
<marcoceppi> I was getting all gutsy and trying to deploy from the store :)
<niemeyer> Will be fixed in a few
<niemeyer> marcoceppi: Sorry for undermining the excitement :-)
<niemeyer> marcoceppi: HOld it for a moment, though!
<niemeyer> :-)
<jcastro> heh, I was already cheering when I hit enter.
<imbrandon> marcoceppi: do i need to make a project to import from another vcs ?
<marcoceppi> imbrandon: I have no idea
<marcoceppi> Never actually used it
<jcastro> just push it by hand for now
<imbrandon> LP ui really does suck, i've been using it for 6 years now and still dont "get it"
<jcastro> we can sort the automated bits later
<imbrandon> kk
<imbrandon> i just thouht about that, 6 years, wow, its been a long time, wonder where that whiprush dude i used to give hell to is nowa days
<jcastro> imbrandon: less talk, more pushing. :)
<imbrandon> its pushing
<jcastro> we're running out of days!
<imbrandon> shish
<imbrandon> bzr = slow
<marcoceppi> There's your whiprush and whip crack!
<imbrandon> hahah
<imbrandon> ahh crap its slow cuz its pushing .git
<imbrandon> ctl+c
<imbrandon> ugh
<imbrandon> ok done
<imbrandon> and linked to bug
<SpamapS> Amd I weird because I like LP's UI? (except blueprints)
<imbrandon> heh
<SpamapS> I find the cross-project-distro bug tracking to be supremely useful
<imbrandon> i dont think its ugly, ui was probably the bad word, i dont get most of the workflows
<SpamapS> and linking branches/merge proposals to bugs is really nice.
<SpamapS> imbrandon: add a bug.. toggle a status... whats not to get?
<imbrandon> SpamapS: yea most modern trackers do that, gitosis , github, bitbucket, and i'm sure others :)
<SpamapS> they're all *really* short
<imbrandon> SpamapS: the basics sure
<SpamapS> and please, don't bring up github's *ridiculous* issue tracker
<SpamapS> I'm coming around to git.. but that thing is a joke.
<imbrandon> heh, i love it personaly ;)
<imbrandon> to each their own i guess on that one
<imbrandon> heh
<SpamapS> its great for small projects I'm sure
<marcoceppi> Charms still require two reviewers, right?
<SpamapS> marcoceppi: *no*
<SpamapS> never have
<marcoceppi> *what*
<SpamapS> marcoceppi: ~charmers needs 2 +1's
<SpamapS> marcoceppi: but if you are in ~charmers, you have the power
<imbrandon> SpamapS: rails isnt what id call a small project nor bootstrap, or h5bp
<marcoceppi> Why have I always thought that charms require two reviewers
 * SpamapS hears "YOU GOT THE TOUCH" in his mind and starts googling for leather pants prices
<jcastro> we've been doing 2 reviewers for the sake of completeness, I think people just got into the habit of doublechecking each other's work
<imbrandon> haha
<jcastro> which is fine by me also
<SpamapS> imbrandon: I suppose by having no features.. it forces developers to just focus on each issue rather than being able to prioritize stuff away
<imbrandon> ok going to get some food and shower/shave , back in 20 min for critique if there is any by that time :)
<imbrandon> SpamapS: yea, sometimes too much optiions is not a good thing
<marcoceppi> Cool, well looks like appflower is ready then!
<imbrandon> SpamapS: and you can prio somewhat
<imbrandon> anyhow brb food time
<SpamapS> imbrandon: though many would call LP's features pretty minimalistic when compard to bugzilla
<imbrandon> very very true, that thing is horrific
<imbrandon> but really its not the number of features about LP , nor the ui specificly , i mis spke at first, but more the workflow as in sometimes , hell all the time its not clean on what needs to be done or if something does or how to do it, or click then then that to do this, FSK!!! give me ONE "FIXED!" button
<marcoceppi> Found a but with charm proof
<niemeyer> marcoceppi, imbrandon, jcastro: It's fixed
<marcoceppi> party time
<imbrandon> niemeyer: rockin ty
<imbrandon> SpamapS: but on the other hand i'm a huge fan of minimalitic UI's too, sometimes to a fault
<imbrandon> ok really gone for food, brb
<jcastro> ok but we need to wait for it to be deployed? I'm not familiar with the store workflow
<marcoceppi> jcastro: it worked for me, just delete the file in ~/.juju/cache/
<SpamapS> Have we fixed the mysql charm in the charm store yet?
<SpamapS> It was broken as of Friday
<marcoceppi> Would a charm having an optional config option with no config-changed hook be a blocker?
<marcoceppi> Or a fix after prog situation?
<jcastro> niemeyer: this is great, I've deployed a bunch of stuff from branches too
<marcoceppi> Yeah, charm store rules already
<jcastro> niemeyer: so "source" and "publish" are 12.10 targets then?
<marcoceppi> so much faster
<SpamapS> marcoceppi: all configs are optional.. I think its ok to have configs that only get applied in install as long as the config.yaml says so in the option's description.
<jcastro> also, I already want "juju search blah"
<marcoceppi> SpamapS: well it doesn't get applied anywhere :)
<marcoceppi> I think it was a future feature half added
<marcoceppi> anywho, I'll mention it in the branch and promulgate
<SpamapS> marcoceppi: thats just a bug. I wouldn't block promulgation on that if it were the only thing wrong.
 * marcoceppi *nod*
<jcastro> just file a bug for it on the spot so we don't forget
<SpamapS> blockers are "does nothing", "explodifies", or "pwns you"
<marcoceppi> cool, appflower is ready. about to promulgate
<SpamapS> its the app FLOW-er
<SpamapS> endorsed by Flo-rida
<niemeyer> jcastro: Yeah
<niemeyer> jcastro: I intend to provide some helpful API endpoints well before that, though
<niemeyer> jcastro: The first thing I want to expose is the error messages
<niemeyer> jcastro: Every imported charm already comes with status
<niemeyer> jcastro: We should have a way to show the import result, so that any failures may be known by the author
<jcastro> I just realized the store spec doesn't mention search
<jcastro> should I file a bug on that?
<jcastro> basically like how apt does it
<niemeyer> jcastro: Yeah, please feel free to file it
<niemeyer> jcastro: It'll certainly come
<marcoceppi> SpamapS: getting an error on promulgation "ERROR:Branch has not been pushed." with nothing else
<SpamapS> marcoceppi: promulgate uses the remembered push location
<SpamapS> marcoceppi: bzr push lp:~charmers/charms/appflower/trunk && charm promulgate should work
<marcoceppi> Cool, thanks
<imbrandon> zomg jcastro SpamapS marcoceppi , yalll cant miss this http://jujucharms.deviantart.com/
<imbrandon> hit #3 on google
<SpamapS> maybe we can get the artist to make us some keychains for promulgatee's
<imbrandon> heh
<_mup_> Bug #972515 was filed: Charm store needs search functionality <juju:New> < https://launchpad.net/bugs/972515 >
<jcastro> SpamapS: did you promulgate Subway?
<SpamapS> jcastro: yes
<jcastro> ok anything else on Friday? I need to chase the people down for swag remember
<SpamapS> jcastro: code.launchpad.net/charms .. you can see all the charms that have been pushed/promulgated recently
<SpamapS> jcastro: "Mature" means promulgated :)
<lynxman> the old way of deploying charms doesn't work anymore?
<lynxman> 2012-04-03 11:44:15,105 ERROR Bad charm URL 'local:precise:precise/splice-glance-keystone-mysql-rabbitmq/': no series specified (URL inferred from 'local:precise:precise/splice-glance-keystone-mysql-rabbitmq/')
<lynxman> sorry, that's the error: 2012-04-03 11:43:30,886 ERROR Bad charm URL 'local:precise/splice-glance-keystone-mysql-rabbitmq/': no series specified (URL inferred from 'local:precise/splice-glance-keystone-mysql-rabbitmq/')
<lynxman> I have default-series as well in my environments.yaml
<SpamapS> lynxman: repository should still work the same
<lynxman> SpamapS: yeah I don't need to specify the series in the repo url anymore, it's wrong in the docs in juju.ubuntu.com as well
<SpamapS> lynxman: you never had to specify series in the repo url
<SpamapS> ??
<lynxman> SpamapS: you had to at some point
<lynxman> SpamapS: and it still says so in the docs
<lynxman> SpamapS: https://juju.ubuntu.com/docs/user-tutorial.html#deploying-service-units
<lynxman> SpamapS: see the "oneiric/somecharmname" in the juju deploy line
<SpamapS> lynxman: I've been using 'local:foo' for a long time.. but I agree the docs is not awesome
<lynxman> SpamapS: I always was using the doc method, doesn't work anymore :)
<marcoceppi> SpamapS: these docs are all in juju/docs right?
<SpamapS> lp:juju/docs is where juju.ubuntu.com/docs is generated
<jcastro> marcoceppi: are you on precise? Can you try to deploy zookeeper from the store?
<marcoceppi> Yea, let me fire up my laptop
<marcoceppi> deploy zookeper?
<jcastro> yeah
<jcastro> 2012-04-03 12:36:39,085 ERROR Error processing 'cs:precise/zookeeper': entry not found
<jcastro> is what I get
<marcoceppi> Oh, but you should be able to do that from an oneiric machine, so long as you set the series up correctly. I'll try anyways
<jcastro> I'm all precise right now
<jcastro> but if you want to test it on oneiric if you have it handy that would be useful too
<marcoceppi> I get the same error on my precise laptop
<marcoceppi> Maybe only oneiric series is in the store atm?
<jcastro> SpamapS: is that because we haven't done something in launchpad for the precise series or is it a bug in the store?
<jcastro> marcoceppi: there's a precise version in the charm browser, not sure how that relates to what's in the actual store
<marcoceppi> I'm not sure either
<shazzner> marcoceppi: hey Marco, did you comment on the kusabax bug with your feedback? :)
<marcoceppi> shazzner: ah, I don't think I submitted it yet. Let me get back to you after lunch
<shazzner> marcoceppi: gratci :)
<SpamapS> Yes only oneiric is in the store right now...
<SpamapS> but I don't think that should be the case
<niemeyer> jcastro: How's the store coming?
<niemeyer> jcastro: Is it working well now?
<jcastro> yep
<jcastro> I've deployed a bunch of things
<niemeyer> jcastro: Super
<SpamapS> niemeyer: yeah, the charm store is working beautifully. :)
<SpamapS> though we still need a switch-charm command so people can fix things without re-deploying
<jcastro> SpamapS: it also just made it painfully obvious that we don't have many precise charms, heh
<marcoceppi> I may have found a bug with boolean configs: http://paste.ubuntu.com/913459/
<marcoceppi> Am I missing something or should this be filed?
<jcastro> marcoceppi: hey check this out: https://help.ubuntu.com/community/EC2-VNC
<jcastro> I was thinking this might be a cute charm
<marcoceppi> smells like a charm
<jcastro> I think it would be cool to have config options to be desktops
<jcastro> so you could test derivatives, etc.
<marcoceppi> problem with that, is you couldn't just sudo apt-get remove *buntu-desktop since meta packages don't remove their dependencies
<marcoceppi> Would have to find a way to cleanly remove those each time. Maybe use aptitude instead
<jcastro> ugh
<marcoceppi> <3
<marcoceppi> #blameapt
<marcoceppi> Would be a cool charm though
<marcoceppi> What would you call it?
<jcastro> hah "juju deploy ubuntu"
<marcoceppi> perfect!
<SpamapS> marcoceppi: I do believe that is a (trivial to fix, but extremely critical) bug in juju set
<marcoceppi> SpamapS: thanks, I'll open a bug report
<jcastro> SpamapS: you in distro mode or charm mode?
<jcastro> daddy wants promulgation
<SpamapS> jcastro: I'm in "recover from 3 days away from email" mode, but I can be interrupted to do important things. :)
<jcastro> https://bugs.launchpad.net/charms/+bug/912050
<_mup_> Bug #912050: Charm Needed: OpenERP <new-charm> <Juju Charms Collection:Fix Committed by patrick-hetu> < https://launchpad.net/bugs/912050 >
<jcastro> and maybe https://bugs.launchpad.net/charms/+bug/906176 ?
<_mup_> Bug #906176: Gitolite charm <new-charm> <Juju Charms Collection:Fix Committed by shazzner> < https://launchpad.net/bugs/906176 >
<marcoceppi> I can grab one of thoes
<marcoceppi> oh both
<marcoceppi> or*
<jcastro> ok
<jcastro> didn't I give you two today already?
<marcoceppi> I did only one :)
<marcoceppi> I don't recall a second one
<SpamapS> I already poked at openerp so I will focus on that one
<jcastro> https://bugs.launchpad.net/charms/+bug/964936
<_mup_> Bug #964936: Drupal Charm: superchared Drupal charm with nginx,, apc, php-fpm, all setup to scale to the moon and be Best Practices. <new-charm> <Juju Charms Collection:Confirmed for imbrandon> < https://launchpad.net/bugs/964936 >
<jcastro> marcoceppi: how about that one?
<marcoceppi> Oh, I haven't looked at that one yet
<marcoceppi> let me grab it while I wait for imbrandon to wake up
<jcastro> Nick has a semi-abandoned drupal charm already
<jcastro> so depending on what you think maybe this can just supercede it?
 * SpamapS votes for it to supersede the others that weren't done by people who make drupal sit up, roll over, and beg like imbrandon does ;)
<jcastro> marcoceppi: I've got some other merge proposals too if you want to clean those up
<marcoceppi> jcastro: yeah, I saw those, shouldn't take too much time to get them updated
<marcoceppi> SpamapS jcastro so if this checks out, just charms/drupal ?
<SpamapS> marcoceppi: yes
<SpamapS> that should always be the most current drupal
<marcoceppi> sounds good
<jcastro> SpamapS: https://bugs.launchpad.net/charms/+bug/903361/comments/3
<_mup_> Bug #903361: Charm needed: Alice IRC <new-charm> <Juju Charms Collection:Incomplete by jorge> < https://launchpad.net/bugs/903361 >
<jcastro> Should the open-port be in the install hook or the start hook?
<jcastro> I think start because you don't want to open the port until the service is started right?
<jcastro> marcoceppi: alice irc is ready. :)
<marcoceppi> sweet!
<marcoceppi> I'm going to just go in to charm mode for the rest of the evening since I'm done at work
<marcoceppi> then switch to omg tonight
<jcastro> marcoceppi: lynxman snagged znc and sbuild, but he's slow, we could do those today too
<jcastro> https://bugs.launchpad.net/charms/+bug/966484
<_mup_> Bug #966484: New Charm: Kusaba X <new-charm> <Juju Charms Collection:New> < https://launchpad.net/bugs/966484 >
<jcastro> is also another shazzner production
<marcoceppi> yeah, I've got a review in the draft for that
<_mup_> Bug #972829 was filed: maas-server setting requires port even when using http default <juju:New> < https://launchpad.net/bugs/972829 >
<jcastro> SpamapS: ok so even if we didn't make the precise store "open" yet, shouldn't "juju deploy precise/zookeeper" work?
<niemeyer> jcastro: Are there any blog/G+/whatever posts about the store yet?
<jcastro> niemeyer: I have a draft, but my problem is I can't seem to deploy any precise charms
<niemeyer> jcastro: Was just thinking about mentioning it online, but it'd be good to point it to something that is not an https API endpoint :-)
<niemeyer> jcastro: What happens?
<jcastro> Error processing 'cs:precise/zookeeper': entry not found
<jcastro> but I don't know if this is a store bug or a charms bug
<niemeyer> jcastro: Hmm.. maybe it doesn't actually exist in the store?
<jcastro> niemeyer: I have an epic blog post ready that I have been working on, I just need to make sure my examples work
<jcastro> http://jujucharms.com/charms/precise/zookeeper
<robbiew> the problem is that we don't have many precise charms yet
<robbiew> SpamapS has some plan for this
<jcastro> right, but the ones that are in there I can't seem to deploy
<robbiew> ah
<jcastro> yeah, that's not my main concern right now
<jcastro> we'll just copy the oneiric ones over, run the charm tester, and see what breaks
<niemeyer> jcastro: Uh.. there are apparently *no* official precise charms
<niemeyer> jcastro: Yeah, that's why I was against having that web site as it is in the first place, but that's history
<robbiew> jcastro: what niemeyer said
<robbiew> https://code.launchpad.net/charms/precise
<jcastro> oh ok, I can file a bug on that
<robbiew> has no lp:charms/appflower for example
<robbiew> like https://code.launchpad.net/charms/oneiric does
<jcastro> hmm ok
<jcastro> so ... either wait for the grand master copy over to precise, then mention the store
<robbiew> jcastro: that's what SpamapS was going to sort out...I believe
<jcastro> or I can rejig the announcement to talk about oneiric charms
<robbiew> I like the latter option, although it takes more effort :/
<jcastro> and then say something like "the store won't switch over until precise releases, but you get the idea."
<robbiew> ack
<jcastro> robbiew: the post is more about policy than actual commands
<robbiew> cool...then I say sooner is better
<jcastro> I even say "this command doesn't exist yet, but you get the idea."
<jcastro> ok, on it.
<jcastro> give me 15.
<niemeyer> jcastro: Yeah, +1 on going with Oneiric for the post
<niemeyer> jcastro: Otherwise you'll be waiting on an unbound timeframe
<jcastro> that's should be motto of this cycle
<jcastro> juju deploy unbound-timeframes
<jcastro> \o/
<marcoceppi> That ec2-vnc thing didn't quite work for me :/
<hazmat> jcastro, while that charm exists for precise, it hasn't been promulgated such that its the branch tip
<hazmat> jcastro, the charm browser was written when that notion was in its infancy, so it takes the expedient approach of if the branch name matches, show it for that series.
<hazmat> because its clearly at the official branch namespace for that package, even if it hasn't been promulgated as the official branch tip yet.
<marcoceppi> jcastro: all your readmes are up to date
<jcastro> marcoceppi: thanks!
<jcastro> hazmat: thanks for clearing that up
<marcoceppi> jcastro: you said Alice IRC was ready for review+prom?
<jcastro> yessir
<jcastro> other than the location of the expose
<jcastro> which we wanted clarification on, but I don't think it's a deal breaker
<marcoceppi> naw, that can be a patch later
<jcastro> marcoceppi: next time shazzner and SpamapS are around I'd like to talk about putting him in ~charmers
<jcastro> he's got enough under his belt soon
<jcastro> same with patrick-hetu I think
<marcoceppi> 07
<shazzner> marcoceppi: thanks for your feedback, I'll get to work on it! :)
<marcoceppi> shazzner: thanks for the charm! This is going to be perfect for the office :)
<hazmat> jcastro, niemeyer its a significant problem that the workflow for the charm store, is rather non obvious for a charm contributor of 206 charms on launchpad, 146 aren't properly marked for a series.
<shazzner> got to run to the hackerspace but I'll get the changes in tonight
<marcoceppi> jcastro: I need to clarify one thing with the website-relation-joined hook, I don't think there's a `unit-get private-address` can someone confirm that it exists?
<jcastro> that whole part confuses me
<marcoceppi> I think there's only public-address and for the private address people have been using `hostname -f`
<marcoceppi> From my understanding you can only get unit data that's shown from the status, so under a typical unit you have agent-state, machine, and public-address
<niemeyer> hazmat: A charm contributor doesn't have to be aware of that workflow at first.. SpamapS, m_3_, and jcastro have to be aware of it
<jcastro> it's not ideal, it involves me hand checking all the time, but we can discuss that at UDS
<niemeyer> hazmat: So far there was very little reason to follow the arguably boring procedure
<niemeyer> hazmat: Now there's a good one
<jcastro> it certainly won't scale, heh
<hazmat> niemeyer its more than that, and this applies even to a ppa charms, which won't be curated
<hazmat> marcoceppi, 'private-address' works as well
<niemeyer> hazmat: What's the "more than that" in this case?
<marcoceppi> hazmat: Thanks, should older charms be updated to use private-address instead of hostname -f ?
<hazmat> niemeyer, its more than just the curated collection of the official distribution, being manually managed
<hazmat> niemeyer, ie. it definitely applies to charm contributors
<hazmat> marcoceppi, yes
<niemeyer> hazmat: Sorry, I don't understand what you're trying to say..
<niemeyer> hazmat: Those "it" are missing context.. it is more.. it definitely applies.. etc
<hazmat> niemeyer,  'its' a significant problem that the workflow for the charm store, is rather non obvious for a charm contributor of 206 charms on launchpad, 146 aren't properly marked for a series.
<niemeyer> hazmat: Do we have a single person that contributed 206 charms!?
<jcastro> shazzner is well on his way, heh
<hazmat> niemeyer, we have 59 contributors.. most of whom haven't gotten the process right such that they have a charm in the charm store.
<niemeyer> hazmat: Why!? All of them have a charm in the charm store, unless their charms are broken
<hazmat> niemeyer, how many charms in the charm store?
<niemeyer> hazmat: mthaddon is the one with the numbers, and he's asleep by now
<niemeyer> hazmat: You can find out-of-date numbers in the email I sent to the list some time ago, though
<hazmat> niemeyer, most of the charms pushed to lp at a correct address don't have series returned by getbranchtips
<hazmat> niemeyer, i have the current numbers..
<niemeyer> hazmat: Branches don't need a series to be in the charm store
<hazmat> niemeyer, then why aren't the precise charms there?
<niemeyer> hazmat: That is, they don't nee to be marked as a series
<niemeyer> hazmat: They are there.. they are just no under cs:precise/* namespace, because they've not been blessed by SpamapS/m_3
<niemeyer> hazmat: % wget --quiet -O- https://store.juju.ubuntu.com/charm/~shazzner/precise/kusabax | wc -c
<niemeyer> 5646
<hazmat> niemeyer, yeah. saw that one
<niemeyer> hazmat: Well, what are you bring up then?
<niemeyer> bringing
<hazmat> niemeyer, so its only the official ones that need to be marked/promulgaged against the series
<hazmat> ?
<niemeyer> hazmat: Yes, it's only the official ones that have to be made official. (!)
<hazmat> ic
<hazmat> so these charms at the official branch locations which haven't been marked as tip.. http://paste.ubuntu.com/913770/
<lynxman> jcastro: sbuild charm looks good, don't have powers though :)
<hazmat> er. promulgated
<jcastro> ^^ marcoceppi want to promulgate that badboy?
<marcoceppi> yeah!
<bkerensa> sup jcastro
<jcastro> heya bkerensa
<jcastro> store is live, your charm is in it brother!
<jcastro> http://www.jorgecastro.org/2012/04/03/the-juju-charm-store-will-change-the-way-you-use-ubuntu-server/
<jcastro> ^^^ I need help spreading the word on this
<bkerensa> jcastro: I will push it on the social webz
<bkerensa> jcastro: any news on contest? :P
<jcastro> tomorrow-ish
<jcastro> we've published like 3-4 today already
<hazmat> jcastro, nice blog post
<jcastro> hazmat: thanks!
<bkerensa> http://www.reddit.com/r/linux/comments/rrvec/why_the_juju_charm_store_will_change_the_way_you/
<jcastro> upvotes please!
<jcastro> http://www.reddit.com/r/Ubuntu/comments/rruma/why_the_juju_charm_store_will_change_the_way_you/
<jcastro> I have it there as well
<jcastro> marcoceppi: alice redirect fixed and pushed.
<AlanBell> jcastro: interesting article, I might have to become interested in this juju stuff at some point
<marcoceppi> jcastro: sweet, just about to prom sbuild
<bkerensa> jcastro: ok enjoy traffic (Reddit, Stumbled, Facebook, Twitter, G+, Hacker News etc) done
<jcastro> AlanBell: almost as if I planned it all along
<jcastro> bkerensa: where's the HN link, HN I've never been able to get onto
<bkerensa> jcastro: http://news.ycombinator.com/item?id=3795097
<jcastro> bkerensa: I don't think HN will roll to a reddit link
<jcastro> is there a way to edit it to point to the canonical url?
<jcastro> hah, I made a pun
<bkerensa> jcastro uhh oh
<bkerensa> jcastro: fixed here http://news.ycombinator.com/item?id=3795109
<bkerensa> jcastro: yeah if you can ship that stuff it would be better... my fiancee wants me to pickup tourist swag on my trip home from UDS... and unfortunately Ill be stuck in Oakland for a entire day after UDS
<bkerensa> :D
<bkerensa> so shopping I must
<jcastro> no worries, I have a juju shirt with your name all over it bud
<bkerensa> k
<bkerensa> jcastro: well the cup was what I was hoping for :P but ok
<bkerensa> :D
<AlanBell> how well does juju work with lcx containers?
<bkerensa> AlanBell: fine
<bkerensa> AlanBell: You can use lxc for testing charms
<AlanBell> and you do that on your own computer right?
<bkerensa> yeah
<AlanBell> could someone host a heap of computers running lcx for juju?
<AlanBell> so kind of an amazon cloud that scales down small
<AlanBell> with a different cost model
<jcastro> AlanBell: yeah so what you really want, is an "ssh provider" that ssh'es into your linode and does all the magic
<marcoceppi> I wouldn't use LXC for production, to be honest
<AlanBell> jcastro: I am thinking of being such a provider
<marcoceppi> AlanBell: You could deploy Open Stack if you wanted to go *that* route
<niemeyer> jcastro: "since we havenât deployed the charms to Precise yet"
<niemeyer> jcastro: "deployed" may be confusing there
<jcastro> "opened" perhaps?
<AlanBell> marcoceppi: possibly, but I don't think juju instances need the hard isolation from each other of virtual machines, or the preallocation of memory
<niemeyer> jcastro: yeah, or "moved" or similar
<marcoceppi> sbuild is promulgated
<bkerensa> jcastro: Why didnt you do the talk at PuppetConf? Adam Gandelman and Marc Cluet were talking juju?
<marcoceppi> alice-irc promulgated
<jcastro> bkerensa: I don't think I was working on juju that much yet, we spread the load.
<jcastro> bkerensa: but no worries, I'll catch Luke and Co. at OSCON
<jcastro> marcoceppi: \o/
 * marcoceppi heads home.
<marcoceppi> Catch you guys in a bit
<SpamapS> AlanBell: what you probably want is openstack + lxc
<AlanBell> maybe, I will have to look into it
<AlanBell> I think that there might be a way to do a juju specific cloud provider that doesn't bill by the number of instance-seconds
<SpamapS> AlanBell: juju is more about using an API to manage compute resources. What you are talking about is more having compute resources and making it available via an API.. which is what openstack does. :)
<AlanBell> sure, but providing it in a way that works well for juju
<AlanBell> economically as well as technically
<SpamapS> AlanBell: frankly, LXC is probably *not* ready for a business to be built on top of it, and you are probably going to spend less on the slight inefficiency of kvm than you will bringing it up to snuff.
<SpamapS> AlanBell: LXC is going there.. but its not there yet. :)
<AlanBell> maybe openstack is the way to do it
<AlanBell> but you have to define your instance sizes ahead of time, I think with LCX you don't
<AlanBell> I kind of want to say "you have 4GB of ram, one public IPv4 address, an IPv6 subnet, it is all set up for juju, spin up as many instances as you like within that" for a fixed monthly hosting fee
<SpamapS> AlanBell: LXC isn't an "instance", its a container
<AlanBell> yeah, juju services then
<SpamapS> AlanBell: sorry, but why would I care about ipv6 subnets? I want availability, computing resources, RAM, disk IO.... not ips.
<AlanBell> well they have to talk to each other
<SpamapS> 127.0.0.1 works fine if its all on one machine. :)
<AlanBell> oh I guess that would work with lcx
<SpamapS> I want to understand what you're getting at.
<SpamapS> Do you want to use juju to setup a whole bunch of stuff on one physical machine?
<AlanBell> juju uses loads of machines, and amazon bills by the second
<AlanBell> or hour or whatever
<SpamapS> thats only because we haven't been clever yet.
<AlanBell> jcastro set up a wordpress blog that cost $85 per day in hosting fees
<SpamapS> AlanBell: and now its down to quite a bit lower than that.. I think maybe $2 or $3 / day
<SpamapS> AlanBell: because we got a lot more clever. :)
<SpamapS> AlanBell: and thats a blog with > 1 million hits per day, btw
<AlanBell> sure
<SpamapS> which is now elastically scalable with one command.. 'juju add-unit omg-wp'
<AlanBell> it is a fairly big wordpress install, and a lot was learned
<AlanBell> but still to get wordpress up you need a server for mysql and a server for apache
<SpamapS> AlanBell: I know what you're getting at. Allowing people to over-subscribe machines (or just use bigger machines and higher density) is definitely on the radar.
<AlanBell> and a server for the controller and a server for a loadbalancer if you want to scale it
<SpamapS> AlanBell: except.. we moved the load balancer onto the omg-wp nodes
<AlanBell> I don't think it is a massive technical problem, I just think the amazon model of charging by instance-hour doesn't really work so well for juju
<SpamapS> AlanBell: it works great for juju. :)
<AlanBell> works great for amazon too :)
<SpamapS> AlanBell: the ZK node can be a t1.micro
<AlanBell> bet they love it
<AlanBell> oh I thought all the juju instances had to be the same size?
<SpamapS> AlanBell: the only situation where it doesn't work well is for sites with no actual traffic.
<SpamapS> AlanBell: no, you can (painfully) change your instance type between deploys.
<AlanBell> yeah, "no actual traffic" is where every site starts out though
<SpamapS> AlanBell: all the instance types for one given service do currently need to be the same.
<AlanBell> so what you need is a smooth migration path from "no actual traffic" to "argh, spin up more instances"
<SpamapS> AlanBell: so they use t1.micros and as they get bigger, reboot them into m1.small's, then medium, and up and up.. ;)
<SpamapS> t1.micro can be rebooted into any other instance size.
<SpamapS> AlanBell: I do want to be able to put a few things on one instance though.. I'm with you there.
<AlanBell> I would kind of like to start building stuff like openERP instances with juju, but no way am I going to tell a customer they need 3 servers from day 1
<AlanBell> plus another 3 for a test/dev environment
<SpamapS> AlanBell: 3 t1.micros would be $51/month ...
<SpamapS> they're not servers, they're VMs :)
<AlanBell> we have a bunch of these http://www.hetzner.de/en/hosting/produkte_rootserver/ex5 which we divide up with KVM
<SpamapS> AlanBell: right, so throw openstack in front of that and you have an API. :)
<AlanBell> yeah, thats what I am thinking
<SpamapS> AlanBell: and just chop them up into tiny bits like they do w/ t1.micro and you're set for juju users. :)
<AlanBell> yeah, could go quite a bit smaller than the t1.micro
<SpamapS> AlanBell: 600MB is pretty tiny :)
<SpamapS> AlanBell: I suppose it would work for haproxy though. :)
<AlanBell> oh, I thought the t1.micro was 1.7GB, is that the small one?
<SpamapS> thats m1.small
<SpamapS> t1.micro is borrowed CPU .. and something just under 700MB of RAM
<AlanBell> ah right, 600mb is pretty small
<AlanBell> yeah, not going to get much on that after the operating system
<SpamapS> Yeah, 80MB for the kernel, 200+MB for in use VFS cache.. you basically just have enough for a single process low-memory type program.
<SpamapS> and then you still have the issue that sometimes there just won't be any CPU for you
<AlanBell> however the point of this thought experiment is to have lots of tiny VMs so that you can start your juju thing and do the horizontal scaling and then when you get big, move to Amazon
<SpamapS> AlanBell: I *love* that idea. :)
<jono> hey guys
<jono> jcastro called me and asked if you can respond to questions on http://news.ycombinator.com/item?id=3795109 while he is at dinner
<hazmat> SpamapS, constraints land3ed
<AlanBell> anyhow, night all o/
<hazmat> SpamapS, ie. you can verify instances easily per service
<hazmat> arg.. vary
<_mup_> juju/relation-hook-context r520 committed by jim.baker@canonical.com
<_mup_> Better tests
<_mup_> juju/relation-hook-context r521 committed by jim.baker@canonical.com
<_mup_> Merged trunk
#juju 2012-04-04
<SpamapS> hazmat: *sweet* wasn't sure if it was done yet :)
<SpamapS> jcastro: http://news.ycombinator.com/news .. I see you at #6
<marcoceppi> Yeah, way to make front page :)
<_mup_> juju/relation-hook-context r522 committed by jim.baker@canonical.com
<_mup_> Tests re visibility of changes in relations from an invoker
<marcoceppi> SpamapS jcastro it also made the ycombinator twitter feed: https://twitter.com/#!/newsycombinator/status/187314809887395840
<_mup_> txzookeeper/managed-watch-and-ephemeral r53 committed by kapil.foss@gmail.com
<_mup_> connection err trapping for managed conn
<_mup_> txzookeeper/managed-watch-and-ephemeral r54 committed by kapil.foss@gmail.com
<_mup_> add .bzrignore
<_mup_> txzookeeper/managed-watch-and-ephemeral r55 committed by kapil.foss@gmail.com
<_mup_> remove unesc. expire handler from retry client
<_mup_> juju/relation-hook-context r523 committed by jim.baker@canonical.com
<_mup_> Fix typo and old comment
<_mup_> juju/relation-id r501 committed by jim.baker@canonical.com
<_mup_> Merged trunk (to make lbox handle old prereq; this branch is already merged)
<jcastro> SpamapS: marcoceppi: thanks for the coverage while I was at taco night.
<jcastro> yes, there is such a thing as taco night.
<jcastro> hazmat: did you say constraints just landed?
<marcoceppi> np jcastro
<hazmat> jcastro, yeah.. last friday
<jcastro> hazmat: woo, tequila time!
<hazmat> jcastro, you can set constraints at bootstrap or when deploying a service
<_mup_> juju/trunk r509 committed by kapil.thangavelu@canonical.com
<_mup_> [trivial] change deploy output when using charm store [r=niemeyer]
<shazzner> marcoceppi: Marco, I'm checking out that sourceforge php download script. When it's set to https it doesn't work, gives ssl error. Any ideas?
<shazzner> specifically this: http://paste.ubuntu.com/914043/
<_mup_> juju/relation-hook-context r524 committed by jim.baker@canonical.com
<_mup_> Display parent context relation ident, if available, when logging relation settings
<_mup_> juju/managed-zk-client r510 committed by kapil.thangavelu@canonical.com
<_mup_> agents use managed conn
<_mup_> juju/relation-hook-context r525 committed by jim.baker@canonical.com
<_mup_> Merged trunk
 * benonsoftware wonders if the topic should change
<jml> I have a half-formed question
<jml> I can see how juju is useful for deploying services, and (for me at least), especially so for deploying dev instances of things I'm working on
<jml> well, at least once I'm allowed to target precise.
<jml> but is there some way to use it, or the charms or something to make setting up development environments easier?
<imbrandon> sure
<_mup_> Bug #973260 was filed: Unable to deploy charm that uses symbolic links from the charm store  <juju:New> < https://launchpad.net/bugs/973260 >
<imbrandon> its not really streight forward atm but yea, just create the charm to install all the dev env tools
<imbrandon> and maybe a current copy of the code
<imbrandon> and deploy or even deploy local to a lcx
<imbrandon> lxc
<jml> hmm
<jml> imbrandon: some differences that I can think of:
<imbrandon> k
<jml> - maybe want to have fewer units than on prod
<imbrandon> sure we do that on omg
<jml> - want to restart services way more frequently (as part of a dev cycle)
<imbrandon> stage has far fewer and even runs on micros vs larges
<jml> - want to have more verbose logging and some possibly insecure debug options
<imbrandon> config option
<jml> - would want to have dependencies for running tests installed
<jml> (and I guess for compiled languages whatever you need to do a build)
<imbrandon> sure all of thats doable now, the last bit i would religgate to a ci server
<imbrandon> but yea
<jml> well, I can't write code without running tests.
<imbrandon> sure i just wouldent have it on the same box, e.g let jenkins run the tests
<imbrandon> imho
<imbrandon> i mean you CAN, that is just prefrnce
<jml> imbrandon: that's generally not effective. Lots of projects deploy have long-running test suites, so while I'm TDDing I need to run a subset of the tests.
<jml> projects *I* deploy, that should read.
<imbrandon> thats a bug in the system imho , if you have long runnign test etc then sure i have lots of sites that do that but they run dedicated testing instances in addition to dev that use the ci server to mamnage the test runnign failures metrics etc
<imbrandon> e.g you end up with local dev, test env, dev env, qa, prod
<imbrandon> ci server manages the test env and long running cont test there
<jml> spell it out for me, you're in your dev env and you want to fix up bug. You write a test that reproduces the bug. How do you run that test?
<imbrandon> you keep dev and qa and prod as close to the same as possible just more/less instances
<imbrandon> you check in the code to vcs for the test
<imbrandon> the ci server picks ut up and runs the test on the test evn that mirrors dev
<imbrandon> ever used travis ci ?
<jml> and then you watch that test fail and then write the fix and then commit that?
<jml> no, I haven't.
<imbrandon> exactly, or you do the test and the code for the fix at the same time
<imbrandon> and check into vcs
<jml> but then you aren't doing TDD
<imbrandon> sure you are
<imbrandon> you;d have to of run the test local
<jml> If you haven't run the test to see if it failed, then how do you know if it's a good test
<jml> OK, now we're getting somewhere :)
<jml> For some projects, it's really complicated to set things up locally to be able to run the tests.
<imbrandon> i'm assuming here that you already have a process and adapting it to thus
<imbrandon> this*
<imbrandon> sure in those cases you do like i said first
<imbrandon> if you dont have a local instance
<imbrandon> and watch it fail or pass etc
<imbrandon> depending on test
<imbrandon> it sound like more work, but its only more work to setup, really its the exact same as you do now
<imbrandon> and once setup its setup for the whole team / multi prohject
<imbrandon> so a one off, its like setting up soyuz the first time, a PITA but its a one off :)
<imbrandon> if done right that is
<imbrandon> and if not its a charm, iterate adn redeploy :)
<imbrandon> wish irc had a white board, would be easier to explain a bit
<imbrandon> lol
<jml> Hmm. Maybe.
<imbrandon> but yea , local dev w/ test ( if possible ) --> check into vcs --> ci server watches vcs and runs test long and short and repeats etc --> passing code goes to dev --> then nightly to qa or whatever the schedule is --> pass qa ( automated qa or live ppl ) --> migrate to prod ( hopefully automaicly for XP )
<imbrandon> there is a bit more there, but thats the jest
<jml> I've already got CI set up, but any system which requires committing and pushing to run tests is unacceptable, and my goal here is to find a way to make it easier for people to set up environments to run tests locally
<imbrandon> well here is my deal, if it takes more than the developer to commit code ONE TIME to have it automaicly migrate to prod then something in the system is broken
<imbrandon> badly
<imbrandon> thats from many years of iterating this process
<imbrandon> ever read joel on software ?
<jml> Yes, of course.
<imbrandon> yea then bascily how he decribes tdd xp setups
<jml> Reference?
<imbrandon> is how i would/do have it
<imbrandon> sure, let me dig it up, been a while since i linked it :)
<imbrandon> and btw you'd be suprised at the ppl in our field that have never read that :)
<imbrandon> so i had to ask heh
<imbrandon> jml: here is most of it, there is a more specific one i'm looking for though
<imbrandon> http://www.joelonsoftware.com/articles/fog0000000023.html
<imbrandon> bah i cant find it right now
<imbrandon> i need a better bookmark system :)
<imbrandon> short awsner is yes though, no matter what your evn or workflow juju can probably make it easier
<imbrandon> jml: just curious but why "but any system which requires committing and pushing to run tests is unacceptable" i mean thats the goal of a continious intergration server, to be continious this no lagtime thus it dont matter if its local or a spun up juju instace or a vm template in vsphere
<imbrandon> or i'm missing somehting else that you dislike about it
<imbrandon> but yea, in your case i would setup a "prod" juju charm, then have the devs use it localy in lxc containers
<imbrandon> as the test env
<jml> imbrandon: oh, that's easy to explain.
<jml> imbrandon: requiring commit and push to run tests increases the time and effort it takes to run tests, making it more difficult than a system where the tests can be run locally.
<imbrandon> i think thats where we differ, i dont see the extra effort, its miliseconds diffrence
<jml> imbrandon: since I want to run tests very frequently, often after changing just a single line, that is unacceptable.
<imbrandon> ahh see i dont see it that way, but i often commit aftter just one line and then rollup commits for later
<jml> imbrandon: no, it's not. coming up with a commit message takes over a second.
<imbrandon> but thats whats good about a vcs like git that lets you do that whewre as hg or bzr wont
<imbrandon> jml: only on a finaly rollup commit, savr commits and test commits are automated
<jml> imbrandon: well, I guess to each their own, but I'm not adding extra steps to my TDD cycle what amounts to no gain.
<imbrandon> with automated messages
<imbrandon> jml: sure sure i was just reading back and thinking
<imbrandon> not trying to sell ya on another way
<imbrandon> :)
<imbrandon> i do think even with your flow though with minimal change juju could help via the local lxc containers
<imbrandon> but it would take some inital setup of the charm etc
<imbrandon> in that way , they would be more like vm snashots of prod that could have extra things in meta.yaml for when running in dev
<imbrandon> mode
<imbrandon> metadata.yaml
<imbrandon> like the verbose logging etc
<imbrandon> the one hiccup that i think will bite you right away is juju lxc dont persist past reboots
<imbrandon> so you reboot, redeploy local but in reality thats a good thing becuse it makes sure the charm is "ture"
<imbrandon> true*
<imbrandon> have you used like vmware and made a vm then shapshoted it right after everythign was installed, then rolled back to that snapshot regularly ? it would be like that but more "live" as in the charm when "reverted" or deployed is the better word would be like a snapshot as in its clean env, but it would be the latest and greatest version of the code and env
<imbrandon> jml: if that makes more sense i think
<imbrandon> and exactly match prod as far as setup since its the same charm, possibly with other options ticked on or off for logging more etc
<imbrandon> when deployed
<imbrandon> anyhow i may be missing a big chunk of your goal too, i've still not had enough coffee yet this morn
<imbrandon> :)
<imbrandon> that and i think another thing we differed on , is in my initial tdd xp setup i had acceptance tdd mixed in with developer tdd
<imbrandon> that assumption can make a big diff too
<imbrandon> jml: btw if you need/want help with a skeleton charm to get you a proof of concept or something going i'd be glad to help. not the best charmer in the world but yea :)
<jml> imbrandon: thanks.
<jml> imbrandon: I think, realistically, I'm going to wait until our production DC is running precise.
<imbrandon> i hear ya, probably wont be terribly long
<imbrandon> might be worth playing with other simple charms before then
<jml> it had better not be
<imbrandon> just to get feel, took me ages to grasp their usefulness
<imbrandon> mor than like chef or something
<jml> I've already had a bit of a play around.
<imbrandon> :)
<marcoceppi> shazzner-asleep: That's weird, it should work
<imbrandon> moins marcoceppi
<marcoceppi> imbrandon: o/
<imbrandon> think i could bribe you into import-id for me on stage.omg at some point this morning ?
<marcoceppi> Yeah, in an hour or so when I'm back in the office, I don't think I have the same ssh key that's currently on omg here on this machine
<imbrandon> no worries, just whenever
<imbrandon> ty
<imbrandon> jml: also i'm still very new to the juju stuff too, so Spa*mapS and marco*ceppi etc might have even more detailed insight when they are active ( put the * so irc wouldnt ding them un-needed )
<imbrandon> been round webdev many years, juju still wrapping my head round, although its clearing up mostly
<_mup_> juju/trunk r512 committed by kapil.thangavelu@canonical.com
<_mup_> [trivial] tweak cli help options for consistency/formatting
<SpamapS_> imbrandon: so, what crack were you smoking that you thought joel on software recommends that you not run test suites on dev machines during development? ;)
 * SpamapS_ is reading backscroll
<jml> SpamapS: I have to say the same thought crossed my mind.
<imbrandon> no
<imbrandon> thats not what i said
<imbrandon> i said run it via a ci server in a test env
<SpamapS> imbrandon: its what you said. :)
<SpamapS> imbrandon: jml was talking about setting up a server *to write the code on* not to test the code.
<jcastro> hazmat, ok I pushed up some doc updates so at least they're not totally wrong, how often does the doc cron generator run?
<imbrandon> huh? that in no way says that
<SpamapS> imbrandon: what you're describing is the stage where the developer believes he has triumphed over the bug/feature/etc.
<imbrandon> <.< >.>
<SpamapS> jml: what you're describing has two good answers in juju right now
<imbrandon> sure after a test has been written and sent to the ci server to fail
<SpamapS> imbrandon: jml wants to write a single test... and then run it and see it fail. Then write code to make it pass. *then* commit and run the whole suite.
<hazmat> jcastro, i don't see that info in the rt... not sure
<jcastro> hazmat, ok I guess I'll just find out when it happens, heh
<SpamapS> imbrandon: you don't need a CI server to run *just that one test*
<imbrandon> SpamapS sure and i said thats wrong , no you dont but you should have
<jcastro> SpamapS, let's finish up the contest today
<imbrandon> "just that one test" and things like it are what make inconsistencies happen
<SpamapS> jcastro: yes, sorry, I was sort of useless yesterday.. should be ready to wrap it up in a couple of hours
<jcastro> cool
<jcastro> the only one left to propagate for the contest is znc
<SpamapS> imbrandon: also bzr's whole design is based around rollup commits. :)
<imbrandon> i can write tests and have them pass all day long but it dont mean in a clean env that the ci box ensures it will pass
<jcastro> lynxman, we just need a thumbs up from you on that one if you're reviewing it
<jcastro> SpamapS, oh, and openerp of course
<SpamapS> imbrandon: so the idea of commit commit commit commit then make a single merge commit is quite common in bzr land. You can even rebase if you'd like to erase all your crackful iterating commit messages. :)
<jcastro> SpamapS, ok so let's plan on hanging out this afternoon?
<imbrandon> i've never seen bzr used like that, i'd need to look over the docs its not the norm for people
<jml> imbrandon: to be crystal clear, I'm not saying I don't need or want CI.
<SpamapS> jcastro: 10:00 my time, 13:00 yours?
<imbrandon> jml: i know i;m trying to keep SpamapS_ from putting words in my mouth out of context
<jcastro> SpamapS, actually let's go post-lunch your time, I have physical therapy today and the wife works late so I can be flexible there.
<imbrandon> SpamapS i dont think you understood what i was getting at
<imbrandon> well obvuously now
<imbrandon> not*
<SpamapS> jcastro: I have to jump on a train at 14:00 my time, so my afternoon will be spent on 3G. :-P
<imbrandon> but no i did not say joel wants you to do it local, infact i said i would have it set up like he describes the tdd xp process
<SpamapS> imbrandon: no I didn't understand at all. :) I read it as "you must commit to run a test"
<imbrandon> sure but if you look at the contect that dosent mean its the final commit to the prod branch
<SpamapS> sure, I didn't think that either.
<lynxman> jcastro: I wasn't asked to review that one, send it my way if you fancy :)
<lynxman> jcastro: I only had sbuild
<imbrandon> then yes, you must commit to run a test unless you have a full abstracted local env
<jcastro> oh
<imbrandon> or your doing it wrong
<jcastro> lynxman, https://bugs.launchpad.net/charms/+bug/956259
<_mup_> Bug #956259: Charm needed: znc  <new-charm> <Juju Charms Collection:Fix Committed by patrick-hetu> < https://launchpad.net/bugs/956259 >
<jcastro> it should be pretty easy
<SpamapS> imbrandon: I support the idea of a CI server sitting around waiting for a commit to run tests on commit. However, if the full suite takes 5 minutes, it takes 5 minutes for me to find out that I mispelled "websrever"...
<jcastro> just tell me when and we'll promulgate it
<lynxman> jcastro: awwight
<imbrandon> bah thats just a bad setup then, it shoudl run on triggers
<SpamapS> imbrandon: whereas if I'm running just the tests I have just written, I can at least have a chance at getting the dumb things right before waiting 5 minutes for the full suite to fail.
<imbrandon> if you cannont garentee that the env is IDENTICAL to the variables in prod then the test is useless local
<SpamapS> imbrandon: we disagree fundamentally there then
<imbrandon> you have never had something work local and fail in production then
<SpamapS> I have
<SpamapS> many times
<SpamapS> not saying you shouldn't have a real test env between dev and production
<imbrandon> then your a gluten for pushishment , fix the porobme
<jcastro> SpamapS, imbrandon: hey so, go to pm so we can work, thanks!
<SpamapS> I'm saying that a lightweight local test suite *should* in fact prevent you from wasting time.
<jcastro> imbrandon, fix drupal, SpamapS, go promulgate. That will be all.
<SpamapS> jcastro: eat me, we're answering jml's question about how to create test environments w/ juju
<imbrandon> jcastro: ... this pertains to juju kthx
<jcastro> heh
<jml> mmmmhh, gluten, *drool*
<imbrandon> lol
<SpamapS> actually, no don't eat me. I am very high in fat. ;)
 * jml goes to get coffee and some kind of pastry with gluten in it
<SpamapS> jml: I have two options for you for setting up dev environments w/o compromising the production charm. buzz me when you're back.
<jml> SpamapS: will do.
<imbrandon> SpamapS: and i'm saying that that *way way* less than 5 minutes waiting for the test to fail is not counter productive, infact i spend more time opening the browser than it would take for the ci to grab it test it and notify me
<imbrandon> and garentees its a clean kill
<SpamapS> imbrandon: launchpad's test suite takes *hours* to run, even with the recent efforts to parallelize it.
<imbrandon> ok then in that case your not talking 5 minutes
<imbrandon> lets keep the same varibles here
<SpamapS> well I'm saying, 5 minutes is too long.. but many large systems would want to run the full many hours long test suite.
<imbrandon> if your running a test suite that takes hours then 5 muntes dont mater and you should NOT be doing it local
<imbrandon> exactly why you have a dedicated test evn
<imbrandon> as well as local
<SpamapS> imbrandon: when I do TDD.. I write a test, run to make sure it fails the way I expect it to, then write the code to make it pass. Its important that I not start writing the code until I see that fail.
<SpamapS> imbrandon: No, I just want to run *one test* ocally.
<SpamapS> locally even
<SpamapS> imbrandon: just for the iterative "prove to me that I have solved this one tiny problem" effect
<imbrandon> sure, but if you run the test and it fails local thats just a CURSORY test, it must fail in the env it was ment for to mean anything
<lynxman> jcastro: charm looks incomplete, giving some more feedback
 * jcastro nods
<lynxman> jcastro: jamespage was already reviewing it btw
<SpamapS> imbrandon: well, this gets into an unsettled theoretical area where we decide between unit tests, functional tests, and integration tests. :)
<imbrandon> SpamapS that and i gave the middle ground, i sugested deploy the charm local , that takes care of both really, run you one off i cant wait 5 minutes because i wrote a bad test or typos then push it to the ci server
<SpamapS> imbrandon: if its a unit test, then in theory, it is its own universe, isolated from all the integratino points of the environment. To be fair, for that one, you shouldn't need any special dependencies as jml was asking for. :)
<imbrandon> sure
<imbrandon> but thast not .... ugh you know we're talking about 5 diffrent things here
<imbrandon> :)
<SpamapS> imbrandon: anyway, I like where you're going with this actually, and juju can make this *super* easy.
<imbrandon> right
<imbrandon> and ensure that it matches
<imbrandon> :)
<jml> SpamapS: back
<SpamapS> so, w/ what jml was describing, we have a *great* use case for subordinates. You can have a subordinate "CI" charm which you deploy along w/ the code/app servers, which then gets down to the business of running the tests on commit from your dev server (config option for branch to watch I suppose)
<imbrandon> yea, i was thinking a config oiption since sub dont exist yet
<SpamapS> jml: ^^ option 1
<imbrandon> and making it all complicated
<jml> SpamapS: I don't quite know what subordinates are, but sure, that sounds good.
<SpamapS> jml: they are charms which don't serve a primary service purpose, and are always deployed along with primary charms. The key is they can relate to things via the filesystem.
<imbrandon> jml: charms have to each be their own "instance" right now, sub;'s let you have 2 or 3 or 6 charms on the same machine, like a nginx charm and a rails charm
<SpamapS> jml: the last branch or two for them is under heavy review right now
<SpamapS> imbrandon: to be clear though, you can't have more than 1 non-subordinate charm on one machine.
<jml> I guess these are for things like plugins, monitoring systems and the like?
<SpamapS> or, in juju-future-ese, on one "container"
<SpamapS> jml: thats the primary use case yes
<SpamapS> jml: also the idea that you could have a node.js charm and then the apps would be subordinates
<imbrandon> SpamapS_: ugh, what happens when i need apache + rails + myapp ? that suks
<SpamapS> imbrandon: rails and myapp would both be subs
<jml> SpamapS: oh, interesting.
<imbrandon> right , but you just said they cant
<SpamapS> subs have their own relations and everything, its really quite elegant
<imbrandon> or i misunderstood
<SpamapS> imbrandon: no, apache would be the primary
<jml> SpamapS: what's the other option?
<imbrandon> kk
<SpamapS> jml: the other option is, as imbrandon suggests, a config option, something like "dev=1"
<SpamapS> jml: that just brings in the things you need,
<jml> and then something in the charm that responds to the config change?
<SpamapS> err, that was a .
<SpamapS> jml: precisely
<imbrandon> yup, a good explination of that is on jcastro lastest post on cloud.ubuntu.com
<imbrandon> where phpmyadmin from upstream or the deb
<imbrandon> etc
<SpamapS> config-changed would do something like "if dev==1 then install testing tools vcs tools etc etc"
<marcoceppi> https://juju.ubuntu.com/docs/drafts/service-config.html
<jml> cool
<SpamapS> jml: the idea with juju is you would have the dev deploy as similar to the prod deploy as possible, just with less resources available to it.
<imbrandon> but local to lxc or maybe to a micro
<SpamapS> yeah, local so you can destroy your machine's performance, or t1.micro so you can wait a long long time. :)
<imbrandon> haha
<SpamapS> we do need to figure out if lxc-start-ephemeral can be used.. the shared VFS cache of overlayfs is a huge win.
 * SpamapS goes afk for a bit
<imbrandon> i was using it yesterday on the HPcloud boxes
<imbrandon> i provisioned a 16GB server and then made baby lx boxed
<imbrandon> SpamapS: so when you get back, what did you mean about the multi sub thing, i'm not quite sure i followed unless you just mean one needs to be the "master"
<imbrandon> if thats the case then i'll cheat and make a ubuntu jeos server charm and everything is a sub of that
<jamespage> lynxman, you are correct -  I had provided feedback but I don't think it had been implemented
 * jamespage reads
<jamespage> oh - it has - there was just a query over 'install'
<imbrandon> jcastro: btw drupal is done and it rocks, now just looking to add some of the cool options to it like marcoceppi demo'd at POSCON
<imbrandon> :)
<marcoceppi> imbrandon: it's got a few blockers in it, I'm in the middle of a review right now
<imbrandon> nice, let me know, i've very keen to add them to the drupal charm
<imbrandon> for like drush archive / upstream, drupal 6 or 7 archive, upstream or pressflow etc etc etc
<imbrandon> will make it very nice
<marcoceppi> I think phpMyAdmin is the only charm that uses an upstream switch, and it's a bit convoluted in that charm.
<marcoceppi> It'd be nice to get this hammered out, then just open a bug against the promulgated charm to add version switching support
<imbrandon> yea there are so many flavors of official drupal that it could benefit, have a sane default then the options
<marcoceppi> and merge in updates
<imbrandon> yup
<imbrandon> well not sure mine is prom yet, havent checked today
<imbrandon> not even sure if its been reviewd
 * imbrandon looks
<lynxman> jamespage: yeah, he's missing some other stuff though :)
<marcoceppi> imbrandon: it hasn't I'm reviewing it now
<jamespage> lynxman, I'll leave it in your capable hands then!
<imbrandon> oh nice ok
 * imbrandon goes to grab a mt dew then
<imbrandon> mmm caffeine :)
<imbrandon> marcoceppi: were we ( read: you ) gonna try and make the aws switch this evening still ? if so i'll make sure i'm around
<marcoceppi> I'm not sure, lets shake over to the other room
 * hazmat reads haxor news comments
<SpamapS> imbrandon: I *love* that idea ... the only thing I don't like about it is that I didn't come up with it.
<imbrandon> heh
<SpamapS> imbrandon: (re a primary "jeos" charm that everything else is a subordinate of)
<SpamapS> like, seriously, its the most brilliantly obvious solution to density that we all missed
 * SpamapS reserves the first gold star on his fresh sheet of gold/silver/green/red star stickers for imbrandon
<imbrandon> :)
 * imbrandon is happy 
<robbiew> lol
<jimbaker> SpamapS, this reminds me when i was at pycon about 5 or 6 years ago... and there was a teacher conference overlapping with us. one of the talks: using star stickers to motivate students
<SpamapS> jimbaker: it always worked for me :)
<jimbaker> :)
<shazzner> marcoceppi: ping
<marcoceppi> shazzner: pong
<shazzner> marcoceppi: hello :)
<shazzner> hey Marco, can you try running that parse_upstream php file?
<marcoceppi> shazzner: Yeah, it worked for me
<shazzner> huh
<shazzner> if I remove the https to just http it works swimingly
<shazzner> I have no idea, is there an import cert or something I have to call :/
<marcoceppi> Shouldn't be
<shazzner> hmm
<shazzner> what's odd, it seems to be only sourceforge, google https works fine
<shazzner> I'm probably going to leave it in for now, and just see if it's some weird configuration on my computer
<_mup_> juju/relation-ids-command r510 committed by jim.baker@canonical.com
<_mup_> Merged trunk
<marcoceppi> shazzner: http://paste.ubuntu.com/914797/
<marcoceppi> You'll want to make sure you update the project id at least :)
<shazzner> marcoceppi: I did :)
<marcoceppi> shazzner: for testing, if you're only doing local, you could just drop https for http
<marcoceppi> Though, it'll need to be https for the charm school
<shazzner> like this doesn't work for me: http://paste.ubuntu.com/914802/
<shazzner> pretend there is a <? in front
<marcoceppi> so weird. what does the php info for your setup look like?
<shazzner> good question, one sec
<shazzner> I know openssl is running
<shazzner> man I forget how big these things are: http://paste.ubuntu.com/914809/
<imbrandon> file_get_contents is off for remote calls by default
<imbrandon> marcoceppi:
<imbrandon> need to use curl
<marcoceppi> shazzner: try installing php-curl
<shazzner> k
<imbrandon> one sec
<marcoceppi> Though, that shouldn't affect it, since straight file_get_contents works
<imbrandon> http://paste.ubuntu.com/914812/
<imbrandon> i dunno some reason i cant see him talk, i'm only getting half the convo
<imbrandon> lol
<imbrandon> but there is a function i use in my classes to "replace" file_get_contents
<marcoceppi> right, that's fine, but it's working on my machine for https, not on his for https, both machines work fine for http
<imbrandon> hrm
<shazzner> yeah
<shazzner> php-curl, no help :/
<shazzner> according to the phpinfo I'm on openssl 1.0.1
<imbrandon> only thing i can think of is not having the ca's or somthing and it rejecting it, but the log should say that
<imbrandon> maybe see if the curl works anyhow
<marcoceppi> shazzner: weird, in the phpinfo for you check if you have this: Registered PHP Streams => https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
<shazzner> this is all it returns: http://paste.ubuntu.com/914821/
<imbrandon> and it bugs me i cant see him talking, wtf, jcastro noticed that with the subway client anywhere else ?
<shazzner> I can see you talking imbrandon
<marcoceppi> shazzner: check your phpinfo, it looks a bit was left out. There's a part at the top of the info that dumps out PHP Sterams and Registered Stream Socket Transports
<shazzner> marcoceppi: http://paste.ubuntu.com/914825/
<imbrandon> brb gonna get on irssi
<shazzner> marcoceppi: you're right I forgot to copy it :p
<shazzner> http://paste.ubuntu.com/914828/
<shazzner> imbrandon: can you hear me now? :)
<imbrandon> yea
<shazzner> yay :)
<imbrandon> finally
<imbrandon> no idea why now before
<imbrandon> i was on that new subway client though
<imbrandon> not*
<shazzner> huh
<marcoceppi> shazzner: So, the final thing I see is this: http://stackoverflow.com/questions/5498497/error-with-fsockopen-and-ssl-failed-to-enable-crypto
<marcoceppi> similar error, but it's due to firewall
<shazzner> huh
<marcoceppi> and this: http://gcov.php.net/viewer.php?version=PHP_5_3&func=tests&file=ext%2Fopenssl%2Ftests%2Fbug54992.phpt
<niemeyer> marcoceppi: heya
<niemeyer> marcoceppi: Do you happen to know if the wordpress+mysql pair is working in the charm store?
<marcoceppi> niemeyer: It is last we deployed, about 3 weeks ago
<niemeyer> marcoceppi: Awesome, thank hou
<niemeyer> you
<marcoceppi> Wordpress + HAProxy don't work though
<marcoceppi> in fact, I'm willing to wager a few of the applications won't work with HAProxy
<SpamapS> marcoceppi: it works, but not the way we want it to
<SpamapS> marcoceppi: everything I've promulgated works w/ haproxy
<SpamapS> marcoceppi: and wordpress did, at one time, work, but I think something got changed that broke the way it handled the Host: header
<marcoceppi> SpamapS: it didn't work when we deployed it, the WordPress charm is setup to listen to hostnames, and only the hostname of the unit. Since originating requests from haproxy are under a different hostname the wordpress box needs to be tweaked
<marcoceppi> SpamapS: right, should be fine when we start backporting the nginx configuration
<SpamapS> marcoceppi: there's a default too though, the default should have worked
<imbrandon> yea i'm sooo makin a patch for that
<krondor> I'm just excited to see the charms deployable without needing all of openstack or costs for ec2
<krondor> wops wrong window
<imbrandon> haproxy should pass the hostname though
<imbrandon> like we have nginx doing
<imbrandon> err we do now
<SpamapS> imbrandon: there's some logic in the haproxy charm to try and determine whether or not to turn on passing the hostname.
<imbrandon> but i'm still gonna work on a patch for wordpress , thats ludacris the way it does it, every other cms and framework in the world is smarter
<SpamapS> imbrandon: that still would not have mattered in the omg case because the backend services were expecting the external hostname.
<imbrandon> ahh
<marcoceppi> imbrandon: It's not a wordpress thing, it's WordPress multi-site from the archives
<imbrandon> marcoceppi: well wp does it too
<imbrandon> with the login
<marcoceppi> that's a different issue though, it's more a security thing
<marcoceppi> You can only post private data to the site_domain in the configuration
<imbrandon> nah, its misguaded secuirity
<marcoceppi> misguided, sure, but it's why it exists
<imbrandon> like how drupal handeles it
<imbrandon> yea
<imbrandon> but yea the normal one doe the host thing too, thast why i had yoy add
<imbrandon> that filter to the settings
<imbrandon> it removes that host header filter
<SpamapS> I think we need to add an 'endpoint-host' component to the http interface so that chains of servers can configure appropriately for the intended endpoint.
<SpamapS> like if you have nginx load balancer -> mod_security -> appservers .. need to know that the expected Host: is "mysite.com"
 * SpamapS rings the bell twice
<SpamapS> OpenERP promulgated!
<imbrandon> is there a way to make it an array ? i'm thinking about when i setup sites
<imbrandon> without juju i have 2 endpoints
<imbrandon> as i seperate the admin side
<imbrandon> most of the time
<SpamapS> imbrandon: sure, comma separated would work fine.. just have to think about that.
<imbrandon> hrm
<imbrandon> kk
<imbrandon> cuz its common for me to setup a drupal site but have domain.com/**/add domain.com/**/edit and domain.com/admin 403 via .htaccess and then another admin.domain.com vhost on the same box that restricts it to an ip subnet
<_mup_> txzookeeper/managed-watch-and-ephemeral r56 committed by kapil.foss@gmail.com
<_mup_> address review comments
<imbrandon> frak
<imbrandon> marcoceppi: i was looking over your comments and rember how i said i changed install quite a bit and you was like "huh?" for omg ? looking at your review and the file, i think i switched the install hooks for drupal and omg
<SpamapS> hazmat: hey, is there a way we can get access to have 'charm promulgate' make _mup_ talk for us?
<imbrandon> i bet if you look in the omg install hook it has git-core
<imbrandon> on the apt-get line
<SpamapS> hazmat: would be nice to have the bot do it :)
<marcoceppi> imbrandon: it doesn't
<imbrandon> i was working on both charms at the same time so ....
<imbrandon> ok
<imbrandon> good
<marcoceppi> the omg install hook is still all omg specific
<marcoceppi> and it works, because we re-deployed it recently
<imbrandon> ok good, then i just fubared one
<imbrandon> cuz i kjnow i changed all thois
<imbrandon> but no biggie
<imbrandon> there are other things you mentioned i needed to change anyghow
<imbrandon> ok , just wanted to make sure i dident screw the pooch really bad
<imbrandon> yea it would have worked
<imbrandon> but just had extra stuff
<imbrandon> like git-core installed etc
<marcoceppi> imbrandon: I review all the diffs for merges very carefully, that would have caught my eye
<imbrandon> rockin :)
<imbrandon> yea see i have the admin.* stuff in the drupal one, frak
<imbrandon> i def screwed something up here , /me checks git history
<imbrandon> btw did you ever add my key ?
<imbrandon> ugh yea and i had all the backup stuff replaced with backup-and-migrate ....
 * imbrandon rolls back git
<imbrandon> * Advisory ID: DRUPAL-SA-CONTRIB-2012-056
<imbrandon> erm wrong win
<imbrandon> SpamapS: oh yea i posted some more unholly acts of bash on my blog this morning, dunno if you read planet or not
<hazmat> SpamapS, yeah.. its trivial afaik the bzrcommit hook uses a fairly simple protocol.. but its a client side hook
<SpamapS> hazmat: thats fine, I want to bake it into charm-tools so that when somebody successfully runs 'charm promulgate' the bot informs #juju :)
<hazmat> which needs the creds distributed with it.. its basically just a message relay/send to mup
<SpamapS> ah, so the bot doesn't support openid? ;)
<imbrandon> SpamapS: heh i wasent the only one who said it "like osx brew on crack" comment on jcastro's latest blogpost :)
<imbrandon> marcoceppi: ok so i pushed the fixes for your review, do i put the bug back to needs-review or ? *me is excited to get in the store*
<marcoceppi> imbrandon: put the bug as fix committed
<imbrandon> k
<m_3_> jcastro: HN!  congrats!
<jcastro> thanks!
<m_3_> just catching up and saw that... awsesome
<imbrandon> you made HackerNews ?
<jcastro> :)
<imbrandon> nice
<jcastro> ... and clint just promulgated openerp.
<jcastro> another fine patrick hetu charm. o/
<jcastro> m_3_: SpamapS: marcoceppi you guys need to pick a winner
<imbrandon> SpamapS: realizticly how long before subs hit  ? before uds ?
<marcoceppi> jcastro: so many good ones
<jcastro> hazmat: does the doc generator sphinx thing only do RST? Or will it generate Markdown as well?
<hazmat> jcastro, rst only
<jcastro> generate from markdown I meant
<jcastro> dang.
<hazmat> jcastro, i'm mean its extensible.. and it can be done.. but its not the default, and likely requires an RT to do. http://stackoverflow.com/questions/2471804/using-sphinx-with-markdown-instead-of-rst
<hazmat> in this case it looks like it needs some dev
<jcastro> in other words. "deal with it Jorge"  :)
 * jcastro goes to fix the docs he broke
<marcoceppi> imbrandon: instead of rejecting it again, can you please add git-core to the install hook
<marcoceppi> imbrandon: instead of reading what I wrote, ignore me
<imbrandon> heh
<imbrandon> i was gonna say i did
<marcoceppi> when I did a pull it conflicted, didn't read the output carefully enough
<imbrandon> if there is anything else minor like that though lemme know :)
<imbrandon> np
<imbrandon> and ty for re-looking at it so fast :)
<imbrandon> sabdfl always has such well thought out blogposts, but i guess when you have as many eyes on you as he does you kinda have to
<jcastro> it ended up being something like 6k pageviews.
<imbrandon> 'nice
<jcastro> so still small potatoes, but at least people know what it is now
<jcastro> imbrandon: so what other hardcore stuff do you have other than drupal?
<imbrandon> jcastro: hrm nginx drupal advanced js and css server side optimzations
<imbrandon> build and deploy schemes
<imbrandon> hrm
<imbrandon> i really like build and deploy schemes
<jcastro> hmm so for all the nginx stuff we're likely waiting on subordinates right?
<imbrandon> yup
<jcastro> ok
<imbrandon> i was actauly thinking about just a website build server though
<imbrandon> not just jenkins
<imbrandon> etc
<imbrandon> one that runs thfough like the h5pb ant scripts and
<imbrandon> optipng
<imbrandon> and less
<imbrandon> scss, closure compilers
<imbrandon> etc
<marcoceppi> imbrandon: your upgrade-charm hook is broken
<imbrandon> doh. me looks
<marcoceppi> it fails in two places, if an upgrade charm is run prior to a db-relation being joined it fails, and even after a db-relation is joined if fails because it's looking for files/drupal instead of just drupal
<marcoceppi> It needs to make sure /var/www/drupal exists before it rsyncs, and also correct the source path
<imbrandon> hrm kk, qwick fix
<imbrandon> yea
<imbrandon> hrm
<imbrandon> then git will fail
<imbrandon> wtf
<marcoceppi> Just do if [ -d "/var/www/drupal" ]; then
<marcoceppi> in the upgrade charm hook
<imbrandon> k
<imbrandon> yea then next round
<imbrandon> it will come back if ...
<imbrandon> ok ok
<imbrandon> pushed
<imbrandon> err git pushed
<imbrandon> one sec
<imbrandon> k pushed
<imbrandon> well fuck , dient change the path
<imbrandon> i mean frak
<imbrandon> wait a minute, files drupal is right isnt it
<imbrandon> not just drupal
<imbrandon> oh no its not
<imbrandon> i have it on the outside
<marcoceppi> take your time
<imbrandon> i know, was just anoying
<imbrandon> ok i moved drupal into files/ that was the intent anyhow and its refrenced other places as in files/drupal
<imbrandon> and pushed
<imbrandon> oh nice , did not know a storm was comming, heard thunder and look outside and it s pitch black out
<imbrandon> WINTER IS COMMING
<jcastro> hazmat: it looks like the code generator thing IS set up for the docs is smart. I've been fixing the docs and then it just regens them, so I get the feeling it's more than just a daily cron job.
<SpamapS> imbrandon: subs are nearly here I think
<imbrandon> SpamapS: sweet
<SpamapS> jcastro: maybe its */15 instead of daily
<jcastro> yeah so anyway, docs being generated quickly, so none of us have excuses. :)
<imbrandon> jcastro: to better awnser what you was fishing for earlier , any part of the xAMP stack
 * imbrandon wants to see cgi perl wwwboards come back into fashion
<imbrandon> jcastro: i was thinking about a mysql ga 7.2 ndb cluster next , with those speedy joins
<imbrandon> dunno tho
<imbrandon> hrm MAAS isnt new, i was doing that 8 years ago when i worked in a datacenter, infact we had dedicated ports on each switch in the racks that would be on the pxe boot + reimage server + add configs badd ass network, i thought it was going to be more than that from Marks blog post
<hazmat> jcastro, cool might be hrly
 * imbrandon feels jipd
<hazmat> imbrandon, it basically wants to be that with an api.. but its also the foundation for bare metal deploys of juju
<imbrandon> seriously did i miss something major there
<robbiew> imbrandon: agree, the concept isn't new
<imbrandon> ahh k
<robbiew> but it's more than just pxe boot
<imbrandon> well yea base kickstart config
<imbrandon> or ubuntu preseed
<imbrandon> the api's will be intresting
<imbrandon> i dint see that part
<imbrandon> but at fisrt glance i was like ummm
<hazmat> its also pretty early for maas (really early actually), it will be interesting to see what it can evolve to
<imbrandon> definatly , esp since it will now have alot of attn
<imbrandon> that kinda thing has always been datacenter wizrdry
<jcastro> imbrandon: so you know the charms we've been writing. Doing a deploy would just have MAAS firing up bare metal boxes instead of EC2.
<jcastro> or in addition to, or both.
<robbiew> right
<imbrandon> yea , but thats a natural evolution , i mean i'm even kinda doing that now on my esx box heere at home minus a few shell scripts, the reall coolness will be to orcrstrate that via a charm
<imbrandon> with the api
<jcastro> yeah but you know how to do that
<jcastro> and bought ESX
<imbrandon> esx is free :)
<jcastro> we're talking about ootb part of the OS.
<imbrandon> yea true
<imbrandon> esx would make a fat charm on bare metal too
<imbrandon> since its free cuz it has not gui
<imbrandon> :_
<imbrandon> :)
<imbrandon> vsphere is what you pay for though jcastro , the gui part with all the goodies, the under pinning esx is free if you know what your doing
<imbrandon> like xenserver from citrix
<imbrandon> xen is free but not the othert citrix goodies
<imbrandon> and yea i forget sometimes that even tech ppl are as tech as us
<imbrandon> for the most part
<jcastro> imbrandon: let me put it this way as an example.
<jcastro> if I was at my old job and someone would have said "quick, we want to set up 250 blogs, one for each faculty member." I would have been doomed.
<jcastro> with all this it's a juju for loop
<imbrandon> arent*
<imbrandon> heh true, or one s/wordpress/drupal :)
<jcastro> heck, this is so easy I am wondering if I should get into the wordpress hosting business. :)
<imbrandon> but thats nother story :)
<imbrandon> hehe
<imbrandon> ahhaah
<imbrandon> you dont want to , wp upstream is a bitch
<imbrandon> start a saas host for drupal like getpantheon.com
<imbrandon> :)
<jcastro> hmmm so, with this load balancing nginx thing + subordinates
<jcastro> that's going to be pretty awesome
 * SpamapS has been happy with drupalgardens which drizzle.org switche dto recently
<imbrandon> my goal after uds is to convince getpanthon to use juju instead of their home grown drop scripts, they already are on rackspace, with like 350 instances or so
<imbrandon> thats 350 charms
<imbrandon> :)
<SpamapS> jcastro: yes, its going to be sexy.. every web app server will be a able to be a load balancer unto itself. :)
<marcoceppi> SpamapS: should there be a drizzle charm?
<SpamapS> marcoceppi: yes I've always wanted to write one
<imbrandon> SpamapS: yea smae exact think except david from pressflow runs pantheon and dries / acquia runs drupal gardens
<marcoceppi> SpamapS: after seeing your g+ post about the next release, I though it would a be a sweet charm to have
<imbrandon> exact same setup though, infact they share a codebase
<SpamapS> marcoceppi: totally, so many ports to expose/consume
<imbrandon> pantheon / drupal gardens
<SpamapS> marcoceppi: the HTTP+JSON thing is especially interesting I think
<imbrandon> the main diffrence between them is gardens is on AWS and Pantheon is on Rackspace
<imbrandon> thats about it
<SpamapS> marcoceppi: also the 0mq transaction poub/sub should be interesting.
<imbrandon> jcastro: yea like omg does now ;)
<imbrandon> jcastro: and the drupal charm :)
<imbrandon> mmmm node charm
<imbrandon> http + json ? /me perks up, whada i miss , reads backscrolll
<marcoceppi> SpamapS: it be interesting to see the charm dynamically open/close ports as relations to specific things are made
<marcoceppi> From my initial investigation there's a lot to be done to make the charm right by the Drizzle devs
<imbrandon> ohhhhhh pantheon isnt invite only now, gogo, get an account jcastro SpamapS marcoceppi , that is the most perfect workflow for small teams using drupal
 * imbrandon ran outa invites the other day to send
<SpamapS> imbrandon: Drizzle has a plugin now that listens for HTTP requests and responds w/ JSON of rows read.
<imbrandon> nice
<imbrandon> wow
<imbrandon> really nice
 * imbrandon wants
<imbrandon> man this suck tho
<imbrandon> mysql proper added memcache api , the other dudes added socket handler
<imbrandon> and now this
<imbrandon> wtf
<imbrandon> if they would all 3 combine and omg
<SpamapS> imbrandon: I believe the memcache thing is in drizzle too
<imbrandon> sweet
<imbrandon> thats the two i would use, not so much socket handler
<SpamapS> imbrandon: drizzle's model of having an actual, working, efficient plugin architecture is really the main reason to use it.
<SpamapS> imbrandon: I maintain handlersocket in Debian. Its not the most awesome thing. ;)
<SpamapS> has to be built inside the mysql source tree
<imbrandon> i wonder if they have the upstream enhacements from 7.2 for the joins
<SpamapS> imbrandon: thats NBD only
<imbrandon> doh
<SpamapS> imbrandon: 5.5 has some join optimizer stuff.. but I don't know if Drizzle has those.
<imbrandon> thats drupals bigest downfall, have tyou seen some of the crazy joins it does
<SpamapS> Drizzle was forked from "MySQL 6.0", so it might have had it already. (6.0 became 5.5, minus some things like Falcon)
<imbrandon> ahh
<imbrandon> i breefly looked at it , kinda like mariadb then brished it off
<imbrandon> percona was all i really looked at lately
<imbrandon> i should probably look em all over again
<SpamapS> imbrandon: Percona is MySQL + stuff. MariaDB is MySQL + way more stuff. Drizzle is a true fork.
<imbrandon> oh and you have to deal with handeler socket / mysql et al packing, my hats off to you, its like the apache guyes
<imbrandon> heh
<SpamapS> Drizzle was the result of the frustrations of quite a few people with long standing crapiness in MySQL.
<imbrandon> yea with the orig maintainer etc
<SpamapS> It was "we're not going to make money with this for many years to come, so lets rip out all the old broken code"
<SpamapS> No, Montye Widenius was not involved with Drizzle
<imbrandon> percona is mostly xtradb engine, maria is stolen xtradb + configs
<SpamapS> he started MariaDB
<imbrandon> :)
<imbrandon> ahh i had him backwards then
<imbrandon> thought he was with drizzel not maria
<imbrandon> dident that curt dude from canonical go work for maria
<imbrandon> the canook
<imbrandon> heh
<imbrandon> curt vonfink or something like that, he worked as helpdesk i think, cant ever rember but he was funny as hell
<imbrandon> wow, i'm so installing this now
<imbrandon> i was actually looking at nodejs servers that did just that
<imbrandon> grabbed rows and spit json out
<imbrandon> saves a nodejs server running
<SpamapS> imbrandon: yeah he did
<SpamapS> ok, afk for a bit
<imbrandon> k
<imbrandon> i want to recreate the pantheon service in a charm ( probably with lots of subs )
<imbrandon> seriously like a clone of it, i bet it can be done as they use the same thing in house written scripts on rackspace instnces
<imbrandon> only free and in the store
<ajmitch> imbrandon: so now that you've sort of talked me into juju, I should look at how I can use it for work :)
 * ajmitch can at least set up things with fabric at the moment
<imbrandon> yea
<imbrandon> dude fab is nince
<imbrandon> juju makes fab projects talk to each other though
<imbrandon> ajmitch: i thouth you did php at work, and u use fab ?
<ajmitch> imbrandon: doesn't mean I like PHP :)
<imbrandon> jcastro: btw look who i dragged into the jujubee jamboree wont be long and we'll have all the oldskoolers :)
<imbrandon> ajmitch: hahaha true
<ajmitch> imbrandon: I've been lurking in here for some time
<imbrandon> i knw i knw i seen ya the first day i came, but i got a bit ego :)
<imbrandon> big*
<imbrandon> seriously though ajmitch i just noticed pantheon opened up drops to everyone
<imbrandon> should grab one if nothing else to check out the workflow
<ajmitch> the charm store is interesting, in a way it's an admission that packaging a lot of the bits that people want to use is a bit of a failure :)
<imbrandon> kinda, but some will still want the stability of pkgs, its like having cake left when ya eat it
<marcoceppi> ajmitch: not so much that the packaging is a failure, more that it takes more than just a package to configure a full service
<imbrandon> heh you get the stability of a base system and the package you care about are a rolling release
<ajmitch> marcoceppi: when it comes to fast-moving things like node.js it's hard to keep up on the distro side
<imbrandon> i think of it like selective rolling releases kinda
<ajmitch> imbrandon: right, which is a useful model to have
<marcoceppi> ajmitch: oh absolutely, in that case the nodejs charm makes use of the ppa or the upstream repo
<imbrandon> as long as it is selective too and not everyting is installed that way
<ajmitch> though in saying that, I see that someone uploaded node.js 0.6 to precise a couple of days ago, I'd thought it was far too late for a change of that size :)
<imbrandon> i mean its mnore to it, but you know, the package side thats how i think of it
<imbrandon> ajmitch: do you really use fab at work though and not like phing ?
<ajmitch> I really use fab at work, honest
<imbrandon> nice, i could have never talked my last employer into that
<imbrandon> infact my whole job was to rid the palce of alll python starting with django apps
<imbrandon> heh
<adam_g> how does juju determine which amazon AMI to use if no default-image-id has been specified in environments.yaml?
<imbrandon> it likely defaults to aws default then of a m1small
<imbrandon> i would guess
<imbrandon> with a amazon distro
<adam_g> imbrandon: juju does some magic to find an appropriate ubuntu cloud image to launch  given the ec2 region
<imbrandon> ahh
<SpamapS> adam_g: https://cloud-images.ubuntu.com/query
 * SpamapS is so far behind on email, don't know if hazmat +1'd the latest iteration on the cert checking code
<shazzner> marcoceppi: hey Marco, I tried the same file_get_contents on my laptop and it worked fine
<marcoceppi> shazzner: must be something on your local then
<shazzner> it's running 11.10, I'm on precise beta
<marcoceppi> oh, fascinating. Let me try that on my precise laptop
<shazzner> yeah could be a bug
<shazzner> I disabled the ufw, which didn't help :p
<marcoceppi> shazzner: looks like it, file_get_contents to any https address from my laptop fail
<shazzner> ah ha!
<shazzner> finally, I'm not the cause of a bug :p :p
<marcoceppi> shazzner: actually, it works for some https addresses and not others
<shazzner> yeah I noticed that, works with google and some others
<shazzner> weird
<marcoceppi> it must be a cert issue
<shazzner> huh
<marcoceppi> I would put that as a big "todo" for when the charms move to precise. A better method of rss parsing will need to be put in place
<marcoceppi> maybe using pything instead of php
<shazzner> using urllib?
<marcoceppi> sure, or whatever
 * marcoceppi not much of a python guy
 * shazzner me either!
<shazzner> also php and bash :p
<marcoceppi> yes! take that SpamapS
<jcastro> m_3 on juju: http://www.youtube.com/watch?v=0iFVvOPcm8g&html5=True
<jcastro> we gotta get that dude a razor
<marcoceppi> haha, yeah. It's gotten unruly over the last 6 months
<ajmitch> marcoceppi: python is the one true way, embrace it while you can
<marcoceppi> ajmitch: slowly I've been seeing the light with python
<shazzner> yep, python works like a charm
<shazzner> w00t
<shazzner> I'm going to _try_ to rewrite that parse_upstream in python
<marcoceppi> feel free! if you get it to work let me know and I'll port it in to the phpmyadmin charm
<shazzner> wow that php2python site is a godsend
<SpamapS> I'm down with php.. :)
<SpamapS> yeah you know me
<SpamapS> who's down with PHP?
<shazzner> openssl broke for php
<m_3_> jcastro: razors are for sissies
<shazzner> not sure why or how, but python seems to work
<SpamapS> I triaged a pretty nasty bug where servers using some implementation would fool php into thinking they were SSL3 but they weren't so fail would spew forth in full glory
<jcastro> http://www.youtube.com/watch?v=3QGDQ2RTLMU
<m_3_> jcastro: the devopsdays ones are recorded too, but you have to sorta search through quite a bit to get to the panel
<jcastro> hah, before and after
<shazzner> speaking of which, I should probably file a bug for that issue
<shazzner> even though it's probably a fault with sourceforge
 * shazzner hates sourceforge
<SpamapS> https://bugs.php.net/bug.php?id=52106
<m_3_> jcastro: what can I say... I'm a looker
<SpamapS> shazzner: perhaps that one?
<shazzner> SpammapS: yep that's the one
<shazzner> huh
#juju 2012-04-05
<hazmat> SpamapS, i thought it was going to have the default config written out with ssl check enabled
<SpamapS> hazmat: the branch I had proposed does that
<hazmat> SpamapS, not the version in reitveld afaics
<hazmat> https://codereview.appspot.com/5934054/
<hazmat> SpamapS, besides that LGTM
<SpamapS> hazmat: https://codereview.appspot.com/5934054/patch/11001/12003
<_mup_> juju/relation-id-option r521 committed by jim.baker@canonical.com
<_mup_> Fix setup of local api factory used by testing
<_mup_> juju/relation-id-option r522 committed by jim.baker@canonical.com
<_mup_> Remove usage of invoker attr in favor of using the factory to get it
<_mup_> juju/relation-id-option r523 committed by jim.baker@canonical.com
<_mup_> Code rearrangement
<_mup_> juju/relation-ids-command r511 committed by jim.baker@canonical.com
<_mup_> relation-ids command without a relation name to qualify returns all relation ids
<_mup_> juju/relation-id-option r524 committed by jim.baker@canonical.com
<_mup_> Merged upstream & resolved conflict due to moving relation-ids command tests to upstream
<_mup_> juju/relation-hook-context r526 committed by jim.baker@canonical.com
<_mup_> Merged trunk for this already merged branch to workaround lbox prereq issue
<_mup_> juju/relation-ids-command r512 committed by jim.baker@canonical.com
<_mup_> Change test setup to verify that relation-ids on a relation name does in fact only return those relation ids
<_mup_> juju/relation-id-option r525 committed by jim.baker@canonical.com
<_mup_> Merged upstream
<_mup_> juju/relation-ids-command r513 committed by jim.baker@canonical.com
<_mup_> Test relation ident enumeration from nonrelational hook context and departed relation hook context
<_mup_> juju/relation-id-option r526 committed by jim.baker@canonical.com
<_mup_> Merged upstream
<lynxman> if someone can promote charm attached to bug #956259 looks alright :)
<_mup_> Bug #956259: Charm needed: znc  <new-charm> <Juju Charms Collection:Fix Committed by lynxman> < https://launchpad.net/bugs/956259 >
<SpamapS> lynxman: you're not in ~charmers ?
<lynxman> SpamapS: yeah, so how can I promote it myself? :)
<SpamapS> lynxman: bzr push lp:~charmers/charms/oneiric/znc/trunk && charm promulgate
<lynxman> SpamapS: cool, thanks
<res0nat0r> /loa/clear
<res0nat0r> oops
<shazzner> ok
<shazzner> I (poorly) rewrote the parse_upstream php file into python
<SpamapS> shazzner: eh?
<imbrandon> heh why ? j/k
<shazzner> http://paste.ubuntu.com/915662/
<shazzner> well
<shazzner> mostly to do with how it's broken in precise
<imbrandon> :)
<SpamapS> oh the https
<shazzner> ya
<SpamapS> wget's not broken.. just wget the damn thing ;)
<imbrandon> i'm actully converting SpamapS's python for the multi nginx stuff to php now
<shazzner> I wish!
<shazzner> haha
<SpamapS> imbrandon: hater
<imbrandon> started it like 15 min ago
<imbrandon> lol
<imbrandon> SpamapS: hehe , well i wanted it all to match
<imbrandon> e.g. all the othersgonna be php
<SpamapS> imbrandon: I'd like for that to all be generic as soon as subordinates land
<imbrandon> nothing against your implmentation though
<SpamapS> imbrandon: shouldn't need to all be one language
<imbrandon> no, it dont, its a prefrence thing
<SpamapS> imbrandon: but I'm actually glad to see non-python/bash charm hooks :)
<imbrandon> just being anal
<imbrandon> :)
<SpamapS> I always figured ruby would be more prevalent.. not .. php
<imbrandon> i'm trying to figure out the best way to do the most in php thought, since its not installed by default i have to bash bootstrap it minimum
<imbrandon> i'm sure rubys and gems and diimonds and poneies will be next :)
<SpamapS> imbrandon: I want to create a more declarative way to pull in packages at some point to handle this case
<imbrandon> yea thats would be cool
<shazzner> I just want to say xml handling is so much easier than python
<shazzner> *in php I mean
<SpamapS> imbrandon: I'd like for there to be a way to write a charm that is 99% just lists of packages/files to install.
<imbrandon> i duno about 99% then its just a deb :)
<imbrandon> deb + rules file thats not debuild'd
<SpamapS> shazzner: seems like you're iterating when you could have done xpath
<imbrandon> SpamapS: but i agree, more than now would be nice
<shazzner> SpamapS: I have no doubt I did it poorly :p
<SpamapS> imbrandon: the 1% would be the bits that run on hook changes.
<imbrandon> ahh ok
<imbrandon> then yea i;'m right with ya
<SpamapS> so maybe 90%
<shazzner> if you have suggestions or changes, please go for it
<SpamapS> Like, let me write the code only when code is warranted.
<imbrandon> right
<imbrandon> yea i just equated that in my head as more, but yea, i fully agree then
<imbrandon> but yea , its nothing against your implmentation, infact its quite simple and easy to understand even for a python newb but i'm just being picky
<imbrandon> is all :)
<SpamapS> The reason I've gravitated to python away from other languages has been that the code is usually easy to understand (except when its twisted based ;)
<imbrandon> btw i got importing from github going i think, its not imported yet but its in the queue for RSN
<imbrandon> yea i've just stayed away from it since the rules seem like they were written by rms
<imbrandon> heh and really i havent stayed away just try not to use it when not nessesary
<imbrandon> lol
 * SpamapS will like github when celery tastes like candy
<imbrandon> hahaah
<shazzner> hehe
<imbrandon> btw they did a huge upgrade to the issue tracker this week
<SpamapS> urllib2.URLError: <urlopen error [Errno 104] Connection reset by peer>
<imbrandon> might peek at it again
<SpamapS> shazzner: thats what I get
<shazzner> huh
<imbrandon> milestones and proraties and stuff
<shazzner> haha it seems like the same issue php had
 * imbrandon slides off to find some nicoteine and finish bootstrapping drupal 8 into a working state
<imbrandon> semi afk
<imbrandon> btw morning fellas 0/ :)
<SpamapS> imbrandon: 'bout to be sleep for me
<imbrandon> ahh
<shazzner> SpamapS: are you behind a proxy perhaps?
<SpamapS> shazzner: definitely not
<shazzner> same here, it's like 3am
<shazzner> err huh
 * imbrandon just woke up, i keep odd hours for most, its 3am here too
<SpamapS> shazzner: have you tried with openssl s_client
<SpamapS> I think their servers may just suck
<shazzner> probably
<SpamapS> probably out of entropy
<imbrandon> where ya grabbin it from ?
<SpamapS> openssl s_client -host sourceforge.net -port 443
<SpamapS> stalls out
<shazzner> I ran that script several times testing it though, all consistant
<imbrandon> nice
<shazzner> hrm
<SpamapS> telnet to that host/port also stalls
<SpamapS> shazzner: sure, you used up all their entropy ;)
<shazzner> damnit! sorry guys
<imbrandon> use lp to import  the sf repo and then grab from there ;)
<SpamapS> actually
<SpamapS> this is likely an openssl issue
<SpamapS> on a centos 6 box, no issue, connects right up
<imbrandon> i'll try from osx one sec
<imbrandon> yea right up here
<shazzner> yeah that openssl line stalls for me too
<imbrandon> http://paste.ubuntu.com/915676/
<SpamapS>     Protocol  : TLSv1
<shazzner> imbrandon: same result
<shazzner> actually wait, mines a little different
<imbrandon> mines from osx so it might be a bit diffrent
<shazzner> ah
<SpamapS> wtf
<imbrandon> http://paste.ubuntu.com/915676/
<SpamapS> I think I accidentally /quit there or something
<bkerensa> SpamapS: you lost terminal
<bkerensa> :D
<imbrandon> heh says lost term
<imbrandon> 03:06 -!- SpamapS [~clint@ubuntu/member/spamaps] has quit [Quit: Lost terminal]
<bkerensa> SpamapS: How is contest coming along ? :P
<shazzner> http://paste.ubuntu.com/915679/
<SpamapS> Yeah must have torched byobu accidentally
<SpamapS> bkerensa: wrapping up judging this week :)
<bkerensa> :P
<shazzner> I use guake and have move between tabs be ctrl-left & right and close tabs ctrl-down
<SpamapS> RC4-SHA
<SpamapS> I wonder if Ubuntu's openssl has that disabled
<shazzner> I've closed my irc session many times :/
<shazzner> the channel topic should probably change too :p
 * imbrandon gave up OPer when lilo passed, no haxoring the topic from me
<SpamapS> aha
<SpamapS> RC4 is in fact disabled
<imbrandon> nice
<SpamapS> if you explicitly request it
<SpamapS> it works
<SpamapS> *thank you ubuntu security team for making sure we are safe*
<SpamapS> and sourceforge.. I spit on your RC4
<imbrandon> heh
<SpamapS> shazzner: so your PHP implementation will probably work fine, if you add some options
<shazzner> oh yeah?
<SpamapS> http://www.php.net/manual/en/context.ssl.php
<SpamapS> specifically, 'ciphers'
<SpamapS> I would set it to AES256-SHA,RC4-SHA
<imbrandon> if google glass is not a april fools joke i'm so getting some
<shazzner> yeah those look pretty rad
<shazzner> SpamapS: I'll take a look at that, thanks!
<shazzner> I'm off to bed though, have do to taxes tomorrow :(
<shazzner> night ya'll
<SpamapS> ugh yeah I have to wrap my taxes up this week too :-P
<SpamapS> what a lovely thought to go to sleep to
 * SpamapS passes out
<res0nat0r> Any guess why I can't test out and deploy the cassandra charm? I see it in the repo https://code.launchpad.net/~charmers/charms/oneiric/cassandra/trunk-1
<res0nat0r> I'm getting a not found
<yolanda> hi, good morning
<yolanda> i'm having a problem running juju in a local container in precise
<yolanda> error: internal error Network is already in use by interface virbr0
<arashbm> yolanda: just re login and it will be solved!
<yolanda> hi, yes, i rebooted and works
<yolanda> hi, another question. In what directory should i put my local.yaml file with config settings? i tried to put it under the precise/ directory of the repo and gives an error
<niemeyer> Good morning jujuers!
<TheMue> niemeyer: morning
<niemeyer> TheMue: Good morning!
<yolanda> hi
<hazmat> g'morning folks
<yolanda> i have this problem when trying to get content from a private repo:
<yolanda> W: Failed to fetch https://private-ppa.launchpad.net/canonical-isd-hackers/ppa/ubuntu/dists/precise/main/binary-i386/Packages  Proxy CONNECT aborted
<yolanda> i'm using local containers
<yolanda> in my local machine works, but juju local container gives that error
<yolanda> any clue?
<koolhead11> yolanda, your running your machine behind a proxy
<yolanda> no, i didn't add any config for that. Locally i can get that repo without problems
<yolanda> but when i create a juju local machine, it gives that error
<hazmat> yolanda, juju setups the local containers for an apt cacher ng proxy on the host
<yolanda> hazmat, how can i solve the problem?
<hazmat> yolanda, you may have to adjust the cacher-ng proxy settings on the host
<yolanda> hazmat, where can i check it?
<hazmat> yolanda, its in /etc/apt-cacher-ng   its got a web page for its stats at http://localhost:3142/acng-report.html
<hazmat> yolanda, do you have that ppa enabled on the host?
<yolanda> hazmat, but in my local machine i can access the repo, the problem is on the juju instance
<yolanda> and in the juju instance i cannot see any apt-cacher-ng directory when i debug
<hazmat> yolanda, the apt-cacher-ng stuff is on the host not the container
<hazmat> the containers are all configured to point to it
<hazmat> yolanda, so you trying to add a ppa and install a package from it in the container in a charm hook?
<hazmat> yolanda, the private ppa has some form of auth.. it sounds like that it causing a problem with proxy.. but if thats not adding ppa auth to the container, or config to the proxy i don't know
<yolanda> hazmat, i added the right user and pass to the sources.list
<yolanda> perhaps is some problem with https?
<hazmat> yolanda, could you pastebin anything relevant from the cacher-ng logs at /var/log/apt-cacher-ng on the host
<yolanda> let me check
<yolanda> hazmat, i cannot see any content about this ppa in logs
<koolhead11> jcastro, hi there
<jcastro> hi
<koolhead11> let me know how can i help with juju doc :)
<koolhead11> i think i did do some changes with the doc and its waiting 4 approaval
<yolanda> hazmat, i'm totally lost with that problem, what else can i check?
<jcastro> koolhead11: that was your one before the docs were split out
<jcastro> everything is integrated now
<hazmat> yolanda, you could try turning up the logging in apt-cacher-ng (VeboseLogging=1), the errors should be here. /var/log/apt-cacher-ng/apt-cacher.err
<koolhead11> jcastro, as in all documenation related stuff is handled?
<hazmat> yolanda, er.. VerboseLog=1
<hazmat> yolanda, or email the list, i'm not that familiar with apt-cacher-ng.. or if it supports https
<hazmat> koolhead11, all the docs are in a separate repo so they don't have to wait in the code merge queue, and there's a larger group that has direct access.
<hazmat> lp:juju/docs
<koolhead11> hazmat, yes saw the ail in mailinglist :)
<hazmat> cool
<yolanda> let me check
<yolanda> hazmat, i enable log, but still any clue about canonical, i see some logs there, but nothing related to that entry
<SpamapS> imbrandon: OpenSSL problem identified btw.
<marcoceppi> SpamapS: what was it?
<SpamapS> bug #965371
<_mup_> Bug #965371: HTTPS requests fail on some sites on Ubuntu 12.04 <rls-p-tracking> <OpenSSL:Confirmed> <openssl (Ubuntu):Triaged by cjwatson> <openssl (Ubuntu Precise):Triaged by cjwatson> <openssl (Debian):New> < https://launchpad.net/bugs/965371 >
<SpamapS> fixed in the latest openssl
<SpamapS> has to do with the size of the initial handshake packet
<marcoceppi> awesome
<SpamapS> so, dist-upgrade people!
<SpamapS> was fixed on Friday
<imbrandon> :)
<jcastro> SpamapS: marcoceppi: m_3_ charm contest, let's finish it </kombat>
<marcoceppi> jcastro: might as well, still waiting on s3cmd
<jcastro> http://pad.ubuntu.com/charmcontest
<jcastro> SpamapS: ^ those are the entrants afaict who are eligible. Confirm pls.
<jcastro> oh, gitolite
<jcastro> https://bugs.launchpad.net/charms/+bug/906176
<_mup_> Bug #906176: Gitolite charm <new-charm> <Juju Charms Collection:Fix Committed by shazzner> < https://launchpad.net/bugs/906176 >
<jcastro> we need to finish this review
<jcastro> ditto for drupal
<jcastro> https://bugs.launchpad.net/charms/+bug/964936
<_mup_> Bug #964936: Drupal Charm: superchared Drupal charm with nginx,, apc, php-fpm, all setup to scale to the moon and be Best Practices. <new-charm> <Juju Charms Collection:Fix Committed by imbrandon> < https://launchpad.net/bugs/964936 >
<SpamapS> jcastro: dunno if you saw, but lynxman promulgated znc last night
<jcastro> yep, on the list
<jcastro> SpamapS: so I'm thinking, check these two, promulgate or kickback, and then decide?
<marcoceppi> Drupal hasn't been promulgated yet, still needs a finaly review
<jcastro> http://pad.ubuntu.com/charmcontest <-- am I missing anyone?
<jcastro> I left out myself, marco, and nick's charms that promulgated or where finished during the period
<bkerensa> jcastro: thanks for the shipment
<bkerensa> :D
<bkerensa> I assume you had Cezz send the UPS thingy
<jcastro> I didn't send you anything yet
<bkerensa> -.-
<bkerensa> jcastro: no?
<jcastro> nope, I'm not mailing out the prizes until tomorrow
<bkerensa> uhh well I didnt order anything and Merchandise Mania is shipping me something
<bkerensa> so hmm
<bkerensa> LOL
<bkerensa> wth
<jcastro> stealth swag
<_mup_> juju/relation-id-option r527 committed by jim.baker@canonical.com
<_mup_> Addressed minors
<bkerensa> jcastro: indeed
<bkerensa> jcastro: lol its from Mozilla :D they use Merchandise Mania too
<marcoceppi> Are there any instructions or documentation on possibly adding a provider to juju?
<zul> SpamapS: hold on http://paste.ubuntu.com/916240/
<jcastro> dude: "authorized-keys: chuck"
<jcastro> you can do that?
<zul> jcastro: according to the docs you can
<zul> but that might be the problem
<aiurea> hi
<aiurea> I have a quick question. Is support for Debian & Redhat in the Juju Roadmap?
<bkerensa> aiurea: good question.... I think jcastro might be able to answer that
<aiurea> bkerensa: I'm a Debian developer starting a new project and I would love to use juju. And I could contribute afterwards. But I would like to know that support for RedHat/Debian is incoming.
<bkerensa> aiurea: If for some reason you have to go and dont get a answer before you leave feel free to ping the Cloud mailing list to get a answer
<bkerensa> https://lists.ubuntu.com/mailman/listinfo/Ubuntu-cloud
<aiurea> bkerensa: thank you.
<marcoceppi> aiurea: bkerensa juju mailing list works well too: https://lists.ubuntu.com/mailman/listinfo/juju
<aiurea> marcoceppi: got it.
<bkerensa> marcoceppi: ok :)
 * bkerensa is interest to know the answer to aiurea's question since I hope to talk about juju in the futurew
<marcoceppi> From what I understand, and I might be wrong, juju client should be able to run on any linux system. The charms are all apt-get specific so outside of aptitude they won't deploy. Theoretically you could deploy to Debian images in say ec2 but I don't think anyone has tried. As for Redhat while the client might run I think yum is missing a few vital packages that would be required for redhat images
<marcoceppi> to run
<marcoceppi> So it's a giant maybe. I don't know if the dev team has any plans to support other systems and if they do when they would be doing that
<zul> SpamapS: http://paste.ubuntu.com/916313/
<aiurea> I see.
<SpamapS> zul: that means zookeeper failed to start
<SpamapS> zul: check console log
<zul> k
 * SpamapS puts $5 on "Hash sum mismatch"
<zul> SpamapS: last line is this: http://paste.ubuntu.com/916321/
<SpamapS> zul: that means juju failed to install. Look up higher.
<zul> SpamapS: wha....it tried to fetch from the ec2 archive: http://paste.ubuntu.com/916324/
<SpamapS> zul: whats 'nov.ec2' ?
<SpamapS> zul: is that some kind of weird thing that cloud-init is doing because the "region" is nov?
<zul> SpamapS: im not exactly sure
<marcoceppi> SpamapS: getting a wall of "[  183.541157] 1 multicall(s) failed: cpu 0" when bootstrapping a t1.micro, is that Amazon's gentle way of saying NO CPU FOR YOU?
<SpamapS> marcoceppi: never seen that
<SpamapS> marcoceppi: what region?
<marcoceppi> eu-west-1
<marcoceppi> The last several micros I've tried to boostrap in eu-west-1 and us-east-1 have failed
<marcoceppi> this is just the first time I've actually checked the logs
<SpamapS> java bug.. very sad. ;)
<SpamapS> jimbaker: did I see relation id support land this morning?
<jimbaker> SpamapS, yes you did
<jimbaker> SpamapS, definitely a nice feature - charms can now work with relations from any hook
<marcoceppi> jimbaker: wait, what?
<jimbaker> marcoceppi, you can list available relation ids using the new relation-ids command
<jimbaker> then use -r <relation id> with relation-get|relation-set|relation-list
<marcoceppi> Ah, so you can get, set, and list relation data from any hook now?
<jimbaker> marcoceppi, correct
<marcoceppi> epic
<SpamapS> truly epic
<SpamapS> you can ripple an event through the system now
 * SpamapS goes to get lunch
<avoine> awesome
<jimbaker> SpamapS, yes, this is a very nice aspect of what has landed - generalizing the orchestration
<jimbaker> with ultimately just a very simple addition of functionality
<bkerensa> SpamapS: I think the next charm I am going to write is for openphoto
<jcastro> wow, I didn't even know that existed
<jcastro> bkerensa: if you want you can file a wishlist bug on lp under "charms" and link the home page there
<jcastro> so we have it
<bkerensa> jcastro: I will do... I am joining the openphoto team as a Community Manager
<bkerensa> :P
<bkerensa> so it naturally makes sense
<jcastro> <3
<SpamapS> bkerensa: *sweeeeet*
<SpamapS> bkerensa: btw, when you're done w/ that charm, I'll definitely +1 you for ~charmers (and I bet somebody else will too)
<bkerensa> heh
<bkerensa> :D
<lifeless> SpamapS: oh hai
<_mup_> Bug #974650 was filed: relation-ids should default to $JUJU_RELATION, or if not available, raise an error <juju:In Progress> < https://launchpad.net/bugs/974650 >
<lifeless> SpamapS: maybe you know the answer to my question in #ubuntu-cloud ?
<shazzner> yay taxes are done! :D
<SpamapS> shazzner: did you see above, the openssl issue is solved in the latest package in precise?
<shazzner> Spamaps: no I didn't, let me give it a shot
<SpamapS> shazzner: something to do with broken BigIP's
<shazzner> huh
<shazzner> does that python script work for you now?
<shazzner> I'm still getting the ssl timeout with the php parse_upstream script
<shazzner> unless, this is something totally different
<SpamapS> shazzner: I lost the python script.. (/tmp .. rebooted.. ;)
<SpamapS> shazzner: but openssl s_client works now
<SpamapS> shazzner: the error 104 would be different
<shazzner> here it is in all it's glory!: http://paste.ubuntu.com/916729/
<shazzner> so when I call juju-log
<shazzner> where exactly does it log it to?
<SpamapS> shazzner: the charm.log
<SpamapS> shazzner: which is visible via 'debug-log'
<SpamapS> shazzner: or on disk, as /var/lib/juju/units/xxx-#/charm.log
<SpamapS> shazzner: or if you're using the local provider, data-dir/units/xxx-#/unit.log
<shazzner> SpamapS: got it, thanks! :)
<shazzner> hmm ok, so the root of the matter is I added a bin/parse_upstream.py file along with my charm
<shazzner> when I try to call it, it can't seem to find it
<shazzner> I'm basing this off the phpmyadmin charm, which seems to be correct but it keeps failing there
<shazzner> what would be the absolute path to the charm on the machine?
<shazzner> oh wait I think I found it
<shazzner> same path as the charm.log
<SpamapS> python /tmp/foo.py
<SpamapS> http://sourceforge.net/projects/kusabax/files/Kusaba%20X%200.9.3/Kusaba%20X%200.9.3%20Full/kusabax_0.9.3_full.zip/download|fbd051a3b0c3ddd9d08e56309b4f2e23
<SpamapS> shazzner: yep, works now
<shazzner> yay! :)
<SpamapS> shazzner: don't assume that path
<SpamapS> shazzner: your charm will always start executing in the root of the charm
<shazzner> yeah I was noticing that
<SpamapS> shazzner: $CHARM_DIR will always be set to that dir
<shazzner> hrm
<SpamapS> those are two assumptions you can make
<shazzner> it fails here: HASHFILE=`bin/parse_upstream.py` with /var/lib/juju/units/kusabax-0/charm/hooks/install: 20: local: not in a function
<shazzner> it's probably something stupid on my end
<SpamapS> thats a syntax error
<SpamapS> local is only allowed in functions
<shazzner> oh
<shazzner> like I said, something stupid :p
<SpamapS> because she'll scope for non-functions is always global :-P
<shazzner> got it
#juju 2012-04-06
<shazzner> alright, updated the kusabax charm
<shazzner> should include all of marco's suggestions in it now
<marcoceppi> shazzner: nice!
<shazzner> marcoceppi: I changed the php parse_upstream file to python, feel free change it I'm no python expert :p
<marcoceppi> shazzner: neither am I, I'll take a look later tonight or in the morning
<shazzner> awesome thanks bro
<_mup_> juju/managed-zk-client r511 committed by kapil.thangavelu@canonical.com
<_mup_> use managed client for state tests
<imbrandon> happy friday everyone
<_mup_> juju/trunk r516 committed by kapil.thangavelu@canonical.com
<_mup_> [trivial] test suite should run without requiring any ec2 env vars, also fix a status test failure [r=clint-fewbar]
<_mup_> juju/managed-zk-client r512 committed by kapil.thangavelu@canonical.com
<_mup_> more managed client test usage
<_mup_> juju/namespace-from-env r476 committed by kapil.thangavelu@canonical.com
<_mup_> merge trunk
<shazzner-away> updated Gitolite charm
<cr3> roadmr and I just invented jujutsu; martial art in the cloud
<cr3> our moves are also called charms, like the wordpress charm is a crouching hand stand
<cr3> there are also combination of moves, like the hadoop charm is a combination of map position and reduce position
<cr3> step aside kungfu, move away karate, jujutsu kicks ass!
<_mup_> juju/log-juju-origin r513 committed by kapil.thangavelu@canonical.com
<_mup_> log juju-origin when bootstrapping
<_mup_> juju/trunk r517 committed by kapil.thangavelu@canonical.com
<_mup_> [trivial] log juju-origin when bootstrapping
<SpamapS> cr3: https://launchpad.net/juju-jitsu :)
<cr3> SpamapS: I hate the internet, everything was invented already :(
<SpamapS> lol
<dotty451> I'm having some trouble with juju and ssh keys
<dotty451> $ juju status
<dotty451> 2012-04-06 16:10:42,985 INFO Connecting to environment.
<dotty451> 2012-04-06 16:10:43,195 ERROR Invalid SSH key
<dotty451> Cannot connect to machine MTMyNzM3MTAyOS40NzczODQ0MjAuNzMxMDk (perhaps still initializing): Invalid SSH key
<dotty451> 2012-04-06 16:10:43,202 ERROR Cannot connect to machine MTMyNzM3MTAyOS40NzczODQ0MjAuNzMxMDk (perhaps still initializing): Invalid SSH key
<dotty451> I've created an ssh key in ~/.ssh/id_rsa
<dotty451> and copied it to the remote host's .ssh/autorized_keys for the ubuntu user
<SpamapS> dotty451: did you reboot the machine after you did the 'bootstrap' ?
<dotty451> the server?
<SpamapS> dotty451: juju copies the key after it installs the OS
<SpamapS> dotty451: juju wants to own the machine from install onward
<SpamapS> dotty451: so it tells cobbler to set it up for re-install on the next reboot
<dotty451> so i need to re-pxe boot the clients?
<SpamapS> dotty451: then on the reboot, juju installs the version of Ubuntu you asked for, and itself, and installs your keys
<SpamapS> dotty451: if you manually pxe'booted them before juju bootstrap, then yes
<_mup_> juju/must-specify-relation-name r515 committed by jim.baker@canonical.com
<_mup_> relation-ids without an arg defaults to ; raises error if unset
<_mup_> juju/ns-from-env r478 committed by kapil.thangavelu@canonical.com
<_mup_> move infer defaults extraction to helper func
<dotty451> SpamapS: I re-installed my clients and it now errors out with a different error
<dotty451> 2012-04-06 17:06:46,511 INFO Connecting to environment.
<dotty451> 2012-04-06 17:06:46,787 ERROR SSH forwarding error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
<dotty451> it seems doing that did not re-install it
<dotty451> instal the keys properly, that is
<dotty451> $ juju ssh 0
<dotty451> 2012-04-06 17:13:06,322 INFO Connecting to environment.
<dotty451> 2012-04-06 17:13:06,503 ERROR Invalid SSH key
<dotty451> Cannot connect to machine MTMyNzM3MTAyOS40NzczODQ0MjAuNzMxMDk (perhaps still initializing): Invalid SSH key
<dotty451> 2012-04-06 17:13:06,511 ERROR Cannot connect to machine MTMyNzM3MTAyOS40NzczODQ0MjAuNzMxMDk (perhaps still initializing): Invalid SSH key
<dotty451> however, sshing manually with the key in .ssh/id_rsa works fine
<bkerensa> marcoceppi: how is progress on contest review? :)
<marcoceppi> bkerensa: You guys didn't make it easy for us!
<marcoceppi> Lots of great submission
<marcoceppi> s
<bkerensa> marcoceppi: :P so perhaps next week?
<marcoceppi> Oh, bug jcastro for a timeline
<bkerensa> marcoceppi: I thought you were the boss not jcastro :)
 * bkerensa jokes
<marcoceppi> :D
#juju 2012-04-07
<imbrandon> hazmat: when you get a few minutes i
<imbrandon> 'd like to pick your brain on what it will take to add a hpcloud provider
<hazmat> imbrandon, greetings
<hazmat> imbrandon, it wouldn't take much.. the compute api should work with juju via its ec2 compatiblity, we just need a place to store a few files per s3 compatiblity, right now compute and storage is composed as a single provider config.   There are lots of options, separate out storage and compute within a provider, allow the provider to provide its own storage on top of compute, expose an s3 api to hpc's storage layer.
<al-maisan> If I can have a number of environments in ~/.juju/environments.yaml -- how do I tell juju which one should be used e.g. when running a 'juju deploy' command
<al-maisan> ?
<al-maisan> ah, http://askubuntu.com/questions/65364/how-can-i-configure-multiple-deployment-environments-for-juju
<al-maisan> I went through the mysql/wordpress example and have a question: even after a 'juju unexpose wordpress' command the wordpress site continues to be visible and usable in the browser -- is that how it should be?
<al-maisan> If yes, what is the purpose of the 'unexpose' command?
<hazmat> al-maisan,  -e env name
<hazmat> al-maisan, expose/unexpose only work for ec2
<hazmat> al-maisan, we need to start using machine level firewalls instead of provider capabilities to implement that functionality
<hazmat> currently it relies on provider capabilities and is limited to ec2
<al-maisan> ah, I see, thanks!
<hazmat> al-maisan, re environment selection, you can also define a default: env_name in environments.yaml.. and you can also specify it via JUJU_ENV  env var
<al-maisan> That's very nice, thanks. I would imagine the question about environments would be a FAQ :-)
<al-maisan> The FAQs also state "If you need a custom AMI you can specify it in the environments.yaml file" .. is this documented somewhere or is there an example of this?
<koolhead17> al-maisan, its there is juju doc i suppose, not in FAQ
 * al-maisan looks
<hazmat> al-maisan, we kinda of want to avoid people using those.. we have it right now mostly to support private clouds, where we don't have good introspection into the available images
<hazmat> al-maisan, right now a charm determines the distro series etc, when people use ami-id, it basically breaks that notion..
<al-maisan> hmm .. I see .. good to know
<hazmat> al-maisan, there's a few new features that are underdocumented, after we get our next upload done, a focus for the team will be on improving docs
<al-maisan> cool
<hazmat> specifically i'm thinking of the constraints functionality (select a machine based on capabilities) and the subordinate charms
<hazmat> as far as poorly documented features
<hazmat> contributions welcome! bzr branch lp:juju/docs :-)
<al-maisan> re. custom AMIs .. there is the case to be made for systems like ours (a lot of additional software needs to be downloaded and installed on top of the plain ubuntu server AMI)
<al-maisan> hazmat: re. documentation .. thanks for the pointer .. will add stuff as I discover it :-)
<al-maisan> hazmat: going back to the custom AMI: in such cases it would be advantageous to use custom AMIs in order to reduce time/cost of deployment IMHO
<hazmat> al-maisan, shaving a minute seems like a petty cost
<hazmat> vs the cost of maintenance
<hazmat> or functional mismatch against the series that a charm was written for
<al-maisan> That's a fair point.
<hazmat> al-maisan, we default to using the daily cloud build of any given series on ec2
<al-maisan> I see.
<hazmat> ie. its already up to date
<al-maisan> gotcha
<al-maisan> hmm .. it's been a while .. how does one push a branch that should be stacked on lp:juju/docs ?
<al-maisan> OK .. got it the "Merge into:" target needs to be lp:juju/docs
<SpamapS> hazmat: we do not use the daily cloud build!
<SpamapS> hazmat: we use the released build
<hazmat> SpamapS, oh..
<SpamapS> so fo precise we'll use beta2
<SpamapS> for even
<hazmat> SpamapS, you ever debug cloud-init?
<SpamapS> hazmat: would be a nice thing to be able to influence the query process with some parameters like 'daily'
<hazmat> SpamapS, i've got the lxc cloud images working, but cloud-init refuses to run the cloud-config parts
<SpamapS> hazmat: I have in the past..
<hazmat> SpamapS, that capability is present, but perhaps we're not using it
<hazmat> SpamapS, its kinda of a mess in there, i've traced through the code, but debugging the absence of working isn't proving fruitful
<hazmat> re ^ cloudinit
<hazmat> Its picking up the right user-data just not doing anything with it
<SpamapS> hazmat: we use the same mechanism in orchestra...
<SpamapS> and I presume maas
<hazmat> SpamapS, indeed, maas has its own datasource
<hazmat> i guess it will wait till post weekend and rendevous with smoser
<SpamapS> hazmat: but what about the orchestra data source?
<hazmat> SpamapS, dunno i assume it used the nocloud source
<hazmat> juju stuffed it into KSMETA as  USER_DATA_BASE64
<hazmat> SpamapS, what do you think of a jitsu cli command to front instead of wrapping
<hazmat> juju
 * hazmat wanders of into django land
<koolhead17> hi all
<zirpu> does juju support running more than 1 service per vm instance?
<koolhead17> zirpu, currently no
<lazyPower> My google fu is failing me. Can someone point me to a good reference for the complete beginner looking to make a charm?
<marcoceppi> lazyPower: https://juju.ubuntu.com/CharmSchool that and just poking at the examples and current charms is how I got started
<marcoceppi> https://juju.ubuntu.com/Charms
<marcoceppi> lazyPower: Actually, this is a pretty good starting point: https://juju.ubuntu.com/docs/write-charm.html
<marcoceppi> Although a bit outdated in some pars
<al-maisan> hazmat: thanks for the review, shall I merge the changes to trunk?
<hazmat> al-maisan, sure.. give me a moment, i need to adjust the permissions
<marcoceppi> shazzner: the python looks good for parse_upstream
<hazmat> al-maisan, you should be able to merge it now
 * al-maisan tries
<al-maisan> hazmat: it worked, thanks again!
<hazmat> al-maisan, thank you :-)
<al-maisan> :-)
<al-maisan> ttyl
<lazyPower> marcoceppi: Thanks! exactly what I was looking for.
#juju 2012-04-08
<shazzner> marcoceppi: hey Marco, thanks for looking at the python script :)
<marcoceppi> shazzner: I actually finished the review
<shazzner> oh sweet
<marcoceppi> there are a few minor things that I'll open a bug report for, but otherwise it looks good
<shazzner> ok cool
<marcoceppi> shazzner: can you promulgate yet?
 * marcoceppi has no idea who has the powers
<shazzner> I have no idea haha
<marcoceppi> Ah, doesn't appear so. I'll promulgate it for you in a few mins
<shazzner> cool. first let me look up what that word means :p
<marcoceppi> promulgate in this sense means "make it an official charm"
<shazzner> ah sweet
<cjuner> Hi, one quick question: For testing purposes I setup a local environment and successfully deployed owncloud. Now, after rebooting the system, how do I get the environment back up?
<shazzner> cjuner: unfortunately local environments don't persist between reboots :(
<shazzner> cjuner: you'll have to destroy-environment and re-bootstrap and deploy
<cjuner> Ok, I suspected as much. Is that being worked on or rather a wontfix?
<shazzner> not sure, it's filed as a bug though for sure
<cjuner> Might one get something like that running with maas?
<cjuner> ,
<shazzner> you can deploy to a maas 'instance'
<shazzner> check this page: https://wiki.ubuntu.com/ServerTeam/MAAS
<cjuner> Hm seems like too much of a hassle than trying it out just for the fun of it right now. Thanks anyway.
<cjuner> I was kind of looking forward on deploying all my installations on one (single) personal server with juju. But that use case does not seem very much supported at the moment.
#juju 2013-04-01
<jcastro> utlemming_bip: when you submit it to the store, can you call it firefox-sync and not fsync?
<jcastro> utlemming_bip: also you didn't subscribe ~charmers, that's why it wasn't in the queue, fixed.
<mfisch> m_3: finally fixed the tracks charm, after much wrestling with juju on lxc... there's a MR incoming
<m_3> mfisch: awesome!
<mfisch> m_3: this weekend and last I had issues with my cloud provider as well, so this took forever
<m_3> mfisch: totally understand... my life has become wrestling with various providers :)
<mfisch> m_3: I also cannot get local juju to work, I was getting segfaults in some of the lxc commands
<m_3> mfisch: raring lxc is broken I think
<mfisch> m_3: okay, glad it's not just me
<m_3> mfisch: precise should probably be fine
<m_3> ok, food
<m_3> biab
<sarnold> yeah, last week raring lxc juju was completely useless; precise lxc juju worked fine. I think a fix / workaround is known for lxc, not sure if it is in the archive yet or not..
<m_3> ok, so update-alternatives works... mgz will be back from vacation tomorrow and review/cleanup lp:~mark-mims/+junk/pyju-packaging-with-alternatives
#juju 2013-04-02
<AskUbuntu_> relation error between nova-compute and nova cloud controller | http://askubuntu.com/q/277139
<jcastro> m_3: so I hear you nailed -alternatives?
<m_3> jcastro: yeah, it's working great... I want martin to take a look and then figure out what to do with the changelog and other official stuff to get it merged
<mgz> jcastro: will want some testing, but looks reasonable
<m_3> he might have a beter way to do it too
<m_3> :)
<m_3> mgz: only tested it on raring btw
<m_3> mgz: welcome back!
<mgz> well, we'll only do this for raring, so that much is fine
<m_3> hope you had a decent long weekend
 * m_3 wants one next weekend I think
<mgz> m_3: was good, still have sis and baby niece around today as well
<m_3> cool
<jcastro> wow, the room for the OpenStack Charm Workshop holds like 320 people.
<m_3> no way
<jcastro> m_3: we'll have wired internet this time!
<m_3> cool
<jcastro> way.
<m_3> oh, awesome
<m_3> jcastro: I really still wanna combine #juju and #juju-dev
<m_3> I don't think developer-speak will drive people away from the channel
<jcastro> I agree, but mramm didn't want to change anything until at least 13.04+
<jcastro> I can appreciate his concern, with the deadlines looming, etc.
<m_3> yeah, understand
<m_3> just looking towards the future ;)
<jcastro> yeah, after that we just need to move cheney to the us
<jcastro> and we'll be good
 * m_3 is still holding out for an australian sprint
<m_3> harumph
 * m_3 coffee
<Carletto> hi all
<jcastro> arosales: charmworld guys are asking for confirmation on something
<jcastro> arosales: the new terminology is "reviewed" and then everything else right?
<jcastro> we're not doing "Community" and all those other labels iirc?
<arosales> jcastro: correct "reviewed" is how I remember it for charms being in the charm store, and then nothing else for all others.
<arosales> and correct, no "community" label
<Carletto> someone Italian?
<SpamapS> jcastro: still searching the archives, but I didn't see that term discussed on the mailing list.. :-P
<jcastro> yeah I am just waiting for some UI thing to bring it up on the list
<jcastro> SpamapS: I am also going to start publishing notes from each weekly call, etc.
<jcastro> and probably recording them and putting them on youtube
<SpamapS> jcastro: and inviting the "community" ?
<jcastro> yeah
<SpamapS> I mean, not that I'll have time to attend
<SpamapS> but its the thought that counts ;)
<jcastro> somehow the weekly call turned private, not on purpose
<jcastro> we used to do them with like brandon and marco etc.
<SpamapS> yeah I remember :)
 * m_3 lunch
 * marcoceppi lunch
<sidnei> SpamapS: heya, still owning the packaging for charm-tools? had to fix a couple things to for the packaging to work with tip of lp:charm-tools, missing some build-deps mainly.
<sidnei> well, and a billion pep8 errors on raring, due to the newer pep8, but im still going through those.
<fss> hi everyone
<fss> I'm having some troubles with zookeeper in one of our juju installation :-(
<fss> zookeeper is eating all the available memory in one bootstrap machine, while in the other environment it uses less than 400MB of RAM. Both environments have about the same number of machines
<fss> has anyone had this problem before?
<andrewsmedina> hi
<benji> fss: I haven't heard anything like that.  Have the two environments existed for the same length of time?  Have the two bootstrap nodes been up for the same amount of time?  I'm wondering if there is a leak somewhere.
<hazmat> fss, can you check that debug-log is off
<hazmat> fss, http://paste.ubuntu.com/5671415/
<hazmat> fss, debug log left on can fill up space in quickly
<hazmat> fss, out of curiosity how many machines in the env?
<fss> hazmat: hmm, I see. thanks for the script. I will turn it off.
<hazmat> fss, that script turns off the log entries but does not clear out the used space
<fss> hazmat: does "juju debug-log" clears it?
<fss> s/clears/clear/
<fss> hazmat: about 10 running machines, but we create and destroy very frequently
<fss> the machine "counter" is on 554
<hazmat> fss, it does not
<fss> hazmat: how can I clean it?
<hazmat> fss, the logs are nodes in /logs
<hazmat> fss, if you can check/verify that's the issue, i can add a flag to that off script to clear it
<fss> hazmat: how can I inspect /logs on nodes? I'm a zookeeper noob :)
<hazmat> fss ssh into bootstrap node and run /usr/share/zookeeper/bin/zkCli.sh   and then $ ls /logs
<fss> hazmat: thanks
<hazmat> fss,  hmm. actually $ get /logs should show the child count as part of the parent node properties without having to count the individual files
<hazmat> there's also not much by way of garbage collection on older state/nodes (ie destroyed services / machines)
<hazmat> but those are typically tiny.. under 1k each
<fss> hazmat: good, because I'm not able to ls /logs, I get "connection loss" error. it's probably out of memory error again
<fss> here's the get output
<fss> numChildren = 684745
<hazmat> yikes..
<fss> (if I increase xmx I would possible be able to fix it, but it's already 1GB)
<sidnei> :)
<hazmat> zk only allows for 1mb packet size to the client by default, trying to do more than that will get that reconnection loss
<hazmat> er connection loss
 * hazmat ponders
<fss> hazmat: I see
<fss> hazmat: what's the proper way to cleanup these log entries?
<hazmat> there isn't a proper tool for it. its a bug.  deleting the nodes under /logs would do it.. but if you can't get the node names..
<fss> S:
<fss> :S
<sidnei> maybe you can infer the node names to purge from the !active ones
<hazmat> i think its a sequence
<hazmat> so should be able to iterate on delete commands to the seuqence
<fss> is it possible to increase that 1MB packet size limit?
<hazmat> fss, yes, but it needs recompilation
<fss> oh boy
<hazmat> fss, got a solution, but in meeting, will need 30m to code up
<fss> hazmat: oh, thanks. I can wait. I will keep trying something else
<hazmat> fss, --reset option to kill the logs.. http://paste.ubuntu.com/5671870/
<hazmat> oh.. he's gone.
 * hazmat emails
<sidnei> hazmat: was about to say. :) also does that delete all the logs unconditionally?
<hazmat> sidnei, it does
<hazmat> sidnei, honestly storing logs in zk is particularly bad..
<hazmat> juju-core i think is setting up syslog as remote target
<sidnei> yeah, no idea how it works. just wondering if that will break something else
<hazmat> sidnei, the logs still exist on disk everywhere
<sidnei> yup, i saw the commit for using syslog passing by
<hazmat> sidnei, yeah.. just updated the script.. to reset the parent block pointer to update the last seen index for the cli tool
<hazmat> in this version, also emailed out http://paste.ubuntu.com/5671892/
<sidnei> ah, cool
<sidnei> m_3: ping! https://code.launchpad.net/~ubuntuone-pqm-team/ubuntu/raring/charm-tools/raring/+merge/156710 https://code.launchpad.net/~ubuntuone-pqm-team/charm-tools/trunk/+merge/156709
<sidnei> successfully built at https://code.launchpad.net/~ubuntuone-pqm-team/+recipe/charm-tools-daily
<m_3> sidnei: hey
<m_3> sidnei: I don't have permission to push to that cause it's distro I guess
<m_3> sidnei: lemme see what the difference it
<m_3> is
<m_3> we might have to submit them against lp:charm-tools first... not sure
<m_3> -vs- lp:ubuntu/charm-tools
<sidnei> m_3: the latter is the packaging branch (the debian/* stuff), the former is the 'upstream' branch
<m_3> sidnei: yeah, just found the right ones... the initial MPs linked to the ubuntu one
<m_3> lemme merge
<sidnei> cool
<m_3> sidnei: do you have permissions to push to the packaging branch?
<m_3> sidnei: the changes are approved, but I can't push to that one
<sidnei> m_3: i don't. maybe SpamapS?
<m_3> clint's the only one that I know of
<m_3> we can probably get somebody to sponsor it, but it might take a bit
<m_3> SpamapS: https://code.launchpad.net/~ubuntuone-pqm-team/ubuntu/raring/charm-tools/raring/+merge/156710
<SpamapS> m_3: about to step out for the day, don't think I'll be able to get to it until tomorrow
<sidnei> tomorrow is fine thanks!
<m_3> SpamapS: np, thanks man
<andrewsmedina> hazmat: its need reboot the zookeeper after delete logs?
<hazmat> andrewsmedina, the purgeTxnLogs cron job (from the zk pkg) should get run. but afaik .. no restart
<m_3> sidnei: lp:charm-tools is updated... it'll start passing again once the packaging updates land
<hazmat> i don't know how aggressive it is about releasing memory.. probably some jvm tuning
<m_3> sidnei: thanks btw!
<hazmat> its not keeping additional versions in memory, it is keeping them on disk in the txn logs which is why the purge script is useful
<sidnei> m_3: thank you!
<fss> i'm back
<fss> hazmat: i saw your email when I was in the bus, thanks for the help! :)
<fss> hazmat: I will take a look tomorrow, it's on vpc, I can't access it from home. I could use an elastic ip, but we have a temporary solution, it can wait
<sidnei> fss, andrewsmedina: did you guys ever try jitsu import/export, and do you have the need for it or something similar to it in tsuru?
<fss> sidnei: nope, we never tried it. Actually, I don't know what it does. Is it used for exporting and importing environments between cloud providers?
<sidnei> fss: roughly yes. im looking for something that can take (charms, configs, relations, constraints, number of units) and either build a complete environment from scratch or update an already-running one.
<sidnei> jitsu import does handle the 'from scratch' part, but im not sure it handles updating an existing environment to match the import file, hazmat?
<andrewsmedina>     content, stat = client.get("/logs")
<fss> sidnei: that would be cool
<andrewsmedina> exceptions.TypeError: iteration over non-sequence
<hazmat> sidnei, it can be imported into an existing non-conflicting env (conflicts detected and aborted)
<hazmat> whoops
<hazmat> andrewdeane, add a yield to before client
<hazmat> 'yield'
<andrewsmedina> hazmat: ok
<hazmat> actually hold on.. i should check the rest of that script
<hazmat> andrewsmedina, fixed version http://paste.ubuntu.com/5672062/
<andrewsmedina> hazmat: it works :)
<hazmat> andrewsmedina, it doesn't...
<fss> andrewsmedina: \o/
<andrewsmedina> hazmat: its removing 685132 logs :p
 * fss zzzzzzz
<hazmat> andrewsmedina, not without the second version.. its not waiting on the op completion.. so its issuing a bunch of deletes without waiting on the results..
<andrewsmedina> hazmat: I added the yield
<hazmat> it should still clear out some stuff, and its not harmful.. but you should run the second version
<hazmat> andrewsmedina, there where a few yields missing.. diff to that second pastebin
<hazmat> but that should clear out the memory
<hazmat> don't forget to clear out the txn logs
<hazmat> if your close to disk full
<sidnei> hazmat: yeah, looking at the source seems like it's pretty specific, and would depend on pyjuju
<hazmat> sidnei, yeah.. i've got on my task/todo list to update juju-deployer2 for juju-core.. as the openstack deploys are using it instead of import/export jitsu style
<hazmat> its much closer to pure cli usage so should work with both
<sidnei> hazmat: is there a juju-deployer2 already? :)
<hazmat> with the advent of the juju-core api publicly things like that should be easier
<hazmat> what import/export are doing that is
<hazmat> sidnei, not yet.. was waiting on maas provider for jcore
<hazmat> else its non-urgent/fun task
<sidnei> hazmat: i got it very high on my list to rewrite juju-deployer with tests
<hazmat> sidnei, when you say update existing env.. what do you mean?
<hazmat> like change config, change charm versions.. change charm origins?
<hazmat> ie more of a sync than import
<sidnei> hazmat: yes, something along these lines. with an eye towards service-swap (deploy charm as service-1; on sync deploy charm as service-2 and move relation from service-1 to service-2)
<hazmat> sidnei, with both s-1 and s-2 defined in the state file ?
<sidnei> hazmat: haven't got to that part yet, but i think nope. it would be defined as 'service' in the state file, the versioning would be a flag.
<sidnei> maybe sync --rolling-swap=service or something
<sidnei> or maybe it's defined as a policy in the state file, and it's always done as a rolling swap whenever there are changes to 'service' to be synced
<hazmat> fss, andrewsmedina you guys good?
<hazmat> sidnei, not really seeing that.. cause else it could just be a charm upgrade away
<hazmat> sidnei, else why throw away state.. ie. what if its a db
<fss> hazmat: I think so
<hazmat> fss, memory usage down?
<sidnei> hazmat: what if you need to change constraints? move from m1.small to m1.large? or can that be done just by setting constraints on an existing service and add/remove nodes?
<fss> hazmat: andrewsmedina is running the script, looks like the memory usage drop 1/3 (from about 1G to about 650M)
<hazmat> fss, excellent
<hazmat> sidnei, you can do that on ec2 without killing things..
<hazmat> sidnei, stop, modify instance attr, start..
<hazmat> i mean there always a place for rolling.. with canaries.. esp for image deploys..
<hazmat> but there are other ways to skin that cat
<fss> hazmat: thank you :-)
<sidnei> hazmat: yeah, i think canaries is actually what im after
<sidnei> hazmat: can you expand on other ways to skin that cat? :)
<sidnei> (dinner will check backlog later)
 * hazmat does the same
#juju 2013-04-03
<Guest65596> how does one install and use the python helpers in charm-tools? I see a charm-helper-sh package but no python equivalent.
<benji> You can install them into your system python like so: sudo apt-get install python-charmhelpers
<sidnei> benji: except you need to add the ppa first
<benji> ooh, indeed
<benji> Which is ppa:charmers/charm-helpers, right?
<sidnei> there's a recipe to build into the juju ppa https://code.launchpad.net/~juju/+recipe/charm-tools but it's broken atm
<sidnei> i've been trying to fix that, but seems a bit more complicated than i thought
<sidnei> i *think* that https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/charm-tools/quantal is correct, just missing pep8 in build-deps
<mgz> any of these pyjuju test failures ring a bell for anyone? http://pastebin.ubuntu.com/5673475/
<sidnei> whereas https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/charm-tools/raring r18 looks like it reverted some of the previous changes
<sidnei> mgz: no idea about that, maybe a change in lxc? could you help with the charm-tools packaging issue above?
<mgz> probably just a missing builddep?
<sidnei> mgz: yes, missing pep8 apparently. but the raring branch looks like it removed python-charmhelpers accidentally on r18
<mgz> ...which is what you said :
<mgz> there doesn't seem to be a raring build anyway
<mgz> I can probably fix this stuff up
<wedgwood> benji: I don't see a python-charmhelpers package in that ppa
<sidnei> that would be awesome. i had a stab at fixing it before realizing that r18 on the raring branch https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/charm-tools/raring/+activereviews and then got pointed at bzr split documentation and lost all interest :)
<benji> wedgwood: hmm, it may be ppa:juju/pkgs and the package name may be just charm-tools; I'm looking into it real quick
<wedgwood> benji: looks like charm-tools exists in raring, it just doesn't include the python stuff
<benji> wedgwood: yep, it seems to be ppa:juju/pkgs and the package name is python-charmhelpers
<sidnei> http://goo.gl/DuHzm ?
<sidnei> i suspect it got unpublished with the latest recipe failure
<jcastro> http://juju.ubuntu.com/survey is live!
<SpamapS> jcastro: bummer you guys couldn't do the survey using open source like the last one ;)
<jcastro> oh the limesurvey?
<jcastro> you can't make me use bad tools. :p
<SpamapS> jcastro: how is it bad?
<SpamapS> like seriously
<SpamapS> Its *at least* as powerful as surveymonkey
<mgz> well, surveymonkey is bad, so I guess that's not saying much
<m_3> mgz: thanks, I realized last night I didn't have perms to push to lp:ubuntu/charm-tools
<mgz> m_3: we can bug someone with the right superpowers to do it though
<mgz> and the recipe build can just come out of a branch under ~juju
<mgz> I'm nearly there with the various packaging fixup pain
<m_3> mgz: and yes those tests look familiar... I put 'export DEB_BUILD_OPTIONS=nocheck' into ~/.pbuilderrc to focus on the packaging... /me guilty look
<mgz> :)
<mgz> and I got a different set of failures on the buildds... at least the tests pass when run in branch, and the build I cared about worked
<m_3> bummer... I hate chasing inconsistencies
<koolhead17> SpamapS, hi
<SpamapS> koolhead17: howdy!
<koolhead17> SpamapS, am good.
<jcastro> m_3: good thing you waited to fix your blog, now you get 50% lower prices on aws!
<SpamapS> my AWS bill has dropped consistently over the 2 years I've run a t1.micro for fewbar.com .. I think its $13/month .. and thats including about 800MB of backups going to S3 weekly.
<SpamapS> (my hpcloud bill is $17/month for my minecraft server) :)
<sidnei> jcastro: so this wsgi charm... how different from say the gunicorn charm that is?
<jcastro> sidnei: I was just announcing it, m_3 is the one to talk to
<jcastro> m_3: ^
<m_3> jcastro: I don't pay anything for it... it's just github pages
<m_3> sidnei: it'd definitely overlap... I just wanted to file it as a separate bug to open the conversation about _which_ webserver is the most commonly used for microframeworks plugged into wsgi
<sidnei> i don't think there's a definitive answer for that, although gunicorn is quite popular
<mgz> m_3: so, I think I've now done all the boring bits (bar some posts to the mailing list)
<m_3> sidnei: ack... that's ok
<m_3> mgz: whoohoo!
<mgz> m_3: what's up next is merging in your update-alternatives work to the packaging branch, testing it, and getting it in raring
<m_3> mgz: thanks man, I wanted a sanity check on those
<m_3> mgz: do I have to do something specific to the changelog?  that's why I didn't do a real MP before
<mgz> we'll add something, but that's pretty simple
<m_3> do we leave it alone at 0.6-1ubuntu2 iirc?
<m_3> or bump
<m_3> coo
<m_3> l
<mgz> I've bumped to 0.7-0ubuntu1
<mgz> and want to do the install changes on a new version as they're pretty major, so 0.7-0ubuntu2
<m_3> mgz: ack
<sidnei> m_3: im looking for a solution to using wedgwood_away's lp:charmsupport on the apache/squid/haproxy charms. i think the best option might be to include the package in the same ppa as charm-tools and add the ppa in the install hook.
<sidnei> as opposed to having a separate ppa that is
<m_3> sidnei: hmmmm
<m_3> sidnei: will that cause problems with the juju version installed
<m_3> sidnei: i.e., if they deployed orig from the distro version of juju
<sidnei> m_3: meaning charm-tools is in the juju ppa? i thought it had its own ppa
<m_3> sidnei: then, the charm adds that ppa, then something during the life of that service updates/upgrades
<m_3> oh, nope, I thought it was the same as juju.... /me looking now
<m_3> sidnei: https://launchpad.net/~juju/+archive/pkgs
<m_3> all together
<sidnei> looks like also https://launchpad.net/~charmers/+archive/charm-helpers
 * m_3 facepalm
<sidnei> an alternative might be to just move all of that into the python charmhelpers
<m_3> sidnei: I have no idea what we should do with that then
<sidnei> there was some concern that nrpe stuff shouldn't live there for example
<m_3> sidnei: lemme look at lp:charmsupport
<m_3> they're really two different things.... helpers are for charms... charm-tools are mostly cli tools for charmers
<sidnei> the biggest blocker atm for me is that the relation_get function from python charmhelpers can't be changed in a backwards-compatible way
<sidnei> are you saying that helpers should be split from charm-tools?
<m_3> sidnei: yes
<m_3> might not solve this particular problem
<m_3> but in general, those stand separately
<m_3> hmmm, yeah, that's what I was gonna ask... what's in the way of integrating charmsupport into python charm-helpers
<sidnei> not necessarily no. but i could move the 3 functions from python charmhelpers that im using into charmsupport and ignore python charmhelpers from now on.
 * m_3 facepalm again
<m_3> it'd be great to build python charmhelpers
<sidnei> yes, i join you in that
<sidnei> to build python charmhelpers as in having a proper set of charmhelpers in a package that charms can use?
<m_3> lemme look at relation_get in charm helpers
<sidnei> which may or may not be the current python charmhelpers that are part of charm-tools
<m_3> yeah!
<sidnei> relation_get in charmhelpers returns the result of relation-get in whatever the default format is, instead of the json-parsed python structure.
<m_3> I think helpers were glommed together into the charm-tools project temporarily...
<m_3> sidnei: ah
<sidnei> i don't think i can change it to simply add json.loads() and still be backward-compatible
<m_3> right... I should do a big pull and start grepping around for deps on the various charm-helper packages
<m_3> prbably have that on disk on one of the testers atm
<sidnei> actually seems only get_config() does a json.loads(), none of the others do in charmhelpers
<sidnei> so if we could reconcile that
<m_3> sidnei: gotta run to a meeting... lemme know if you see a clear solution, I'll take a look this afternoon
<m_3> sorry man
<sidnei> m_3: no problem. i might throw it in an email, im off next week.
<jcastro> niemeyer: heya, publish looks awesome, when do you expect to land it? Wondering as far as documenting it for the submissions guidelines and all that.
<niemeyer> jcastro: I've been landing it in pieces.. I just started working on it again 30 mins ago.. if I manage to keep my focus, perhaps sometime tomorrow it should be all in
<jcastro> niemeyer: oh ok, so for 13.04 then, that's brilliant
<SpamapS> uh
<SpamapS> 13.04 what?
 * SpamapS saw something about a final beta freeze yesterday
<jcastro> I don't know what the status of juju's FFe is offhand
<SpamapS> IIRC, juju is still unseeded. So.. the freeze is nominal
<SpamapS> does juju-core exist in Ubuntu yet?
<jcastro> is unseeded meaning ... ?
<SpamapS> https://launchpad.net/ubuntu/+source/juju-core
<SpamapS> no existe
<SpamapS> jcastro: unseeded is the new universe man
<jcastro> oh, I believe this is what mgz/mims were working on today?
<SpamapS> https://launchpad.net/ubuntu/raring/+queue?queue_state=0
<SpamapS> jcastro: you'll also have to tax an archive admin to pass NEW
<SpamapS> should have done that months ago
<jcastro> I don't know who's working on the package
 * SpamapS will take some responsibility for ditching in December ;)
<jcastro> I care more about it being in the ppa for 12.04 tbh
<SpamapS> jcastro: totally, I'd ignore distro for raring
<jcastro> I don't think I can get away with ignoring it
<jcastro> :)
<SpamapS> you're going to create a bunch of work for over-taxed individuals because the plan was to work right up until the last final possible moment
<SpamapS> this was what I was upset about.. calling it "13.04" when you have 6 months of new work to do isn't really possible and, big surprise, the schedule slips.
<jcastro> I more mean about the PPA
<balloons> jcastro, I asked plars to swing by to help out
<jcastro> ok
<balloons> I'm assuming since the jobs are on jenkins.qa.u.c he might be able to help you ;-)
<jcastro> m_3: ^^^^
<plars> jcastro: if you know the job name, I can check to see if it's running on one of the jenkins instances I have access to
<plars> nothing actually runs on jenkins.qa.u.c, it's just for showing results
<m_3> jcastro: thanks
<m_3> plars: hi
<plars> hi m_3
<m_3> plars: hey, so I've got some instances running that publish to jenkins.qa.ubuntu.com
<m_3> plars: the publication mechanism seems to be broken
<m_3> plars: can you look at the logs to see what's up with... for instance... precise-openstack-charm-bitlbee
<m_3> as a job name
<plars> m_3: ah, which jenkins instance actually runs the jobs?
<plars> m_3: typically, if publication is failing, it will be on the jenkins system that runs the jobs, not the one that it publishes to
<m_3> plars: these're running on instances in ec2
<plars> m_3: and unfortunately, restarting jenkins is usually the only fix (the one running the jobs)
<m_3> plars: yup, they're actually ephemeral and come to life every day
<m_3> plars: they're configured automatically with juju
<plars> m_3: and they've previously worked, but suddenly stopped?
<m_3> plars: james page orig set up creds for publishing to jenkins.qa.ubuntu.com
<m_3> plars: yes, they were working in the past
<m_3> plars: then they stopped a few months ago due to version changes
<m_3> plars: then were running again
<plars> m_3: any chance they are getting shut down before publication has finished?
<m_3> plars: and stopped about a month ago
<plars> m_3: I don't have any access (other than the public page) to jenkins.qa.ubuntu.com, so everything I can see is what anyone can see on that
<plars> m_3: If it's an access problem, likely james or IS will have to handle it
<plars> m_3: if there's any way to keep the instance alive after it finishes for a bit, for debugging though
<plars> m_3: that might be helpful so that you can see where if it's just dying to quick, or if there's an error on the jenkins running in ec2 when it tries to publish
<jcastro> plars: he just texted me that his network is out.
<m_3> whew
<m_3> ok, back
<plars> m_3: wb :)
<m_3> plars: sorry
<plars> m_3: what was the last thing you saw from me?
<m_3> one sec
<m_3> plars: ok, so you were asking if the jobs died before they could publish
<plars> plars> m_3: I don't have any access (other than the public page) to jenkins.qa.ubuntu.com, so everything I can see is what anyone can see on that
<plars> <plars> m_3: If it's an access problem, likely james or IS will have to handle it
<plars> <plars> m_3: if there's any way to keep the instance alive after it finishes for a bit, for debugging though
<plars> plars> m_3: that might be helpful so that you can see where if it's just dying to quick, or if there's an error on the jenkins running in ec2 when it tries to publish
<m_3> plars: ok, yeah I just wanted somebody to check the logs on there while I was publishing
<plars> m_3: I have no ability to do that
<m_3> plars: yeah, I can control thelifetime
<m_3> plars: ok, cool... I'll ping is
<m_3> plars: thanks!
<m_3> plars: oh, btw... do you manage the disk space on there?
<m_3> plars: i.e., if I wanted to remove old build artifacts
<plars> m_3: nope, that would also be IS, sorry :(
<m_3> ack
<m_3> plars: thanks
<jcastro> marcoceppi: you had plans to rename shelr.tv to something else right?
<marcoceppi> jcastro: it's already been renamed
<marcoceppi> jcastro:
<marcoceppi> jcastro: http://jujucharms.com/charms/precise/shelrtv
<jcastro> ack
<AskUbuntu> Tried to follow the EC2 Juju guide and it fails | http://askubuntu.com/q/277638
#juju 2013-04-04
<hazmat> sarnold, answered btw re askubu
<sarnold> hazmat: cool :)
<sarnold> hazmat: s/your/you're/
 * hazmat concedes an edit to the rules of a punctuation
<hazmat> :-)
<sarnold> yay, done within the five minute window :D
<sarnold> "look ma, no edit" :)
 * mariusko is really tired of Juju-gui stopping working
<frankban> mariusko: please join #juju-gui and describe the problem
<mariusko> frankban: ah, didn't knew there was a separate channel
<popey> Is anyone able to address bug 1159020 ? - Juju is unusable in raring
<_mup_> Bug #1159020: SyntaxError: invalid syntax <juju:Confirmed> < https://launchpad.net/bugs/1159020 >
<ubot5`> bug 1159020 in juju "SyntaxError: invalid syntax" [High,Confirmed] https://launchpad.net/bugs/1159020
<_mup_> Bug #1159020: SyntaxError: invalid syntax <juju:Confirmed> < https://launchpad.net/bugs/1159020 >
<_mup_> Bug #1159020: SyntaxError: invalid syntax <juju:Confirmed> < https://launchpad.net/bugs/1159020 >
<sidnei_> bothfight
<sidnei_> bot even
<mariusko> Okay, landscape-client kills juju-machines
<mariusko> With its CPU and RAM usage
<mariusko> It is not even possible to get rid of it completely
<bbcmicrocomputer> sarnold: unattended-upgrades charm is promulgated :)
<sidnei`> dpb_: ^
<mthaddon> If we have a problem with a particular hook, and fix that, we can upgrade-charm to rollout the fixed version of the charm. However, how do we actually fire the hook in question?
<marcoceppi> mthaddon: If the charm is in an error state, you can juju resolved --retry <charm>; if it's not you'll either need to change a relation or configuration (to get the hook to fire again). IIRC there's a jitsu command to "run-as-hook" that might also help achieve what you're trying to do
<mthaddon> marcoceppi: I'd rather avoid jitsu and do it "the right way"â¢ if there is such a thing
<marcoceppi> mthaddon: understood. You can't just fire off hooks arbitrarily from juju itself. You'll need to trigger the event again if possible
<mthaddon> marcoceppi: I might just send a mail to the list, as this is kind of an interesting question - thx for your feedback
<marcoceppi> Well, there is a way to "sort of" trap hooks and fire them off at will, using juju debug-hooks
<mthaddon> yeah, that was one of the workarounds we'd thought of, but as I say, would like to do it "the right way"â¢ if there is such a thing
<marcoceppi> The list might have more interesting feedback, to be honest (outside of jitsu) I think debug-hooks would be your next and possibly only bet
<mthaddon> thx
<hazmat> mthaddon, replied via email
<mthaddon> thx
<hazmat> marcoceppi, the run-as-hook needs a big warning in blinkies that its executing on the local machine
<hazmat> er client
<hazmat> i think its broken..
<marcoceppi> hazmat: the help was slightly off-putting. I saw that it "executes locally" I just assumed that meant in relation to the machine it was referring to
<hazmat> what would be nice is a juju-run-hook cli api on the units that admins, cron jobs can use to execute hooks
<marcoceppi> Yeah, that would be swell
<hazmat> argh.. pypi down
#juju 2013-04-05
<AskUbuntu> Mass post-node-enlisting installation fails or doesn't start! | http://askubuntu.com/q/278154
<paraglade> I am trying to get a juju environment running under an amazon VPC.  I have added "vpc_id" and "subnet_id" to the environments.yaml but I am not seeing the instances staring in the VPC.  Any idea why?
<paraglade> I am trying to get a juju environment running under an amazon VPC.  I have added "vpc_id" and "subnet_id" to the environments.yaml but I am not seeing the instances staring in the VPC.  Any idea why?
#juju 2013-04-06
<conikee> friends , a few quick question pertaining to mongo provisioning
<conikee> I followed every step through this tutorial http://blog.xtremeghost.com/2012/11/lets-shard-something.html
<conikee> AT the final steps, on issuing "juju status mongos" I receive relation-errors   relation-errors:           mongos:           - shard1           - shard2           - shard3           mongos-cfg:           - configsvr
<conikee> I did not miss any steps
<conikee> can somebody please enlighten me on what the error could be
<paraglade> been really quite on this channel today everyone ok?  ")
<abathingchris> anybody working with juju bootstrapping in a Rackspace managed cloud which doesn't have a security groups layer?
#juju 2013-04-07
<AskUbuntu> Problem while deploying MysQL through Juju in LXC | http://askubuntu.com/q/278770
<AskUbuntu> juju local error ERROR could not connect before timeout | http://askubuntu.com/q/278841
<hazmat> paraglade, there is no vpc support at the moment
#juju 2014-03-31
<Valduare> hi guys im getting some odd behavior with juju and add-machine
<mbruzek> Valduare, specifically what kind of odd-ness?
<Valduare> ERROR lookup juju-openerp: no such host
<Valduare> this is after I destroyed environment
<Valduare> and am re-using the same vmâs
<Valduare> I sshâed into the vm and rm the juju stuff there as per the wiki
<mbruzek> I have not done the manual provider personally but I can take a shot here.  When you destroyed the environment Juju might not have cleaned up all the way.  Can you try to destroy-environment with the --force option?
<Valduare> I have
<mbruzek> What version of Juju are you using?
<Valduare> 1.17.7
<mbruzek> Yeah that is the latest.
<mbruzek> I am sorry Valduare you seem to have stumped me.  I have a cleanup script for when the local provider does not destroy properly but I don't think that will help you in this case.
<Valduare> hmm
<Valduare> its not anything with the vmâs cause iâve blown them away and reinstalled fresh servers
<Valduare> its something on my workstation -
<Valduare> and juju
<mbruzek> You mentioned you were following the wiki page which page?
<Valduare> the one on manual provisioning
<mbruzek> What is your bootstrap-host value ?
<Valduare> http://askubuntu.com/questions/433842/how-to-resolve-error-machine-is-already-provisioned-in-manual-provision-set-up   thats how I cleaned up one of the vmâs im trying to re-add in this new juju bootstrap environment
<Valduare> its an ip address
<Valduare> it bootstraps fine
<Valduare> i have all of the vmâs setup with one of my public ipâs and diffeent ssh ports right now
<mbruzek> All machines added with juju add-machine ssh:... must be able to address and communicate directly with the bootstrap-host, and vice-versa.
<mbruzek> When you ssh to your machines.  you can see your workstation?
<Valduare> yes
<Valduare> iâll have to figure this out tomorrow
<Valduare> g'night
<mbruzek> Sorry Valduare
<rogpeppe1> mornin' all
<rogpeppe1> axw: about "call State.SetAPIAddresses in bootstrap-state command"
<rogpeppe1> axw: there are two reasons we want to do this
<rogpeppe1> axw: firstly, and most pragmatically, we won't be able to enable the peergrouper worker for a little while, and having valid API hostports in state is a prereq for other branches
<rogpeppe1> axw: secondly, if we rely on the peergrouper worker to do it, there's a window at bootstrap time when there are no API addresses, so clients that connect early won't get them
<axw> rogpeppe1: sorry, was picking up my daughter
<rogpeppe1> axw: np
<rogpeppe1> axw: in #juju by accident. #juju-dev probably more appropriate
<lseror_> Hi everyone
<lseror_> I am Laurent and I am in charge of Outscale who is a Cloud Provider (IaaS)
<lseror_> I just install juju and I want to test it
<lseror_> thanks for the work, the website is great
<lseror_> I notice that some configurations seems to be inside the juju binary, like aws region address
<lseror_> I think that it would be cleaner to put that kind of informations in another file, with an editable format
<lseror_> like json
<lseror_> I did not find any forum to discuss about it but I subscribe to the ML and will use it
<lseror_> I am just fishing here for some comments
<ashipika> look at .juju/environments.yaml
<ashipika> most stuff should be configurede there
<lseror_> not the aws regions
<lseror_> I check
<lseror_> you can tell the regions
<lseror_> but not the url
<lseror_> you can put us-east-1 by example
<lseror_> but not the corresponding utl
<lseror_> but not the corresponding url
<lseror_> that is in the juju file (I strings it)
<ashipika> oh, ok.. i see..
<lseror_> it should have https://ec2.us-east-1.amazonaws.com as a parameter somewhere
<ashipika> sorry
<lseror_> no problem
<lseror_> I am here for discussion
<lseror_> ;)
<weblife> say if I connect an elastic ip though aws to one of my machines managed by juju. Would there be a way to retrieve that newly attached external ip because unit-get public-address pulls the dns address (ie. ec2-54-215-195-84.us-west-1.compute.amazonaws.com) ?
<Valduare> morning guys
<jcastro> hi!
<mbruzek> Good morning Valduare
<mbruzek> Valduare, I was thinking about your problem last night.  Can you run the failing command with --debug and pastebin the results?
<Valduare> sure
<Valduare> it says it completes if I remember right though
<Valduare> oh that was different debug I was thinking of
<Valduare> one sec pastebinning
<Valduare> http://pastebin.com/qhK1HJ9Y
<Valduare> stripped ip and usernames out etc
<mbruzek> Valduare, The message "ubuntu user is already initialised" makes me think there is a problem on the machine
<Valduare> I just removed the user and removed the home dir
<Valduare> juju had set it up on a previous run
<mbruzek> did that help?
<Valduare> no
<Valduare> what I dont understand, why it asks for password after i coppied my key over already
<Valduare> I can ssh without password to these hosts just fine
<mbruzek> Someone from juju-core should take a look, maybe you can post this link in #juju-dev
<themonk> marcoceppi: hi
<themonk> marcoceppi: i am in problem with relation-set and relation-get
<themonk> marcoceppi: need help
<mbruzek> themonk:  What is the problem?
<themonk> mbruzek: hi thanks, problem is in provider charms joined i am setting some values using relation-set but not getting it requirer joined/changed using relation-get
<mbruzek> themonk, sometimes the order of things is important.  For instance sometimes the mysql charm does not set all the values so consumers of the mysql relation need to check if all values are there before they process the db relation.
<themonk> mbruzek: may be i am missing some thing here, can u tell me when to set value and get value like joined/changed
<mbruzek> themonk, so for instance if relation-get database is not set the related charm can not progress so some people put an exit 0 in their relation code and wait until the mysql relation returns a database
<mbruzek> if [ -z "${db_db}" ]; then
<mbruzek>   juju-log "No database information sent yet. Silently exiting"
<mbruzek>   exit 0
<mbruzek> fi
<mbruzek> Where db_db=`relation-get database`
<jose> that needs to be on a db-relation-changed, as it'll run once the relation data changes
<mbruzek> jose, you are correct that is where I pulled it from.
<mbruzek> So themonk may be getting timing issues, where the relation-set and relation-get are happening out of order
<jose> yep, that should fix it :)
<themonk> mbruzek: hmm, that possibility is high :)
<mbruzek> themonk, Use juju-log to print out the data from the relations and then exit if it is not all there.
<themonk> mbruzek: can you tell when the relation callbacks called and there order (joined,changed,departed,broken) doc is not good enough in jujudoc
<mbruzek> *relation-joined is when a connection has been established, *relation-changed is when data on a relation changes, *relation-departed is called when you still have a connection but it is going away, and *relation-broken is called when there is no more connection.
<mbruzek> Remember you must make he hooks idempotent because these hooks can run more than once in the lifetime of a charm.
<themonk> mbruzek: hmm, can you point me a detail youtube video, blog or anything
<mbruzek> themonk, have you already read this: https://juju.ubuntu.com/docs/charms-relations.html
<themonk> mbruzek: yes
<mbruzek> OK looking for more specific content
<themonk> mbruzek: if i check inside *relation-changed that is data changed then my question is, is juju periodically calls it?
<themonk> mbruzek: sorry for bad english :)
<mbruzek> Juju will not call it randomly.  It gets called when information on that relation changes
<jose> you need to consider that information may change, so you may have to update it at any point
<jose> make sure you take your precautions when writing the code
<mbruzek> themonk, jose is correct.  Here is a youtube video that talk about relations http://www.youtube.com/watch?v=yRcqSjOGweo
<themonk> mbruzek: Ok. what i am doing is this, my provider charm *relation-joined is setting some data then requirer charm *relation-changed should called by juju automatically and my method will check the data and make changes, is it ok?
<mbruzek> themonk, Yes that is the pattern.
<themonk> thanks jose and mbruzek
<themonk> mbruzek: i am watching it now
<weblife> say if I connect an elastic ip though aws to one of my machines managed by juju. Would there be a way to retrieve that newly attached external ip because unit-get public-address pulls the dns address (ie. ec2-54-215-195-84.us-west-1.compute.amazonaws.com) ?
<mbruzek> weblife, I don't know of a way to do that.  Could you find the ip by using dig or some tool like that?
<mbruzek> our use route53 to look it up?
* mbruzek_ changed the topic of #juju to:  Welccome to Juju!  Reviewer mbruzek || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP
<weblife> mbruzek Okay thank you.
<mbruzek> weblife, actually nslookup might give you a better parsable answer
<mbruzek> weblife  nslookup ec2-54-215-195-84.us-west-1.compute.amazonaws.com
<weblife> thanks good idea
<weblife> try it out in my next launch
<bloodearnest> anyone know a way to fake a public ip for a unit with the local provider?
<Flint_> hi mbruzek
<mbruzek> Hello Flint_
<Flint_> just checking connections, seems to only work on one of my 4 computers...
<mbruzek> Flint_ Well I can see you there so one of the works.
<Flint_> btw juju brings up some interesting photos by default
<mbruzek> Yes I have seen some of those
<mgz> beware the image search
<timrc> marcoceppi, FYI, upgrading to 1.17.7 fixed the issue I had with upgrade-charm where it was losing the service config values
<tvansteenburgh> inside of a config-changed hook, i'd like to check "am i in a mongodb relation, and if so, what's the ip and port of the remote side?" is this possible with charm-helpers?
<tvansteenburgh> there are lots of hookenv.relation_* functions...trying to figure out which ones i need for this (if it's possible)
<jose> tvansteenburgh: what I could do in that case is check if touch a file called '.mongodb-configured' once configuration is done, and then check if the file's there, maybe there's a charm helper that can do that more easily
<tvansteenburgh> looks like i could borrow the code from `is_relation_made()` so i can get the context
<marcoceppi> timrc: \o/
<cargill> marcoceppi: going through the amulet documentation vs. code, could tthe doc somehow hint which parts are not implemented yet? Maybe with a note, or being greyed out?
<marcoceppi> cargill: what's not implemented in the docs?
<marcoceppi> with the exception of the bash interface, everything in the docs should be in the code
<cargill> picking up a file from the unit
<cargill> https://bazaar.launchpad.net/~marcoceppi/amulet/master/view/head:/amulet/sentry.py
<cargill> oops? maybe I'm reading too fast?
<marcoceppi> cargill: it's implemented in UnitSentry
<marcoceppi> yeah
<marcoceppi> cargill: you can get to it from d.sentry.unit['unit/#'].file()
<cargill> sorry, I was getting weird errors, and waiting 20 minutes for a test to get to the failure and not being able to run pdb must have gotten the best of me
<lemao> I am trying to figure out "An error occurred: watcher error: [Errno 111] Connection refused". This after I try to access the juju-gui from the browser
<mbruzek> lemao Did you run:  juju expose juju-gui    first?
<mbruzek> lemao, What command are you trying to run?
<lemao> mbruzek: yes, I did expose.
<mbruzek> lemao, What command are you getting the error on?
<lemao> mbruzek: well, I am trying to get my OSX Mavericks working with Juju in a VagrantBox using the local provider. I am using JuJuBox + precise lxc guests. I basically used the Vagrant IP to access the juju-gui :80 and got a juju web page with the error above
<AskUbuntu> Error when using Juju Client on Windows 8.1 juju bootstrap to aws get AWS Acess key id you provided | http://askubuntu.com/q/441663
<lazyPower> lemao: are you using the official basebox or did you build your own?
<lemao> lazyPower: this specific case I am using the JujuBox
<lemao> (error: template container "juju-precise-template" did not stop)
<lemao> lazyPower: I also have a trusty vagrant box but ran into other issues
<lemao> lazyPower: (sorry the error message came first)
<lazyPower> lemao: interesting. I haven't seen that, and i ran the demo vid on mavericks.
<lazyPower> but we have have updated the box recently which would have other implications. Whats the juju version in the box?
<lemao> lazyPower: Ok, let me review my steps.
<lazyPower> s/have have/may have/
<lemao> lazyPower: 1.16.6-precise-amd64
<lazyPower> ok that seems like its the same version in the box i demo'd
<lazyPower> lemao: Can you pack up your logs of the vagrant run and post thems omewhere so I can see whats going on?
<tvansteenburgh> anyone know of an existing charm that uses the charm-helpers @hook() decorator?
<tvansteenburgh> my hooks aren't failing, but i don't think they're executing either - none of my log msgs are showing up
<mbruzek> tvansteenburgh, I don't see @hook() in the ganglia charm that I am working on
<tvansteenburgh> here's my code: http://paste.ubuntu.com/7186887/
<tvansteenburgh> so, line 214 for example
<lemao> lazyPower: Let me start once more from scratch just to make sure it is not a stupid error from my part
<lazyPower> lemao: ok ping me if you want me to lookat logs
<lemao> lazyPower: I will. thanks
<mbruzek> tvansteenburgh, I haven't seen any python hooks like that.  The ones I have seen have a key value section that calls the hooks
<lazyPower> @tvansteenburgh the decorator is displayed in the charm helpers youtube video ~ 3/4 of thew ay through if that helps
<lazyPower> @tvansteenburgh aslo i think cassandra uses the decorator
 * tvansteenburgh looks at cassandra
<mbruzek> cassandra hooks are bash
<tvansteenburgh> i don't see it being used in cassandra
<tvansteenburgh> oh well, i'll see if i can debug it.
<tvansteenburgh> oh i see
<lazyPower> hmm
<lazyPower> maybe i'm thinking of mongo
<tvansteenburgh> you still have to execute the hook with `hooks.execute(sys.argv)`
<tvansteenburgh> i missed that part
<lazyPower> nope
<lazyPower> right on
<lazyPower> ok i'm heading out for a bit
<tvansteenburgh> o/
<lazyPower> o/
<lemao> lazyPower: stupid me... I had a custom bootstrap.sh being called by vagrant that was probably messing up JujuBox. I removed it and started from scratch and now I get the juju-gui on my OSX
<lazyPower> lemao: bueno.
<lemao> I have deployed mysql but get "ERROR juju.worker.uniter uniter.go:350 hook failed: exit status 1" how should I debug this in juju?
<jose> lemao: ssh into the machine and look at the logs, they're stored in /var/log/juju
<tvansteenburgh> debug-hooks also very useful: https://juju.ubuntu.com/docs/authors-hook-debug.html
<lemao> jose: I did that but the above message was most of what I could find
<lazyPower> lemao: its typically due to the pool memory size
<lemao> lazyPower: I ran 'sudo route -n add -net 10.0.3.0 172.16.250.15' in OSX and was able to access LXC nodes inside Vagrant without any port forwarding. If this can be hooked into Vagrant so the route is added when vagrant is up'ed and deleted from halt'ed/destroy'ed that would be quite nice
<lazyPower> its a known bug
<lazyPower> lemao: we've been using sshuttle
<lemao> lazyPower: sshuttle doesn't work for me
<lazyPower> that way it doesn't alter your pc's routing table after sshuttle is terminated
<lemao> lazyPower: "IOError: [Errno 24] Too many open files: '/etc/resolv.conf'"
<lazyPower> lemao: thats coming from sshuttle?
<lemao> lazyPower: yeah, that would be ideal. It just barfs as soon as I hit one of the ip's proxied by sshuttle
<lemao> lazyPower: yes
<lemao> lazyPower: after tons of ': DNS request from ('192.168.0.104', 55405): 31 bytes'
<lazyPower> lemao: that has something to do with the max number of open apps/file streams you have going on your system.
<lazyPower> i dont think theres anything I can do to resolve that
<lemao> lazyPower: yes, that's what I thought, but even after a reboot I still get the same error.
<lemao> lazyPower: for now I will stick with manually adding/removing the route. I need to experiment with charms now.
<lemao> On a different note, does it make sense to use juju to deploy tomcat wars? Tomcat will definitely be a charm, but what about the 1 or more .war's that are deploy there? Would that be a charm that is related to the tomcat charm?
<Valduare> when is 1.18 due to release
<davecheney> Valduare: this week
<Valduare> neato
<lemao> humm, found 'servercloud-r-juju-appserver-support'. Is this basically already supported with subordinate charms (web app deployments)?
<lemao> (https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-juju-appserver-support)
<davecheney> marcoceppi: http://paste.ubuntu.com/7187355/
<davecheney> manual provider on ppc
<marcoceppi> davecheney: sweet!
<davecheney>       mysql/0:
<davecheney>         agent-state: pending
<davecheney>         agent-version: 1.17.8.9001
<davecheney>         machine: "1"
<davecheney>         public-address: 10.245.67.7
<davecheney> marcoceppi: it's over 9000
<marcoceppi> hahak I noticed
<andreas__> how do I bootstrap a trusty env, just "juju bootstrap --series=trusty"?
<davecheney> andreas__: good question
<davecheney> andreas__: do you want a trusty boottrap machine
<davecheney> or service units running trusty
<andreas__> right now I wanted bootstrap only because it was going to be the fastest way to get a clean trusty machine "out there"
<davecheney> andreas__: if you want a clean trusty macine
<andreas__> but if that doesn't work, I can do having bootstrap on whatever an a "ubuntu" unit on trusty
<davecheney> juju deploy cs:trusty/ubuntu
<andreas__> yeah, I just didn't want to waste a machine
<davecheney> andreas__: sorry, i didn't understan that last comment
<andreas__> so I figured bootstrap could be trusty
<andreas__> davecheney: juju deploy cs:trusty/ubuntu will in the end need two machines
<andreas__> bootstrap + ubuntu
<davecheney> andreas__: yes
<davecheney> you could try
<andreas__> I just wanted one, and figured bootstrap could be it
<davecheney> juju bootstrap --constraints="series=trusty"
<davecheney> it might work
<andreas__> ok, because juju bootstrap --series=trusty doesn't
<davecheney> --series isn't a flag
<andreas__> ah, it's just about the tools?
<andreas__>     upload tools for supplied comma-separated series list
<davecheney> andreas__: nope
<andreas__> I don't know what it is for then, clearly my assumption was wrong
<davecheney> andreas__: juju makes it really hard to control the series of the bootstap machine
<andreas__> and the "series" constraint isn't known
<davecheney> andreas__: you could try default-series in config
<davecheney> but we're getting rid of that
<andreas__> I think that doesn't exist anymore either
<andreas__> I'll go with bootstrap + ubuntu
#juju 2014-04-01
<jose> hey guys, do you think a dnsmasq charm would be suitable for the charm store?
<davecheney> jose: sure
<davecheney> but it sounds like a subordinate
<davecheney> well, maybe
<davecheney> it could be either
<overm1nd> hi guys, how I deploy a machine from a juju client on a different architecture (like juju on ARM -> to a amd64)?
<overm1nd> hazmat I opened an issue for juju-docean here: https://github.com/kapilt/juju-digitalocean/issues/17
<overm1nd> don't hate me :P
<hazmat> overm1nd, no worries.. so that's a failing of the plugin, easy to address as well.
<overm1nd> :)
<hazmat> overm1nd, interesting though. i didn't bother with arch.. because there is only one arch on docean
<hazmat> overm1nd, but it sounds like your running into juju wanting to use the client arch when provisioning?
<overm1nd> yes
<hazmat> cool, easy fix.. one moment
<overm1nd> i 'm using juju from an ubuntu on arm
<overm1nd> and if I don't use the arch parameter it fails
<overm1nd> because the are no upload tools for my environment of course
<hazmat> overm1nd, i pushed a fix to git.. i'm not sure if that's enough though.
<hazmat> overm1nd, if it still errors (it will be a different place) please attach the new traceback to the issue
<overm1nd> great, let me check
<overm1nd> hazmat I updated the issue
<hazmat> overm1nd, yeah.. reproduced
<hazmat> overm1nd, new version and test pushed
<overm1nd> in pip or github?
<hazmat> overm1nd, github
<overm1nd> ok
<overm1nd> hazmat updated
<overm1nd> still some problems but I don-t know if is related to the juju/docean
<hazmat> overm1nd, docean occassionally messes up i've noticed.. i've had a stuck instance with them before and had to contact support, some sort of issue with their hypervisor.. they extended credit for it.
<hazmat> only happened once in roughly 150 instances launched
<hazmat> overm1nd, that looks like the instance is stuck booting.. ie it never comes up before the ssh timeout.
<hazmat> hmm
<hazmat> actually that's different, pre the ssh check
<hazmat> that looks like it never launched
<hazmat> overm1nd, contact support its just a bad instance it looks like.. the plugin gives up if the api doesn't get to 100% completion on a start instance action within 3.5 m
<bac> hey benji i saw you held the charmworld 'maintainers field' card for a while.  did you produce anything worth passing along to me as i start it?
<overm1nd> ok hazmat
<overm1nd> thx
<benji> bac: no, not really.  I found that the existing "maintainer" field was intended to support a list of maintainers so I spent several hours trying to get that to work, but then I found out that it had been decided beforehand that the field name must be "maintainers"
<overm1nd> I will start another machine in the mean time
<hazmat> overm1nd, sounds good
<bac> benji: ok, thanks
<overm1nd> mmm another machine  stucked
<marcoceppi> benji: there was some discussion on the list about having the metadata.yaml file support both maintainer and maintainers
<marcoceppi> bac: ^
<overm1nd> it-s the plugin I think hazmat
<bac> thanks marcoceppi
<hazmat> overm1nd, unlikely..
<overm1nd> I tri to bootstrap a machine from thre panel
<overm1nd> try+
<overm1nd> let's see
<hazmat> overm1nd, looks like digitalocean api and console is just broken atm
<hazmat> overm1nd, http://www.digitaloceanstatus.com/
<overm1nd> ahah right
<hazmat> that's from a few days ago
<overm1nd> I cannot start a droplet even from the panel
<hazmat> overm1nd, yeah.. i just verified this is universal on #digitalocean
<overm1nd> good to know the plugin should work
<hazmat> overm1nd, its working again.. but it might be too slow for the plugin
<hazmat> i'll have to add timeout as a cli param i think
<gnuoy> mbruzek, I have a charm that's waiting for review. I just wanted to check it wasn't being skipped over on the assumption an IS person was going to review it. If its in the queue thats fine and I'll get back in line :)
<gnuoy> oh, its the content-fetcher one
<mbruzek> Hello gnuoy.  Let me check where it is.
<gnuoy> thanks
<gnuoy> Bug#1296720
<_mup_> Bug #1296720: Bug to track submission of content-fetcher charm to charm store <Juju Charms Collection:New> <https://launchpad.net/bugs/1296720>
<mbruzek> gnuoy, The Review Queue can be found here: http://manage.jujucharms.com/tools/review-queue
<jcastro> marcoceppi, lazyPower, mbruzek: hey so you guys now how rails and node need a git URL to deploy an app right
<jcastro> and for rails it's one of pavel's branches.
 * lazyPower nods
<jcastro> I was thinking about filing a bug that we should include a Hello World app for each of those charms
<jcastro> so that we can test them
<lazyPower> jcastro: good plan
<gnuoy> mbruzek, ah, I didn't know about that page (or maybe I forgot)
<mbruzek> gnuoy  I see your request in there, and it looks like it is in the middle.
<jcastro> like, if you don't have a node app handy how can we test the node charm, etc.
<gnuoy> mbruzek, thats fine, thanks
<lazyPower> jcastro: make sure you include the specs on what you want it to do, as in, if it should have a database dependency
<jcastro> yeah
<lazyPower> or be a stand-alone app
<lazyPower> but i'd be game for buliding a hello-world rails app for the charm
<mbruzek> gnuoy It is in the proper place, we have many reviews to do.  Someone will get to it hopefully soon.
<gnuoy> sounds good, thanks
<lazyPower> gnuoy: I'll try to get some reviews in tonight when i'm at the hotel. Is this charm review blocking work for you?
<gnuoy> hi lazyPower, no its not blocking us. We have a few places we're going to use it when reviewed but its not zOMG urgent
<gnuoy> and thanks
<lazyPower> Ok. Just checking :) if its actively blocking you from moving forward and its urgent - feel free to ping me direct and I'll promote it on my list.
<jcastro> gnuoy, and if someone from your team(s) wants to help us dig through this queue ... :)
<gnuoy> jcastro, yeah, fair point
<lazyPower> jcastro: <3
<gnuoy> Do you have a set procedure to work through for a review ? Must pass charmproof and work on provider x & y etc?
<jcastro> gnuoy, https://juju.ubuntu.com/docs/reference-reviewers.html
<gnuoy> thanks
<gnuoy> I'm a fan of Bug#1277652. Would a charm be bounced for missing default values ?
<_mup_> Bug #1277652: charm proof should not warn for missing default values <Juju Charm Tools:New> <https://launchpad.net/bugs/1277652>
<lazyPower> gnuoy: if it comes up in charm proof, it should be noted in the review
<lazyPower> gnuoy: anything above i, warns are not blockers but warrant call-outs
<gnuoy> ack
<webbrandon> yeah auto complete working with service names!  thank you
<webbrandon> little things that make the difference sometimes
<tvansteenburgh> i am a charm that exposes the website interface, and i'm in a relation with haproxy. in a config-changed event, my port changes. how do i inform haproxy?
<lemao> ola! Is there a juju roadmap available somewhere? I am curious to know what is in store for Juju in the future.
<sarnold> world domination of course :)
<avoine1> lemao: maybe you will find what you want in here: http://summit.ubuntu.com/uds-1403/meeting/22208/juju-core-update-for-1404/
<avoine1> and here: http://summit.ubuntu.com/uds-1403/meeting/22207/juju-gui-update-for-1404/
<lemao> sarnold: :-) sounds good as long as 'do no evil' is part of the roadmap
<lemao> avoine: thanks
<webbrandon> I think `juju status` should show any hook that is running.  My set new config takes awhile and it would be nice to see if the hook is done.
<arosales> tvansteenburgh: hello
<tvansteenburgh> arosales: o/
<arosales> tvansteenburgh: is relation changed what you are looking for?
<marcoceppi> tvansteenburgh: you need to invoke relation-set out of band
<marcoceppi> tvansteenburgh: which requires you to know the relation_id
<arosales> lemao: http://summit.ubuntu.com/uds-1403/meeting/22209/state-of-the-juju-ecosystem/ is also a good one in adtion do the ones sarnold caleld out
<sarnold> heh, it was avoine who was useful :)
<arosales> ah yes, avoine, sorry I read that wrong
<tvansteenburgh> marcoceppi: so you're saying the user would be responsible for doing that if he changed the website port?
<marcoceppi> tvansteenburgh: during relation-changed, you'll want to record JUJU_RELATION_ID and JUJU_REMOTE_UNIT somewhere
<marcoceppi> tvansteenburgh: no, it's doable in the charm
<tvansteenburgh> ok
<arosales> marcoceppi: would this be a good use case for juju run?
<marcoceppi> arosales: no, this is something the charm should do
<marcoceppi> the user initated the change with juju set, no need to make them /also/ do juju run
<marcoceppi> tvansteenburgh: so once you have those, you can use relation-set from outside of a relation hook
<arosales> I thought a charm could do "juju run"
<marcoceppi> arosales: maybe?
<tvansteenburgh> oh ok, so i can call relation-set from inside my config-changed handler?
<marcoceppi> Idk, only know about the client side juju run
<marcoceppi> tvansteenburgh: yeah, relation-set -r JUJU_RELATION_ID key=val JUJU_REMOTE_UNIT
<arosales> ya I need to confirm that feature
<tvansteenburgh> marcoceppi: excellent, thanks
<Fishy__> Has anyone seen when booting nodes off a MAAS server.. node makes it halfway though the boot...   then times out?
<Fishy__> Filename: pxelinux.0     tftp://192.168.4.1/pxelinux.0................ Connection timed out (http://ipxe.org/4c126035 )
<lemao> arosales: thanks.
<lemao> one feature I am looking for is the ability to manage application state while starting/stopping juju charms. e.g. backup a db schema before decommissioning a juju charm and machine and vice versa
<lemao> is is possible to achieve the above with juju as it is? I basically don't see a start/stop life cycle event
<mbruzek> lemao the start is called by juju after install, and stop is called by juju just before destroy
<mbruzek> lemao I would back up stuff in the  *relation-departed hook.  That is what it is inteded for iirc
<mbruzek> Other than calling start and stop from within  a hook I don't believe you can make juju call start or stop on your own.
<mbruzek> Feel free to chime in if someone knows differently.
<lemao> mbruzek: I see. My ultimate goal is to be able to provision a whole environment without ever having to manually log in to the env machines. This is trivial in the common case, but trickier to get done right when dealing with out-of-place upgrades or decommissioning customer tenants etc
<lemao> mbruzek: So I may have existing data when provisioning an environment X that I want to pre-populate before the service runs
<mbruzek> Your comment above was about backing it up?
<lemao> mbruzek: yes, that is part of it.
<mbruzek> lemao, My suggestion for that approach is to have a configuration option that points to the data.  The install hook could install the software but leave it unconfigured until the user sets the configuration value with the pre-populated data
<lemao> mbruzek: If I am upgrading an existing env X from 1.0 to 2.0, I will need to backup all services (the ones that have data), launch env Xv2 and restore the data there
<mbruzek> So your config-changed hook would finish the install and load the pre-populated data
<mbruzek> Again I think config-changed hook is where you want to concentrate on.
<mbruzek> All this sounds like input from the user.
<lemao> mbruzek: I basically want to make sure that I am not trying to squeze something out of juju that was not really part of the requirement.
<mbruzek> juju deploy lemao-charm
<lemao> mbruzek: that is great. I really like the devops in the large approach that juju takes
<mbruzek> juju set lemao-charm version="1.0"
<mbruzek> Do some stuff, time to upgrade
<mbruzek> juju set lemao-charm version="2.0"
<mbruzek> config-changed hook is called
<mbruzek> In the config-changed hook you could save the data to a directory and when the new software is installed it could load from the same directory.
<lemao> mbruzek: I see. This would take care of the inplace upgrade. But I guess I could achieve the same with an out-of-place upgrade, right? I.e. in a stop hook, save the data, deploy the charm, and on start hook restore it.
<mbruzek> lemao, As I said stop is called when juju is destroying that machine.
<mbruzek> So if you saved the data on that system, there would be no way to get it back.
<mbruzek> from that system
<mbruzek> You could dump it to a database and reload from a database relation
<lemao> mbruzek: is there a stopped state as opposed to running or destroyed?
<mbruzek> Not that I am aware of.
<lemao> mbruzek: One where the services and/or machines are not running but the service state (config/relations) are persistent (I guess stored as a bundle)
<mbruzek> lemao, I do not know of something like that.  You would have to push the data off the machine and grab it back
<lemao> mbruzek: ok. thanks for the information!
<mbruzek> lemao, anytime, and good luck!
<lemao> mbruzek: one additional question (unrelated to the above), if I may
<mbruzek> lemao, shoot
<lemao> mbruzek: For a typical webapplication, I assume the common practice is to model tomcat as a charm and my-web-app also as a charm and have them related to each other.
<lemao> mbruzek: so I could have N webapp charms related to the tomcat charm.
<mbruzek> lemao, There is already tomcat7 charm out there.
<lemao> mbruzek: yes, I saw that. but is this how people are deployment webapps, for instance, using juju?
<mbruzek> you can create a subordinate charm, that deploys the web app to the same machine as tomcat.
<mbruzek> https://juju.ubuntu.com/docs/authors-subordinate-services.html
<mbruzek> I wrote a charm that does this for OpenMRS.
<mbruzek> http://manage.jujucharms.com/charms/precise/openmrs
<mbruzek> there is also a j2ee-deployer charm that has not landed in the store
<mbruzek> http://manage.jujucharms.com/~robert-ayres/precise/j2ee-deployer
<mbruzek> take a look at those
<lemao> mbruzek: thanks a million! Will do.
<mbruzek> lemao, you are welcome
<lemao> me again ... :-) What would be the best way to add support for additional AWS features such as RDS, VPC, ELB, etc? As a provider or as a charm?
<lemao> when deploying a charm to an amazon environment an EC2 machine is automatically provisioned. Is it  possible to have juju launch an RDS instance instead?
<Valduare> hows it going guys
#juju 2014-04-02
<lazyPower> Valduare:  o/
<Valduare> o/
<Valduare> hows it going
<lazyPower> oh wow, a solid 3 hours later. heh heh
<Valduare> lol
<lazyPower> Good. Just got back from a pretty decent burger chef
<Valduare> iâve been sitting here for 3 hours waiting for someone to respond to my hey guys â¦ I didnt want to be rude and leave anyone hanging
<Valduare> jk :P
<lazyPower> hah well its my mistake for not reading the timestamp :)
<webbrandon> is juju local working okay now?
<Valduare> lazyPower: im still not up and running with juju
<Valduare> keeps bugging out
<Valduare> im at point now where it wont let me add machines at all
<lazyPower> meaning the manual provider workspace has all but given up hope?
<lazyPower> you can no longer spin up a new vm and register it?
<lazyPower> the existing vm's are dirty and wont respond to any deployment commands? they just fail?
<lazyPower> i'm reaching here, whats it doing?
<Valduare> all of the above
<Valduare> so I spun up a new vm fresh install of ubuntu and cant even provision it
<Valduare> https://bugs.launchpad.net/juju-core/+bug/1300264 I got this bug listed
<_mup_> Bug #1300264: manual provisioning requires target hostname to be directly resolvable <manual-provider> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1300264>
<lazyPower> oi
<Valduare> pretty fancy bug - its triaged :P
<lazyPower> i blame sarnold for all of he above Valduare. Not that he really did anything...directly... but he makes a great scapegoat
<lazyPower> sarnold: we're still buds right?
<Valduare> lol
<sarnold> lazyPower: <3
<lazyPower> sarnold: <3
<AskUbuntu> Clarification on JuJu for web apps and pages | http://askubuntu.com/q/442259
<overm1nd> hazmat I did not get what I need to do for the arch constraint
<overm1nd> it's a juju client problem?
<rbasak> frankban: FFe in bug 1282630 approved, but could you please confirm that my statement in comment #5 was accurate?
<AskUbuntu> conversion from commencing to ready state in maas | http://askubuntu.com/q/442350
<hazmat> overm1nd, output?
<hazmat> overm1nd, from -v verbose mode
<hazmat> overm1nd, juju should be detecting the host arch when ssh'ing and retrieving the correct tools for it
<overm1nd> hi hazmat in PVT for the log
<frankban> rbasak: yeah quickstart 1.3 does not require 1.18, it just includes changes to make quickstart work well on 1.18. rick_h_: relatedly, what's the plan for FFe vs upcoming quickstart changes (e.g. joyent and/or maas provider support)?
<hazmat> overm1nd, what's the cli your using?
<hazmat> overm1nd, are you passing --upload-tools
<hazmat> i think i might have defaulted that to on.. which is the problem
<overm1nd> I'm not doing anything special
<overm1nd> I just added the arch param
<overm1nd> 	juju docean bootstrap --constraints="mem=512M, region=ams2, arch=amd64" -v
<overm1nd> this is the command I'm using
<rick_h_> frankban: we can ask rbasak if it'll be possible to get a late update or else we'll just have to make that a ppa release.
<rick_h_> frankban: wev'e been delayed so long with things not sure if it's possible to still get it in trusty or not
<frankban> rick_h_: ack, ok thank you. the joyent fixes we needed seems to be landing now, so the joyent card could be unblocked very soon
<rick_h_> frankban: yea, with the delay we've had in that I've assumed we probably won't be able to get that into trusty
<rick_h_> frankban: but we can ask/check if there's some way
<overm1nd> hazmat I see, --upload-tools is passed when creating the machine
<overm1nd> but I don't get why it should be ommitted
<overm1nd> it's not mandatory to have juju tools on the started new machine?
<hazmat> overm1nd, juju will pull the right binaries on its own
<overm1nd> ah ok
<hazmat> overm1nd, upload-tools is there because its simple reliable, juju pull binaries mechanism involves a few roundtrips to query various sources.
<overm1nd> so it's failing because architecture are different between the client and the machine
<hazmat> but upload-tools will fail in this case
<hazmat> but the pull of binaries would work
<overm1nd> understand
<overm1nd> and the pull is based on the arch param I will pass right?
<hazmat> overm1nd, no.. thats ignored.. for manual provider juju is going to inspect the machine via ssh and determine the architecture
<overm1nd> ok
<hazmat> manual provider == docean plugin
<overm1nd> thank you I will try to mess with the code to exclude the upload-tool
<hazmat> overm1nd, fix pushed to git
<overm1nd> you are super kind and fast!
<hazmat> overm1nd, your welcome.. let me know if that solves it for you
<overm1nd> sure
<overm1nd> hazmat working great :)
<hazmat> overm1nd, awesome, i'm gonna push a new release, there's a few other minor fixes.
<overm1nd> agree
<lazyPower> Hazmat are you still sprinting?
<hazmat> lazyPower, no.. just bcsaller ... i'm running :-)
<lazyPower> Zombies? :)
<hazmat> apocalypse happens
<lazyPower> I'm in your neck of the woods is why I ask.
<lazyPower> Next time we'll have to coordinate and have an outing
<hazmat> lazyPower, ah.. sounds good.. your dc or sf?
<lazyPower> I'm in DC until tomorrow afternoon
<onrea> marcoceppi: could you help me to completely remove juju and reinstall it from scratch! you may want to a glance at this thread: http://askubuntu.com/q/436975/152405
<marcoceppi> onrea: what platform are you on?
<onrea> can*
<onrea> Ubuntu 13.10
<onrea> 64 bit
<marcoceppi> onrea: sudo apt-get purge juju-core juju juju-local
<onrea> I've copied these two file manually to /var/cache/lxc/cloud-precise
<onrea> https://cloud-images.ubuntu.com/server/releases/precise/release-20140227/ubuntu-12.04-server-cloudimg-amd64.tar.gz (229 MB) https://cloud-images.ubuntu.com/server/releases/precise/release-20140227/ubuntu-12.04-server-cloudimg-amd64-root.tar.gz (223 MB)
<onrea> should I delete them, too?
<onrea> What about these packages: postgresql-9.3, charm-tools, cloud-utils
<rbasak> I'm getting "agent-state-info: '(error: template container "juju-precise-template" did not stop)'"
<rbasak> It's still going - just a particularly slow machine. I can recover afterwards, but is this timeout tunable anywhere?
<rbasak> I can't find any environments.yaml reference documentation.
<jcastro> lazyPower, wasn't there something in the queue to update owncloud?
<lazyPower> jcastro: yeah thats part of the ceph update that zchander wrote
<jcastro> is that in the queue I can't see it
<lazyPower> it needs a bit more work, but its coming along nicely
<lazyPower> i already reviewed it and sent it back with requested mods
<lazyPower> do you need the link?
<jcastro> yes please
<lazyPower> jcastro: https://code.launchpad.net/~xander-h/charms/precise/owncloud/ceph-support
<jcastro> that guy was on irc wasn't he?
<lazyPower> zchander: <-- he's here.
<jcastro> hey maybe we should have cherry picked the version upgrade
<avoine> anyone have ever seen an lxc machine that gets terminated as soon at it connect to the api server?  http://paste.ubuntu.com/7194643/
<jcastro>  agent-state-info: '(error: error executing "lxc-start": command get_cgroup
<jcastro>           failed to receive response)'
<jcastro> anyone see that before?
<hatch> hmm thats a new one
<jcastro> oh I know why, nevermind!
<jcastro> I am trying to LXC inside a local deployment, duh
<lazyPower> Jcastro the upgrade was incomplete. It needed the mysql db migrations
<jcastro> lazyPower, ahh, I see
<jcastro> hazmat, is `to: lxc:0` a valid line for a deployer file?
<jcastro> I want to stick all the services in this bundle on 0, in containers
<jcastro> but if I do "to: 0" for each service that's hulksmash right?
<avoine> nevermind, I forgot to add the backports on precise for lxc
<hazmat> jcastro, http://pythonhosted.org/juju-deployer/config.html#placement
<jcastro> yep I read that
<hazmat> double checking re 0..
<hazmat> jcastro,  yeah that should work kvm:0 and lxc:0
 * hazmat adds a unit test for that one
<hazmat> jcastro, in general if you can i recommend doing the co-location form especially for distributed bundles
<hazmat> jcastro, ie you can get the entire bundle into a single machine using colocated services  that's not the bootstrap machine
<hazmat> with containers
<hazmat> jcastro, otherwise when people are pulling in these bundles, their going to overload their machine 0 if they pull more than 1
<hazmat> er.. use more than one compact bundle
<jcastro> hazmat, this one is more specifically for a VPS case
<jcastro> like, I want to go cheap
<hazmat> jcastro, fair enough ... have you tried the docean plugin ? ;-)
<jcastro> I have not
<hazmat> jcastro, well its tailored made for the go cheap
<jcastro> are your instructions awesome?
<hazmat> jcastro, i think so.. they beat the heck out of the deployer docs .. ;-)
<hazmat> jcastro, https://github.com/kapilt/juju-digitalocean
<hazmat> jcastro, you tell me
<jcastro> I liked the docs, they provided examples, just not the one I was looking for
<jcastro> I'll give it a shot later today
<hazmat> jcastro, the wording on them is tortorous and geeky..  re deployer.. i could barely parse it and i wrote it.
<hazmat> jcastro, like what the heck does this mean "The serenade service is overriding the default deploy-with unit by explicitly specifying a unit index for the deployment. These are not unit id based but rather based on extant unit count of the remote service starting with 0."
<jcastro> I had never even heard of serenade
<hazmat> jcastro, its an example service in the placement docs of deployer
<jcastro> hazmat, I can fix it up, where do the docs live? I can do that later
<hazmat> jcastro, there in the source tree for deployer.. lp:juju-deployer
<hazmat> cd docs
<jcastro> ack
<hazmat> sphinx and rst :-)
<gnuoy> I was happily using the lxc provider this afternoon was suddenly it stopped working after a juju destroy-envirnment. I can bootstrap fine but when I try and provision a machine its gets stuck in pending. I've cleared out /var/cache/lxc/. The only smoking gun I can find is in the machine-0.log:
<gnuoy> ERROR juju runner.go:220 worker: exited "environ-provisioner": no state server machines with addresses found
<gnuoy> what state server machines is it referring to (or is this a red herring) ?
<rick_h_> rbasak: juju is making a change that breaks quickstart that they're aiming for 1.18. We've gotten through our original FFE, is there something we can do/file to let us get one more update in so that we don't have broken juju/quickstart combo in trusty?
<rbasak> rick_h_: this concerns me. What happens in the future if juju makes another change that breaks quickstart?
<rbasak> rick_h_: it sounds to me that --distro-only needs to be the default then.
<rbasak> Otherwise the juju-quickstart in Trusty could forever be broken.
<rbasak> jamespage: ^^
<jamespage> rick_h_, rbasak: this is a fix, not a new feature right?
<rick_h_> rbasak: yes, the email about it went out overnight. frankban we can support both paths right? e.g. it'll be backwards compatible and we're just missing the forward working side?
<rbasak> rick_h_: setting that aside...
<rbasak> Yeah
<rbasak> For the immediate problem, we can just distro-patch a fix or something.
<rbasak> No FFe needed for that.
<rick_h_> rbasak: jamespage yes, so this is a fix, they're moving where you get ip address info. Quickstart needs to grow support for the new location
<rbasak> But I do think there's a bigger problem here, and we need to address it. Otherwise we're just putting it off until after Trusty release, when we won't be able to fix it, or have far more limited options.
<rick_h_> rbasak: ok, thanks. We should have a fix before EOW.
<jamespage> yes - no FFe needed
<rick_h_> rbasak: well, I'm not sure even distro-only would help. The idea is that juju updated and we need to stay in sync. If they get a non-distory juju, from a ppa, then quickstat is in that ppa and would upgrade?
<rick_h_> we're getting a last minute heads up on the change before their stable release
<rbasak> rick_h_: we have the opportunity of fixing it in distro - we can upload both a new juju-core that breaks things, and a new juju-quickstart that can accomodate that change.
<rbasak> rick_h_: however, after release, if juju-quickstart in Trusty uses the PPA by default, then users using the distro juju-quickstart will get a new juju-core from the PPA, and that will forever be broken.
<rbasak> rick_h_: an SRU might be possible in that situation, but I don't think it's appropriate to have that breakage happen, and need an SRU, for end users.
<bloodearnest> I am trying to workaround public ip address changes on a unit not firing hooks by blocking in the hook, and waiting for 'unit-get public-address' to change
<rick_h_> rbasak: yea, good point and I follow it now.
<rick_h_> talking with frankban about it
<bloodearnest> but it never does, even after juju status is reporting a public ip
<rbasak> rick_h_: ack. To make it clear, I'm fine with uploading a fix for the immediate issue.
<rick_h_> rbasak: +1
<bloodearnest> I understand that some other charms use the same workaround, but I haven't found them
<rbasak> bloodearnest: I'm not an expert in this area. But my understanding is that your hook should exit, and you'll have a hook fire again when something changes.
 * rbasak isn't sure how that applies to public-address though
<bloodearnest> rbasak: sadly that doesn't yet work for public ip address changes
<rbasak> Ah
<bloodearnest> or volume changes
<rbasak> What's a volume change?
<bloodearnest> rbasak: when a new volume is added or removed from the instance
<rbasak> Is there a big piece I'm missing here? What does juju know about "volumes"?
<rbasak> Is there any documentation on that, please?
 * rbasak is interested.
<bloodearnest> rbasak: juju knows nothing about volumes yet, that's the problem :)
<bloodearnest> rbasak: charms know about volumes though
<rbasak> bloodearnest: you get a udev event there though, right? So you can call back into a hook context using juju-run.
<bloodearnest> rbasak: the postgresql charm would be a good place to look
<bloodearnest> rbasak: if you're running the development release, yes. We're in 1.16 in prod.
<bloodearnest> but I need to deploy this ASAP
<bloodearnest> rbasak: once 1.18 is out, then this hacky workaround will be replaced by a less hacky workaround :)
<rick_h_> rbasak: talked with frankban and we agree distro default will be done with this bug fix to make that work
<rick_h_> rbasak: the only thing we'll need to look at with you as a follow up is that we want anyone that gets quickstart from pypi to get the ppa by default
<rick_h_> rbasak: but you use that for the packaging in the distro, so we'll need to agree on some way to have that setting flipped. But that can go after we get 1.18 unblocked
<rbasak> rick_h_: ack. Hold fire for a few minutes though? otp.
<rick_h_> rbasak: rgr
<rbasak> rick_h_, frankban, jamespage: I filed bug 1301481. Is there a bug for the immediate issue?
<_mup_> Bug #1301481: juju-quickstart will be broken in Trusty after juju-core updates in its stable PPA <juju-quickstart (Ubuntu):Triaged> <juju-quickstart (Ubuntu Trusty):Triaged> <https://launchpad.net/bugs/1301481>
<rick_h_> rbasak: yep #1301464
<_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses <addressability> <api> <juju-gui> <juju-core:Triaged> <https://launchpad.net/bugs/1301464>
<rbasak> rick_h_: thanks. Just to check, we should have juju-core in Ubuntu and juju-quickstart in Ubuntu tasks for these, right, since we need to track when they are fixed in each corresponding Ubuntu package?
<rick_h_> rbasak: hmm, yes, you're right.
<rbasak> OK, thanks. I'll do that now.
<rick_h_> thanks rbasak
<rbasak> bloodearnest: ah, that makes sense. Thanks!
<jamespage> marcoceppi, gnuoy: nice easy one for either of you if you have time - https://code.launchpad.net/~openstack-charmers/charm-helpers/icehouse/+merge/213888
<marcoceppi> jamespage: ack
<jamespage> marcoceppi, ta
<webbrandon> Glad there is a manual environment.  Anything I should know about the manual environment usage. Set an 12.04 LTS server up as virtual machine host and install juju,python-pycurl, and openssh packages. anything else?
<marcoceppi> webbrandon: don't install juju, just install openssh
<webbrandon> damn, too late, lol
<webbrandon> marcoceppi: thanks
<tvansteenburgh> marcoceppi: make develop in amulet complains about missing setuptools...
<marcoceppi> tvansteenburgh: then your venv didn't setup
<marcoceppi> tvansteenburgh: make clean_all
<marcoceppi> then make develop
<tvansteenburgh> well i have to make venv first right?
<tvansteenburgh> marcoceppi: http://pastebin.ubuntu.com/7195228/
<marcoceppi> tvansteenburgh: ah, so python three venv isn't working
<marcoceppi> tvansteenburgh: what version of Ubuntu are you on?
<tvansteenburgh> trusty
<tvansteenburgh> 2 tvansteenburgh@trusty-vm:~/src/amuletâ« venv/bin/python --version
<tvansteenburgh> Python 3.4.0
<tvansteenburgh> tvansteenburgh@trusty-vm:~/src/amuletâ« venv/bin/python -m ensurepip
<tvansteenburgh> /home/tvansteenburgh/src/amulet/venv/bin/python: No module named ensurepip
<marcoceppi> tvansteenburgh: is python3-pip installed?
<webbrandon> how can I make juju treat my manual environment set up virtual machines on its own instead of using 'juju add-machine user@host' and more like when I add a service though say aws.
<marcoceppi> webbrandon: you can't
<marcoceppi> well, other than use maas
<webbrandon> man my typing is bad today
<tvansteenburgh> marcoceppi: just installed it
<webbrandon> marcoceppi: thanks,  Maybe I will try MASS.
<marcoceppi> tvansteenburgh: do a clean_all then make install again
<tvansteenburgh> same error
<tvansteenburgh> i wonder if i can install ensurepip with pip
<tvansteenburgh> heh
<tvansteenburgh> apparently not
<marcoceppi> tvansteenburgh: do you have python3-setuptools ?
<tvansteenburgh> yeah
<marcoceppi> the make file was written for saucy
<marcoceppi> so there is probably something missing
<webbrandon> if anyone is into Altcoin mining I would live you participation: https://github.com/webbrandon/mpos-charm (dont pay to much attention to readme, been a week since i updated it.)
<tvansteenburgh> marcoceppi: my python 3.4.0 is missing what stdlib module for some reason
<tvansteenburgh> s/what/a/
<tvansteenburgh> so maybe not the makefile at fault
<marcoceppi> tvansteenburgh: wat
<tvansteenburgh> i can try reinstalling python from source i guess?
<marcoceppi> tvansteenburgh: uhhhh, I wouldn't
<tvansteenburgh> yeah, no `ensurepip`
<marcoceppi> tvansteenburgh: I was looking at this
<marcoceppi> http://bugs.python.org/issue19406
<marcoceppi> ntos ure if it helps
<webbrandon> sorry to be buggin today.  Im am working with manual environment on 12.04 LTS as virtual machine host and when I want to add a new machine it says :ERROR machine is already provisioned.  Tried all methods of adding but it gives me the same everytime,  what did I miss or is something wrong?
<webbrandon> or do I actual need to creat my own virtual machines and connect to those?
<webbrandon> think I missunderstood the manual environment.  SWitching to MASS per your suggestion marcoceppi
<tvansteenburgh> marcoceppi: got it to work with this:
<tvansteenburgh> -       python3 -m venv venv
<tvansteenburgh> +       python3 -m venv venv --without-pip
<marcoceppi> tvansteenburgh: cool
<marcoceppi> tvansteenburgh: makes sense since we install pip later on
<tvansteenburgh> right
<marcoceppi> tvansteenburgh: pull req welcome :)
<tvansteenburgh> yeah, will do
<tvansteenburgh> twittersphere just sent me this: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847
<_mup_> Bug #1290847: Command "python3 -m venv" fails if "--without-pip" isn't given <python3.4 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1290847>
<marcoceppi> tvansteenburgh: yeah
<dannf> no.. when you setup a private openstack cloud - how does juju know what images map to what releases, etc? is it expected that you setup your own simple stream of data?
<dannf> s/no/so/
<lemao> ok, I got the same "[Errno 111] Connection refused" again but this time while using JujuBox. The issue showed up after I vagrant suspend and vagrant resume
<lemao> The issue is shown in the juju-gui
<lemao> maybe there is a service not running after a reboot?
<lemao> I can actually access wordpress (the juju I deployed) fine, but not juju-gui
<rick_h_> lemao: is this in Firfox?
<lemao> safari
<rick_h_> lemao: there's a known issue where firefox has issues re-establishing the websocket connection when the machine the gui runs on is reboot
<lemao> rick_h_: and this was working yesterday with a fresh JujuBox vagrant box launched
<lemao> rick_h_: is there a workaround?
<rick_h_> lemao: looking for the bug second
<rick_h_> lemao: hmm, so using chrome worked. Closing and reopening the browser maybe? It's a card of work to investigate atm
<lemao> rick_h_: ok. Let me try it.
<webbrandon> okay getting started with maas has raken longer then exprected
<webbrandon> only reason im doing this is because of aws storage size for single host.  they need to make tools that integrate their server environments directly into their S3 bin by default when reaching local capacity ;0)
<Fishy__> where do the logs go for the maas server you can normally HTTP to
<mwhudson> Fishy__: /var/log/mass on that host iirc
<mwhudson> er maas obv :)
<Fishy__> celery.log is showing the wrong ip, hummm
<Fishy__> or maybe my webserver isn't running at all?
<bac> hi marcoceppi, i've proposed a branch for charm-tools that i'd like you to look at when you've got a chance: https://codereview.appspot.com/83700043.  it makes it easy to point charm-proof at different instances of charmworld for bundle proofing.
<Valduare> hows it going guys
<sarnold> hey Valduare :)
<sarnold> lazyPower: see? no waiting three hours :P
<Valduare> lol
<Valduare> very nice
<Valduare> im getting this channel trained up right! :P
<lazyPower> sarnold: clever :P
<sarnold> lazyPower: :D  <3
<Valduare> if I brew uninstall juju
<Valduare> how can I make sure everything is cleaned up
<lemao> rick_h_: It seems that a service was not running in the juju-gui machine. I had to 'sudo restart jujud-unit-juju-gui-0' and it is now working
<lemao> rick_h_: maybe the Javascript cached in the browser was trying to connect to the missing service.
<lemao> one other problem I am having with this Vagrant/JujuBox setup: juju debug-log # I get: Permission denied (publickey,password).
<lemao> however, juju ssh testcharm/0 works fine
<lemao> what is juju debug-log trying to do? ssh into each of the machines?
<Valduare> how much memory does juju-bootstrap vm need
<lemao> ok, debug-log is trying to ssh into machine-0, which doesn't have the juju key in the authorized_keys file. This seems to be a problem with JujuBox
<lemao> wellll, the private key has a paraphrase so this must be another f...g user error
<lemao> thanks for listening :-)
<Valduare> gah
<Valduare> i dont get it
<Valduare> iâve made all new vmâs and cant provision them
<davechen1y> Valduare: what output are you seeing ?
<Valduare> hmm
<Valduare> think I just found something odd
<Valduare> the juju-bootstrap my user account on thereâs using my sparkleshare id_rsa key  not the one from .ssh/ dir
<Valduare> ugh
<Valduare> re-installing the vmâs again from scratch and this time doing a snapshot of fresh install lol
<Valduare> question
<Valduare> since my VMs are behind NAT
<Valduare> should i be tunneling into the juju-bootstrap?
<Valduare> so it can run the commands with their local ip
<Valduare> instead of trying to port forward specific ssh ports for each vm
<lemao> Ok, I destroy'ed and up'ed the JujuBox vagrant box, vagrant ssh'ed into the box and juju debug-log will not work - so this doesn't seem to be a user error. Where should I report this?
<webbrandon> arrg can't get by commisioning
<davechen1y> Valduare: before we move on to that question, i'm still waiting for detalis for your first request of 09:42
<Valduare> my history dosnt go back that far
<Valduare> what did i say
<davechen1y> 09:38 < Valduare> iâve made all new vmâs and cant provision them
<davechen1y> 09:38 < Valduare> iâve made all new vmâs and cant provision them
<davechen1y> 09:38 < Valduare> iâve made all new vmâs and cant provision them
<davechen1y> 09:38 < Valduare> iâve made all new vmâs and cant provision them
<Valduare> ah
<davechen1y> < Valduare> iâve made all new vmâs and cant provision them
<Valduare> so I blew away the vmâs and started from scratch
<Valduare> even uninstalled juju with brew uninstall
<Valduare> then re-installed 1.17.7
<Valduare> and it is not able to add machines
<Valduare> no host found
<Valduare> going to log into ubuntu brb
<ghartmann> can we bootstrap envs in the trusty 14.04 beta ?
<davechen1y> ghartmann: yes and no
<davechen1y> yes you can deploy cs:trsuty/ubuntu
<davechen1y> but that is about it
<ghartmann> I am getting an error when trying to bootstrap
<ghartmann> and it seems to be related with 1.17 solved in 1.18
<davechen1y> ghartmann: can you give some details please
<ghartmann> sudo juju bootstrap used to work on 13.10
<ghartmann> it seems that now we can't run it as sudo
<davechen1y> ghartmann: which provier are you using ?
<ghartmann> local provider
<davechen1y> ghartmann: do the docs say to use sudo ?
 * davechen1y isn't sure, this has changed
<davechen1y> oh look
<davechen1y> they do say you have to use sudo
<ghartmann> it used to require sudo, somewhere on the webpages
<davechen1y> yup, docs are wrong
<ghartmann> but it seems that now it won't need it anymore
<davechen1y> juju will ask if it needs sudo permissions
<ghartmann> the error I get now is
<ghartmann> ERROR bootstrapping a local environment must not be done as root
<ghartmann> but without sudo it giver panic
<ghartmann> gives
<ghartmann> "panic: runtime error: invalid memory address or nil pointer dereference"
<davechen1y> ghartmann: can oyu paste the full panic message
<ghartmann> on the channel ?
#juju 2014-04-03
<davechen1y> paste.ubuntu.com
<ghartmann> http://paste.ubuntu.com/7196567/
<davechen1y> ghartmann: ok, i'll log a bug
<davechen1y> it will be related to your config
<davechen1y> backup .juju
<davechen1y> delete it
<davechen1y> juju init -w
<davechen1y> and try again
<ghartmann> error: flag provided but not defined: -w
<ghartmann> it seems that force is the only flag there
<davechen1y> sorry, that has changed as well
<davechen1y> the whole thing might have changed to be juju generate-config
<davechen1y> https://bugs.launchpad.net/juju-core/+bug/1301663
<_mup_> Bug #1301663: cmd/juju: panic during bootstrap <juju-core:Triaged> <https://launchpad.net/bugs/1301663>
<ghartmann> ah thanks
<davechen1y> ghartmann: with a fresh config
<davechen1y> does the panic still happen ?
<davechen1y> ghartmann: what I would like to do is find the specific yaml stanza thta is causing the panic
<davechen1y> so we can make a test case
<ghartmann> I get ERROR environment has no access-key or secret-key
<ghartmann> sorry it's on amazon provider
<davechen1y> ghartmann: hang on, you just said you were using local
<ghartmann> ok
<ghartmann> it seems to work
<davechen1y> ok, so lets deal with these problems one at at time
<davechen1y> ghartmann: juju destroy-environment -y local
<davechen1y> then put the old .juju back
<davechen1y> or just the local: stanza from your config
<davechen1y> and see if it happens agian
<ghartmann> I installed juju, ran init, switched to local, created the ssh keys and bootstrap
<ghartmann> this time I ran already had the sshkeys created, ran generate config, switched to local and bootrapped
<davechen1y> ghartmann: can you put your original .juju back and see what happens ?
<ghartmann> I have removed it before
<ghartmann> what I have noticed is that beforehand the ssh folder in .juju didn't have the keys there
<ghartmann> and now it has
<ghartmann> it seems that when the config is generated it copies the folder in
<davechen1y> yes, i think it does that
<ghartmann> so the problem seems to be related with the sequence
<ghartmann> anyway it works now
<ghartmann> I just need to configure the bridge and should be good to go
<ghartmann> thanks !
<davechen1y> ok
<ghartmann> by the way, to setup the bridge. is there a better way to expose lxc services to the internal lan ? I am going through setting up the bridge manually
<webbrandon> if im gonna use maas for virtual machines and juju i have to install LXC on my MAAS server correct?  Not to familiar with this yet, but running lxc-create now for node, hope im on the right track
<Valduare> interesting
<davechen1y> webbrandon: false
<webbrandon> wha, wha. damn. need to find some more straight forward docs
<davechen1y> webbrandon: if you want to use maas for virtual machines the way we deploy openstack is this
<davechen1y> 1. deploy maas controller
<davechen1y> 2. enroll all the machines with maas
<davechen1y> 3. deploy a juju environment on your maas cluster
<davechen1y> 4. use juju to deploy openstack
<davechen1y> and scale out the various services like storage and compute to consume all the available macines on your maas cluster
<davechen1y> 5. optional, use juju to deploy environments on your openstack cloud
<davechen1y> webbrandon: you +could+ use maas and manually call add-machine to create virtual machines on those physical maas nodes
<davechen1y> but you'd probably find that the networking gets all screwed up
<Valduare> hook failed : config changed   unexpected token near fi
<Valduare> err unexpected token 'fi'
<webbrandon> davechen1y thank you
<davechen1y> Valduare: this is coming from your hook
<davechen1y> which is written in bash
<davechen1y> which has a syntax error
<davechen1y> win8
<davechen1y> how many times am i going to do that today ?
<Valduare> it didnt throw this error last time I did the same charm
<davechen1y> Valduare: that may be true, but that doesn't mean there isn't a syntax error
<Valduare> how do I find out which line from the logs
<Valduare> oh it did tell me
<Valduare> line 33
<Valduare> looking now
<Valduare> ok so how can I fix the syntax and re-try deploying
<davechen1y> Valduare: this is a local charm ?
<Valduare> do I use the juju tools and copy it locally?
<davechen1y> Valduare: this is a local charm ?
<Valduare> ya
<davechen1y> juju help upgrade-charm
<Valduare> http://pastebin.com/83r1Uwn2 I dont see a syntax error on line 33
<lemao> Ola. I see that subordinate services are used for things such as AWS ELB or RDS. What I don't understand is how can I model an RDS instance that can be used by a number of services
<Valduare> ah and oddly it just turned green all by itself
<overm1nd> marcoceppi did I get some time to work on the wordpress charm?
<ghartmann> is there a recommended way to setup lxc provider network as a bridge ?
<stub> Once a peer relation is joined, will a unit remain in it until the unit is destroyed? Even if it is the only unit in the service for a period of time?
<stub> It seems to be, but I'm unsure if that can be relied on
<stub> If it *can* be relied on, then I might be able to work around the split-brain problem in Bug #1258485
<_mup_> Bug #1258485: support leader election for charms <juju-core:Triaged> <postgresql (Juju Charms Collection):New> <https://launchpad.net/bugs/1258485>
<stub> (if a unit joins a relation that has never had a leader, then unit 0 will become the leader even if it hasn't joined yet)
<stub> no, that still fails in a pathalogical case (dropping unit 0 before the other units can see each other in the peer relation)
<lazyPower> stub: i'm not sure i understand the question
<lazyPower> are you asking if the peer relationship membership remains after the peer'ing units are destroyed?
<stub> It doesn't matter... but I was asking if it remained when all-but-one units were destroyed
<stub> Create a single unit service, the unit isn't in the peer relation. Add a new unit, both get added to the peer relation. Remove one unit, and the remaining unit remains in the peer relation.
<lazyPower> stub: its in the pool, but the hooks dont fire
<lazyPower> so yeah its still in the relationship, but wit only one unit, the hooks wont fire against themselves.
<bloodearnest> is there documentation that lists what hooks are called in what order when?
<bloodearnest> so juju upgrade-charm calls upgrade-charm and then config-changed?
<bloodearnest> actually, that's the other way round I think - config then upgrade
<lazyPower> bloodearnest: you were right the first time
<lazyPower> upgrade-charm, *then* config-changed
<lazyPower> then any peering hooks on peer-config-changed
<bloodearnest> lazyPower: so, interesting question then:
<bloodearnest> upgrade-charm deploys my new payload, and restarts the server. This fails because the config format has changed slightly, and the new code can't process the old config format, so the hook fails
<bloodearnest> lazyPower: this is a "fat" charm, as currently being discussed on the ML
<lazyPower> bloodearnest: charms have to retain backwords compat, what you're prposing would fail charm store review
<lazyPower> even if the config value is not used, it should be marked in the config description as depreciated, and handled appropriately
<bloodearnest> lazyPower: yeah, but it's never going in the charmstore...
<lazyPower> wait i may be goig overboard, the config of what?
<lazyPower> you mean the charm config? or do you mean the service config?
<bloodearnest> lazyPower: by config format I mean application config format, not charm config, which hasn't changed
<lazyPower> ahhhh ok, sorry i went overboard :)
<bloodearnest> heh
<lazyPower> a bit preoccupied with my active sprint
<Valduare> morning
<bloodearnest> so in this case, an app under rapid development, a config value changed from a list to a dict
<lazyPower> well there are 2 things you can do. Either fully depreciate the old config of the application, and do a full upgrade with a backup of the environment dropped in /mnt, or have a precondition check with 2 paths to handle the application version, one for the old app + config, and one for the new app+config
<bloodearnest> right
<lazyPower> this is trivial when using config management solutions like ansible, you write 2 sep. roles and assign the role based on the predicate configuration value
<lazyPower> Valduare: o/
<bloodearnest> or just juju resolved, as the config-changed hook will fix everything :)
<bloodearnest> lazyPower: am using ansible
<lazyPower> bloodearnest: i would suggest not restarting the service until config-changed has run then
<lazyPower> so it upgrades the app along with the configuration before the restart
<bloodearnest> lazyPower: ah yes - that sounds better
<arosales> marcoceppi: if you exited a relation gracefully would you see relation broken?
<arosales> or does one _always_ see relation broken and departed with gracefully severing a relation?
<marcoceppi> arosales: yes, you'll always get a relation-broken event
<arosales> ah ok
<arosales> marcoceppi: thanks for the clearification
<arosales> tvansteenburgh ^
<arosales> tvansteenburgh: that was my misinterpretation
<bloodearnest> lazyPower: turns out, that was exactly what I was doing, problem was the config-changed hook not doing *all* configs
<lazyPower> bloodearnest: but you have a clear path moving forward. *thumbsup*
<jcastro> does anyone have time to review/fix up the issues with owncloud?
<tvansteenburgh> jcastro: is that something i can do?
<ValDuare> what command removes a dead machine from juju
<tvansteenburgh> juju destroy-machine <machine_num>
<jcastro> tvansteenburgh, yeah but post-sugar
<jcastro> we also have seafile, which is apparently awesome: http://manage.jujucharms.com/~negronjl/precise/seafile
<ValDuare> tvansteenburgh: that just puts it to life: dead   mode
<ValDuare> im on manual provision
<tvansteenburgh> ValDuare: ok sorry, i don't know anything about manual provisioning
<jcastro> does remove-machine not work?
<ValDuare> let me see
<ValDuare> nope
<jcastro> what does juju say the status is of the machine in `juju status`?
<frankban> rbasak: I erroneously marked bug 1301464 as committed in quickstart, switched back to confirmed. could you please re-triage it? thanks
<_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses <addressability> <api> <juju-gui> <juju-core:Fix Committed by wallyworld> <juju-core (Ubuntu):Triaged> <juju-quickstart (Ubuntu):Confirmed> <https://launchpad.net/bugs/1301464>
<rbasak> frankban: no problem. DOne.
<mbruzek> Hi #juju
<mbruzek> question for you
<mbruzek> According to the log config-get returns an int in scientific notation and that makes it hard to do math on the value.
<mbruzek> 2014-04-03 16:04:47 INFO config-changed ++ config-get upload-maxsize
<mbruzek> 2014-04-03 16:04:47 INFO config-changed + upload_maxsize=3e+07
<mbruzek> Is config get supposed to return 3e+07 ?
<frankban> rbasak: thanks! also I have a question for you and jamespage: we have a branch introducing joyent support in quickstart, not yet landed. it's few code but it's also a nice new feature (for quickstart and juju-core 1.18 itself). Should we keep that out for now? I mean, until we fix the bug introduced by core changes and we rebuild the distro package? We'd like to include that, but if you prefer otherwise it's not a prob
<frankban> lem
<marcoceppi> mbruzek: not really, I've never seen this
<marcoceppi> mgz: have you seen juju truncate long numbers? ^^
<mbruzek> 30000000 is less than max int for 32 bit values, but in scientific notation I can not get bc to use it.
<tvansteenburgh> here are my solutions: http://pastebin.ubuntu.com/7199425/
<mgz> marcoceppi: is that just the log though?
<rbasak> frankban: as you have probably guessed that branch would need a feature freeze exception. It's easiest for me if you don't land it and release without it.
<rbasak> frankban: the alternative would be for me to cherry-pick the specific fixes we need in a distro patch taken from bzr commits, without bumping the upstream version number.
<mbruzek> mgz I don't think so, I get a syntax error when using bc and can repeat the syntax error when I use scientific notation
<rbasak> frankban: that's only slightly more work for me, if the number of commits I need to cherry-pick are small, and they all apply correctly without conflicts.
<frankban> rbasak: ack, so I mean, it's not possible to include both the new feature and the bug fix as part of that exception, correct?
<rbasak> frankban: if you want an exception, you only need it for the feature. Bugs don't need exceptions.
<rbasak> frankban: then we can land it all together. If you want to do it that way.
<rbasak> frankban: you'll need to get the exception approved in time though, and I assume the release team are pretty busy given how long it took them to approve the previous exception.
<rbasak> frankban: Laney also asked for more QA assurances for future exceptions, so we'll want to document that too. I can certainly prepare the proposed package first and put it in a PPA for testing.
<frankban> rbasak: OIC. so I guess we'll just release 1.3.1 with the bug fix. I believe it will be readu Mon or Tue
<rbasak> frankban: sounds good.
<marcoceppi> tvansteenburgh: <3
<frankban> rbasak: it will include the bug fix for juju-core mega-watcher and the --ppa flag, for discriminating between distro and pypi packages. I planned to have a module including something like JUJU_CORE_SOURCE = 'ppa', what can be changed to 'distro' to switch defaults
<mgz> mbruzek: I don't see any uses of float format verbs in our code. are you sure it's not specific to that charm?
<rbasak> frankban: that sounds great
<frankban> rbasak: cool thank you
<mbruzek> mgz upload-maxsize:
<mbruzek>     type: int
<mbruzek>     default: 30000000
<mbruzek>     description: "Maximum file size (in bytes) that users can upload into Sugar as attachments."
<rbasak> frankban: please just makes sure that it only includes bugfixes though, so that we don't find later that we have to ask for an exception
<mbruzek> mgz I do not get that value as a number out of config-get
<frankban> rbasak: sure, just those two changes, no new features, just a new patch number version, sounds good?
<rbasak> frankban: sounds great :)
<marcoceppi> mgz: why not do smart filtering?
<marcoceppi> err mbruzek ^^
<marcoceppi> mbruzek: like 30M for 30 Megabytes
<marcoceppi> 1G
<marcoceppi> etc
<mbruzek> The number has to be in bytes for the sugar config file, but in MB for the php file
<mbruzek> So either way I have to do math on it.
<marcoceppi> mbruzek: it'd be better to do MB from user input
<mbruzek> I defaulted to the byte number that sugar admins would be used to
<marcoceppi> to bytes for sugar
<mbruzek> I could also change it to a string
<mbruzek> But it is an int, and I thought that should work.
<mbruzek> sugar admins are used to setting 30000000
<mgz> mbruzek: to be clear, what does config-get in a hook return? a mangled version or the bytes?
<mbruzek> mgz config-get returns with the scientific notation
<mgz> you should be able to reproduce with a stub charm then, and file a bug
<mbruzek> 2014-04-03 16:45:53 INFO config-changed ++ config-get upload-maxsize
<mbruzek> 2014-04-03 16:45:53 INFO config-changed + upload_maxsize=3e+07
<mbruzek> against juju-core?
<mgz> yes.
<mgz> a skeleton charm with config.yaml with one entry, a config-changed hook, and a tests/ script should reproduce
<dannf> i've got some ARM64 vms, on which i'm trying to deploy with the manual provider.
<dannf> bootstrap: done. juju-gui deployed to bootstrap node: done (and working)
<dannf> but i juju add-machined a couple other nodes and, while add-machine completes w/o error and the agent is running, juju status shows the nodes stuck in pending
<dannf> machine-0: 2014-04-03 18:14:16 WARNING juju.worker.instanceupdater updater.go:231 cannot get instance info for instance "manual:10.0.128.7": no instances found
<dannf> is what debug-log shows
<webbrandon> arrg I am having a hell of a time trying to get MAAS to act the way I want.
<webbrandon> im done messing with it for now. Just have to spend out my behind to use service for now.
<webbrandon> actually I am just going to follow marcoceppi tut.  Not what I want but I guess good for the interm of testing
<webbrandon> not tut - blog post
<xagaba_> Any place to get info about net-ju ?
<bac> sinzui: hey do you know who is working on the joyent support?  anyone that might currently be around?
<sinzui> bac, bodie_ and wallyworld_  in #juju-dev
<bac> thanks sinzui
<xagaba_> It's possible to deploy juju in a couple of servers to use only LXC as cloud machines ?
<marcoceppi> xagaba_: yes, you can use deploy --to lxc:<machine-num>
<xagaba_> marcoceppi: any place to get info about such deploy mode ?
<marcoceppi> xagaba_: https://juju.ubuntu.com/docs/charms-deploying.html#deploying-to-machines
<sarnold> cool!
<xagaba_> marcoceppi: thanks, I take a look
<themonk> what does it mean by "instance-state: missing" ?
<perrito666> nessita: well? talk
<perrito666> :p
<nessita> hello everyone! my units are not moving from the pending state, log shows:
<nessita> 2014-04-03 19:54:54 ERROR juju.worker.uniter.charm git.go:211 git command failed: exec: "git": executable file not found in $PATH path: /var/lib/juju/agents/unit-solr-jetty-0/state/deployer/update-20140403-165454781105382 args: []string{"init"}
<nessita> complete logs: https://pastebin.canonical.com/107753/
<nessita> I ssh'd into elasticsearch/0 and confirmed the unit can access the internet
<nessita> Until yesterday I was running saucy with juju/stable + juju/devel PPA's
<nessita> yesterday I upgraded to trusty
<nessita> and since the units were not starting, I cleaned up everything and retried
<nessita> same error
<nessita> any ideas? :-)
<themonk> what does it mean by "instance-state: missing" ?
#juju 2014-04-04
<mischief61507> hi, can someone tell me the purpose of admin-secret for openstack config?
 * davechen1y looks in the source
<davechen1y> hmm, it's not openstack specific
 * davechen1y looks in the base config
<davechen1y> ok, its the admin password for your environment
<davechen1y> you should leave it unset
<mischief61507> ok
<mischief61507> when i did generate-config, it automatically inserted a default
<mischief61507> it put an admin-secret and control-bucket. i am using 12.04 lts for my host os, and installed juju with https://juju.ubuntu.com/install/ instructions for ubuntu
<davechen1y> mischief61507: oh sorry
<davechen1y> yes
<davechen1y> it's been so long
<davechen1y> admin-secret is a passphrase for your environment
<davechen1y> it should be private
<davechen1y> and unique
<davechen1y> control bucket is the name of the storage bucket
<davechen1y> which will hold stuff about your environment
<davechen1y> if you have two ec2 environments, say, then the control bucket must be unique
<davechen1y> otherwise shit will get crazy
<mischief61507> is admin-secret something i have to set on the openstack side or is that used to bootstrap it
<davechen1y> mischief61507: it is the root password to your juju environment
<davechen1y> it applies for all juju environments
<davechen1y> it's not openstack specific
<davechen1y> so has no relation to any other openstack credentials
<mischief61507> looks like i forgot to set up swift on my openstack haha
<davechen1y> mischief: yea, you need some kind of object storage to put juju stuff in
<davechen1y> specifically the tools and charms tarballs
<themonk> marcoceppi: hi
<themonk> is there any firewall between unites in juju
<davechen1y> themonk: depends on the provider
<themonk> its lxc container on my local machine
<themonk> davechen1y: its lxc container on my local machine
<davechen1y> themonk: what is your question
<davechen1y> themonk: are you asking why you cannot connect to lxc machines remotely ?
<themonk> davechen1y: is there any firewall between unites in juju? that means that if <some-unit>/0 has a server running with a open port XXXX will <some-other-unit>/0 can make request it? is there any sort of firewall?
<davechen1y> themonk: yes and no
<davechen1y> in this case, no
<themonk> that means no firewall ryt
<davechen1y> davechen1y: i can't give you a clearer answer
<davechen1y> can you explain more abou the problem you have
<themonk> ok i will
<themonk> i have 2 charm, one of them is server, it take request from other charm, problem is server charm is not getting any request, before i file a bug I wanted to make sure that juju is not blocking it.
<rick_h_> mattyw: ping, this current user branch thing landing. What's this mean for real user authentication?
<rick_h_> mattyw: I'm worried about the GUI falling a chunk behind and not being usable
<davechen1y> themonk: if you are using the local provider there will most likely _not_ be a firewall between units
<davechen1y> however your charms may be using the wrong address to talk to each other
<themonk> davechen1y: thanks :)
<themonk> davechen1y: is ec2 has any firewalls between units?
<davechen1y> themonk: generally no
<themonk> davechen1y: thanks a lot man :) much appreciated
<davechen1y> np
<davechen1y> HA!
<davechen1y> func uploadFakeTools(stor storage.Storage) error { versions := []version.Binary{version.Current} toolsVersion := version.Current
<davechen1y> ^ ja'cuse
<davechen1y> version.Current is always the arch of the local machine !!!
<thumper> davechen1y: yes... yes it is
<davechen1y> booo
<rick_h_> mattyw: all good thanks
<rick_h_> mattyw: seems like the network hates you for the moment
<mattyw> rick_h_, we're very much off and on
<sinzui> rogpeppe, natefinch : can either you glance at wallyworld's MP to fix tests that prevent the release of 1.18. https://code.launchpad.net/~wallyworld/juju-core/fix-tools-tests-1.18/+merge/214159
<wallyworld> sinzui: sadly i have to rework them
<wallyworld> because
<wallyworld> the current code disallows upload-tools for released juju versions
<wallyworld> which is sensible
<wallyworld> but apparently people depend on it
<wallyworld> so i need to reinstate the dumb behaviour, but there's a several tests which fail (existing tests)
<wallyworld> so at some point certain code paths were run
<wallyworld> it messy :-(
<sinzui> wallyworld, Are you intimating that 1.18.0 will be releasable next week?
<wallyworld> sinzui: i hope to have a fix proposed soon, within an hour maybe
<sinzui> Well I don't think the version blocks cmars and jhobbs. I can merge those now.
<sinzui> wallyworld, If something looks grim. I can release everything as 1.17.8...a beta for 1.18.0 that is just a rename next week
<wallyworld> sinzui: ok, im hopeful so give me a little more time
<caribou> marcoceppi: niedbalski is working on a but on the nrpe charm that may be tied to the 'old' shell version of the helpers
<caribou> marcoceppi: though I have doubt as it seems to be the same code in the mysql charm & the behavior only happen with maas
<jcastro> https://juju.ubuntu.com/docs/howto-privatecloud.html
<jcastro> fresh new docs folks!
<avoine> nice
<overm1nd> marcoceppi I tried to open a bug for discourse charm but I got this error from launchpad: (Error ID: OOPS-48eaf11d28efcb274bb49c42de5f2ae2)
<overm1nd> basically is impossible to find the discourse charm submitting the big
<overm1nd> bug*
<jcastro> ~2 hours until our Charm School on Juju plugins
<jcastro> marcoceppi, ^^
<marcoceppi> overm1nd: the charm is on gh
<marcoceppi> overm1nd: https://github.com/marcoceppi/discourse-charm
<lemao> is there a property in the local provider to force juju to use an explicit ssh user?
<jose> lemao: is that local or manual?
<lemao> local
<jose> lemao: may I ask why? because afaik the local provider creates LXC for each machine
<lemao> jose: This is a Vagrant JujuBox with a vagrant user by default. It seems that juju show-log is trying to ssh into current box with user ubuntu
<jose> ah
<jose> gotcha
<lemao> jose: and jujubox provisions the authorized_keys in the vagrant user
<jose> lemme try and see if I get something
<lemao> jose: I can work around by copying the authorized_keys to the ubuntu user, but it would be nice to have it working smoothly
<jose> I don't seem to find something useful
<jcastro> lemao, that seems to be a bug in the box to me
<jcastro> we should make it like autogen keys or something
<lemao> jcastro: the vagrant user does have the key generated
<lemao> jcastro: but juju show-log is trying to ssh into ubuntu@10.0.3.1 instead of vagrant@10.0.3.1
 * jcastro nods
<lemao> jcastro: my first thought was that there may be a property I can add to the local env file to change this default
<lemao> jcastro, jose: https://bugs.launchpad.net/juju-core/+bug/1202682
<_mup_> Bug #1202682: debug-log doesn't work with lxc provider <cts-cloud-review> <debug-log> <local-provider> <papercut> <ssh> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1202682>
<jcastro> yeah that one is in progress
<jcastro> I just pinged them about it yesterday
<jcastro> lemao, tail the log in ~.juju/local/logs is the workaround there
<lemao> jcastro: thanks.
<jcastro> all-machines.log is quite handy
<lemao> jcastro: humm, I don't see all-machines.log there.
<lemao> jcastro: 1.16.6-precise-amd64
<lemao> jcastro: only machine-0.log
<jcastro> oh, after you deploy something
<jcastro> right now you just have the one machine
<lemao> jcastro: I see. I do have machine-1 with juju-gui, but that came with the JujuBox afaik. Ok, not important. Thanks.
<lemao> I do have a more general question, though, if I may ask, that is bugging me for a couple of days.
<lemao> I would like to support RDS machines. It seems like an alternative machine to the amazon provider. How does one support that in juju as it seems that the amazon always creates EC2 instances.
<lemao> After searching around, I realized that subordinate services may be the answer here. However, what about identity of the RDS instance that may be shared among multiple services across different machines?
<jcastro> yeah we haven't really done anything wrt. RDS
<jcastro> like, it'd be nice to just connect a mediawiki charm to an RDS instance instead of EC2/Mysql
<jcastro> ~30 minutes until our charm school on Juju Plugins! ^^ marcoceppi
<lemao> jcastro: right. It seems that each provider has a single 'type' of machine. In the amazon's provider, that is an EC2 instance. It would be nice if I could specify a machine type that is required (constraint?) and that would mean the charm is provider specific.
<lemao> jcastro: and the amazon provider would specify the default machine type and additional machines such as RDS
<marcoceppi> \o/
<lemao> jcastro: right now, it seems I can fake this with a subordinate service but to share instances I would have to assign a unique id/label to connect to the same RDS instance
<jcastro> that would be cool if it worked
<lemao> jcastro: is my thinking correct or are there ways/approaches I am not aware off?
<jcastro> lemao, I think provider-specific options in a charm are fine
<jcastro> lemao, I think so; though I'd confirm on the list as well
<jcastro> though it would be cool to have provider-specific subordinates for things
<jcastro> aws-s3-backup, etc.
<lemao> jcastro: is it possible to override the machine creation logic when a charm is deployed? I.e. let my charm take over the machine creation to manually instantiate an RDS instance.
<jcastro> lemao, I need to bail for a bit to run this charm school
<lemao> jcastro: ok. Thanks for the help
<jcastro> Ok we're going to be doing a videocast in about 10 minutes on http://ubuntuonair.com
<jcastro> the Topic is Juju Plugins!
<jcastro> we'll be taking and answering questions from this channel
<ppetraki> o/
<ppetraki> questions?
<sfeole> any plans on the juju test plugin supporting all of the manual provider ???   ;)
<sfeole> I use juju test, it's quite useful. I've only used it with EC2 providers. After watching the presentation, i don't mind taking a crack at some of the bugs i've found with the plugin. Perhaps making some MPs to it
<sfeole> ;)
<sfeole> ;) to the trolling comment
<ppetraki> sfeole, well, you're being ignored atm so...
<sfeole> cool
<ppetraki> ;)
<axisys> is there a juju/charm hangout today?
<sfeole> axisys: http://ubuntuonair.com/
<axisys> do I need to connect to the irc on the web to see the hangout? it is a black screen for me
<axisys> sfeole: ^
<sfeole> axisys: try reloading the page?
<axisys> I see it now
<sfeole> kewl
<axisys> thanks
<sfeole> thanks guys!
<axisys> thanka lot
<krondor> fun stuff
<lemao> hi all, is it possible to read environment properties from a charm? E.g. the amazon has the access/private keys that I would like to use in a charm.
<jose> lemao: you should be able to open the environments.yaml file and find that info
<marcoceppi> lemao: not from a charm not
<marcoceppi> no*
<lemao> jose: yeah, that would be an option. It has a couple of drawbacks though: every charm would have to perform the same exact work and it is a bit error prone if I don't select the current environment right.
<lemao> marcoceppi, jose: I am trying to create an RDS subordinate service hence the question. It would be a bummer if I have to reenter the keys in the charm configuration
<marcoceppi> lemao: there's already an RDS charm, and it is a bummer
<lemao> marcoceppi: this one? https://code.launchpad.net/~hazmat/charms/precise/aws-rds/trunk
<marcoceppi> lemao: yeah, that one
<lemao> marcoceppi: it is using 'awsjuju.services.rds'. Do you know what is that and how it is installed?
<marcoceppi> lemao: no idea
<hazmat> lemao, its a package that gets installed
<lemao> hazmat: $CHARM_DIR/bin/pip install awsjuju I see
<hazmat> lemao, most of the logic for my aws charms is in a python package that gets bootstrapped in install
<lemao> hazmat: what about the keys?
<hazmat> lemao, keys?
<lemao> hazmat: access/private aws keys
<lemao> ec2 keys
<hazmat> lemao,  go into the service config
<hazmat> lemao, i don't consider my aws charms production grade fwiw
<lemao> hazmat: sorry for the obvious question, I am getting up to speed with juju
<lemao> hazmat: I have the impression that juju-core needs a few additional changes to make this a bit smoother
<hazmat> lemao, https://github.com/kapilt/awsjuju is the backend logic, unit tests, etc for aws rds, aws elb, tagging, etc
<hazmat> lemao, you mean aws access key management ?
<hazmat> lemao, in particular rds implementation is here https://github.com/kapilt/awsjuju/blob/master/awsjuju/services/rds.py
<lemao> hazmat: something like 'env-get access-key'
<hazmat> lemao, that would be rather a bad idea think..
<lemao> hazmat: how so?
<hazmat> lemao, you want to pass your credentials to third-party code ?
<lemao> hazmat: yes, that is indeed a problem is you don't trust the charms.
<hazmat> lemao, i recommend iam for all such cases
<lemao> hazmat: what would be the ideal solution?
<lemao> hazmat: expand the amazon provider?
<hazmat> lemao, create an iam for each third-party charms that give them the exact access they need.. or an iam broker charm that can do the same..
<hazmat> lemao, i tried to include iam policies needed for each of my aws charms.. but doesn't look like the rds charm got one.. here's the elb charm iam policy for comparison http://bazaar.launchpad.net/~hazmat/charms/precise/aws-elb/trunk/view/head:/elb-policy.json
<lemao> hazmat: does RDS has support for IAM roles?
<lemao> hazmat: oh, I see.
<hazmat> lemao, this isn't quite iam roles.. this is create an iam identity with perms and hand those to the charm via service config
<lemao> hazmat: you create a individual user for each charm with their own access keys.
<hazmat> lemao, yeah
<lemao> hazmat: I don't see subordinate: true there in the aws-rds. Won't that create a new machine for this service when deployed?
<hazmat> lemao, use --to=0
<lemao> hazmat: I see. That smells like a unavoidable hack :-)
<hazmat> lemao, you can place workloads wherever you want
<hazmat> lemao, you don't have to create new machines for them
<hazmat> lemao, if you want it to run isolated do --to=lxc:0
<hazmat> lemao, using a subordinate would mean distributing access keys and creating extra units.. its a proxy charm.. only needs 1 unit.
<hazmat> lemao, yes there could be some simple notion of doing that for you based on metadata, but it amounts to the same, you need the charm to run somewhere.
<hazmat> and yes.. all the aws charms support running multiple units for ha .. they use  dynamodb for coordination
<ghartmann> it has happen with me a few times but some services fail to start they can't be deleted. I wonder if there is a flag like a force option
<lemao> hazmat: yes, makes sense. the rds service is a proxy service that interfaces with an external machine and it has to run somewhere in the current environment. Machine-0 is the most obvious place or so it seems
<lemao> hazmat: how are you handling things like smtp service (e.g. exim4)?
<lemao> hazmat: is that a plain service with subordinate: true?
<hazmat> lemao, smtp -> non subordinate charm.. ala postfix.. connect all the things that need it up.
<hazmat> saas email service might be better for aws though
<hatch> marcoceppi if you're ever looking for a broken charm again I wrote one which was designed to fail http://fromanegg.com/post/67488243238/a-juju-charm-designed-to-fail
<lemao> hazmat: yes, but SES has some mime restrictions that don't work for me
<hazmat> lemao, mailgun.. sendgrid.. etc
<marcoceppi> hatch: awesome, thanks!
<hatch> np, we use it in the GUI to test the failure paths :)
<hazmat> lemao, postfix/exim are going to run afoul of the spam blocks aws ip ranges
<hazmat> ^on
<lemao> hazmat: I see so if I want to use postfix I am basically creating a dedicated machine for it and have all the nodes connect to it
<lemao> s/connect/relate/
<hazmat> lemao, doesn't need to be dedicated.. you can place multiple workloads together if their compatible on the same machine
<hazmat> lemao, hence the --to syntax on deploy or add-unit
<lemao> hazmat: using --to I guess?
<hazmat> lemao, yeah.. juju deploy --help
<lemao> hazmat: which makes the order of deployment important
<hazmat> lemao, not really
<hazmat> lemao, which service goes onto the machine first doesn't matter.. the services communicate config via relations
<hazmat> and a good charm doesn't assuming ordering to relation creation
<lemao> hazmat: humm, but if I want to have postfix running on the same machine as ServiceA I will need to hard code a machine #
<hazmat> pretty much none of them assume ordering
<hazmat> lemao, that's unfortunate ... there's a feature request out there for --to=service for co-located services..  i've added a --to=service/a syntax in some tools i've built ontop of juju .. but thats not built-in.. http://pythonhosted.org/juju-deployer/config.html#placement
<hazmat> its a simple dsl for capturing env topologies/deployments into a yaml file.
<lemao> hazmat: yes, that would be nice. is this topology/deployment dsl being considered to be included in juju-core? It would be nice to be able to describe a set of machines and then assign services to them
<lemao> hazmat: (actually remember going through juju-deployer)
<hazmat> lemao, eventually.. lots of other tools build on deployer for bundle/dsl support..
<lemao> hazmat: finally, do you have apps in production using juju on AWS?
<lemao> hazmat: actually juju-gui could support first class machines along side services. Place a service in an empty canvas you get a machine wrapping a service. Place a machine you get just an empty machine. Place a service on an existing machine and then add the service there. This visual model would be easily translated to your dsl
<hazmat> lemao, personally no.. i do on digital ocean using https://github.com/kapilt/juju-digitalocean
<hazmat> lemao, gui is currently working on a machine view of the environment for placement as well
<hazmat> lemao, the pricing model on ec2 is a bit much for me to do personal projects there minus reserved instances.. i'm looking forward to gce getting ubuntu images.. cause their pricing is pretty nice basically baking usage discounts without the reserved instance pricing up front cost.
<dpb1`> is juju supposed to support deploying (for example) a trusty lxc to a precise bootstrap node with --to lxc:0 cs:trusty/ubuntu?  Seems it always ends up as a precise container.
<hazmat> dpb1`, it definitely should be a trusty container
<dpb1`> hazmat: :(
<hazmat> dpb1`, file a bug pls
<lemao> hazmat: never used digital ocean. Have been using AWS for 5+ years.
<dpb1`> hazmat: on it
<hazmat> lemao, fair enough. aws has lots going for it.
<hazmat> lemao, i maintain a few prod non juju aws envs.. their feature iteration is pretty impressive
<lemao> hazmat: yes, not the cheapest but they have been improving on it non-stop
<lemao> hazmat: looking at kapilt/awsjuju I was wondering: it would be quite nice if it was possible to create provides in the same way one creates charms (i.e. hooks, any language, etc)
<lemao> hazmat: s/provides/providers/
<lemao> hazmat: set of key events (install, create-unit, etc, etc)
<hazmat> lemao, yup.. its been discussed.. smoser is a fan.. the shell-script provider..
<hazmat> lemao, its sort of possible now.. that's basically how the juju digital ocean provider works.. it layers  on top of the manual provider.. to do client side provisioning.
<lemao> hazmat: it may be a temporary win until there is a stable provider that everyone can reuse and covers all features
<dpb1`> hazmat:  https://bugs.launchpad.net/juju-core/+bug/1302820
<_mup_> Bug #1302820: juju deploy --to lxc:0 cs:trusty/ubuntu creates precise container <landscape> <juju-core:New> <https://launchpad.net/bugs/1302820>
<hazmat> lemao, the issue with doing it server side is thats its problematic wrt to software install and upgrades across architectures..
<hazmat> lemao, yup.. that's exactly the goal i have with making client-side providers.. also works in the case where providers don't nesc offer all the features nesc for a core implementation (userdata etc).
<lemao> hazmat: nice to hear that these things are being worked on, or discussed. Was looking for some docs/info on juju directions...
<hazmat> lemao, just filed bug 1302825 for it
<_mup_> Bug #1302825: juju roadmap in the docs <juju-core:New> <https://launchpad.net/bugs/1302825>
<lemao> hazmat: thanks!
<lemao> hazmat: I find that juju provides a devops in-the-large that is much more interesting. Working with ansible, for instance, I end up slowly creating a framework on top of ansible to be able to quickly creating stacks etc. Juju provides that framewokr for me out of the box
<avoine> ls
<avoine> ls
<avoine> l
<lemao> hazmat: is there a repo for this shell-script provide by smoser? I could not find in his launchpad account.
<hazmat> lemao, that's funny.. i'm using ansible and juju together atm..
<lemao> hazmat: that makes sense to me ... juju in the large and ansible in the small
<hazmat> lemao, the shell script provider doesn't exist..  an extant client side provisioning plugin is the juju digital ocean provider.
<lemao> hazmat: I see. I will look at that then
<hazmat> lemao, well ansible in charms is supported as well. there's a couple of helpers we have to make it fairly seamless as an experience.
<hazmat> ie. single yaml file charm, with the rest just as generic support
<lemao> hazmat: I don't particularly care about ansible it just seemed a better option (simpler) than chef/puppet. But at the end of the day a charm may need to perform a few idempotent operations
<hazmat> lemao, juju has a built-in ansible light.. sort of thing.. juju run .. let's you run stuff/shell on selective sets of machine
<lemao> hazmat: interesting
<hazmat> lemao, yup.. also easy to review/audit
<hazmat> lemao, actually ansible light. is not accurate.. better is parallel ssh
<lemao> hazmat: I am actually evaluating juju for our company. So I appreciate the information and feedback. I will be getting more hands on in the next couple of weeks and see how that goes.
<ghartmann> when we have issues with particular charms ( gitlab in this case )
<ghartmann> should I be reporting the bugs ?
<marcoceppi> ghartmann: yes!
<ghartmann> how is the best way ?
<marcoceppi> ghartmann: on launchpad!
<ghartmann> btw, I am really happy with juju ! great work
<marcoceppi> ghartmann: https://bugs.launchpad.net/charms/+source/gitlab/+filebug
<marcoceppi> ghartmann: thanks! I know someone was working on fixing up the gitlab charm, I think it's lazypower-conf
<ghartmann> great, if we have a bugfix how can we push the code in for review ?
<marcoceppi> ghartmann: so, you'll want to run `charm get gitlab` if you haven't already, to branch the code. Then apply your fix and push to lp:~YOURLPUSERNAME/charms/precise/gitlab/trunk
<marcoceppi> then run `bzr lp-propose lp:charms/gitlab` that will start the merge proposal process
<marcoceppi> after you complete that it'll show up in our review-queue!
<hazmat> gitlabs.. very cool
<ghartmann> that sounds great, do you have the instructions on a webpage ?
<marcoceppi> ghartmann: yes, for the most part, https://juju.ubuntu.com/docs/authors-charm-store.html#submitting_fix
<ghartmann> thanks, I will set it up now
<ghartmann> found the issue that I was facing .. and got to a new one related with ruby
<ghartmann> bundle install modernizer seems to be removed
#juju 2014-04-05
<ghartmann> made some progress on the gitlab deployment, it seems to have the following issues  - release tag is incorrect ( the version deployed is corrupted ), the hook file is missing, it requires admin password but it's not clearly stated and it doesn't set the user/password in mysql when installing it
<AskUbuntu> Configure juju on Rackspace | http://askubuntu.com/q/443706
<jose> hey guys
<jose> can anyone give a reason on why bip appears twice in manage.jujucharms.com?
<lazyPower> jose: some funky bug. there are a few charms in the revq that show up twice
<jose> lazyPower: hmm, ok!
<jose> at a hackaton for the global jam now, trying to get some stuff fixed
<lazyPower> awesome!
<jose> lazyPower: have a minute?
<lazyPower> jose: whats up?
<jose> hey, do you know how could I delete this line <http://paste.ubuntu.com/7209610/> I add to a sql table?
<lazyPower> DELETE FROM 'jos_users' WHERE <fieldname of user admin> = 'admin'
<jose> thanks
 * jose got confused with that line
<lazyPower> crap, i found my issue with maas it hink
<lazyPower> missing pxe boot images therefore teh tgt server has nothing to serve
<lazyPower> and importing the pxe images is doing nothing
<jose> looks like someone is stressed!
<lazyPower> i've been poking at this trusty upgrade for the last 2 hours trying to puzzle out why its not booting the vm's
<lazyPower> i think i know why now
<lazyPower> i'm not sure if its pebkac or a bug
<lazyPower> bah i'm going to go play steam and deal with this later
<jose> that's a pretty good idea
<jose> enjoy your afternoon!
<minja> hello
<jose> hey minja
<lazyPower> and yet again a reinstall + some configuration magic seems to have done the trick on resolving the issue.
<lazyPower> man that was strange
#juju 2014-04-06
<hazmat> smoser, ping.. how was the game..
#juju 2015-03-30
<blahdeblah> Hi all.  I'm trying to learn enough amulet to get my charm accepted: https://bugs.launchpad.net/charms/+bug/999439  Are there any examples of charms which get the "charmers seal of approval" for good amulet tests?
<mup> Bug #999439: Need charm for quassel-core <new-charm> <Juju Charms Collection:In Progress by paulgear> <https://launchpad.net/bugs/999439>
<blahdeblah> And a related question: Is there a recommended workflow for getting local results from my tests rather than having to wait for them to churn through the various cloud testing setups?
<stub> blahdeblah: Setup a makefile so that 'make test' runs your tests against an environment you already have bootstrapped (with JUJU_ENV set if it is not your default).
<stub> blahdeblah: Or there is a new docker image that can be used to get the same environment as the jenkins setup. Similar process, except you run the tests inside the vm.
<blahdeblah> stub: Thanks - I might have a look into those next time.  Next Q: if I want to run the same set of tests against a precise deploy and a trusty deploy, what's the best way to do it?  I don't want to duplicate whole modules.
<stub> I stick "SERIES := $(juju get-environment default-series)" at the top of my Makefile, then reference that environment variable.
<stub> So it uses the default series, unless I override it on the make command line.
<stub> The jenkins setup sets up the juju environment to have a default series corresponding to your branch, so you unfortunately need to push your branch to two locations to get it to run the tests against two series.
<blahdeblah> Cool - thanks stub
<stub> blahdeblah: Were you doing ntp charming? I have a charm where the units require clock syncronization. At the moment I'm just installing the ntp package, but was wondering if that is good enough.
<blahdeblah> stub: I was helping bradm with it a bit
<stub> I could say 'you must also use this subordinate', but it would be nice if that was optional.
<blahdeblah> stub: If you really want it to work, you need to deploy a few ntp masters, then deploy ntp clients (which will auto-relate to the masters) on the hosts whose clocks you want synchronized.
<stub> Cause now I think of it just installing the package will fail with some egress restrictions.
<blahdeblah> NTP egress restrictions, or something else?
<stub> NTP egress restrictions
<stub> Is there a reason I can't rely on the default NTP masters you get when you install the ntp package? Apart from egress?
<apuimedo> gnuoy`: hi
<apuimedo> where does the nova-api-metadata server run on a default juju openstack deployment?
<lukasa> apuimedo: nova-cloud-controller, I believe
<lukasa> apuimedo: Though Calico installs and runs it as part of its neutron-calico subordinate charm
<apuimedo> lukasa: I can't find it there
<lukasa> I think it's part of nova-api, which does run there
<apuimedo> I saw it only in the quantum-gateway charm
<lukasa> Oh interesting
<lukasa> This isn't a problem we had because we distribute nova-api-metadata, so maybe it is only part of quantum-gateway
<apuimedo> ;-)
<lukasa> When it comes to the quantum-gateway charm I know almost nothing about it because we don't use it. =d
<apuimedo> lukasa: I saw that you put it as a required service for Calico in the charm-helpers ;-)
<apuimedo> (nova-api-metadata, I mean)
<lukasa> Yeah. =) Wherever we can we distribute services as widely as possible, nova-api-metadata is one of them.
<apuimedo> ;-)
<lukasa> No reason to have metadata queries wandering all over the network if we can avoid it
<apuimedo> true
<lukasa> But having it in quantum-gateway sounds plausible too
<lukasa> Though I expect that if you don't add neutron-api, it runs on nova-cloud-controller
<lukasa> Regardless, try making a metadata query to nova-cloud-controller and see what happens, I wouldn't be surprised if it responds
<lukasa> (I don't have a juju deployment up at the minute)
<apuimedo> celebdor@nx02 ~/code/nova-cloud-controller $ bzr grep nova-api-metadata
<apuimedo> hooks/charmhelpers/contrib/openstack/neutron.py:                         'nova-api-metadata'],
<apuimedo> hooks/charmhelpers/contrib/openstack/neutron.py:                          'nova-api-metadata']],
<lukasa> =) I mean literally spinning one up and then curling the endpoint. =)
<apuimedo> and I believe those two mentions are calico's :P
<lukasa> I think they are too. =D
<lukasa> However, IIRC nova-api-os-compute also includes nova-api-metadata
<apuimedo> makes sense
<lukasa> And that *is* deployed by nova-cloud-controller
<jamespage> bug 1431286
<mup> Bug #1431286: juju bootstrap fails when http_proxy is set in environments.yaml <ubuntu-openstack> <juju-core:Incomplete> <https://launchpad.net/bugs/1431286>
<beisner> hi ctlaugh, fyi that change has landed in the nova-compute "next" (development) charm.  https://code.launchpad.net/~clark-laughlin/charms/trusty/nova-compute/arm64-patch-1/+merge/252682    ps thanks, gnuoy`
<gnuoy`> np, thanks for the contribution ctlaugh
<jamespage> gnuoy`, https://code.launchpad.net/~openstack-charmers/charm-helpers/0mq/+merge/254590
<jamespage> if you have 5 secs
<gnuoy`> jamespage, approved
<web>  Is there a variable I can call on `config-change` hook that gets the name of a service as it is, like `mongo-master` not `mongo-master/0`.  Or will I need to regex the line?
<web> oops I mean relation change
<web> on `relation-change`.  Thought this would do but it is not: hostservicename=`relation-get $JUJU_RELATION`
<stub> web: You need to extract the service name from the unit name as you suggest. It is not available as a separate variable.
<web> stud: thank you.  So I would use `relation-get $JUJU_UNIT_NAME`, correct?
<web> sorry to ask and not test myself.  Don't want to spin up a server to test value.  I'm being lazy... :)
<stub> web: Yes, $JUJU_UNIT_NAME
<stub> web: But it is an environment variable, so don't use relation-get
<stub> `echo $JUJU_UNIT_NAME | sed -e 's|/.*||'`
<web> stud: if I need the relation unit name then??
<web> thats more elegant then mine: `expr "$host_service_name_string" : '^\(.[a-z]*\)'`
<web> oh i see it : $JUJU_REMOTE_UNIT
<web> stub: thank you again
<web> never mind I was wrong not right
<web> now i see )
<web> now i feel stupied
<marcoceppi_> web: you can also do ${JUJU_UNIT_NAME%/*}
<marcoceppi_> it's bash substitution, but as long as your hooks are /bin/bash and not /bin/dash, that will work
<drbidwell> When running openstack-install what kind of name do I set JUJU_BOOTSTRAP_TO so that it creates an lxc container on the maas server?
<web> marcoceppi_ :  Always improving things!
<marcoceppi_> drbidwell: link to the openstack-install instructions/download? i'm not familiar with the software but I canprobably figire it out
<web> haha http://www.newegg.com/Product/Product.aspx?Item=9SIA6N42616299&nm_mc=KNC-GoogleMKP-PC&cm_mmc=KNC-GoogleMKP-PC-_-pla-_-All+Cases+%26+Covers-_-9SIA6N42616299&gclid=Cj0KEQjw6OOoBRDP9uG4oqzUv7kBEiQA0sRYBAv_3qEC_e-rZ2s-jRzIYjGQiso_DaDj3RMnUuMEhx4aAphS8P8HAQ&gclsrc=aw.ds
<mhall119> jcastro: marcoceppi_: I think I broke juju
<mhall119> trying to update my canonistack deployment
<mhall119> juju debug-log's last lines are:
<mhall119> machine-0: 2015-03-17 16:36:33 ERROR juju.rpc server.go:554 error writing response: EOF
<mhall119> machine-0: 2015-03-17 16:36:36 ERROR juju.state.apiserver debuglog.go:101 debug-log handler error: write tcp 10.172.65.78:57110: connection timed out
<mhall119> and no juju command I issue seems to have any impact on the actual instances
<mhall119> oh, wait...darnit, I'm in the wrong environment
<web> you need to check your environment variables and make sure your connecting to the correct api
<web> i think
<web> haha
<web> or that
<mhall119> also, it seems to be doing things now (even on the wrong environment), so maybe it was just slow to respond
<marcoceppi_> mhall119: when you run commands use --debug and -v to help give more verbose information
<mhall119> marcoceppi_: will keep that in mind, thanks
<mhall119> it's all running now, and at least this environment is just another canonistack instance of the same app, so minimal damage done
<rharper> is there a way to see which uvt- commands juju runs when creating kvm machines?  when add-machine for kvm fails, I can only see that it failed, but nothing in the logs clearly shows what command failed (I assume a uvt-kvm create, but you can't tell).
<marcoceppi_> rharper: did you check the machine-*.log?
<rharper> I'll check this time, I did but didn't see anything uvt related
<rharper> and ofcourse it works this time since I removed all of the uvt-kvm images first
<rharper> well, I'll look there next time
<web> okay here is a fun question I wish I thought of before.  Can I deploy a charm from a git (ie: github)?
<rick_h_> web: there's a plugin for that
<rick_h_> web: https://pypi.python.org/pypi/juju-git-deploy
<web> what plug-ins now.  I need to read those docs again don't I.
<rick_h_> web: :) lots of cool plugins. Just wait until they show you the dhx video
<web> :x I wish I could focus on researching new stuff right now :(  one month left to finish graduate work no time :( so behind and baby on the way
<web> have to use what I know
<AskUbuntu> Is MasaS, juju, or the charm responsible for ssh-keygen on nodes? | http://askubuntu.com/q/603317
#juju 2015-03-31
<jamespage> gnuoy`, unit test failures on the quantum-gateway dvr merge
<gnuoy`> jamespage, ack, I'll take a look
<jamespage> gnuoy`, needs some further mocking by the looks of things
<jamespage> gnuoy`, nova-compute +1 and merged
<gnuoy`> jamespage, fantastic, ta
<jamespage> gnuoy`, I added the snippet to the kilo template as I did it
<jamespage> libbo but trivial
<gnuoy`> kk
<jamespage> gnuoy`, one trivial comment on neutron-api - take a look - I've tested it locally with the unit tests - seems OK
<gnuoy`> will do, thanks
<gnuoy`> jamespage, +1 your proposed change to my neutron-api mp
<gnuoy`> jamespage, quantum-gateway unit tests are fixed too
<gnuoy`> jamespage, I'd like to talk to you about the neutron-network-service relation in the neutron-openvswitch charm nut we can do that later
<gnuoy`> s/nut/bur/
<gnuoy`> urgh, typing is hard
<jamespage> gnuoy`, sure lets do that in a sec
<jamespage> gnuoy`, it seems odd to have nova-cc related to neutron-openvswitch
<gnuoy`> jamespage, neutron metadata service needs keystone credentials. So, this operates in the same way as the quantum-gateway charm does. ie its gets keystone creds from nova-cc. However, I do accept that this is really an abuse and suboptimal. Currently, the keystone charm will not issue creds without the client registering an endpoint which neutron-ovs doesn;'t do. I was thinking that the longer term solution here is to amned the keystone charm to allow you
<gnuoy`> to join the identity-service relation without specifying an endpoint and get creds back
<jamespage> gnuoy`, the alternative is for the neutron-api charm to pass those over?
<jamespage> an alternative rather
<gnuoy`> jamespage, yes, that would work
<jamespage> gnuoy`, that would be preferable to having another relation IMHO
<gnuoy`> jamespage, fine by me. I'll make that so
<jamespage> gnuoy`, +1
<gnuoy`> :q
<dosaboy> jamespage: i've done a bit of a refactor of the cred gen code in keystone with the aim of following up with the ability for identity relation to be able to hand out creds without necessarily adding an endpoint
<dosaboy> jamespage: gnuoy suggested perhaps a new relation
<dosaboy> jamespage: not sure what best approach is yet
<apuimedo> gnuoy`: +1 for amending the keystone service
<apuimedo> at the moment what I do is use keystone-admin and use keystone client to get my credentials
<apuimedo> dosaboy: sounds good ;-)
<gnuoy`> apuimedo, yes, I think the keystone charm needs to grow that feature
<apuimedo> indeed
<apuimedo> gnuoy`: why is nova-api-metadata not run by the nova-cloud-controller charm?
<gnuoy`> apuimedo, I am struggling to come up with a sensible reason
<apuimedo> ;-)
<jamespage> gnuoy`, legacy mode good for review?
<jamespage> dosaboy, your keystone refactoring landed btw
<jamespage> dosaboy, and some feedback on your hacluster one
<gnuoy`> jamespage, just having a moment of doubt as to whether it'll block the packages being installed
<jamespage> apuimedo, gnuoy`: re the neutron-api-metadata agent not running on the nova-cc - by placing it on the edges alongside the hypervisors, we avoid a) pushing all traffic to a single set of services a b) avoid having to make them HA as well
<gnuoy`> jamespage, but it currently runs on the neutron-gateway
<gnuoy`> not on the edges
<jamespage> gnuoy`, unless you run novat-network - in which case it does run on the hypervisors
<jamespage> gnuoy`, for neutron right now it sits alongside the neutron-metadata agents
<jamespage> on the gateway nodes
<jamespage> gnuoy`, dvr changes that again right?
<gnuoy`> (unless you're using dvr)
<gnuoy`> yeah
<jamespage> spot on
<jamespage> that way the neutron-metadata agent is only dependent on the api service running locally - so its quick
<jamespage> and resilient to a whole node failure
<jamespage> single service failures can still create problems tho
<dosaboy> jamespage: got it thanks, fixing now
<apuimedo> ok
<apuimedo> thanks
<apuimedo> jamespage: why is it that on the quantum-gateway charm
<apuimedo> there's only the template for nova.conf for havana but not for icehouse/juno?
<jamespage> apuimedo, template loader is os series prioritized
<jamespage> the nova.conf in havana is ok for icehouse and juno
<jamespage> we only create a new template for a specific OS version if its really required
<apuimedo> I thought as much, but I wanted to confirm :P
<jamespage> (as for kilo)
<apuimedo> on my charms I follow a default on /templates plus overrides in subdirs
<jamespage> its on the gateway charm so it can sit alongside neutron metadata proxies in l3 and dhcp namespaces
<apuimedo> (if needed)
<gnuoy`> jamespage, legacy mode is good for review
<jamespage> gnuoy`, ack - doing so now
<gnuoy`> ta
<apuimedo> jamespage: well, it's there also because nova-api-metadata needs it to exist
<apuimedo> right?
<jamespage> yeah
<jamespage> gnuoy`, merged legacy mode support
<jamespage> ta
<apuimedo> jamespage: the legacy mode support is so that the charms that are refactored still play nice with those that had relations with the pre-refactor versions?
<jamespage> yup
<jamespage> we'll leave legacy mode on by default for this release, and then turn of off for 15.07
<jamespage> gnuoy`, OK - I think I've reviewed what I can - I'm going to rebase my 0mq branches next
<jamespage> gnuoy`, are you looking at le next?
<gnuoy`> neutron-oopenvswitch dvr fixes next, then le, was my plan
<stub> The charm boilerplate from 'charm create' does a 'pip install charmhelpers'. How does that work with the python-apt dependency? Last I heard, you couldn't install that with pip.
<marcoceppi_> stub: you can't, unfortunately, I thought python-apt was installed on the images already?
 * marcoceppi_ goes to verify
<Odd_Bloke> I'm playing around with the GCE provider in the latest ppa:juju/devel package, and it looks like the boostrap node doesn't have port 17070 opened up to the world.
<Odd_Bloke> Is this a known bug?
<ericsnow> Odd_Bloke: yep #1436191
<mup> Bug #1436191: gce: bootstrap instance has no network rule for API <firewall> <gce-provider> <juju-core:Fix Committed by dimitern> <juju-core 1.23:Fix Committed by dimitern> <https://launchpad.net/bugs/1436191>
<ericsnow> Odd_Bloke: already fixed
<Odd_Bloke> ericsnow: Any easy way to get the fixed code?
<lazyPower> Odd_Bloke: we have a docker container with trunk
<lazyPower> aisrael: have you started publishing your nightlies?
<Odd_Bloke> lazyPower: Ah, cool; link?
<ericsnow> Odd_Bloke: yep, see http://reviews.vapour.ws/r/1282
<lazyPower>  Odd_Bloke:   docker run -ti -v $HOME/.juju-trunk:/home/ubuntu/.juju adamisrael/juju-trunk
<ericsnow> Odd_Bloke: the key thing is to change the first arg to OpenPorts to env.globalFirewallName()
<lazyPower> i'm not sure that has the fix however - confirming with aisreal that he's still tracking nightlies - we just started publishing these last week at our sprint
<Odd_Bloke> OK, cool; I'm just playing around so I'll hold off until aisrael confirms.
<ericsnow> Odd_Bloke: let me or wwitzel3 know if you have any questions or run into trouble (we wrote the provider)
<lazyPower> apuimedo: o/  I understand amulet is giving you some fuss?
<marcoceppi_> jcastro: et al can someone look over my answer to see if I can improve it? http://askubuntu.com/questions/603317/is-masas-juju-or-the-charm-responsible-for-ssh-keygen-on-nodes/603381#603381
<jcastro> looking
<apuimedo> lazyPower: luqas was the one that experienced the issue
<apuimedo> he'll be able to detail it better
<lazyPower> apuimedo: sure thing :) If i can get the error message and a sneak peek at the test code we should be able to triage/address it
<luqas> lazyPower: hi, when trying to use the placement option for deployment in amulet I get an error in juju-deployer
<luqas> let me find it
<luqas> lazyPower: http://paste.ubuntu.com/10712730/
<luqas> but I've seen there was a fix for that in https://bugs.launchpad.net/juju-deployer/+bug/1383336
<mup> Bug #1383336: TypeError "takes exactly 2 arguments (4 given)" raised while deploying <cts> <juju-deployer:Fix Committed by freyes> <https://launchpad.net/bugs/1383336>
<apuimedo> brb
<lazyPower> luqas: do you have juju-deployer installed via pip?
<lazyPower> luqas: i do believe this fix was released in the pip package, but has not yet been ported to the repository package. bit of a mismatch atm
<luqas> lazyPower: yes, that can be, I have the repository package, will try with the pip one and be back if it still shows, thank you
<lazyPower> np
<joec1> Hi folks, has anyone got Juju to deploy to subscription in Azure with EA? Either via the VMDepot VM or the Azure CLI tools? I'm having problems.
<lazyPower> joec1: i'm not sure i'm parsing what you're asking. EA = Ensure availability?
<joec1> Hi @ LazyPowerAzure Sorry I meant with Microsoft Enterprise Agreement
<joec1> I'm not sure if that even matters but I can't get Juju to deploy using any documented methods
<lazyPower> joec1: yeah, i'm looking here @ the azure EA markeing page and this looks mostly like a pricing structure model, not a different provider setup. So I'm going to make the blanket statement of it should just work
<lazyPower> what issue are you running into during bootstrapping?
<lazyPower> joec1: can you confirm you were following the instructions located here: bzr merge lp:~canonical-ci-engineering/charms/trusty/logstash/local-tarball
<joec1> I'm just attempting starting from scratch again but a few days ago I got the following:
<joec1> ERROR failed to bootstrap environment: PUT request failed: BadRequest -  XML Schema validation error in network configuration at line 39,18.  (http code 400: Bad Request)
<lazyPower> gah, paste fail
<lazyPower> https://jujucharms.com/docs/1.20/config-azure
<joec1> yes I followed those instructions (even though there is an error in the openssl generation commands)
<lazyPower> joec1: can you file a bug about the openssl generation eror here? https://github.com/juju/docs/issues
<joec1> forget the openssl error, that was my fault
<lazyPower> i'm bootstrapping now to try and reproduce
<lazyPower> joec1: i've found a relevant thread on this bug and it looks like its due to storage configuration
<lazyPower> https://bugs.launchpad.net/juju-core/+bug/1304778
<mup> Bug #1304778: ERROR PUT request failed: BadRequest - XML Schema validation error in network configuration at line 54,18. (http code 400: Bad Request) <azure-provider> <bootstrap> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1304778>
<joec1> brilliant!
<joec1> I'll test with trunk, thanks so much
<lazyPower> not a problem, i can confirm it bootstraps appropriately on 1.23-beta
<joec1> I did see that bug but my eyes jumped over the second reported error - I thought it was just about storage not network
<joec1> thanks again
<lazyPower> cheers
<joec1> ahhh
<joec1> I'm using juju 1.22 stable from the repos, that bug was committed to 1.20 I think. Still, will try with 1.23-beta....
<lazyPower> I don't believe its a core bug, i may be wrong
<lazyPower> it seems strange that I'm able to bootstrap if it were a core bug. I know that azure is a fairly finicky provider - its very particular about how you have it configured
<rbasak> strikov: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<joec1> @lazyPower - I don't suppose you have any easy to follow instructions for building juju trunk do you? I've already hit a problem following instructions in http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/README
<joec1> # launchpad.net/juju-core/testing/filetesting
<joec1> ../src/launchpad.net/juju-core/testing/filetesting/filetesting.go:194: cannot use checkers.Satisfies (type check.Checker) as type gocheck.Checker in function argument:
<joec1> 	check.Checker does not implement gocheck.Checker (wrong type for Info method)
<joec1> 		have Info() *check.CheckerInfo
<joec1> 		want Info() *gocheck.CheckerInfo
<joec1> apologies for the spam
<lazyPower> joec1: i do 1 moment. theres 2 methods you can follow
<lazyPower> 1) you can use the dockerbox aisrael is publishing/maintaining of nightly builds
<joec1> @lazyPower thanks its ok
<joec1> I used github instead of launchpad.net
<lazyPower> or 2) you can build from source following a tutorial here: http://marcoceppi.com/2014/11/compiling-juju-core-from-source/
<joec1> really appreciate the help thanks! :)
<lazyPower> cheers :)
<joec1> Fiddlesticks! I get the same error using juju trunk
<lazyPower> joec1: lets recap your config
<joec1> sure
<lazyPower> can you nuke the sensitive bits and pastebin me your config?
<joec1> will do
<joec1> 1 sec
<joec1> @lazyPower http://pastebin.com/GyExhKR5
<joec1> shows the error log also. I have to add --upload-tools as it complains: "Juju cannot bootstrap because no tools are available for your environment. You may want to use the 'agent-metadata-url' configuration setting to specify the tools location."
<joec1> I've also attempted using "--constraints instance-type=Small" but get the same XML BadRequest error
<aisrael> joec1: You need to add a couple options to your ~/.juju/environments.yaml, under the provider you're trying to bootstrap
<aisrael> agent-metadata-url: https://streams.canonical.com/juju/tools
<aisrael> agent-stream: devel
<lazyPower> aisrael: o/
<joec1> will try that now thanks @aisrael
<lazyPower> aisrael: is your nightly docker image still the go-to place to get trunks code? Odd_Bloke was asking earlier.
<aisrael> lazyPower: Yep, it sure is!
<lazyPower> Odd_Bloke: ^ seems like you're g2g, aisrael is on the case.
<joec1> @aisrael juju can't parse those options in environments.yaml
<joec1> "YAML error: line 458: found character that cannot start any token"
<aisrael> joec1: What error are you getting? Can you pastebin your environments.yaml (with the sensitive bits removed)?
<joec1> here is the one I just made: http://pastebin.com/GyExhKR5
<aisrael> which provider are you using?
<lazyPower> joec1: apologies for the delay in a conf call - give me a few and i'll be responsive again
<lazyPower> aisrael: this is for azure
<lazyPower> aisrael: thanks for taking a look
 * lazyPower got busy all of a sudden
<joec1> :) np really appreciate your help
<aisrael> joec1: Based on that error, I suspect you have an error in the lines you just added. They should be added under test-juju01
<joec1> yep, that's where i added them
<lazyPower> joec1: just for grins can you attempt to bootstrap in teh US West region? i can confirm this is the group i'm using as well - and this may be region specific.
<joec1> will do
<lazyPower> i see you're using the EU group - if we can isolate that this may be region specific i can get a bug tailored to the issue
<joec1> ...creating storage account.....
<joec1> same error unfortunately
<joec1> I changed my environment.yaml file to reflect the new region and the new storage account created in that region
<joec1> region being "West US"
<joec1> a couple of things:
<aisrael> If you're still getting a yaml parsing error, then there's something wrong with the yaml.
<joec1> OK, I didn't try with the agent-stream settings, will do now
<joec1> the error I'm getting is this currently: "2015-03-31 18:11:05 ERROR juju.cmd supercommand.go:430 failed to bootstrap environment: PUT request failed: BadRequest - XML Schema validation error in network configuration at line 39,18. (http code 400: Bad Request)"
<joec1> OK, juju doesn't like TAB indentation :(
<joec1> however, after adding agent-metadata-url: https://streams.canonical.com/juju/tools and agent-stream: "released" I still get the XML Bad request error
<joec1> juju status complains that it can't connect to API server without admin-secret
<lazyPower> joec1: so you've already bootstrapped, these issues are coming from juju deploy <service>?
<joec1> FYI, I'm trying to start a Juju environment in an already set up Azure service that has VMs and local network configured already, could that be the problem?
<joec1> no, I haven't bootstrapped at all
<lazyPower> that does sound like it could be part of the issue
<lazyPower> the existing VM's not so much
<lazyPower> but altererd networking - indeed
<lazyPower> i would have thought that changing the region to be US West (so long as this was still vanilla networking, et-al) would have been successful. Did those networking changes propigate globally?
<joec1> mmm not sure
<joec1> i'm not sure how I can check because Azure web portal doesn't appear to differentiate
<joec1> I'd imagine the local network config would propagate so VMs can be moved between regions easily
<joec1> I've got to go for 30 minutes back soon!
<lazyPower> ack, cheers joec1afk
<Odd_Bloke> lazyPower: aisrael: The .juju/environments.yaml written out by that Docker container is (a) owned by root:root and (b) has agent-stream at the top level which doesn't appear to apply to an environment manually added.
<Odd_Bloke> (i.e. I had to move the agent-stream declaration in to my gce environment mapping)
<lazyPower> Odd_Bloke: interesting, we pass a -v to volume mount our $JUJU_HOME which should have copied your local environments.yaml
<Odd_Bloke> lazyPower: I actually did (copy-pasting from earlier), -v $HOME/.juju-trunk:/home/ubuntu/.juju.
<Odd_Bloke> But I wouldn't have had a config pointing at the devel tools anyway. :)
<aisrael> lazyPower: I usually point it to a fresh juju path, as to not trample over an existing environment
<lazyPower> wierdness,  #disclaimer - i havent used teh nightly image yet - but this is good feedback if its being silly on volume mounts.
<aisrael> Odd_Bloke: I'll take a look at that. I thought I'd fixed the top level thing. :/
<Odd_Bloke> aisrael: I exited out of the pretty curses interface (because it didn't have a GCE option).
<aisrael> Odd_Bloke: did you exit out of juju-quickstart?
<aisrael> Odd_Bloke: ahh. That'd definitely cause the error with agent-stream being nested incorrectly.
<Odd_Bloke> aisrael: I did indeed.  #prebugging
<aisrael> Odd_Bloke: thanks for that! I've added issues to the project. I'll see to getting those fixed.
<Odd_Bloke> aisrael: Thanks!
<Odd_Bloke> Next question: I'm trying out deploying Jenkins; I've juju deploy'd, and I have agent-status 'executing' and workload-status 'maintenance'. Should I translate this as "patience, my young padawan"?
<joec1> the more I think about my issue the more I think it has something to do with the EA subscriptions
<joec1> for example, the Azure Market doesn't work for me in the default Azure portal
<Odd_Bloke> OK, I've now got agent-status 'executing' and workload-status 'active', but Jenkins is not running on jenkins/0.
<jcastro> I think it's just patience at this point
<jcastro> how long has it been?
<Odd_Bloke> 2015-03-31 18:43:49 INFO unit.jenkins/0.start logger.go:40  * Starting Jenkins Continuous Integration Server jenkins
<Odd_Bloke> 2015-03-31 18:43:49 INFO unit.jenkins/0.start logger.go:40    ...done.
<Odd_Bloke> So ~10 minutes.
<Odd_Bloke> `sudo service jenkins status` reports "Jenkins Continuous Integration Server is not running"
<jcastro> did you deploy the slave too?
<Odd_Bloke> Nope; shall I?
<jcastro> I assume so, it's what the instructions say
<jcastro> "To deploy Jenkins server you will also need to deploy the jenkins-slave charm."
<Odd_Bloke> *shuffles feet*  *avoids eye contact*
<jcastro> https://jujucharms.com/jenkins/
<jcastro> after that you expose it and it should work
<joec1> bah, I give up for now, many thank again @lazyPower and @aisrael for offering assistance
<Odd_Bloke> Rut roh: http://paste.ubuntu.com/10713842/
<Odd_Bloke> I suspect that's a problem with GCE firewalls.
<Odd_Bloke> How can I get juju to retry the hook (so I can try to fix it manually)?
<tvansteenburgh> juju resolved --retry
<Odd_Bloke> OK, I think that failure is happening because the Jenkins server isn't running.
<Odd_Bloke> And Jenkins isn't running because of... a buffer overflow. \o/
<Odd_Bloke> http://paste.ubuntu.com/10713939/ to be exact.
<jcastro> Odd_Bloke, what size is the instance?
<Odd_Bloke> jcastro: A GCE g1-small, which only has 1.7GB of RAM.
<Odd_Bloke> So that certainly seems a likely culprit.
<jcastro> yeah that's my first guess, out of RAM, but that's a guess
<Odd_Bloke> ericsnow: wwitzel3: The europe-west1-a zone has been deprecated and removed in GCE, but juju just tried to use it.
<ericsnow> Odd_Bloke: it only tries zones that GCE offers (we get a list from the GCE API at runtime)
<Odd_Bloke> ericsnow: http://paste.ubuntu.com/10714510/
<ericsnow> Odd_Bloke: yeah, dimitern ran into the same thing and we decided not to worry about it since the zone will be gone before 1.23 is released and we only try zones GCE tells us about at runtime
<ericsnow> Odd_Bloke: however, it is a pain
<Odd_Bloke> Ah, OK, cool.
<ericsnow> Odd_Bloke: for now you can use a different region
<ericsnow> Odd_Bloke: I imagine this could be a problem in the future if GCE deprecates any other zones
<ericsnow> Odd_Bloke: we could add code to filter out known deprecated zones but that is a maintenance burden we didn't want to take on if we didn't have to
<Odd_Bloke> ericsnow: The API returns the deprecation info: https://cloud.google.com/compute/docs/reference/latest/zones#resource
<ericsnow> Odd_Bloke: thanks for pointing that out, we must of missed it
<ericsnow> Odd_Bloke: could you open a bug for this?
<Odd_Bloke> ericsnow: I could reopen https://bugs.launchpad.net/juju-core/+bug/1436655 ?
<mup> Bug #1436655: gce provider should stop using deprecated zone europe-west1-a <gce-provider> <juju-core:Won't Fix> <juju-core 1.23:Won't Fix> <https://launchpad.net/bugs/1436655>
<ericsnow> Odd_Bloke: that would be perfect
<ericsnow> thanks
<Odd_Bloke> ericsnow: Actually, I can't change the status there; shall I comment and you reopen?
<ericsnow> Odd_Bloke: sounds good
<ericsnow> Odd_Bloke: done; thanks for looking into this.
<Odd_Bloke> ericsnow: No worries; thanks for writing the provider! :)
<ericsnow> wwitzel3: could you take a look at #1436655?
<mup> Bug #1436655: gce provider should stop using deprecated zone europe-west1-a <gce-provider> <juju-core:Won't Fix> <juju-core 1.23:Won't Fix> <https://launchpad.net/bugs/1436655>
<wwitzel3> ericsnow: yeah, I can take a look, I need a break from the CS stuff anyway
<ericsnow> wwitzel3: :)
<ericsnow> wwitzel3: the fix shouldn't be too bad
<Odd_Bloke> jcastro: Jenkins still falls over in the same way on a 12G RAM instance. :(
<Odd_Bloke> (And the same version doesn't do so when I run it in a similar GCE instance not via Juju)
<jcastro> Odd_Bloke, hmm no clue then, I'm off to dinner so perhaps post to the list?
<wwitzel3> ericsnow: I'm only working on one right now, I haven't started on the other yet
<ericsnow> wwitzel3: k
<ennoble> Is there a way to stop juju from destroying a maas node when no services are deployed to it? I just destroyed the services running on a machine and it seems like it's freed immediately? It's pretty annoying to have to wait 10 minutes for maas to re-deploy the node
<wwitzel3> ericsnow: is NewZone purely for testing purposes?
<ericsnow> wwitzel3: note sure
 * ericsnow take a look
<wwitzel3> ericsnow: I don't see it being used anywhere but tests, but just watned to make sure
<ericsnow> wwitzel3: yeah, looks like it is just for testing
<wwitzel3> ericsnow: I've got a fix, I insept the the deprecatedStatus of the zone and bubble that up via the availZoneUp method, I also annotate the default error if Google suggests a replacement
<ericsnow> wwitzel3: cool
<ennoble> is there a way to get juju to reread the JUJU_DEV_FEATURE_FLAG env variable or do you have to destroy the environment and re-create it?
#juju 2015-04-01
<redelmann_> mh... is safe to use block-storage-broker from charmes in trusty?
<redelmann_> easy as cloning to /trusty/ and deploying?
<redelmann_> well, there are a lot of fork of official block-storage-broker
<redelmann_> I'll assume that it's safe
<stub> redelmann: bsb works fine in trusty. I don't know if there is a reason it hasn't been promulgated.
<gnuoy`> jamespage, I have 3 mps to support dvr if you get a sec http://paste.ubuntu.com/10716710/
<gnuoy`> jamespage, and another unrelated small one if you have time https://code.launchpad.net/~gnuoy/charms/trusty/keystone/token-expiry/+merge/254870
<jamespage> gnuoy`, keystone reviewed and landed
<jamespage> I also synced up the kilo template with ed's pki stuff
<gnuoy`> jamespage, thanks!
<jamespage> gnuoy`, nice to have a unit test for the charm-helper change
<jamespage> ?
<gnuoy`> jamespage, sure, I'll do that now
<jam> hey jamespage. I had a "quick" question for you
<jamespage> jam: fireaway
<jam> elmo had mentioned that he'd really like cgroup QoS for the Openstack charms
<jam> is that something you're part of ?
<jam> jamespage: I think he CC'd you on the last email I had with him.
<jamespage> jam: he did
<jamespage> gnuoy`, neutron-openvswitch has lint and test errors/failures
<gnuoy`> urgh, sorry about that. I could have sworn I fixed those up
<jamespage> gnuoy`, one bigish comment on your neutron-api change
<jamespage> it looks to complex
<jamespage> (see MP for details)
<jamespage> all you want todo is pass the data from keystone down to neutron-openvswitch right?
<jamespage> so the remapping looks surplus and inefficient
<gnuoy`> Well, I've had mps bounced before for not being explicit about what I'm expecting and setting and acting as a blind proxy
<gnuoy`> jamespage, I'll take a look. I've updated the charm helpers mp
<jamespage> gnuoy`, oh wait I see
<gnuoy`> jamespage,I think your way would leave the keystone settings in place even if the keystone <-> neutron-api relation was removed
<gnuoy`> which I think is wrong
<jamespage> gnuoy`, you'r right
<jamespage> gnuoy`, also the context does some remapping from what keystone provides
<jamespage> specifically tenant, username and password
<gnuoy`> jamespage, hmm, that may not be useful tbh
<gnuoy`> the remapping
<jamespage> so to re-use the same context in openvswitch, you need todo what you've done
<gnuoy`> ah, yes
<gnuoy`> that's why
<gnuoy`> yesterday was sooo long ago
<jamespage> gnuoy`, can you add auth_protocol to the list as well please
<jamespage> just in case we need that sometime
<gnuoy`> jamespage, sure. I need to step out for 30mins but will do it when I get back
<jamespage> (I have it in my head that's required for kilo but I'm prob wrong)
<jamespage> gnuoy`, ack
<gnuoy`> ssh chure
<jamespage> gnuoy`, https://code.launchpad.net/~james-page/charms/trusty/rabbitmq-server/bug-1439085/+merge/254882
<gnuoy`> jamespage, approved
<philip_stoev> What is the canonical way for obtaining the information about a juju inteface endpoint? For example, if I have a mysql charm, how can I see, using the command line, the username and password that have been generated?
<philip_stoev> The only solution I could find was to use juju debug-hooks, but it does not work for me -- relation-get is not found
<stub> philip_stoev: You can use 'juju run --unit=foo/0 relation-ids', 'juju run --unit=foo/0 relation-get'
<stub> philip_stoev: Of if your fingers get tired, install the juju-relinfo package from ppa:stub/juju to give yourself the 'juju relation-get' and 'juju relation-set' commands
<philip_stoev> thank you!
<gnuoy`> jamespage, http://paste.ubuntu.com/10716710/ are ready for review if you have a moment
<jamespage> gnuoy`, going to have lunch - will do them when I get back
<jamespage> gnuoy`, zmq is testing well now
<gnuoy`> \o/
<jamespage> gnuoy`, just polishing things
<jamespage> gnuoy`, well for nova and neutron
<jamespage> cinder appears quite broken
<jamespage> gnuoy`, nested kvm appears a little happer now as well
<jamespage> no drops all this morning
<gnuoy`> jamespage, same here, I've done multiple big deploys this morning and no drops
<jamespage> gnuoy`, did you see my comment re removing the downed rmq broker?
<jamespage> it was first in all the lists so was causing lag
<gnuoy`> jamespage, could we have tuned the timout value ?
<jamespage> maybe
 * jamespage looks
<gnuoy`> dosaboy, I was planning on getting some of the le branches merged to next this afternoon. Are you working on them atm?
<dosaboy> gnuoy: lets discuss ;)
<jamespage> gnuoy, charmhelper merged - looking at charms now
<jamespage> gnuoy, all done and merged - thanks!
<gnuoy> jamespage, fantastic. thanks for all your review/merge efforts
<jamespage> gnuoy, I'm pretty happy with this lot - http://paste.ubuntu.com/10718125/
<jamespage> I need to look at glance and cinder still
<jamespage> + ceilometer
<jamespage> but nova/neutron is all good for 0mq
<gnuoy> jamespage, ack, I'll take a look
<jamespage> gnuoy, ta
<jamespage> gnuoy, you can run that against the kilo staging ppa
<jamespage> ppa:ubuntu-cloud-archive/kilo-staging
<jamespage> but keystone needs a hack right now with next branch as its not at b3 yet in archive (waiting MIR's)
<gnuoy> jamespage, the neutron-ovs one needs rebasing
<gnuoy> I would guess compute, api and gateway probably will too
<jamespage> urgh - Ok I'll check
<jamespage> I suspect I just hosed myself by landing your bits first....
<jcastro> Odd_Bloke, any luck with your problem?
<jamespage> gnuoy, they should all be good now
<gnuoy> jamespage, thanks. Do, you have a bundle I can prod at?
<jamespage> gnuoy, oct bundles/0mq
<gnuoy> ack
<Odd_Bloke> jcastro: I haven't really looked at it; I was just playing around in downtime during test runs.
 * jcastro nods
<lazyPower> If anyone missed the charmers meeting and wanted to catch up - the video is here: https://www.youtube.com/watch?v=99iiQCypEGI
<apuimedo> cool having the meetings recorded :-)
<mbruzek> yeah +1 on the recorded meetings
<mbruzek> tvansteenburgh: If I use the jenkins test runner will I get the new isolated containers on Jenkins?
<tvansteenburgh> yes
<mbruzek> across all clouds?
<tvansteenburgh> yes
<mbruzek> thanks
<gnuoy> jamespage, I've landed your 0mq branches. Thanks!
<jamespage> gnuoy, awesome - thankyou
<ennoble> Does the action feature flag work with 1.22? I can't seem to get actions to work. I have JUJU_DEV_FEATURE_FLAG="action" destroyed my environment, re-created the environment and then juju help action or juju action both return "ERROR unknown command or topic for action"
<jw4> ennoble: yes it's in 1.22
<jw4> ennoble: the envar is plural... JUJU_DEV_FEATURE_FLAGS
<ennoble> any idea why i can't quite get it to work... the user feature flag works (jes) and enables help user
<ennoble> jw4: is setting the environment variable enough or do I need to destroy and re-create the environment too?
<jw4> ennoble: just setting the feature flag should be sufficient
<ennoble> jw4: thanks, it's working; I appreciate it
<jw4> ennoble: you're welcome :)
<ennoble> jw4: it will become the default in 1.23?
<jw4> ennoble: yes
<marcoceppi_> ennoble: 1.23-beta1 is out in the ppa:juju/devel repository if you wanted to try it out
<marcoceppi_> ennoble: there are also docker containers that have the dev release in them if you want to try them out in isolation
<ennoble> Is there a way to run the juju orchestration server on the same system that's running MaaS? I don't want to use one of the machines MaaS is managing for that functionality, but I assume if I create another non-MaaS environment that won't work.
<marcoceppi_> ennoble: you can create a KVM on the MAAS machine and enlist it in maas then have the juju bootstrap node deployed to it
<ennoble> thank macroeppi_ that will probably do the trick
<skay> is it possible to use docker and mount both my .juju directory and a local charm that I want to test? https://github.com/juju-solutions/charmbox/blob/master/README.md#using-charmbox-with-existing-juju
<skay> it looks like I can only do one or the other
 * lazyPower reads scrollback
<lazyPower> skay: oh you sure can!
<cory_fu> skay: You can.  You'll want to mount the trusty directory under /home/ubuntu/trusty
<lazyPower> skay: you pass the -v to volume mount
<lazyPower> let me fetch the readme  1 sec
<skay> lazyPower: I can pass more than one -v?
<lazyPower> https://github.com/whitmo/jujubox/blob/master/charmbox.md
<lazyPower> sure can!
<cory_fu> You just can't mount the whole JUJU_REPOSITORY directory directly, since it will overwrite the .juju folder
<skay> lazyPower: I linked the readme up there!
<lazyPower> skay: the charmbox has an illustration of 2 -v mounts
<lazyPower> slightly different than the base jujubox
<skay> lazyPower: okiedokie. I am pretty excited if I can get this to work.
<skay> lazyPower: which version of docker does the readme assume? -f isn't a valid flag
<skay> I've got 1.2.0 build fa7b24f
<lazyPower> 1.3 plus
<lazyPower> i'm personally running 1.5 provided from the docker PPA
<lazyPower> 1.2.x is really old... i believe we're offering 1.3.1 in distro in trusty
<skay> I thought I was using the ppa, but I guess I screwed it up somehow
<lazyPower> thanks for pointing that out though, i'll open a bug about that
<skay> and I updated from trusty to utopic a few weeks ago
<lazyPower> https://github.com/whitmo/jujubox/issues/17
<skay> I've fallen down a weird rabbit hole
<lazyPower> skay: uh oh - whats going on?
<skay> lazyPower: it's not any of you, it's me. I can't figure out how to upgrade docker. I must have installed it in some bizarro way
<skay> lazyPower: I tried sudo apt-get uninstalling it, and installing it and the system thinks I have 1.5.x instealled, but when I run it, It still tell sme it's the other version
<skay> I'm quiet sure once I get that settled I'll be able to do things. I ran a test with the other box successfully
<skay> lazyPower: which ppa are you using?
<lazyPower> skay: deb https://get.docker.com/ubuntu docker main
<lazyPower> skay: have you tried 'which docker' to see where the bin in $PATH is overriding the ppa provided docker binary?
<skay> lazyPower: I did, and I wasn't sure which package installed it. One of my friends walked me through using dpkg -S against the binary to figure out which package it belonged to. culprit was docker.io
<lazyPower> thats the distro package, lxc-docker is the ppa package
<lazyPower> yeah, those two dont play nice together, at all
<ennoble> is there a way to prevent juju from freeing a MaaS machine after you destroy a service running on it?
<ennoble> Juju seems overly eager to clean-up and it's extremely annoying to have to wait 8 minutes for Maas to re-provision the machine
<ennoble> it seems like i should have to run juju destroy-machine or destroy-environment for the machine to be freed based on the documentation, but in practice it just happens immediately after the service is destroyed
<skay> lazyPower: thanks, btw. I have it installed properly and was able to build the charmbox
<lazyPower> \o/
<skay> alrighty, I can run tests woohoo.
<lazyPower> skay: glad we got you sorted :)
<skay> today's goal is to add basenode support to block-storage-broker. I see that charmhelpers has an execd_preinstall helper for that, but I also see a lot of charms doing this in very many ways
<skay> any reason for me NOT to use execd_preinstall?
<blr> skay: the b-s-b charm already supports basenode
<skay> blr: it does? I did something wrong then. it wasn't working in my environment
<skay> blr: I don't see where it happens in the source. could you show me?
<skay> this adds basenode support to block-storage-broker. https://code.launchpad.net/~codersquid/charms/precise/block-storage-broker/basenode-support
<skay> I'm not sure it's good for a merge request
* FrogLeg changed the topic of #juju to: This Topic is now Hot. B===D~ B===D~ B===D~ B===D~ B===D~
<lazyPower> tvansteenburgh: for tomorow - https://github.com/juju-solutions/bundletester/issues/15
#juju 2015-04-02
<lukasa_> jamespage: got a sec?
<jamespage> lukasa_, sure
<lukasa_> First, thanks for the nova-cc + nova-compute merges a few days ago. =D
<lukasa_> Just wanted to confirm something I thought I heard
<lukasa_> My understanding is that the OpenStack charms are relased twice a year: April and October. Is that right?
<jamespage> lukasa_, 4 times a year - 01 04 07 10
<lukasa_> Ah cool. =) That makes more sense.
<lukasa_> Brill, thanks! That was all I needed to know. =)
<Odd_Bloke> Someone might want to fix the topic. >.<
<jamespage> lukasa_, which where your mp's? I've done alot of landing in the last week
<lukasa_> Odd_Bloke: Uh...wow. I hadn't actually noticed...
<lukasa_> jamespage: Calico ones for nova-compute and nova-cloud-controller
<jamespage> lukasa_, ah - gotcha
<lukasa_> Odd_Bloke: That said, there are no ops in this channel atm...
* Odd_Bloke changed the topic of #juju to:  
<Odd_Bloke> Well, that's an improvement, at least.
<lukasa_> +1
* Odd_Bloke changed the topic of #juju to: Welcome to Juju! || Office Hours, here 16 April 2000UTC || Docs: http://juju.ubuntu.com/doc
* Odd_Bloke changed the topic of #juju to: Welcome to Juju! || Office Hours, here 16 April 2000UTC || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://review.juju.solutions || Unanswered Questions: http://goo.gl/dNj8CP
<Odd_Bloke> Logs FTW.
<zw> Hi there.
<zw> I have a small question. We have an openstack cluser offering debian / centos / windows vm's to customers. Can we use Juju as an addon for a customer to boot a debian vm with haproxy/mysql/... whatever ? Or de we need to use a specific distro for that ?
<marcoceppi_> zw: currently Juju supports Ubuntu and Windows as deployable series. CentOS support is landing soon and Debian soon after that
<zw> marcoceppi_: ok thank jou
<zw> marcoceppi_: can I for example deploy debian vm's/centos vm's/ubuntu vm's but only allow juju on ubuntu ?
<zw> As an extra
<marcoceppi_> zw: if you wanted to, sure. Juju doesn't care what else is deployed along side it, it just has a limitation (one we're working to resolve) on Ubuntu and Windows guests atm
<lazyPower> hazmat: ping
<arosales> charmers is https://bugs.launchpad.net/charms/+source/ubuntu/+bug/1423694 to update the precise ubuntu charm?
<mup> Bug #1423694: ubuntu charm lacks lxc bridge config <ubuntu (Juju Charms Collection):Triaged by cbjchen> <ubuntu (Charms Precise):Triaged by cbjchen> <ubuntu (Charms Trusty):Fix Released by cbjchen> <https://launchpad.net/bugs/1423694>
<arosales> I think the charmers had promoted the trusty version . . .
<arosales> marcoceppi_, ^
* FatBack changed the topic of #juju to: penis
#juju 2015-04-03
 * dimitern seems to be the only one here today :o)
<lazyPower> Lots of good announcements yesterday :)
<lazyPower> dimitern: at least we're going out on a high note for the week :D
<dimitern> lazyPower,  :) oh yeah\
<redelmann> hi, is safe to deploy block-storage-broker to machine0??
<redelmann> create one instance just to manage credential is overkilling
<skay> when trying to run bundletester in johnsca/charmbox I have this problem http://paste.ubuntu.com/10732721/
<tvansteenburgh1> skay: try installing bzr
<tvansteenburgh1> in the container, ie `sudo apt-get install bzr`
<skay> tvansteenburgh1: bzr is installed.
<tvansteenburgh1> hrm
<skay> it's installed in the container, and I've also done some rounds of doing bzr launchpad-login, copying some ssh keys that I have with lp
<skay> and I'm giving up and want to start from ground 0 with troubleshooting
<tvansteenburgh1> can you `bzr branch lp:charmers/precise/python-django` manually?
<skay> did I miss any steps?
<marcoceppi_> tvansteenburgh1: that's not the righ command, should be lp:charms/precise/python-django
<skay> tvansteenburgh1: no, but I can bzr branch lp:charms/python-django
<tvansteenburgh1> skay: try bundletester with lp:charms/precise/python-django
<tvansteenburgh1> (assuming you actually want precise)
<lp|away> redelmann: thats an acceptable colocation use case.
<skay> tvansteenburgh1: I just did, and the same thing happened
<lp|away> redelmann: however this is with the assumption that it's going to be a precise bootstrap node - hopefully that wont cause you any headaches?
<lp|away> a nice alternative would be to deploy it to a LXC container, colocated somewhere :) juju deploy --to lxc:# cs:precise/block-storage-broker
<redelmann> lp|away: actually im using trusty/block-storag-broker
<redelmann> lp|away: simple cloning it into local/trusty
<tvansteenburgh1> skay: pastebin the contents of the django.yaml in the traceback
<lp|away> redelmann: right, it hasn't been pushed to trusty as its pending amulet tests
<lp|away> carry on then :)
<redelmann> lp|away: im in testing enrimont for the moment, everithing look fine for now
<skay> tvansteenburgh1: http://paste.ubuntu.com/10732802/
<skay> tvansteenburgh1: I'm presuming that the trunk python-django charm passes tests
<skay> tvansteenburgh1: I'm trying to get to a spot where I can run bundletester successfully so that I can start running it on my branches
<tvansteenburgh1> skay: the branches in that bundle file are wrong
<tvansteenburgh1> lp:charmers/precise/python-django
<skay> tvansteenburgh1: does that mean trunk is failing?
<skay> tvansteenburgh1: oh, I ran against lp:charms/precise/python-django
<skay> tvansteenburgh1: that doesn't even start for me. bundletester -t lp:charmers/precise/python-django complains about my launchpad id
<marcoceppi_> skay: lp:charmers/ is not a thing
<tvansteenburgh1> skay: correct, that is the wrong branch
<skay> tvansteenburgh1: does your ci thing do some extra stuff I'm missing?
<tvansteenburgh1> that's what i mean, those need to be changed the yaml file
<tvansteenburgh1> skay: no
<tvansteenburgh1> s/charmers/charms/ in those lp branch paths
<skay> okay
 * skay wonders how the charm isn't failing currently
<tvansteenburgh1> skay if you submit a patch i'll merge it
<skay> tvansteenburgh1: if I managed to get it working I'll submit a mr
<tvansteenburgh1> fair enough
<skay> tvansteenburgh1: I'm afraid of wasting your time on my bundltester learning curve
<tvansteenburgh> skay: no worries man, here to help
<tvansteenburgh> it's not really a bundle tester issue though, the charm is just wrong
<skay> yes, but since I've never successfuly done bundletester stuff one won't know whether anything else fails due to an environment problem or a real problem
<tvansteenburgh> as to why it's not failing it CI, it probably hasn't been run. i'm about to kick off tests for it
<skay> tvansteenburgh: okay, trying out a run now. lp:~codersquid/charms/precise/python-django/fix-test-branches I'll make a MR when it passes
<tvansteenburgh> skay: cool
<skay> oh foo. I think it failed due to some missing dependencies
<lp|away> thats fun :)
<lp|away> yaaay docker isolation catching dependency problems
<skay> yeah
<tvansteenburgh> skay: missing pyyaml i presume?
<skay> thank one I remembered to install (and would be asking... about now)
<skay> tvansteenburgh: how would one specify dependencies for bundletester and/or CI?
<tvansteenburgh> need to specify for the charm itself
<skay> I will install them by hand just to see if the rest works but I want to fix that
<tvansteenburgh> is there a Makefile?
<skay> yes
<skay> it doesn't do that
<skay> tvansteenburgh: I guess I could add a step
<tvansteenburgh> yeah, like a deps target that the other targets depend on
<skay> tvansteenburgh: what is safe to assume for CI. that ppa:juju/stable is installed?
<tvansteenburgh> yeah
<tvansteenburgh> also bundletester and flake8
<skay> tvansteenburgh: the current repo has a script to install deps and checks for version 12.04. should I worry about supporting that?
<skay> can I do trusty instead?
<tvansteenburgh> which script?
<skay> actually, I think I can just leave it alone and add it as something make calls
<skay> tvansteenburgh: http://bazaar.launchpad.net/~codersquid/charms/precise/python-django/fix-test-branches/view/head:/dev/ubuntu-deps
<skay> I haven't changed that
<tvansteenburgh> skay: i'd ignore that file, it won't be run in CI
<skay> tvansteenburgh: what will CI run?
<tvansteenburgh> in that case, make lint, and anything +x in the tests/ dir
<tvansteenburgh> s/that/this/
<skay> are there any other make targets it calls?
<tvansteenburgh> by default it looks for make test and make lint
<skay> ok, I could make test have a dependency on dep and that target could call the script
<tvansteenburgh> you could i guess, but you really only need pyyaml, everything else is already installed in the container
<skay> tvansteenburgh: it complained about curl
<tvansteenburgh> heh, fair enough, curl too then
<skay> not sure how much thought was put in to that script. I might just ignore it
<skay> it's probably bitrotted by now
<tvansteenburgh> agree
<tvansteenburgh> skay: i just realized that it's not lint that needs the deps, it's the stuff in tests/
<skay> tvansteenburgh: I'm running through without installing anything until something fails so that I can have a list of what tests/ requires
<tvansteenburgh> so you could just make a tests/00-setup file (+x) and install deps there
<skay> oh, okay
<skay> I'd prefer that than to changing a makefile
<skay> is it safe to assume that CI will be running from an account with sudo privs?
<skay> oh derp, I can go look at the dockerfile
<skay> since that's now the way you do things
<tvansteenburgh> skay: yeah
<tvansteenburgh> passwordless sudo even
<skay> tvansteenburgh: how did the tests fair for trunk that you kicked off?
<tvansteenburgh> http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-209
<skay> tvansteenburgh: so far I've only installed python3-yaml and curl and the first few tests run
<tvansteenburgh> cool
<redelmann> lp|away: Juju stable (1.22) has support for lxc?
<marcoceppi_> redelmann: juju has had lxc support since some of the very first few versions
<redelmann> marcoceppi_: but you cant expose lxc services? im right?
<redelmann> marcoceppi_: or it cant handle iptables?
<skay> tvansteenburgh: would you consider kicking off a ci run for https://code.launchpad.net/~codersquid/charms/precise/python-django/fix-test-branches/+merge/255214 ?
<tvansteenburgh> skay: sure
<skay> my laptop is underpowered
<tvansteenburgh> in progress
<tvansteenburgh> container can't do merges since on bzr user is set, so i'm running against your branch directly
<tvansteenburgh> s/on/no/
<skay> okay
<tvansteenburgh> you can follow along here http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/36/console
<tvansteenburgh> (lxc)
<skay> oh thanks!
<roadmr> juju-ci cool!
<tvansteenburgh> skay: fair warning, i gotta go in about 20 min
<skay> tvansteenburgh: no worries. and I am wanting to EOD myself.
<tvansteenburgh> it's beer brewing night
<skay> oh pleasant
* jw4 changed the topic of #juju to: Juju
* marcoceppi_ changed the topic of #juju to: #juju to: "Welcome to Juju! || Office Hours, here 16 April 2000UTC || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://review.juju.solutions || Unanswered Questions: http://goo.gl/dNj8CP
* marcoceppi_ changed the topic of #juju to: Welcome to Juju! || Office Hours, here 16 April 2000UTC || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://review.juju.solutions || Unanswered Questions: http://goo.gl/dNj8CP
<jw4> thanks marcoceppi_
<marcoceppi_> jw4: yeah, didn't notice until you changed it
<jw4> heh
<tvansteenburgh> skay: gotta run, but i'll assuming the tests pass i'll get your branch merged later
<skay> tvansteenburgh: o/
<skay> okay, thanks
<tvansteenburgh> sure thing
#juju 2015-04-05
<redelmann> hi!! good night!
<redelmann> there any way to deploy to t2.micro/small instance in juju 1.22?
<redelmann> looking in https://github.com/juju/juju/blob/1.22/provider/ec2/instancetype.go cant see t2 instances
<redelmann> but maybe with some constraints
#juju 2016-04-04
<bdx> lazy|sprint: i hooked it up the rest of the way, check it -> https://github.com/jamesbeedy/layer-kibana
<Prabakaran> juju bootstrap failed stating "Error: Flag provided but not defined --config"in juju 2.0 installation. Could someone help me to resolve this issue?
<jose> Prabakaran: still around?
<Prabakaran> hi jose
<Prabakaran> can you help me on this
<jose> Prabakaran: hello! were you able to fix your issue?
<jose> if not, I'd like to know what command are you executing
<jose> over here, please
<jose> Prabakaran: ^
<Prabakaran> i was giving this command to bootstrap "juju bootstrap --config default-series=xenial lxd-test lxd"
<jose> Prabakaran: oh! I believe I know what's going on.
<jose> Prabakaran: so, can you try editing your environments.yaml file and add a line to your environment? this should have "default-series" as a key, and "xenial" as a value
<Prabakaran> k let me try
<jose> Prabakaran: sure! once you have changed that, let me know :)
<Prabakaran> i have made the changes
<Prabakaran> can i bootstrap the env?
<jose> Prabakaran: not actually, I have just two questions
<jose> Prabakaran: is this the only environment? or do you have multiple environments?
<Prabakaran> this is the only environment i am using.. not any other
<jose> Prabakaran: ok! then I personally suggest executing "juju switch [environment name goes here]". that way, it will be more simple to execute your commands
<jose> otherwise, you will have to append the -e flag for every single command you execute in juju
<Prabakaran> k
<Prabakaran> i swiched the local environment
<jose> Prabakaran: and finally, can you provide me with the output of "juju version"?
<Prabakaran> 1.25.3-willy-amd64
<jose> Prabakaran: aha! there we go. you're getting the error because you are still using 1.25 instead of 2.0
<Prabakaran> oh is it?
<jose> yep!
<Prabakaran> i followed this commands
<Prabakaran>   sudo add-apt-repository ppa:juju/devel   sudo apt-get update   sudo apt install juju2
<Prabakaran>   sudo mkdir /var/lib/zfs   sudo truncate -s 50G /var/lib/zfs/lxd.img
<Prabakaran>   sudo zpool create lxd /var/lib/zfs/lxd.img   sudo zpool status
<jose> Prabakaran: ok, one sec
<Prabakaran>   sudo lxd init --auto --storage-backend zfs --storage-pool lxd   newgrp -  # I think this is needed to get into the LXD group
<jose> Prabakaran: before moving, on, I need you to do me a favor
<Prabakaran> hmm sure
<jose> Prabakaran: please go to paste.ubuntu.com, and paste in that box the output of "apt-cache policy juju2"
<jose> then, give me the link over here
<Prabakaran> hi jose.. http://pastebin.ubuntu.com/15608142/
<jose> Prabakaran: thanks!
<jose> Prabakaran: hmm. weird. what's the output of "juju2 version"?
<Prabakaran> juju2 version is 2.0-beta3-wily-amd64
<jose> Prabakaran: try executing your same command, but instead of "juju" at the beginning, use "juju2"
<Prabakaran> version command?
<Prabakaran> output of juju2 version is 2.0-beta3-wily-amd64
<jose> Prabakaran: no, no. "juju2 bootstrap --config default-series=xenial lxd-test lxd"
<Prabakaran> oh k
<Prabakaran> let me try
<jose> sure thing! let me know how it goes
<Prabakaran> ya it is downloading lxd xenial image now
<Prabakaran> is it mandatory to use ubuntu 15 and above version for juju 2.0 installation?
<jose> Prabakaran: woohoo! great news! yes, we need 16.04 or above because LXD is only available on 16.04+
<jose> Prabakaran: from now on, execute "juju2" instead of "juju" in all commands on the guide :)
<jose> that should make it work!
<Prabakaran> if i use juju2 instead of juju .. is it possible for me to use juju2.0 and lxd in ubuntu 14.0?
<jose> Prabakaran: no, it is not. LXD and dependencies are not available for 14.04. Only available for 16.04 at the moment, from what I understand.
<Prabakaran> k
<Prabakaran> hi jose, bootstrap got failled stating "ERROR failed to bootstrap model: waited for 10m0s without being able to connect: /var/lib/juju/nonce.txt does not exist"
<jose> Prabakaran: it looks like but 1314682. I'm about to head out for the night, but someone should be back in a couple hours.
<jose> also, please do not PM contributors. we may take a while to respond, and it's better to post here in case I don't know the answer but someone else does :)
<Prabakaran> Thanks jose.. i will wait for the reply on this
<jose> np. if you don't get a response, you can always email juju@lists.ubuntu.com
<Prabakaran> ya sure
<A-Kaser> hi
<BlackDex> Hello there
<BlackDex> i'm unable to create a backup of juju
<BlackDex> i get the following response
<BlackDex> 2016-04-04 10:31:24 ERROR juju.cmd supercommand.go:429 while creating backup archive: while bundling state-critical files: write to tar file failed: failed to write "/var/log/juju/all-machines.log": archive/tar: write too long
<lazy|sprint> o/ greetings from the sprint in DC everyone
<magicaltrout> wwoooooo
<rick_h_> lazy|sprint: woot!
<aisrael> o/ lazy|sprint
<lazy|sprint> friendly reminder, that we have an open channel via appear.in, and our planning is happening publically on a taiga board.
<lazy|sprint> more info here: https://lists.ubuntu.com/archives/juju/2016-April/006966.html
<magicaltrout> who knew mums could be so annoying
<magicaltrout> I've actually had to enable parental controls on my home router
<magicaltrout> to stop my mum showing my mrs endless instagram and facebook posts
<magicaltrout> i guess its called parental control for a reason
<lazy|sprint> haha
<magicaltrout> oh you have no idea what its like lazy|sprint, when my dad died, my mum went out and bought an ipad mini, which was acceptable, but then signed up to every social media network going
<magicaltrout> on facebook technically we're "friends" but I completely unfollowed her because its so.... so... so... annoying
<lazy|sprint> magicaltrout - no i have a similar story. when my mom got divorced i gave her an ipad and its been a never ending repost fest
<magicaltrout> then she visits and doesn't ever put down the tabel
<magicaltrout> aye
<magicaltrout> mums should live on pintrest
<magicaltrout> and nowhere else
 * lazy|sprint grins
<lazy|sprint> i cant comment that forcefully about it. Its keeping my mum out of trouble
<magicaltrout> well at first i blocked her mac address on the router
<magicaltrout> but figured that was a bit mean
<magicaltrout> so I let her back in and just blocked facebook and instagram
<magicaltrout> handily you don't get some "parental lock" warning, it just never connects so it doesn't look like I'm being mean
<lazy|sprint> cory_fu - +10000 to that bug. you'll wind up catching all my schenanigans early if we enable that.
<lazy|sprint> for reference: https://github.com/juju/charm-tools/issues/171
<cory_fu> :)
<marcoceppi> lazy|sprint: here's the actual jsonschema: http://spacetelescope.github.io/understanding-json-schema/reference/generic.html
<lazy|sprint> gracias
<lazy|sprint> marcoceppi https://github.com/juju/charm-tools/issues/173
<marcoceppi> cory_fu: ^^ halp plz
<cory_fu> Hrm.  That's odd.
<cory_fu> Oh, lazy|sprint, you have to nest the options by layer name
<marcoceppi> cory_fu: thanks, we should warn or err if there's a layer key defined that's not found in the layer list
<marcoceppi> cory_fu: that was the real issue, but the validation worked!
<cory_fu> Yeah, +1 on erroring if defining options for a non-existant layer
<marcoceppi> cory_fu: cool, not as critical of a bug
<marcoceppi> cory_fu: thanks for the halp
<icey> I have a bundle that I'm updating, I've updated the readme but it hasn't updated on the store? I can see the updated readme if I click on it but the main page shows the old version
<beisner> jamespage, can you have a run through ppc64el smt nova-compute mods?  https://review.openstack.org/#/c/301183/
<c0s> cory_fu: kwmonroe the road-bumps I was going trough on Friday got me thinking: does it even make sens to try to mix the installation of Hadoop tarbalss with something more structured as Bigtop packages?
<cory_fu> c0s: By mix, you're talking about installing Big Top's Ignite package on top of the Hadoop libs currently supplied by the Plugin charm?
<c0s> yeah
<cory_fu> You know, we talked at one point of having the Plugin charm support a second interface, hadoop-plugin-rest or such, that would provide the server info but not install the client libs or set up the config env.  Maybe that would be a better fit for this?
<c0s> or rather let's resort to a clean-cut installation with packages only? If the latter, then I won't even waste anymore time on trying to resolve the configuration conflicts I got last time
<c0s> I am not sure cory_fu - perhaps need a bit more info than just that ;)
<cory_fu> That way, a Big Top component, like Ignite, could just use that connection info and let the Hadoop libs and config be managed by the Big Top package, but smaller third parties that aren't yet part of Big Top can let the Plugin manage the lib and configs so they don't have to
<cory_fu> And they would both work with the Plugin charm, just by using different interfaces on it
<c0s> hmm, that sounds good cory_fu. Details are where all the troubles are hiding usually..
<c0s> ok, let me timebox this conflicts resolution and we'll see how it goes then
<jcastro_> icey, did you republish after pushing?
<cory_fu> lazy|sprint, marcoceppi: https://github.com/juju/charm-tools/pull/175
<lazy|sprint> cory_fu man you're on fire
<cory_fu> lazy|sprint: http://cdn.meme.am/instances/57809981.jpg
<cory_fu> Tests failed.  Help me Tom Cruise
<lazy|sprint> cory_fu http://i.imgur.com/wIievS7.jpg
<cory_fu> :D
<jcastro_> marcoceppi, http://paste.ubuntu.com/15616534/
<icey> jcastro_: yes, the new version is the current version, it's updated now so I think it just takes a bit
<jcastro_> urulama, 3 perm --channel unpublished
<jcastro_> perm:
<jcastro_>   Read:
<jcastro_>   - jorge
<jcastro_>   Write:
<jcastro_>   - jorge
<jcastro_> is the output of the last command
<urulama> hm, that is weird, so, ACLs are ok, you just can't publish
<urulama> sorry, push
<marcoceppi> urulama: yeah
<urulama> jcastro: ok, so, revision 1 seems to be published and promulgated, but revision 3 is not published and set to jorge only
<marcoceppi> urulama: why do we get an error?
<marcoceppi> urulama: so it uploaded but just gave a weird error?
<urulama> marcoceppi: it's gated to jorge only
<urulama> marcoceppi: but the error is weird, yes
<cory_fu> lazy|sprint, marcoceppi: Tests fixed
<marcoceppi> urulama: cool, he just pushed to development channel
<marcoceppi> urulama: that error seem superfluous
<urulama> ok, will talk to jrwren later on 1-1, he'll look into this
<jrwren> oh no!
<marcoceppi> urulama: thanks, I think this error even happened on the frist upload, not that I think about it
<marcoceppi> urulama: we will test more with another bundle
<urulama> marcoceppi: ok, thanks
<LiftedKilt> out of curiosity, has anyone ever tried adding 2k machines to a model?
<LiftedKilt> I imagine it will make the state database cry and qq
<cory_fu> kjackal: Thanks for putting together https://github.com/ktsakalozos/jujubigdata-assemblage  We should create a README for it based on http://bigdata.juju.solutions/getstarted or such and add links to our blog, presentations, etc.
<cory_fu> But I think it will definitely lower the barrier to entry for the big data charms
<icey> the Juju base layer (https://github.com/juju-solutions/layer-basic/blob/master/tox.ini) sets up tox for python3.4, which Xenial seems to not have, should that version be bumped or should somebody work on adding python3.4 into Xenial?
<cory_fu> icey: We should probably bump it up, though we should ensure that we can also run tests on trusty
<icey> reading the docs, it looks like you can do 3.5 and 3.5, and that tox should skip missing
<icey> rather, 3.4 and 3.5
<icey> cory_fu:
<cory_fu> icey: https://github.com/juju-solutions/layer-basic/pull/52
<icey> cory_fu: there's one more issue :) the makefile breaks with 3.5 right now
<icey> it expects flake8 in the py34 path
<cory_fu> bah.  And here I though it would be easy
<icey> yeah, I'm pokling around right now
<icey> I'll make a PR if I can get it figured out :)
<cory_fu> icey: Can the Makefile do: @.tox/py*/bin/flake8 $(wildcard hooks reactive lib unit_tests tests)
<jamespage> thedac, apparmor looks good to me but needs a rebase....
<thedac> jamespage: the charmhelpers mp needs a rebase?
<jamespage> thedac, yeah - its trivial - happy to +1 landing and let you deal with that...
<thedac> jamespage: great, will do
<icey> nope cory_fu
<icey> /bin/sh: 1: tox/py*/bin/flake8: not found
<cory_fu> icey: Irksome
<icey> yeah cory_fu
<cory_fu> icey: I'm going to close my PR, then, and await yours
<icey> ack
<lazy|sprint> cory_fu intereting, i see the 'trusty/foo' in there, is that how we reference layers now using series/layer?
<cory_fu> lazy|sprint: I think that's just a hacky work-around for the test
<cory_fu> I think that mysql thing was from another test and co-opted to be used as a "layer"
<Prabakaran> Hello Team, After bootstraping the juju environment in the juju 2.0 installation i was trying to create a test model using the command juju create-model test.  But this command takes so much of time and it doesnt show any progress. Please advise on this.
<mbruzek> Prabakaran: what kind of controller are you using?
<icey> haha cory_fu .tox/py3*/bin doesn't work, but PATH=$$PATH:`pwd`/.tox/py34/bin:`pwd`/.tox/py35/bin flake8 $(wildcard hooks reactive lib unit_tests tests) does
<icey> working on the PR now
<Prabakaran> i'm using local.lxd-test
<mbruzek> Prabakaran: I wrestled with lxd today. Can you give me a juju version?
<Prabakaran> juju version : 2.0-beta3-wily-amd64
<mbruzek> OK that is the latest one.
<jamespage> gnuoy, did you see https://review.openstack.org/#/c/299205/ ?
<Prabakaran> i just observed one thing.. if i run juju list-controllers command it doesnt show any server ip in the table of data..
<Prabakaran> is this anyway related to juju bootstrap?
<mbruzek> hrmm yes.
<mbruzek> Prabakaran: can you run `juju kill-controller lxd-test` ?
<mbruzek> Prabakaran: lets start over
<Prabakaran> k
<mbruzek> Prabakaran: I have an ip address in my list-controllers output
<Prabakaran> i just destroyed lxd-test
<mbruzek> Prabakaran: OK now what is the contents of ~/.local/share/juju/  use pastebin if it is huge
<Prabakaran> k
<mbruzek> ls -al ~/.local/share/juju
<icey> cory_fu: https://github.com/juju-solutions/layer-basic/pull/53
<icey> I'm about to test it on a trusty container
<Prabakaran> accounts.yaml, bootstrap-config.yaml, controllers.yaml, current-controller, models.yaml and ssh
<mbruzek> Prabakaran: ok many of the yaml files should be empty or with controllers: {} please remove the .yaml files in that directory
<Prabakaran> sorry, should i remove all *.yaml file in this dir?
<mbruzek> Prabakaran: Yes and also current-controller
<mbruzek> Prabakaran: save them off if they are not empty, just don't have them in this directory, trying to reset
<Prabakaran> k
<mbruzek> Prabakaran: After that is done run the bootstrap command out of https://jujucharms.com/docs/devel/config-LXD
<Prabakaran> in this same dir i am able to see ssh dir also. should i remove this also ?
<mbruzek> no ssh is fine
<Prabakaran> k
<jamespage> beisner, some feedback on https://review.openstack.org/#/c/301183
<mbruzek> Prabakaran: let me know if that bootstrap works OK, then you should be able to create a model
<Prabakaran> ya k .. bootstrap is now attempting to connectiing to some ip
<mbruzek> OK
<Prabakaran> i will let you know on this chat
<icey> cory_fu: the version of tox in trusty (python-tox) is too old to recognize py35, we can install from pip and it works though: https://github.com/juju-solutions/layer-basic/pull/53
<beisner> jamespage, how would you feel about having no smt knob, and jdtrt when arch matches?
<Prabakaran> hi mbruzek, bootstrap failed staing below error " ERROR failed to bootstrap model: waited for 10m0s without being able to connect: ssh: connect to host 10.0.4.1 port 22: connection refused" please advise
<jamespage> beisner, what does an integer do?
<beisner> jamespage, nothing in our use case afaik.
<jamespage> beisner, do we always want smt on?
<beisner> jamespage, off
<jamespage> beisner, if the only real value is on for ppc64el then yes, drop the config option and turn it off automatically...
<jamespage> on/off in that sentence
<beisner> jamespage, so if arch is ppc64el, smt off.  otherwise ignore.
<beisner> that's really all we've done manually
<jamespage> beisner, go for it
<beisner> jamespage, right on, thx
<mbruzek> Prabakaran: can you give me the `lxc version`
<jamespage> coreycb, oh dear - https://code.launchpad.net/~corey.bryant/charm-helpers/liberty810/+merge/290908
<jamespage> sorry
<jamespage> missed that...
<coreycb> jamespage, oh np, that's what testing is for
<jamespage> coreycb, indeed
<Prabakaran> lxc version is : 2.0.0.rc8
<mbruzek> Prabakaran: OK lets see if LXD/LXC is working for you
<Prabakaran> k
<mbruzek> Prabakaran: please run this command `lxc launch ubuntu:16.04`
<Prabakaran> i ran this command - it success
<Prabakaran> generated client certificate and started its service
<c0s> cory_fu: I have a working single node Ignite cluster on top of Juju hadoop installation ;)
<magicaltrout> a cluster of 1! \o/
<c0s> there is a couple of silly things to do with one of the scripts in the ignite, but it could be there bug (I am mostly sure). And I have figured out what was wrong with the hadoop client, so cli works fine as well
<mbruzek> Prabakaran: but yet your bootstrap command fails?
<c0s> yeah magicaltrout - it's called pseudo-distributed ;)
<cory_fu> c0s: Awesome.  It seems like it was a fair bit of work to get that working, though?
<mbruzek> Prabakaran: Can you also try 14.04  to see if that works?
<Prabakaran> K
<c0s> cory_fu: not so much - more like a silly debugging in one place ;(
<c0s> so at this point, we can make a decision if we want to add a simple charm to install ignite hadoop accelerator from Bigtop packages and do some trivial configuration (so it is available in the current bundles); or to develop a new set of charms for bigtop
<c0s> up to you guys.
<c0s> arosales: cory_fu kwmonroe I will go ahead and write some recommendations for your team to decide
<c0s> beautiful (running yarn pi 50 50)
<c0s> on ignite                  on yarn		
<c0s> real    0m10.967s     real    1m6.222s
<c0s> user    0m4.787s      user    0m6.247s
<c0s> sys     0m0.229s      sys     0m0.288s
<D4RKS1D3> Hi Everyone, someone  can help me?, I have some issues when I change my enviorment to openstack
<coreycb> beisner, think you could land this massive change? https://code.launchpad.net/~corey.bryant/charm-helpers/liberty810/+merge/290908
<Prabakaran> i tried 14.04 also.. it is working fine
 * arosales reads backscroll
<beisner> coreycb, i can this eve.  got a kiddo dr appt shortly.
<arosales> c0s: first gret to hear :-)
<arosales> c0s: looking forward to hearing what your recommendations may be
<coreycb> beisner, np, maybe thedac can land it
<c0s> arosales: sure, working on a doc now
<arosales> c0s: thanks
<c0s> no worries ;)
<terje> hi, I'm trying to bootstrap juju on my private openstack cloud, and I'm getting the following: http://pastebin.com/vaa5MPU1
<terje> hoping someone can tell me what I'm doing wrong.
<jcastro_> arosales, https://jujucharms.com/wiki-simple/bundle/0
<thedac> coreycb: what do you need me to look at?
<coreycb> thedac, hey, just looking for this to get landed: https://code.launchpad.net/~corey.bryant/charm-helpers/liberty810/+merge/290908
<thedac> coreycb: ok, is the 8.1 version live now?
<coreycb> thedac, yes, it's in trusty-liberty-proposed
<coreycb> thedac, I have a keystone review on gerritt
<thedac> coreycb: ok, I'll land this CH MP
<coreycb> thedac, thanks
<thedac> coreycb: done
<jcastro_> urulama__, any idea on this one?
<jcastro_> charm set bundle/wiki-simple bugs-url=https://github.com/juju-solutions/wiki-simple/issues
<jcastro_> ERROR cannot update the set arguments provided: unauthorized: access denied for user "jorge"
<jcastro_> that should work right?
<marcoceppi> jcastro_: https://bugs.launchpad.net/juju-core/+bug/1563067
<mup> Bug #1563067: deploying from charmstore fails on lxd provider in a restricted network <juju-core:New> <https://launchpad.net/bugs/1563067>
<jcastro_> heya cherylj
<jcastro_> can we get this bug on your list? ^^^
<cherylj> jcastro_: it's already there!
<cherylj> jcastro_:  did you see the comments from today?
<cherylj> jcastro_:  the bug that it's dup'ed to (bug 1556207) should also address the issue where updating proxy information isn't picked up by running jujuds
<mup> Bug #1556207: 1.25.4: Units attempt to go through the proxy to download charm from state server <landscape> <juju-core:In Progress by dooferlad> <juju-core 1.25:Fix Committed by dooferlad> <https://launchpad.net/bugs/1556207>
<jcastro_> ok, so "juju needs to work behind proxy" is basically on the radar already
<cherylj> yeah
<terje> in the environments.yaml file, I'd like to specify a different s3 user than what's being used for 'username'
<marcoceppi> arosales: ^^ fyi
 * arosales reads back scroll
<arosales> marcoceppi: thanks for fyi,
<arosales> cherylj: thanks for the info on bug 1563067
<mup> Bug #1563067: deploying from charmstore fails on lxd provider in a restricted network <juju-core:New> <https://launchpad.net/bugs/1563067>
<Saviq> hey all, in new juju gui (2.1.1) on firefox all the input fields seem to get input back-to-front... i.e. if I type "foo", I get "oof", is that a known issue?
<Saviq> the caret seems to be stuck to the beginning of the field
<magicaltrout> is it april 1st?
<LiftedKilt> Saviq: haha I've gotten really good at typing in reverse
<Saviq> LiftedKilt, yeah learning fast here, too ;P
<Saviq> "P; oot , ereh tsaf gninrael haey ,tliKdetfiL" ,yas I dluohs ro
<LiftedKilt> Saviq: I'm officially impressed
#juju 2016-04-05
<jamespage> gnuoy, are https://review.openstack.org/#/q/owner:liam.young%2540canonical.com+status:open ready for review?
<jamespage> well the ones passing verification at least...
<gnuoy> jamespage, yes, the neutron-gateway problem is similiar to the one I had yesterday, I don't think neutron-plugin-metering-agent is a think in icehouse onwards
<jamespage> gnuoy, comments on rmq
<jamespage> gnuoy, cinder +2'ed and landing
<gnuoy> jamespage, lovely, ta
<neiljerram> Morning all!  Charm store appears to have gone offline - any idea when it will be back?
<urulama__> neiljerram: we're working on it
<urulama> neiljerram: but no estimates for the moment
<neiljerram> Thank you - good to know that.
<urulama> neiljerram: charm store is back
<neiljerram> Thanks!
<BrunoR> Hi! a charm using juju block storage deployed to aws does not create ebs-volumes (as expected) but loop-devices ~ juju storage pool config is unchanged/default ~ someone an idea how to fix this?
<BlackDex> Hello ther
<BlackDex> e
<BlackDex> is there a way that i can restart juju agents ?
<BlackDex> they clame there connection is lost, but that isn't
<lazyPower> Greetings from DC everyone o/
<lazyPower> Day 2 of the Charm Community team sprint is underway, we invite you to participate. More information here: https://lists.ubuntu.com/archives/juju/2016-April/006966.html
<BlackDex_> how can i get all the machines which are used in juju?
<rick_h_> BlackDex_: ? in what way? juju status shows all the machines?
<rick_h_> BlackDex_: or do you mean in the cloud control panel?
<BlackDex_> rick_h_: i need to do a `juju run` on all machines
<BlackDex_> currently i can only do that with --machine=ID
<BlackDex_> so i want to grep or something to extract only the machines
<rick_h_> BlackDex_: oh hmm, thinking
<BlackDex_> i need to restart all the jujud agents
<BlackDex_> and i don't want to go to every machine and run the script
<D4RKS1D3> Hi someone can help me to launch services in openstack with JUJU?
<BrunoR> BlackDex_: 'juju run --all ...' does not work?
<BlackDex_> BrunoR: That run's on all
<BlackDex_> also the lxc stuff
<BrunoR> BlackDex_: ah ok
<rick_h_> BlackDex_: what version of Juju?
<rick_h_> BlackDex_: will have to do something with juju status --format=yaml and grep out the ids with bash-foo me thinks
<BlackDex_> rick_h_: 1.25.3
<marcoceppi> BlackDex_: you'd have to do some fun stuff with awk, but it's possible
<magicaltrout> nothing involving awk is fun
<BlackDex_> haha
<marcoceppi> BlackDex_: I'll get ya a one liner, give me a min
<BlackDex_> i now have the list of machine id's in a {1,2,3} ;)
<BlackDex_> that works
<BlackDex_> for MACHINE_ID in {136,137,138,139,140,141,142,143}; do echo "Machine $MACHINE_ID"; juju run --machine=$MACHINE_ID 'for JUJUD in `find /etc/init -type f -name "jujud-*" -exec sh -c '"'"'basename "$0" | cut -f1 -d. '"'"' {} \;`; do sudo status $JUJUD; done'; done
<rick_h_> wheeeeee, that looks like a party
<marcoceppi> BlackDex_: I'll get you a juju-run-all-machines plugin
<BlackDex_> marcoceppi: That would be nice ;)
<rick_h_> BlackDex_: a bug for a --all-machines option to core would be cool
<BlackDex_> Would be even better if juju run --machine will just do it when no id is given
<BlackDex_> rick_h_: Or that ;)
<BlackDex> rick_h_: If i report that to juju-core in LP that would be fine right?
<rick_h_> BlackDex: yes please
<BlackDex> on it's way
<BlackDex> ill also will add a request for the abillity to restart all the jujud agents ;)
<marcoceppi> BlackDex: you're not going to like this ;)
<BlackDex> i'm waiting to see the horror
<marcoceppi> BlackDex: I simplified one line for complexity in another https://gist.github.com/marcoceppi/2b86e80f376ed790198aafdcaf9271e9
<marcoceppi> BlackDex: I updated it for readability, https://gist.github.com/marcoceppi/2b86e80f376ed790198aafdcaf9271e9
<BlackDex> i like the initctl list part
<BlackDex> lets keep it at that ;)
<BrunoR> I still have problems using Juju storage https://lists.ubuntu.com/archives/juju/2016-April/006979.html
<BlackDex> but thx marcoceppi :)
<BlackDex> forked it
<A-Kaser> Hi
<D4RKS1D3> Hi someone can help me? I received "2016-04-05 14:31:55 ERROR juju.cmd supercommand.go:429 cannot connect to API servers without admin-secret"
<D4RKS1D3> Someone knows how to solve it?
<D4RKS1D3> For me works properly with the enviorement maas but, when I change to openstack do not works
<D4RKS1D3> Thanks
<jamespage> gnuoy, thedac: quick one? - https://code.launchpad.net/~james-page/charm-helpers/ovs-datapath-type/+merge/290999
<thedac> jamespage: sure, I'll take a look
<D4RKS1D3> Hi jamespage , could you help me?
<jamespage> D4RKS1D3, not something I've seen before
<D4RKS1D3> Thanks jamespage
<jamespage> D4RKS1D3, looks like some sort of auth problem - which juju version?
<thedac> jamespage: merged.
<thedac> jamespage: if you have time neutron-gateway apparmor is ready https://review.openstack.org/#/c/299670/
<jamespage> thedac, ta
<jamespage> thedac, endeavouring to get my dpdk updates done today and then will switch back to reviews...
<D4RKS1D3> 1.25.1 james
<thedac> understood
<BlackDex> D4RKS1D3: which provider do you use or is configured for openstack?
<BlackDex> it's complaining about that there is no admin-secret in your environments.yaml
<BlackDex> for the openstack environment
<D4RKS1D3> I have the field password:
<D4RKS1D3> in the documentation do not exist the field admin-secret
<D4RKS1D3> this is the token of openstack?
<D4RKS1D3> BlackDex, if I download the openstack enviorement from the openstack dashboard I see this information http://pastebin.com/KjMkPEL7
<cory_fu> c0s: Have you been using the charmbox for the deployments you've been doing so far?
<lazyPower> charmbox \o/
<cory_fu> c0s: https://github.com/juju-solutions/charmbox
<lazyPower> recommend you pull charmbox:devel if you're testing on 2.0
<cory_fu> lazyPower: Why does the charmbox not set {LAYER,INTERFACE}_PATH?
<lazyPower> cory_fu - dev does, doesn't look like i got that ported into -stable   https://github.com/juju-solutions/charmbox/blob/devel/install-review-tools.sh#L18
<cory_fu> Ah.  Ok
<lazyPower> our 1.25 box is going to need a little bit more love before i shelve it and supplant with whats in the devel flavor
<lazyPower> cory_fu - if ya file bugs i'll make sure to clean those up before we tag and archive the box
<cory_fu> c0s: The starting docs are at https://jujucharms.com/docs/devel/developer-getting-started and all the other items under Developer Guide in the sidebar on that page.
<c0s> thanks cory_fu
<BlackDex> D4RKS1D3: i need to add admin-secret to that list
<D4RKS1D3> I resolve now the problem
<D4RKS1D3> The problem is the project name or tenant
<D4RKS1D3> and the user and pass are "incorrect"
<D4RKS1D3> now i am having others problem but now i can logging properly
<D4RKS1D3> thanks for your support BlackDex and jamespage
<BlackDex> yw
<jcastro_> rick_h_, we tried publish again today and everything worked
<jcastro_> \o/
<jcastro_> jrwren fixed things
<jcastro_> urulama, ^^
<rick_h_> jcastro_: <3
 * rick_h_ finds a new way to irritate jcastro_ 
<jrwren> i'll take the credit, but I swear, I didn't do anything :]
<rick_h_> jrwren: always take the credit
<jcastro_> rick_h_, "Home Submit a Bug" is my new irritant.
<jcastro_> https://jujucharms.com/u/jorge/wiki-scalable/bundle/0
<lazyPower_> i'm in ur html'z, removing your <p> tags
<rick_h_> lazyPower_: wfm, pr's welcome :P
<lazyPower_> rick_h_ if you have me working on any of your HTML i'm dropping support for every browser but lynx
<rick_h_> lazyPower_: :)
<lazyPower_> it'll be the ugliest throw back to 1993 we've ever seen, but man it'll load fast.
<narindergupta1> gnuoy: hi there is query on openstack ovs integration charm from OPNFV member.  where do I see how OVSs are connected to each other?
<narindergupta1> gnuoy: do we know which charm is responsible for and how it is done?
<thedac> narindergupta1: this is vanilla ovs not ovs-odl?
<narindergupta1> thedac: correct vanilla ovs
<thedac> vanilla ovs is neutron-openvsitch which runs on nova-compute as a subordinate
<narindergupta1> thedac: question was how do they interconnect for east west traffic?
<thedac> Between nova-compute and neutron-gateway neutron-openvsitch builds tunnels (GRE or VXLAN). You can show these with `ovs-vsctl show`
<thedac> s/Between nova-compute/Between all the nova-compute(s)
<narindergupta1> thedac: do we have code where tunnel is built?
<thedac> openvswitch and neutron-api (neutron-server) handle building the tunnels
<thedac> Not our code directly
<narindergupta1> thedac: ok thanks for letting me know and i will pose any query frther
<thedac> no problem
<narindergupta1> if i get it from
<jcastro_> hatch, is there a way to disable having to use the commit button in the ui? like a flag or config setting?
<hatch> jcastro_: so you want to auto deploy as soon as you add something to the canvas?
<jcastro_> yeah
<hatch> no there isn't
<jcastro_> if I wishlist it what are the chances we'd consider it?
<hatch> jcastro_: are you running into issues with the deployment summary?
<jcastro_> for like development, etc.
<hatch> jcastro_: slim to none :)
<jcastro_> there's just too many clicks
<jcastro_> it's like, let me model
<jcastro_> and THEN can I commit
<hatch> with the new deployment summary adding the 'immediate deploy' back requires us to make a number of assumptions about what the user wants to do
<jcastro_> I just want to cut down on the number of dialogs I have to click through
<jcastro_> like, it's actually easier to edit bundles by hand than try to make a bundle in the ui
<hatch> jcastro_: but don't you add everything to the canvas once then click deploy/commit?
<jcastro_> I'm trying to test to show you
<jcastro_> but it seems demo.j.c is having some issues?
<hatch> hmm appears to be working for me
<hatch> or did I just lie...
<hatch> oh no, was just slow
<hatch> looks like it's working
<jcastro_> yeah the search seems to take a long time
<hatch> yeah it does
<jcastro_> kwmonroe, I notice you guys do like "bundle-local.yaml" etc in your bundles
<jcastro_> is that to make it convenient when you're locally deploying or is there a way to use multiple bundle.yaml's in the same bundle?
<rick_h_> jcastro_: you can have as many yaml files in there as you want. Juju will just look for the one
<jcastro_> right, so the store will only ever show the actual one
<jcastro_> I was thinking how we could have a concept of like, flavors for a bundle
<jcastro_> for example, I am working on wiki bundles
<jcastro_> I have wiki-simple, ,wiki-scalable, and wiki-smooshed
<jcastro_> it would be neat if I could have those as multiple yamls
<lazyPower> wiki-smooshed :D
<jcastro_> and then like, `juju deploy wiki:scalable` or something
<jcastro_> `juju deploy wiki --flavor smooshed` or whatever if you don't like the colon
<marcoceppi> rick_h_: the idea being that, we have a clear set of overrides available per flavor: basically constraints and placement, unliek before where overrides were _anything_
<marcoceppi> I could have a GCE and Amazon flavor bundle, each with explicity storage and intstance-type constraints
<jcastro_> yep!
<kjackal_> cory_fu kwmonroe , just moved the jujusolutions-pack to juju-solutions. Many thanks to c0s who offered the first README version. https://github.com/juju-solutions/jujubigdata-pack
<c0s> yay! I am helping ;)
<kwmonroe> yeah jcastro_, we have a bundle[-dev|local].yaml for all our bundles.  we use -dev and -local for rapid deployment (though local is now screwed because of what a bare charm name means now)
<kwmonroe> for us, -dev pulls latest charms from ~bigdata-dev namespace with no revision, so you know every time you deploy it, it's pulling the latest charms from the store.
<c0s> kwmonroe cory_fu I am looking into this marriage of Juju and Bigtop and looking into resources.yaml file: while installing from a repository (e.g. Bigtop Hadoop stack release) we don't need to list all the packages for the installation, but rather only a repo URL is needed.
<magicaltrout> bah my new website must be raising up google
<magicaltrout> because i'm being spammed to f$ck
<kwmonroe> c0s: i'm +1 for moving to repos vs juju-resources where it makes sense.. couple questions though:  should the repo url be configurable for bigtop charms?  and does the repo have multiple hadoop versions (like 2.7.1 and 2.7.2) that would suggest each  charm might need a version string?
<c0s> kwmonroe: at least in Bigtop we don't mix different versions in the same repo, but sure it is possible, so great point! As for configurable: are the locations of current resources configurable? Looks like they are hard-coded
<lazyPower> magicaltrout - ah the woes of being popular
<c0s> going to grab a bit. BB in 10
<magicaltrout> i wish
<magicaltrout> but I can get a good supply of under the counter meds
<kwmonroe> yeah c0s, they are hard coded in resources.yaml, which gives us a pseudo configurable option that can be set for deployment, but not changed afterwards.  we had to do that so mbruzek wouldn't nack us for immutable config :)  if we do make the repo configurable, we have to handle a change for the lifecycle of the charm -- that may be ok, but is something to consider (ie: what happens if a user changes the slave repo, but not
<kwmonroe>  the namenode).
<mbruzek> kwmonroe: immutable config is against the rules, and breaks the user experience.
<mbruzek> If you set a configuration variable you would expect it to actually change something in the charm
<kwmonroe> see c0s? ^^  that's the wrath we're trying to avoid.
<lazyPower> kwmonroe - you're an abriter of that squirrely wrath too ya know, mr ~charmer
<lazyPower> *arbiter
<c0s> kwmonroe: mramm I see your life is full of joy~
<c0s> kwmonroe cory_fu with changing the format of the artifacts we'll have to be changing juju-solutions/jujuresources as well
<cory_fu> c0s: If the artifacts are packages, we can drop jujuresources altogether.  That was just there to make it a bit easier to handle more or less arbitrary .tar.gz files
<cory_fu> Also, the plan was to drop it anyway in favor of 2.0 resources
<c0s> or so just apt-get directly from the handler?
<c0s> damn, I suck at Python
<cory_fu> c0s: You can call apt-get directly from a handler, but I would recommend using a helper such as https://pythonhosted.org/charmhelpers/api/charmhelpers.fetch.html#charmhelpers.fetch.add_source or the apt layer: https://git.launchpad.net/layer-apt/tree/README.md
<c0s> ah, thanks cory_fu - it's getting better by the minute ;)
<c0s> cory_fu: interestingly, we Bigtop puppet we don't even need to configure apt sources - it is all done in the Puppet ;)
<cory_fu> c0s: Oh, well that's convenient.  You can use that in the charms, right?
<c0s> if we call 'puppet apply' from charms - then yes
<c0s> still pealing off the layers of juju
<terje> Is it possible to specify a seperate swift username and secret key in an environment.yaml file?
#juju 2016-04-06
<jamespage> gnuoy, re bug 1566688
<mup> Bug #1566688: Charm installs different l3 package for same openstack release for installs > trusty <neutron-gateway (Juju Charms Collection):Confirmed for gnuoy> <https://launchpad.net/bugs/1566688>
<jamespage> thats correct
<jamespage> Ubuntu releases after trusty did not have...
<jamespage> openswan
<jamespage> which was the default vpn option for the vpn-agent until recently
<jamespage> strongswan is now supported as well which is in later releases...
<gnuoy> jamespage, so it should be http://paste.ubuntu.com/15642553/
<gnuoy> ?
<jamespage> gnuoy, maybe
<jamespage> tbh I took the approach of disabling post trusty as I had not tested with strongswan
<jamespage> and we've sinularly failed to get neutron-vpn-agent into main since then as well
<gnuoy> ok, I'll go and ponder, thanks
<jamespage> gnuoy, is this blocking something?
<gnuoy> jamespage, with the new pause/resume code the services that we register against a config have to actually be accurate rather than the scatter gun register loads and don't worry if they don;t exist
<gnuoy> so its just fall out from that
<gnuoy> I think I just need to update the amulet tests for my pause/resume branch tbh
<gnuoy> I have a if-icehouse-or-greater-its-neutron-vpn-agent clause which is obviously now wrong
<gnuoy> s/now//
<jamespage> gnuoy, yeah - its if_trusty_neutron_vpn
<gnuoy> ack
<A-Kaser> Hi
<jamespage> coreycb, gnuoy: https://review.openstack.org/#/c/302101/
<jamespage> follow up for coreycb's keystone ch-resync for 8.1.0 for stable
<D4RKS1D3> Morning
<D4RKS1D3> Someone has experience launching services in openstack with juju? I receive this error "ERROR instances not found"
<webscholar> Hi all
<webscholar> I am trying to install juju2 beta3 on ubuntu 14.04 LTS using the ppa:juju/devel but it installs the juju 1.24 version
<webscholar> Can any one share the ppa for juju 2 latest version here ?
<webscholar> I am following this
<webscholar> https://jujucharms.com/docs/devel/getting-started-general
<freak_> anyone available ? need help regarding juju quickstart
<freak_> getting error:    juju-quickstart: error: invalid version string: 2.0
<freak_> i have installed juju 2
<freak_> and quickstart version is 1.3.1
<rick_h_> freak_: juju-quickstart is deprecated for juju 2.0.
<rick_h_> freak_: juju 2.0 does the work that quickstart did
<jamespage> gnuoy, https://review.openstack.org/#/c/301761
<jamespage> I think that will do the trick, just need test rig time now....
<stub> webscholar: Add ppa:juju/devel and ppa:juju/stable, and install the juju2 package
<webscholar> is there a way to mention in bootstrap command which node to use as bootstrap ? When I run juju bootstrap <controller-name> my-maas it bootstraps with its own choice
<evilnickveitch> webscholar, if you are using MAAS, you can do it with constraints
<evilnickveitch> webscholar, see https://jujucharms.com/docs/devel/charms-constraints and:
<evilnickveitch> https://jujucharms.com/docs/devel/reference-constraints
<jcastro_> tvansteenburgh, https://github.com/juju/docs/issues/692
<stub> Does juju-deployer work with juju2? Interested because amulet, and I'm not sure if juju-deployer needs updating or my environment isn't setup the way it wants.
<lazyPower> stub tvansteenburgh is working on it.
<tvansteenburgh> stub: tip of deployer works on juju2
<stub> ta
<tvansteenburgh> stub: same for python-jujuclient
<stub> I think the juju-deployer issue has saved me tripping over python-jujuclient ;)
<jamespage> coreycb, gnuoy, thedac: can one of you do the honours on https://review.openstack.org/#/c/302101
<jamespage> +2 review +1 workflow needed
<coreycb> jamespage, on it
<jamespage> coreycb, ta
<tych0> is there a way to set model config globally?
<tych0> like if i always want to set image-stream=daily and default-series=xenial for everything?
<Spads> when the agent-status message is "run leader-settings-changed hook", is that prescriptive or descriptive?
<Spads> like, is that saying what failed, or advising me on how to un-fail it?
<marcoceppi> jcastro_: http://paste.ubuntu.com/15654448/
<jamespage> gnuoy, urgh
<jamespage> so
<jamespage> gnuoy, I just hit the nuance of binding a device to dpdk in that it disappears from /sys/class/net/
<jamespage> so re-running the same code post binding results in an empty whitelist of pci devices based on resolution by mac address...
<gnuoy> jamespage, do the devices appear elsewhere in the /sys tree?
<cory_fu> kwmonroe, c0s: How do you feel about my suggestion in the email about all NameNodes sharing a common ssh key?
<cory_fu> Does that seem insecure?  I notice that Big Top has an ssh key checked in to the repo, but I assume that will get replaced by a generated one in a deployment, right?
<c0s> cory_fu: are you referring to the yesterday's email?
<c0s> cory_fu: in Bigtop there are two different places where we use SSH key
<c0s> keys
<c0s> 1. for ssh fencing (this one is getting generated, I believe)
<c0s> 2. for user hdfs ONLY IF a special test-mode is turned on.
<c0s> The latter is static, but is only used in a controlled environment for passwordless ssh, because we need it for some low-level HDFS tests (like block recovery, for instance)
<c0s> does it make sense?
<cory_fu> Yep
<c0s> in general, using static key in production is big no-no, of course
<cory_fu> So, for fencing, do you think it's insecure for the namenodes to share a (generated) key?
<cory_fu> c0s: I ask because it simplifies the key management quite a bit and if the nodes already have passwordless ssh amongst each other, it doesn't seem any less secure for them to use the same ssh key to do it.  Though, it does mean putting the private key in the leader settings, but again, if you access to that, then you already have access to those boxes
<c0s> yeah, I agree
<c0s> sharing generated key is perhaps ok.
<c0s> Ideally, you'd want some sort of PK management system like kerberos ;)
<cory_fu> +1
<c0s> but it is way too heavy and overly-sensetive
<jcastro_> heya evilnickveitch
<evilnickveitch> jcastro, hello, having fun?
<jcastro_> I don't have perms to do this, but if you want to take every "this page doesn't have navigation for next and back" bugs for the docs and point them all to one, Marco is going to do it
<jcastro_> evilnickveitch, it is wonderful to delete large swaths of things we don't need, yes!
<evilnickveitch> jcastro, yes, I am looking forward to killing a lot more stuff tomorrow
<evilnickveitch> jcastro, to clarify, not EVERY page is going to have next/back?
<evilnickveitch> perhaps i need to see the implementation
<jcastro_> yeah so like, are we putting something in the footer or ?
<jcastro_> marcoceppi, ^
<marcoceppi> jcastro_ evilnickveitch each page, that has peers at the same level, will have a forward backward (when applicable). this will be built using the navigation information and embedded at compile time
<marcoceppi> evilnickveitch: I'd support a breadcrumb header that we could interprut at build time to say either breadcrumb: true|false and a sane default to drive this functionality
<marcoceppi> but it's basically going to be a new mdx plugin
<marcoceppi> evilnickveitch: as an example: https://jujucharms.com/docs/devel/developer-getting-started#install-libraries-and-tools
<marcoceppi> at the bottom this would have "Designing your charm ->"
<marcoceppi> evilnickveitch jcastro_ the following page, Designing your charm, would have "<- Install libraries and tools                   Writing your charm ->"
<marcoceppi> althight, that's a terrible example, since those are anchors
<marcoceppi> but that's the idea
<evilnickveitch> marcoceppi, I see how that works for the developer docs, as a lot of that is a narrative. Not sure it works so well in other parts
<evilnickveitch> but yeah, whatever, I will take a look if you do it
<marcoceppi> evilnickveitch: so we would have the top of page config "breadcrumb" set to false
<marcoceppi> evilnickveitch: and we'd enable it where it made sense
<evilnickveitch> ok
<evilnickveitch> marcoceppi, actually, thinking about it...
<evilnickveitch> marcoceppi, it would probably save some effort if you just used the metadata
<marcoceppi> what metadata?
<evilnickveitch> to turn on and off
<evilnickveitch> marcoceppi, at the top of each doc
<evilnickveitch> there is a line or number of lines
<evilnickveitch> (mostly to set the title0
<evilnickveitch> any key:value there is interpreted as metadata
<evilnickveitch> so it doesn't get processed.
<evilnickveitch> hang on...
<evilnickveitch> marcoceppi, https://pythonhosted.org/Markdown/extensions/meta_data.html
<evilnickveitch> at the moment it is used for the page titles, and the todo generator
<marcoceppi> evilnickveitch: cool
<evilnickveitch> but it would be simple to add Breadcrumb:true or whatever
<evilnickveitch> the metadat is already parsed in the build tool
<evilnickveitch> i think you get a dict
<evilnickveitch> so, yeah
<evilnickveitch> try that way first :)
<evilnickveitch> marcoceppi, actually, thinking about it even more, you could have Previous and next instead in the metadata, and use the urls as values. It does mean some manual editing to begin with but would be a lot simpler to implement.
<evilnickveitch> anyhow, I think I have done enough thinking for one day
<tvansteenburgh> dpb1_, fginther: fyi https://code.launchpad.net/~tvansteenburgh/python-jujuclient/juju2-fixes/+merge/291182
<dpb1_> tvansteenburgh: looking
<dpb1_> tvansteenburgh: you have an error ~2613 it looks lik
<dpb1_> like
<tvansteenburgh> dpb1_: jeez, htf did that happen
<tvansteenburgh> dpb1_: fixing
<dpb1_> :)
<tvansteenburgh> dpb1_: fixed and pushed
<dpb1_> re-merging
<dpb1_> looking now
<c0s> kwmonroe: if not with jujuresources how else can I can download binaries specified in resources.yaml? Is there any helper code for that?
#juju 2016-04-07
<A-Kaser> Hi
<jacekn> hello. marcoceppi marked my bug as "Fix Released" but my charm is still not recommended in the charmstore: https://bugs.launchpad.net/charms/+bug/1538573
<mup> Bug #1538573: New collectd subordinate charm <Juju Charms Collection:Fix Released> <https://launchpad.net/bugs/1538573>
<A-Kaser> I would like to have a node with mesos, hadoop, spark to run my charm; I'm using cs:~tads2015dataart/trusty/mesos-master-0 as "scope: container"; but how can I add trusty/apache-spark-7 on the same node ?
<jacekn> is there anything I need to do? If not when shoudl I expect my charm to be in the charmstore?
<D4RKS1D3> Morning, Someone knows if its possible to re-bootstrap one enviorement? I am trying to install services with juju in maas, and all the time I need to create all
<gnuoy> jamespage, anytime for https://review.openstack.org/#/c/301637/ ?
<jamespage> gnuoy, my n-ovs review for enabling DPDK is good for initial review; I need to figure out one other thing which is how to get libvirt to switch to using the root user for qemu processes - but that will require a n-compute change as well
<jamespage> gnuoy, sure
<jamespage> gnuoy, swap you for https://review.openstack.org/#/c/301761
<gnuoy> done
<gnuoy> well, deal is what I mean
<jamespage> gnuoy, :-)
<jamespage> gnuoy, also have https://review.openstack.org/#/c/302236/ up as well
<jamespage> and https://review.openstack.org/#/c/300384/
<jamespage> gnuoy, did you figure out whether the switch to apache+wsgi works OK with https?
<gnuoy> jamespage, Yes I did, not it didn't, it does now
<jamespage> is the existing support re-used i.e. haproxy -> apache SSL -> apache-wsgi
<gnuoy> yes
<gnuoy> jamespage, see how I cunningly stole the keystone.conf context which has the port shuffle logic
<jamespage> gnuoy, right - so we kinda double hop through apache now?
<gnuoy> jamespage, yes we do
<jamespage> gnuoy, that's fine - just wanted to check...
<gnuoy> jamespage, I think the seperation makes sense tbh. It allows the charm to still talk to the local keystone on localhost without ssl
<jamespage> gnuoy, agreed
<jamespage> gnuoy, +2 on that review - lgtm
<jamespage> landing now
<gnuoy> ta
<jamespage> gnuoy, going to focus on the network-spaces -> ceph bits now and will come back to sorting out the last bit of dpdk/libvirt/ovs madness after that
<gnuoy> jamespage, ok, enjoy
<gnuoy> jamespage, can I just clarify that your saying that once a device has been given to dpdk you can still see the device via lspci etc but there is no way of accessing the MAC ?
<jamespage> gnuoy, it is still in lspci and there might be a way of discovering it still via /sys
<jamespage> but I did not dig that deep
<neiljerram> Has someone just broken the mysql-server package on Xenial?  As of this morning, deployment of the mysql charm on Xenial is failing for me, whereas yesterday it was fine.
<suchvenu> Hi All
<suchvenu> I have a query related to getting values in Interface.
<suchvenu> I am trying to get the contents of a file from the consumer charm . In the interace (requires side) can I get this value ?
<suchvenu> In require side, I am trying something like this :  subprocess.check_output("sudo cat /root/.ssh/id_rsa.pub")
<suchvenu> I am getting the error that the file doesn;t exist , where as actually the file exists.
<gnuoy> neiljerram, just had one of our automated tests fail using the mysql charm on xenial. Looking into it now
<jamespage> neiljerram, might be that 5.7 landed...
<jamespage> rbasak, ?? ^^
<rbasak> gnuoy: possibly bug 1566406
<mup> Bug #1566406: postinst fails on mysql_upgrade if database is already upgraded <amd64> <apport-package> <package-from-proposed> <xenial> <mysql-5.7 (Ubuntu):In Progress by racb> <https://launchpad.net/bugs/1566406>
<jamespage> gnuoy, hmm - are you aware of any test isolation problems in any of the charms?
<jamespage> gnuoy, I was expecting mock state to be rest between indivivdual tests, but I'm not seeing that in ceph-mon
<jamespage> reset rather
<neiljerram> gnuoy, jamespage, thanks - certainly 5.7 is the version now being installed.
<neiljerram> gnuoy, jamespage It is still possible to install version 5.6.28-1ubuntu3 of mysql-server, and that appears to go through...
<neiljerram> (although a manual step of 'rm -f /var/lib/mysql/debian-*.flag' is needed)
<gnuoy> I'm seeing http://paste.ubuntu.com/15667815/
<gnuoy> proper context http://paste.ubuntu.com/15667822/
<freak_> I'm getting below error when deploying juju-gui
<freak_> root@maas61:~/.local/share/juju#  root@maas61:~/.local/share/juju# watch juju status Every 2.0s: juju status                                                                                                                         Thu Apr  7 16:42:06 201  [Services] NAME       STATUS  EXPOSED CHARM juju-gui   unknown true    cs:trusty/juju-gui-52  [Units] ID         WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
<freak_> [Machines] ID         STATE DNS INS-ID  SERIES AZ 0          error     pending trusty
<freak_> http://paste.ubuntu.com/15667891/
<gnuoy> jamespage, yes, I had test isloation problems with the action unit_tests specifically but I don't think the issue is limited to them
<freak__> i have deployed juju-gui and also expose it..but when i type watch juju status i get this outputn: http://paste.ubuntu.com/15667891/
<freak__> anyone pls help
<rick_h_> freak__: see help in #juju-gui
<freak__> rick_h thanks
<rbasak> gnuoy: a fix for the known mysql-5.7 packaging bug is on its way. Please let me know if you're still broken after that lands.
<rbasak> neiljerram: ^^
<rbasak> We'll be deleting mysql-5.6 soon.
<neiljerram> rbasak, thanks!  But I suggest not deleting mysql-5.6 until you're really sure that 5.7 is good!
<rbasak> neiljerram: we don't really have a choice now. Going back would be more effort than fixing whatever's broken in 5.7.
<marcoceppi> jacekn: looks like ingestion is broken
<neiljerram> rbasak, I don't understand.  I just managed to work around the current 5.7 breakage by installing version 5.6.28-1ubuntu3 of mysql-server.  There is no 'more effort' needed - you just need to leave 5.6 there.
<rbasak> neiljerram: the archive is in a pretty inconsistent state.
<rbasak> neiljerram: we can't release like this.
<rbasak> neiljerram: for example we couldn't do a security update for 5.6 right now without breaking 5.7.
<rbasak> (and we wouldn't want double the maintenance effort to support both for five years in any case)
<gnuoy> rbasak, will do, thanks
<neiljerram> rbasak, OK, but all I said was "I suggest not deleting mysql-5.6 until you're really sure that 5.7 is good!"  That could just mean for the next couple of days - it doesn't have to mean beyond the Xenial releas.
<rbasak> If we wanted to go back to 5.6, we'd need to upload a new 5.6 from the 5.6 source and have it build anyway.
<rbasak> So deleting it or not deleting it doesn't actually make any difference.
<neiljerram> Are you saying that you've deleted 5.6 already?
<rbasak> No, but we will.
<rbasak> I appreciate your sentiment, but in practice it makes no difference from an archive management perspective.
<rbasak> We can't delete 5.6 until all the reverse dependencies are switched to 5.7.
<rbasak> I'm working on that actively now.
<neiljerram> I'm sorry, I have no clue what you're actually saying.  Sounds like nonsense to me.
<rbasak> 5.6 and 5.7 are not independent. They are intertwined. Between each other and with their reverse dependencies.
<neiljerram> Right now, I can install 5.6 to work around 5.7 breakage.  If you delete 5.6, I won't be able to do it, and I won't have a working 5.7 either.  To my mind, that definitely does "make a difference".
<rbasak> I have uploaded a fixed 5.7.
<rbasak> If it does not work, please tell me so that I can fix it.
<neiljerram> rbasak, Cool, I will try that.  Probably will be an hour or so, because of my Juju deployment cycle time.
<rbasak> neiljerram: make sure you pick up the fix for bug 1566406 please - 5.7.11-0ubuntu5, which isn't built and published yet.
<mup> Bug #1566406: postinst fails on mysql_upgrade if database is already upgraded <amd64> <apport-package> <package-from-proposed> <xenial> <mysql-5.7 (Ubuntu):Fix Committed by racb> <https://launchpad.net/bugs/1566406>
<rbasak> neiljerram: I don't know that this is your issue either. I only know that we were getting reports and this was a bug. You might have another.
<neiljerram> rbasak, I looked at the bug, but can't tell where to get the fixed package from.
<rbasak> neiljerram: when the bug is marked Fix Released, wait half an hour and it should be available from archive.ubuntu.com.
<rbasak> Just check the version you end up with (it'll be announced in the bug) to be sure you have the fix.
<neiljerram> rbasak, BTW it appears that my latest deployment using 5.6 instead doesn't fully work - which I guess is the point that you were making above.
<neiljerram> rbasak, Thanks, will do.
<jamespage> gnuoy, I think I'm going a little mad
<jamespage> I have no idea why I'm suddenly hitting this isolation problem
<gnuoy> jamespage, are you adding a new unit_test file ?
<jamespage> gnuoy, yes
<gnuoy> jamespage, does its name feature alphabetically before the others?
<jamespage> gnuoy, kinda in the middle
<gnuoy> jamespage, well, I'd try renaming in temporarily test_zzz and go from there
<gnuoy> s/in/it/
<jamespage> gnuoy, nope - its completely due to when two tests get scheduled on the same testr process
<jamespage> gnuoy, its like the cleanup is not getting run between individual tests...
<jamespage> afaict
<gnuoy> jamespage, engage the tinwood would be my advice
<tinwood> jamespage, can you run them both individually? (e.g. tox -e py27 -- -n unit_tests.xxxx)
<jamespage> tinwood, no
<tinwood> oh
<jamespage> tinwood, its really weird - the mocks are different for each test case...
<jamespage> but something odd is going on
<tinwood> which charm is it?
<jamespage> tinwood, ceph-mon
<jamespage> tinwood, https://review.openstack.org/#/c/302681/
 * tinwood is having a look ...
<tinwood> jamespage, do you mind if I pull it down and have a look at it?
<jamespage> tinwood, please do
<jamespage> I'm baffled
<jamespage> what should have taken me 2 hrs todo across three charms is completely blocking me now...
<tinwood> okay, will do.
<jamespage> tinwood, sorry I'm being a dimwit
<jamespage> please stop looking at my complete stooopidity...
<tinwood> have you tracked down the problem.
<jamespage> @cached - wish I'd never written that decorator...
<tinwood> ah.
<tinwood> yes, that would do it.
<tinwood> tricky to mock as it happens at loadtime.
<jamespage> tinwood, yah - I fixed this before
<jamespage> tinwood, reseting the cache in tearDown works OK
<tinwood> ah, good idea.  Like it.
<jamespage> gnuoy, https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces they should all be good now
<jamespage> to much copy/paste in the ceph charms atm - cholcombe, icey - it would be nice to try address that next cycle...
<icey> jamespage: I'd love to take a whack at layering up the charms, the ceph-mon and ceph inherit from a ceph-base, and then we could maintain the ceph charm as a POS charm because it would just depend on ceph-mon and ceph-osd
<jamespage> icey, +1 sounds neat...
<jamespage> icey, https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces might be of interest to you as well
<icey> I'm about to want a review to add the storage hooks (in the ceph charm) to the ceph-osd charm as well :)
<jamespage> tinwood, pxc pause/resume lgtm - ok for me to push that through to landing?
<tinwood> jamespage, pxc == percona?
<jamespage> tinwood, yes
<tinwood> yes, it should be.
<tinwood> jamespage, I also need to talk to you about ceph and pause/resume.  I'm still unsure about use case now I've dug into it more
<jamespage> gnuoy, arghhhhhh
<jamespage> gnuoy, how many amulet tests check for 'keystone' as a running service now...
<gnuoy> jamespage, ? amulet was passing for me with the move to mod_wsgi or am I missing your point?
<jamespage> gnuoy, well yes in keystone
<gnuoy> oh
<gnuoy> yeah
<jamespage> but how many other charms deploy keystone as part of their amulet tests...
<jamespage> ceph-mon
<jamespage> \o/
<gnuoy> jamespage, I don't think other charms should test that tbh
<jamespage> gnuoy, yeah - I think our amulet test approach needs a rethink/refactor...
<jamespage> beisner and I where chatting about that a while back
<jamespage> gnuoy, ok reviews raised for ceph* for that change...
<lazyPower> mbruzek - when you get a sec i need a hotfix review on https://github.com/juju-solutions/layer-docker/pull/34
<jamespage> gnuoy, I had a run through the apparmor reviews; I don't think they are ready to go in yet...
<gnuoy> jamespage, ok, I'll take a look at your review comments
<lazyPower> cory_fu nvm on the ping,
<jamespage> gnuoy, https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces are testing OK
<cory_fu> lazyPower: What ping?
<lazyPower> from 10:17
<lazyPower> sa'll good man, you missed it :)
<gnuoy> jamespage, not sure canonical ci agrees with you
<jamespage> gnuoy, oh not those ones
<jamespage> gnuoy, https://review.openstack.org/#/q/status:open+branch:master+topic:keystone-apache
<gnuoy> kk
<cory_fu> lazyPower: Odd, I didn't get a ping from you at that time.
<cory_fu> Hope I'm not missing other messages
<gnuoy> jamespage, are you suggesting an amulet full would be overkill ? I tend to agree is thats what your proposing
<jamespage> gnuoy, +`
<jamespage> 1 rather
<gnuoy> kk
<aisrael> What's the status of payloads in juju 2? I'm running beta3 and `juju list-payloads` throws "ERROR unknown object type "payloads" (not implemented)"
<aisrael> marcoceppi: lazyPower ^^
<lazyPower> :O
<lazyPower> cherylj - did payloads get dropped?
<aisrael> `juju help payloads` is dead, too. :(
<alexisb> lazyPower, no
<alexisb> that is a bug
<alexisb> can you please open a bug
<lazyPower> you betchya alexisb
<aisrael> alexisb: will do!
<alexisb> we can get eyes on it
<icey> cory_fu: how do oyu guys handle the upgrade charm hook in reactive / layers
<jamespage> gnuoy, I suspect that our mysql woes are charm related
<gnuoy> jamespage, well, a fresh install on xenial without the charm did not result in an error
<gnuoy> rbasak, ^
<jamespage> gnuoy, yah - confirmed
<gnuoy> jamespage, but I can't see what the charm is doing to mess up the install
<rbasak> It wouldn't surprise me if some behaviour changed in 5.7 causing this though.
<rbasak> Eg. authentication.
<jamespage> gnuoy, I think it pushed a config file onto disk prior to install
<rbasak> We're using socket auth by default now, so a few bits have changed, especially if automatic.
<jamespage> rbasak, did 5.7 just go in?
<rbasak> bug 1567098 for example.
<gnuoy> jamespage, yes
<mup> Bug #1567098: Cannot log in as root user when not root Unix user <mysql-5.7-transition> <mysql-5.7 (Ubuntu):New> <https://launchpad.net/bugs/1567098>
<rbasak> jamespage: yes
<cory_fu> icey: Basically the same as other hooks, really.  The charm dependencies (wheelhouse) is upgraded automatically, and you can have a @hook('upgrade-charm') decorated block if you need to do anything special during upgrade.
<cory_fu> I think upgrade-charm is probably the one remaining case where it really makes more sense to use @hook
<jamespage> gnuoy, rbasak: I think its something todo with the fact that the charm writes password files into /var/lib/mysql
<beisner> jamespage, gnuoy - yah i'm still +1 for yanking irrelevant checks from amulet tests (focus on the charm and its services only).
<beisner> jamespage, gnuoy - we also need to a spike on xenial test enablement.
<beisner> gnuoy, looks like the charm writes a conf file, then apt installs with confold.  maybe we're breaking there?
<gnuoy> beisner, that sounds likely
<rbasak> Do you need to tell apt to tell dpkg to use your conffile and not overwrite? There's an option for that AIUI.
<neiljerram> rbasak, Sorry for not asking this earlier - but how long would you expect until that mysql-server bug shows Fix Released ?
<rbasak> neiljerram: by now I'd have thought. I see an issue. Looking.
<neiljerram> rbasak, Thanks...
<beisner> jamespage, gnuoy (ftr consider that a standing +1 to prune such tests as drive-bys with your other changes)
<gnuoy> ta :)
<A-Kaser> is it possible to have action executed when we remove a service , as an uninstall script ?
<kwmonroe> hey suchvenu - you were asking about getting a remote unit name from an interface?
<kwmonroe> i'm assuming you want to do this from the "requires" side of the interface.. if the scope of that interface is scopes.UNIT, then you can have a method that simply returns self.conversaion().scope
<kwmonroe> (scope will be the name of the unit)
<suchvenu> Yes
<suchvenu> i want to get the require side unit name
<suchvenu> and my scope is global
<kwmonroe> (one sec, gotta meet the schoolbus)
<suchvenu> ok, np
<kwmonroe> sorry abou that suchvenu, i'm back
<kwmonroe> ok.. so you have an interface, and in the requires.py, you want to return the remote unit name?
<kwmonroe> (bcsaller may have some tips here ^)
<suchvenu> in provides.py i want remote unit name
<kwmonroe> ok, so you're providing a service, and the provider needs to know the remotely connected unit name?  i'm guessing this is to do something like create a db2 instance name based on whatever requires the db2 relation?
<lazyPower> kwmonroe - there's an environment variable for $JUJU_REMOTE_UNIT during a relationship hook sequence
<suchvenu> yes, right... kwmonroe
<lazyPower> https://jujucharms.com/docs/devel/reference-environment-variables#juju_remote_unit
<lazyPower> doc link if its helpful ^
<kwmonroe> oh hey!  there's an idea.. that may be an easy thing to do do suchvenu ^
<suchvenu> the env variable $JUJU_REMOTE_UNIT will work in the interface a?
<suchvenu> I have used it in the reactive layer..
<suchvenu> But this i want in the interface
<lazyPower> suchvenu - that environment variable is set during the relationship context, so it's important ot remember that you should only depend on that during the @hook('relation-name-joined')  joined/changed/departed/broken
<lazyPower> if you attempt to reference that environment variable during say, config-changed, its not going to be there
<kwmonroe> suchvenu: in a more complicated example -- say, for example, you needed to know *all* the remote units connected to your interface, you could create an "endpoints" method simliar to how the monitor interface does it: https://github.com/juju-solutions/interface-monitor/blob/master/provides.py
<kwmonroe> suchvenu: i think lazyPower's suggestion is that you not worry about the remote unit name in the interface, and use it in the reactive layer during a @when '<required>-relation-changed' state is present.
<kwmonroe> ugh, sorry, i meant provides.. so like in the db2 reactive layer, @when 'db2-relation-changed'
<kwmonroe> echo $JUJU_REMOTE_UNIT, or whatever you need to do with that
<suchvenu> The issue i am facing is, I need to get the remote-unit name to create DB and users based on the unit name. If i miss to set accept_license to true and add-relation between db2 and consumer, I get the remote unit name in the reactive layer. But since accept_license was not set the install will not happen
<suchvenu> Then I set the accept_license flag and after this, when it comes to relation hooks I am not getting the $JUJU_REMOTE_UNIT name
<suchvenu> Before install, when the add-relation was called, it actually goes to the relation hooks and gives the $JUJU_REMOTE_UNIT name
<suchvenu> But not after install. So I thot of getting this value from Interface
<kwmonroe> ah yeah, so that gets back to what lazyPower was saying.. when add-relation was called, you were in a "db2-relation-[joined|changed]" hook, which is a relation hook, which is why $JUJU_REMOTE_UNIT was available
<suchvenu> right
<suchvenu> first time i get it
<kwmonroe> when you set accept_license, you were in a "config-chagned" hook, which has no remote relation information available
<kwmonroe> so you would need to adjust your states to handle the case when both license is accepted && relation is available
<suchvenu> But doesn't it go to relation hook again after config-changed ?
<kwmonroe> like "@when 'license.accepted' 'db2-relation.joined'"
<kwmonroe> then echo $JUJU_REMOTE_UNIT
<kwmonroe> the 2nd clause in that @when decorator will ensure it happens in a relation context, so remote unit info should be available
<kwmonroe> no, relation hooks may not fire after a config-changed hook, and even if a conifg and relation hook are both set to fire, you have no guarantee which one will happen first
<suchvenu> hmm
<kwmonroe> that's the nice part about reactive charming.. you can create a combination of states so that it does not matter which happens first
<kwmonroe> simply define a method that requires both states -- in this case, license.accepted and db2.ready (or whatever the db2 state is called) -- and you can do both config and relation-related things in there.
<suchvenu> ok..
<suchvenu> let me try this way and see
<kwmonroe> does that help?  if not, please point me to a repo so i can take a look (it doesn't have to be working code :), or paste the reactive code that isn't working to http://paste.ubuntu.com/
<suchvenu> Thanks Kwmonroe and lazypower
<suchvenu> I will try and let you know
<suchvenu> Sure thanks
<jcastro_> mthaddon, https://jujucharms.com/docs/devel/tools-charm-tools
<cory_fu> kwmonroe, suchvenu, lazyPower: Sorry I'm late to the party, but I'd highly recommend against using $JUJU_REMOTE_UNIT, because it will *only* be valid within a @hook('*-relation-*') handler and almost certainly not in any @when handler.  Instead, you can always get the list of unit names from a conversation with conv.units
<lazyPower> ah thats right
<lazyPower> cory_fu - as usual, to the rescue ;)
<kwmonroe> oh dear -- sorry suchvenu!  don't do that
<cory_fu> kwmonroe: I'm also now recommending *against* ever using conv.scope directly.  That was a bad pattern that I started and now regret.
<lazyPower> cory_fu - we need some of that knowledge in the docs, if i bug that can I point you at it?
<kwmonroe> heh
<cory_fu> lazyPower: Yes, please do.  conv.units isn't even in the docs anywhere and definitely needs ot be
<cory_fu> lazyPower: I've also been thinking about scrapping the Conversation pattern entirely (or at least hiding it) because it seems to cause more confusion than it saves
<jcastro_> aisrael, can you loop back around to this today? https://bugs.launchpad.net/charms/+bug/1562944
<mup> Bug #1562944: Please review and add auditd charm as a recommended charm <Juju Charms Collection:New for charmers> <https://launchpad.net/bugs/1562944>
<cory_fu> And there is at least one bug now that's damned hard to fix with people relying on conv.scope
<aisrael> jcastro_: Yep, I'll hit it again tonight. The AWS test finally ran and passed. \m/
<stub> I'd love to have an example of a relation where the leader sets a password that all units set on their relation, cause then I might understand how I can use conversations ;)
<jcastro_> does the review queue bot not post immediately to lp when the test passes?
<jcastro_> or is it like a nightly thing or something?
<jcastro_> all I see on the bug are the failed tests
<aisrael> jcastro_: Not sure. I'm going by this: http://review.juju.solutions/review/2620
<jcastro_> mthaddon, ^^
<jcastro_> aisrael,  thanks!
<cory_fu> stub: You've pretty much convinced me that not only are conversations and scopes harder to understand, but they lead to an incorrect mental model of how relations work under the hood.
<aisrael> jcastro_: no worries. I'm on the case
<mthaddon> jcastro_: thx, will pass on to Tim
<stub> cory_fu: I was hoping I'd missed some important fact that was stopping me grokking it :-(
<kwmonroe> cory_fu: how would you get the current remote unit name from a globally scoped provides.py?
<suchvenu> cory_fu, kwmonroe -> So are ou suggesting me to use conv.units ?
<kwmonroe> cory_fu: conv.units gets me all remote (requiring) units, right?  i just want 1 in particular.
<cory_fu> stub: The intention originally was to model the progression of states that one unit assigns to another as a conversation, but the asymmetry of how relations actually work in Juju, and the variation in the use-cases led to it ending up being less useful than we'd originally hoped
<cory_fu> kwmonroe: When you're dealing with states (@when), there *is* no "current" remote unit.  You could be in a config-changed hook, if that happened to be the last thing that changed to satisfy all of your @when conditions.  All you know is that the state you referenced applies to a set of one or more remote units
<cory_fu> suchvenu: Yes, I am recommending that you use conv.units which will be a list of unit names.
<suchvenu> But I want only one unit for which I am creating the DB name and user
<cory_fu> suchvenu: If you have two services connect to the database, they should both get a database, right?  So, if the timing works out that you are handling two at once, it means you need to loop over them and create a database for each.
<suchvenu> But if I have already created for one ?
<cory_fu> suchvenu: Unless you only want to create one database per service and the connected service has multiple units?
<cory_fu> In that case, you'll need to convert the unit names to a (shorter) list of service names and create one per service.
<kwmonroe> how about this cory_fu suchvenu... in the db2 charm, @when 'db2.ready', loop through all units from conv.units, test if user/db/whatever already exists, and if not, create what you need based the data in the current loop iteration.
<cory_fu> +1
<A-Kaser> I got this warning : charm URL should include a revision
<kwmonroe> because i think you're right in that all units connected to db2 will need a user/db/whatever, so just always loop through all of them and create the missing pieces
<suchvenu> yes that will work
<A-Kaser> is it in metadata.yaml ?
<cory_fu> A-Kaser: Where did you get that warning?
<A-Kaser> juju bundle proof
<cory_fu> Hrm.  I think that's an out-of-date warning
<cory_fu> Oh, bundle proof!
<cory_fu> A-Kaser: That means that bundles should include specific revisions for charms.  I.e., "charm: cs:trusty/mysql-5" instead of "charm: cs:trusty/mysql"
<A-Kaser> it's my owns charms
<cory_fu> A-Kaser: That's to ensure that bundles are a set of specific charm revs that are known to work together
<A-Kaser> and there are only local, I'm lookig to how publish it
<cory_fu> A-Kaser: Really, that only applies to bundles that you want promulgated.  They will work w/o revs, but for promulgated bundles we basically require them to be rev locked
<A-Kaser> ok
<A-Kaser> so I can add -1 at the end of "charm:" line
<cory_fu> A-Kaser: But you can put a bundle in your own namespace, that refers to charms in your own namespace, w/o rev locking them
<A-Kaser> and I suppose I will be able to create this revision
<A-Kaser> ok ok, I need to check how to publish it
<suchvenu> Cory_fu , do you have any example where I can look at conv.units ?
<A-Kaser> launchpad use only bzr ?
<cory_fu> A-Kaser: Whenever the charm is published to the store (either by having it be automatically ingested from Launchpad, or using the new `charm push` / `charm publish`, it will create the rev
<cory_fu> suchvenu: Not off the top of my head, and I have to step away for a few minutes.  I will find one and get back to you shortly, if kwmonroe doesn't find you one first
<cory_fu> bbiab
<suchvenu> sure
<c0s> kwmonroe: cory_fu : a quick question about ArchiveUrlFetchHandler. If I am using in the form of
<c0s>   fetcher.install(my_url, my_dest, checksum="deadbeef", hash_type="md5)
<c0s> where the checksum and hash type would be coming from ? Assuming my_url is defined in the config.yaml, shall the other two be defined there as well?
<c0s> sorry for the silly question
<c0s> oh I see - I guess I just can add the checksum to the url itself.
<kjackal> cory_fu, kwmonroe, admcleod-, who is where do we set the "namenode.joined" ?
<kwmonroe> suchvenu: i don't know of a conv.units example either, but i think in your provides.py, you'd just define a method that does "return self.conversation().units" and then call that method from your db2 layer when license.accepted and db2.ready.
<kjackal> cory_fu, kwmonroe, admcleod-, interface:dfs
<kwmonroe> yup c0s, you can either have the sum and hashtype as separate config vars (and only call install when all pieces are configured), or stick those onto the url as url?md5=deadbeef
<c0s> k, thanks!
<coreycb> jamespage, gnuoy, thedac: way past eod for a few of you but rockstar needs this fix if any of you happen to be free to review. https://review.openstack.org/#/c/302427/
<beisner> coreycb, do we have full passing on that ^?
<coreycb> beisner, no, I'm waiting for a +2 and full recheck
<coreycb> beisner, or can the full passing come first?
<beisner> coreycb, yah let's get charm-recheck-full passing
<coreycb> beisner, ok
<beisner> fyi thedac is on hols today/tomorrow
<coreycb> beisner, ok thx
<rbasak> neiljerram: mysql-5.7 5.7.11-0ubuntu5 has landed in the release pocket now. If you're using the mysql charm though, I think gnuoy's working on that since it broke something there?
<magicaltrout> are charms building to the charmstore?
<kwmonroe> magicaltrout: wadda you mean by 'building to the charmstore'?
<magicaltrout> push charm to LP -> deploy charm to CS
<magicaltrout> just trying to unbreak my saiku charm so I pushed an update 50odd minutes ago but I don't see an update in the CS
<kwmonroe> magicaltrout: i believe the LP ingestion process is still a thing, but have seen it take an hour(ish).  however, iiuc, if the charm has ever been published with the new "charm push && charm publish" commands, then the LP ingester doesn't look at that anymore.
<kwmonroe> magicaltrout: did you push an update to LP for this one? https://jujucharms.com/u/f-tom-n/saikuanalytics/trusty/3
<magicaltrout> https://jujucharms.com/u/spicule/saikuanalytics-enterprise/trusty/
<magicaltrout> its its up over an hour, i'll return to twiddling my thumbs, i thought it was ~40mins
<marcoceppi> magicaltrout: ingestion is broken at best
<marcoceppi> magicaltrout: use new charm workflow
<marcoceppi> magicaltrout: and help vet our documentation :)
<magicaltrout> that involes me doing things
<magicaltrout> link me up
<marcoceppi> magicaltrout: https://github.com/juju/docs/pull/975
<marcoceppi> magicaltrout: https://github.com/marcoceppi/docs/blob/17b54ba8f49d464a0b26b11fab7087705166c6bf/src/en/authors-charm-store.md
<marcoceppi> magicaltrout: doc is very much WIP, but feedback on that pull request would be great
<marcoceppi> magicaltrout: hope to hvae it finished up by EOW
<magicaltrout> k i'll give it a spin
<magicaltrout> thanks
<kwmonroe> magicaltrout: the nice thing about the new workflow is that you push and it's immediate.. no waiting on an ingestion process to pull
<kwmonroe> dang marcoceppi, really nice job on the wip!  that ascii art and pointer description are really helpful.
 * thumper chuckles at the name of magicaltrout
<thumper> cracks me up
<thumper> morning folks
<magicaltrout> er right them marcoceppi problem #1
<magicaltrout> where do I get a charm exec thats up to date enough to run charm login?
<marcoceppi> magicaltrout: ppa:juju/devel and ppa:juju/stable - you need both
<magicaltrout> er
<magicaltrout> right
<magicaltrout> oh I've got a charm in some anaconda dir stomping on my path
<magicaltrout> dont' even know what/how that got there
<magicaltrout> alrighty then marcoceppi
<magicaltrout> says its published to stable
<magicaltrout> whats the lag time on the UI?
<magicaltrout> because you said its immediate and either its not or I've ballsed up
<jrwren> kwmonroe: magicaltrout looks like ingestion run and your saikuanalytics imported: https://api.jujucharms.com/charmstore/v5/changes/published?start=2016-04-07
<magicaltrout> that does indeed jrwren
<magicaltrout> oh arse
<magicaltrout> wrong bloody bzr launchpad login
<magicaltrout> okay so
<magicaltrout> help me out here ;)
<magicaltrout> logged in with charm login
<magicaltrout> but its associated me with ~f-tom-n and not spicule
<magicaltrout> ah charm whoami
<magicaltrout> okay i'm stuck
<magicaltrout>  /usr/bin/charm push . cs:~spicule/saikuanalytics-enterprise
<magicaltrout> ERROR cannot post archive: unauthorized: access denied for user "f-tom-n"
<rick_h_> magicaltrout: what's f-tom-n?
<rick_h_> magicaltrout: do you have more than one login?
<rick_h_> magicaltrout: can you charm logout?
<rick_h_> magicaltrout: or rm -rf ~/.go-cookies
<rick_h_> and relogin
<rick_h_> using the spicule account
<rick_h_> logout support was added recently, /me goes to look
<magicaltrout> rick_h_: I don't have 2 accounts, I did rename my launchpad account though
<magicaltrout> but as I logged in like 5 minutes ago for the first time, I do'nt see what a logout would do
<rick_h_> magicaltrout: well, charm login thinks your ~f-tom-n and you're trying to submit to the user ~spicule which ~f-tom-n isn't able to
<rick_h_> magicaltrout: so which one did you have before and which one is the current username?
<magicaltrout> yeah, but that was my old launchpad id
<magicaltrout> f-tom-n is the old one, and a few weeks ago I changed it to spicule
<magicaltrout> dumped my cookies and did it again
<magicaltrout> same output
<magicaltrout> well then
<magicaltrout> in a nutshell i can't publish to my new launchpad ID and ingestion seems knackered, so, I'm snookered
<rick_h_> magicaltrout: sorry, meetings wheee
<magicaltrout> aye no worries
<rick_h_> magicaltrout: yea, well it doesn't support the LP username change.
<magicaltrout> so it appears! :)
<rick_h_> magicaltrout: there's work to try to find a path forward, but atm it breaks things since those names are the urls everyone uses to deploy production stuff
<rick_h_> it's like a username with a published PPA, it blocks username
<magicaltrout> rick_h_: but as I already have saiku deployed under spicule and my LP id is now spicule, why can't charm push just use an alternative url
<magicaltrout> even if I have to specify it instead of it being default
<magicaltrout> `https://bugs.launchpad.net/juju-core/+bug/1567690 I dunno where charm tool bugs go, so I filed it in juju core
<mup> Bug #1567690: Can't push charm to my new LP home <juju-core:New> <https://launchpad.net/bugs/1567690>
<c0s> does anyone know if bundletester work with juju 2.0?
<LiftedKilt> is there a way to tell juju that if maas reports a machine as failed-deployment, have it add another machine and retry the charm deployment on that machine?
<LiftedKilt> otherwise if I deploy a bundle with say 9 machines, and one of the machines fails to deploy properly, the whole bundle is in limbo until I manually add a machine and move the units and relationships
<rbasak> jamespage, gnuoy: I've filed bug 1567696 and bug 1567695
<mup> Bug #1567696: mysql-server-5.7.postinst is influenced by ~/.my.cnf, causing installation hangs <mysql-5.7-transition> <mysql-5.7 (Ubuntu):Triaged> <https://launchpad.net/bugs/1567696>
<mup> Bug #1567695: mysql-server-5.7.postinst is influenced by $HOME, causing installation hangs <mysql-5.7-transition> <mysql-5.7 (Ubuntu):Triaged> <https://launchpad.net/bugs/1567695>
<rbasak> I suspect this may be related to your charm problems.
#juju 2016-04-08
<marcoceppi> magicaltrout: the charm push/login stuff goes here: https://github.com/juju/charmstore-client
<webscholar> any one here deployed wordpress on juju2 beta3 ?
<gnuoy> rbasak, jamespage, beisner, I've created a bug for the mysql charm, I'll mark it as a dupe if the root cause is one of the ones that rbasak found last night but I'm going to keep digging at this point because I still think some fault lies with the charm
<gnuoy> Bug #1567778
<mup> Bug #1567778: Charm fails on xenial installing mysql 5.7 <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1567778>
<jamespage> gnuoy, ack - do you need a second pair of eyes on that?
<jamespage> gnuoy, if not I'll poke at bradm's mitaka/nova-cc problem whilst hacking on removal of neutron from nova-cc
<bradm> jamespage: I have LP#1567807 if you want that one too? :)
<jamespage> bug 1567807
<mup> Bug #1567807: nova delete doesn't work with EFI booted VMs <canonical-bootstack> <nova (Ubuntu):New> <https://launchpad.net/bugs/1567807>
<bradm> jamespage: thats possibly more an upstream thing, though.
<bradm> jamespage: oh, fwiw with that n-c-c issue, I dropped the stack back to r226 and the issue went away.
<jamespage> bradm, just trying to repro now
<bradm> jamespage: this happened twice on redeploying the same stack, so it doesn't seem like its too tricky.  unless there's something odd with my setup
<jamespage> bradm, that was with cloud:trusty-mitaka right?
<bradm> jamespage: correct.
<bradm> jamespage: with ppc64 and arm64 compute nodes, not that I know if that makes a difference.
<jamespage> bradm, that should not make a difference
<gnuoy> jamespage, I've got to the bottom of the mysql bug and working on a fix now. If you could take bradms that'd be great
<jamespage> gnuoy, on it - you focus on unblocking mysql
<gnuoy> ta
<jamespage> I'll review and landing that when you are ready
<gnuoy> ack
<jamespage> cause right now we can't fix fa due to that blocker...
<gnuoy> yep
<bradm> jamespage: I didn't think it would, but its the only vaguely special thing about this stack, just about everything else is vanilla.  Oh, g-s-s we have 3 of, using a patched version that gives us better control over the properties on images.
<bradm> but that shouldn't do anything either.
<jamespage> bradm, hey - can I get a copy of the nova.conf from that deployment please?
<bradm> jamespage: on n-c-c ?
<jamespage> bradm, yes please
<bradm> jamespage: https://paste.ubuntu.com/15664360/
<bradm> jamespage: unfortunately I've run out of week, disappearing for dinner now.
<jamespage> bradm, ack
<bradm> jamespage: you can bug a bootstack person to grab any info, they have access to that stack.  they probably just don't know much about it.
<gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/mysql/1567778/+merge/291339 (not run any amulet yet but thought I'd see if you have any objections first)
<jamespage> bradm, ok reproduced
<bradm> jamespage: excellent news.
<jamespage> gnuoy, looks reasonable
<jamespage> was the db init getting confused by files in /var/lib/mysql ?
<gnuoy> jamespage, yep https://bugs.launchpad.net/charms/+source/mysql/+bug/1567778/comments/2
<mup> Bug #1567778: Charm fails on xenial installing mysql 5.7 <mysql (Juju Charms Collection):Confirmed for gnuoy> <https://launchpad.net/bugs/1567778>
<jamespage> bradm, I suspect a problem with the packaging in mitaka-updates with the keystone v3 changes in the charms...
<jamespage> probably
<magicaltrout> marcoceppi: thats very nice, I have no idea how to compile it
<gnuoy> jamespage, err, is osci likely to still do CI things against my mysql branch since its in LP ?
<jamespage> gnuoy, it might
<jamespage> gnuoy, branch scanner will run in 2 mins
<jamespage> gnuoy, tests running now
<gnuoy> ack
<jamespage> gnuoy, bradm: looks like a openstack bug with the packages in mitaka-updates - proposed tests ok so I'll promote proposed -> updates shortly
<gnuoy> jamespage, you think the root cause of Bug #1567236 is a packaging bug?
<mup> Bug #1567236: nova-api-os-compute api failure - DuplicateOptError: duplicate option: auth-url <canonical-bootstack> <nova-cloud-controller (Juju Charms Collection):In Progress by james-page> <https://launchpad.net/bugs/1567236>
<jamespage> gnuoy, well technically and openstack bug but yes
<gnuoy> I mean openstack bug
<jamespage> gnuoy, I can repro with mitaka-updates, but its all ok with mitaka-proposed
<gnuoy> jamespage, ok, I assumed it was a duplicate value in a c config file and couldn't see how it could be
<jamespage> gnuoy, it was not
<gnuoy> jamespage, thanks for getting to the bottom of it
<jamespage> probably a problem with parser for oslo.config or suchlike
<gnuoy> kk
<jamespage> wolsen, dosaboy: hey just a reminder that today its really the last day for landing features for the 16.04 charm release
<jamespage> we should have the gate unblocked shortly - gnuoy - your mysql changes look to be testing ok
<gnuoy> jamespage, https://review.openstack.org/#/c/303302/ if you have a sec
<jamespage> gnuoy, your indentation is well wonky
<gnuoy> oh, let me check
<gnuoy> ah, yeah, one sec
<neiljerram> gnuoy, rbasak, morning
<neiljerram> mysql charm on Xenial is still not working for me this morning - but I think that's expected at the moment, right?
<neiljerram> I just did an interactive 'apt-get install mysql-server' on another Xenial box, and it was fine.  But the charm install fails as you can see here: http://pastebin.com/pTxBmCJF
<gnuoy> neiljerram, If your using the mysql charm then yes, that is expected. the fix is going through testing atm
<neiljerram> gnuoy, Thanks - is there a bug that I can track?
<gnuoy> neiljerram, Bug #1567778
<mup> Bug #1567778: Charm fails on xenial installing mysql 5.7 <mysql (Juju Charms Collection):Confirmed for gnuoy> <https://launchpad.net/bugs/1567778>
<gnuoy> neiljerram, The merge proposal is here https://code.launchpad.net/~gnuoy/charms/trusty/mysql/1567778/+merge/291339 Waiting for the CI to report functional test results atm
<neiljerram> gnuoy, cool, I can test that locally here too
<gnuoy> tip top
<gnuoy> Do you have a +2 laying around for https://review.openstack.org/#/c/303302/ ?
<gnuoy> jam^
<gnuoy> jamespage, ^
<gnuoy> (Sorry jam)
<jamespage> gnuoy, done
<gnuoy> ta
<jamespage> gnuoy, does the mysql charm have a xenial test?
<gnuoy> jamespage, that is a very good question
<gnuoy> jamespage, yes, but not enabled
<gnuoy> argh
<jamespage> gnuoy, well can you test that by hand please
<gnuoy> defo
<jamespage> gnuoy, if it passes on regression testing then we'll land with your manual test
<gnuoy> yep, and I'll post a second mp to enable the test
<jamespage> gnuoy, https://review.openstack.org/#/c/303321/
<jamespage> I think that just about covers it
<jamespage> gnuoy, I need todo a companion to neutron-api to drop the > kilo test
<gnuoy> jamespage, you've left some code in the neutron-api-* hooks, what is that there to support?
<jamespage> gnuoy, hmm - looking
<jamespage> gnuoy, actually they are still required - the nova-cc charm passes data from n-api to nova-compute
<gnuoy> urgh, ok
<jamespage> gnuoy, merging your mysql changes
<gnuoy> jamespage, wait
<gnuoy> jamespage, don't you want the results of tests/021-basic-xenial-mitaka ?
<jamespage> gnuoy, oh yeah - your still executing the xenial test right....
<jamespage> yes I do
<jamespage> gnuoy, nova-cc needs a bit more work - just found another neutron-y bit
<gnuoy> jamespage, ack. err xenial mitaka amulet test for mysql failed becuase keystone failed to install. looking into that now
<gnuoy> jamespage, I'm really confused. The xenial mataka amulet test for keystone was enabled and passed for the run keystone via mod_wsgi change. But install of the charm on xenial is now saying that python-psutil has no NUM_CPU variable
<gnuoy> I guess python-psutil could have changed in the last 48 hours
<jamespage> gnuoy, hmm it might
<neiljerram> gnuoy, FYI, my deployment with your mysql changes is in progress now...
<gnuoy> neiljerram, ok, thanks
<jamespage> gnuoy, looking now
<jamespage> psutil has not changed...
<jamespage> gnuoy, 23:05:54 juju-test.conductor.021-basic-xenial-mitaka RESULT  : PASS
<jamespage> yup it passed...
<gnuoy> jamespage, nope it hasn't changed
<gnuoy> >>> from psutil import NUM_CPUS
<gnuoy> Traceback (most recent call last):
<gnuoy>   File "<stdin>", line 1, in <module>
<gnuoy> ImportError: cannot import name NUM_CPUS
<gnuoy> jamespage, the only thing I can think is that the amulet full test results in the change are from a previous patch set
<jamespage> gnuoy, the charm-helpers code should deal with that
<gnuoy> jamespage, errr I don't think so
<jamespage> gnuoy, psutil.cpu_count is used if detected...
<jamespage> gnuoy, # NOTE: use cpu_count if present (16.04 support)
<neiljerram> gnuoy, mysql unit is now happy, but the related neutron-api unit has hook failed: "shared-db-relation-changed" for mysql:shared-db.  http://pastebin.com/ehHutDmk
<jamespage> neiljerram, unit log from neutron-api would be useful here...
<gnuoy> jamespage, ah! I bet mysql has brought in stable keystone
<jamespage> gnuoy, oh that's quite possible
<jamespage> and likely that's why the test is still disabled
<gnuoy> yep
<gnuoy> jamespage, I'll tactically fix amulet to use keystone from next and rerun the test
<jamespage> gnuoy, I suggest we land part one which does not regress older ubuntu releases and appears to start to fix the xenial problems...
<gnuoy> jamespage, ok, if you're happy to land the mp as is that makes sense to me
<jamespage> gnuoy, +1
<neiljerram> jamespage, https://transfer.sh/dyzRS/unit-neutron-api-0.log
<jamespage> gnuoy, https://review.openstack.org/303344 anotherkeystone/apache2
<gnuoy> jamespage, https://review.openstack.org/#/c/303328/
<jamespage> neiljerram, https://transfer.sh/dyzRS/unit-neutron-api-0.log
<jamespage> no not that
<jamespage> oslo_db.exception.DBError: (pymysql.err.DataError) (1171, u'All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead') [SQL: u'ALTER TABLE cisco_csr_identifier_map MODIFY ipsec_site_conn_id VARCHAR(36) NULL']
<jamespage> that may be an incompat of neutron with mysql-5.7
<neiljerram> I'll see if there are wider reports about that.
<jamespage> gnuoy, and another - https://review.openstack.org/#/c/303347/
<gnuoy> jamespage, https://review.openstack.org/#/c/303328/
<jamespage> gnuoy, oppps overlap
<jamespage> gnuoy, as you already +2'ed mine, lets abandon yours...
<gnuoy> +1
<jamespage> neiljerram, I think our dep8 tests in xenial should be validating that - let me see
<neiljerram> jamespage, There appear to be reports of that problem with MySQL 5.7 across software in general.  Nothing Neutron-specific that I could find, though.
<jamespage> neiljerram, db sync with local mysql 5.7 in ci for packaging looks ok - https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/n/neutron/20160408_095603@/log.gz
<neiljerram> jamespage, And would that be with Mitaka Neutron code?
<jamespage> neiljerram, although that sync is not actually done in the ci tests
<jamespage> neiljerram, yes
<neiljerram> neiljerram, But perhaps the DB in that ci doesn't include cisco_csr_identifier_map table.  I've never heard of that table before.
<jamespage> neiljerram, same packages as from your charm deployment which I find very odd
<jamespage> neiljerram, what is cisco_csr_identifier_map ?
<neiljerram> jamespage, I got that from the error message above.
<jamespage> neiljerram, yeah - just trying to figure out why I don't see that migration in the CI tests - they should be the same always right? there is no conditional migration in neutron any longer based on plugin ...
<jamespage> well at least I think that is the case...
<jamespage> neiljerram, lemme stand up a xenial-mitaka env and take a look as well
<jamespage> mysql fix is in the main charm branch now
<neiljerram> jamespage, gnuoy, thanks on both counts
<gnuoy> neiljerram, np
 * jamespage needs coffee biab
<jamespage> neiljerram, yah - just hit the same thing
<jamespage> hmmm
<gnuoy> jamespage, are you planning to do a full amulet run against your dpdk branch ?
<jamespage> gnuoy, yes
<gnuoy> kk
<jamespage> neiljerram, that migration comes from neutron-vpnaas
<jamespage> I suspect that mysql-5.7 is behaving a little diff to 5.6 here
<jamespage> but need to prove that
<neiljerram> jamespage, But it looks like mysql-5.7 has been out for a while, so I would guess that other OpenStack/Neutron users have been using it.
<jamespage> neiljerram, yeah but its probably not in a gate anywhere just yet...
<neiljerram> jamespage, So I wonder what is the Xenial-specific or charm-specific factor here?  Could it be that common deployments don't include neutron-vpnaas?
<jamespage> neiljerram, this is not a new migration step (its from liberty)
<jamespage> neiljerram, trying neutron-api on xenial against a trusty mysql
<jamespage> gnuoy, suspicion that we may be seeing the same restart race as we saw for apache on the dashboard with keystone now
<jamespage> gnuoy, Apr  8 10:32:01 juju-osci-sv19-machine-2 cron[1086]: Error: bad username; while reading /etc/cron.d/keystone-token-flush
<jamespage> urgh that's not great either...
<jamespage> neiljerram, neutron-api on xenial is find against mysql-5.5 on trusty
<jamespage> craptastic
 * jamespage raises a bug
<neiljerram> jamespage, So basically no OpenStack on Xenial, at the moment... :-(
<jamespage> rbasak, fyi ^^
<jamespage> neiljerram, nope
<marcoceppi> hey magicaltrout, sorry you're having so much trouble with this
<gnuoy> jamespage, do you have a bug number for xenial db migration issue?
<marcoceppi> jamespage: I'm about ~400 copyright notices away from having the charm package clean lint
<jamespage> gnuoy, https://bugs.launchpad.net/ubuntu/+source/neutron-vpnaas/+bug/1567899
<mup> Bug #1567899: alembic migration failure with mysql 5.7 <amd64> <apport-bug> <ec2-images> <xenial> <neutron:New> <neutron-vpnaas (Ubuntu):New> <https://launchpad.net/bugs/1567899>
<gnuoy> jamespage, ta
<jamespage> I think I have a fix - just tried it locally
<gnuoy> that was quick
<rbasak> jamespage: mysqld runs in a stricter mode in 5.7 by default. If necessary, you can configure it to be as relaxed as previously.
<rbasak> jamespage: I'm told that putting NOT NULL in the schema should do it, and there should be no consequences because it was enforced like that previously anyway.
<rbasak> (and that it's not strict mode related)
<jamespage> rbasak, can you comment on that bug please...
<jamespage> gnuoy, neiljerram: ok fix proposed upstream and I've uploaded as a patch to xenial as well
<jamespage> might not be 100% right but should unblock testing for now
<neiljerram> jamespage, Many thanks, I'll take a look shortly.  Will your upload go into the main Xenial archive, or do I need to add a PPA for it?
<jamespage> neiljerram, it will go into the main xenial archive
<neiljerram> jamespage, thanks
<jamespage> neiljerram, I'll shove it in ppa:james-page/xenial as well
<jamespage> uploaded - will take a short while to build
<pmatulis> what is --resource for in 'juju deploy'?
<rick_h_> pmatulis: put it in the other channel
<jamespage> neiljerram, gnuoy: vpnaas fix accepted by the release team
<gnuoy> jamespage, excellent, good work
<beisner> yah - rbasak, jamespage, gnuoy - nice work tracking down the 5.7 issues & thx for the charm work around
<gnuoy> np
<rbasak> Note that I haven't yet uploaded fixes for the bugs I found last night yet for MySQL itself.
<rbasak> Workaround is to not have ~/.my.cnf or ~root/.my.cnf while the maintainer scripts run
<rbasak> Upstream will have updated packaging for me on (probably) Monday. It'll have some other fixes too.
<rbasak> If that's awkward for anyone please let me know.
<rbasak> MySQL itself> I mean packaging src:mysql-5.7
<A-Kaser> Hi, I would like to deploy my charm located on lp ( https://code.launchpad.net/~frbayart/charms/trusty/datafellas-notebook/trunk )
<A-Kaser> juju deploy cs:~frbayart/trusty/datafellas-notebook don't work
<A-Kaser> what is the correct url ?
<neiljerram> lp: instead of cs: I think
<neiljerram> Also need the 'charms' and 'trunk' parts in there - so: lp:~frbayart/charms/trusty/datafellas-notebook/trunk
<A-Kaser> I have tried lot of url format with cs and lp without success
<A-Kaser> I think I have skipped a step
<pmatulis> with 'juju deploy', are there just 2 "repositories"? charm store (cs) and local?
<rick_h_> pmatulis: yes, and local isn't a repository but a path
<rick_h_> A-Kaser: does it show in jujucharms.com?
<rick_h_> A-Kaser: there's a big time gap between a bzr push and the charmstore seeing it
<rick_h_> A-Kaser: there's a new process that's in beta right now for going direct to the charmstore.
<rick_h_> A-Kaser: jcastro marcoceppi do we have a first draft from your sprint we could share?
<marcoceppi> rick_h_: A-Kaser yes
<marcoceppi> https://github.com/marcoceppi/docs/blob/17b54ba8f49d464a0b26b11fab7087705166c6bf/src/en/authors-charm-store.md
<marcoceppi> feedback can be placed here https://github.com/juju/docs/pull/975
<rick_h_> ty marcoceppi
<A-Kaser> rick_h_: no I'm not un jujucharms.com, I do nothing for that
<rick_h_> A-Kaser: right, jujucharms.com pulls charms from LP automatically but it takes 1-2hrs
<jamespage> gnuoy, for these - https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces
<rick_h_> A-Kaser: the new process that is in testing marcoceppi linked you to docs if you want to try it out and get it in immediately to deploy it
<jamespage> I don't intend on a full recheck as the code is the same in all versions...
<A-Kaser> rick_h_: ok I'm reading marcoceppi doc
<A-Kaser> just to know, new charms need to be declared somewhere in jujucharms
<rick_h_> A-Kaser: juju asks jujucharms.com for the charm when you deploy
<A-Kaser> or all repository with "charms" in name  are added ?
<rick_h_> A-Kaser: so if jujucharms.com doesn't know about it yet, neither does juju deploy
<rick_h_> A-Kaser: all repos in charms are pulled in every 1-2hrs
<rick_h_> A-Kaser: or you can use the new system and avoid that old process
<A-Kaser> ok
<A-Kaser> loOk I suppose I need to upgrade my charm command
<A-Kaser> I'm using ppa:juju/stable , and I don't have "push" subcommand with "charm"
<rick_h_> A-Kaser: yes, it's in the devel one right now. But if you go there you'll end up on juju 2.0 as well.
<pmatulis> rick_h_: ty
<A-Kaser> I have started with juju2 but I had too many problem with it
<A-Kaser> so people ask to me to move to v1
<rick_h_> A-Kaser: understand, so you should be ok. it'll make juju2 available but it's a different install
<rick_h_> or you can wait on ingestion into jujucharms.com for now
<rick_h_> A-Kaser: the charm package should hit stable soon. In next week I'd expect
<gnuoy> tinwood, got a sec to review https://code.launchpad.net/~gnuoy/charm-helpers/custom-restart/+merge/291372 ?
<tinwood> yep, running an amulet test, so will jump on it :)
<gnuoy> thanks
<A-Kaser> rick_h_: I have pushed my repo yesterday
<A-Kaser> I'm testing to install charm-tools v2 and keep juju1
<gnuoy> rbasak, do you know if percona-server will follow mysql and shift to 5.7 for xenial imminently ?
<rbasak> gnuoy: I'm not aware of any plans. I haven't heard from Percona in a while.
<gnuoy> rbasak, ack, thanks
<beisner> gnuoy, hrm.  i know that your mysql charm MP amulet test passed, but i've got 2 for 2 fails in mysql full amulet after that landed.  weird.    http://pastebin.ubuntu.com/15688809/
<gnuoy> beisner, which amulet tests is that, the mysql one?
<beisner> yep
<gnuoy> beisner, I *think* that is actually the mysql amulet tests being incompatable with the new mitaka schema
<gnuoy> s/mitaka/mitaka keystone/
<beisner> gnuoy, quite possibly.  we'll need to update the test if so
<gnuoy> beisner, the error is a missing column in a keystone table
<beisner> indeed
<beisner> perhaps crossed paths with a pkg rev in trusty-mitaka uca?  (why it passed earlier, but fails now)
<jamespage> tinwood, out and in for ceph osds?
<tinwood> done for ceph-osd, about to submit for ceph.
<jamespage> tinwood, yeah I was questioning 'out' - that causes an evac of all data off the unit
<tinwood> jamespage, I put a note in the actions.yaml that the 'user' needs to do a pause-health before doing an osd pause.
<tinwood> jamespage, ... if they want to stop the migration of PGs.
<tinwood> jamespage, https://review.openstack.org/#/c/303360/1/actions.yaml
<gnuoy> beisner, oh, sorry I missed the point you were making. 019-basic-trusty-mitaka went from working a few hours ago to not working now
<jamespage> tinwood, yeah - I was looking at that
<jamespage> beisner, I pushed a load of updates into the updates pocket earlier today for mitaka
<jamespage> so that might be the cause...
<tinwood> jamespage,  I didn't think it should be prescriptive (at the charm level) and enforce a noout on the cluster for the pause? But I'm open to suggestions.
<jamespage> tinwood, my base assumption was that we could noout/nodown the osd's on a specific unit
<tinwood> jamespage, I though noout worked at cluster level?
<gnuoy> beisner, Bug #1567971
<mup> Bug #1567971: Mitaka amulet tests fail <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1567971>
<jamespage> tinwood, yes that's correct - my assumption was wrong...
<A-Kaser> marcoceppi: thx for the doc
<beisner> thx gnuoy
<A-Kaser> now I have another error with juju deploy cs:~frbayart/datafellas-notebook-0
<tinwood> gnuoy, I posted my comments on the charmhelpers change.  comment only, as there was a corner case, but it's (in hindsight) fairly unlikely to be activated.
<gnuoy> tinwood, thanks
<beisner> coreycb, \o/ @  https://review.openstack.org/#/c/302427/
<coreycb> beisner, hooray!
<beisner> apache2 init script racing, same as we saw in dashboard as jamespage pointed out
<coreycb> gnuoy, jamespage, this ^ could use a review and +2 by an openstack charmer, it's blocking rockstar
<gnuoy> coreycb, I can tkae a look
<coreycb> gnuoy, thanks
<gnuoy> beisner, I'm working on the assumption that Bug #1567741 is an apache race and am looking to land https://code.launchpad.net/~gnuoy/charm-helpers/custom-restart/+merge/291372 which will allow us to pass a custom restart function to the restart_on_change function. We can use that to replace the redefinition of restart_on_change that we've done in someplaces like openstack_dashboard
<mup> Bug #1567741: get_keystone_manager exhausts retries on:  Unable to establish connection to http://localhost:35347/v2.0/OS-KSADM/services <uosci> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1567741>
<gnuoy> jamespage, I don't suppose you have time for https://code.launchpad.net/~gnuoy/charm-helpers/custom-restart/+merge/291372 ?
<jamespage> I was about to say I'm spinning my wheels looking for something todo
<jamespage> gnuoy, yes
<gnuoy> thanks
<jamespage> gnuoy, coreycb: you have 'liberty' at the top of your nova.conf - I'd ask you fix that and we'll push that review through without OSCI...
<coreycb> jamespage, shoot, ok
<beisner> gnuoy, ack & tyvm.  that looks handy.
<jamespage> gnuoy, +1 landed for you
<gnuoy> jamespage, fantastic, thank you
<coreycb> jamespage, I pushed a new patch series to my review if you want to land it, or i cna
<coreycb> can
<jamespage> coreycb, OK I'll take that - gnuoy <<<<<
<jamespage> coreycb, maybe you could peek at https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces for me :-0
<jamespage> coreycb, +2/+1 workflow on your nova-cc change
<coreycb> jamespage, thanks, sure I'll take a look
<gnuoy> beisner, I've osci https://code.launchpad.net/~gnuoy/charms/trusty/mysql/1567971/+merge/291388 to chew on, hopefully should fix mitaka amulet.
<beisner> gnuoy, i think the xenial-mitaka target will fail there, because it will pull in the stable keystone charm
<gnuoy> beisner, on a related note, once 16.04 is done could we s/mysql/percona/ accross all our amulet tests and stop worrying about mysql charm ?
<gnuoy> beisner, that +x to xenial was a mistake
<beisner> gnuoy, that should be the goal.  but first:  refactor pxc's amulet tests so that it covers something other than trusty.
<gnuoy> ack
<gnuoy> beisner, -x'd xenial in the mp
<beisner> coolio ta gnuoy
<gnuoy> ok, keystone apache race here I come
<beisner> gnuoy, added 2 cards re: mysql->pxc in charm backlog for 16.10, but we should aim for 16.07 in that.
<gnuoy> beisner, ack, +1. Might be a nice thing to twiddle on during ODS
<beisner> gnuoy, if i've got nothing else pressing, i'd like to do that.  i usually take on one fairly major amulet or spec addition or refactor during ods and sprint time.
<beisner> or if you'd like to take it on, quite ok too
<gnuoy> beisner, be my guest, I would be forced to buy you beer though
<beisner> heat, rmq, lxd tests all came about ~sprint time.   will work for beer
<gnuoy> \o.
<gnuoy> \o/ I meant
<jamespage> gnuoy, yah - ready to review that apache keystone race fix once you have it ready
<jamespage> keep hitting it on a recheck-full
<gnuoy> jamespage, trying to decide how proffesional to be at the moment. Either easy stop-sleep-start or slightly more involved stop-check-pids-start
 * gnuoy thinks its beginning to show that my xchat spell checker is broken
<beisner> gnuoy, let's have a look at openstack-dashboard where nearly the same was worked around
<gnuoy> beisner, thats got a sleep
<beisner> bah
<beisner> a fixed sleep is an invitation to race elsewhere
<beisner> i like check; sleep; loop; with a max total wait.
<coreycb> I'm trying to get to juju 2.0 from 1.25.3.  The devel ppa doesn't have a new juju-core, only has a new juju2 client.
<rick_h_> coreycb: yes, apt-get install juju2
<coreycb> rick_h_, you're fast!
<rick_h_> coreycb: in xenial it'll just be 'juju'
<coreycb> rick_h_, thanks
<rick_h_> coreycb: np
<rick_h_> coreycb: let us know how it goes. Have fun playing
 * rick_h_ sends patience pills to coreycb :)
<coreycb> rick_h_, thanks, I may need them.  I've been stuck in packaging land too long.
<gnuoy> jamespage, beisner https://review.openstack.org/303538 <- open for initial comments/critism. I need to fix up the unit tests now
<jamespage> gnuoy, looks ok
<beisner> gnuoy, def feels like restart_pid_check is an apache2 pkg thing, but i understand why we're doing it here.  do you know if the appropriate pkg bug is raised?
<gnuoy> beisner, it has
<beisner> gnuoy, i like how this paves the way for optional restart funcs
<gnuoy> beisner, theres a comment in the horizon charm which references the bug
<beisner> kk thx
<beisner> gnuoy, we should prob also comment similarly in restart_pid_check so that a year or 3 from now we know wth that's there.
<jamespage> gnuoy, generally looks ok - some minor comments on the review...
<gnuoy> beisner, agreed
<gnuoy> jamespage, thanks, I'll take a look
<jamespage> going to take a break for a bit - suspect I will be back later...
<beisner> gnuoy, also 1 comment
<coreycb> rick_h_, do I need to purge  juju-core 1.25.3?
<rick_h_> coreycb: no
<gnuoy> ack, ta
<rick_h_> coreycb: they fit side by side
<coreycb> rick_h_, ok for some reason /usr/bin/juju --version is still 1.25.3-xenial-amd64
<rick_h_> coreycb: for juju2 and beta3 update-alternatives
<coreycb> rick_h_, that's better, thanks. I should have figured that on my own.  sudo update-alternatives --config juju
<gnuoy> beisner, jamespage, thanks for the comments, I've updated the pull request
<beisner> gnuoy, /melikes
<gnuoy> tip top
<gnuoy> ok, I'm stepping out for a little bit. I'll be back later if there are any nacks to respond to
<beisner> gnuoy, thx. i'll keep an eye on it.  will do a full recheck shortly.
<beisner> fyi tinwood, i think the test fail on https://review.openstack.org/#/c/303467/ will be resolved when https://review.openstack.org/#/c/303538/ lands
<beisner> gnuoy, mysql amulet test update landed.  thx again for that.
<tinwood> beisner, thanks.  I'll hold off investigating for the moment.
<c0s> fellas, with juju2 - how would I deploy from local repo? Somehow this
<c0s>   juju deploy --repository=`pwd` local:trusty/apache-bigtop-namenode/
<c0s> doesn't work, claiming the charm/bundle URL is wrong.
<c0s> kwmonroe: cory_fu - any hints? ;) ^^^^
<rick_h_> c0s: just deploy the directory. leave local: out
<rick_h_> c0s: ./apache-bigtop-namenode
<cory_fu> rick_h_: Our charms don't yet include the series in the metadata.  Don't you have to specify the series for local charms?  --series perhaps?
<c0s> I see. rick_h_ and if I need to deploy a bundle - it'd be the same, right?
<rick_h_> cory_fu: i think you can just --series --force ?
<c0s> although, it seems that bundle need to have the info about particular revisions of the charms, hence the repository is needed
<rick_h_> c0s: yes, bundle is the same
<cory_fu> c0s: Within a bundle.yaml, you currently still need local: but that is supposed to change
<c0s> this
<c0s>   juju deploy `pwd`/trusty/apache-bigtop-namenode/ --series trusty
<c0s> at least started doing something
<cory_fu> But if you're talking about deploying a local bundle, you would just: juju deploy bundle.yaml
<c0s> cory_fu: "local bundle" as in 'sitting on my laptop', yes
<c0s> guys, could you share some best practices with me, please?
<c0s> Say, I deployed something and it failed.
<c0s> Is there a quick way to clean up and re-deploy again?
<jamespage> beisner, gnuoy's apache fix recheck-full's ok
<jamespage> beisner, wanna do the honors?
<beisner> jamespage, yep on it
<jamespage> beisner, awesome
<LiftedKilt> c0s: same problem - I destroy the model every time, but it leaves the ghost model in list-models
<c0s> yeah... I stepped on it last night were I couldn't destroy the controller and it wasn't clear why
<c0s> then I realized that I have a ghost model around
<cory_fu> c0s: So, I'm struggling with this as well.  The answer is supposed to be one of: fix the issue + upgrade-charm --force-units + resolved --retry, debug-hooks + resolved --retry, or destroy-model + create-model + re-deploy
<cory_fu> But all of those are having issues for me in 2.0 beta3
<LiftedKilt> c0s: a clean-model or something would be nice - especially with a flag to retain the deployed machines
<c0s> got it.
<c0s> +1 LiftedKilt
<c0s> ok, for now I will just remove the service and the machine. Luckily I only have a single node ;)
<cory_fu> LiftedKilt: I believe there's an open issue about cleaning up those models.
<c0s> stepping away for 20 to grab a bite
<LiftedKilt> c0s: with a single node it's not terrible, but with 20 or so machines and a full openstack deployment it gets annoying
<LiftedKilt> cory_fu: yeah I saw something about thata while back. Hopefully it makes it into beta4
<c0s> yup, agree LiftedKilt
<cory_fu> LiftedKilt: I've also been running into an issue where, if I have done an upgrade-charm in one model, then tear that down and start another, deploys of that charm don't work until I upgrade-charm in the new env as many or more times as I had done in the previous env
<LiftedKilt> cory_fu: oh that's fun
<LiftedKilt> haha
<magicaltrout> awww
<magicaltrout> a dodgy tomcat charm has broken tomcat until monday
<magicaltrout> its like the juju gods don't want me to get saiku reviewed
<magicaltrout> kwmonroe: if you have anything depending on archive.apache.org other than tomcat
<magicaltrout> it will fail to deploy until monday
<magicaltrout> https://bugs.launchpad.net/charms/+source/tomcat/+bug/1568153 for that reason
<mup> Bug #1568153: incorrect reliance on archive.apache.org <tomcat (Juju Charms Collection):New> <https://launchpad.net/bugs/1568153>
<magicaltrout> marcoceppi: as the guy with many fingers in pies you should probably be aware of that as well
<cory_fu> magicaltrout: We never install directly from *.apache.org for that exact reason (and because things get dropped, and the archive is slow, etc.)
<cory_fu> We mirror everything to a jujubigdata S3 bucket
<marcoceppi> magicaltrout: huzzah. tbh, tomcat should probably be a layer instead of a charm
 * marcoceppi ponders this
<cory_fu> marcoceppi: https://i.imgur.com/c7NJRa2.gif
<magicaltrout> lol
<magicaltrout> fair enough cory_fu, just a heads up
<cory_fu> Tomcat could serve as either a base layer or standalone charm, I think.
<magicaltrout> marcoceppi: many thanks to your database guys for unpicking my LP rebranding
<marcoceppi> cory_fu: totally, but a standalone charm built from a layer ;)
<cory_fu> Well, I mean it could serve both roles at the same time, potentially.  If you deploy it directly, it's a standalone charm.  But it could also be coded such that it does the right thing if included via layer.yaml
<magicaltrout> well thats sorta why i piped up on the ML about a webapp interface
<magicaltrout> 10:45 on friday sounds like a good time to update my boxes... what could possibly go wrong
<LiftedKilt> what does "Waiting for agent initialization to finish" mean? I've got an openstack bundle I wrote, and all the charms except the nova-compute are just stuck in limbo
<LiftedKilt> bundle for reference: https://paste.ubuntu.com/15699491/
<rick_h_> LiftedKilt: run juju status --format=yaml
<LiftedKilt> rick_h_: https://paste.ubuntu.com/15699542/
<c0s> weird... getting a lot of error messages in the debug like
<c0s> unit-apache-bigtop-namenode-0: 2016-04-08 21:55:07 ERROR juju.worker.dependency engine.go:509 "uniter" manifold worker returned unexpected error: preparing operation "install local:trusty/apache-bigtop-namenode-0": failed to download charm "local:trusty/apache-bigtop-namenode-0" from ["https://172.31.4.145:17070/model/3f1319b4-ab01-485f-82f1-27afffe6f1a5/charms?file=%2A&url=local%3Atrusty%2Fapache-bigtop-namenode-0"]: expected sha256 "8a9a5571efb6c9f575f56d54d10cd76
<c0s> unit-apache-bigtop-namenode-0: 2016-04-08 21:55:09 ERROR juju.worker.dependency engine.go:509 "metric-collect" manifold worker returned unexpected error: failed to read charm from: /var/lib/juju/agents/unit-apache-bigtop-namenode-0/charm: stat /var/lib/juju/agents/unit-apache-bigtop-namenode-0/charm: no such file or directory
<c0s> cory_fu: I am deploying from local repo - any ideas what'd be issue?
<cory_fu> c0s: Yes, that's exactly the upgrade-charm issue I'm running in to contantly
<cory_fu> c0s: Just do `juju upgrade-charm namenode` until it works
<c0s> I am not even doing upgrade ;(
<c0s> I am creating new model and deploying fresh
<c0s> that's the status
<c0s> ID                       WORKLOAD-STATUS JUJU-STATUS VERSION   MACHINE PORTS PUBLIC-ADDRESS MESSAGE
<c0s> apache-bigtop-namenode/0 unknown         allocating  2.0-beta3 0             54.183.6.62    Waiting for agent initialization to finish
<cory_fu> c0s: Yeah, I think it has something to do with the new model  resetting the internal rev of the charm it's looking for but subsequent deploys still incrementing the the internal rev in the controller
<cory_fu> i.e., every time you `juju deploy namenode` or `juju upgrade-charm namenode`, the controller increments the rev.  But every new model gets its rev set back to 0
<c0s> so, shall I nuke the controller cory_fu?
<cory_fu> c0s: That would  certainly work, but you can probably work around it by doing pointless upgrade-charms, as I mentioned
<c0s> nah... nuking is easier and surely cleaner. Thanks man!
<cory_fu> Sorry you're hitting these beta bugs.  They're certainly irksome
<cory_fu> c0s: It's EOD time for me.  Have a good weekend
<c0s> no worries.
<cory_fu> And safe travels!
<c0s> I will push for a couple more hours and then switch off as well - need to pack and stuff. The flight is at noon.
<c0s> Thanks! TTL
<c0s> Have a good weekend, cory_fu
<LiftedKilt> cory_fu: in my debug logs I'm seeing stuff like
<LiftedKilt> manifold worker stopped: preparing operation "install cs:~openstack-charmers-next/xenial/openstack-dashboard-200": failed to download charm "cs:~openstack-charmers-next/xenial/openstack-dashboard-200
<LiftedKilt> is that the same problem you are looking at?
<cory_fu> LiftedKilt: Possibly.  I've seen it show that "failed to download" message in two different ways.  One mentions the hashes not matching, which can be worked-around with upgrade-charm, but I've also occasionally see it mention "Bad request" and then I have to just destroy the controller and re-bootstrap
<LiftedKilt> cory_fu: Ok yeah I'm seeing the bad request 400 message
<cory_fu> Yeah, I have no idea what causes that or how to get around it other than starting over
<cory_fu> LiftedKilt: Now would be a good time for you to open a bug about that one
<cory_fu> I can't reproduce it consistently and didn't open a bug about it the times it happened to me (shame on me)
<LiftedKilt> cory_fu: I'll check on Monday and open one then - I want to try and get openstack up and running before end of the day
<cory_fu> ha.  That's about what I said to myself when I didn't open a bug about it before.
<LiftedKilt> cory_fu: Thanks for guilting me into it haha
<LiftedKilt> https://bugs.launchpad.net/juju-core/+bug/1568176
<mup> Bug #1568176: charm deployment requests invalid revision number <juju-core:New> <https://launchpad.net/bugs/1568176>
<LiftedKilt> linked it in case you wanted to add any pertinent info
<dsc> would anyone here know how provide MAAS credentials to juju2? all of the previous mass schema wont be accepted
<mattrae> dsc: this solution worked for me http://askubuntu.com/a/744065
<dsc> thanks so much...I was looking through the code to try to figure out how it was intended to be parsed
<mattrae> sure no problem
<dsc> it looks like the MAAS rest api has changed in version 2.0+ and in my search of the juju source I couldnt find any refrences to the api path that is appended to the uri other than in test files. anyone know where that is set (I need to change /MAAS/api/1.0/ to/MAAS/api/2.0/ )
<LiftedKilt> dsc: maas 2.0 support is still pending for juju2
<dsc> I checked out the maas2 branch to look for it
#juju 2016-04-10
<rohit_> hello everyone.. today for the very first time I tried installing juju and  bootstrap it locally using lxd .I got this error as reported in the bug https://bugs.launchpad.net/juju-core/+bug/1566589
<mup> Bug #1566589: ERROR cannot find network interface "lxcbr0": route ip+net: no such network interface <juju-core:Fix Committed by tycho-s> <https://launchpad.net/bugs/1566589>
<rohit_> I could bootstrap it after configuring the bridge with the name "lxcbr0" .. is the fix not released yet?
<rick_h_> rohit_: fix is landing and release early next week
<rohit_> ð
<arosales> Thanks rick_h_
<arosales> Sounds like rohit_  was able to work around the issue
<petevg> Hi, everyone. I've got a newbie question: is there an equivalent of "juju generate-config" in juju2 (devel)? "charm test" is complaining about my sad lack of an enviroments.yaml, and I'd like to ask juju to write one for me, rather than trying to write it myself.
<jrwren> petevg: sounds like you have a stale version of charm test.
<petevg> jrwren: that sounds plausible.
<petevg> I apt installed it. I just have the devel ppa setup, so I thought that it'd grab the right version. I could be wrong , th
<petevg> *though.
<petevg> (Also: thank you for getting back to me on a Sunday.)
<petevg> ... just got pulled away from my computer (helping a friend's kid tour a college campus). I will argue with apt about what it installed when I can grab another chair and wireless connection.
<jrwren> petevg: hrm, no, if you are using devel ppa, then you have latest. hrm. might be a bug with charm test.
<jrwren> petevg: or well, not a bug, but i'm guessing charm test does not yet support juju2
<petevg> Oh no. Sadness. :-( Is there an alternative official way to run the tests as a package, or should I just setup a virtualenv and point nose at the test dir?
<jrwren> Sorry, I don't know. virtualenv and nose probably works great.
<petevg> jrwren: Thank you very much for the help, and for saving me some time fruitlessly arguing with apt and dpkg :-) I will work on getting the tests setup with my old standbys.
#juju 2017-04-03
<aisrael> I've done something slightly dumb; moved a juju controller/model, on lxd, to a new bridge. The containers have the right ip now, but the juju controller isn't accessible. It looks like the api websocket isn't listening on the new ip.
<kjackal> Good morning Juju world!
<admcleod> kjackal: hello! do you have a good example for peer relations?
<kjackal> hello admcleod, I guess the best would be ZK or spark
<admcleod> spark please
<kjackal> admcleod: Give me a sec to spot the respective
<kjackal> code
<admcleod> interface-spark-quorum?
<kjackal> admcleod: Here is the interface: https://github.com/juju-solutions/interface-spark-quorum/blob/master/peers.py
<kjackal> admcleod: Here is the interface: https://github.com/juju-solutions/interface-spark-quorum/blob/master/peers.py
<admcleod> thanks
<kjackal> admcleod: updating peers ends up here: https://github.com/juju-solutions/layer-apache-spark/blob/master/lib/charms/layer/apache_spark.py
<kjackal> admcleod: after going though the reactive part: https://github.com/juju-solutions/layer-apache-spark/blob/master/reactive/spark.py#L143
<admcleod> kjackal: i wonder, why use unit scope and not global for peering?
<kjackal> admcleod: https://github.com/juju-solutions/layer-apache-spark/blob/master/lib/charms/layer/apache_spark.py#L294
<kjackal> admcleod: that is a good question!
<kjackal> admcleod: not sure I have a good answer
<admcleod> or service
<admcleod> kjackal: looks like UNIT is what it should be. im trying to do something really simple, just setting a state (conv.set_remote('thing', True) and then trying to read it back (a = conv.get_remote('thing')
<admcleod> kjackal: but it keeps returning None and im sure its something simple. got a good example of this?
<kjackal> admcleod: you want all nodes to agree on a remote 'thing'?
<admcleod> kjackal: yep
<kjackal> admcleod: have you consedered using the leadership layer?
<admcleod> yes, but this should work no?
<kjackal> yes, peers should work as well but I feel you will be coding the same logic that you can find in leadership
<admcleod> thats fine
<kjackal> admcleod: let me look at the zk layer, It might be easier
<admcleod> kjackal: i want the leader to be able to set 'is_leader, True', which all other peers should be able to see - that bit i could do with leadership. but i also want all other peers to set a state, "non-leader ready"
<kjackal> admcleod: looking at the zk quorum there is not magic: https://github.com/juju-solutions/interface-zookeeper-quorum/blob/master/peers.py#L55
<kjackal> admcleod: give me a sec for the non-leader state, I have seen an example
<kjackal> admcleod: here is how kubernetes-master figures out if it is the leader: https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L145
<kjackal> admcleod: and here is what happens if it is not: https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L191
<kjackal> I think you should have something like "when_not('leadership.is_leader')
<kjackal> def nonleader():
<kjackal> set_state('non-leader')
<kjackal> status_set('active', 'non-leader ready')"
<kjackal> admcleod: ^
<admcleod> kjackal: right.. yeah... but
<admcleod> kjackal: when_not leader, i want to set something.. like "ok im ready".
<admcleod> kjackal: then once all the other nodes have set ready, the leader can do action
<kjackal> admcleod: I see... this is tricky... how would you know that all your non-leaders are up? What if you have some non-leader pending provision?
<admcleod> kjackal: it gets a list of all other nodes (it knows its the leader). it checks if those other nodes had set a state (ready). if it hasnt, it waits
<admcleod> kjackal: anyway. i guess the thing here is... for me, set_remote and get_remote dont appear to be working as id expect
<kjackal> admcleod: The thing that needed some care when we were doing these interactions was that we would have to use conv.set_state('my_state') to signal the other side that something has changed https://github.com/juju-solutions/interface-zookeeper-quorum/blob/master/peers.py#L31
<admcleod> ah.
<kjackal> admcleod: after that the other end would have to go and do a get_remote('whatever')
<kjackal> admcleod: basicaly you should model the message enchange "protocol" using conversation states
<admcleod> kjackal: told you it was somethign simple. thanks
<kjackal> admcleod: :)
<admcleod> kjackal: also, how do you force an update-status now?
<admcleod> kjackal: nvm
<joedborg> hey all!  is the Joyent cloud still supported?
<joedborg> hey all!  is the Joyent cloud still officially supported?
<Diabelko> is there anything special I should know about using Juju with MAAS?
<Diabelko> used to work just fine up until I removed the model and tried to redeploy the environment
<Diabelko> now it doesn't boot the servers and I don't see anything in the logs
<joedborg> Diabelko: can you still play with the nodes via MaaS?
<kjackal> joedborg: Joyent should be still supported
<joedborg> kjackal: seems that apt fails now
<kjackal> joedborg: how does it fail? At which point?
<admcleod> kjackal: turns out its a problem with the function im calling after i set the state (with set_remote) - it seems as if, since its in 'executing' state, the state i sent hasnt been committed.. and there doesnt seem to be a flush that applies to set_remote
<cory_fu> tvansteenburgh, petevg, stokachu (and anyone else who feels like reviewing): https://github.com/juju/python-libjuju/pull/102 when you have a chance
<stormmore> lp|swap, what you swaping today?
<mbruzek> stormmore: Yes he is. Is there something I can help you wiht?
<stormmore> mbruzek, not at the moment, thanks though :) just wanted to let him know that I think I figured out the last "bug" I came across with regards to seeing old replicasets for heapster
<mbruzek> Was there any code change needed? (hint: I am working on our next release)
<stormmore> mbruzek, no I think based on what I am seeing elsewhere, it is working as designed.
<stormmore> mbarnett, the "problem" (hence the confusion) is that heapster ends up with 3 replicasets but only 1 which has running containers
<stormmore> mbruzek, no code needed I think based on what I am seeing elsewhere, it is working as designed.
<mbruzek> stormmore: OK glad to read that. If you need anything in the next release please let me know
<stormmore> mbruzek, in testing deployments of my own services, it would appear that this is the design so that it makes it easier to roll back
<mcapsali1> hi guys
<mcapsali1> i have a problem with python-jujuclient and juju ha and maybe you can help me
<derekcat> jamespage: Hey, thanks for the reply!  Could you resend that message?  I didn't have chat logging turned on until now >_<  [I got a notification that said, "Actually that's a charm bug that's been...", but I didn't have enough scrollback]
<mcapsali1> we run juju 2.0.1 with 3 state machines in ha
<mcapsali1> we have a custom python code that uses python-jujuclient to deploy a bundle and then use juju.watcher to monitor the deployment untill it is finished
<mcapsali1> the problem is that sometimes after a bundle deployment, jujuclient tries to reconnect to a watcher
<mcapsali1> https://paste.ubuntu.com/24307892/
<mcapsali1> here is a paste of the error
<mcapsali1> iá¸¿ not that good with python but as i understand there is no Â´connectorÂ´ instanciated in jujuclient code when the reconnect occurs
<mcapsali1> there is a bug opened in december 2016 with the same problem, it seems this only occurs in a juju ha env
<mcapsali1> this bug https://bugs.launchpad.net/python-jujuclient/+bug/1639104 is similar to what we expirience
<mup> Bug #1639104: can no longer deploy to model: 'error': 'shared state watcher was stopped' <canonical-bootstack> <canonical-is> <landscape> <python-jujuclient:New> <https://launchpad.net/bugs/1639104>
<mcapsali1> any suggestion will be greatly appreciated :)
<tvansteenburgh> mcapsali1: the best suggestion i can give is to submit a patch for the bug
<tvansteenburgh> mcapsali1: or you can try using the new python client
<tvansteenburgh> mcapsali1: python-jujuclient isn't gonna get much love going forward
<tvansteenburgh> mcapsali1: https://github.com/juju/python-libjuju
<cory_fu> mcapsali1: I should note, though, that I think that also has an issue with reconnects (issues #98 and #99)
<mcapsali1> iÄºl take a look into that
<mcapsali1> did not know there was a new python client
<mcapsali1> ty everyone
<mcapsali1> i will get back if i run into same problem is the new client :)
<cory_fu> mcapsali1: It seems like the connector call ought to be picking up https://bazaar.launchpad.net/~juju-deployers/python-jujuclient/trunk/view/head:/jujuclient/juju2/environment.py#L21
<tvansteenburgh> cory_fu: it's a Watcher though
<tvansteenburgh> i think there are just missing connector properties on the juju1 and juju2 Watcher subclasses
<cory_fu> tvansteenburgh: Hrm.  I figured the Watcher would need to be based off the correct Environment for the correct version of Juju?
<cory_fu> I see
<cory_fu> So it might be enough to copy that connector method to the Watcher class there?
<tvansteenburgh> yeah
#juju 2017-04-04
<viswesn> Juju will delete the storage that were added automatically on removing the charm?
<kjackal> good morning Juju world!
<viswesn> It is juju that will delete all the storage automatically that were added to the charm/unit on removing it or on destroying the controller. Please let me know if I am wrong in my understaning
<jhobbs> one of my units is receiving a config changed hook every few hours or so, I am not sure where it is coming from, how can I debug that?  is there some way to enable logging of what is triggering the hook, and what config is changing?
<jhobbs> ok.. i think it's this "when recovering from transient unit agent errors"
<jrwren> jhobbs: does juju status show that it is not in error state?
<jhobbs> i'm not sure jrwren, i'm not polling it constantly
<jhobbs> http://paste.ubuntu.com/24313724/
<jhobbs> w/wg 2
<jrwren> jhobbs: you should probably run juju status and see what it says. Maybe `juju status --format yaml` to get more details.
<admcleod>  /query kwmonroe
<admcleod> wut
<kwmonroe> spaces ftw
<kwmonroe>  /kickban admcleod
<admcleod>  /troutslap kwmonroe
<rogpeppe> here's a question: can anyone think of a juju command that uses a single model that can succeed if there's no current model and no model specified?
<rogpeppe> jcastro: ^
<cory_fu> tvansteenburgh: If you have a minute, would you mind taking a look at https://travis-ci.org/juju/amulet/jobs/218604087 to see if you can figure out why it's complaining about "import yaml"?  pyyaml is in the test-requirements.txt and the pip log shows that it should be installed.
<tvansteenburgh> cory_fu: https://travis-ci.org/juju/amulet/jobs/218604087#L679
<cory_fu> tvansteenburgh: Yes.  "requirement already satisfied"  So why would it fail to import?
<tvansteenburgh> yeah but it's not actually installed in the venv
<cory_fu> tvansteenburgh: What venv?
<cory_fu> Oh, Travis creates one.  Hrm
<cory_fu> How did this work previously?
<cory_fu> tvansteenburgh: Oh, it's because the install script is being run with sudo
#juju 2017-04-05
<wesleymason> https://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2
<wesleymason> doh, wrong channel
<erik_lonroth> Great post!
<pranav_> Hi. Need help on keystone:identity-admin relation.
<pranav_> Getting a 403 error when trying to list service/user with the admin user
<pranav_> # /usr/bin/openstack --os-username admin --os-password "openstack" --os-project-name admin --os-auth-url http://172.101.101.9:5000/v3 --os-identity-api-version 3 project show service You are not authorized to perform the requested action: identity:list_projects. (HTTP 403) (Request-ID: req-f62bf819-b814-4335-a019-fd8cac60d433)
<pranav_> keystone charm set with preffered-api-version 3
<tardimctardyface> Hi all. Any thoughts on the best way to "refresh" all the juju machines after I restored the controller from a backup. Each machine/service is working fine but all agents show up as "lost" and all machines are "down". From bug-reports/docs I understand it's because each agent/machine doesn't know about the new controller IP address, but how do I force them to check a new one? Will "juju upgrade-juju" work?
<pranav_> Hi Folks. Getting 403 forbidden error when using admin user credentials.
<pranav_> # /usr/bin/openstack --os-username admin --os-password root123 --os-project-name admin --os-auth-url http://172.101.101.9:5000/v3 --os-identity-api-version 3 project show service You are not authorized to perform the requested action: identity:list_projects. (HTTP 403) (Request-ID: req-f453f64b-aa53-42f9-be36-49b3442faf3e)
<pranav_> my charm creates a identity-admin relation.
<urulama> bdx: so, i tried the replicate the "big bundle deploy" on a 2.2 tip and it passed without problems deploying on 100 machines
<urulama> bdx: i'll verify on 2.1 and 2.0.2 now
<petevg> cory_fu: I've got a lonely PR here: https://github.com/juju/python-libjuju/pull/105 (feel free to pull me into a hangout if you want to grill me on the approach -- I think that it's the Right Thing to do, but I'm open to arguments against :-) )
<cory_fu> petevg: Yep, I have been looking at PRs all morning and that is on my list.  :)
<petevg> cory_fu: cool. Thx :-)
<cory_fu> petevg: LGTM.  I added a comment, but I'm +1 to merging it
<petevg> cory_fu: cool. Will read the comment. Thank you.
<cory_fu> petevg: Comment'd
<petevg> cory_fu: thx.
<petevg> cory_fu: left a comment on your comment. I think that you're right. There's a reason that I went the way that I did -- it avoids some potentially messy bits -- but having Python code that a dev can read is probably worth the cost of doing a bit of naughty magic with import.
<cory_fu> petevg: I had a follow-up comment about how to handle the changes in the object layer, if you missed that
<petevg> cory_fu: I missed it. And that's a good point, too. I assumed that the object layer would have the job of maintaining backwards compatibility. We could technically version it, too.
<cory_fu> petevg: I definitely don't want to see the object layer versioned.  :p  Either conditionals in the object layer, or if it contains enough application logic (which I think it does) then a proper facade over the versioned API interfaces (what we're currently calling facades but which I think is inaccurate)
<petevg> cory_fu: yeah. I'm writing a comment, but it's getting complex.
<petevg> cory_fu: I think that you vision is good. I think that, practically speaking, we may have to drop in add-hoc fixes in the object layer to patch over the places where our Facades aren't really Facades.
<cory_fu> petevg: Also, for making the import logic easier, what if we generate an __init__.py for the "facades" with an __all__ that lists the versions?  Then we just do a single normal import and a getattr  with the version number?
<cory_fu> petevg: Our "facades" definitely aren't facades and will require translation, so I think we should start calling them versioned API interfaces ASAP
<cory_fu> :)
<petevg> cory_fu: That sounds like a good idea, though if I can figure out a way to do it without calling getattr, I'll be happier :-)
<cory_fu> petevg: Also, I wasn't thinking that we'd do any monkey patching.  Rather, I was thinking of something like a get_versioned_api factory method or something.  Again, this should probably be wrapped in actual facades
<petevg> cory_fu: yeah. The factory thing I mentioned in the notes sounds better and better.
<petevg> cory_fu: ... and that almost makes these things into proper facades. The one missing piece is that your object layer might want to pass in extra args that only work with a newer version of juju, or might want to access properties on an object that don't exist in earlier versions.
<cory_fu> petevg: When I say factory, I still mean that the Python code would be pre-generated.  There would just be a method responsible for returning you an instance of the right class by version.
<petevg> cory_fu: exactly.
<cory_fu> Ok
<cory_fu> Just wanted to make sure we were talking about the same thing.  :)
<cory_fu> Anyway, I have to run to an appointment
<cory_fu> bbiab
<petevg> cory_fu: so you do something like action = Action.connect, and you get the right version of an Action facade.
<petevg> cory_fu: cool. Thx for all the comments, feedback, and generally making my life harder by bringing up things that I didn't thin about :-)
<petevg> *think
<stormmore> o/ juju world
<stormmore> hey marcoceppi I think I have figured out that replicaset issue
<bdx> urulama: thats awesome! the set of fixed bugs @anastasiamac listed looked pretty applicable to what we were seeing ... great news none the less
<bdx> urulama: did you still experience the issue on 2.0.2 and 2.1?
<urulama> bdx: yeah, 2.0.2 right now ... i need to manually remove around 100 machines from gce console :D
<urulama> bdx: we'll upgrade controllers to 2.1.2 soon, and then to 2.2 in may when it's out
<urulama> soon = this or latest next week
<bdx> urulama: niceeeeee
<bdx> urulama: does that mean the beta controller will rev too then?
<urulama> bdx: not sure i understand the question
<bdx> urulama: the hosted controller .... when will it get receive the upgrade to 2.1.2?
<urulama> bdx: this or latest next week
<bdx> urulama: my bad I miss read above ... thx
<urulama> bdx: the upgrade to 2.2 will happen when it's out, and that is planned end of month, early May
<bdx> urulama: thats great news
<bdx> urulama: thanks for looking into this
<urulama> bdx: np, always looking to improve where we can scale better :)
<jose> marcoceppi: hey, do you have time for a quick call?
<marcoceppi> stormmore: I'm interested
<stormmore> marcoceppi, I updated the ticket with my notes on the issue
<stormmore> marcoceppi, just seems odd that the install would cause heapster to be deployed 3 times
<marcoceppi> stormmore: linky? (for the lazy)
<stormmore> https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/241
<stormmore> marcoceppi, you lazy?!? :P
<marcoceppi> ;)
<stormmore> I thought lazyPower was the only lazy one in here
<stormmore> marcoceppi, let me if what I put in there makes sense as I have been pretty brain-foggy today
#juju 2017-04-06
<oops__> hi, is there a privare charm store setup guide?
<oops__> juju status stuck on: "allocating 0/lxd/0 waiting for machine". Any ideas?
#juju 2017-04-07
<anrah_> Does destroy-model and destroy(kill)-controller use same methods to delete instances from openstack provider?
<anrah_> I have weird problem where I can not delete model correctly, as the destroy fails to juju.worker.dependency engine.go:492 "undertaker" manifold worker stopped: destroying storage: listing volumes: <openstack IP> x509: certificate signed by unknown authority
<anrah_> I have ssl-hostname-verification     model    false on both controller and other models
<kklimonda> how do I access models of other users?
<kklimonda> seems like juju status -m user/model doesn't work
<kklimonda> and I can't do juju switch user/model
<anrah_> kklimonda: Has the other user granted permissions for your user?
<kklimonda> @anrah_ should he, if I'm a superuser?
<blahdeblah> BlackDex: are you Fairbanks from launchpad?
<BlackDex> blahdeblah: Yes
<blahdeblah> BlackDex: Got your message about nrpe charm - good to hear the patch worked for you.  I'd like to do a little more testing over the weekend if that's all right with you.
<blahdeblah> I'm happy to push to candidate channel if you have some things you'd really like to do with it today.
<BlackDex> Ow, now, i can deploy it localy :)
<BlackDex> and i can switch to the cs version when it is pushed
<blahdeblah> OK - cool
<BlackDex> that doesn't bother me
<blahdeblah> thanks
<BlackDex> But nice that is is fixed :)
<BlackDex> You thx :)
<BlackDex> for fixing this
<blahdeblah> np
<dgonzo> SaMnCo: following your blogpost I'm able to get a gpu/cpu kubernetes cluster deployed
<dgonzo> I'm hitting an error when to trying to `juju deploy mydir/bundle.yml`
<dgonzo> ERROR cannot deploy bundle: cannot resolve URL "local:xenial/cuda-1": unknown schema for charm URL "local:xenial/cuda-1"
<dgonzo> now that path i put in there was just a guess
<dgonzo> How can I list locally build charms?
<tvansteenburgh> dgonzo: just use a local path to the charm
<tvansteenburgh> dgonzo: in your bundle -> charm: /path/to/my/charm
<tvansteenburgh> dgonzo: which blog post are you following? maybe i can help.
<SaMnCo> dgonzo: Cool, happy you succeed :)
<SaMnCo> https://usercontent.irccloud-cdn.com/file/Be2u6c50/enable-efs.sh https://usercontent.irccloud-cdn.com/file/DW4bx2vM/enable-gpu.sh https://usercontent.irccloud-cdn.com/file/DUCnVqKo/k8s-gpu.yaml
<SaMnCo> dgonzo: these are my latest versions. deploy the bundle first, then watch until it is finished
<SaMnCo> this deploys 3x CPU workers on m4.xlarge, and 3x on p2.xlarge
<SaMnCo> then run enable-gpu.sh
<SaMnCo> if you need an EFS drive, edit enable-efs.sh and add the EFS ID, then run it
<SaMnCo> regarding building charms, you need the charm-tools package
<SaMnCo> then there is a fair amount of info here : https://jujucharms.com/docs/stable/developer-getting-started
<SaMnCo> this describe how to get started
<Budgie^Smore> o/ juju world :)
<stormmore> o/ juju world
<kklimonda> is there a way to forward agent with juju ssh?
#juju 2017-04-08
<Budgie^Smore> so now I am officially a full-tme job seeker, hopefully I will find a place that either uses juju or is open to it!
<dgonzo> SaMnCo & tvansteenburgh thank you
<SaMnCo> dgonzo: np, happy to help. What are you working on lately? Would a bare metal cluster of 3x nVidia Pascal P5000 help?
<dgonzo> SaMnCo: I'm working on automating the setup of our cloud cluster. Next step is to figure out what level of autoscaling we can employ.
<dgonzo> NVIDIA has reached out to us about a couple bare-metal projects so that would be helpful but right now the focus is our aws cloud.
<dgonzo> just started the deploy again and it appears to be working. I read through the `enable-gpu.sh`
<dgonzo> I see that's to run once the cluster is up. Have you looked at any of the stuff on autoscaling? I see clarifai (e.g. folks who worked on the "--experimental-nvidia-gpus" suppor) hint at it and I ran into the autoscaling bundle by elastisys https://jujucharms.com/u/elastisys/autoscaled-kubernetes/bundle/0
<dgonzo> anything else you can point to on autoscaling kubernetes would be appreciated ... but it looks pretty sparse when this all hits GPUs
<SaMnCo> Exactly dgonzo I was about to point you to that. SimonKLB can you help and send a link to your video about Elastisys & CDK?
<SaMnCo> With CDK you could set constraints on services and then be done.
<SaMnCo> Howamy nodes are you looking at?
<dgonzo> SaMnCo: This is still a dev cluster. I would like to start with one CPU node and one GPU node and have the cluster scale based on resource needs.
<dgonzo> SaMnCo: I'm getting an unable to connect from kubectl (both installed and the pre-configured client I scp'd from k8s master)
<dgonzo> "Unable to connect to the server: dial tcp 35.164.49.125:6443: i/o timeout"
<SaMnCo> juju expose kubernetes-master
<dgonzo> ahh, great
<SaMnCo> did you get the scripts I shared yesterday? These fasten the process quite a bit (but the next official release will have auto GPU discovery
<SaMnCo> )
<dgonzo> I was just about to mess with the SG settings in aws proper
<SaMnCo> so you won't need to worry about the GPU anymore
<dgonzo> I did. Awesome. I'll keep following your progress. This is such a sore spot in AI workflows and our current processes are very hacky
<Zic> hi here, I just saw that I can use the latest version of Docker in CDK when configuring the kubernetes-worker charm... can I and "how" do this afterward on a production cluster?
<Zic> we have a serious performance bug in the latest Docker package from Ubuntu archive that we don't have on latest Docker version
<dgonzo> SaMnCo: ran kubectl create -f ./nvidia-smi.yml and the container is erroring out:
<dgonzo> 2017-04-08T17:06:55.508474879Z container_linux.go:247: starting container process caused "exec: \"nvidia-smi\": executable file not found in $PATH"
<SaMnCo> interesting
<SaMnCo> let me check
<SaMnCo> dgonzo can you send the nvidia-smi file you are using (is it the one from my repo?)
<dgonzo> it is the one from your repo
<SaMnCo> ok
<SaMnCo> wondering if nvidia changed their images
<SaMnCo> I should have locked that to a specific version and build my own
<dgonzo> currently kubernetes dashboard is reporting issues : Service Unavailable (503)
<SaMnCo> when you go on the long link from kubectl cluster-info
<SaMnCo> ?
<SaMnCo> in the version I used for the blog, which is an old stuff, we did not include that endpoint, and the only way to look at the kubeUI was to do a kubectl proxy
<SaMnCo> more recent versions allow it with an admin:admin login
<dgonzo> ok. Yeah I'm using the kubectl proxy
<SaMnCo> so if you use the bundle from the blog, it is abit outdated
<dgonzo> it was fine but broken jobs were piling up on the nvidia-smi
<dgonzo> ok
<SaMnCo> right, delete the job
<SaMnCo> will stop the bleeding
<SaMnCo> I'm downloading teh nvidia/cuda image to have a look, but my connection is really bad here
<SaMnCo> it is taking ages
<dgonzo> yeah, it's a big file
<SaMnCo> if you can download then run locally on your laptop, see if the binary has been moved
<SaMnCo> then change the command from the nvidia-smi.yaml
<SaMnCo> then I will probably have to update the post
<SaMnCo> laster 300MB...
<dgonzo> delete seems to hang. Is this right "kubectl delete -f bundles/nvidia-smi.yml"
<dgonzo> also I'm familiar with running CUDA on my labptop (GTK equipped) but I'm not sure what you're asking me to check. Are you wanting me to try and run the cuda charm locally?
<SaMnCo> no
<SaMnCo> docker pull nvidia/cuda
<SaMnCo> docker run --rm -it nvidia/cuda bash
<SaMnCo> then try running nvidia-smi from the command line
<SaMnCo> it should fail, as it failed on k8s, saying the binary is not in $path
<SaMnCo> dgonzo: ^
<SaMnCo> then do
<SaMnCo> find / -name "nvidia-smi"
<SaMnCo> and see if it returns something
<SaMnCo> if yes, update the nvifia-smi.yaml file at the line command:
<SaMnCo> to include the full path of the binary, then reinstall it in the cluster
<SaMnCo> via kubectl
<dgonzo> I'm able to run the nvidia/cuda bash locally
<dgonzo> even though it didn't fail I'm getting this for the PATH
<dgonzo> /usr/local/nvidia/bin:/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
<dgonzo> e.g. # echo $PATH
<SaMnCo> ok
<SaMnCo> give me a sec
<dgonzo> ok I don't think I'm understanding...
<dgonzo> ok
<SaMnCo> I am 9MB away from having the image
<dgonzo> nvidia-docker is not in the cuda image
<dgonzo> :)
<dgonzo> sorry nvidia-smi is not a command in the nvidia/cuda image as far as I can tell
<SaMnCo> yes, they seem to have removed it
<SaMnCo> which is why the test fails
<dgonzo> ok, nice. At least my problem is sane
<SaMnCo> yep
<dgonzo> locally i'm using nvidia-docker and nvidia-docker-compose
<dgonzo> so k8s and juju are all new to me... I'm feeling dumb :)
<dgonzo> I've had quite a bit of success rolling out GPU capable docker containers
<SaMnCo> no problem, we are here to help
<SaMnCo> have a look into https://hub.docker.com/r/opless/t-nvidia-smi/
<SaMnCo> I am sorry my connection is really bad, hard for me to DL 1GB in less than 30min
<SaMnCo> but if you can
<SaMnCo> run the same test
<SaMnCo> docker pull ...
<SaMnCo> docker run --rm opless/t-nvidia-smi nvidia-smi
<dgonzo> ok, i'm lucky to have GB internet
<SaMnCo> if it returns something that is not a path problem, then you may replace the image in the nvidia-smi.yaml file by this one
<dgonzo> pulling now
<SaMnCo> cool
<dgonzo> nope, getting a path problem with that image too
<SaMnCo> grrrmmmmh
<SaMnCo> ok, give me a set
<dgonzo> np
<dgonzo> not sure if it will be helpful but here's what I've been doing to run nvidia containers with compose directly on aws
<dgonzo> https://github.com/NVIDIA/nvidia-docker/wiki/Installation
<SaMnCo> oh but you are running nVidia CUDA containers
<SaMnCo> it is just that I used this as a test
<dgonzo> *nods*
<SaMnCo> and the test fails because of the Docker image, not of anything else
<SaMnCo> there is no doubt you can run these, but I like easy proofs
<SaMnCo> and this just fails now and it annoys me
<SaMnCo> so here is my idea
<dgonzo> hah!
<SaMnCo> can you do the following for me
<SaMnCo> juju ssh kubernetes-worker-gpu "sudo find / -name nvidia-smi"
<SaMnCo> juju ssh kubernetes-worker-gpu/0 "sudo find / -name nvidia-smi"
<SaMnCo> sorry first line I forgot the 0
<SaMnCo> this will return a path
<SaMnCo> then
<SaMnCo> juju scp kubernetes-worker-gpu/0:<path you got> ./
<dgonzo> ok
<SaMnCo> from that, you should be able to build a docker image FROM nvidia/cuda
<dgonzo> hmm not getting any results from the find command
<SaMnCo> https://www.irccloud.com/pastebin/JZNCQVte/
<SaMnCo> wtf maybe they just killed it
<dgonzo> :(
<SaMnCo> what happens if you do
<SaMnCo> juju ssh kubernetes-worker/0 "nvidia-smi"
<dgonzo> so I just ran NV_GPU=0 nvidia-docker run -it --rm nvidia/cuda
<dgonzo> and then which nvidia-smi
<dgonzo> and get
<dgonzo> /usr/local/nvidia/bin/nvidia-smi
<dgonzo> ... trying
<dgonzo> bash: nvidia-smi: command not found
<SaMnCo> oh I am so stupid I think the nvidia-smi is shared from the host
<SaMnCo> it is not in the container itself
<SaMnCo> do you have the CUDA installed and all that?
<dgonzo> you're not stupid that's just wacky
<dgonzo> I do cudnn and all that
<SaMnCo> the cluster you deployed, so you have CUDA installed on the workers?
<SaMnCo> meaning you have the CUDA charm built locally and so on?
<dgonzo> I thought I did how can I triple check
<dgonzo> yes
<SaMnCo> juju status
<SaMnCo> should return a line with CUDA
<dgonzo> yes
<SaMnCo> and like all green
<SaMnCo> ok
<dgonzo> well, I have a Status = unknown
<SaMnCo> can you run
<SaMnCo> juju ssh kubernetes-worker-gpu/0 "ls -l /dev/nvidia*"
<SaMnCo> do we have the devices created there?
<dgonzo> ls: cannot access '/dev/nvidia': No such file or directory
<SaMnCo> juju ssh kubernetes-worker-gpu/0 "sudo ls -l /dev/nvidia*"
<SaMnCo> sorry
<dgonzo> yeah, still no
<dgonzo> (cluster) gonzo@gonzo-msi:~/Projects/ziff/cluster$ juju ssh kubernetes-worker-gpu/0 "sudo ls -l /dev/nvidia"
<dgonzo> ls: cannot access '/dev/nvidia': No such file or directory
<dgonzo> so looks like my deploy failed on cuda
<dgonzo> ??
<dgonzo> I'm going to try redeploying cuda and see where it goes wrong
<SaMnCo> I am publishing the charm in my namespaces
<SaMnCo> so you can use that
<SaMnCo> ok so, replace the charm line by cs:~samuel-cozannet/xenial/cuda-0
<SaMnCo> this is the same code base as what I have been using
<dgonzo> cool
<SaMnCo> so at least we will know if it is again outdated, but I used this like 2 days ago and it worked fine
<dgonzo> so looks like my deploy failed on cuda si:~/Projects/ziff/cluster$ juju deploy cs:~samuel-cozannet/xenial/cuda-0
<dgonzo> ERROR cannot resolve charm URL "cs:~samuel-cozannet/xenial/cuda-0": cannot get "/~samuel-cozannet/xenial/cuda-0/meta/any?include=id&include=supported-series&include=published": unauthorized: access denied for user "davidbgonzalez"
<SaMnCo> ah maybe I need to grant you some rights
<dgonzo> ... I just tried rebuilding and deploying from the cloned repo and this time got and error "hook failed: install"
<dgonzo> I'm going to remove that relation and app and try the charm you've shared and circle back on the error later
<SaMnCo> ah you can try again
<SaMnCo> ok I got to go for tonight, but the charm is now in the store
<SaMnCo> and public
<dgonzo> thanks! I'll keep hacking really appreciate the help
<dgonzo> buenas noches
<SaMnCo> np, happy to help
<SaMnCo> keep me posted
<Catalys> Hey folks, I just deployed a local environment of openstack (based on LXD) on a test machine. I was trying to have the nova compute node change from virt-type lxc to kvm, however it doesn't same to get processed. There is a warning that is shouldn't be changed after deployment, assuming this is because it might break running VM's, however we don't have any yet. Is there a way to force the change though?
#juju 2017-04-09
<rick_h> Catalys: no, I don't think so as it's not compatible on the machine to have both kvm and lxc related tools install (kernel bits)
<rick_h> Catalys: can you change the config and add units and remove the old units?
<Catalys> rick_h: I use conjure-up.io for deployment, do you know how to open the configuration window there (or juju).
<rick_h> Catalys: type "juju config nova-compute" to get the config from it
<rick_h> Catalys: so conjure-up is a great way to get the deploy setup and going. To modify it and run it longer term there's juju underneath so you can check things with "juju status" and change config with the config command and do things like "juju add-unit"
<Catalys> rick_h: Oh I did juju config nova-compute virt-type=kvm which didn't seem to work. I guess I can try the units you've suggested though.
<rick_h> Catalys: right, so it can't be changed on units already running
<rick_h> Catalys: so the question is, if you juju add-unit nova-compute does it come up with the new config and come up as kvm?
<Catalys> rick_h: If I just run "juju add-unit nova-comput" it gives me "ERROR No model in focus.".
<Catalys> compute*
<rick_h> Catalys: oh I see. We'll have to select what conjure-up setup.
<rick_h> Catalys: "juju controllers"
<rick_h> Catalys: and then "juju switch xxxxx"
<rick_h> Catalys: and then you can see "juju models" and switch to the right model that conjure-up created
<Catalys> Says no controllers registered but it suggests "Please either create a new controller using "juju bootstrap" or connect to another controller that you have been given access to using "juju register".
<Catalys> rick_h: Do I use the bootstrap command or might that wipe it?
<rick_h> Catalys: no, don't bootstrap. conjure-up had to do that for you. Is this on the same machine you ran conjure-up on?
<Catalys> rick_h: Oh wait a minute lol.
<Catalys> rick_h: I was logged in to the wrong user...
<Catalys> rick_h: Alright so the add-unit command seems to have been run, but didn't return anything. Is that correct though?
<rick_h> Catalys: right, now in juju status there should be a new unit of nova-compute coming up
<Catalys> rick_h: Yup it's there as pending/
<Catalys> rick_h: It seems to have been created with lxd and openvswitch. Should I pass a flag when I add-unit though?
<rick_h> Catalys: no, it just means that the new one is checking with the leader and/or previous units when making the decision
<rick_h> Catalys: I wasn't sure if it would be its own awesome unit or not
<Catalys> It is another nova-compute/1 does that means it just takes the config from /0 or?
<Catalys> rick_h: Would I delete the original one then?
<rick_h> Catalys: so you typically set the config on the application and all the units respect that config
<rick_h> Catalys: however, in this case, the units need to all behave the same or things like balancing vms across units of nova won't work well
<Catalys> rick_h: Are you familiair with conjure-up since I want to move it to a MAAS environment, but not sure how many node's I need. It seems to be 4, will that mean 1 controller and 3 computing nodes, since that is the preferred too.
<rick_h> Catalys: yea, looks like 3 for the openstack and 1 for the juju controller: https://docs.openstack.org/developer/charm-guide/getting-started.html
#juju 2018-04-02
<pmatulis_> rock & roll
<cynthiaoneill> Just curious, when running the juju canonical-kubernetes charm, is there a way to indicate we donât want some of the things deployed (like loadbalancer)?  Or recommended way to remove?
<cynthiaoneill> Using the juju command line (not conjure)
<hml> cynthiaoneill: is a bundle (grouping of multiple charm), so you can download and modify it for your own purposes.
<hml> cynthiaoneill: you can also remove charms by running âjuju remove-application <charm name>â
<cynthiaoneill> @hml: cool.  So each âcharmâ is really a single application?
<hml> cynthiaoneill: yes
<hml> cynthiaoneill: once a charm is deployed, we call it an application.
<cynthiaoneill> @hml - nice that will work well!
<cynthiaoneill> @hml:  I found a bundle that includes canal (which is the networking we want).  What would be the command to deploy that bundle using juju command line.  Would this work? juju deploy cs:~containers/bundle/canonical-kubernetes-canal-78
<hml> cynthiaoneill: yes
<cynthiaoneill> tks
<cynthiaoneill> Are there guides on troubleshooting (i.e. restarting, or reconfiguring services) the canonical kubernetes deploy?  I checked to see what services are there.  Do we just restart these?? sudo ls -alt /etc/systemd/system/*kub*
<kwmonroe> cynthiaoneill: the k8s-master charm (which is include in all the k8s bundles) has a restart action so you wouldn't need to systemctl those services directly: https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/README.md#actions
<kwmonroe> cynthiaoneill: instead, you could do something like "juju run-action --wait kubernetes-master/0 restart"
<kwmonroe> cynthiaoneill: similarly, the k8s-worker charm has its own set of actions: https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-worker/README.md#operational-actions
<kwmonroe> more info on juju actions (including debugging them) is available at https://jujucharms.com/docs/stable/actions
<bjonnh> what are the possibilities to expose the ports of juju created containers (lets say haproxy) to an interface of the host? (using lxd localhost)
<bjonnh> IÂ use a bridge but now, all the machines are exposed to the bridgeâ¦
<cynthiaoneill> Would I need to modify the bundle to change kube-apiserver settings?  (I noticed no RBAC, and not the right defalut admission controllers for 1.9)
<kwmonroe> cynthiaoneill: if the default apiserver settings are not working for 1.9, please open an issue at https://github.com/juju-solutions/bundle-canonical-kubernetes/issues.  that said, you can adjust args for the apiserver, controller-mgr, and scheduler (see 44-70 for descriptions: https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/config.yaml#L44) using something like: juju config
<kwmonroe> kubernetes-master api-extra-args=arg=value
<cynthiaoneill> @kwmonroe what is the command example to pass api-extra-args?
<cynthiaoneill> Or is this a change in the bundle?
#juju 2018-04-03
<cnf> does anyone use juju with maas pods? trying to figure out how you define the amount of disk space a pod should have
<stapler> Hi, I am getting an error when deploying cs:~tengu-team/ssl-termination-proxy-0
<stapler> cannot get discharge from "https://api.jujucharms.com/terms": cannot acquire discharge: POST "https://api.jujucharms.com/terms/discharge"
<stapler> what would that mean?
<kwmonroe> cmars: anything wonky with terms this morning? ^^
<cmars> kwmonroe: yes, we had a temporary outage earlier this morning, should be fixed now
<cmars> stapler: ^^
<kwmonroe> roger dodger, thx cmars
<cynthiaoneill> Best way to test changing the kube-apiserver arguments?  Iâd like to modify the startup
<cynthiaoneill> I got it, modfied the args and restarted
<knobby> cynthiaoneill: if you change the config on the charm it will handle the restart and everything for you
<cynthiaoneill> ok, but wanted to change several api server arguments, iâll have to see if the config lets me do that
<knobby> cynthiaoneill: It does, you can do something like `juju config kubernetes-master api-extra-args="runtime-config=batch/v2alpha1=true profiling=true" and it would pass --runtime-config=batch/v2alpha1=true --profiling=true in addition to the other args. Anything you pass takes precedent as well.
<cynthiaoneill> Thanks!
<cynthiaoneill> The kubernetes-master charm supports a configuration option called âenable-rbacâ.  What would be a command example using this?
<tvansteenburgh> cynthiaoneill: if you want to turn on rbac you can do so with: juju config kubernetes-master authorization-mode="RBAC,Node"
<tvansteenburgh> cynthiaoneill: more info here: https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Authorization-Mode-and-RBAC
<cynthiaoneill> Yay!!!  Thatâs what I needed.  We would also want secure-port and bind, Iâll try it that way.
<bjonnh> I'm getting a "sudo: unable to resolve host juju-138a08-0" when doing a "juju bootstrap localhost controller --config=juju.config.yaml"  (config sets the proxies, no direct internet access on these machines)
<bjonnh> (lxd 3.0.0)
<bjonnh> it seems that the bootstrap just hangs there
<bjonnh> looking at the log file, I see that it reaches the login
<bjonnh> but there is a (probably stuck) "sudo /bin/bash -c /bin/bash -c  set -e tmpfile=$(mktemp) trap "rm -f $tmpfile" EXIT cat > $tmpfile /bin/bash $tmpfile"
<cynthiaoneill> When I change to secure-port=443, and bind-address=0.0.0.0, I get this error when doing kubectl get nodes: Error from server (InternalError): an error on the server ("<html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>502 Bad Gateway</h1></center>\r\n<hr><center>nginx/1.10.3 (Ubuntu)</center>\r\n</body>\r\n</html>") has prevented the request from succeeding (get nodes)
<cynthiaoneill> I donât have to use secure-port=443 for the apiserver if we use an ingress to terminate the encryption - just learned.  So the dashboard ssl termination would be nice if it went to an ingress controller
<bjonnh> is there a way to fix the hwaddr of the controller?
<bjonnh> (using lxd)
<pilot8092> Hi, has anyone configured OpenStack to use VLANs through Juju? I am not sure where it is best to ask this (I have tried Ask Ubuntu but I have not yet received a response). Does anyone have further information about where I might ask?
<pilot8092> or if anyone can point me in the direction of documentation on the networking components of the OpenStack charm, that would be great, too. I have been struggling with this for several days
<bdx> pilot8092: yeah
<bdx> pilot8092: I gotchu covered
<bdx> doing just that right now on my own cluster
<bdx> pilot8092: https://paste.ubuntu.com/p/pxtWjkJpVb/
<cynthiaoneill> Is there a juju way to install tiller into kubernetes?
#juju 2018-04-04
<cnf> 5        down                     pending              xenial           cannot run instances: cannot run instance: No available machine matches constraints
<cnf> how do i make it try again?
<cnf> this is against MaaS
<bdx> cnf: juju help commands
<cnf> bdx: yes, i did that
<bdx> cnf: juju help commands | grep remove-machine
<cnf> i can't find a command that does it
<cnf> right, so you can't retry, you have to remove, and readd
<bdx> then
<bdx> juju help remove-machine
<cnf> which doesn't work btw, you have to remove the unit first
<bdx> ahh
<bdx> cnf
<bdx> please read the help docs for remove-machine
<cnf> i have removed the machine ages ago
<cnf> my question was how can i make it retry, to which the answer is "you can't" aparently
<bdx> cnf: if it failed the first time, what makes you think it would succeed a second time without manual intervention of some sort?
<cnf> because i did the manual intervention on maas
<bdx> cnf: yeah, you just have to `juju remove-machine # --force` and redeploy it
<bdx> (to the best of my knowledge)
<cnf> yeah...
<zeestrat> cnf: you might want pour some more gasoline on this fire so we can get retry-provisioning to work: https://bugs.launchpad.net/juju/+bug/1645422
<mup> Bug #1645422: retry-provisioning doesn't retry failed deployments on MAAS <4010> <cdo-qa> <cpe-onsite> <landscape> <maas-provider> <retry-provisioning> <juju:Triaged> <https://launchpad.net/bugs/1645422>
<cnf> zeestrat: will do tomorrow
<cnf> zeestrat: thanks
<Mmike> Hi, all. Is there a (faster than 'juju models') way to get the current juju model?
<Mmike> I want to add that info into my bash prompt, but having bash do 'juju models' each time is pretty slow
<Mmike> currently i'm defaulting JUJU_MODEL to 'default' and display that, and refrain from using 'juju switch', and I display JUJU_MODEL in my path, but I'm wondering if there is a better way
<kwmonroe> Mmike: you mentioned refraining from 'juju switch', but calling that with no args will give you the current <controller>[:model]
#juju 2018-04-05
<bdx> Mmike: https://gist.github.com/jamesbeedy/7a2226b7ab097e7e329cb45c54c5097d
<bdx> Mmike: I hacked at it for a while, that is as clean and simple as I could get it
<Mmike> kwmonroe, heh, did't know that ;) 'juju switch' and 'juju whoami' are fast enough, it seems
<Mmike> bdx, thnx! I'll expand that a bit, so that it shows JUJU_MODEL, unless it is set up it will do 'juju whoami/juju switch' and display what's relevant. I actually prefer JUJU_MODEL because that way I can control two different environments/models within different terminals, or so.
<TheAbsentOne> Is it possible with actions to deploy a new charm or a subordinate?
<TheAbsentOne> Someone willing to take a look at this: https://ciberth.gitbooks.io/logboek-thesis/content/actions.html I want to know if this is possible in juju and if so how you can deploy subordinates or charms inside actions! Thanks for the help!
<zeestrat> TheAbsentOne: I haven't seen anything about deploying charms or subordinates (kind of the same thing) from actions so you might want to ask the mailing list about that one. Just so I understand your use case, is there a reason why you want to use something like a generic-db-manager and subordinates instead of talking directly to the mysql server? The MySQL shared interface might be helpful if you want work with sharing multiple
<zeestrat> db's with different applications: https://github.com/openstack/charm-interface-mysql-shared
<TheAbsentOne> Thanks for replying zeestrat! Maybe I should try the mailing list idd. To clarify the situation: I'm doing a research about virtual data administrators. The basic idea is that a user can request a generic database instead of a certain technology. For example if an applications needs some kind of SQL database then the user doesn't really care if it's on mysql, mariadb or even postgresql
<TheAbsentOne> Part of my research is looking into this matter conceptually and with oasis tosca, but we want to implement (or try at least) some parts of it with juju as well. The big problem I have is that I want to create charms that do not really represent applications but in this case a database. I hope this clarifies it a bit, zeestrat? :)
<TheAbsentOne> So in a concrete example: imagine a charm requiring a generic-sql interface and the generic-db-manager providing that then the whole ecosystem should work if under the generic-db-manager hangs a mysql or a mariadb charm from the charmstore
<TheAbsentOne> I need some sort of manager node though because I want to offer flexibility to create databases and re-use them as needed
<zeestrat> I think I understand. Well the current mysql interfaces allow you to use either mysql and percona-cluster already but I understand that you want a more generalised version for other sql's so I'd check with the mailing list for the best approach.
<TheAbsentOne> Well I'm by far not an expert (not in juju and not with all database technologies) but I try to find ways to make it work ^^ thanks for trying to help though zeestrat . Could you recommend someone to talk about this before using the mailing list? The last juju show kinda comes close tbh
<TheAbsentOne> In addition to that, either I'm really missing something but it seems that when I use the mysql charm, I can't choose a specific database name?
<zeestrat> TheAbsentOne: rick_h_ might know or who to ask (NA time zone), but you might as well hit the list to get some more eyes.
<TheAbsentOne> He follows PT? I'll try to keep that in mind
<TheAbsentOne> Thanks again though!
<zeestrat> Right, so the mysql charm just installs and sets up a mysql server. A charm that wants to use a mysql then needs to specify what it needs, dbname, username, password etc using the mysql interface which is what talks to the mysql charm. If you look at the readme in https://github.com/openstack/charm-interface-mysql-shared you see example use cases where an example charm configures a couple of db's.
<zeestrat> Both the mysql charm which deploys the mysql server and the charm requiring mysql communicate using the mysql interface which is their common language so to speak.
<TheAbsentOne> Exactly, maybe I'm a bit too focussed on the wordpress example and that is confusing me. But in the db-relation-changed hook there is this line "database=`relation-get database`" getting the database name right? But where is this defined originally, because when I tried it all values are kinda random. Is that default behaviour when it's not filled in or something zeestrat ?
<TheAbsentOne> I think I played mindgames with myself here. Sorry for the stupid questions
<zeestrat> No no, it's most likely just a not good enough example, especially with the wordpress charm which is a bit old and only has the standard mysql interface (which page are you looking at btw?). The thing is, there are a bunch of different interface that are defined that charms either provide (server) or require (client). You can see the list here: https://github.com/juju/layer-index. If you look closely, there are multiple
<zeestrat> different mysql interfaces. The links I posted earlier are for the `mysql-shared` interface which is a bit more fully featured where you can define things yourself compared to the standard `mysql` interface. The wordpress charm you're looking at only knows about the standard `mysql` interface which I think just generates a database for you.
<zeestrat> You can see the different interfaces that a charm supports by looking at the interface widget in the charm store, for example https://jujucharms.com/wordpress/ and https://jujucharms.com/percona-cluster/, or in the `metadata.yaml` in the charm directories.
<TheAbsentOne> I was looking at the api from the wordpress charm. I'm gonna use the shared one with a custom example later today.
<TheAbsentOne> Yeah I get the workflows, bit confused by the auto generated values and not finding where it's auto generated
<TheAbsentOne> I'm gonna toy a bit around with it and come back later to it. I need to figure out a way though to communicate with juju from within hooks for my desired action functionalities :/
<zeestrat> Gotcha. Then I'd really recommend reaching out the list. I've seen some charms use a bit of a workaround by adding an service user to the juju model which they then connect to from the charm (https://jujucharms.com/charmscaler/), but there's probably a better way to do what you want so I'd ask.
<TheAbsentOne> nice, yeah I'll think I'm gonna mail. But I'll prepare some clear documentation first as it might be a bit abstract. Thanks again man, I don't know what I would do without the help of you guys!
<zeestrat> No problemo. Please do make sure to add a comment in the mail and/or in a bug (https://github.com/juju/docs/issues) on where the docs and examples are unclear or lead you astray :)
<TheAbsentOne> I've been thinking about suggesting a tutorial/roadmap when I'm done!
<rick_h_> TheAbsentOne: zeestrat so ideally there's on real love in the db names. They're named after the relation other end so it's somewhat identifiable but doesn't require manual input and if you setup > 1 you don't have name collisions
<rick_h_> TheAbsentOne: zeestrat, however, one thing is that I was talking about enabling things like new dbs, that normally take place over a relation, to be able to be done via a charm action
<rick_h_> in that case having things like optional db names as part of running the action would be sweet
<rick_h_> that was a basic note during the juju show stuff from last week.
<TheAbsentOne> Exactly! The question then pops up where do we want that action be performed on? Do you want "juju run-action mysql create name=mynewdb" or do you want to perform this action to another charm.
<rick_h_> TheAbsentOne: ? I don't get the "on another charm" bit
<TheAbsentOne> For most use cases the mysql charm would be the fitting answer. But for my use cases with generic databases I want some knowledge to happen on a higher level. Do you know by any chance rick_h_ if it's possible to deploy charms/subordinates inside an action/hook?
<rick_h_> TheAbsentOne: so the idea there is that the various dbs you want to support need to have a common action language. So the same action can work the same way on different charms and the charms are wrapping the 'how to' knowledge
<TheAbsentOne> https://ciberth.gitbooks.io/logboek-thesis/content/actions.html This might illustrate it or clarify.
<TheAbsentOne> Yes exactly
<rick_h_> TheAbsentOne: so yea, I'd propose that the manager isn't really necessary if everything supports the same list of actions that are common
<TheAbsentOne> Meaning that it doesn't matter if you have a mysql or mariadb charm when talking about sql databases.
<rick_h_> then you just run it where you need it, but that's just a quick glance
<rick_h_> TheAbsentOne: rgr
<TheAbsentOne> That is true, the manager is not needed if the mysql charm, mariadb charm, postgrescharm, mongodb charm, cassandra charm, ... all support that action
<TheAbsentOne> Now I'm curious what rgr means? :o rick_h_
<rick_h_> TheAbsentOne: ah sorry, roger
<rick_h_> like "I hear you, roger" or whatever
<rick_h_> it's my short way of saying ... kk
<TheAbsentOne> ohn gotcha xD haha
<rick_h_> or something
<TheAbsentOne> rick_h_: In my ultimate working proof of concept I would have an application that needs a database (and it's allowed to be anything so mysql, mariadb, postgres but mongodb would be fine too!) and that my "generic database" charm would determine what kinda service the app would use and everything would still work.
<TheAbsentOne> But it might be impossible with juju
<rick_h_> TheAbsentOne: right, but in the end you still need to ask the user what db to use and you still need those dbs deployed, and they still need to have the right actions/etc.
<TheAbsentOne> Well that's the thing the user in my use case won't need to worry about that
<rick_h_> TheAbsentOne: so its' running a VM you're paying for and maybe it'll do more later, but just for selecting which db to add a new database to I'm not sure how much value it's adding there.
<rick_h_> gotcha
<TheAbsentOne> Another way of looking at it is this: you have a bundle that deploys a set of big data tools and stuff right. The data scientist will get some data from "a database" but it doesn't matter what it is. I kinda want to model his infrastructure with these generic db charms
<TheAbsentOne> But you are definitely right about the added value part rick_h_ therefore they are letting me (a stupid student) research it :P
<parlos> Good Morning
<kwmonroe> rick_h_: grafana-11 is in the beta channel (includes your gettingstarted)
<rick_h_> kwmonroe: awesomesauce
#juju 2018-04-06
<ybaumy> can i move a juju controller folger in vcenter to another location or will this break functionality?
<ybaumy> s/folger/folder
<parlos> Is there any (easy) way to search the config options of a model? Either via gui or console?
<zeestrat> parlos: Are you thinking of searching through the options of `juju model-config` or `juju config <charm>`?
<parlos> @zeestrat not sure, probably model. Cf, I've got a model, that is made of several applications(charms, would this be the charm?), each application needs to have the same 'identifier' ..
<parlos> The default identifier could be "myIdentifier", now as I want to change that to "theirID" I need to find all locations of "myIdentifier" and replace it...
<parlos> as now, you need to know that myIdentifier is used in app A,B and C..and change it 'manually'
<zeestrat> parlos: I'm sorry, but I'm not quite sure I understand. Could you try with an concrete example with commands that you're doing manually right now?
<zeestrat> Haven't had my coffee yet :)
<parlos> Get Coffee, I'm on my 3rd :)
<parlos> So; I've selected the Openstack-bundle; by default there is a "region" called RegionOne. This appears in quite a few of the applications; (this is just an example)
<parlos> If I'd like to change this, I need to identify what applications has a config option set to "RegionOne", and change that.
<parlos> Now, for OS I have an idea what apps have this, but for a different model... Id probably be lost.
<zeestrat> parlos: Gotcha. I actually don't think that there is an easy way to do that right now without scripting a bit and looping through all applications/charms in a model and running `juju config <name-of-charm>`. But it sounds like a valid use case so I'd file a request at https://bugs.launchpad.net/juju
<zeestrat> Ideally you'd define the options you care about in the bundle so you know which values are where, but that does not cover inheriting models and charms with values (either default or otherwise).
<parlos> Ok, for a bundle, I'd think it would be great if it has a list of default options, that will be applied, when the bundle is 'read'.. no clue how to do it..
<parlos> zeestrat this isnt really a bug... is it used to track requests too?
<zeestrat> Yup. You can also ask the mailing list about this. P.S. Most of the folks are in the US so the activity usually picks up in a few hours.
<parlos> ok, will try to write it down.
<zeestrat> parlos: I hear you about the bundle. Right now it's a balance of the options you define and relying on some sane defaults. My approach at work is to explicitly specify the charm revisions and some of the options and then test the heck out of config changes and charm upgrades. However the use case of managing large scale charm config changes in models after upgrades post bundle deployment are not covered.
<zeestrat> I'll gladly voice some support on a mailing list post or bug if you write something up.
<cynthiaoneill> What does it mean to expose the kubernetes-worker?  What exactly is exposed?
<bdx> cynthiaoneill: juju help <command>
<bdx> going to be your best friend
<bdx> `juju help expose`
<bdx> https://jujucharms.com/docs/2.3/charms-exposing
<cynthiaoneill> cool.  I donât think of a kubernetes worker as an application. It deploys several apps needed by kubernetes (kubelet, kube-proxy..)
<bdx> in the context of juju
<bdx> it is an application
<bdx> https://jujucharms.com/docs/2.3/juju-concepts#unit-and-application
<bdx> cynthiaoneill: has no one showed you the docs yet?
<cynthiaoneill> Iâve seen them.  Iâm trying to understand from a security point of view, if this makes our cluster insecure
<gvseghbr> cynthiaoneill: In the case of K8s it is not really necessary to expose the workers. Especially if you have a secure API gateway serving access to the pods
<cynthiaoneill> gvseghbr: Thanks!
<gvseghbr> but what it basically does, is creating firewall rules in your cloud provider, to allow access to all the open_ports (known to Juju). You can see which ports are open via `juju status`
<cynthiaoneill> gvseghbr: I see which charm is exposed, with juju status.  The Ports for each Unit are listed, so if Load balancer is exposed then only Port 443 is open?
<cynthiaoneill> and tcp
<cynthiaoneill> never mind 443 is a tcp port :)
<cynthiaoneill> Ooh closing off the worker is important, 80 was exposed
<gvseghbr> yes, (was looking for one of our k8s clusters with the loadbalancer), the loadbalancer only has port 443 open (over TCP)
<Cynerva> cynthiaoneill: nginx-ingress-controller is the service that listens to ports 80 and 443 on kubernetes-worker, and it's responsible for handling Ingress resources in kubernetes. If you don't have any Ingress resources defined, all the incoming requests will get routed to default-http-backend, which I think serves up a 404 response
<gvseghbr> Does anybody know how I can get the private IP address from within a charm? The introduction of FAN in Juju 2.3.x seem to have changed a lot. Even if I'm not using containers on GCE, FAN is still being setup. And now every time I try to get the private IP address of a unit (local or remote, it doesn't matter) I always get the FAN IP address, somewhere in the 252. range.
<bdx> gvseghbr: you have to use network_get() now (I think)
<gvseghbr> yes, but I always get the FAN IP address. I'm looking for the actual IP address of the machine
<gvseghbr> I thought FAN only "kicked in" when I would use containers on a machine. However, it seems it is now the only private IP I can get from a charm
<bdx> gvseghbr: its in the model-config
<bdx> gvseghbr: I think you just set `$ juju model-config fan-config=""` if you don't want the fan
<bdx> I think you also need to set `juju model-config container-networking-method=local` or `juju model-config container-networking-method=provider` - depending on what you want
<bdx> gvseghbr: network_get() should return a dict with all of the ip address in formation ... are you parsing that?
<bdx> not sure if this is the best example, but this is how I'm using it https://github.com/omnivector-solutions/layer-redis/blob/new_endpoints_trials/reactive/redis.py#L32
<kwmonroe> gvseghbr: i think by default, network-get will return  address for all interfaces.. since the fan-XXX interface is last, you might be picking the last value.  using network-get with --ingress-address should get you the real private ip.
<kwmonroe> https://charm-helpers.readthedocs.io/en/latest/api/charmhelpers.core.hookenv.html#charmhelpers.core.hookenv.ingress_address
<gvseghbr> This is what I get from within debug-hooks: `>>> network_get('public') {'ingress-addresses': ['252.1.224.1'], 'bind-addresses': [{'macaddress': '62:b6:9e:a6:c7:8a', 'interfacename': 'fan-252', 'addresses': [{'cidr': '252.0.0.0/8', 'address': '252.1.224.1'}]}]}`
<kwmonroe> gvseghbr: verify with: juju run --unit <app>/n 'network-get <endpoint> --ingress-address --format yaml
<kwmonroe> oof, only 1 ingres address, eh?  and that sure looks fanny.
<kwmonroe> gvseghbr: do it without debug hooks with that juju run above and see what it returns
<gvseghbr> Only get the fan ip: sojobo@juju-e441d6-0:~$ juju run --unit elasticsearch/0 'network-get public --ingress-address --format yaml' >> 252.1.240.1
<gvseghbr> the suggestions bdx made, shutting it off, do work, however ...
<gvseghbr> I'm using libjuju to create my models, and unfortunately I cannot set fan-config to an empty string
<gvseghbr> and setting the model-defaults on my controller doesn't help either, they get overwritten
<gvseghbr> @kwmonroe, @bdx, a bit of context: I have a Google Controller, Juju 2.3.5 and I'm trying to deploy James Beedy's ElasticSearch and Kibana Charms.
<bdx> ahh
<bdx> gvseghbr: try this one https://jujucharms.com/u/omnivector/kibana-elasticsearch/
<gvseghbr> Those are the charms I'm using :)
<bdx> but the charm shouldn't matter
<gvseghbr> On JAAS (Juju 2.2.9) and on our VMware cluster (2.3.5, but do not support FAN yet) everything works perfectly
<bdx> ahh its just gce? - sounds like a bug to me
<gvseghbr> I haven't tried AWS yet
<bdx> those charms work great for me on aws and MAAS ... I'm a bit embarrassed to say I haven't a GCE account and haven't tested them there
<bdx> gvseghbr: would you mind filing a bug for this issue ?
<gvseghbr> sure, no problem. Where?
<bdx> https://bugs.launchpad.net/juju
<bdx> thanks
<gvseghbr> you're welcome. Any idea why, on GCE, I cannot fix the fan-config setting in the model-default during bootstrap?
#juju 2018-04-07
<pmatulis_> seems 'juju model-config container-networking-method=local' gives you standard LXD (addressing based on the LXD bridge (e.g. lxdbr0))
#juju 2018-04-08
<wolfmitchell> Whenever I try to use LXC containers in Juju with MAAS, I get this in the debug logs: http://upaste.me/aa1f49586d2b3739d
<wolfmitchell> How would I fix that?
<wolfmitchell> I'm trying to deploy Openstack with the bundle linked in the Openstack docs here: https://docs.openstack.org/charm-deployment-guide/latest/install-openstack-bundle.html
<bdx> wolfmitchell: if you have multiple spaces available on each host, then you have to specify the network bindings
<bdx> not sure if thats what you are hitting or not
<wolfmitchell> What do you mean by multiple spaces? Just getting started with MAAS and Juju so I'm not sure
#juju 2020-03-30
<hpidcock> wallyworld: k8s charms don't have an install hook correct?
<hpidcock> considering dropping the noop upgrade op for the standard deploy op, but instead of firing the "install" hook it fires the "start" hook
<hpidcock> then the caasoperator has a caching downloader
<hpidcock> and we use the deployer as normal inside the caas uniter
<hpidcock> then caas upgrade/install has a post install op that copies files to the pod
<hpidcock> that pod init op is also run on container init
<wallyworld> hpidcock: they do have one now
<wallyworld> it was added just before the sprint
<wallyworld> here's that action enablement PR https://github.com/juju/juju/pull/11374
<wallyworld> we could use the "normal" deployer if we rejig things i suspect
<wallyworld> or we could serialse the deployer and actions etc
<wallyworld> so that we don't unpack a new charm if there's an action running. we may even do that, would need to check
<hpidcock> the resolver is serialised and only runs one op at a time
<pmatulis> how does JUJU_AVAILABILITY_ZONE information, set from MAAS, get propagated to a Juju model? and is this strictly used by the nova-compute charm?
<timClicks> latest progress report is now available: https://discourse.jujucharms.com/t/juju-progress-report-2020-w13/2842
<zeestrat> pmatulis: regarding usage, ceph-mon can use it for crush maps if `customize-failure-domain` is enabled: https://github.com/openstack/charm-ceph-mon/blob/master/config.yaml#L172-L177
<flxfoo> hi all
<timClicks> hi flxfoo
<flxfoo> little question about ~/.local/share/juju/ssh/juju_id_rsa... where does this one comes from? If I create a new user (syste/ and juju) I have this some ssh key... and if I try a juju-ssh or a simple ssh i have a permission denied... I would need to override that key by some generated in ~/.ssh ? I am not sure about the best practice here...
<timClicks> all inter-agent communication is protected by TLS
<timClicks> using a self-signed CA
<timClicks> so, it is created by the juju controller
<hpidcock> timClicks: wouldn't be the TLS cert, probably the ssh key that I think is created when you bootstrap. Not sure.
<flxfoo> sorry I think I am not clear at all :p ... when creating a new user, (unis system and juju) one should ssh-genkey for the system user, juju register the user, import that .ssh/id_rsa.pub key, and replace .local/share/juju/ssh/ with those keys?
<timClicks> hpidcock: good point (I was a bit too fast )
<timClicks> flxfoo: I don't recall exactly what the steps are.. perhaps ask on https://discourse.jujucharms.com?
<jam> achilleasa, when you work out the DEBUG level to set for the dependency engine, it would probably be good to send it to discourse to let others know that it at least exists, and they can come back if they ever want to use it.
<achilleasa> jam: will do
<stickupkid> manadart, whilst I'm doing some integration testing, I fixed my reload spaces-rework https://github.com/juju/juju/pull/11366
<stickupkid> who wants a quick PR that prevents me from swearing a lot https://github.com/juju/juju/pull/11375
<achilleasa> stickupkid: looking
<stickupkid> haha, need to fix the linter one sec
<achilleasa> stickupkid: can you try this on dev? cd provider/openstack; go test -check.f TestGetVolumeEndpointBadURL
<stickupkid> achilleasa, what branch?
<achilleasa> dev/head
<stickupkid> achilleasa, fixed my lint issue
<stickupkid> achilleasa, worked for me
<achilleasa> did you pull + make dep?
<stickupkid> probably not
<achilleasa> on my branch I see a %q in there while the regex tests the unquoted error
<stickupkid> PASS: cinder_test.go:914: cinderVolumeSourceSuite.TestGetVolumeEndpointBadURL	0.000s
<achilleasa> stickupkid: not sure why but I get https://paste.ubuntu.com/p/PknhR9Zh9V/
<achilleasa> stickupkid: getting same error on develop too
<achilleasa> stickupkid: you wouldn't happen to use < go1.14.1 would you?
<achilleasa> gotcha! https://github.com/golang/go/commit/64cfe9fe22113cd6bc05a2c5d0cbe872b1b57860
<achilleasa> jam: I have rebased my relation-departed changes after the relation-created PR merged. It has already been reviewed but let me know if you want to take a quick look before I land it (https://github.com/juju/juju/pull/11356)
<rick_h_> achilleasa:  wallyworld has a ping out to me around https://launchpad.net/bugs/1869275 and a need for an upgrade-step around the app relation work?
<mup> Bug #1869275: [subordinate] main unit did not get subordinate installed <juju:Triaged> <https://launchpad.net/bugs/1869275>
<rick_h_> achilleasa:  if you have a sec can you read that and let me know what you think?
 * rick_h_ is processing email/irc ping backlogs
<achilleasa> rick_h_: reading...
<stickupkid> achilleasa, I use go1.12 for work ;)
<achilleasa> stickupkid: 11375 approved with small req
<stickupkid> achilleasa, nope ;)
<achilleasa> all other tests pass with go1.14 ;-)
<rick_h_> achilleasa:  looks like errors merged?
<achilleasa> rick_h_: did juju/errors need anything special?
<achilleasa> my merge on Friday didn't do anything :D
<rick_h_> achilleasa:  I just checked the settings, I updated the password in case it wasn't up to date
<rick_h_> achilleasa:  and watch the logs to see it go by
<achilleasa> all good then
<achilleasa> hml: still reviewing 11339; it's gonna take a while though
<hml> achilleasa:  itâs not blocking me, iâm storage right now, an independent piece
<achilleasa> rick_h_: looks like we are indeed missing an upgrade step from 2.6 -> 2.7 (https://github.com/juju/juju/blob/2.7/worker/uniter/hook/hook.go#L36 vs https://github.com/juju/juju/blob/2.6/worker/uniter/hook/hook.go#L32)
<achilleasa> I might be able to add a small patch that attempts to recover the application name from the remote which means we won't need an upgrade step
<achilleasa> or I can just add an upgrade step but if that won't ship with 2.7.5 and we won't have a 2.7.6 things might get interesting...
<achilleasa> any preference?
<rick_h_> achilleasa:  ok, on the phone atm. Preference would be the safest path for existing users. We don't/can't set a gateway release where "you have to upgrdae to X before you upgrade to Y"
<achilleasa> rick_h_: I guess the manual workaround is un-relate and then relate?
<achilleasa> rick_h_: so this seems to affect 2.6 -> 2.7 upgrades where a unit's state indicates a pending hook of type RelationChange
<achilleasa> rick_h_: maybe just having an upgrade step should be enough; you still need to run the steps if you go from 2.6 -> 2.8 right?
<pmatulis> how does JUJU_AVAILABILITY_ZONE information, in a MAAS context, get propagated to a Juju model?
<rick_h_> achilleasa:  sorry, off the phone now, processing
<rick_h_> achilleasa:  let's sync up in the morning. You're EOD and I want to read this again. I mean we can add an upgrade step to 2.8 that's fine.
<rick_h_> achilleasa:  but I'm nervous about current steps for existing users. So anyone on 2.7 will hit this and we've got a lot of stuff that's going to be upgaded from 2.6 to 2.7 with prodstack
<rick_h_> achilleasa:  not everything can be unrelated/rerelated
<achilleasa> rick_h_: AFAICT it's upgrade 2.6->2.(6+x) where any of the units have a pending relation{Changed, Departed} hook (both check for non-empty RemoteApplication)
<rick_h_> achilleasa:  oh, so the thought is this is missing within the 2.6 series vs 2.6 to 2.7?
<achilleasa> so it's not everyone but can probably (?) happen with enough units
<rick_h_> achilleasa:  yea... ugh
<achilleasa> that's my understanding
<rick_h_> achilleasa:  ok...thinking. I don't think there's a magic trick to this though...ugh
<achilleasa> so we can add an upgrade step to the 2.7 line
<rick_h_> achilleasa:  right, but but but I'm going to start crying lol
<rick_h_> achilleasa:  please drop your notes into the bug before you EOD and then go enjoy the evening
<achilleasa> well another option would be to offer a juju-unfck tool to attempt and fix the state files
<rick_h_> achilleasa:  :/ not making me feel better lol
<achilleasa> but we probably need the upgrade step anyway
<rick_h_> yea, definitely need that. ...can the upgade step check the hook state before running?
<achilleasa> patch 2.7.0?
<rick_h_> e.g. can we promise we won't hit it?
<rick_h_> achilleasa:  maybe. For tomorrow you can start off 2.7 with the idea of forward port and I'll try to find out tonight about what we're thinking with 2.7.
<achilleasa> ok. will drop my notes in the bug
<rick_h_> I really wish I'd have been strong with the "release what we've got" because we're 5 shas in now...this would be 6...
<achilleasa> rick_h_: added a comment but skipped the proposal to patch 2.7.0 onwards as I am not sure if it's even feasible with snaps and whatnot
<rick_h_> achilleasa:  ok, ty
<babbageclunk> have we introduced a go 1.13 dependency in develop?
<babbageclunk> I'm getting an error building k8s.io/apimachinery/pkg/util/errors
<tlm> babbageclunk: good chance that was me as I started using that package
<tlm> but more than likely it was our upgrade to latest k8's client that triggered it
<babbageclunk> yeah, sounds likely
<babbageclunk> is it a problem?
<tlm> sounds like it might be when we go to make 2.8
<tlm> ?
<babbageclunk> I'm not sure where we are with getting off go 1.10 - might just upgrade to 1.14 locally for now
<tlm> what is the error so I an take a look ?
<babbageclunk> tlm: https://paste.ubuntu.com/p/r2zBVRVjhm/
<babbageclunk> it's weird though - building juju works fine (with go 1.12), this only happens when I try to do an upgrade-controller --build-agent
<tlm> 1.17 kubernetes is built with go 1.13.8
<babbageclunk> hmm, upgrading to 1.14 didn't help :/
<babbageclunk> oh no - I think it's because I was in the juju-restore directory, so it was trying to use modules!
<babbageclunk> sorry
<babbageclunk> that's really annoying
<tlm> ?
<tlm> still raises a good point, we are very lucky  that the upgrade hasn't given us more problems
<babbageclunk> I'm going to try downgrading back to 1.12 and then run the upgrade from outside the juju-restore directory
<tlm> it should fail as they are using the new errors stuff
<babbageclunk> yeah that totally worked fine, somehow
<tlm> magic
 * babbageclunk shrugs!
<tlm> all I can think of is we are not using that code so it's being compiled out
<babbageclunk> tlm: yeah, that might be it
<babbageclunk> a bit weird that just being in a go mod directory (for a different project) is enough to completely change how juju builds though
<tlm> hpidcock: is the plan to get off 1.10 before 2.8 release ?
<tlm> what is your GO111MODULE env set to ?
<hpidcock> tlm: `go env` says empty string, so auto
<hpidcock> the plan is to get 1.14 in snap building at least
<babbageclunk> tlm: yeah it's unset in that shell
<hpidcock> also babbageclunk the github actions stuff builds with 1.10
<hpidcock> so people can't land breaking changes
<babbageclunk> seems like it was a weird interaction between modules and unused deps?
<babbageclunk> it's fine for me now anyway, thanks guys!
#juju 2020-03-31
<wallyworld> hpidcock: pushed up a couple of changes for the run socker and deployment mode stuff, just testing locally. also a makefile fix to get us out of the current build dilema in the least cost way unti; we redo the process
<thumper> if anyone wants to review a lot of deleted code... https://github.com/juju/juju/pull/11377/files
<hpidcock> wallyworld: thanks
<wallyworld> thumper: small PR to fix an annoyance seen in those Solutions QA logs https://github.com/juju/juju/pull/11378
 * thumper looks
<thumper> lgtm
<wallyworld> ta
<wallyworld> kelvinliu: here's a small PR to fix an upgrade step https://github.com/juju/juju/pull/11379
<kelvinliu> wallyworld: looking now
<kelvinliu> lgtm, ty wallyworld
<wallyworld> \o/ ty
<wallyworld> lots of loose threads to tidy up before beta
<kelvinliu> wallyworld: can I get ur 2mins to discuss the new option for storage mode?
<wallyworld> kelvinliu: sure, just give me 5
<kelvinliu> sure
<wallyworld> kelvinliu: standup?
<kelvinliu> yep
<wallyworld> kelvinliu: hpidcock: if you guys could give early feedback on https://github.com/juju/juju/pull/11381 that would be great
<kelvinliu> yep
<tlm[m]> lol was going to tidy up a few things first. If it seems obvious or unsafe I am probably already on it
<elox> Good morning
<achilleasa> stickupkid_: can you take a quick look to this tiny change? https://github.com/juju/names/pull/104
<achilleasa> also cmars, when online can you please take a look at https://github.com/juju/terms-client/pull/23
<stickupkid_> achilleasa, done
<achilleasa> (turns out adding new errors to juju/errors is hard)
<stickupkid_> transient dependencies
<hml> achilleasa: changes made to https://github.com/juju/juju/pull/11339
<hml> achilleasa:  i grabed the card to move facade calls to common
<stickupkid> openstack doesn't clear it's own ports up, well that's annoying
<achilleasa> hml: can I have a green tick? https://github.com/juju/terms-client/pull/24
<hml> achilleasa:  looking
<achilleasa> hml: 11339 approved with minor doc-related comments
<hml> achilleasa:  ty
<hml> achilleasa:  approved
<achilleasa> thanks
<achilleasa> stickupkid and hml: do you see any strange warning if you `juju deploy x; juju destroy model -y default'?
<achilleasa> https://pastebin.canonical.com/p/NRPQMkwTCT/
<achilleasa> (that IP is where lxd binds on my dev box)
<hml> achilleasa:  not on 2.7.4, though iâve noticed some command are really long on develop.  like add-model
<achilleasa> hml: yes, I get the same with add-model
<hml> achilleasa:  not on my local branch either
<stickupkid> achilleasa, I've seen that before
<stickupkid> I believe manadart has spotted that in CI, but unable to reproduce
<stickupkid> we did suspect it was systemd issue, but that was a theory
<achilleasa> stickupkid: hitting it consistently :-(
<hml> achilleasa:  which branch?
<hml> achilleasa:  localhost?
<achilleasa> develop/HEAD, local lxd exposed on eth0 ip
<stickupkid> achilleasa, can you get info from journal etc
<stickupkid> that way we can see if it's systemd theory
<achilleasa> stickupkid: journalctl on the host?
<stickupkid> yeah
<achilleasa> stickupkid: lxd.daemon[529331]: 2020/03/31 17:40:58 http: TLS handshake error from 10.176.227.245:41548: remote error: tls: bad certificate
<stickupkid> there we go, not idea why though
<stickupkid> s/not/no
<rick_h_> achilleasa:  got the merge to go through so think we're good now
<rick_h_> stickupkid:  achilleasa when do you time swap? (and why are you still around today? :p )
<stickupkid> rick_h_, last weekend
<hml> achilleasa:  what kinda of comments on ErrNoSavedState?  it seems self explainitory to me
<achilleasa> hml: usually it's something along the lines of 'ErrNoSavedState is returned by X when Y happens'. Just mentioned it because there is a linter (we don't use ATM) that complains about missing docs for exported types
<josephillips> hey
<josephillips> question i perform a commit for add a functionatily on openstack swift-proxy charm
<josephillips> how long take that someone verified the commit?
<rick_h_> josephillips:  that depends on the folks around/etc. beisner might be able to give you a better answer more official-like
<josephillips> ok and another question i want to commit another change
<josephillips> to support another funcionatily on the same charm
<josephillips> i have to wait until this commit is accepted or i can perform a second commit
<josephillips> that make me thing another question
<josephillips> i have to clone the master repo again to perform the new one or i can work with my last clone and changes?
<rick_h_> josephillips:  well if the changes are independent then I'd expect you could create two pull requests no problem
<rick_h_> josephillips:  if they're dependent on each other you can queue up two pull requests, but the one will have to land/rebase before the other goes through
<josephillips> no are not dependent they just add new funcionatily to configure new middlewares
<josephillips> on swift-proxy
<rick_h_> ok
<hml> achilleasa: rgr
<babbageclunk> wallyworld: do you think we should restrict acceptable downgrades to max of one minor version? I guess one major in the case of 3.0 -> 2.9 (or whatever)?
<wallyworld> babbageclunk: i don't think there's any reason we need to?
<babbageclunk> (Although that's difficult without knowing what the maximum minor version of the prev major was)
<babbageclunk> wallyworld: ok, that's much simpler obvs - I think I'm just getting the jibblies from ripping out this checking code.
<wallyworld> so long as the db matches the agent version?
<wallyworld> i guess there's the possibility of local file incompatibility, eg uniter state file
<wallyworld> that's one thing we've just ignored
<babbageclunk> ugh
<babbageclunk> I'd thought about config file inconsistency but not state file
<babbageclunk> Is the state file part of the stuff being moved into the db? Or is that just charm state?
<wallyworld> i would hope everything
<babbageclunk> also reference to https://bugs.launchpad.net/juju-core/+bug/1299802 in the code - I don't think this is still a problem because everything looks at the model version rather than the units looking to the machine to work out what version they should be. Does that seem right?
<mup> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails <juju-core:Fix Released by jameinel> <juju-core 1.18:Fix Released by jameinel> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1299802>
<wallyworld> will read that after call
<babbageclunk> wallyworld: ok, that would remove the problem in the future, although it doesn't help for the existing versions
<babbageclunk> ok, sorry!
<babbageclunk> hey hml, are we right in thinking that the unit-state is being moved into the db as well as the charm state?
<hml> babbageclunk: yes.. uniter internal state, storage relations metrics
<hml> babbageclunk: only bundles  deployer will be left in the state dirâ¦ the can be easiler gotten
<hml> babbageclunk: but itâs a work in progress right nowâ¦ not everything is there
<hml> or moved
<babbageclunk> hml: awesome - thanks!
<pmatulis> is there something unstable about ~containers namespace? i'm also wondering whether failed attempts to use the stable/promulgated namespace should leave a hint to the user that another namespace contains the charm in question
<wallyworld> babbageclunk: unit state file compatability would still be an issue i think on downgrades, but is negated by that stuff moving to the controller as hopefully a structured doc that is then served via an api and hence compatibile versions can be served
<babbageclunk> wallyworld: well, if it's coming from the db then it would be reset along with the restore, right? Once the agents downgrade themselves then the state would be the right format.
<wallyworld> that is true. i was thinkin also that the api would serve a version of the data consistent with the api version, but you are right we get that by default with the db version being downgraded also
<wallyworld> rick_h_: wadda ya reckon about creating a 2.9 milestone to park bugs that we know we want to do next cycle?
<rick_h_> wallyworld:  wfm
<wallyworld> thumper: i've always wondered why we don't enforce relation limits, did we want to target at a 2.8.1? bug 1869840
<mup> Bug #1869840: Enforce limit: specified in relation metadata <canonical-is> <juju:Triaged> <https://launchpad.net/bugs/1869840>
<thumper> is it something we could do post beta 1 before rc?
<babbageclunk> wallyworld: making the same change in caasupgrader - k8s isn't really handled in juju-restore at the moment, but when it is it'll be the same situation, right?
<wallyworld> thumper: we could, but if code freeze is friday.....
<thumper> freeze for features
<wallyworld> it is potentially a non-trivial change if there's corner cases
<thumper> it could just be validation in the api-sever call for relate
<thumper> where if the limit is hit, we just reject the relate call
<thumper> doesn't feel like a lot of corner cases
<thumper> what we don't have
<wallyworld> it could be but i am always wary
<thumper> is "my charm only works with one of mysql or pgsql"
<wallyworld> this late in the peice
<thumper> trying to define that could get very messy
<wallyworld> thumper: also bug 1869795, i can't recall why we send --verbose to stderr
<mup> Bug #1869795: --verbose output from juju CLI is written to stderr <juju:New> <https://launchpad.net/bugs/1869795>
<thumper> I saw that too...
<wallyworld> i changed the title as it is all juju cli
<thumper> I had thought that we agreed to send info/verbose to stdout except if --format yaml/json
<wallyworld> yeah, i thought so too, just wanted to double check as it is a wide reaching hcange
<thumper> we could quickly see where we actually call ctx.Infof and ctx.Verbosef
<thumper> the problem is the machine readable format bits
<wallyworld> yup
<wallyworld> babbageclunk: k8s upgrades a slightly different in how they're triggered, i'd need to look specifically at the code etc
<babbageclunk> wallyworld: Ok - presumably the agent version being different will still trigger this code though right? I'll try chasing it through.
<wallyworld> babbageclunk: the difference is that the agent does not shut itself down and restart,it's a whole new docker image
<babbageclunk> ah right
<wallyworld> thumper: i want to do a burn down list of bugs for 2.8-beta1. i've created 2.8-rc1, 2.8.1, and 2.9-beta1 milestones. i'd like us to shuffle bugs around to reflect reality and allow folks to pick off bugs to fix once we hit feature freeze
<babbageclunk> wallyworld: it looks like essentially the same situation (from my not very familiar reading) - that's the place that decides whether this upgrade is sensible (and unlocks downstream workers), the API accepts the version change and updates the image in k8s to the requested version
<wallyworld> babbageclunk: you are most likely right, i need to go look at the code. i just wanted to be sure that any k8s differences were accounted for etc
<babbageclunk> wallyworld: cool cool - I'll make the change for now, we can discuss in stdup/review, thanks!
<hpidcock> wallyworld: feeling it might soon be time to move ProviderID for Deployments/Daemonsets to pod name, not pod uuid
<wallyworld> hpidcock: given pod name is always regenerated as a unique value in those cases, it would work to do that. is the rationale to make it easier to match things up?
<hpidcock> wallyworld: the rationale is that UUIDs for now, and probably for a long time are not index in etcd. So you can't just get on UUID, must list all pods and filter on uuid
<hpidcock> wallyworld: with k8s usage increasing, and us better supporting non-statefulset deployments, probably a good time to do it
<wallyworld> ah that is true, and unfortumate
<hpidcock> I'm happy to do it as a driveby
<wallyworld> let's discuss in standup
<hpidcock> sure thing
<babbageclunk> hpidcock: that's weird - why don't they index on uuid? I'd have expected it to be way cheaper than indexing on a string?
<hpidcock> babbageclunk: because k8s objects use namespace + name as their key
<babbageclunk> ok - so the uuid is just some other field and you can't query by it directly?
<hpidcock> correct, used to determine if two objects are different when you delete and recreate an object with the same
<babbageclunk> ah, right - thanks!
#juju 2020-04-01
<babbageclunk> wallyworld: https://github.com/juju/juju/pull/11384
<wallyworld> ok
<babbageclunk> way more in the description and QA steps than the code change!
<wallyworld> good :-)
<wallyworld> babbageclunk: what happens if you got to juju/description and try and run the tests?
<babbageclunk> checking
<babbageclunk> um, fails - is that me?
<babbageclunk> (This is on the tip of master)
<wallyworld> it fails for me due to registering a http protocol twice
<wallyworld> nfi how stuff got landed
<babbageclunk> yeah, seems pretty weird
<wallyworld> babbageclunk: =1 on review with a request for a change
<babbageclunk> go version diffs?
<babbageclunk> ok, thanks!
<babbageclunk> wallyworld: for me the juju/description failure is missing quotes around a time value
<babbageclunk> which might be a yaml version diff
<wallyworld> for me it's a godeps issue
<wallyworld> the upstream all have incompatible deps
<wallyworld> it's a mess
<babbageclunk> ugh
<wallyworld> so you ned to godeps -u dependencies.tsv
<wallyworld> to get the deps as specified
<wallyworld> then stuff fails
<wallyworld> and trying to fix one breaks something else
<wallyworld> thanks for looking though
<babbageclunk> ok now the tests pass for me
<babbageclunk> (I'd forgotten how to run godeps!)
<wallyworld> hmmm
<wallyworld> i'll try again after resetting everything
<babbageclunk> that's the only way to be sure
<babbageclunk> (bar nuking from orbit)
<wallyworld> nup, still get the protocol already registered :-( must be a transitive dep somewhere
<wallyworld> might be go 1.14
<babbageclunk> no, just tried with go 1.14 - maybe something with gomodules?
<wallyworld> godeps should write out all the upstream repos to the specified sha, no gomodules involved. i've updated deps to get past that and now have juju/clock vs utls/clock compile errors, so will just need to keep at it
<wallyworld> babbageclunk: maybe past you EOD, if so let me know... here's a juju/description PR, works with juju state tests with operations added. jenkins acting up pulling repos so still getting merge check to pass
<wallyworld> https://github.com/juju/description/pull/74
<babbageclunk> wallyworld: nope - looking now
<tlm> has the ACME code in juju ever worked ?
<wallyworld> i think so, there was a bug filed recently that hpidcock fixed
<tlm> ah yep I see it now
<tlm> missed a line and was scratching my head
<hpidcock> tlm: wallyworld: I only updated x/crypto to support acme v2. Not sure if the whole thing works end to end. I do remember testing to see if the error happened anymore and didn't see it when I setup a domain etc
<hpidcock> and a controller using that domain
<tlm> yeah not it's fine hpidcock, I would kill for go 1.14 at the moment
<wallyworld> "soon"
<wallyworld> :-)
<wallyworld> next week with luck
<tlm> there is a helper function that would save me an hour of work
<tlm> https://golang.org/src/crypto/tls/common.go?s=34175:34244#L911
<wallyworld> cut and paste? :-)
<babbageclunk> +1
<tlm> yeah could do
<hpidcock> tlm: hah yeah.. we ain't vendoring that for you
<tlm> but where do I dump the cut and paste
<wallyworld> maybe with the worker that uses it (or whatever it is) with a TODO to remove next week
<hpidcock> Yeah I'd rather you just todo it and come back to it next week like wallyworld suggests
<babbageclunk> Or a test that fails in go 1.14!
<tlm> checking out how they did it in 1.10 and see if there is a quick win with that first
<wallyworld> thamks babbageclunk
<babbageclunk> wallyworld: approved - it's a pity there's so much boilerplate to add a new entity there
<tlm> ok going for the cut and paste
<tlm> sorry juju
<babbageclunk> I feel like we could do with some codegen
<wallyworld> yeah
<kelvinliu> wallyworld: +1 plz a small PR to disable some CMDs for daemonset  https://github.com/juju/juju/pull/11386
<wallyworld> looking
<kelvinliu> ty
<wallyworld> kelvinliu: looks nice. ty. here's a small one also https://github.com/juju/juju/pull/11387
<kelvinliu> ty looking now
<pmatulis> can the value of JUJU_AVAILABILITY_ZONE be inspected somehow?
<wallyworld> i think you can use juju run and look at the env vars in a hook context that way
<kelvinliu> wallyworld: lgtm ty
<wallyworld> tyvm
<wallyworld> kelvinliu: can you plese comment on https://discourse.juju.is/t/k8s-spec-v3-changes/2698/2
<kelvinliu> sure
<elox> Good morning
<wallyworld> o/
<hpidcock> wallyworld: this bug fix is going to take at least another day. Hopefully I have a pr up this afternoon for the implementation so you can sanity check it, but the unit tests are going to be fun.
<wallyworld> yeah, i bet
<wallyworld> manadart: what's O7k?
<manadart> wallyworld: OpenStack
<wallyworld> ah, derp
<wallyworld> all this fance txt speak
<wallyworld> *fancy
 * manadart gestures with pipe. "We we was comin' up, we talked proper like."
<wallyworld> when i was a boy, people did speak properly with grammer rules and punctuation all followed
<stickupkid> manadart, got a second?
<manadart> stickupkid: Yeah.
<stickupkid> manadart, https://github.com/juju/juju/pull/11388
<manadart> stickupkid: Yup.
<elox> I'm trying to deploy a centos charm in vsphere. But I have no idea as how to get a working image in there and how to get vsphere to understand "--series centos7". Anyone that has a clue? The same is true for AWS https://discourse.juju.is/t/deploying-centos7-in-aws/2839/4
<manadart> stickupkid: HO?
<stickupkid> manadart, of course
<hml> manadart:  updated the pr with caas qa test
<manadart> hml: Ack.
<stickupkid> manadart, so I have an issue with trying to pass a new type of header func through the client, in that it gets very messy and by messy, each goose.Client holds a http.Client and we create lots of different types of goose.Clients.
<stickupkid> manadart, we then end up having lots of different ways to construct this goose.Client and non of them seem right
<stickupkid> manadart, it feels like there should be a factory to get me a client and depending on my parameters
<manadart> stickupkid: Yes.
<stickupkid> manadart, but nova and neutron share the same http client between them both
<jam> guild https://github.com/juju/juju/pull/11389 does now have some tests of both the CLI parsing and putting the args into the right spot, and more direct unit tests of how args get serialized.
<jam> feedback appreciated.
<manadart> hml: Getting this on the integration test. https://pastebin.ubuntu.com/p/pq6m8kfVhy/
<hml> manadart: huh, iâll take a look.
<stickupkid> manadart, can I grab you before you EOD quickly?
<manadart> stickupkid: I'm in Daily.
<hml> manadart: iâll have to put up a new pr to fix the integration test.  itâll run if you replace `_` with `-`
<stickupkid> hml, manadart that because juju has that restriction
<hml> stickupkid: np, it just looks like i replaced only one.  not sure where that happened
<stickupkid> yeah, :)
<achilleasa> anyone wants to review https://github.com/juju/juju/pull/11390?
<rick_h_> achilleasa:  can you please make sure that you ping an email to thumper to peek at it as well
<achilleasa> rick_h_: I have already @commented him in the PR
<achilleasa> rick_h_: btw, if you have some time can you try to poke any holes in the implementation?
<rick_h_> achilleasa:  awesome ty
<rick_h_> achilleasa:  will look ty
<achilleasa> hml: left a few comments on 11376; overall it looks good but I would recommend getting a +1 from someone who has worked with storage before
<hml> quick pr review anyone?  https://github.com/juju/juju/pull/11391
<rick_h_> hml:  +1
<hml> rick_h_: ty
<hml> another quick on :-) https://github.com/juju/juju/pull/11392
<hatch> I'm having issues running the gui simplestreams tests....it requires the values in export_test which aren't loaded when running the test file directly `go test environs/gui/simplestreams_test.go`
<tlm> mongo pem handling doesn't support headers :(
#juju 2020-04-02
<tlm[m]> FYI issue is that version of OpenSSL doesnât support ecdsa keys, the encoding is fine.
<thumper> wallyworld: does the caas controller use the machine agent engine?
<thumper> I think it does, just want clarification
<tlm[m]> I think so
<thumper> thanks...
<thumper> I realised that my approach isn't working, so I need to back up and try again
 * thumper is looking to add dependency engine metrics for worker restart counts
<wallyworld> thumper: yeah, it does with a few tweaks
<wallyworld> there's a separate caas model set of workers
<wallyworld> and separate caas application agent (vs unit agent)
 * thumper nods
<thumper> ta
<thumper> I still need to backup though
<thumper> yay metrics
<wallyworld> thumper: i don't get why we need remote-application since it can be inferred from the unit name
<wallyworld> maybe babbageclunk knows?
<thumper> yeah...
<thumper> it is there for application relation changes
<thumper> I don't think it should be needed for non-application relation changes
<thumper> but the validation is there now
<thumper> something to be cleaned up maybe?
<thumper> but we need to provide people with the way to unblock
<wallyworld> upgrading should not even result in any app relation changes, right? since the charms don't have that yet
<thumper> right
<thumper> but if someone upgrades to 2.7.5, they need a way to unblock themselves
<wallyworld> hence it seems wrong to expect that entry when it's not even used in the context of the hook
<wallyworld> yes, workaround needed, but also agree we should fix
<wallyworld> another 2.7.6 fix i'd say
<wallyworld> well *the* 2.7.6 fix
<thumper> wallyworld: yeah, I think achilleasa is going to look next week
 * thumper EODs
<wallyworld> ttyl
<wallyworld> hpidcock: i think you fix bug 1849660 right?
<mup> Bug #1849660: AWS A1 instances are not available via juju in eu-central-1 <juju:Triaged> <juju 2.8:Triaged> <https://launchpad.net/bugs/1849660>
<hpidcock> wallyworld: might need to run the AWS update scripts
<wallyworld> i thought we had already? i thought the bug was fixed but just not marked as fix committed
<hpidcock> hmmm
<hpidcock> oh yeah
<hpidcock> should be fixed'
<wallyworld> ta, will makrk as such
<hpidcock> wallyworld: if you feel like a PR readthrough of the charm upgrade stuff
<hpidcock> https://github.com/juju/juju/pull/11395
<wallyworld> ok
<hpidcock> still working through it, needs some cleanup possibly
<hpidcock> but it works
<hpidcock> "works"
<wallyworld> hpidcock: wanna rebase and resolve conflicts?
<hpidcock> wallyworld: one momento, having lunch
<wallyworld> all good, i've got plenty to do
<achilleasa> wallyworld: I will work on that next week. Should be a simple upgrade step (read unit name, mangle it to an app name and write it back to the state file). I may be able to cobble together a sed script to use as a manual workaround for stuck units until the fix lands
<achilleasa> can I get a CR on https://github.com/juju/juju/pull/11390?
<achilleasa> whoops... ^ needs rebasing to resolve conflics
<stickupkid> I don't get this, I don't know what it gives you? https://github.com/go-goose/goose/blob/v2/http/client.go#L111-L112
<stickupkid> if you want to pool http clients, the there are better ways
<stickupkid> manadart, https://github.com/go-goose/goose/pull/85
<stickupkid> just updated the description
<manadart> stickupkid: OK.
<achilleasa> I have resolved the conflicts on 11390. Can I get a CR on it? (if you review it make sure you run the QA steps for both actions/hooks)
<wallyworld> achilleasa: i don't understand why we even need that yaml attribute since the app name can always be derived from the unit name, and if it is used to signal the hook is firing as a result of an app data change ,that's fine, but it shouldn't be needed otherwise, and in this case, it definitely doesn't seem valid to error because the system is being upgraded from one where there's no app relation data
<wallyworld> so perhaps there's a bigger problem to fix
<achilleasa> wallyworld: my guess is that it's a sanity check introduced as part of the application databag work
<wallyworld> still doesn't seem right ti me
<achilleasa> wallyworld: AFAICT from the validation code, for RelationChanged it seems like you are allowed to have an empty unit but the application must always be populated. Maybe it's there to signal something on the application level?
<wallyworld> interesting. not being familiar with the code, my thought was that one of app/unit must be optional, it seems unit is the optional one
<achilleasa> wallyworld: though for RelationJoined/Departed both are required
<wallyworld> that seems weird since if you know the unit, you know the app
<wallyworld> might need to ask xtian/john
<manadart> stickupkid: Do we need the Options defs in both http/client.go and client/client.go?
<stickupkid> manadart, well I'm unsure if people are using http/client directly. If so, we do need to do that to ensure backwards compatibility. Otherwise we have to move to v3 of goose
<stickupkid> manadart, if we're sure then I probably just set it in the constructor, but that means a signature change etc
<manadart> stickupkid: So can't we use the http/client ones in client/client?
<manadart> We already import it...
<stickupkid> manadart, it would seem weird that client/client constructor takes http/client ones no?
<stickupkid> manadart, what if client/client wants it's own options?
<manadart> stickupkid: I can live with it.
<stickupkid> manadart, i'm not a fan by the way, I just wanted to be safer
<stickupkid> manadart, my prefered method is make a factory
<jam> guild, has anyone felt that juju 2.8 takes *much* longer to link than 2.7 ?
<hml> jam, not that iâve noticed.  but add-model seems to take a longer time than iâd expect.
<jam> time go test -check.v in cmd/juju/commands takes around 30s before it gets to the 5s test.
<jam> which the test itself is stupid slow, but 6x slower to compile it.
<hml> achilleasa:  resolved comments in https://github.com/juju/juju/pull/11376 and retested upgrade
<stickupkid> jam, I'll keep my eye out, I might use my old computer as my new one is stupid fast
<jam> stickupkid, so I also got a new machine this year, dropped my compile times by something like 6x (yay massive cores).
<jam> git co 2.7; dep ensure -v -vendor-only; time go install github.com/juju/juju/... 1m1s
<jam> back to 2.8, its 57s, so maybe I'm just crazy
<jam> stickupkid, so I'm not entirely crazy 'time go install' was the same, but
<jam> cd cmd/juju/commands; time go test -check.v -check.f dontrunanytests
<jam> is 36s vs 51s
<stickupkid> git co 2.7 and install took 30s for me.
<jam> anyway, 30s to spin up a test suite takes it way outside the 'productive loop' for me.
<stickupkid> 2.8 took 21s
<jam> very nice
<stickupkid> i'll see what the cmd/juju/commands one is
<stickupkid> 9s for 2.8
<stickupkid> roughly the same for 2.7
<jam> stickupkid, what go version are you running?
<stickupkid> 1.13.7
<stickupkid> I should move it back to 1.12
<jam> I'm on 1.13.9 (whatever from snaps),
<stickupkid> not on a snap
<stickupkid> it doesn't play well with my editor
<jam> stickupkid, have you ever seen 'dep check' say that Gopkg.lock doesn't match?
<jam> stickupkid, I hit a weird bug where static_analysis failed on my machine, but if I push the PR updating Gopkg.lock it says it doesn't match on the bot
<jam> stickupkid, but I don't know how to clear out whatever cache dep is using that has a bad version in it.
<stickupkid> jam, yeah, but not for a long time, me achilleasa ran into it. Note: you can't remake the Gopkg.lock from scratch, you need a seeded version
<stickupkid> jam, nuke your vendor folder?
<jam> stickupkid, yeah, I'm aware you can't reset Gopkg.lock when I was figuring out dep ensure in the beginning.
<jam> I deleted the dir from vendor, but not the whole dir, maybe I'll try that
<jam> stickupkid, I noticed static analysis complaining about a bunch of stuff I didn't touch. Was the test added recently?
<stickupkid> jam, nope, got a link
<jam> stickupkid, https://jenkins.juju.canonical.com/job/github-static-analysis-go-juju/2149/console
<stickupkid> jam, it doesn't like this file for some reason https://github.com/juju/juju/pull/11389/files#diff-6e09331bad8b6f463aba28902512a50d
<stickupkid> jam, I suspect the github one is using a different version than local, i.e. it's probably because it's 1.12 v 1.13
<jam> stickupkid, so client_test I fixed, it was that I had an import in the wrong section
<jam> but it was complaining about more than that.
<stickupkid> yeah, I need to clean up the grep output, it's because generated files really message that output up
<jam> stickupkid, https://pastebin.canonical.com/p/Sb8MzPvn4D/
<jam> I can fix client_test.go which I did touch, it was the leadership upgradeseries, mock_statetracker etc
<jam> that I didn't touch
<jam> that made me confused
<stickupkid> jam, yeah, ignore them
<jam> stickupkid, also, it doesn't say *what* the issue is, just "there was an issue"
<jam> I had to figure out (a) it was go-import and (b) that it was a problem with client_test.go
<stickupkid> jam, agreed
<jam> stickupkid, also it mentions output.tar.gz but I couldn't find that as part of Jenkins anywhere
<stickupkid> jam, I'm thinking that the output would be better served in s3, jenkins just isn't reliable for us around this
<bdx> hello
<bdx> I wanted to bring up https://bugs.launchpad.net/juju/+bug/1849916
<mup> Bug #1849916: [jaas] add-model doesn't respect region <juju:Incomplete> <https://launchpad.net/bugs/1849916>
<bdx> this bug is still impacting myself and others, the same way that it was on 2019-10-26
<bdx> it's pretty critical for us, because it blocks us from using/creating models on jaas
<bdx> I'll be around to help give some info and/or diagnoses on this if need be
<bdx> if someone who knows these waters might be kind enough to lend hand at looking into this further it would be greatly appreciated
<bdx> thanks!
<achilleasa> hml: there is an error in one of the upgrade tests in 11376
<hml> achilleasa:  iâll take a look
<achilleasa> other than that I think it's ready to land. Do you want me to approve it now before my EOD so you can land it once the errors are fixed?
<hml> achilleasa:  yes pleaseâ¦  if thereâs a big change to fix the test, iâll have someone review that piece from NZ/AU
<hatch> bdx I'll send this around to some folks to see if they have any ideas as it's outside of my wheelhouse
<hml> achilleasa:  it was an easy fix, had to update the args for a call in the test which changed signature.
<hml> achilleasa:  verifying in github jobs, then squash and merge
<hml> ty
<bdx> hatch: thanks!
<wallyworld> thumper[m]: https://github.com/juju/juju/pull/11396
<wallyworld> thumper: you gonna look at my pr? it will make you happy
<babbageclunk> can someone take a look at my juju-restore pr to fix HA node counting? https://github.com/juju/juju-restore/pull/13
<thumper> ok
<thumper> wallyworld: which PR?
<wallyworld> thumper: it's posted above
<wallyworld> https://github.com/juju/juju/pull/11396
<thumper> wallyworld: I was probably not here
<wallyworld> asked via github to :-)
<wallyworld> *too
<thumper> wallyworld: yep, will get to it after my call with timClicks
<thumper> wallyworld: 71 files? what have I gotten myself into?
<wallyworld> thumper: it's mechanical :-) and you will lovethe result
<thumper> I'm reviewing now
<thumper> wallyworld: approved with one change requested
<wallyworld> ty will look after meeting
<thumper> babbageclunk: approved with one change requested too
 * thumper goes to get lunch now
<babbageclunk> thumper: awesome thanks!
#juju 2020-04-03
<hpidcock> wallyworld: I added https://bugs.launchpad.net/juju/+bug/1870458 for 2.9-beta1, something we can't forget about but isn't too urgent.
<mup> Bug #1870458: extend k8s remote hook context with sh and python <juju:Triaged> <https://launchpad.net/bugs/1870458>
<wallyworld> ta
<hpidcock> also added the k8s application cleanup bug to 2.8-beta1
<wallyworld> excellent
<wallyworld> kelvinliu: small one https://github.com/juju/juju/pull/11398
<kelvinliu> looking
<kelvinliu> nice! wallyworld
<wallyworld> it was manadart's excellent suggestion
<kelvinliu> initially, k8s controller supposed to only support k8s models but now it's not the case anymore.
<wallyworld> kelvinliu: correct. but even for k8s models, there could be another cluster added as a separate cloud
<wallyworld> babbageclunk: any chance to look at the add-model bug?
<kelvinliu> that's right
<babbageclunk> wallyworld: I'll look at it now
<wallyworld> babbageclunk: whereever you get to let me know so i can progress it. thanks for helping!
<wallyworld> hpidcock: did you raise a bug or create a card for the remote exec path issue?
<hpidcock> ahh will do
<hpidcock> thanks
<wallyworld> ta, add to 2.8-beta1 milestone please
<wallyworld> manadart: or stickupkid__ or achilleasa: a vert small PR to fix a long standing, subtle add-model bug https://github.com/juju/juju/pull/11399
<manadart> wallyworld: That's approved.
<wallyworld> manadart: awesome, ty
<stickupkid> manadart, https://github.com/juju/juju/pull/11388 <- it wasn't as easy as I first thought, see
<stickupkid> manadart, agreed, I'll fix it up
<stickupkid> spent most of my time fixing the client, will go back to the original problem space
<wallyworld> achilleasa: did you consider max-unitagent-state-size instead of max-uniter-state-size? unitagent is what end users think about. uniter is of little meaning outside juju dev and is more of an implementation artefact. compare to how we present status - Agent Status, Workload Status etc
<wallyworld> max-agent-state-size even
<wallyworld> since we want to combine the agents eventually
<achilleasa> wallyworld: the uniter-state-size was added for symmetry and is probably something operators never have to worry about or tweak (although you can set it to 0 as an escape hatch if something goes wrong). It is there more as a sanity check for ensuring that the uniter does not suddenly try to persist an odd amount of data
<achilleasa> wallyworld: happy to rename if you think it's ambiguous
<wallyworld> not some muh ambiguous but not how we expose that particular juju component elsewhere. everywhere else we talk externally about the "unit agent"
<wallyworld> the uniter is just what we chose to call the package implementing the main aspect of the unit agent
<wallyworld> it has no meaning to users
<wallyworld> and since we want to combine unit agent and machine agent to just a single agent, just "agent" makes sense
<achilleasa> wallyworld: makes sense. I will open a small PR to rename to max-agent-state-size
<wallyworld> thank you :-) sorry for the late input
<achilleasa> wallyworld: no prob. Small renames are no biggie as opposed to omg-you-implemented-this-wrong! :D
<wallyworld> that i have no opinion on :-) haven't read the code in detail, but i'm sure you did a greta job :-)
<wallyworld> greta lol. *great
<achilleasa> manadart: or stickupkid small PR to rename the config option for the max uniter state size: https://github.com/juju/juju/pull/11401 ^
<stickupkid> manadart, I updated and added some tests
<manadart> stickupkid: https://github.com/juju/juju/pull/11402. Was deep in this one, will grab a bite and review yours.
<stickupkid> manadart, I had to rebase my changes anyway
<achilleasa> hml: any tips for testing the meterstatus worker? IIRC you had something metrics-related in the QA steps for one of your PRs
<hml> achilleasa:  i would have to look at the QA steps in that pr.  :-)
<achilleasa> hml: asking bec I can't find it :D
<hml> achilleasa:  sure, let me look
<hml> achilleasa:  iâm thinking itâs broken with the stdout change:   juju collect-metrics keystone/0
<hml> failed to collect metrics: could not read stdout
<SpecialK|Canon> Hello! If I have Charm source on Launchpad that I'm actively developing, what's the easiest way for me to be able to use it in JaaS / jujucharms.com please?
<hml> achilleasa:  here is the pr https://github.com/juju/juju/pull/11318
<SpecialK|Canon> Or do I need to get it into the charmstore as a prerequisite?
<hml> achilleasa:  got out output from metrics âall like i should have
<hml> achilleasa:  iâm stillâ¦ need to deploy a specific charm first
<achilleasa> hml: https://paste.ubuntu.com/p/xJC9FnmjkX/ seems like it's working :D
<achilleasa> now I need to test what happens when you move from 2.6 -> 2.7
<achilleasa> er... 2.7 yo 2.8
<hml> achilleasa:  iâd leave it for a bitâ¦ gather data then due the upgrade
<achilleasa> hml: seems like it fires immediately after the hook comes online. So I will bootstrap 2.7, verify the state file is there and then upgrade to verify the state got migrated
<hml> achilleasa:  rgr
<manadart> achilleasa, hml, stickupkid: I messed the LXD thing up: Here's the fix: https://github.com/juju/juju/pull/11404
<manadart> If anyone approves it, please go ahead and merge.
<stickupkid> manadart, nps, bridge vs bridged :)
<achilleasa> hml: the meter-status state PR is ready for review; please have a look and I will address any feedback on Monday: https://github.com/juju/juju/pull/11405
<hml> achilleasa:  sure.  might need a break from the UT in relations.  ha!
<achilleasa> I also have a separate PR for renaming SetStateArg.State -> SetStateArg.CharmState (and everywhere we use this; also a bit of naming cleanup in the uniter context to avoid confusion as to what "state" we are caching). I will push this on Monday though
<hml> achilleasa:  ack
 * achilleasa waves
