#juju 2012-03-12
<SpamapS> negronjl: you ready for tomorrow?
<antono> hi all. testing juju with local provider
<antono> for some reason no success. it cannot start all lxc containers for very long time
<antono> so basically machine     state: not-started during 10 minutes
<antono>  
<antono> yesterday i got it running somehow... but i was away for a long time
<yolanda> hi, good afternoon
<yolanda> i'm trying to create an openstack instance from juju, but the instance gives me error
<yolanda> anyone can guide me on how correctly setup the environments.yaml for openstack? i should be missing something
<james_w> how's the charm store coming along?
<bbcmicrocomputer> hi, a quick Q.. when writing Charms, is it by design that Juju executes hooks with a umask of 0077?
<jcastro> bbcmicrocomputer, out of curiosity, what are you looking to charm?
<jamespage> jcastro, I hoping to persuade him to charm hive :-)
<jcastro> heh
<jamespage> jcastro, are you helping with the charm school today?
<jcastro> no, that's Clint and Juan
<jcastro> it's a meatspace one
<bbcmicrocomputer> jcastro: yeah, I'd like to do a Hive charm
<jcastro> oh nice
<bbcmicrocomputer> jcastro: atm, I'm just playing with jamespage's existing Hadoop ones
<bbcmicrocomputer> jcastro, jamespage: would love to also create a Solr charm, so we could have a search server coupled to a MySQL or PostgreSQL instance
<bbcmicrocomputer> jcastro, jamespage: be quite cool if you could just have indexing automatically set-up via the relations
<jcastro> https://bugs.launchpad.net/charms/+bug/828367
<_mup_> Bug #828367: Charm Needed: SolrCloud <Juju Charms Collection:New> < https://launchpad.net/bugs/828367 >
<jcastro> and https://bugs.launchpad.net/charms/+bug/808255
<_mup_> Bug #808255: Charm Needed: Solandra <Juju Charms Collection:New> < https://launchpad.net/bugs/808255 >
<jcastro> those would be quite cool to see
<bbcmicrocomputer> jcastro: ah cool, well would love to have a go at tackling them, schedule permitting
<jcastro> awesome
<bbcmicrocomputer> jcastro: any answer to the previous Q about why juju executes hooks with a umask of 0077?  Is it just to be *safe*?
<jcastro> not sure
<bbcmicrocomputer> jcastro: ah ok
<jcastro> I can however ping bcsaller, fwereade_, hazmat, and niemeyer for you. :)
<bbcmicrocomputer> jcastro: sure, thanks
<fwereade_> bbcmicrocomputer, I think that comes from twistd defaults; I don;t know that we made an explicit decision ourselves
<fwereade_> bbcmicrocomputer, but perhaps someone who joined before me will be able to contradict that
<bbcmicrocomputer> fwereade_: ok, thanks
<andrewsmedina> hi
<andrewsmedina> there's a way to define a custom image in a deploy?
<jcastro> like an AMI?
<andrewsmedina> jcastro: yes
<jcastro> http://askubuntu.com/questions/84333/how-do-i-use-a-specific-ami-for-juju-instances
<jcastro> you want default-image-id
<fwereade_> andrewsmedina, I *think* that you can still change default-image-id in environments.yaml before you deploy; but I recommend you don't come to depend on that because it'll be going away soon
<fwereade_> andrewsmedina, what's your use case?
<andrewsmedina> fwereade_: I want in some cases to define a custom ami in a deploy
<andrewsmedina> jcastro: I want define at a deploy time
<fwereade_> andrewsmedina, what are the important characteristics of the different ami?
<jcastro> i've always wanted to do that too
<andrewsmedina> fwereade_: I want to use juju with golden images
<andrewsmedina> This would be possible with "--contraints"
<andrewsmedina> like
<andrewsmedina> juju deploy local:mysql --constraints 'image-id: ami-0000002d'
<fwereade_> andrewsmedina, as I recall it was agreed that allowing specific images with constraints was a bad idea
<andrewsmedina> fwereade_: why?
<fwereade_> andrewsmedina, in particular it's an end-run around our attempts to match the ubuntu series tothe charm that's being deployed
<andrewsmedina> fwereade_: but with this juju only works on ubuntu
<fwereade_> andrewsmedina, but that is clearly a sensible thing to want to do; can I suggest starting a discussion on the lists? I suspect it'll be the best way to get properly considered discussion
<fwereade_> andrewsmedina, that is a restriction that I think we're... er... somewhere between "resigned to" and "comfortable with" for now
<andrewsmedina> fwereade_: you can do it
<andrewsmedina> fwereade_: use golden image is a very common amazon workflow
<fwereade_> andrewsmedina, I think there's a general assumption in the codebase that we'll be deploying to ubuntu -- charms, in particular, are intended to be targeted to a particular ubuntu series -- and we'd need to think carefully about how to relax that
<andrewsmedina> fwereade_: and with this is not need install the same thing every time
<andrewsmedina> fwereade_: humm
<fwereade_> andrewsmedina, indeed -- I can definitely see the utility of what you ask for
<fwereade_> andrewsmedina, but as I say it involves a bit more complexity than one might hope for
<andrewsmedina> fwereade_: I know
<fwereade_> andrewsmedina, is it ramp-up time you're mainly worried about?
<andrewsmedina> fwereade_: yes
<fwereade_> andrewsmedina, hmm, I'm just thinking that I actually don't know what the usual distribution of time-spent-ramping-up actually is
<andrewsmedina> fwereade_: in every deploy, juju install juju, zookeeper agent...
<andrewsmedina> fwereade_: update and upgrade the ubuntu
<fwereade_> andrewsmedina, quite -- there's a fair amount to be done -- but I'm wondering how to get a decent idea of where we can save the most time in the general case
<niemeyer> bbcmicrocomputer: Are you getting such a umask? (/cc jcastro)
<niemeyer> bbcmicrocomputer: What's the 0077 reflecting, more precisely?
<andrewsmedina> fwereade_: I think skipping this installation every time
<bbcmicrocomputer> niemeyer: I noticed a lot of the configuration files being copied as part of a charm install hook was ending up as private to root, which caused problems when running daemon processes as other users.  So I altered one of the hooks to output the umask to a temporary file and found that when juju called it, it was 0077.
<niemeyer> bbcmicrocomputer: That certainly sounds bogus
<niemeyer> hazmat: Does that ring any bells?
<fwereade_> bbcmicrocomputer, btw, what version of juju are you using?
<niemeyer> bbcmicrocomputer: I can't find anything about such a umask in the code base, FWIW
<bbcmicrocomputer> niemeyer: 0.5+bzr457-0ubuntu1
<bbcmicrocomputer> niemeyer: me neither :)
<niemeyer> bbcmicrocomputer: Ah, found the source
<bbcmicrocomputer> niemeyer: it's an EC2 deployment and the system umask is def not set to 0077, so have assumed it was juju
<niemeyer> bbcmicrocomputer:        --umask <mask>
<niemeyer>               The (octal) file creation mask to apply. (default: 0077 for daemons, no change otherwise).
<niemeyer> bbcmicrocomputer: From twistd
<niemeyer> bbcmicrocomputer: Would you mind to file a bug? We'll certainly fix that
<bbcmicrocomputer> niemeyer: ah ok, so we def shouldn't be altering charms to switch umasks?
<niemeyer> bbcmicrocomputer: No, juju should not execute charms with such a umask
<fwereade_> niemeyer, I *think* it's already fixed accidentally, because the upstart agents run with --nodaemon
<bbcmicrocomputer> niemeyer: ok, will file a bug
<niemeyer> fwereade_: Oh, was that recent?
<fwereade_> niemeyer, thatstarts at r460 :)
<niemeyer> hah, ok :-)
<m_3> bbcmicrocomputer: we usually either use explicit chmods (preferred) or set the umask as needed in hooks
<niemeyer> bbcmicrocomputer: Thanks for filing the bug. It'll be good to have that tracked no matter what
<bbcmicrocomputer> m_3: makes sense
<m_3> bbcmicrocomputer: lots of charm helper fns have a mode arg... ch_template_file <owner> <mode> <source> <target>
<fwereade_> niemeyer, I haven't verified, so yeah, we definitely want that bug ;)
<m_3> bbcmicrocomputer: 600 isn't an unreasonable starting point... better for the charm author to screw up in a more secure way than not IMO
<bbcmicrocomputer> m_3: yeah, it wouldn't surprise me if it was by design for this very reason
<bbcmicrocomputer> m_3: at least then the author is thinking about it
<m_3> bbcmicrocomputer: right
<_mup_> Bug #953258 was filed: juju executing hooks with umask of 0077 <juju:New> < https://launchpad.net/bugs/953258 >
<_mup_> Bug #953339 was filed: juju remove-relation usage/help typo <juju:New> < https://launchpad.net/bugs/953339 >
<robbiew> jcastro: SpamapS: http://www.zazzle.com/run_lxc_tshirt-235168775723259384
<robbiew> we should make hallyn wear it
<jcastro> robbiew, can we put "but don't forget to remove the stuff in /var/lib every once in a while." on the back?
<jcastro> that is pretty awesome though
<arosales> jcastro, m_3: If you have a spare minute could you add http://charmschoolsv.eventbrite.com/ to juju.ubuntu.com/Events?
<robbiew> lol
<arosales> more for our tracking where and what we have done.
<arosales> also what do you think about putting webinars/virtual sessions you have done there to?
<arosales> for http://charmschoolsv.eventbrite.com/ Clint and Juan are running that one.
<m_3> arosales: done
<arosales> m_3: Thank you
<m_3> np
<marcoceppi> Hey everyone o/ So I've started back up on the Steam charm and I don't think it's being done properly
<m_3> marcoceppi: cool man... don't be shy about making changes
<marcoceppi> Right, This one is kind of drastic though. I'm thinking that each "steam game" should be a subordinate(sp?) charm of a main Steam charm. To be deployed with the "Constraints" flag
<marcoceppi> Opinions?
<marcoceppi> Basically "I want to do this thing even more weirder"
<m_3> ha!
<marcoceppi> Because more weirder is the only way to describe it
<m_3> I kind of seems like a config option to me
<m_3> but there's no reason not to do it that way
<m_3> well... except those features haven't really landed yet
<m_3> I'd say heck yeah... experiment
<marcoceppi> That's what I've been hammering on; however, I've run into "How do I deploy custom maps", "How do I add plugins", "How do I manage config options that don't exist between games"
<m_3> ah right
<marcoceppi> There are maybe a handful of shared config options, the rest are just hog wild different
<m_3> well perhaps they're all separate charms?  that have a steam plugin of sorts
<m_3> which is exactly what you were saying ;)
<marcoceppi> For maps I figured there could be a "maps" folder that users can extract maps to and that would be moved in to place for that game, but if you switch game types the maps won't be compatible
<marcoceppi> m_3: Yeah ;)
<marcoceppi> It's a weird use case
<marcoceppi> I really don't _want_ to make 35 different charms for each different Steam game server
<marcoceppi> but I'm running out of sane options for consolidating them in to one
<m_3> marcoceppi: until the steam charm can be deployed separately, then I'd recommend just using a helper sort of library for those parts... then you can turn it into a separate charm once we can do subordinates
<m_3> marcoceppi: wow.. that _is_ a lot
<marcoceppi> yeah :\
<m_3> perhaps it's just more complex configuration then
<marcoceppi> Well, I currently do this for configuration. juju steam --set config_key="mp_timelimit" config_value="12"
<marcoceppi> so you have wild card config keys
<m_3> right
<m_3> note you can pass entire json or yaml files as config options...
<marcoceppi> Also, what's the policy on something like "map_url" as a config option that would fetch a remote ZIP file and extract it (not over HTTPS and most likely using any Cryptographic checking) but wouldn't be part of the actual charm setup, user invoked
<m_3> marcoceppi: do you have example configuration files for deploying steam?
<m_3> a couple of different games
<marcoceppi> m_3: I've been doing that for each game
<marcoceppi> so you could just point to a configuration file and it would use "sane" defaults for that game
<m_3> marcoceppi: links?
<m_3> marcoceppi: you still working from lp:~marcoceppi/charms/oneiric/steam/trunk?
<marcoceppi> Yeah, there might not be all the updates there but not much work has been done since then
<marcoceppi> http://bazaar.launchpad.net/~marcoceppi/charms/oneiric/steam/trunk/view/head:/opt/tf2.cfg
<marcoceppi> So that's what a game config looks like
<m_3> marcoceppi: awesome... I'll take a look
<m_3> marcoceppi: perhaps some config options can be grouped into dedicated config files... then we can pass the entire config files in as charm config params
<m_3> yaml can take a yaml file as a field
<marcoceppi> Interesting
<m_3> http://paste.ubuntu.com/881172/
<m_3> that's a snippet from a config yaml file I'm passing in to a charm
<m_3> the | and the indentation make the magic happen
<m_3> I think that could be really useful here
<m_3> marcoceppi: we'd have to watch _re_configuration... treat that more as a full upgrade... but it should work
<marcoceppi> Right, this looks promising, I'm going to give it a shot
<m_3> seems like it'd make it easier to have separate sets of config options for different games... this way you can pass in a whole config file for each game
<m_3> common stuff you can keep in the main config.yaml
<m_3> but then there's an option for... game_config:
<m_3> that you write out and point the game to during spinup
#juju 2012-03-13
<marcoceppi> HTTPS okay to avoid hash check?
<SpamapS> marcoceppi: as long as you are verifying the certificate
<SpamapS> marcoceppi: which wget does by default
<marcoceppi> what about git clone via GIT+SSH?
<SpamapS> Would need to have the ssh server key in the charm.
<SpamapS> But then, yes
<marcoceppi> cool, cool
<marcoceppi> thanks
<SpamapS> as long as you have a high degree of confidence that the content is the content you intended
<marcoceppi> Like my highschool self, I'm low on confidence :)
<SpamapS> marcoceppi: interesting .. who owns the S3 bucket MinecraftDownload ?
<marcoceppi> That's Mojang's official bucket
<SpamapS> marcoceppi: ok, so if they ever deleted it, could someone else pwn it?
<SpamapS> marcoceppi: I think thats just "something to look out for" and not a reason to be worried
<marcoceppi> SpamapS:  that's a good question though, I'm not sure
<marcoceppi> I'll try that out with my personal vs work AWS accounts, see if names are locked in forever or not
<SpamapS> marcoceppi: seems like they should be mutable if you can delete them
<marcoceppi> Would make sense
<SpamapS> marcoceppi: reviewed proposed change
<marcoceppi> SpamapS:  thanks! I understand calling stop and start, but why install? Should I have the check in install to see if it's been "installed" before there?
<hazmat> SpamapS, are you in santa clara?
 * hazmat is as well
<SpamapS> hazmat: haha yes
<SpamapS> hazmat: actually I'm at the SJC airport
<SpamapS> hazmat: didn't realize pycon was here as well, or I'd have tried to get in touch w/ you guys
<SpamapS> hazmat: I did bump into some canonical peeps at the hyatt before realizing charm school was at the hilton across the street. ;)
<hazmat> SpamapS, wanna come over, we're all hanging out sprinting
<hazmat> i'm sitting next to barryW
<SpamapS> hazmat: I'm in the airport. Depart in 1hr. :-P
<SpamapS> hazmat: just dropped in for a commando attack on the juju users of silicon valley :)
<marcoceppi> If I'm updating a charm, and there's no copyright file, should I throw one in there?
 * marcoceppi is not a lawyer
<SpamapS> marcoceppi: do you know for sure the license and copyright status of all the files?
<marcoceppi> The only files are the hooks and core charm files
<marcoceppi> none of them have copyright headers
<SpamapS> marcoceppi: where did you get those files?
<marcoceppi> heh, http://charms.kapilt.com/charms/oneiric/owncloud
<SpamapS> well I-be-damned
<marcoceppi> yes, yes you be :)
<SpamapS> marcoceppi: can you open a bug in that charm and assign it to koolhead17 ?
<marcoceppi> yeah
<SpamapS> should not have been promulgated
<SpamapS> anyway.. since I'm damned.. I think I"ll go get a mojo burger
 * marcoceppi looks sternly at SpamapS for not being perfect
 * SpamapS looks hard a-stern .. 
<marcoceppi> bug opened
<marcoceppi> Going to head off, have a safe flight!
<koolhead17|away> marcoceppi, hey there
<koolhead17|away> hey SpamapS
<_mup_> Bug #953732 was filed: Destroying a maas environment results in a traceback <juju:New> < https://launchpad.net/bugs/953732 >
<gary_poster> I'm getting the following error when I try to start a local charm:
<gary_poster> 2012-03-13 08:44:12,459 INFO Searching for charm
<gary_poster> Invalid value for cache: False
<gary_poster> ...well, I'll google first...
<gary_poster> Looks similar to https://bugs.launchpad.net/juju/+bug/952355
<_mup_> Bug #952355: Backward incompatible change: existing env boolean values cause total failure <juju:New> < https://launchpad.net/bugs/952355 >
<marcoceppi> gary_poster: Which charm?
<gary_poster> marcoceppi, buildbot-master (which we wrote)
<gary_poster> looks like something to do with a config value not being a string?
<jamespage> gary_poster, yep
<gary_poster> ok, looking, thanks
<jamespage> basically if juju thinks it might be a boolean it won't let the config value be  string
<gary_poster> :-/
<jamespage> I hit this in several of my charms when running against juju PPA
<jamespage> its also annoying that juju will fail if ANY charm in your repository has this issue - not just the one you are trying to deploy...
<jamespage> (that took me a while to figure out)
<gary_poster> oof, wow.  jamespage, is there an easy workaround for now?
<marcoceppi> jamespage: Oh, that's weird
<gary_poster> I mean, even in changing config
 * gary_poster goes to look for explicit yaml string syntax, if there is such a thing
<jamespage> gary_poster, switch anything that has values 'True' or 'False' to type: boolean
<jamespage> rather than string
<jamespage> same applies to uncapitalized versions of those literals
<jamespage> or don't use true/false
<gary_poster> jamespage, ack, thank you.  I don't think it's even in my charms--which charms did you find with the problem?
<jamespage> gary_poster, cassandra had it but I've fixed that one
<gary_poster> I suppose I could get rid of all the ones I don't currently use...and try to get newer versions of all of them
<jamespage> gary_poster, might make sense for the time being
<gary_poster> jamespage, ack, thanks again
<jamespage> I'm hoping that we might get a fix to sort out backwards compat
<jamespage> its a PITA
<jamespage> gary_poster, np
<gary_poster> agreed on PITA
<bbcmicrocomputer> jamespage: ah glad I just checked in here, was about to file a bug report for the same thing :)
<jamespage> bbcmicrocomputer, :-)
<jamespage> bbcmicrocomputer, both hadoop and hbase suffered from this change
<jamespage> I've fixed both up for precise
<bbcmicrocomputer> jamespage: ah cool, I'll pull down those updates then
<bbcmicrocomputer> jamespage: looked to me like juju was just using the YAML parser and allowing it to coerce config objects to any type, hence not allowed boolean values as strings
<niemeyer> Good mornings!
<bbcmicrocomputer> niemeyer: morning
<niemeyer> bbcmicrocomputer: Heya
<marcoceppi> R
<m_3> marcoceppi: shouldn't that be 'R m8t3' for chat like a pirate day?
<marcoceppi> m_3:  I suppose... *rubs chin*
<m_3> marcoceppi: :)
<SpamapS> m_3: my son was born on talk like a pirate day. Wife was not exactly in the spirit during labor.. but the nurses were all about swabbing the deck and hoisting the mainsail.. ;)
<SpamapS> shiver me timbers, thar be a baby!
<marcoceppi> How can you tell which charms need review? It would appear almost all the new-charms are awaiting feedback from the authors
<jcastro> marcoceppi, it should be new-charm
<jcastro> https://bugs.launchpad.net/charms/+bugs?field.tag=new-charm
<marcoceppi> right, but they all seem to have been turned over
<jcastro> check the in progress ones
<marcoceppi> k
<jcastro> incomplete means not ready
<jcastro> oh dude, new. :)
<SpamapS> we started on diaspora on the big screen yesterday, sort of a collaborative charm writing experience.. it went pretty well.
<jcastro> marcoceppi, looks like Gearman is ready for review
<SpamapS> and disaspora is.. nightmarish to setup
<jcastro> it looked so not fun
<SpamapS> negronjl said it felt a lot like cloudfoundry
<m_3> marcoceppi: new-charm tag _and_ status of "new" or "fix committed"
<marcoceppi> m_3 jcastro thanks!
<m_3> SpamapS: yay!  I totally wanna see diaspora working
<SpamapS> m_3: 18 tons of ruby gems to install. :-(
<SpamapS> I can't believe rubygems, pear, and pecl, don't use any kind of crypto to secure their downloads
<m_3> marcoceppi: been trying to keep it as a conversation... review and update status to incomplete or in progress... then they set status to fix committed for a nother round of review
<m_3> SpamapS: use bundler... there's a Gemfile
<marcoceppi> m_3: makes sense, easy enough to track
<SpamapS> m_3: bundler is what we used
<m_3> SpamapS: gem won't check certs on https sources?
<SpamapS> m_3: gem doesn't use https
<m_3> rhuh?
<SpamapS> it didn't last year when I was patching it for some other bugs and I got curious
<m_3> I'd have to look... thought most sources were specified via https github urls
<SpamapS> m_3: and where does it get those source URLs?
<m_3> you can set that in the gemfile
<m_3> don't know for the "standard" rubygems.org gems tho
<SpamapS> m_3: ok, so I'm more talking about when I type 'gem install foo'
<m_3> right... dunno for the stds
<m_3> how'd charmschoolsv go?
<m_3> how many peeps were working along -vs- osmoting?
<negronjl> SpamapS, m_3:  I'll keep working on diaspora.  I'll commit the work soon.  It's a pain in the neck but, I like a challenge :)
<m_3> negronjl: cool!
<m_3> negronjl: I'll try to drum up volunteers to maintain it going forward
<negronjl> m_3:  that would be great !  It's a complicated mess of gems, ruby packages and all other sorts of nonesense
<SpamapS> so.. typical charm :)
<m_3> negronjl: yeah, hitting a ruby conf later this week... I'll try to drum up help
<negronjl> m_3: nice!
<m_3> negronjl: were there lots of peeps writing stuff?
<m_3> negronjl: or was it mostly people wanting to customize/use existing charms?
<negronjl> m_3: Some of the guys kept asking very intelligent questions ( outside of what we were talking about ) which tells me that they were already investigating the use of juju ( and charms ) for their own projects.
<m_3> negronjl: awesome
<negronjl> m_3: We had some guys that were looking at the existing charms ( couchbase and cassandra come to mind ) to see how they can better the charm.
<m_3> dude, that's great
<negronjl> m_3: The DataStax guy in particular was already looking for ways to make cassandra better .... that part was awesome!
<m_3> how'd we publicize this event?
<m_3> sounds like you had a great group of people show up
<negronjl> m_3: Some of the business guys here sent email out to their customers ... that was it
<m_3> ok, gotcha
<negronjl> m_3: indeed ... very smart and technical people.
<m_3> cool... thanks for the update
<jcastro> SpamapS, are you guys back from travel? like should we have a linkup today?
<SpamapS> jcastro: yeah it was a 1 day thing :)
<SpamapS> jcastro: I have a team call.. then need to catch up on email. So, probably 90min.. but then yeah I want to chat w/ you and Juan
<jcastro> yeah whenevs
<SpamapS> negronjl: can you join us from the land of barristas and lattes?
<jcastro> just the usual charm team hang out, we'll snag mims
<negronjl> SpamapS: here
<negronjl> SpamapS: can you guys give me the Hangout URL ?
<SpamapS> negronjl: when we start it.. 90 min
<negronjl> SpamapS: yeah ... I jumped the gun there didn't I :/
<SpamapS> negronjl: perhaps try thinking about baseball..
<m_3> ewww
<jamespage> so how exactly does the new constraints stuff work?  any good docs on usage yet?
<SpamapS> jamespage: I believe there's a spec
<SpamapS> hm, not in the trees anywhere.. weird
<jamespage> SpamapS, http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/docs/source/drafts/placement.rst
<jamespage> ?
<SpamapS> jamespage: actually yes
<SpamapS> that does seem to mention it
<SpamapS> though light on implementation details like how to use them
<jamespage> SpamapS, agreed
<SpamapS> jamespage: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589386
<SpamapS> jamespage: even weirder than needing a restart..
<SpamapS> you need *two* reloads
 * jamespage faceplants
<jamespage> why oh why oh why
<SpamapS> jamespage: pretty odd. The recommended solution is to do 'restart' on initial install, and 'force-reload' on upgrades
<SpamapS> I think I'll submit a patch for that to Debian and fix it in our packages once we get some clarity on 5.4.0
<jamespage> SpamapS, OK - sounds sensible
<SpamapS> jcastro: G+?
<SpamapS> negronjl: ?
<SpamapS> m_3: ?
<negronjl> SpamapS: here
<SpamapS> actually let me reboot to see if I get my video back
<jcastro> SpamapS, give me 5!
<SpamapS> hrm..
 * SpamapS tries new kernel
 * SpamapS rejoices
<SpamapS> invites out
 * SpamapS lurves audio hell
<SpamapS> jcastro: ??
<m_3> SpamapS: in a meeting...
<m_3> SpamapS negronjl jcastro : damn... just tried to join
<SpamapS> dohhhh haha
<m_3> miss anything
<m_3> ?
<negronjl> m_3: too funny
<SpamapS> jcastro did a triple lindy
<negronjl> m_3: maybe we left 'cause we saw you trying to join
<m_3> we were hanging out talking about juju arm tests
<m_3> no way!
<m_3> I love the triple lindy
<_mup_> Bug #954350 was filed: juju bootstrap doesn't ensure zookeeper is installed <juju:New> < https://launchpad.net/bugs/954350 >
<koolhead11> SpamapS, marcoceppi if anyone can update the charm repo with my latest commit, i have added the copyright file!! :)
<marcoceppi> koolhead11:  I saw that! I've got an update that will put it in place
<koolhead11> marcoceppi, cool!! cheers!!
<hazmat> m_3, it feels like the timeout on the charmrunner service watching needs to be increased to account for the container creation
<SpamapS> hazmat: hey, ... lxc-start-ephemeral.. why can't we use that in juju instead of lxc-start?
<SpamapS> or rather, instead of lxc-clone+lxc-start ?
<hazmat> SpamapS, we do lxc-clone
<SpamapS> Right, ephemeral is now using overlayfs .. allowing all containers to share the same VFS cache
<hazmat> on an ssd its pretty fast to get a new container for a new unit
<SpamapS> not about speed
<hazmat> the charmrunner is reusing the env, so the template container is still around
<SpamapS> cache pressure is intense w/ 7 containers running
<SpamapS> think .. laptop w/ 4GB of RAM..  spinning up openstack on that pushes it into swap.
<hazmat> doc it hurts when i kick myself ;-0
<hazmat> SpamapS,  is that overlay persistent?
<SpamapS> hazmat: don't know.
<SpamapS> perhaps?
<SpamapS> hazmat: aufs was persistent.. so I presume overlayfs (which is supposed to be a replacement) is too
<hazmat> i guess i should play around with it
<SpamapS> hazmat: tho "lxc-start-ephemeral" suggests that the containers maybe are not.
<SpamapS> hazmat: I wonder.. maybe we can mod lxc-clone to use it somehow
 * SpamapS wonders why we're re-inventing schroot in lxc's tools
<hazmat> SpamapS, yeah.. its creating the overlay in /tmp
<SpamapS> hazmat: ok, so in theory, we could just change our usage of 'lxc-clone' to just mount an overlayfs and copy the configs..
<SpamapS> hazmat: and then push that back upstream to lxc as '--overlayfs' eventually.
<SpamapS> hazmat: one thing that sucks.. overlayfs still doesn't support inotify. :-P
<hazmat> SpamapS, we could, but really that should be in the ephemeral script to take an overlaydir option
<hazmat> and then we could just use it..
<SpamapS> hazmat: except then its not ephemeral :)
<hazmat> SpamapS, the only reason its ephemeral is that the script is hardcoded to use a /tmp dir.. else it would be suitable.. but yeah.. point taken
<SpamapS> hazmat: tho because the rootfs is a mount, and not static files on disk, we'd need a pre-start for the container that mounts it again.. I think
<SpamapS> hazmat: or just accept that they are ephemeral make it an environment option
<SpamapS> err.. "and" make it an option
<koolhead11> https://github.com/lg/murder  is it possible to use it as charm?
<SpamapS> koolhead11: yes it would be an awesome charm!
<SpamapS> koolhead11: it might morph into a subordinate once that lands
<koolhead11> SpamapS, but how will/can we use it?
<koolhead11> i meant a used case kind :PO
<SpamapS> koolhead11: probably two parts.. one charm for the tracker server, and then one as the client that distributes files.
<SpamapS> koolhead11: dare to dream... if you have a use case.. charm it up.. otherwise.. perhaps leave it for somebody with practical need/experience to make it happen?
<koolhead11> SpamapS, shall i put it as whishlist/charm needed?
<SpamapS> koolhead11: sure. :)
<SpamapS> hazmat: thoughs on bug 952397 .. I saw that you picked it up..
<_mup_> Bug #952397: Juju is forcing *ALL* charms in a repo to be perfect to be able to deploy *any* <juju:In Progress by hazmat> < https://launchpad.net/bugs/952397 >
<SpamapS> thoughs or thoughts  .. either is fine ;)
<hazmat> SpamapS, yeah.. i need to fix up the exception hiearchy to prevent that from reoccuring.. the whole get_charm_from_path returning a charm error if its not a charm screws up the error catching logic to often
<hazmat> SpamapS, i'm sprinting on mailman right now at pycon (conference day).. but i'll be back in the swing tomorrow
<koolhead11> SpamapS, https://bugs.launchpad.net/charms/+bug/954535
<_mup_> Bug #954535: Charm needed: murder <charm> <juju> <Juju Charms Collection:New> < https://launchpad.net/bugs/954535 >
<SpamapS> hazmat: cool I figured it was just an error handling issue
<SpamapS> koolhead11: thanks!
#juju 2012-03-14
<marcoceppi> SpamapS: When you get a chance can you take a look over the Minecraft charm merge?
<marcoceppi> https://code.launchpad.net/~marcoceppi/charms/oneiric/minecraft/trunk/+merge/97132
<zyga> hi, can I experiment with juju on my single computer?
<zyga> without using ec2?
<zyga> according to the docs I cannot (it says lxc support is not ready)
<zyga> but installing juju on precise pulled in lxc
<zyga> so what is it?
<james_w> zyga, lxc works, so you can use that
<james_w> zyga, where did you see that it isn't ready?
<zyga> james_w, in the official juju docs, although they keep talking about natty so they may just be old
<zyga> let me pull the link
<zyga> james_w, https://juju.ubuntu.com/docs/faq.html?highlight=amazon%20ec2
<zyga> james_w, "Does juju only deploy to the Amazon EC2 cloud?"
<james_w> zyga, thanks
<zyga> james_w, do you know of a tutorial that would allow me to learn about juju using my desktop and lxc/kvm?
<zyga> james_w, I think those docs are out of date in other areas too: https://juju.ubuntu.com/docs/getting-started.html#running-from-ppa
<james_w> juju: https://juju.ubuntu.com/CharmSchool
<james_w> err, zyga ^
<zyga> thanks
<james_w> jcastro, where do we file/fix those doc bugs?
<jcastro> lp:juju/docs
<zyga> is the ppa still recommended?
<jcastro> for oneiric?
<jcastro> yes, for precise, not sure.
<zyga> for precise
<jcastro> i've been trying to run distro as much as I can
<james_w> I'd say run the distro version in precise
<james_w> so that you can report problems and they can be fixed
<zyga> on https://juju.ubuntu.com/CharmSchool I see an example local environment
<zyga> since I want to use distro packages what should I say in juju-origin:
<jcastro> Leaving it out should just work
<zyga> http://pastebin.ubuntu.com/883240/
<zyga> virbr0 is already up
<zyga> it was up on boot
<zyga> my /etc/network/interfaces contains static configuration for eth0 and lo, if that is relevant
 * zyga tries to reboot 
<zyga> so rebooting did not help
<zyga> what should I do when juju fails to boostrap with "2012-03-14 15:16:01,188 ERROR Command '['virsh', 'net-start', 'default']' returned non-zero exit status 1"
<jamespage> zyga, can you check that the account you are using is in the libvirtd group please
<zyga> jamespage, it is not
<zyga> jamespage, should that be automatic?
<jamespage> zyga, no
<zyga> ah, I see
<zyga> sigh
<zyga> juju should tell me that
<jamespage> zyga, that should be in the docs and juju should tell you - please raise a bug
<zyga> reporting now
<jamespage> zyga, TBH as soon as you add that group it will be able to see the default network (which should already exist)
<zyga> it does
<zyga> sigh
<zyga> can I do this without logging out?
<zyga> https://bugs.launchpad.net/ubuntu/+source/juju/+bug/955110
<_mup_> Bug #955110: juju should tell me that I'm not in libvirtd group when running juju bootstrap <amd64> <apport-bug> <precise> <juju (Ubuntu):New> < https://launchpad.net/bugs/955110 >
<jamespage> zyga, I don't think so
<james_w> newgrp libvirtd
<zyga> james_w, wow, I learned something very cool today, thanks
<jamespage> nice
<jamespage> zyga, hmm - the docs do actually refer to this - https://juju.ubuntu.com/docs/provider-configuration-local.html
<jamespage> but it would be nice for juju to check
<jdstrand> hi, it's me again and I'm having trouble with juju lxc
<jdstrand> I'm am trying to perform the mir for juju, but can't get it to work the way I thought it should work
<jdstrand> s/mir/mir review/
<jdstrand> you may recall last time I tried to do this inside a vm. today I am trying on bare-metal
<jdstrand> here are the commands I ran: http://paste.ubuntu.com/883423/
<jdstrand> looking at juju debug-log, I see:
<jdstrand> 2012-03-14 10:27:59,548 Machine:0: juju.agents.machine INFO: Started service unit wordpress/0
<hazmat> jdstrand, what's the current status output?
<jdstrand> (it took a while to bootstrap)
<hazmat> jdstrand, bootstrap on local doesn't do very much, it does most of the work creating the first unit
<hazmat> and subsequent units in that env are fast (lxc-clone)
<jdstrand> hazmat: http://paste.ubuntu.com/883430/
<jdstrand> hazmat: I meant debootstrap
<jdstrand> hazmat: I did notice some firewall denials on the host, which thought could be the problem. so I did: sudo ufw allow in on virbr0 from 192.168.122.0/24
<jdstrand> hazmat: I have not exposed this yet, cause the state is still pending
<hazmat> jdstrand, hmm
<hazmat> jdstrand, can you ssh into the unit
<hazmat> jdstrand, you did the firewall manipulation after launching the unit?
<hazmat> er. deploying the charm
<jdstrand> hazmat: I only noticed the firewall denials after deploying the charm, so yes, after
<jdstrand> I did not try to do the charm again
<jdstrand> hazmat: is there a convenient way to get the ip address for the machine?
<jdstrand> s/machine/container/
<jdstrand> (remember I'm still a juju noob :)
<hazmat> jdstrand, yeah.. if the container didn't external connectivity during its setup, that would be problematic for it.. inside of $data-dir/units  there should be symlinks to the unit logs which would be helpful to see
<jdstrand> hazmat: what is the proper way to blow away this charm, destroy-service?
<SpamapS> jdstrand: to get the ip btw, I usually just 'grep dnsmasq /var/log/syslog'
<jdstrand> SpamapS: ah right, this is just a libvirt thing. thanks
 * jdstrand is not new to libvirt
<SpamapS> Right it uses the libvirt networking
<jdstrand> ssh ubuntu@192.168.122.145 worked
<SpamapS> jdstrand: next thing to check is whether or not juju is running (should be, via an upstart job)
<SpamapS> I think.. I'm not sure if that landed before or after 457, which is what is in precise
<jdstrand> SpamapS: on the host, right?
<SpamapS> jdstrand: there should be a unit agent running inside the container
<SpamapS> jdstrand: and there would be a machine agent running on the host
<jdstrand> $ ps auxww|grep juju
<jdstrand> root       372  0.0  0.6  34972 14036 ?        Ss   15:28   0:01 /usr/bin/python -m juju.agents.unit --logfile=/var/log/juju/unit-wordpress-0.log
<jdstrand> (that's in the container, so yes)
<SpamapS> yay
<hazmat> jdstrand, yes
<SpamapS> jdstrand: so you should also have a charm log visible on the host at ${data-dir}/${USERNAME}-${environment-name}/units/wordpress-0/charm.log
<jdstrand> the agent is running on the host as well
<hazmat> jdstrand, there's a machine agent juju.agents.machine on the host that's deploying the containers + unit agents
<SpamapS> hazmat: remind me, why doesn't debug-log show install anymore?
<jdstrand> SpamapS: no charm.log, only container.log and unit.log (a symlink)
<hazmat> SpamapS, argh.. i thought that was fixed, it hasn't really ever done it reliably to be honest. its worth a bug report
<SpamapS> jdstrand: oh I think unit.log is the one.
<hazmat> yup
<SpamapS> hazmat: there's an open bug
<SpamapS> bug #760818
<_mup_> Bug #760818: debug log is initialized too late in the unit agent startup, to catch install/start hooks <juju:Confirmed> < https://launchpad.net/bugs/760818 >
<hazmat> sheesh that's old
 * hazmat needs caffienates
<jdstrand> SpamapS: what am I looking for in unit.log?
<SpamapS> jdstrand: that should be the record of the install of wordpress
<jdstrand> I do see some zookeeper errors
<SpamapS> the timeouts are just ZK being pedantic
<jdstrand> it ends wth initiated connection to server [192.168.122.1:56835]
<jdstrand> session establishment complete on server [192.168.122.1:56835]
<jdstrand> Closing zookeeper sessionId=0x1361181aacd0007 to [192.168.122.1:56835]
<jdstrand> there is nothing about wordpress
<jdstrand> (except ZOO_INFO@log_env@662: Client environment:host.name=jamie-local-wordpress-0)
<SpamapS> interesting.. I guess I'm forgetting where the charm log ends up
<jdstrand> SpamapS: perhaps destroy-service and try again now that my firewall is in order?
<SpamapS> jdstrand: you can just 'deploy local:wordpress wp2' and keep the old one around for comparison..
<SpamapS> jdstrand: I'm deploying here so I can jog my memory
<jdstrand> SpamapS: so, the first time I used:
<jdstrand> juju deploy --repository=/usr/share/doc/juju/examples local:oneiric/wordpress
<jdstrand> this time I should use:
<jdstrand> juju deploy --repository=/usr/share/doc/juju/examples local:oneiric/wordpress wp2
<jdstrand> correct?
<SpamapS> jdstrand: correct
<jdstrand> 'deploy' command finished successfully
<SpamapS> jdstrand: naming the service after the charm is just a convenience
<jdstrand> it still says pending
 * jdstrand check firewall logs again
<jdstrand> did have some ipv6 ping denials in the forward chain...
 * jdstrand disables firewall and does wp3
<SpamapS> jdstrand: its entirely possible that master-customize step failed.. which would make all subsequent deploys fail. thats in ${data-dir}/user-env/units/master-customize.log
<SpamapS> hazmat: been meaning to poke you about that.. master-customize seemes to not detect errors very well
<jdstrand> SpamapS: it looks ok
<jdstrand> apt-get update
<jdstrand> id ubuntu
<jdstrand> etc
<jdstrand> Container Customization Complete
<jdstrand> (of course, I think we knew that cause I could ssh into the machine)
<jdstrand> SpamapS: after 'deply' what am I supposed to see in 'juju status'?
<SpamapS> jdstrand: well, thats just the thing, one of the steps in the middle can fail and it still starts the containers
<jdstrand> deploy*
<SpamapS> jdstrand: you should see the unit wordpress/0 with a state: started
<SpamapS> or, wp3/0
<_mup_> Bug #955209 was filed: charm.log uses 'Error' for all stderr messages <juju:New> < https://launchpad.net/bugs/955209 >
<jdstrand> SpamapS: yeah, I've never seen that :(
<jdstrand> SpamapS: I'll be happy to paste master-customize.log, but it looks ok
<SpamapS> http://paste.ubuntu.com/883485/
<SpamapS> jdstrand: is that more like what you have?
<SpamapS> hazmat: would be nice if destroy-environment cleaned up datadir some.. I just realized mine has a ridiculous amount of cruft in it
<jdstrand> SpamapS: yes, that is exactly what I have for wordpress/0
<jdstrand> SpamapS: wp2/0 and wp3/0 now have a public-address
<SpamapS> jdstrand: but still pending?
<jdstrand> SpamapS: master-customize.log: http://paste.ubuntu.com/883488/ (would be great if I could set a local mirror)
<jdstrand> SpamapS: juju status: http://paste.ubuntu.com/883491/
<jdstrand> oh, I just ran it again and it started!
<jdstrand> both wp2 and wp3
<SpamapS> yay
<jdstrand> SpamapS: how long does it typically take for a charm to go to 'started'?
<SpamapS> jdstrand: the local provider is particularly slow because it has to download everything as individual packages and unpack them...
<SpamapS> jdstrand: with EC2, you have the Ubuntu cloud image, which has a lot of deps already installed, so the time between saying 'deploy' and the install hook runite a bit less
<SpamapS> jdstrand: On my very-slow-disk macbookpro, I said 'deploy' some 8 minutes ago, and its justn ow instaling the wordpress package. :-P
<jdstrand> SpamapS, hazmat: thanks for your help and explanations. seems my bare-metal woes were firewall related. I will continue this later (I have calls now)
<jdstrand> SpamapS: ok, thanks. that is helpful
<jdstrand> SpamapS: it would be nice if there was a command to see the progress of the deployment...
<jdstrand> anyhoo-- call!
 * jdstrand steps away
<SpamapS> jdstrand: btw, the request for allowing a local mirror is here; bug #897645
<_mup_> Bug #897645: juju should support an apt proxy or alternate mirror for private clouds <cloud-init:Fix Committed> <juju:Confirmed> < https://launchpad.net/bugs/897645 >
 * SpamapS raised it to High since its such a common request
<jdstrand> SpamapS: awesome, thanks :)
<jcastro> m_3,  I just did a review call with msm about our events and stuff.
<jcastro> all our major events are handled
<jcastro> m_3, but we need to know your plans for all the language confs your hitting this summer
<jcastro> so she can ping the organizers and get you what you need.
<jcastro> so if you could ping her this week that would be grand.
<benji> I did a review-of-sorts of https://code.launchpad.net/~rockstar/juju/setuppy-fixes/+merge/96902.  I'm not an approved reviewer so I marked it as a comment in hopes that it will be helpful to the person that reviews it for real.
<mars> Hi guys, is it possible to call a custom cloud-init script from a juju charm?
<mars> I have some custom initialization I would like to use on all of the hosts I create, and cloud-init's config files could save me from writing boilerplate code.
<SpamapS> mars: we're working on supporting the "policy" use case in a somewhat different way
<mars> SpamapS, ?
<mars> Sorry, I don't understand what the 'policy' use case is
<SpamapS> mars: basically a new feature called "subordinate charms" will land soon that will allow you to define policy for the box and deploy it along with other charms
<SpamapS> mars: what you're talking about is policy.. it goes across all your machines.. you want users or monitoring or whatever...
<SpamapS> mars: so, you'll write a charm that enables that, and then say 'deploy mystuff' and then 'add-relation service1 mystuff'  and 'add-relation service2 mystuff' and they'll be deployed together
<SpamapS> benji: thanks btw!
<mars> ok
<mars> SpamapS, I was looking to do something a bit different
<mars> There are few problems with LXC Lucid containers that I was hoping cloud-init could help smooth over
<benji> SpamapS: my pleasure
<mars> And one of my charms needs to have a custom repository set up in order to fetch the sourcecode: again, cloud-init makes that very simple
<SpamapS> mars: lucid is not a tested target for juju.. we don't test on python2.6.. so its possible the agents won't even start up
<SpamapS> mars: so do shell scripts. :)
<mars> hmm, good to know
<SpamapS> mars: seems like your install hook is a simpler place to setup your custom repository than cloud-init
<mars> SpamapS, yeah, I have written that in shell, and in Python fabric.  But I wanted to skip the boilerplate 'bootstrap' targets.
<SpamapS> I do think we need to look at adding some kind of way to easily include shared code in charms. Right now the best way to do that is with packages in PPA's.. but that seems too complicated for the simpler use cases
<mars> SpamapS, so Google has a couple references to Juju using cloud-init internally.  If that is true, then I assume there is no way to extend or call cloud-init with my additional configuration?
<SpamapS> mars: juju uses cloud-init for orchestra and ec2, but its not fundamental to juju..
<SpamapS> mars: so if you do any customization around cloud-init .. you won't be able to repeat on the local provider, which does not use cloud-init
<mars> ah
<mars> ok
<SpamapS> mars: I agree that boilerplate is bad.. juju needs to do more to allow cross charm sharing of code. Right now.. packages are the best way to do that.
<SpamapS> mars: note that there is precedent for this in the charm-helpers-sh package
<_mup_> juju/increase-session-timeout r450 committed by kapil.thangavelu@canonical.com
<_mup_> increase default session expiration timeout from 10s to 20s (same ping count/timeTick)
<_mup_> juju/force-upgrade r463 committed by kapil.thangavelu@canonical.com
<_mup_> remove cli short switch, force should be explicitly spelled
<_mup_> juju/scheduler-peek-list r473 committed by kapil.thangavelu@canonical.com
<_mup_> additional error scenario testing around revamped scheduler
<_mup_> txzookeeper/managed-watch-and-ephemeral r47 committed by kapil.foss@gmail.com
<_mup_> new managed client subclass that tracks watches and ephemerals
<jdstrand> so, I rebooted my machine that had local working right, and now get:
<jdstrand> $ juju status
<jdstrand> could not connect before timeout
<jdstrand> 2012-03-14 16:05:21,185 ERROR could not connect before timeout
<jdstrand> nothing is running-- not zookeeper, not the agents, not the containers
<jdstrand> I tried 'juju bootstrap' again, and it told me it was already bootstrapped
<jdstrand> is there some procedure I missed for rebooting a machine with local lxc and juju?
<m_3> jcastro: will do
<gary_poster> SpamapS, hey, you around?  I'd like to talk about our team's difficulties with the debian build for the python charm helpers
<gary_poster> my team's, I should say :-)
<SpamapS> gary_poster: yeah
<SpamapS> gary_poster: been fighting the email demons all day, but I have a todo to review that whole merge proposal. :)
<gary_poster> Thanks SpamapS.  Yeah, I've been fighting my own demons today too.  The short of it is that we've lost a lot of man hours on trying to get the debian packaging working on that.  Could we do one of (a) toss it to you, (b) make a separate package and toss it to you, or (c) have some close attention from you to pair with someone to get this packaged?  We'd love to increase our packaging fu, but that's more time for you I suspec
<gary_poster> t.
<SpamapS> gary_poster: toss to me
<SpamapS> gary_poster: will try to carve out some time today, otherwise I'll take a look tomorrow firs tthing.
<gary_poster> SpamapS, ok, many thanks.  gmb, do you have something you should merge into that mp, or should SpamapS just look at the original stuff from bac?
<gmb> gary_poster, SpamapS: I think the original stuff from bac is sufficient. My additions either a) had no effect or b) broke everything.
<gary_poster> lol
<gmb> I'll make sure it's in a pristine state.
<gary_poster> ok, thanks again SpamapS, and thanks gmb
<jdstrand> SpamapS: is there any trick to restarting a machine with a 'local' configuration?
<jdstrand> SpamapS: the host that is. if I reboot the host all is gone on reboot
<gmb> SpamapS, I've updated the branch to remove my cruft. Best of luck; let me know if you need any help so that I can be conveniently sick that day.
<SpamapS> jdstrand: in theory, it should all come back up.. as it should have installed an upstart job to start the machine agent and zk
<SpamapS> jdstrand: in practice, I have not tested that. ;)
<jdstrand> (ie, zookeeper, twistd, agents, instances and anything else I forgot is not started)
<jdstrand> SpamapS: I guess I will file a bug
<SpamapS> jdstrand: on my system, I see a juju-clint-local-file-storage.conf and a juju-clint-local-machine-agent.conf .. but nothing that starts ZK
<SpamapS> gmb: remind me where the branch is?
<jdstrand> SpamapS: I don't have any /etc/init/juju* on the host
<SpamapS> jdstrand: should be put there after 'bootstrap' ..
<jdstrand> SpamapS: I can say after employing my workaround in bug #955540, I was actually able to use juju wholly within a vm
<_mup_> Bug #955540 was filed: juju-create hard-coded to use 192.168.122.1 <juju:New> <juju (Ubuntu):Triaged> < https://launchpad.net/bugs/955540 >
<_mup_> Bug #955540: juju-create hard-coded to use 192.168.122.1 <juju:New> <juju (Ubuntu):Triaged> < https://launchpad.net/bugs/955540 >
<SpamapS> jdstrand: its entirely possible that landed after r457
<jdstrand> SpamapS: is there a new version of juju expected in precise soon?
<SpamapS> jdstrand: yes there will be a FFe filed as soon as one last feature is done.
<SpamapS> jdstrand: thanks for the thorough reviews.. lots of stuff to work on.
<jdstrand> SpamapS: heh-- at this point I am just trying to get it to work so I can understand it and pke at it :)
<jdstrand> but np
<jdstrand> its pretty cool once I got things working
<jdstrand> it's
<SpamapS> jdstrand: I think we need to make it more visual.. more feedback between the agent coming up and state: changing to started.. so you can watch more
<jdstrand> SpamapS: that would be helpful. I'm also finding the lack of man pages with toy and real world examples to be a hinderance (that will be in my MIR review)
<jdstrand> I feel like I can actually do enough to test it. but to deploy it in the real world I have a lot too learn
<jdstrand> (particularly around zookeeper security)
<SpamapS> jdstrand: I wrote a man page 6 months ago but the devs didn't want to keep it up to date. :-/ perhaps I should add it back to the debian package and just commit to updating it as part of the packaging.
<SpamapS> jdstrand: https://bugs.launchpad.net/juju/+bugs?field.tag=security
<SpamapS> jdstrand: https://bugs.launchpad.net/juju/+bug/813773
<_mup_> Bug #813773: Juju should have security rules/acls for every path in zk <security> <juju:In Progress by hazmat> < https://launchpad.net/bugs/813773 >
<jdstrand> SpamapS: excellent, thanks. are these bugs planned on being fixed in precise, or maybe 12.04.1?
<SpamapS> jdstrand: I'm not aware of plans to complete any of those no
<jdstrand> SpamapS: re man page> I find them immensely useful, and so do others (as you know, you wrote one :). there are so many urls to go to it is confusing to know what to use. most of the ones I saw were out of date (didn't mention lxc)
<jdstrand> heck, the man page could say: for more information, please see http://...'
<jdstrand> but something should be up to date :)
<jdstrand> I'm sure there are plenty of docs that are up to date-- I just didn't know where to find them is all
<SpamapS> jdstrand: good point. I think there's going to be a big documentation push very soon.
<jdstrand> SpamapS: that is great to here
<gmb> SpamapS, lp:~gmb/charm-tools/add-charm-helpers
<SpamapS> gmb: awesome, thanks
<hazmat> jdstrand, that should work with the ppa
<hazmat> re  reboot
<hazmat> not sure that it does with the last precise upload
<hazmat> which was right before the restart work landed
<jcastro> "I'm sure there are plenty of docs that are up to date-- I just didn't know where to find them is all"
<jcastro> hah
<jcastro> soon, soon!
<jcastro> ah cool, a bug for murder, that should be interesting
<jcastro> SpamapS, you still working? Because if you're going to do an initial review of the subway charm I'd like to shoulder surf
<adam_g> anyone seen an issue where, after deploying a number of services, a service is missing its machine units?
<adam_g> http://paste.ubuntu.com/884080/
<adam_g> ^ rabbitmq gets deployed but a machine never provisioned or associated with the service
<adam_g> ive been seeing this somewhat frequently but randomly over the last week
<SpamapS> jcastro: yeah still working
<jcastro> SpamapS, I found some things for him to improve
<jcastro> so no need to review it
<SpamapS> adam_g: for your issue, have you looked through the provisioning agent log?
<SpamapS> jcastro: aight
<jcastro> SpamapS, https://bugs.launchpad.net/charms/+bug/944246
<_mup_> Bug #944246: Charm Needed: Subway IRC client/server <new-charm> <Juju Charms Collection:Incomplete by bkerensa> < https://launchpad.net/bugs/944246 >
<jcastro> yeah! I helped! </10 year old>
<jcastro> SpamapS, also I owe the team, I used the word idempotent when talking to him
<SpamapS> aahhhh!!!!!!
 * SpamapS responding to idempotent
#juju 2012-03-15
<jcastro> SpamapS, next time you do want to do a review though, ping me, I can at least pick up the easy ones to prescreen for ya.
<SpamapS> jcastro: I need to get the python charm helpers into charm-tools actualy..  thats the current priority
<jcastro> I mean an opportunistic "whenever"
<hazmat> adam_g, if you have the provisioning agent log that would be helpful to diagnose.. is that against maas or orchestra?
<hazmat> ooh.
<hazmat> baremetal that is
<hazmat> that is odd, its not even showing the unit
<adam_g> hazmat: yeah, i watched the logs and there was nothing odd, let me go see if i can grep out that deployment
<adam_g> its since been working
<adam_g> this is an orchestra provider
<adam_g> http://paste.ubuntu.com/884140/
<hazmat> adam_g, with no units like that, it would appear the units where destroy via juju remove-unit
<hazmat> adam_g, that's a fragment of the log
<adam_g> hazmat: on ec2, ive seen juju get trigger happy and start taking out nodes that i've manually added to the security group. is it capable of doing similar things with the orchestra provider?
<adam_g> hazmat: how much context would you like? the log is big
<hazmat> adam_g, yes.. it owns the security group on ec2, and will treat things it doesn't know about on ec2 as runaways and clean them up.. that behavior is also present on orchestra
<hazmat> adam_g, but again something would have to have removed the rabbitmq unit
<hazmat> ie.. juju remove-unit
<hazmat> and even then juju wouldn't kill the machine.. because it knows about it
<hazmat> and if the machine where dead out of band, the unit would still show
<hazmat> adam_g, i'll take as much context as you have
<adam_g> right
<adam_g> sure one sec
<adam_g> http://paste.ubuntu.com/884146/
<adam_g> ^ that is from the teardown of the previous deployment through till the deployment following the failure
<adam_g> http://paste.ubuntu.com/884147/ <- thats the whole thing
<SpamapS> hazmat: does zk have transactions of any kind, or could it be a transient thing caused by a timeout of some kind between client and zk?
<hazmat> SpamapS, it has atomic operations we use, it has a limited tx in 3.4.. as for the cause of this issue, i haven't seen anything in the logs that shows me its a bug
<hazmat> versus just acting on executed command
<hazmat> adam_g, how are you tearing down the env?
<hazmat> hmm.. it would be nice to get a dump of
<hazmat> zk
<hazmat> as is i see the unit was destroyed explicitly, and the machine to which it was assigned was removed as well
<hazmat> a service with no units, looks like the original status output
<adam_g> hazmat: i keep the bootstra node in place, and do something like: destroy all services, terminate all machines but the bootstrap, usually sleeping for some seconds between terminate-machine to allow power unit to catch up with requests
<adam_g> hazmat: 'as i see the unit was destroy explicitly'... which unit? the rabbitmq that is missing its machine?
<SpamapS> ahh so remove-unit won't clean up an empty service
<hazmat> adam_g, its missing any  units
<hazmat> SpamapS, yes
<SpamapS> adam_g: does add-unit resolve things?
 * hazmat tries to come up with a remote dump zk script
<hazmat> yeah.. that would verify
<adam_g> SpamapS: i can try next time i hit this...
<hazmat> adam_g, do you have this teardown automated?
<hazmat> adam_g, you should try the charmrunner tools
<hazmat> hmm
<hazmat> actually i guess the snapshot/restore assumes a local provider
<hazmat> easy to fix though
<adam_g> hazmat: yea, teardown is automated. i'd definitely like to combine efforts and standardize on whatever tools you guys are using at some point
<adam_g> FWIW, i'd never seen this issue until recently though, last 1.5 week or so
<hazmat> adam_g, pls keep that env alive for a few minutes more if not already dead
<adam_g> hazmat: still in place
<hazmat> adam_g, i'm almost done with a remote dump zk script
<hazmat> adam_g, the tools are a bit split.. i've got a few useful ones in charmrunner (charm test thingy), and there are some in jujujitsu
<hazmat> SpamapS, btw. nice name
<hazmat> adam_g, here's the script http://paste.ubuntu.com/884162/
<hazmat> you can just python dumpzk.py -f filen.zip -e env_name
<SpamapS> hazmat: name?
<hazmat> SpamapS, the jujujitsu name
<SpamapS> Oh, hah, yeah, I love it. :)
<SpamapS> I do hope others like the idea and want to dump more things into it.
<adam_g> hazmat: people.canonical.com/~agandelman/zk.zip  this is from the current deployment in the same enviromment. the failed unit in that pastebin is gone by now. ill hang onto that script and dump it next time i run into the issue
<hazmat> adam_g, cool
<hazmat> adam_g, till then afaics from looking at status code, the rabbitmq unit was removed explicitly with juju remove-unit, and then the machine removed with juju terminate-machine
<hazmat> adam_g, but that seems odd, since i assume your just using destroy-service and terminate-machine for cleanup
<adam_g> hazmat: thats strange. nowhere in any of the automation we use is remove-unit called
<adam_g> right
<hazmat> anyways.. if you can run that script if it happens again that would be helpful
<adam_g> for sure
<_mup_> Bug #955677 was filed: provisioning agent crashes when deploying to a maas node <juju:New> < https://launchpad.net/bugs/955677 >
<_mup_> Bug #955576 was filed: 'local:' services not started on reboot <juju:New> <juju (Ubuntu):Confirmed> < https://launchpad.net/bugs/955576 >
<_mup_> juju/local-survive-restart r477 committed by kapil.thangavelu@canonical.com
<_mup_> upstartify local provider zk
<jamespage> \o/
<SpamapS> hazmat: my hero! :)
<SpamapS> lxc and the local provider have gotten much better of late
<hazmat> SpamapS, its mostly unchanged outside of the upstartification of some bits
<hazmat> SpamapS, there's still some love needed for the whole failure scenario around lxc-wait
<SpamapS> hazmat: yeah thats being looked at upstream... apparently you can only have one lxc-wait running at a time, and that is the krux of the problem
<SpamapS> crux even .. :-P
<hazmat> SpamapS, well.. we're not properly passing it a bit mask around multiple states, we're just waiting for it to get to started, and on error it never does. but yeah.. the ability to ask it multiple times is also nice
<hazmat> er. concurrently
<SpamapS> hazmat: apparently it listens for a signal from lxc-start on a private socket so only one lxc-wait can be listening at one time
<_mup_> Bug #956183 was filed: Support suspending environment <juju:New> < https://launchpad.net/bugs/956183 >
<SpamapS> hazmat: I'm pretty sure that master-customize also seems to not error on failure of any of its commands.
<adam_g> hazmat: around?
<hazmat> adam_g, yes
<hazmat> headless chicken
<adam_g> same here heh
<SpamapS> maybe try a tournequette to stop the bleeding?
<adam_g> hazmat: so there seems to be some issues ATM /w juju + essex, which i think are security group related.  i was going to see if you had a script/doc around that mimicks the boto calls juju runs in the ec2 provider. i was having trouble recreating using euca2ools. i can extract it all myself if you're bogged down, but figured id check first
<hazmat> un momento
<hazmat> adam_g, http://paste.ubuntu.com/885124/
<hazmat> those are all the calls, but re security groups, there is one for the environment, and then one per machine
<SpamapS> adam_g: one thing.. juju uses txaws, not boto
<hazmat> the environment has a rule to allow for internal group access
<hazmat> and then ones per machine are manipulate to allow for external access as the services with units on a given machine are exposed
<hazmat> the environment group is also used to help identify which machine in the provider juju has responsibility for, ie as a form of tagging
<adam_g> hazmat: thanks, ill check those. id like to be able to recreate the same security groups + rules manually on ec2 and nova. i think theres something screwy going on with rules that reference other groups
<adam_g> great idea>> iptables-save for ec2 security groups
<hazmat> adam_g, yeah.. it was a bit wonky last cycle as well for self-referential security group rules, ie. the metadata looked suspect, i think it worked well because effectively the enforcement wasn't in place.
<jcastro> SpamapS, I've got two incoming charms that need a round 2 review
<jcastro> and m_3 is chilling at some ruby conference
<jcastro> but these will be easy. :)
<SpamapS> cool
<jamespage> jcastro, I can prob pickup some review later tomorrow if that would help?
<jcastro> subway IRC and Alice IRC.
<jcastro> jamespage, actually what would help is you monitoring the incoming queue on occassion
<jcastro> let me get you a link
<jamespage> jcastro, sure
<jamespage> maybe we should try to doing something pilot'ish like we do for Ubuntu dev?
<jcastro> yeah
<jcastro> for now though:
<jcastro> https://bugs.launchpad.net/charms/+bugs?field.tag=new-charm
<jcastro> any of the new ones
<jamespage> like saltmaster or gearman?
<jcastro> and Fix Committed
<jcastro> saltmaster is incomplete, updated
<jcastro> fix committed is when the person was incomplete then wants another review
<jamespage> rightoh
<jamespage> and New is up for first review?
<jcastro> right
<_mup_> juju/refactor-machine-agent r461 committed by jim.baker@canonical.com
<_mup_> Merged trunk & resolved conflict
<_mup_> juju/relation-reference-spec r6 committed by jim.baker@canonical.com
<_mup_> Initial commit
<_mup_> juju/relation-hook-commands-spec r6 committed by jim.baker@canonical.com
<_mup_> Initial commit
<_mup_> juju/relation-info-command-spec r6 committed by jim.baker@canonical.com
<_mup_> Initial commit
<_mup_> Bug #956352 was filed: Enable relation hook commands to work with arbitrary relations. <juju:In Progress by jimbaker> < https://launchpad.net/bugs/956352 >
<_mup_> juju/juju-status-changes-spec r6 committed by jim.baker@canonical.com
<_mup_> Initial commit
<_mup_> Bug #956357 was filed: Fix `juju status` bug when working with multiple relations for a service. <juju:In Progress by jimbaker> < https://launchpad.net/bugs/956357 >
<_mup_> Bug #956372 was filed: Add `relation-info` to list relation ids associated with a service <juju:New> < https://launchpad.net/bugs/956372 >
<_mup_> Bug #956377 was filed: Enable unambiguous reference to relations by using a relation id <juju:In Progress by jimbaker> < https://launchpad.net/bugs/956377 >
<jcastro> SpamapS, this might be more of an m_3 question but
<jcastro> if I want to see a big list of what charms are currently failing tests and that I should be looking to fix I go to .... ?
<SpamapS> hm, why does yaml.dump have to make such ugly yaml?
<SpamapS> jcastro: charmtests.markmims.com is what I've been looknig at
<SpamapS> Looks dead tho
<jcastro> bummer
<SpamapS> jcastro: Its a single charm, so you can also just deploy it.. ;)
<SpamapS> ahh.. defualt_flow_style=False helps
<SpamapS> jcastro: how much would you love a juju-jitsu subcommand called 'setup-environment' that did Q&A to fill in the blanks?
<jcastro> I would have a party
<SpamapS> jcastro: polishing it off now
<jcastro> hey is this in the PPA yet?
<SpamapS> no
<SpamapS> still pretty raw.. so.. bzr branch and play..
<jcastro> oh dude
<jcastro> you put the gource thing in here
<SpamapS> jcastro: yes!
<SpamapS> jcastro: just run it.. you get a gourcer on your default environment. :)
<m_3> jcastro SpamapS charmtests back up
<m_3> hit by the overly-strict type checking across the whole repo
<SpamapS> m_3: did you pull the latest changes? I fixed most of them over the last week.
<m_3> SpamapS: I did... essentially `charm list | grep lp:charms`
<SpamapS> m_3: thats part of why I added the new --fix stuff to 'charm update'
<m_3> I thougth that was for existing local repos.. this wipes andclean branches
<m_3> win 17
<SpamapS> jcastro: there's a little surprise waiting for you on your blog ;)
<m_3> hazmat: lots of progress!  charmtests.markmims.com
<m_3> looks like most of them are completing the graph runs without hanging
<hazmat> m_3, nice
#juju 2012-03-16
<hazmat> m_3, seems like the timeout should be 5m instead of 2m
<m_3> that's a remaininng bug I'll push tomorrow... I adjusted manually
<hazmat> m_3, yeah.. some of those look ok, when it goes to record the state its working already
<hazmat> but the watcher timed out
<m_3> the current set of runs are with the new timeout
<m_3> they seem to be passing
<m_3> one strange hang still... hadoop-mapreduce
<m_3> green is wrong there...an artifact of how I killed it
 * m_3 out... back on later
<jcastro> SpamapS, you are awesome
<_mup_> Bug #956697 was filed: Maas provider can't start second node for deployment (CloudInitError: Incomplete cloud-init: you need to call set_machine_id) <juju:In Progress by julian-edwards> < https://launchpad.net/bugs/956697 >
<marcoceppi> What does "I:" items mean in charm proof? I understand W:, etc but no I:
<bbcmicrocomputer> what's the best way of writing a charm with a generic db relation such that it can support either mysql or postgresql?
<bbcmicrocomputer> obviously, you could have two separate relationships defined, one for each type, but then you lose the meaning of a required db interface
<bbcmicrocomputer> it'd be nice if you could say db interface was required in metadata but then specify which implementers can satisfy that requirement
<jamespage> bbcmicrocomputer, hmm
<jamespage> that would be nice but is not a current feature
<bbcmicrocomputer> I did look at the existing charms but didn't find any that have attempted this.. yet
<jamespage> if you want to support diff database types you will have to specify different relations
<jamespage> I'd pick one to start with and be opinionated....
<bbcmicrocomputer> jamespage: :)
<SpamapS> marcoceppi: I is just informational.
<marcoceppi> Ah, thank you SpamapS
<SpamapS> marcoceppi: short for FYI ;)
<marcoceppi> hum, not sure if this is a bug
<marcoceppi> I added a new environment to my environments.yaml file
<marcoceppi> The name of it is "720", which throws this error: "error: Environments configuration error: /home/marco/.juju/environments.yaml: environments: expected string, got 720"
<marcoceppi> nevermind, I wrapped it in quotes
<marcoceppi> Okay, back to the real problem, when I bootstrap in EC2 machine 0's state is always "not-started"
<marcoceppi> subsequent deploys don't seem to work
<SpamapS> marcoceppi: also you may have problems with the first char not being a number
<SpamapS> marcoceppi: that means the agent isn't starting
<SpamapS> marcoceppi: check the console output
<SpamapS> marcoceppi: what version of juju are you using?
<marcoceppi> SpamapS: this is a boostrap/deployment on an environment that's all chars and not numberic, not sure which juju version since juju --version doesn't work but dpkg says it's : 0.5+bzr470-1juju2~oneiric1
<SpamapS> marcoceppi: ok, and if you ssh to the machine directly, does it have the same juju version?
<marcoceppi> One sec, let me check
<SpamapS> marcoceppi: also do check the console output of the instance. I'd bet it had problems starting the machine agent.
<marcoceppi> SpamapS: System Log from AWS doesn't show anything
<marcoceppi> Not sure how to connect to the machine at this point, AWS Console won't connect because it has no key-pair, juju ssh 0 says "Waiting for machine to come up" and just a straight SSH timesout
<robbiew> bcsaller: ping
<marcoceppi> SpamapS: Did an upgrade on my machine for juju, good to go
<SpamapS> marcoceppi: you could have just ssh'd to the public hostname ;)
<marcoceppi> SpamapS: Tried, it didn't accept my connections
<SpamapS> marcoceppi: did you try euca-get-console-output ? (or ec2-get-console-output)
<marcoceppi> Nope, I didn't know about that
<SpamapS> marcoceppi: very important commands. :)
<_mup_> juju/refactor-machine-agent r462 committed by jim.baker@canonical.com
<_mup_> Fix failing tests due to refactorings in other merges
<bcsaller> robbiew: hey
<robbiew> bcsaller: just a friendly reminder about objectives ;)
<bcsaller> righto
<jcastro> jamespage, thanks for that review, it's excellent
<jamespage> jcastro, no problemo!
<jcastro> especially the tips to the sections of the documentation, that's clutch for new charmers
<jamespage> jcastro, I commented on your sun-jdk/hadoop bug - what do we want todo with the existing hadoop charms for oneiric?
<jcastro> jamespage, mims is at a conference, I was going to wait for his input
<jamespage> jcastro, sounds sensible
<jcastro> that charm was mostly his right?
<jamespage> yeah
<jcastro> I have a sneaking suspicion post-12.04 that no one will care for hadoop on 11.10.
<jcastro> so maybe it'll just start down the road to obscurity
<jamespage> jcastro, well the charm I wrote for 12.04 works with 11.10 as well - backported the packages I did for 11.10 in the hadoop-ubuntu PPA's
<jcastro> ah ok, so maybe just supercede it
<jamespage> maybe
<SpamapS> jamespage: backporting charms to oneiric is a good idea. Though I think we'll do that quite a bit less after April :)
<jamespage> SpamapS, most likely
<jamespage> SpamapS, that was more of a between now and april type plan from my perspective
<jcastro> having one set is better I think.
<jcastro> but hey, I don't want to make claims on someone's baby when they're not around.
<jamespage> lol
<jamespage> I'm sure m_3 is listening...
<jcastro> "hey so welcome back, we threw away the charm you slaved on that was our premier use case for the entire project and stuff. Hope that's ok."
<jcastro> actually, knowing mims he's probably happy that hadoop is now a james page problem and not his, heh
<SpamapS> "I don't always do hadoop. But when I do, I do it with Sun Java". -- James Page
 * m_3 backscroll
<m_3> jcastro: negronjl wrote the hadoop charms... I just got the natty packages building on oneiric
<m_3> jcastro: I'm happy with the new charms/packages... and'd love to see the oneiric cdh pkg do an end-of-life
<jamespage> forget that - I do it with OpenJDK
<m_3> ha!
<jamespage> (its the only option on armhf)
<jcastro> negronjl, mira, how do you feel about just using jamespage's hadoop charms in 11.10?
<m_3> OMG... finally!
<m_3> we've got consistently reproducible full-graph charm-tests.... charmtests.markmims.com
<m_3> hazmat: whoohoo!
<hazmat> m_3, nice!
<SpamapS> you guys are unbelievably amazing
<hazmat> m_3, thats incredibly awesome, nice work
<SpamapS> http://www.youtube.com/watch?v=Vh78T--ZUxY  <-- message from the entire juju community to hazmat and m_3
 * m_3 is in public atm
<SpamapS> m_3: SFW
<SpamapS> in fact, I order you to watch it
<SpamapS> ORDER YOU
<jamespage> lol
<hazmat> SpamapS, got a moment to talk about the namespace-from-env branch?
<jamespage> nice one m_3
<SpamapS> hazmat: I saw your comments. Very frustrating parsing effort in general and I'm more than happy to shorten that code to a few RE's if that will work.. I just didn't give it much thought after I got the tests passing ;)
<hazmat> SpamapS, i'm split out the parsing to a separate function on your branch, it simplifies it a little, i'll  put a diff link on the merge, outside of that if you can finish up the coverage, i'm fine with it
<hazmat> s/i'm/i've
<SpamapS> hazmat: er, do you want to just do a new MP that supersedes imine?
<SpamapS> hazmat: this has gotten a bit out of hand for me.. originally it was a 1 line change.
<hazmat> SpamapS, fair enough, i'll finish it
<SpamapS> hazmat: so at this point its easier for me to move forward with a wrapper than wait for this to pass review
<hazmat> SpamapS, thanks for getting it this far
<_mup_> juju/refactor-machine-agent r463 committed by jim.baker@canonical.com
<_mup_> Expand comment on the reason for machine_id type assertion
<_mup_> juju/robust-test-removed-service-unit r461 committed by jim.baker@canonical.com
<_mup_> Merged upstream
<jcastro> SpamapS, charmstests.markmims.com is back for me now
<SpamapS> jcastro: yeah, ^^
 * marcoceppi checks in on Minecraft charm
<SpamapS> 2012-03-16 16:09:24,226 juju.service_watch:ERROR unit minecraft/3 startup failed install_error
<marcoceppi> SpamapS: Yeah, saw that
<marcoceppi> I really wish I could figure out the local provider, I still can't get it to bootstrap or deploy here
<marcoceppi> SpamapS: have you ever seen this when deploying?  http://paste.ubuntu.com/886618/
<SpamapS> marcoceppi: yes
<SpamapS> marcoceppi: https://bugs.launchpad.net/juju/+bug/952397
<_mup_> Bug #952397: Juju is forcing *ALL* charms in a repo to be perfect to be able to deploy *any* <juju:In Progress by hazmat> < https://launchpad.net/bugs/952397 >
<jcastro> jamespage, would you consider the etherpad-lite charm complete enough to be demoable?
<SpamapS> marcoceppi: you need to fix your charms
<marcoceppi> ah, thanks
<SpamapS> marcoceppi: if you have the latest charm-tools you can do 'charm update --fix path/to/a/dir' and it will pull all fixes in
<marcoceppi> SpamapS: I do, but all the repos are setup against the old charm/* lp branches
<jcastro> hey does any other charm other than phpmyadmin have a "get from upstream instead" option?
<m_3> jcastro: jenkins does
<jcastro> ta
<m_3> rails, node, django do too...
<m_3> but they're not in the store except for node
<jcastro> node does?
<jamespage> jcastro, no - its broken
 * m_3 looking
<jcastro> yeah I just need an example
<jcastro> I'm working on my companion blog post to the store landing
<jcastro> and I want to show an example of "don't want what's in the archive? Fine, here you go"
<m_3> jcastro: yeah, node is using the pacakge... I thought I had npm updateing the node version, but it's only updating (node) package deps... not node itself
<SpamapS> marcoceppi: --fix fixes that :)
<jcastro> yeah I am waiting for the node ppa guy to get back from SXSW to talk to him about it
<jcastro> hopefully he'll dig it
<m_3> cool
<jcastro> node is the perfect example of something that we can rock by having an up to date charm
<jcastro> but do we have one that works now?
<m_3> oh yeah
<m_3> yeah
<m_3> I used it in the mongodb demo
<marcoceppi> phpmaydmin works
<m_3> node talks to a mongodb replset
<marcoceppi> but it's not a very fun charm
<jcastro> marcoceppi, yeah I am hoping for something sexy and cloudy
<jcastro> not to take away from your charm of course. :)
<marcoceppi> *nod*
<marcoceppi> naw, it's PMA, it's neither sexy or cloudy :)
<m_3> jcastro: http://paste.ubuntu.com/886640/
<jcastro> ok which part there does the upgraded node?
<jcastro> do you just have that local?
<m_3> oops, sorry that was unclear... node just uses the pacakge only... I was wrong
<jcastro> aha!
<jcastro> hey so I see jamespage uses "lts" and "trunk" to differentiate his versions
<jcastro> but marco does it differently in phpmyadmin
<m_3> the node guy should update it to get npm to update node itself to the version the app actually depends on
<jcastro> we should probably best practice one
<m_3> yup
<jamespage> jcastro, those are quite specific to upstream naming
<jcastro> m_3, yea, that's what I was thinking
<jamespage> they have LTS and trunk releases
<jcastro> jamespage, ah ok, so we'll likely run into service-specific conventions then
<jcastro> but for a jenkins person that totally makes sense then
<jamespage> jcastro, take a look at the zookeeper charm
<m_3> although it's really pretty obvious.... might not need to be so std
<jamespage> that uses distro OR some PPA options
<jcastro> m_3, indeed, I am overthinking
<jcastro> jamespage, brilliant, that's exactly what I need
<SpamapS> actually for PPA's ..
<SpamapS> we really need to be able to override that for system policy. I think a subordinate would be able to do that.
<jcastro> jamespage, ok so ... you can do dev, testing, or stable, what does the command look like
<jcastro> like, do I set a config or ... ?
<jamespage> set a config
<jamespage> juju deploy --config config.yaml --reposistory ....
<jcastro>     juju set config source=dev
<jamespage> typically my charms don't support switching
<jamespage> i.e. that information is use in the install hook only
<jcastro> switching is a bit too sexy and scary for now I think
<jamespage> its one more thing to test....
<jcastro> I think just an install switch is still way awesomer than what people have to do now
<jamespage> jcastro, I'm going to switch the etherpad-lite charm to use chris lea's PPA for node/npm
<jcastro> jamespage, I sent chris a mail
<jamespage> trying to make it work from upstream git for npm is to hard and unreliable
<jcastro> I am going to try to work with him on convincing him about the node charm
<jcastro> everyone uses his PPA for stuff
<jcastro> we might as well make it a nice option in the node charm
<jcastro> that would be slick.
<jamespage> jcastro, arggh
<m_3> jcastro: I think the node one should be done like rails... the app specifies which version of node/rails it depends on thru package.json or Gemfile
<jamespage> etherpad-lite won't run on 0.6 node js
 * jamespage put this down for the week
<jamespage> I need a beer
<jamespage> have a nice weekend folks
<jcastro> you've had a good week james, chill!
<jcastro> you've earned it!
<m_3> jamespage: I can help clean that up next week
<m_3> night!
<jcastro> m_3, are you at a conference still? I'd like to start running my blog post past you guys
<SpamapS> ninjix: welcome :)
<ninjix> hey
<ninjix> I'm trying to do some juju with virtualized servers
<SpamapS> ninjix: excellent. That should work. :)
<ninjix> running 11.10 orchestra and juju
<ninjix> getting a cannot connect error
<ninjix> when I run juju status
<ninjix> virtual machines were PXE installed with Orchestra
<marcoceppi> Uh, juju local is prompting for a password when I try to juju ssh
<SpamapS> ninjix: backup.. did you run all the steps?
<SpamapS> marcoceppi: ssh password or sudo password?
<marcoceppi> SSH
<SpamapS> marcoceppi: actually it would have to be ssh password
<marcoceppi> ubuntu@localhost's password:
<SpamapS> marcoceppi: most likely there was a problem during master-customize
<SpamapS> marcoceppi: though 'localhost' sounds wrong
<ninjix> I haven't manually copied any ssh keys
<ninjix> I thought the juju profile was doing that
<SpamapS> ninjix: don't get confused, I'm talking to marco about ssh
<ninjix> ;)
<SpamapS> ninjix: for orchestra, the steps should be: 1) add VMs to cobbler (orchestra-provisioning-server) including adding them to the available mgmt class. Did you do that?
<ninjix> SpamapS: I followed the Dustin's blog howto
<SpamapS> ninjix: Ok, so you did 'bootstrap' and 'deploy' already?
<marcoceppi> Found out the problem with the Minecraft charm, the "store" doesn't have the latest code.
<marcoceppi> Scratch that
<marcoceppi> talking out of my butt
<SpamapS> marcoceppi: makes sense because what you just said stinks ;)
<SpamapS> ninjix: I'd recommend getting juju from the juju PPA. The version in 11.10 is fairly buggy.
<ninjix> SpamapS: I added the mgmt classes but only after I ran into the "no available" error
<marcoceppi> SpamapS: did you actually merge the changes I had in to the main charm?
<SpamapS> marcoceppi:  not sure
<marcoceppi> nbd if you didn't I can merge it
<marcoceppi> but the code in charms/minecraft doesn't have my changes
<SpamapS> marcoceppi: usually the proposer, not the approver, merges.
<ninjix> SpamapS: do the orchestra-juju-available need to be added before the cobbler install runs?
<marcoceppi> SpamapS: I'll keep that in mind, thanks
<SpamapS> marcoceppi: the merge proposal would be 'Merged' if the code was merged. :)
<marcoceppi> <3 so foolish of me
<SpamapS> ninjix: definitely
<ninjix> ok
<ninjix> SpamapS: do I need both *acquired and *available enabled?
<SpamapS> ninjix: no
<SpamapS> ninjix: only available
<SpamapS> ninjix: the sequence is to set them to 'available', then 'bootstrap', then reboot the box (so it installs w/ juju)
<SpamapS> ninjix: can you paste the HOWTO url you're using? I want to make sure thats what it says. :)
<ninjix> https://wiki.ubuntu.com/ServerTeam/OrchestraJuju
<ninjix> that wiki page is missing the default-series
<SpamapS> ninjix: so right after the 'bootstrap' step, you should reboot the server that was acquired.
<marcoceppi> SpamapS: thanks, minecraft is updated now \o/
<SpamapS> ninjix: I just added some clarifying notes to that in the wiki page
<SpamapS> marcoceppi: been a while since I lost myself in minecraft.. might have to go digging for lunch.. :)
<SpamapS> marcoceppi: favorite thing to do: dig a ridiculously deep and long tunnel, then dig back up.. then find the ridiculously tall tower I built at my old base. ;)
<SpamapS> I'm always a lot closer than I think I should be. :-P
<marcoceppi> yeah, that's what my first base was, a giant pillar with torches so I could find it from afar :)
<SpamapS> I can't really get into playing on big long living multiplayer servers
<SpamapS> Every time I do.. I come back and all my s*** is gone.
<SpamapS> even when I hide it under sand. ;)
<ninjix> SpamapS: restarted the kvm and it was reinstalled by cobbler
<SpamapS> ninjix: ok, it should now have zookeeper running, and 'juju status' should work
<ninjix> just saw the zookeeper get installed on the kvm console's echo
<ninjix> SpamapS: ahhh... just checked the firewall and a see some blocked traffic between the orchestra kvm's VLAN and the test machines
<ninjix> SpamapS: juju status working now
<ninjix> SpamapS: thank you
<ninjix> going to switch over to the ppa juju now
<SpamapS> ninjix: you're not the first to get confused by that. Hopefully the wiki update will help.
<ninjix> SpamapS: it did
<SpamapS> ninjix: I added default-series too
<ninjix> good move
<ninjix> can juju do a master-master mysql relationship?
<ninjix> i see in some references to slave instances
<SpamapS> ninjix: yes it can, but there's no charm for that yet
<SpamapS> ninjix: I'd like to add it to the mysql charm at some point
<ninjix> nice.  Let me wrap my mind around these charms and maybe I can help out
<ninjix> looks like I'm going need to write a Proxmox API extension for provisioning and controlling the kvm
<ninjix> is that what the "virtualization" settings are for in the Cobbler profile?
<SpamapS> ninjix: dunno. I believe cobbler has support for libvirt and/or kvm
<SpamapS> ninjix: you might want to consider trying the 'local' provider which does things in LXC containers rather than on VMs controlled by cobbler.
<ninjix> SpamapS: thanks but I am working on project to leverage our mucho macho server nodes
<ninjix> we've been running proxmox for several years now
<SpamapS> ninjix: ah cool :)
<ninjix> just saw the first mysql charmed kvm get provisioned
<SpamapS> ninjix: what exactly is proxmox? I only see a mail gateway at proxmox.com
<ninjix> http://pve.proxmox.com/wiki/Category:Proxmox_VE_2.0
<ninjix> SpamapS: mysql install is still pending
<SpamapS> ninjix: yeah, we've been looking at ways to allow you to install all of the nodes in parallel before you know what you want them to do. ;)
<SpamapS> ninjix: since the install takes a few minutes. :-P
<ninjix> SpamapS: logged into the provisioned mysql charmed instance
<ninjix> SpamapS: can see mysql there but the juju status still shows state: not-started
<ninjix> SpamapS: kvm is idling now
<SpamapS> ninjix: interesting. So is there a juju agent running?
<SpamapS> ninjix: because it should have started up, and called back in to the zookeeper node.
<ninjix> SpamapS: I see it running
<ninjix> and it installed mysql
<SpamapS> ninjix: ok, can you maybe pastebin your 'juju status' ?
<SpamapS> ninjix: because that state should be 'running' or 'started' or something
<ninjix> http://pastebin.com/Tz5UCMx9
<ninjix> SpamapS: how do you restart the juju agent
<ninjix> don't see juju in the /etc/init
<ninjix> SpamapS: I see an error in the machine-agent.log
<ninjix> SpamapS: but I am not sure if it occurred before I fixed the firewall rules
<SpamapS> ninjix: if you're not on the PPA, you can't restart the agent
<SpamapS> ninjix: the one that shipped in 11.10 just ran it as part of the first boot.. newer versions ship an upstart job for each agent
<SpamapS> ninjix: dpkg -l juju , what does it show?
<ninjix> SpamapS:  0.5+bzr398-0ubuntu
<ninjix> that's from the mysql instance
<ninjix> the orchestra machine is now running 0.5+bzr481-1juju3~oneiric
<jcastro> SpamapS, hazmat, m_3, I have some stuff to run by you guys
<jcastro> if you're feeling for a Friday afternoon hangout
<SpamapS> ninjix: yeah thats the old distro version, and you can't restart the agent (and it dies a lot if your servers get overloaded because the timeouts aren't handled right)
<jcastro> SpamapS, oh, kapil and ben are already hanging out
<ninjix> SpamapS: so... I should reboot the mysql instance?
<ninjix> SpamapS: or can I bang on its pid?
<_mup_> Bug #956000 was filed: 'juju' with no arguments gives confusing message <juju:Confirmed> <juju (Ubuntu):New> < https://launchpad.net/bugs/956000 >
<ninjix> SpamapS: killed the juju pid and restarted it with the same command line args
<ninjix> now I see the error
<jcastro> SpamapS, invite sent!
<ninjix> getting "No zookeeper connection configured." along with python trace
<m_3> jcastro: sorry, no can do atm
<ninjix> does that mean it's having trouble talking to the bootstrap?
<SpamapS> ninjix: it takes stuff from the environment too
<ninjix> SpamapS: ok
<ninjix> going to terminate this run and try again
<SpamapS> ninjix: definitely get on the PPA version, much better
<bkerensa> jamespage: I just pushed a new version of subway charm...  I have not yet had a chance to deploy myself since I need to setup LXC and I am writing this charm as a favor of sorts ;p
<ninjix> SpamapS: do I need to change a cobbler snippet to get the instances to use PPA juju?
<bkerensa> jcastro: you did say --repository needs to point to my charm yes?
<SpamapS> ninjix: no
<SpamapS> ninjix: juju pushes the commands to deploy itself every time you bootstrap or deploy
<koolhead17|away> hi all
<bkerensa> jcastro: http://paste.ubuntu.com/886877/ :(
<jcastro> you want
<jcastro> juju deploy --repository= . subway local:subway
<jcastro> but you need to be in ~Work/Development
<bkerensa> jcastro: juju: error: unrecognized arguments: local:subway
<bkerensa> from ~Work/Development
<jcastro> one sec
<jcastro> on a call
<ninjix> SpamapS: got a little further with this run
<ninjix> now I see a "could not internally obtain zookeeper handle" error message
<SpamapS> ninjix: hrm
<SpamapS> ninjix: where are you seeing that?
<jcastro> hmm, why would  local:subway not work?
<jcastro> clint?
<SpamapS> jcastro: because --repository isn't pointing at something witht default-series/subway in it?
<SpamapS> bkerensa: juju deploy --repository=~/Work/Development local:subway
<SpamapS> actually
<SpamapS> bkerensa: juju deploy --repository ~/Work/Development local:subway
<SpamapS> no =
<SpamapS> you need to let the shell expand ~
 * SpamapS goes to get lunch
<ninjix> SpamapS: found it. just had to read a little further up in the trace
<ninjix> SpamapS: DNS strikes again
<bkerensa> SpamapS: same error
<bkerensa> =/
<bkerensa> jcastro: no idea why its failwhaling
<ninjix> this is turning into a very productive afternoon. Thanks for your help, SpamapS.
<bkerensa> indeed
<jcastro> nor me
<jcastro> hey, I'm going to finish off my charm and then just test yours bkerensa
<bkerensa> jcastro: sure :)
<jcastro> you're not the first person who can't get it working locally
<bkerensa> feel free to propose any fixes to its bad state
<bkerensa> :D
<jcastro> but no worries, team effort.
<jcastro> SpamapS, znc incoming!
<SpamapS> bkerensa: can you do ls -l ~/Work/Development | pastebinit ?
<bkerensa> SpamapS: http://paste.ubuntu.com/886965/
<SpamapS> bkerensa: and ls -l ~/Work/Development/oneiric ?
<bkerensa> SpamapS: http://paste.ubuntu.com/887000/
<SpamapS> bkerensa: they look identical.. that can't be right
<SpamapS> bkerensa: did you forget to add /oneiric ?
<bkerensa> SpamapS: add it where?
<bkerensa> it exists
<bkerensa> ~/Work/Development/oneiric/subway is where the charm resides
<SpamapS> bkerensa: I was asking for ls -l ~/Work/Development/oneiric
<SpamapS> bkerensa: also is the name set to 'subway' in metadata.yaml .. that can mess it up too
<bkerensa> SpamapS: http://paste.ubuntu.com/887014/ ^
<SpamapS> bkerensa: ok cool, and 'cat ~/Work/Development/oneiric/subway/metadata.yaml' ?
<SpamapS> bkerensa: you are almost as good as sshd at running my commands btw.. though I think the connection has a bit more latency than I'd like. ;)
<bkerensa> SpamapS: http://paste.ubuntu.com/887015/
<SpamapS> bkerensa: and in environments.yaml, do you have 'default-series: oneiric' ?
<bkerensa> SpamapS: where is this located?
<SpamapS> bkerensa: ~/.juju/environments.yaml
<SpamapS> bkerensa: you wouldn't have been able to bootstrap without that
<bkerensa> SpamapS: http://paste.ubuntu.com/887026/
<SpamapS> bkerensa: interesting. You have two 'environments' sections. You should only have one.
<SpamapS> bkerensa: if that fixes it, we have a bug to fix :)
<bkerensa> SpamapS: Nope I removed the EC2 copy and tried again
<bkerensa> http://paste.ubuntu.com/887037/
<SpamapS> bkerensa: AHA!
<SpamapS> provides: subway: interface: http
<SpamapS> well, irc ate that
<SpamapS> bkerensa: interface needs to be indented
<SpamapS> what a terrible error message.
<SpamapS> 2012-03-16 15:31:02,246 WARNING Charm 'subway' has an error: MetaDataError('Bad data in charm info: /home/bkerensa/Work/Development/oneiric/subway/metadata.yaml: provides.subway: expected unicode or utf-8 string, got None',) Bad data in charm info: /home/bkerensa/Work/Development/oneiric/subway/metadata.yaml: provides.subway: expected unicode or utf-8 string, got None
<SpamapS> bkerensa: I'm opening a bug to make charm validation more friendly. :)
<SpamapS> actually bug 899433 is already open :)
<_mup_> Bug #899433: YAML errors in charms should be obvious to users <juju:Invalid> < https://launchpad.net/bugs/899433 >
<SpamapS> hm no
<SpamapS> That wasn't even logging an error
<SpamapS> bkerensa: so, yeah, indent interface: http one more level, and it should work fine
<_mup_> Bug #957498 was filed: Metadata errors should be user friendly <juju:Confirmed> < https://launchpad.net/bugs/957498 >
<bkerensa> SpamapS: That fixed it
<bkerensa> jcastro: My charm works fully now
<bkerensa> I just deployed it succesfully so its working fine here and I just pushed the final changes
<SpamapS> bkerensa: *woot*
<SpamapS> bkerensa: whats your new-charm tagged bug #? I'll review it first since you've been such a good sport working this out. :-D
<bkerensa> SpamapS: Bug #944246
<_mup_> Bug #944246: Charm Needed: Subway IRC client/server <new-charm> <Juju Charms Collection:Fix Committed by bkerensa> < https://launchpad.net/bugs/944246 >
<SpamapS> bkerensa: ok, I have one other thing blocking me.. then I'll start review in about 30min
<bkerensa> SpamapS: no problem :) I have to go run errands I just wanted to sort this for review before I went out and did this stuff
<bkerensa> :D
<_mup_> Bug #929187 was filed: juju.control.tests.test_remove_unit.ControlRemoveUnitTest.test_zookeeper_logging_default is non-deterministic and should be removed <juju:In Progress> < https://launchpad.net/bugs/929187 >
#juju 2012-03-17
<_mup_> Bug #957620 was filed: A spec for how to cleanly stop agents. <juju:In Progress by hazmat> < https://launchpad.net/bugs/957620 >
<_mup_> Bug #957621 was filed: A spec for how to cleanly stop agents. <juju:In Progress by hazmat> < https://launchpad.net/bugs/957621 >
<hazmat> argh.. lbox
<hazmat> niemeyer, ^
<hazmat> niemeyer, lbox should use the closest open milestone and shouldn't reduplicate a bug. ie mp before bug
 * hazmat files a bug
<hazmat> it originally had the branch attached to both bugs
<_mup_> Bug #957675 was filed: juju debug-hooks doesn't use exit code as hook exit code <juju:New> < https://launchpad.net/bugs/957675 >
<m_3> q
<koolhead17|away> m_3, we can still see you :P
<m_3> ha!
<m_3> just working through some config issues
<_mup_> Bug #957906 was filed: Environment settings explicitly set. <juju:In Progress by hazmat> < https://launchpad.net/bugs/957906 >
<_mup_> juju/hook-alias-expansion-redux r472 committed by kapil.thangavelu@canonical.com
<_mup_> address review comments
<hazmat> whoops.. wrong lbox subcommand
<hazmat> hmm... interesting lbox doesn't seem to invoke the post commit hooks, probably because of the temp dir usage defeats a locations setup
<_mup_> juju/repository-broken-charms r477 committed by kapil.thangavelu@canonical.com
<_mup_> rearrange charm exception hierarchy, charmnotfound is not a charm structural error, add catch all handler to repository for unexpected errors
<akgraner> hey all - so is juju always written lower case unless it starts a sentence?
<jcastro> yes
<jcastro> Juju or juju, never JuJu though
<akgraner> ok - I'll leave it as Juju then :-)
<akgraner> thanks jcastro
<jcastro> jamespage, we using jetty for anyting you've charmed?
<bkerensa> jcastro or SpamapS: If you would like to have a look at Bug #944246 when you get a chance and grab the more frosty copy of my branch and have a look :D
<bkerensa> thanks
<_mup_> Bug #944246: Charm Needed: Subway IRC client/server <new-charm> <Juju Charms Collection:Fix Committed by bkerensa> < https://launchpad.net/bugs/944246 >
<jcastro> I am frosty now!
<jcastro> looking!
<jcastro> bkerensa, hmm, lxc problems, I need to sort them
<jcastro> bkerensa, oh it's working, just getting it all started took a while
<bkerensa> jcastro: So its working nice for you?
<jcastro> still waiting for it to come up
<jcastro> (it has to fetch the OS and stuff, clean container)
<SpamapS> bkerensa: there's something else broken in the charm. I got a failure in lxc because 'make' wasn't available.
<_mup_> juju/ns-from-env r476 committed by kapil.thangavelu@canonical.com
<_mup_> merge trunk
<_mup_> juju/ns-from-env r477 committed by kapil.thangavelu@canonical.com
<_mup_> pep8 and minor refactor
<jcastro> SpamapS, my LXC isn't working at all
<jcastro> I blame you
<jcastro> SpamapS, do I still need to blow away something in /var/lib or whatever on occasion?
<SpamapS> jcastro: the most common problem is precise mirrors being inconsistent with 'hash sum mismatch'
<SpamapS> jcastro: check data-dir/units/master-customize.log
<SpamapS> jcastro: that process needs to detect errors but does not.. :p
<SpamapS> jcastro: if you see any problems reported in that log, destroy-environment and bootstrap again should fix it
<SpamapS> jcastro: if you still have problems.. try killing /var/cache/lxc/*
<hazmat> hmm..
<hazmat> i'm currently working on that lxc-wait issue, but its a bit time consuming
<hazmat> jcastro, if you have any logs those would be helfpul
<SpamapS> hazmat: the problem I've hit twice has been apt-get failing. Its not detected during master-customize.
<jcastro> SpamapS, doing anything right now?
<jcastro> I have an idea
<jcastro> hazmat, hey so
<jcastro> how do you do shared environments in juju?
<jcastro> say marco and I wanted to share managing an environment?
<bkerensa> SpamapS: Make isnt available by default?
<bkerensa> =/
<bkerensa> jcastro: ^ what? Your the juju guy =s
<jcastro> much to learn about deploying in a way I can share with someone else
<hazmat> jcastro, create a new key and share along with the environment.yaml snippet
<hazmat> ie. ssh key explicitly specified by content in the environment.yaml snippet is probably the most self-contained way
<jcastro> hazmat, ok so from looking at how  mims set ours up for another project
<jcastro> he just put all our ssh keys in authorized-keys:
<jcastro> and then we just share the snippet right?
<hazmat> jcastro, cool, that sounds nice as well, yes
<jcastro> hazmat, since OMG guy can't set up wordpress I'm going to do it in juju for him
<jcastro> hazmat, and that worked perfectly.
<jcastro> man, awesome
<_mup_> juju/force-upgrade r464 committed by kapil.thangavelu@canonical.com
<_mup_> per review only raise error if flags differ on upgrade, tolerate empty upgrade nodes (old format)
<jcastro> hazmat, still there?
<hazmat> jcastro, yup
<jcastro> nm found it, just looking for where juju puts the mysql root pw
<jcastro> we've got OMGs data and we've set up wordpress
<marcoceppi> hazmat: I've added a relation from WP -> HA, but HA's URL is showing the apache page
<jcastro> but the haproxy isn't doing what we think it should be doing
<marcoceppi> If I go directly to the WP URL it shows the WP install
<hazmat> marcoceppi, odd, is it pointing at the right address? it might be the wp only sets itself up for serving off the public address of the unit, ha is going to do the request via its private networking address
<marcoceppi> Ah, so I'll need to mod the apache conf to accept connections from all then?
<marcoceppi> That makes a lot of sense actually
<jcastro> did the charm change recently?
<jcastro> I thought this worked ootb
<hazmat> jcastro, it would if the proxy is using the public address, or the apache is setup for that vhost on both public/private addresses
<hazmat> jcastro, in particular it wouldn't be an issue anywhere public and private address are the same, but it would matter for ec2
<hazmat> or openstack
<jcastro> hazmat, ah so that would be why when I've demoed it on my laptop it just worked
<jcastro> marcoceppi, d0od is here ^
<marcoceppi> d0od: o/
<d0od> Howdy!
<marcoceppi> Hopefully we can put something in place for you shortly d0od
<jcastro> ok so picking an m1.small won't work
<d0od> marcoceppi: Very much appreciated
<jcastro> going to have to go large
<marcoceppi> hazmat: is there any way to specify a specific unit's size? or is that still a global juju config?
<hazmat> marcoceppi, till next week yes
<jcastro> hah man
<jcastro> nice timing
<marcoceppi> hazmat: how well does juju take to rebooting units outside of Juju?
<jcastro> we're running oneiric with origin:PPA
<hazmat> marcoceppi, which provider?
<jcastro> ec2
<hazmat> marcoceppi, jcastro it should work in theory, i haven't tested in practice though
<marcoceppi> jcastro: I'll bootstrap a quick juju setup on my ec2 and test
<jcastro> ok
<hazmat> everything running on the machine is upstartified
<jcastro> hazmat, so basically I thought m1.smalls would be enough
<jcastro> but we did the redirect and the load on the wordpress node was like 98
<hazmat> jcastro, huh.. interesting
<hazmat> that would be a nice jujitsu tool
<hazmat> grow/shrink a unit
 * marcoceppi *nods furiously*
<jcastro> juju add-unit --type=m1.xboxlarge wordpress
<jcastro> is what I want
#juju 2012-03-18
<hazmat> jcastro, there's one more branch before that works for ec2, i'm going to try and get a review on it today, but i've perused it and looks pretty good already
<hazmat> you can define the constraints on the service or unit level
<jcastro> that is awesome because we just ran into this problem, so now I can see why we would need it in real practice
<jcastro> d0od, we severely underestimated how huge OMG is
<jcastro> I'm going to relaunch it with larges
<jcastro> marcoceppi, how fast is the ec2->ec2 transfer?
<marcoceppi> jcastro: probably 10-15Mb/s
<marcoceppi> The meat of the OMG Site is about 2GB in size (images, plugins, themes, etc)
<marcoceppi> Sorry, not 10-15, it's currently tracking at 60Mbps
<marcoceppi> jcastro: Tear it down, everything is moved off
<jcastro> on it
<marcoceppi> If you want, you can use the patched branch that fixes the haproxy issue
<jcastro> link me to it pls?
<marcoceppi> lp:~marcoceppi/charms/oneiric/wordpress/haproxy-patch
<jcastro> ta
<jcastro> hey so the wife wants ice cream
<jcastro> when I launch these
<marcoceppi> I'll wait for the team to review, it's a minor change but I'm not sure if there's a *better* way to do it
<jcastro> and get you in them can you drive for a while?
<jcastro> I shouldn't be longer than 30
<marcoceppi> yeah, no problem
<marcoceppi> Launch and I can relate, move files, setup, etc
<jcastro> bootstrapping
<marcoceppi> d0od: I saw that you have cdn.omgubuntu.co.uk setup, but it looks like you're pointing it to the same server as the main site
<marcoceppi> Do you have a CDN for OMG?
<jcastro> man, waiting for bootstrap on ec2 vs. lxc is not a fun time
<marcoceppi> I know, *keeps pinging status*
<d0od> The CDN was something our then web admin set up; i really don't know more than that
<d0od> shocking, I know ;)
<marcoceppi> ha, no problem! just checking
<marcoceppi> Do you have access to the DNS for the domain?
<jcastro> ok deployed
<jcastro> marcoceppi, not started yet
<d0od> marcoceppi: I do
<marcoceppi> jcastro: it looks like they're finally coming up
<jcastro> mysql is up
<jcastro> just waiting on wp
<jcastro> and ... up
<jcastro> go.
<jcastro> ok lmk when you have access to stuff, and then I'll pop out and be back in 30 or so
<jcastro> No EC2 Instances selected.
<jcastro> Select an instance above
<jcastro> mispaste, sorry
<marcoceppi> jcastro: I'm good! Enjoy
<jcastro> bbiab!
<marcoceppi> Transfering the Dabatase dump back over
<marcoceppi> Okay, database is on the server, importing. WordPress is setup, haproxy in place, and the OMG content is being transferred over
<d0od> :D
<marcoceppi> Once the content is extracted it'll be a quick skip and hop to a living site
<d0od> I can't thank you enough for doing this :)
<marcoceppi> No problem! I hope to have this done before jcastro gets back
<marcoceppi> Database imported, content synced. Moving all the images, plugins, and theme in to place
<marcoceppi> Okay, d0od, it's not pretty but: http://ec2-23-20-126-44.compute-1.amazonaws.com/ the post links don't work yet either. The images and layout will be fixed when we "redirect" the domain
<marcoceppi> If you open your browser in to porno mode, http://ec2-23-20-126-44.compute-1.amazonaws.com/ that should look like OMG Ubuntu!
<marcoceppi> Images won't all be working yet, because of the domain name
<marcoceppi> Just need to get the seo friendly URLs setup
<jcastro> marcoceppi, back, wow that was fast!
<marcoceppi> jcastro: slow poke
<marcoceppi> :)
<marcoceppi> It's always faster the second time around, when you know what to do
<jcastro> heh
<marcoceppi> tellin' ya, it's like 10 mins away from being a charm
<jcastro> hey so how's the IO on the larges? Much better?
<marcoceppi> smoooooooooth
<jcastro> nice
<marcoceppi> the old server was an 8core beast
<jcastro> ok so what do we need to do then ... just the redirect?
<marcoceppi> one more thing
<marcoceppi> post links aren't working
<marcoceppi> but I think that's a mis-behaving plugin
<jcastro> yeah we should have looked at the hw it was on before deciding on smalls
 * marcoceppi nods sadly
<jcastro> 1 large for a bootstrap node, heh
<marcoceppi> well, Zookeeper should be happy
<marcoceppi> So, I'm not sure how to fix the whole post not working, I'm going to try to create myself an account
<jcastro> d0od, ok get ready
 * d0od readies self
<jcastro> hazmat, any idea how we can move the bootstrap node and haproxy to smalls?
<jcastro> or is it like "wait a week and redeploy"?
<hazmat> jcastro, the bootstrap node isn't really resizable without additional work
<jcastro> ok
<jcastro> marcoceppi, about ready?
<hazmat> the whole notion of resizing isn't really supported.. but if you want to try.. i'd first try stopping and restarting a non bootstrap node, check if it comes up okay.. then snapshot, and boot the snapshot as a new instance, hmm.. i don't think its going to work.
<marcoceppi> yeah, just need to patch up the wordpress install so it functions 100%
<hazmat> its got to update the zk data with the new instance id or juju will terminate it as an unknown (if it shares the environment group, which it needs to for net security)
<jcastro> ok so I think it's best to wait until the ability to specify a size per node lands
<jcastro> then just redeploy?
<hazmat> jcastro, yeah
<marcoceppi> jcastro: founda  few more things that need to be added to the wp charm, php-mail and sendmail are not installed
<jcastro> .... adding to the doc
<jcastro> d0od, ok wordpress problem, I texted SpamapS, he's on his way
<jcastro> just this one thing left to fix
<jcastro> marcoceppi, is there a way to turn off plugins from a config file or something?
<SpamapS> jcastro: use /mnt and backup/replicate aggressively ;)
<SpamapS> jcastro: /mnt is the instance storage on an ebs root instance
<marcoceppi> jcastro: I'm in the admin panel
<SpamapS> its huge, and heavily outperforms EBS
<jcastro> ... and we ran out of space on EBS anyway. :)
<jcastro> so he moved it
<marcoceppi> SpamapS: do all units have access to that same /mnt?
<SpamapS> marcoceppi: no definitely not
<marcoceppi> damn, okay
<SpamapS> that is local to the instance
<jcastro> that would be too easy
<jcastro> marcoceppi, hey so how many plugins are in there?
<jcastro> maybe we can shut them off
<jcastro> and then turn them on one by one?
<marcoceppi> 29 active
<jcastro> hah, seriously
<SpamapS> marcoceppi: whats the trouble?
<SpamapS> shared image upload?
<marcoceppi> well, 29 of 45 :)
<SpamapS> simplest thing would be to use the wordpress S3 plugin.
<SpamapS> which I used long before I had my blog in EC2 :)
<marcoceppi> FIXED
<marcoceppi> FIRE MISSILES
<SpamapS> but I am le tired
<jcastro> url please?
<marcoceppi> http://www.omgubuntu.co.uk/2012/03/instant-messaging-comes-to-thunderbird-13-speed-dial-to-firefox-13/
<jcastro> db error
<jcastro> there we go
<jcastro> the tbird image is broken though
<marcoceppi> file isn't on the server
<jcastro> marcoceppi, your hackergotchi is showing up instead of joey, heh
<marcoceppi> jcastro: yeah, refresh and I should be gone
<marcoceppi> nvm, I'm still there, Page is cached
<jcastro> still getting db errors
<jcastro> is the mysql box getting thrashed?
<SpamapS> the tuning on the default mysql is really low scale
<SpamapS> There are some big knobs for bumping it up
<marcoceppi> jcastro: connections are maxed out
<marcoceppi> turning big knobs
<SpamapS> I believe that is one of them
<SpamapS> juju set max-connections=500 should work
<jcastro> marcoceppi, you comfortable turning them up or want clint to have a look?
<marcoceppi> Normal circumstances I would say STAND BACK, but Clint I hear you're like a SQL wizard
<marcoceppi> I can add your key to the db to take a look and work some magic
<jcastro> cpu looks maxed on the wp one too according to the Aws meter
<marcoceppi> jcastro: I'm going to drop a fix for that in a min
<marcoceppi> see if we can't keep AWS from getting too pissed
<SpamapS> marcoceppi: I do have some mysql scaling experience yes. :)
<jcastro> yes, let's do this
<SpamapS> marcoceppi: probably want to bump dataset-size > 1G unless the database is in fact ~= 1G
<marcoceppi> db is about 1.2gb
<SpamapS> nice ok
<marcoceppi> SpamapS: PM'd you the server address
<marcoceppi> I haven't done much, but I was planning to move MySQL to a tmpdisk
<SpamapS> marcoceppi: tmpdisk? are we replicating or backing up aggressively at all?
<marcoceppi> right now it's just one instance
<SpamapS> ok
<SpamapS> What I'd recommend is that we spin up another env on t1.micro's in a different region...
<SpamapS> and manually setup replication to that.
<SpamapS> Any chance we started with t1.micro's here? Because they have the advantage of being able to be rebooted into any other instance type
<jcastro> we started with smalls
<SpamapS> jcastro: darn.
<jcastro> ok so we need more instances?
<SpamapS> wow... MyISAM ..
<jcastro> We can't tune the existing one?
<marcoceppi> SpamapS: ah, I converted the first time around, hadn't done it for this time around
<SpamapS> jcastro: no, but thats a way around the "all larges" problem
<marcoceppi> all but a few tables can be moved to InnoDB
<SpamapS> marcoceppi: was there a mysqldump ?
<SpamapS> because the default table type is innodb
<marcoceppi> SpamapS:  yeah it's in /usr/src
<marcoceppi> Dump had them as MyISAM
<SpamapS> Because MyISAM will have table locks which will make comment traffic suck ass
<SpamapS> Probably means the original site had MyISAM
<SpamapS> lets not d*** with that
<jcastro> comments are on disqus
<marcoceppi> Originally (OMGEC2-v1) I did a quick dump of the table names and update to InnoDB, few tables have fulltext indexes (yuck) and can't be converted
<SpamapS> obal turned on slow query logging for a bit.. the thing looks healthy
<SpamapS> jcastro: score, ok
<SpamapS> jcastro: probably because the old comments were so damn slow.. ;)
<jcastro> marcoceppi, is the db problem the reason the Continue Reading, etc don't work?
<SpamapS> 33qps .. 1GB db.. could have stayed on small. :)
<SpamapS> tho I suspect it gets a lot busier sometimes. :)
<jcastro> we can move it to smalls tomorrow
<jcastro> marcoceppi, ooh, cpu on wp going down
<marcoceppi> hopefully if this caching works out like it's supposed to, we can move the site back down to a smaller instance and just use add-units when needed
<jcastro> ^^
<jcastro> that's why we went with smalls to begin with
<jcastro> marcoceppi, ... and pegged again
<SpamapS> Yeah seems like without comments this site should be nearly static
<marcoceppi> SpamapS: should
<marcoceppi> comments are off-site with disquss
<marcoceppi> just a lot of plugins
<jcastro> marcoceppi, hmm so what do you suppose is going on with the wp node?
<SpamapS> query cache is handling most of the mysql load...
<marcoceppi> jcastro: php
<SpamapS> marcoceppi: apc?
<marcoceppi> I think that's it
 * SpamapS installs mytop and enjoys the show
<marcoceppi> jk, it's back
<SpamapS> ok, I need to run out and get dinner for the family.. you guys need anything else?
<jcastro> ok so mysql is set?
<jcastro> man
<jcastro> that is waaaay faster
<SpamapS> mysql is doing nearly nothing
<jcastro> man so all that mess was the ootb mysql being that horrible?
<SpamapS>  Key Efficiency: 97.9%  Bps in/out:   1.0/335.9   Now in/out:   8.3/ 3.2k
<SpamapS> 97.9% means that the indexes are all basically fitting in the anemic buffers that are left over because we tune for InnoDB by default
<jcastro> I owed you one, <3
<SpamapS> jcastro: this has been so much fun.. I totally miss running a real site. ;)
 * SpamapS sighs
<SpamapS> Ok, I have to go get tacos. Will check back in later.
<jcastro> well, if you want, you can fix php
<jcastro> ok, cheers!
<SpamapS> VERY COOL btw
<SpamapS> install APC
<SpamapS> PHP should fly
<SpamapS> it seriously helps
<SpamapS> ok, out, bbl
<marcoceppi> SpamapS: APC is already installed :)
<marcoceppi> WHAT SAY YOU NOW!
<SpamapS> So we're pegging 4 CPU's w/ PHP? time to look at varnish :)
 * SpamapS gone
<hazmat> varnish rocks
<jcastro> too bad there's no charm
<jcastro> hah
<hazmat> although i've been using the builtin nginx cache facilities for more trivial caching as of recent
<hazmat> its hard to charm i think, to allow for flexibility you end up needing to put vcl config down the relation.. for really basic upstream caching its okay
<_mup_> juju/scheduler-peek-list r474 committed by kapil.thangavelu@canonical.com
<_mup_> new scheduler v2, much expanded error testing, now for version 3
<jcastro> d0od, ok
<jcastro> working
<jcastro> the images weren't in the backup
<jcastro> so marco is looking on the old server
<jcastro> we can move dns now if you want
<marcoceppi> d0od: Images recovered
<marcoceppi> everything's in place
<_mup_> Bug #958312 was filed: Change zk logging configuration <juju:New> < https://launchpad.net/bugs/958312 >
<_mup_> Bug #958378 was filed: juju/control should be aware of subordinates <juju:In Progress by bcsaller> < https://launchpad.net/bugs/958378 >
<jcastro> marcoceppi, alright, she's still up and running!
<marcoceppi> jcastro: she lives!
<marcoceppi> There's a few quirks with the WordPress charm that I was going over with d0od
<jcastro> ah ok
<jcastro> do we have that logged?
<marcoceppi> it was PM I can put it in the doc
<jcastro> k, whenevs
<jcastro> hey I noticed search is wonky, probably like the other links where it needs the real domain I am guessing
<marcoceppi> jcastro: Yeah, on my desktop (with host modification) it works fine. On my laptop without host modification it's hit or miss
<jcastro> CPU on the wordpress notes is spiking
<marcoceppi>  13:52:44 up 13:17,  1 user,  load average: 0.44, 0.56, 0.68
<marcoceppi> wouldn't appear so?
<jcastro> I am just looking back at the AWS graph
<marcoceppi> ah
<marcoceppi> http://i.imgur.com/Aw0FH.png
<marcoceppi> there were a few spikes over 1
<jcastro> marcoceppi, ok so he can get back in now?
<marcoceppi> jcastro: Yeah, it was a dns issue preventing him from logging in
<marcoceppi> He's all setup
<marcoceppi> Stupid Twitter thing doesn't work though
<SpamapS> marcoceppi: good "morning" :)
 * hazmat digs himself out of the rabbit hole
<marcoceppi> SpamapS: o/
<_mup_> juju/scheduler-peek-list r475 committed by kapil.thangavelu@canonical.com
<_mup_> rewrite of the relation hook scheduler
<SpamapS> marcoceppi: so, did you just accept that PHP was going to get pegged sometimes?
<marcoceppi> SpamapS: we tried varnish and that sucked. I went back and looked at APC, quick tweak, hard stopped apache, brought it back up
<marcoceppi> that combined with aggressive caching in WP settled the load to an average of 0.43 for the night on the WP node
<SpamapS> marcoceppi: ahh, was APC not actually working?
<marcoceppi> that's what it looked like
<marcoceppi> Enable APC, load jumps extra 20 points. Didn't seem right
<SpamapS> marcoceppi: yeah varnish is hard to get right
<marcoceppi> It seems really complex to charm, but would be great as a proxy/cache drop in for HAProxy
<SpamapS> marcoceppi: "quick tweak" ? did it land in the wordpress charm yet? ;)
<SpamapS> marcoceppi: yeah m_3 started working on it
<marcoceppi> SpamapS: there's a bunch of stuff that needs to be tweaked in the WP charm ;)
<SpamapS> marcoceppi: yeah I was thinking we should look at switching it to fastcgi
<marcoceppi> mm
<marcoceppi> I'm making a bunch of changes in the omg fork of the charm
<marcoceppi> then see what I can slide back in
<marcoceppi> There's also some oddities when you throw HAProxy in front
<marcoceppi> The silly archive version of WP doesn't handle it very well
<SpamapS> marcoceppi: the way the configs are done in the packaged version is kind of confusing
<SpamapS> marcoceppi: I think we need to enhance the 'http' relation with some new optional bits.. one of those being 'endpoint hostname'
<SpamapS> marcoceppi: I'm not settled on whether haproxy should feed that back to wordpress, or wordpress should feed it to haproxy..
<SpamapS> marcoceppi: but either way, I'm sure you had problems with the Host: header
<_mup_> juju/scheduler-peek-list r476 committed by kapil.thangavelu@canonical.com
<_mup_> cleanup for review
<_mup_> juju/scheduler-peek-list r477 committed by kapil.thangavelu@canonical.com
<_mup_> expand ignores
<hazmat> i'm still amazed sometimes how much memory/cpu emacs uses
<_mup_> Bug #958662 was filed: Rewrite the scheduler, for simplicity, and better error handling. <juju:New> < https://launchpad.net/bugs/958662 >
<_mup_> juju/scheduler-peek-list r478 committed by kapil.thangavelu@canonical.com
<_mup_> log stops
<_mup_> Bug #958668 was filed: Rewrite the scheduler, for simplicity, and better error handling. <juju:In Progress by hazmat> < https://launchpad.net/bugs/958668 >
 * hazmat sighs
<_mup_> juju/local-provider-container-wait-flags r485 committed by kapil.thangavelu@canonical.com
<_mup_> wip on lxc containers with bitmask wait flags, something odd in the lxc responses, reporting started units as stopped in lxc-ls, tbd
<hazmat> bcsaller1, please resolve your branch (subordinate-type) with trunk conflicts
<bcsaller1> hazmat: ok and I noticed a another issue, I'll push an updated version in a bit
<hazmat> just noticed some failures on trunk from my hook-alias branch merge.. argh.
<hazmat> ah.. found it
<hazmat> bcsaller1, did you end up normalizing log locations as part of subordinates?.. if not i'm going to do a branch against trunk for it
<bcsaller1> hazmat: I didn't address that, no
<hazmat> bcsaller1, no worries, the normalized form i'll use should accomodate it, i'm just going to use the local scheme on other providers
<hazmat> bcsaller1, jimbaker can i get a +1 on this trivial?
<hazmat> http://paste.ubuntu.com/889598/
<bcsaller1> hazmat: in process_reason the first branch returns and the second doesn't now?
<hazmat> bcsaller1, the second branch and third branch have return at the end of the conditional block, the other two conditional blocks setup the return value, the first block is self-contained
<hazmat> ie. the others define error, and then return deferred.errback(error) at the end of the method.. the first one was failing because..
<_mup_> juju/trunk r485 committed by kapil.thangavelu@canonical.com
<_mup_> [trivial] hook exit and test teardown one liner fixes [r=bcsaller]
<pindonga> hi, I'm trying to use juju on precise and I'm getting errors about dns name resolving issues... looks like it's not using --ipv4 when running the equivalent of euca-describe-instances
<pindonga> any ideas?
<hazmat> SpamapS, not sure how to  setup --no-recommends cloud-init installs juju
<pindonga> so, on another angle, what's the recommended way for starting with juju if I don't want to use amazon (due to it's cost basically)?
<pindonga> is it openstack or lxc?
<pindonga> I have not found a single way to deploy a charm yet in either :(
<hazmat> pindonga, ugh..
<hazmat> pindonga, i use lxc all the time, openstack is also viable
<hazmat> pindonga, do you have a traceback with the dns issues?
<hazmat> er. pastebin/log
<pindonga> let me get one for you
<pindonga> hazmat, http://pastebin.ubuntu.com/889699/
<pindonga> also, when I re-run the bootstrap, now I get an error saying the security group cannot be deleted
<pindonga> http://pastebin.ubuntu.com/889701/
<pindonga> is that expected?
<pindonga> I'm running precise (afaik)
<pindonga> with lxc i get a log entry saying 'Creating master container...' and nothing after that, so juju will always see the container as pending
<pindonga> I can share my environments.yaml if that helps
<hazmat> pindonga, you have to destroy-environment before doing another bootstrap typically
<pindonga> hazmat, I figured, but wanted to check anyway... I think if something fails juju should recover gracefully, but that can be worked on later maybe?
<hazmat> pindonga, lxc creates the containers in the background, it takes a few minutes, if takes more than 10m, there master-customize.log in data-dir should have some clues if you could paste it, there's all dev tool for it that does the same
<pindonga> let me check that log file
<pindonga> one sec
<hazmat> re openstack, it looks like that setup isn't returning publicly routable dns names
<hazmat> pindonga, you can either associate a static ip/public ip to the bootstrap node or run juju from a location where the public-addresses returned by the api are routable
<pindonga> hazmat, this is canonistack, so yes, the ips are not public routable by default.... (you can get ips by doing euca-describe-instances --ipv4 normally)
<pindonga> not sure this is something juju should fix or canonistack should fix
<pindonga> hazmat, so where should I look for the master-customize.log file? I got nothing neither in the juju folder nor in the lxc folder (the lxc folder is completely empty)
<pindonga> just have a config file and an empty rootfs folder
<pindonga> though I still see a bunch of lxc processes around... maybe I should keep waiting
<marcoceppi> hey SpamapS why do you want to remove md5 and sha1 checks from ch_get_file ?
<pindonga> hazmat, I appreciate your help btw... while we are on it... I know juju is service-oriented and not machine oriented, but can you tell me if this is too far fetched? in order to learn about juju and charms, I decided to write a charm to deploy my development environment... ie, once deployed, a new host will have my full env ready for development (though it doesn't make sense to have more than one host for this 'service' ,)
<hazmat> pindonga, thats sound reasonable to me.. effectively a charm for a dev env
<hazmat> ie. its taking advantage of automation not orchestration
<pindonga> hazmat, ok, good news, the master-customize.log showed up in the end... it may have been I was just too anxious :)
<hazmat> pindonga, try status now out of curiosity?
<pindonga> still pending
<pindonga> though the log says Container Customization Complete
<pindonga> and the juju log says Starting container...
<hazmat> pindonga, what's lxc-ls show?
<pindonga> besides the ones I already had it lists ricardo-local-0-template and ricardo-local-devel-1
<hazmat> pindonga, on canonistack, you can allocate and associate a public ip address to the bootstrap node
<hazmat> pindonga, cool, does it list -devel-1 only once.. it lists them twice if its running
<pindonga> no, it lists everything only once
<pindonga> which means no container is running
<hazmat> yup
<hazmat> hmm.. pindonga  is there an lxc-wait in your ps aux | grep lxc output?
<pindonga> yes
<pindonga> lxc-wait -n ricardo-local-devel-1 -s RUNNING
<hazmat> pindonga, hmm.. so this is bug 912879
<_mup_> Bug #912879: Machine agent hangs if lxc container start fails <local> <juju:Confirmed> < https://launchpad.net/bugs/912879 >
<hazmat> pindonga, what's unclear though is why the container fails to start.. there's a console log for the container in data-dir/units/$unit-name
<hazmat> it might have some useful details
<pindonga> let me check
<pindonga> hazmat, this doesn't sound right
<pindonga>      lxc-start 1332102305.341 ERROR    lxc_conf - Permission denied - failed to mount 'proc' on '/usr/lib/lxc/root//proc'
<pindonga>       lxc-start 1332102305.342 ERROR    lxc_conf - failed to setup the mounts for 'ricardo-local-devel-1'
<pindonga>       lxc-start 1332102305.342 ERROR    lxc_start - failed to setup the container
<hazmat> hmm.. why's it using /usr/lib/lxc.. that paths look strange
 * hazmat tries locally
<pindonga> I have lxc==0.7.5-3ubuntu40
<hazmat> oh.. that's in the container
<hazmat> pindonga, can you pastebin the whole console.log
<pindonga> sure, one sec
<pindonga> hazmat, http://pastebin.ubuntu.com/889766/
<pindonga> this is container.log , yes?
<hazmat> pindonga, yup, thanks
<hazmat> hmm.. why would the mount fail..
<pindonga> one extra bit of info that might be useful
<pindonga> I don't get the cgroups to mount automatically, so I issues cgroups-mount
<hazmat> pindonga, there should be an upstart job that takes care of that.. cgroup-lite.conf
<pindonga> and I get this exact same error when running lxc-start directly
<pindonga> on this specific container
<pindonga> mhh
<pindonga> actually on other containers too
<pindonga> k, let me reboot to see if this is a temporary glitch with the cgroups
<pindonga> be right back
<hazmat> pindonga, it sounds like something to take up with hallyn on #ubuntu-server.. offhand i don't know what the issue is
<pindonga> hazmat, ok, you've been quite helpful anyway, so thx! :)
<pindonga> for the canonistack env,you said I can associate a public ip to the bootstrap?
<pindonga> let's say I get a public ip from openstack first
<pindonga> how do I invoke juju then?
<hazmat> pindonga, yeah.. its euca-allocate-address, and then euca-associate-address to the bootstrap instance id
<hazmat> pindonga, then just use juju normally
<pindonga> kk
<pindonga> thx, I'll try it out and let you know
<lifeless> hazmat: question for you, when you e.g. start a node, does zookeeper get updated *to trigger* the node being started, juju agent kicking off set, or does zookeeper get updates to record that that stuff *has happened*
<lifeless> hazmat: e.g. which is cause and which is effect
<SpamapS> lifeless: zookeeper is changed, the agents react to that change
<SpamapS> lifeless: states are then updated by the agent to reflect the result of the reactions
<hazmat> lifeless, there's always a state change to initiate an accompanying action
<lifeless> great, thanks for that
<SpamapS> hazmat: re cloud-init / --no-install-recommends , I think you can tell cloud-init what apt options to use... standby
<SpamapS> hm, actually it would seem rather complex
<SpamapS> hazmat: I believe you'd need to actually drop a file in /etc/apt/apt.conf.d to disable the recommends. But then you'd have to turn back around and re-enable it, otherwise charms will fail. :-/
<hazmat> SpamapS, i'll just rearrange to use cmds for juju pkg install.. what do we need for proposed upgrade support?
<SpamapS> hazmat: be careful with that. :)
<SpamapS> hazmat: in the past we broke badly because DEBIAN_FRONTEND=noninteractive wasn't set.. and we also should make sure it uses --force-confold when calling dpkg. See cloudinit's code for how it calls apt-get
<SpamapS> hazmat: for proposed we need, IMO, the thing I sent to the mailing list. But at a bare minimum, we need to be able to cause juju to point machines at -proposed at any time..
<hazmat> SpamapS, yeah.. running cluster upgrade support for juju itself would be nice.. but its out of scope for 12.04 at the moment. but getting initial installation, means what exactly.. just installing juju from a proposed ppa?
<hazmat> i'll check the ml
<SpamapS> hazmat: not ppa
<SpamapS> hazmat: you just need to enable the -proposed repository
<hazmat> SpamapS, interesting.. so the easiest way to do this.. effectively version-pinning and upgrades.. is to always deploy from bzr or assembled tarball
<SpamapS> hazmat: so add another apt source in cloud-init just like the PPA. The bare minimum would be to have another juju-origin called 'proposed' that would enable proposed in cloud-init
<SpamapS> hazmat: then a set of instructions for how to change the origin in zk so that you can test adding newly -proposed units to a running environment.
<hazmat> SpamapS, i can do the minimal proposed origin step for testing new installation for today, i think your ml post would be a good starting post for a spec on upgrading/running existing environments, i don't know if it can be done before 12.04 though, it is important though, tbd
<pindonga> hi hazmat , so I have some progress in the lxc case
<pindonga> hazmat, but now I see this when the container starts:
<pindonga>      lxc-start 1332109039.505 NOTICE   lxc_start - '/sbin/init' started with pid '28727'
<pindonga>       lxc-start 1332109039.505 WARN     lxc_console - console input disabled
<pindonga>       lxc-start 1332109039.505 WARN     lxc_start - invalid pid for SIGCHLD
<pindonga>       lxc-start 1332109147.641 INFO     lxc_af_unix - message denied for '1000/1000'
<pindonga>       lxc-start 1332109147.673 INFO     lxc_af_unix - message denied for '1000/1000'
<pindonga>       lxc-start 1332109162.493 DEBUG    lxc_commands - peer has disconnected
<pindonga>       lxc-start 1332109162.555 DEBUG    lxc_commands - peer has disconnected
<pindonga> I think I heard about a bug like this, but not sure what the workaround was (the bug was that the default user already existed with the same id (1000))
<lifeless> http://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_strengthsAndLimitations - do we hve something in place to clean up the data snapshot/log files?
<_mup_> Bug #958872 was filed: bootstrap Install cron job to cleanup zk logs <juju:New> < https://launchpad.net/bugs/958872 >
<lifeless> hah
<lifeless> is it possible to have some code run whenever a new node is setup ? (user supplied code I mean)
#juju 2013-03-14
<m_3> what happened to mup?
<sarnold> +q
<m_3> ok, queue down to 11
 * m_3 food... biab
<miu2n> i am starting a cloud server and am having problems getting nodes to boot
#juju 2013-03-15
<AskUbuntu> How does Juju "co-exist" with Chef, taking the automation process "one step further"? | http://askubuntu.com/q/267956
<benji> hmm, the IRC logs for #juju seem a bit spotty
<gtklocker> hey
<gtklocker> I saw this: http://www.jorgecastro.org/2013/03/14/newsblur-volunteer-wanted/ I have no idea what juju is though
<melmoth> gtklocker, it s a tool to deploy services in an easy way.
<melmoth> think about it as apt-get for the cloud.
<melmoth> works with amazon, openstack, and lxc containers.
<melmoth> https://juju.ubuntu.com/docs/user-tutorial.html
 * mariusko_ thinks Juju still is buggy! :/
<_mup_> Bug #1155548 was filed: Consumes a lot of CPU resources <juju:New> <juju-gui:Triaged> < https://launchpad.net/bugs/1155548 >
<sidnei> mariusko_: no one said it wasnt. ;)
<mariusko_> sidnei: nope, it says semi-clearly that it is not production ready yet
<lifeless> sinzui: https://juju.ubuntu.com/docs/ "juju is still in a stage of fast development, and is not yet ready for prime time. The current software is being made available as an early technology preview, and while it can be experimented with, it should not be used in real deployments just yet."
<mariusko_> for the charm instances that contain all state in the config, a workaround is to redeploy the service
<sidnei> a workaround for what exactly?
<mariusko_> all kind of strange behavior. Now I think I was having problem with phantom relations
<mariusko_> after removing some of them
<mariusko_> in the haproxy charm, but the bug might be in the core
<mariusko_> resolved by redeploying
<sidnei> more often than not the problems that i had were with the charms, ymmv
<mariusko_> also possible
<mariusko_> I just saw in the log of it iterating relations and found much more than expected
<m_3> sidnei: hey, I'm marking the apache2 MP as resubmit to move those /tests to somewhere else
<m_3> sidnei: I can put that as a but after the changes are in if that's easier for you
<m_3> sidnei: but it seems simpler to move them before it's in trunk imo
<m_3> ha!... s/but/bug/ above
<sidnei> m_3: that's fine yes
<m_3> cool... thanks man!
<m_3> sorry the testing hasn't been communicated well
<sidnei> np. i also want to solve the charmhelper/charmsupport issue, might end up delaying the resubmit for that.
<m_3> sidnei: hey... side note
<m_3> would it make sense to consolidate squid-{reverse,forward}proxy into a single charm?
<m_3> that could take role based on the relations
<m_3> similar to the hadoop charm (there's a great readme on that)
<sidnei> m_3: i believe so, after the changes i did
<m_3> sidnei: cool... well one step at a time, let's get these landed first
<m_3> then we can see what people would expect to see for squid and what's easy to use
<m_3> sidnei: awesome work man
<sidnei> thanks!
<dpb__> m_3: lp:~davidpbritton/charms/precise/landscape-client/add-landscape-relation is ready for review again
<m_3> dpb__: cool, thanks!  there're a couple in-process atm
<dpb__> m_3: backlog getting worked down? :)
<m_3> dpb__: one bite at a time... was a big backlog
<marcoceppi> hazmat: m_3 I've got a fix for failing charm-tools. It's kind of small but thought you should know https://code.launchpad.net/~marcoceppi/charm-tools/pep8-fix/+merge/153585
<m_3> marcoceppi: ack, thanks
<marcoceppi> Screw it, thundergun, going to just merge it
 * marcoceppi Two seconds too late
<m_3> marcoceppi: sounds good
<marcoceppi> I should have run make check after "rebasing" from trunk
<m_3> marcoceppi: I should've done it in the review ;)
<m_3> doh
<m_3> no biggie
<marcoceppi> there's always next time ;)
<mattyw> jcastro, sure
<jcastro> mattyw: post your error
<mattyw> jcastro, bzr: ERROR: Permission denied: "~mattyw/charms/precise/mongodb_auth_experiment/": : Cannot create branch at '/~mattyw/charms/precise/mongodb_auth_experiment'
<qengho> mattyw: does  ~/charms/precise  exist?
<qengho> What's the command that caused that?
<mattyw> qengho, bzr push lp:~mattyw/charms/mongodb_auth_experiment
<marcoceppi> mattyw try this:
<marcoceppi> bzr push lp:~mattyw/charms/precise/mongodb_auth_experiment/trunk
<mattyw> marcoceppi, mongodb_auth_experiment is not a valid source package name.
<mattyw> that's the error I get :(
<marcoceppi> mattyw interesting. You could always push to ~mattyw/+junk/mongodb_auth_experiment for the time being I don't know nearly enough about the name scheme to say why that doesn't work for you but works for me
<mattyw> marcoceppi, do I need to be a member of any team?
<mattyw> marcoceppi, the team that own the charms project?
<qengho> mattyw: try dropping the "/precise" -- the system may interpret that as part of a distro/release/package/branchname sequence.
<qengho> Oh, I see you started without it.  Never mind.
<marcoceppi> mattyw I'm not sure what the rules are for creating branches in your own namespace. that might be the case. You may want to join https://launchpad.net/~charm-contributors to see if that fixes it
<marcoceppi> that team, iirc, is your first stop if you're interested in helping with charms
<mattyw> marcoceppi, nope that doesn't seem to have fixed it :(
<mattyw> marcoceppi, member of charmers pherhaps? I've applied are you one of the mods?
<marcoceppi> mattyw that's not it. I know other users who aren't in charmers who have branches with that address
<mattyw> marcoceppi, ok, I'll keep trying and see what I can come up with
<marcoceppi> I'm at at bit of a loss as to why you can't push. You could probably get away with ~mattyw/charms/precise/mongodb/auth_experiment
<marcoceppi> not sure if it's actually part of the Mongodb charm or if it's something different
<mattyw> marcoceppi, yep - that got it
<marcoceppi> Cool, looks like it's based on the mongodb charm, so that would be the "best" address for it
<mattyw> marcoceppi, jcastro qengho rather embarrassingly that is actually what the documentation says - thanks for helping guys!
<jcastro> wait
<jcastro> so what was the problem? I'm confused now
<jcastro> m_3: you were pinging me about some broken branches earlier?
<m_3> jcastro: nah, nm I got what I was looking for
<mattyw> jcastro, I was trying to put it in bzr push lp:~mattyw/charms/precise/mongodb_auth_experiment rather than bzr push lp:~mattyw/charms/precise/mongodb/auth_experiment
<jcastro> oh! the charm's name, of course, that makes sense now
<mattyw> jcastro, it does say that in the docs I was reading - but seems like I tried to blaze my own trail :(
<mattyw> jcastro, thanks for the help. I'll post it to the juju list
<wedgwood> did anyone start on that newsblur charm?
<jcastro> not yet!
<jcastro> it would be awesome though
<wedgwood> no kidding. I be the author would even be thankful. he's getting destroyed by demand
<wedgwood> I'll give it the rest of my lunch break and see where that gets me.
<wedgwood> ooh, off-by-30 error on that. gotta get back to work, but maybe this evening.
<jcastro> nod
<jcastro> yeah it would be nice to say
<jcastro> "oh hey greader shut down, so I "juju add-unit newsblur -n 20"
<marcoceppi> probably be around -n 100
<salgado> juju occasionally tells me that it's using a cached version of the charm to deploy (e.g. "INFO Using cached charm version of postgresql"). is there a way to tell it not to use a cached version since I'm using local:postgresql and I've made changes to it?
<salgado> if not, where can I find the cache so that I can manually delete it?
<sarnold> salgado: juju deploy -u is probably what you're looking for
<jcastro> http://askubuntu.com/questions/262833/how-do-i-force-the-juju-bootstrap-node-to-clear-the-charm-cache
<jcastro> sarnold: I reworded the question to be more generic
<sarnold> jcastro: aha :)
<salgado> thanks sarnold, jcastro!
<benm> Hello, where is the right place to ask for first time help testing a juju local mysql configuration?
<marcoceppi> m_3 looks like pep8 needs to be added as a dependency for charm-tools. I'm not 100% sure how to do that though
<m_3> marcoceppi: ack
<marcoceppi> m_3 thanks!
<m_3> marcoceppi: I'll fix it
<sarnold> benm: here or askubuntu.com is fine :)
<benm> \msg sarnold thanks, marcoceppi's blog is proving useful
<sarnold> benm: oh, cool, I'll have to give it a look :D
#juju 2013-03-16
<jcastro> m_3: I see stuff is happening on github. :)
<SpamapS> I see dead bzr trees. ;)
<m_3> jcastro: yeah... wondering what's up with the gravatar on there
<AskUbuntu> How are log files persisted with the Logstash charm? | http://askubuntu.com/q/268634
<jcastro> m_3: don't forget that guy's AU question wrt. chef
#juju 2013-03-17
<penguin1> hi
<penguin1> When a mysql service is scaled, how do the mysql server loadbalancing? They have to be configured first?
<SpamapS> penguin1: currently they are independent servers. However, if you relate that service to a separate master service, they will all be slaves of the master.
<SpamapS> penguin1: there's been work to try and build an auto-scalable Galera based mysql charm (by me), but I never finished it
<iggy> Is there a way to tell juju which ssh keypair to use in AWS? We have quite a few keys and I think that may be confusing juju.
<iggy> or maybe I should restate my problem another way... when trying to run through the getting started doc, I get an "ERROR Invalid SSH key" message, I go and look at the instance in the aws console and it doesn't have an ssh key assigned to it
<penguin1> SpamapS: so the charm will change the configuration files in order to make them to slaves, right?
<SpamapS> penguin1: yes, but not on add-unit, only on add-relation to another separate service
<penguin1> SpamapS: you mean, mysql server got a mysql-service, and other can use that service, right?
<penguin1> SpamapS: what is used for manipulating the configuration files?
#juju 2014-03-10
<perrito666> nites people
<perrito666> what does exactly expose do when used with lxc?
<perrito666> I mean, is there anything I should implement in my charm to support it?
<davecheney> perrito666: it's sort of theother way around
<davecheney> your charm should call open-port when it wants to expose a port to consumers of the charm
<perrito666> davecheney: I see, Ill rtfm myself with that info :D tx
<davecheney> perrito666: the goal, when everything works right, is as the charm author you shouldn't have to worry about the differences between the various providers
<perrito666> davecheney: I see, I was trying to learn juju trough creating a charm, I found a grey area on that particular feature (expose)
<davecheney> perrito666: ok, so there are two parts
<davecheney> one, in the charm, you say open-port or close-port to indicate to juju that the charm will talk on said ports
<davecheney> on the client side, you call juju expose $SERVICE
<davecheney> which takes the list of ports indicated by open-port and does firewall magic to make those visible on the public ip
<perrito666> davecheney: tx, that is very informative
<prathamesh> hi all
<onrea> How to install juju manually by this files:
<onrea> ubuntu-12.04-server-cloudimg-amd64
<onrea> and
<onrea> ubuntu-12.04-server-cloudimg-amd64-root
<onrea> Oops! How to install juju via cloudimg's?
<bloodearnest> so, I use a charm that bundles charm-tools (for reasons currently unknown)
<marcoceppi> bloodearnest: wat?
<bloodearnest> marcoceppi: I've no idea why
<marcoceppi> bloodearnest: is this a charm that you downloaded or one you're writing?
<bloodearnest> marcoceppi: it's one some one on my team wrote who has now left, it's an nginx-rate-limiter charm
<marcoceppi> bloodearnest: yeahh, there's really no need to embed charm-tools UNLESS they were trying to use the old charm-helpers
<bloodearnest> marcoceppi: last commit was 06/2013
<marcoceppi> in which case, they should use the PPA that only builds charm-helper-sh/charm-helper-python
<marcoceppi> bloodearnest: well, that's not much help
<bloodearnest> right, so I need to re-write the charm, I'm good with that, I just don't have time to do it today, as I have some urgent deployments
<bloodearnest> the only reason this is blocking me is I can't deploy the charm as is any more with 1.17, I get an error:
<bloodearnest> charm-tools has a number of
<bloodearnest> ERROR error uploading charm: cannot read extracted archive: charm "$package" using a duplicated relation name: "relation-name"
<bloodearnest> gah
<bloodearnest> which I believe is due to some template metadata.yaml files in charm tools
<marcoceppi> bloodearnest: you can fix that by embedded a more recent version of charm-tools
<bloodearnest> the new thing is that somehow juju is finding the those metadata.yaml files and complainging
<marcoceppi> but whatttt
<bloodearnest> marcoceppi: indeed
<marcoceppi> yeah, juju really shouldn't dive /that/ deep
<bloodearnest> marcoceppi: ack, will bump charm-tools an move forward, and after deployment will back track and file a bug
<marcoceppi> bloodearnest: ta
<bloodearnest> marcoceppi: updating to r318 of lp:charm-tools gives a different error, but same issue of parsing a template metadata.yaml:
<bloodearnest> ERROR error uploading charm: charm URL has invalid charm name: "local:precise/$package-1"
<bloodearnest>  at least, I assume that's the issue, not 100% sure
<marcoceppi> bloodearnest: I'm like 98% sure you only need the helpers directory in charm-tools
<marcoceppi> but I don't know where to find the charm to verify that
<bloodearnest> marcoceppi: it's lp:~ubuntuone-pqm-team/canonical-is-charms/nginx-rate-limiter
<bloodearnest> marcoceppi: I will probably rebase on upstream nginx and add the rate limiting as an MP on that
<bloodearnest> just wondered if there was a quickfix to get past it
<marcoceppi> bloodearnest: very interesting. I don't see charm-tools being used anywhere in the hooks
<bloodearnest> marcoceppi: yeah, it's possible I could just remove it?
<bloodearnest> marcoceppi: still, it would be good to figure out why it's failing on 1.17.4/trusty and it's been fine on 1.16.x/precise
<marcoceppi> bloodearnest: I would just remove it and deploy for now
<marcoceppi> oh wait
<marcoceppi> bloodearnest: _pythonpath.py shows that it's just using lib/charm-tools/helpers/python
<marcoceppi> bloodearnest: delete everything but the helpers dir in charm-tools
<marcoceppi> and you should be good to go for the deployment
<bloodearnest> marcoceppi: ack will try
<zchander> Hi all, does anyone have any pointers (or working config samples) for a reverse proxy setup, so I can expose my charms from my cluster to the 'real' world? My cluster is a private/seperate network from our schoolnetwork (it is being NATted through the MAAS controller)
<lazyPower> o/ zchander
<lazyPower> marcoceppi: is this something that can be achieved with iptables on the controller node as a gateway?
<zchander> Hi lazyPower, for what I have tried for now, is a apache2 reverse proxy setup, but that doesn't seem to proxy
<zchander> lazyPower: Did the presentation run well?
<lazyPower> zchander: it did. My internet was flakey and dropped while deploying a hadoop cluster
<lazyPower> so i wasn't able to give the full technical rundown with magic without a minor bit of failure
<lazyPower> but my showmanship was pretty high, so it went over pretty well
<zchander> brb: going to get some caffein
<zchander> back again...
<lazyPower> re
<lazyPower> zchander: when you say the apache reverse proxy doesnt work, how so? is the region controller not reaching the internal instances? or...
<zchander> It seems so.... I have just reinstalled my MAAS environment from scratch this morning.
* marcoceppi changed the topic of #juju to: Welcome!! Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP || Reviewer: lazyPower
<zchander> lazyPower: Is seems the 'reverse proxy' redirects all traffic to a https site, which cannot be found, as no ssl enabled site exists (yet)
<zchander> And the log mentions POST requests to my MAAS api
<zchander> Currently I get a 502 - Bad Gateway from nginx
<zchander> And additionally I cannot connect to my MAAS web interface anymore from my school network
<jcastro> hazmat, got a minute to talk deployer?
<zchander> Please disregard my last issue: I forgot (with my fat fingers) to include the ServerName directive in my VirtualHost
<lazyPower> zchander: np :) happens to the best of us
<jcastro> ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: dial tcp 10.0.3.1:17070: connection refused
<jcastro> I am getting this when trying to teardown the local provider
<lazyPower> jcastro: i typically get that when my local provider has gone awry, such as an interrupted bootstrap
<jcastro> yeah
<jcastro> so the "normal" procedures should work?
<lazyPower> just removing .jenv if there are no lxc containers usually resolves that.
<jcastro> to clean up
<jcastro> yeah
<lazyPower> if there are leftover lxc containers, follow the AU post
<lazyPower> jcastro: i'm working through porting my writeup on osx/vagrant charm authoring to the docs atm. What subsectionw ould you put this under?
<lazyPower> authors-osx-walkthrough?
<cargill> in amulet, can Deployment.setup() be called multiple times in the same test?
<jcastro> I would do "How To" and then "Vagrant work flow"
<lazyPower> cargill: thats part of post deployment commands. I filed a bug about the behavior you will see if you try it :)
<marcoceppi> cargill: it can, but you shouldn't add any relations between setup calls, it's not supported
<lazyPower> jcastro: ack. ty
<marcoceppi> cargill: not supported yet*
<marcoceppi> cargill: what's your ultimate goal?
<cargill> I'm getting 'service "postgresql-sentry" not found' when I deploy my charm and potgresql, and not when I deploy just potgresql, so I'm trying to find out whether it's a timeout from my charm setting up itself (it does take a long time) or something else
<marcoceppi> cargill: what's your test file look like?
<cargill> and setting up one, then the other does indeed trigger an error suggesting that setup cannot be run multiple times
<cargill> marcoceppi: http://pastebin.ubuntu.com/7067852/
<cargill> this is without any "debugging" additions
<marcoceppi> cargill: interesting, and so what's the error you're getting? Also, do you have the latest amulet?
<marcoceppi> as in, is there a Python traceback?
<hazmat> jcastro, shoot
<jcastro> can I make bundles with colocated services in LXC containers?
<zchander> lazyPower: can I send you my virtual host config (for a wordpress charm, as per tutorial)
<hazmat> jcastro, yes
<jcastro> let's say I want rails and postgres, but I want all the monitoring stuff in one instance on LXC containers
<lazyPower> zchander: sure, pastebin it
<hazmat> jcastro, http://pythonhosted.org/juju-deployer/config.html#placement
<hazmat> jcastro, placement is somewhat limited at the moment, its a form of deploy x with service y.. and supports containers
<jcastro> ok so lxc:wordpress is "whichever machine wordpress ended up on" then?
<hazmat> jcastro, i've had some discussions last week about allowing machine specification (ie a machines block in addition to a services block) and then allowing for machines to be placed there.
<hazmat> er.. i mean workloads to be placed there
<zchander> lazyPower: http://paste.ubuntu.com/7067872/
<hazmat> jcastro, yes
<cargill> marcoceppi: yes, the vagrant scripts from lazyPower pick up the latest amulet
<hazmat> jcastro, i avoided machine spec (minus 0) in the initial pass because its quite fragile unless you can abstract machines a bit from their env specific identity.
<jcastro> hazmat, perfect, that's exactly what I needed, thanks
<cargill> will post the output shortly
<jcastro> well for this bundle I don't care about machines
<zchander> lazyPower: I might be back tonight again, going into a meeting in a few minutes
<jcastro> I'm making a "rails" one for development and I don't want a ton of instances
<lazyPower> cargill: offtopic from what you're talkign about, but I did a writeup using the precise basebox. it'll reduce that overall footprint of the box to 200mb in your vagrant cache.
<lazyPower> http://blog.dasroot.net/writing-juju-charms-on-osx/
<hazmat> jcastro, cool, for most of them you shouldn't.. the call for machines in deployment is more about real world ops scenarios.. where you want to prep a machine a bit before hand
<hazmat> jcastro, ie.. service co-location is ideal for bundles
<lazyPower> use that vagrantfile with the precisebasebox and you should be g2g. I've tested it locally with no issues.
<hazmat> that re shared/reused.
<lazyPower> zchander: i dont see anything apparently wrong with this
<lazyPower> zchander: ping me when you get back and we'll do some troubleshooting
<cargill> lazyPower: oh, great, right now I'm just running provision everytime, that won't be faster though, will it? but speeding up the bootstrap is definitely a good thing
<lazyPower> cargill: it may slow it down since its cloud-init bootstrapping a juju gui
<lazyPower> the box you're using right now was specifically tailored for amulet testing
<jcastro> hazmat, yeah I didn't want to be like "here's your rails dev bundle, have fun paying for 9 instances an hour!"
<hazmat> jcastro, approximately $1 on do ;-) .. if you have a chance i'd love  your feedback on that plugin.
<hazmat> jcastro, not sure you can do better than hulk-smash in public clouds atm, vpc/private networking against cloud apis for containers is still wip.
<cargill> marcoceppi: this is the log with the test written as above: http://pastebin.ubuntu.com/7067958/
<marcoceppi> cargill: interesting
<cargill> marcoceppi: this another of the errors I'm getting http://pastebin.ubuntu.com/7068075/
<marcoceppi> cargill: what's weird, is the setup is being killed beacuse of timeout, but it keeps going aftwards
<marcoceppi> which is probably why you're seeing that error
<cargill> that's because the timeout passed to setup() is 900 and there is an internal one of 600 seconds?
<jcastro> http://askubuntu.com/questions/432187/how-can-i-deploy-my-local-juju-charm-with-amulet-framework
<jcastro> just in case anyone missed this
<marcoceppi> cargill: it should respect your timeout, however, if you're doing `charm test` command there's timeout per test
<marcoceppi> cargill: actually, that's probably where it's coming from
<marcoceppi> cargill: you need to modify whatever is running `charm test` and add `charm test --timeout=10m` or something like that
<marcoceppi> lazyPower: ^^
<lazyPower> marcoceppi: can you open a bug on the project? I'll get that update pushed in a minute
<lazyPower> wrapping up my doc edits
<marcoceppi> lazyPower: which project/
<lazyPower> https://github.com/chuckbutler/juju-vagrant
<cargill> marcoceppi: will try with 30minute timeout, let's see where it gets me next
<marcoceppi> cargill: ack
<lazyPower> https://github.com/juju/docs/pull/27 -- for anyone thats interested in reviewing the proposed merge for Vagrant based workflow on OSX
<lazyPower> also sent an announcement to the list
<jcastro> hey lazyPower
<jcastro> wrt. your +1 on the hadoop bundle
<jcastro> I made a section on how to put them in the store
<jcastro> https://juju.ubuntu.com/docs/reference-reviewers.html
<jcastro> oh nm, you're not in ~charmers
<marcoceppi> lazyPower: see gh for feedback on pull
<lazyPower> marcoceppi: fixing, addendum to that is we need to do that for the rails howto then, thats what i modeled it after.
<marcoceppi> lazyPower: that's fine, we can fix that later
<lazyPower> ack
<jcastro> https://github.com/juju/docs/pull/28
<jcastro> if someone could ack that it's a simple fix.
<lazyPower> marcoceppi: wiped $'s
<marcoceppi> lazyPower: re-reviewing
<marcoceppi> lazyPower: updated
<lazyPower> re-updated
<lazyPower> marcoceppi: ^
<marcoceppi> lazyPower: okay, finally reviewed everything, only two little things
<marcoceppi> I won't be so lazy reviewing next time
<lazyPower> marcoceppi: ack. Fixed and pushed.
<jcastro> marcoceppi, does bundle proof check that juju-gui is not included in a bundle?
<marcoceppi> jcastro: no, but it could/should
<jcastro> filing
<marcoceppi> open a bug and I'll add it to the next release
<marcoceppi> lazyPower: hahah, I found one more thing
<marcoceppi> you were a little aggressive with the $ removal
<lazyPower> KILL IT WITH FIRE!
<lazyPower> marcoceppi: line 240?
<marcoceppi> lazyPower: nooooope
<marcoceppi> ;)
<lazyPower> find and replace came back to haunt me :((
<sarnold> not sed -i? :)
<lazyPower> sarnold: yuck it up fuzzball :P
<sarnold> nyuk nyuk nyuk
<lazyPower> <3
<sarnold> <3
<marcoceppi> lazyPower: commented
<marcoceppi> lazyPower: or just ommit that all togehter
<lazyPower> but, that cuts out my interesting prompt/path
<lazyPower> ack - removing.
 * lazyPower goes back to the review queue
<jcastro> hey everyone, "State of the Juju Ecosystem" had to be moved to thursday as they added a plenary slot
<jcastro> so Thursday will be charm school, state of the eco, and then Amulet tests all in one day
<lazyPower> womp
<lazyPower> ty for the update jcastro
<lazyPower> did we move that around on the eco calendar yet?
<jcastro> I didn't know we were putting those  on the calendar
<jcastro> in that case, no
<lazyPower> maybe we arent. I just looked and didn't see anything there
<lazyPower> i figured with it being UDS related, it would go on the calendar, my b.
<jcastro> it's UDS, we're supposed to be paying attention heh
<jcastro> but if you register yourself at UDS it will generate a calendar of sessions for you, etc.
<jcastro> I'll be sending reminders here throughout the week anyway
<marcoceppi> lazyPower: noooo
<marcoceppi> lazyPower: you only needed to fix that one line, the rest was fine :(
<lazyPower> marcoceppi: no idea what you're talking about
<marcoceppi> gh
<lazyPower> damnit
<lazyPower> i'm quit
<lazyPower> s/i'm/i
<marcoceppi> You even asked, and I was like "nooo, those are fine"
<lazyPower> marcoceppi: updated
<marcoceppi> lazyPower: now, can you squash 'em all :) <3
<jcastro> hey lazyPower
<jcastro> now that you've documented the vagrant workflow
<jcastro> http://www.vagrantup.com/blog/vagrant-1-5-and-vagrant-cloud.html#features
<jcastro> hah.
<lazyPower> jcastro: make a card
<lazyPower> and stand in line behind marco
<jcastro> I think it'll be a bit before we get 1.5
<jcastro> utlemming, https://vagrantcloud.com/
<jcastro> utlemming, this is just launched, but we should perhaps look at indexing the official boxes there?
<lazyPower> jcastro: https://vagrantcloud.com/search?utf8=%E2%9C%93&q=juju
<lazyPower> boo
<jcastro> indeed!
<lazyPower> look at all these chef boxes
<lazyPower> boy sure would be nice if JUJU was a featured box
 * lazyPower tongues cheek
<zchander> ping lazyPower
<lazyPower> zchander: pong
<zchander> I am at home right now, but with VPN to school
<lazyPower> zchander: ok. my thoughts are check connectivity from the gateway node to the internal net. validate its communicating properly
<lazyPower> start at the lowest common denominator and unwind the onion of complexity layer by layer
<zchander> I can ssh into the node without any problem using the hostname from the controller
<lazyPower> ok, is port80 of the node accessible from the controller?
<lazyPower> you can use links or similar text based browser to validate
<lazyPower> or curl for that matter
<zchander> I am installing lynx right now
<zchander> Done: I am getting a bad gateway from nginx
<lazyPower> that would be on the wordpress charm, and you should have gotten that via the apache reverse proxy. but ok we have validated you have port 80 connectivity
<lazyPower> tail your apache logs for the vhost, and attempt to reach the wordpress node.
<zchander> snippet from wordpress-access_log: http://paste.ubuntu.com/7069014/
<zchander> btw, maas-ctrl-001.nimeto.edu/MAAS also gives a bad gateway from nginx
<lazyPower> so the reverse proxy is working?
<zchander> (this is the fqdn for my MAAS controller)
<zchander> Seems so, but too good? ;)
<lazyPower> so, my thoughts are, poke at wordpress and figure out a) why its a bad gateway (probably PHP-FPM failed to start) b) what do you need to add to get the proper hostname on the wordpress unit to respond to the request.
<zchander> This a line from the access log from nginx on the wordpress node: 10.0.41.5 - - [10/Mar/2014:18:06:05 +0000] "GET /favicon.ico HTTP/1.1" 404 140 "http://node001.nimeto.edu/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9"
<lazyPower> i saw that. its not finding a site for that hostname.
<lazyPower> the 404 in the log detail points to that.
<zchander> Seems I have to get up to speed with nginx....
<lazyPower> zchander: http://wiki.nginx.org/ServerBlockExample
<lazyPower> zchander: there's also a configuration option for the wordpress charm to use apache instead of nginx
<lazyPower> zchander: juju set wordpress engine=apache2
<lazyPower> https://jujucharms.com/precise/wordpress/#readme
<zchander> Can I foo that with a running charm?
<lazyPower> yep. so long as the charm is not in an error state, it will reconfigure itself on the fly
<zchander> just did it.... Trying again
<zchander> getting [agent-state-info: 'hook failed: "config-changed"'], this will resolve itself in time? Or should I 'resolve' the issue?
<zchander> brb: getting kid to bed....
<mgz> zchander: hook failures need manual resolution
<lazyPower> zchander: you can either pass the -r to the resolved command, or use debug-hooks to manually investigate and resolve the issue.
<lazyPower> zchander: units in an error state do not magically resolve themselves, and always require manual intervention.
<zchander> getting a HOOK W: Failed to fetch http://ppa.launchpad.net/charmers/charm-helpers/ubuntu/dists/precise/main/binary-amd64/Packages  403  Forbidden when switching to apache (??)
<zchander> I am going to destroy the service and retry to redeploy
<zchander> bbl, got visite... parents...
<bac> hi sinzui
<sinzui> hi bac
<geekmush> anyone playing with juju on Digital Ocean?
<lazyPower> geekmush: there are a few using hazmat's plugin for alpha-level testing
<hazmat> geekmush, just saw your issue
<hazmat> geekmush, so you need the dop library from git atm..
<hazmat> geekmush, i'll switch out to just doing a mini digital ocean client lib for the needed bits within the plugin.
<hazmat> but probably not today
<geekmush> hazmat:  ok, cool â¦ I'll stand by and also try out the git'd version of dop as well
<hazmat> geekmush, cool, yeah.. things work if you using the git version of dop.. i put a bug in there for them to make a release, since its been over a release since their last
<hazmat> er.. over a year
* lazyPower changed the topic of #juju to: Welcome!! Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP
<jcastro> hey fellas, so I am working on a django bundle
<jcastro> but the charm hasn't been touched in like a year
<jcastro> anyone mind doing it next on the audit?
<hazmat> geekmush, any luck/progress?
<geekmush> just started â¦ got pulled into last minute conf call â¦
<bodie_> does anyone know the status of juju on debian?
<bodie_> i'm seeing some articles linking to a juju package in experimental, but it's gone now
<sarnold> bodie_: I don't think there has been any effort to push the juju packages to debian yet; those packages in experimental were probably the old python version 0.5 or so iirc, which, while neat, weren't anything that anyone wanted to tell users to use :)
<marcoceppi> bodie_: juju the client should just work
<marcoceppi> bodie_: though you may need to compile it from source,
<bodie_> I see :)
<bodie_> thanks
#juju 2014-03-11
<themonk> what is the default password fir juju-gui?
<marcoceppi> themonk: it's your admin-secret
<themonk> marcoceppi: hi :) thanks
<marcoceppi> themonk: if you didn't explicitly set it in your environments.yaml file, you can find it in ~/.juju/environments/$(cat ~/.juju/current-environment).jenv
<themonk> marcoceppi: hmm
<themonk> marcoceppi: i want to share a charm scenario with you.
<marcoceppi> themonk: I'm all "ears"
<themonk> marcoceppi: in my charm i have a custom java server which i have written and it runs on localhost and it listens to 9099 port, now if i make a new charm only for my java server then how i tell other charm to comunicate with my java server
<marcoceppi> themonk: as in install applications in the java server, or actually communicate with that service like mysql does to mediawiki?
<themonk> marcoceppi: i need only to comunicate with java server no install
<marcoceppi> themonk: you can create a new interface if one doesn't already exist
<marcoceppi> which it probably doesn't, unless your java server does something that exists already, just implemented in a different way
<themonk> marcoceppi: hmm my java server is a http server which communicates with json data
<marcoceppi> themonk: so, you /could/ use the json-rpc interface, but really it's best to just create a new interface. Interfaces describe how compatible charms are
<marcoceppi> so, if your java server is an rss parser and provides a json stream of data, you could just say the interface is rss-data or something
<marcoceppi> it's hard to think of a name when I don't know what the service does
<marcoceppi> but basically it would provide that interface as a relation, and your other charms would require it
<marcoceppi> and if all that's needed is the address and port to connect, the java server charm hooks would basically do a `relation-set hostname=$(unit-get private-address) port=9099`
<marcoceppi> and your other charms would injest that with relation-get, configure themselves appropriate, etc
<marcoceppi> Interfaces are "arbitrary" as in you can create one at anytime by simply naming it
<themonk> marcoceppi: hmm thanks :) it was helpful one more thing i need to understand hole add-relation thing is there any doc or youtube video other than juju doc which can help me to understand more clearly :)
<marcoceppi> themonk: well, we ahve some vids talking about relations, but they either skim over it like "Hey, look relations" or they dive really deep into the underlying logic. Having a video focusing on the 90% of relations stuff would probably be a good idea
<themonk> marcoceppi: or a good sample charm written in python
<marcoceppi> themonk: I'll see if I can correl a few people to shoot one in the next few days, otherwise let me see if I can find a charm for you
<themonk> marcoceppi: thanks man that will be great :)
<themonk> marcoceppi: until then just point me a charm :)
<marcoceppi> themonk: so, most charms that are written in Python are using charm-helpers, not sure if you are already or not
<themonk> marcoceppi: hmm i know very small about charm-helpers but i was planning to use it. its looks like flask.
<marcoceppi> themonk: yeah, it has a flask like element, in that there are method decorators, It also wraps a lot of the command line tools (like relation_get, etc) in to python methods
<themonk> marcoceppi: is charm-helpers stable?
<marcoceppi> themonk: it's used in almost all the openstack charms, as well as a lot of other python charms, has a >90% testing coverage
<marcoceppi> so, for the most part yes. There's some work planned this cycle to package charm-helpers as right now you have to embed them directly in the charm using a sync tool
<themonk> marcoceppi: and is there any doc about charm-helpers?
<marcoceppi> themonk: heh, that's part of the work scheduled for charm-helpers
<themonk> marcoceppi: hmm, ok then charm-helpers will not be a problem for me.
<themonk> marcoceppi: point me a python charm to understand add-relation
<marcoceppi> themonk: so, most of these use a "hooks.py" where all the hooks are symlinked to one file and that holds all the methods. Not required, but that's just a pattern that some who wrote python charms choose
<themonk> marcoceppi: thanks for your support man :)
<marcoceppi> themonk: but the apache2 charm is one to check out
<marcoceppi> let me find another one, that's slightly less complicated
<themonk> marcoceppi: my charm is like django charm
<marcoceppi> openstack-dashboard is another python charm that's a bit simpler
<marcoceppi> themonk: then check that one out, openstack-dashboard is bascially a django application
<marcoceppi> with some extra, openstack dependant relations
<themonk> marcoceppi: ok then :)
<marcoceppi> themonk: lmk if you want some more examples. In the mean time I'll think of a way to record this video for relation stuff
<themonk> marcoceppi: yes that will be great :)
<marcoceppi> themonk: and since none of the charm-helpers are documented, just ping us in here if you have questions
<themonk> marcoceppi: ok :)
<zchander> ping lazyPower
<psivaa> hello, curious if there is a way to reboot the a juju machine without destroying it when we are not able to ssh to it?
<davecheney> psivaa: which provider ?
<psivaa> davecheney: canonistack lcy01
<davecheney> psivaa: maybe use the nova command to restart the instance
<psivaa> davecheney: ack, thanks
<vila> davecheney: and juju will be able to reconnect it properly ?
<zchander> lazyPower: ping
<marcoceppi> zchander: anything I or others could help with while lazyPower gets online?
<zchander> marcoceppi: I got the reverse proxy working, it seems. (only HTTP, HTTPS still gives me some troubles)
<rick_h_> marcoceppi: do you or jcastro help me get into the hangout for the vuds session?
<marcoceppi> zchander: so, the reverse proxy as in trying to access your private MAAS which has no public addresses? are you using sshuttle? (I think I vaguely remember you from a few days ago)
<marcoceppi> rick_h_: sure, what do you need?
<rick_h_> marcoceppi: just looking for the hangout url or something so I know how to get into the session
<marcoceppi> rick_h_: has it started?
<zchander> I am trying to deploy juju-gui, through the reverse proxy and HTTPS through the reverse proxy gives me some 'End of file found: SSL handshake interrupted by system' errors. And the juju-gui is trying to call back to my MAAS controller for /ws which also gives me some 'little' challenges
<rick_h_> marcoceppi: no, does the url show once it's started?
<rick_h_> marcoceppi: I'm trying to be a good boy and plan ahead :)
<marcoceppi> rick_h_: someone is the track lead, and will be updating the page with hangout URLs about 10-15 mins before session start
<zchander> marcoceppi, no I am using the reverse proxy through apache
<rick_h_> marcoceppi: I can pre-fill some notes, join irc, but the hangout info is no where to be found.
<rick_h_> marcoceppi: ah, that's what I needed to know. Thanks
<zchander> (body had mentioned shuttle before.... ;))
<marcoceppi> rick_h_: it seems like jcastro will probably be doing the track lead for servercloud1
<rick_h_> marcoceppi: yep cool thanks
<marcoceppi> zchander: so, it's probably because apache terminates the SSL connection and assumes http for proxing.
<marcoceppi> rick_h_: can juju-gui be configured to not SSL?
<zchander> It seems so, but I have set juju-gui to use non-ssl right now
<rick_h_> marcoceppi: not right now.
<rick_h_> marcoceppi: actually the plan is to remove the port 80 options
<rick_h_> but that redirects to 443
<rick_h_> so the bug we've got on file is to allow not watching port 80 but only 443
<marcoceppi> rick_h_: but still have like a simple meta-redirect to 443 from 80?
<zchander> ?? This is a setting? juju set juju-gui secure=true|false ?
<rick_h_> marcoceppi: no, we'd just only listen on 443 and leave 80 alone so you can colo a web site on that machine
<rick_h_> zchander: ooh, yea try that :)
 * rick_h_ is looking
<frankban> zchander: yes, that's used to make the GUI use http
<rick_h_> zchander: just beware then that your admin secret can be traveling over the clear
<zchander> (It is what I tried and the warning about my browser (Safari) is showing, but it won't get any further
<rick_h_> zchander: so it's not recommended, but there
<rick_h_> zchander: ah, safari support is coming this week
<zchander> rick_h: I know, but it is for my prove of concept at the moment
<rick_h_> zchander: it'll warn you about it for now
<rick_h_> zchander: chrome, firefox, or IE 10 will get you in ok
 * rick_h_ reads backlog to get an idea of what's going on 
<rick_h_> oh looks like this is a running conversation
<zchander> When I do a tail for the guiserver.log I get the following messages:
<zchander> [I 140311 13:03:39 handlers:87] GET /ws (192.168.3.1) client connected
<zchander> [I 140311 13:03:40 handlers:115] GET /ws (192.168.3.1) Juju API connected
<zchander> (192.168.3.1 is the IP of my MAAS controller(s) )
<rick_h_> is that the same as your state server?
<rick_h_> zchander: it should be connecting to the juju state server to talk over the api, nothing to do with maas
<zchander> With my state server, you mean my region/cluster controller? -> yes
<rick_h_> huh? do you have a juju environment bootstrapped?
 * rick_h_ isn't up on what you've got setup here
<zchander> My juju bootstrapped node is 192.168.3.13
<rick_h_> ok, that's what the guiserver should be talking to. Something is confused?
<zchander> rick_h: is that mentioned in some config file?
<frankban> rick_h_: I think 192.168.3.1 is the connection client
<rick_h_> frankban: would be his maas controller?
<zchander> I am starting Chrome right now...
<rick_h_> zchander: so you've got maas, installed open stack, and created an environment?
<zchander> I set up MAAS (using an online tutorial), created an environment, bootstrapped juju, deployed juju-gui
<frankban> rick_h_, zchander: not sure, what's the output of http://GUISERVER/gui-server-info?
<zchander> {"uptime": 2184, "deployer": [], "apiversion": "go", "sandbox": false, "version": "0.3.0", "debug": true, "apiurl": "wss://tntn7.cluster001.nimeto.edu:17070"}
<zchander> tntn7.cluster001.nimeot.edu if the juju bootstrapped node
<frankban> zchander: ok, so that's configured correctly
<jcastro> rick_h_, I'll ping you about ~10 min before
<rick_h_> jcastro: coolio thanks
<zchander> For your info: We have our school LAN, connected to eth1 on my MAAS controller. My MAAS controller is connected to my 'cluster' over eth0 (192.168.3.0/24). IP forwarding from the 'cluster' is working
<jcastro> 2 hours if I'm reading the schedule correctly
<rick_h_> jcastro: yep
<rick_h_> jcastro: just getting my plan together
<zchander> I would like to be able to connect to charms (juju-gui, wordpress(??) and/or owncloud) from my school LAN (Our intent is to set up some 'private cloud' for our students
<jcastro> rick_h_, basically think of this one as a normal status report
<jcastro> except with more people
<jcastro> marcoceppi, if you could check out the syncope bundle today that would be swell
<rick_h_> jcastro: ok cool, wasn't sure how much was more mug-like "look awesome" talk vs "what we're doing, what's coming up"
<jcastro> no, it's a working summit, so no slides or anything
<rick_h_> j
<rick_h_> k
<jcastro> maybe we could do a little screencast showing the stuff you like, etc. I'll walk you through it
<rick_h_> zchander: ok, so curious what you get when you have chrome running and load up the gui
<marcoceppi> jcastro: has it passed a +1?
<rick_h_> jcastro: yea, will be ready to screenshare
<jcastro> marcoceppi, not sure, let me check
<marcoceppi> jcastro: because lazyPower is on review this week ;)
<jcastro> lazyPower, can I get a -1/+1 on the syncope bundle? It's in the queue. The charm is already in
<frankban> zchander: could you please repeat what's the problem?
<zchander> frankban: brb, helping a student at the moment
<zchander> frankban: I am trying to deploy one or more charms in my MAAS/juju environment. Also I would like to be able to connect to these charms, e.g. through a (reverse) proxy
<zchander> frankban:  this is the config the virtual host (reverse proxy) right now: http://paste.ubuntu.com/7073510/
<frankban> zchander: what problems are you encountering while deploying charms from the GUI?
<zchander> As I have mentioned before, it is a proof of concept/test environment, so security isn't that important at the moment
<zchander> frankban: I can't get to the point I can deploy charms from juju-gui
<zchander> I also have/had problems connecting them through my browser
<frankban> zchander: so does the GUI open and connect to Juju?
<zchander> Nope....
<frankban> zchander: so you see the "connecting to Juju" splash screen?
<lazyPower> jcastro: ack
<zchander> All I see (in Chrome and Safari) is the 'Connecting to the Juju environment' page, with a progress inficator
<zchander> *indicator
* lazyPower changed the topic of #juju to: Reviewer on Duty: lazyPower || Welcome!! Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP
<frankban> zchander: any errors in the chrome js console?
<zchander> lazyPower: Thanks for your help, yesterday. Sorry I had to go so unexpectedly....
<zchander> frankban: WebSocket connection to 'ws://node001.nimeto.edu/ws' failed: Error during WebSocket handshake: Unexpected response code: 400
<lazyPower> zchander: np
<frankban> zchander: so a bad request sent from the browser to the GUI node
<zchander> frankban: Could this be due to my apache reverse proxy?
<lazyPower> marcoceppi: http://paste.ubuntu.com/7073559/
<lazyPower> what'd i do wrong?
<marcoceppi> lazyPower: you need 1.2.10 which isn't released which fixes that error
<lazyPower> ack
<marcoceppi> but you're basically getting a fatal error, and an exception is being thrown before the fatal error can be revealed
<marcoceppi> because unittests
 * marcoceppi drops the patch
<lazyPower> jcastro: minor error in the bundle, they've targeted a release that doesn't exist yet
<jcastro> heh
<frankban> zchander: that's wat I was thinking
<lazyPower> easy fix though
<jcastro> "Does not pass review, makes assumptions in the space time continuum."
<lazyPower> well in the grand scheme of things, its opening a black hole
<lazyPower> but far be it for me to stifle their creativity
<frankban> zchander: I am not an apache reverse proxy expert, and I am not sure about how mod_proxy heaves when handling websocket connections
<frankban> zchander: perhaps you need http://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html ?
<zchander> frankban: Thanks, I am firing up google at the moment you mentioned it ;)
<zchander> Seems I have to build the module, as there is no mod_proxy_wstunnel for apache 2.2 (I am running Ubuntu 12.04.4)
<lazyPower> marcoceppi: https://bugs.launchpad.net/charms/+bug/1289263
<_mup_> Bug #1289263: Syncope bundle <Juju Charms Collection:New for francesco-chicchiricco> <https://launchpad.net/bugs/1289263>
<lazyPower> +1'd with a single character edit
<lazyPower> i tested it with the drag and drop test on the gui
<marcoceppi> lazyPower: did you actually get proof to run?
<lazyPower> no
<lazyPower> proof hates life
<lazyPower> i made it walk the plank
<marcoceppi> :\
<lazyPower> jcastro: should we maybe update the docs on https://juju.ubuntu.com/docs/charms-bundles.html - so it doesn't contain the envExport?
<marcoceppi> it needs to pass proof before you can really sign off on it, I'm rolling a new release for it atm
<lazyPower> charles@Bushido:~/tmp/revq/bundle$ juju charm proof
<lazyPower> charles@Bushido:~/tmp/revq/bundle$
<lazyPower> marcoceppi: it passes proof
<marcoceppi> you just said it didn't?
<lazyPower> it didnt hte last time i ran it (Before the one line edit)
<marcoceppi> lazyPower: ah, that was probably why it vomitted
<frankban> zchander: :-/ let me know if it works, and please double check removing chrome caches: sometimes browsers get confused when handling websockets/caches
<lazyPower> targeting a revision of the charm that didnt exist :)
<lazyPower> charmworld api said "nope"
<marcoceppi> lazyPower: right, I just uploaded tothe ppa, could you re-run it with the wrong version when it builds to verify you no longer get Mr Angry Eyes?
<lazyPower> sure
<lazyPower> marcoceppi: no charm tools update exists for me
<lazyPower> did you release a saucy package?
<marcoceppi> lazyPower: I just uploaded it ot ppa, it needs to build first
<lazyPower> oooooo
<marcoceppi> queue is about 20 mins
 * lazyPower pins this
<lazyPower> hey our drupal friends pushed a new drupal charm
<lazyPower> https://bugs.launchpad.net/charms/+bug/1290636
<_mup_> Bug #1290636: New drupal charm submission. <Juju Charms Collection:New> <https://launchpad.net/bugs/1290636>
<marcoceppi> lazyPower: um, not the same drupal guys
<lazyPower> ah, well, here's a new contender all the same
<marcoceppi> lazyPower: this one doesn't even tell what version of Drupal it deploys, considering not all Drupal's are made equal
<marcoceppi> ohhh, it's using what's in the archive
<lazyPower> i havent started reviewing it. I'm at VEM atm
<jcastro> lazyPower, I can fix that up in the docs now
<zchander> 'make' is running. Following the tut from http://serverfault.com/questions/290121/configuring-apache2-to-proxy-websocket to create the module
<natefinch> jcastro: do you have the link to the hangout for the juju UDS?
<jcastro> http://summit.ubuntu.com/uds-1403/meeting/22202/intro-by-jono-bacon/
<jcastro> each session on the schedule has a page with the hangout
<natefinch> jcastro: I need to be *in* the hangout, though... and I don't see a link to join the hangout there.
<jcastro> oh, for the plenary I don't think he gives out the URL
<lazyPower> Well, its on ubuntuonair.com
<lazyPower> if that helps
<jcastro> I think you can just ping him if you want to join the hangout
<natefinch> jcastro: hmm... maybe I have my days mixed up,  I thought there was a juju-specific thing at 1400, but the schedule says no
<jcastro> now is the kickoff plenary
<jcastro> and then the GUI update
<lazyPower> wait, no. its not. this is his QA from the 7'th
<jcastro> UDS  is at summit.ubuntu.com, not ubuntuonair
<natefinch> jcastro: oh, it's tomorrow.  Huh, ok
<jcastro> lazyPower, incoming PR
<zchander> frankban: I built the module, enabled it, but I still get the error(s)
<zchander> In addition I get a Exception I/O handler for fd 14
<zchander> frankban: //paste.ubuntu.com/7073964/
<nessita> hello! I'm having an issue trying to bootstrap a local provider in a precise instance. I have added the ppa:juju/devel repo and updated the sources and installed all updates. I also installed the 8.0-37-generic kernel as per the https://juju.ubuntu.com/docs/config-LXC.html doc.
<nessita> When trying to bootstrap the local env I get:
<nessita> $ juju bootstrap
<nessita> ERROR failed verification of local provider prerequisites: installed version of mongod (2.0.4) is not supported by Juju. Juju requires version 2.2.4 or greater.
<nessita> any ideas how to solve?
<lazyPower> nessita: do you have the juju-mongodb package installed?
<nessita> lazyPower, nopes, and does not seem available in the repo, $ sudo apt-cache policy juju-mongodb
<nessita> N: Unable to locate package juju-mongodb
<nessita> I do have mongodb-server Installed: 1:2.0.4-1ubuntu2.1
<lazyPower> marcoceppi: whats the juju mongodb package? i seem to have forgotten
<lazyPower> apt-cache isn't being very helpful
<marcoceppi> juju-db
<marcoceppi> or juju-mongodb
<marcoceppi> can't remember
<nessita> checking
<marcoceppi> nessita: did you install juju-local
<nessita> marcoceppi, yeah, I did
<marcoceppi> that's all you really need, it'll set up the dependency chain
<marcoceppi> oh, okay
<nessita> marcoceppi, I m following https://juju.ubuntu.com/docs/config-LXC.html on a precise canonistack instance
<nessita> but I just realized I added the devel ppa but not stable, so I will do that
<marcoceppi> nessita: well, that should work
<nessita> marcoceppi, without having the stable ppa, mongod is 2.0.4-1ubuntu2.1 which apparently is too old
<nessita> added stable ppa and udpating
<marcoceppi> nessita: right, you need either the cloud-tools pocket orthe stable ppa
<nessita> mongodb-server update coming!
<nessita> *great*, I knew this was PICNIC
<marcoceppi> nessita: how did you even install juju-core?
<marcoceppi> it's not in precise
<nessita> marcoceppi, I installed juju-local
<nessita> is on the juju/devel ppa
<marcoceppi> OH
<frankban> zchander: uhm, Too many open files... weird. you could try  investigating the juju-gui machine. ssh into it. also restarting the GUI server might help (i.e. "service guiserver restart" on the GUI node)
<marcoceppi> yeah, it's recommended to add stable if you have devel nessita
<marcoceppi> we should make that more clear in the docs
<nessita> marcoceppi, yeah, you mentioned this already, sorry, is me that I forgot
<zchander> frankban: I'll try to restart the juju-gui machine first.
<marcoceppi> nessita: well it should be in the docs
<nessita> marcoceppi, I need to fix our HACKING docs, which I will do right now
<zchander> I'll be the last thing I'll try for now, as I am going home in a few minutes. Might be back again tonight, after dinner
<nessita> lazyPower, marcoceppi: thanks for your help, and sorry for the unnecesasry ping
<marcoceppi> nessita: psh, np! anytime
<lazyPower> :)
<lazyPower> happy to help
<lazyPower> jcastro: https://bugs.launchpad.net/charms/+bug/1289291
<_mup_> Bug #1289291: New Charm proposal: GNU Cobol sample <new-charm> <Juju Charms Collection:New> <https://launchpad.net/bugs/1289291>
<lazyPower> Does this warrant a review or should I skip it for now and mark it as incomplete?
<jcastro> come to it later
<jcastro> the guy says it's not ready yet
<jcastro> and tbh we need to get the bundles in
<jcastro> though a review wouldn't hurt, it's just not a "omg today" review
<lazyPower> ack
<lazyPower> jcastro: most of the bundles have been +1'd already
 * jcastro nods
<jcastro> marcoceppi, syncope bundle has been +1'ed
<jcastro> https://bugs.launchpad.net/charms/+bug/1287871
<_mup_> Bug #1287871: Bundle submission: Hadoop <Juju Charms Collection:New> <https://launchpad.net/bugs/1287871>
<marcoceppi> jcastro: ack, I'll set some time aside today to review the +1'd stuff
<jcastro> https://bugs.launchpad.net/charms/+bug/1287328
<_mup_> Bug #1287328: Bundle submission: Simple mediawiki <Juju Charms Collection:New for jorge> <https://launchpad.net/bugs/1287328>
<jcastro> https://bugs.launchpad.net/charms/+bug/1287317
<_mup_> Bug #1287317: Bundle Submission: Simple MongoDB bundle <Juju Charms Collection:New for jorge> <https://launchpad.net/bugs/1287317>
<jcastro> that's all of them
<jcastro> <3
<marcoceppi> ta
<lazyPower> omg
<lazyPower> marcoceppi: my first +1 review that has amulet tests embedded in teh charm
 * lazyPower is jazzed
<lazyPower> https://code.launchpad.net/~michael.nelson/charms/precise/elasticsearch/trunk
<marcoceppi> http://i.imgur.com/fL4ACUT.gif
<lazyPower> exactly
<lazyPower> marcoceppi: https://bugs.launchpad.net/charms/+bug/1287871
<_mup_> Bug #1287871: Bundle submission: Hadoop <Juju Charms Collection:New> <https://launchpad.net/bugs/1287871>
<lazyPower> another +1'd bundle
<marcoceppi> we should tag these with something so I can easily filter them
<marcoceppi> like a `ready-promulgate` tag
<lazyPower> i can go back and do that if you'd like on the reviews i've done today
<lazyPower> i was tagging the cards as +1
<marcoceppi> lazyPower: oh, that's fine too
<marcoceppi> if the cards are assigned to me
<hazmat> geekmush, if you have a chance to try i uploaded a new version of the digitalocean plugin to pypi, and dropped the dep on dop
<geekmush> I just ran the pip update â¦ let's see if it bootstraps!
<lazyPower> marcoceppi: negative. I havent been building promulgation cards
<marcoceppi> lazyPower: they it's up to you
<marcoceppi> either cards or tag the bugs
<lazyPower> easier to tag the issues since i'm already in there. I'll take that route
<geekmush> hazmat:  same error â¦ how can I check to see if my update did anything?
<hazmat> geekmush, $ pip list | grep docean
<hazmat> should show  juju-docean (0.2.0
<geekmush> no "list" command to pip?
<geekmush> pip 1.0 from /usr/lib/python2.7/dist-packages (python 2.7)
<geekmush> if that helps
<hazmat> geekmush, what linux/mac version are you on?
<geekmush> hazmat:  mac os mountain lion
<geekmush> err, duh
<geekmush> linux ubuntu 12.04 lts
<geekmush> (forgot my window was on DO â¦ ha)
<lazyPower> marcoceppi: reviews have been tagged: ready-promulgate
<lazyPower> filter and promulgate away sir
<hazmat> geekmush, can you pastebin the output of $ pip install -v -U juju-docean
<geekmush> that did a lot more stuff than the other update ...
<geekmush> and it looks like it's doing something now in bootstrap!
<hazmat> geekmush, cool!
<geekmush> the "pip install -U python-digitalocean" wasn't enough to trip it, I guess
<hazmat> geekmush, yeah.. cause i foobar'd the package name.. its actually juju-dcoean
<hazmat> er.. juju-docean
<geekmush> hazmat:  I kinda wondered â¦  :)
<geekmush> it's chugging along, looks like â¦ woot!
<hazmat> geekmush, also most of the plugin commands do pretty verbose output with -v
<marcoceppi> lazyPower: ack, thanks
<hazmat> like progress indicators on boot and add-machine
<geekmush> hazmat:  I like verbose output!
<geekmush> hazmat:  makes me feel like I'm getting my money's worth .. haha
<hazmat> infinite value * 0 ;-)
<geekmush> well, crap, the bootstrap completed â¦ now I find myself in the awkward position of coming up with a bright idea to *do* something with juju!
<geekmush> I guess, the good old wordpress + mysql sample?
<hazmat> geekmush, yeah.. why not.
 * hazmat yearns for a better does it float example
<geekmush> my real goal is to see if I can use this thing to bank out ceph environments easier ...
<hazmat> geekmush, owncloud is also nice
<hazmat> geekmush, oh.. nice
<hazmat> geekmush, the lack of volume storage in DO might make that a little akward
<geekmush> oh sure, this is just to see if juju will do what I want
<geekmush> DO is fast and cheap!
 * hazmat nods
<geekmush> I've got a BUNCH of to-be-retired backup servers with (what used to be) big disk on them looking to get repurposed
<geekmush> if it works on DO, tho, I got lots of other projects that need rapid deployment, too
<hazmat> geekmush, for ceph.. your probably going to need to create loopback devices
<hazmat> to pass in when deploying ceph... the new juju run facility (juju 1.17+) might help.. its like parallel remote exec
<geekmush> fun â¦ I guess I'll putz with it a bit today, as I have time
<hazmat> geekmush, cool, i'll close out the issue then.. feedback/issues filed appreciated. thanks
<geekmush> hazmat:  thanks for writing the software!!
<melmoth> i used to be able to get charm behind a proxy with charm and some http_proxy command.
<melmoth> not anymore
<melmoth> :-(
<melmoth> why is it keep changing the way it behave ?
<hazmat> melmoth, in juju 1.17+ if you set proxy on the env (it has config options for them) it will propgate the env vars through to the charm hooks (and also setup apt proxies on the machine)
<melmoth> well, i have been told 1.17 is devel , and not supported
<melmoth> as i m trying to have the same kind of env as the customer i m suppose to support....
<melmoth> and it used to work before.. that s the main painfull point
<geekmush> ummmâ¦I'm confused â¦ what exactly does "expose" do?  I thought that you had to "expose" a service in order to get to it or some such, but my wordpress demo â¦ I hit the IP before I exposed it (by accident) and it comes up anyway
<geekmush> I see the bit flipped in the output of "juju status", but otherwise, no visible effect
<hazmat> geekmush, exposed will have no effect in docean
<hazmat> geekmush, its based on manipulating the provider's network security rules to the instance, digitalocean has no notion of such
<hazmat> and manual provider based plugins can't intercept them.. juju needs to grow iptables management for this to be meaningful in docean
<geekmush> hazmat:  ok, cool â¦ any idea what I should expect in a MaaS situation?  will we need to teach it to tweak our FW stuffs?
<hazmat> geekmush, yes you would
<geekmush> hazmat:  good data points, thanks!
<hazmat> geekmush, effectively expose is meaningful in cloud envs only (azure, ec2, openstack).
<hazmat> atm
<geekmush> i c
<geekmush> well, it workie â¦ woot!  http://162.243.91.205/
<geekmush> I hope I have time later to come back around and futz more, but food, work, work, work ..
<bodie_> trying to run through this http://marcoceppi.com/2013/07/compiling-juju-and-the-local-provider/ -- is this outdated?
<bodie_> I'm getting 'cannot find network interface "lxcbr0": net: no such interface' when I run juju bootstrap -e
<bodie_> which I guess means I need to configure lxc
<marcoceppi> bodie_: https://juju.ubuntu.com/docs/config-LXC.html is the best version
<bodie_> er, bootstrap -e local*
<bodie_> thanks
<bodie_> oh, I'm trying to do it myself since I'm on Debian
<bodie_> If I *really* need to I'll just make a ubuntu VM I guess, but I don't see why it wouldn't just work
<jcastro> we have a vagrant box that will probably be less work than making a VM from scratch btw
<bodie_> mkay, cool
<jcastro> I would very much like Juju to just work ootb on Debian but we're short on people and testers to make that happen
<marcoceppi> bodie_: yeah, then the compile instructions should work
<bodie_> It kinda looks like just a minor configuration detail of LXC
<marcoceppi> bodie_: you might just be able to grab the deb packages from ubuntu
<bodie_> but I'll just do what works :)
<bodie_> jcastro, you mentioned a vagrant box?  Is there a link to the config?  I've never used vagrant so pardon me if I'm missing something obvious here
<marcoceppi> bodie_: https://juju.ubuntu.com/docs/config-vagrant.html
<jcastro> yeah one sec
<bodie_> neato, thanks
<bodie_> I see, this is cool
<lazyPower> bodie_: one of the quickest ways to get started. You can even use sshuttle to "vpn" your traffic through the vagrant host to test deployments.
<bodie_> The reason I'm getting set up with this is to get rolling on core dev
<bodie_> is there a diagram anywhere?  I have the godoc obviously but ...
<zchander> Good evening to all
<zchander> lazyPower: Seems that my reverse proxy breaks PXE boot
<lazyPower> interesting, how so?
<lazyPower> is it proxying all requests to the reversed proxy?
<zchander> Seems so, but it shouldn't...
<zchander> The default virtual host doesn't have any proxy info
<zchander> I did have to mention my maas controller explicit in a virtual host in order to be able to contact it
<zchander> (for the web interface)
<lazyPower> zchander_: i'm not positive but it sounds like there's a problem with the apache config in general. It shouldn't be proxying your pxe boots back to that host if the server matching is happening correctly.
<zchander> Is there any difference between the 12.04.4 release of Ubuntu and later versions (say 13.10)?
<zchander> I am still able to test other version
<zchander> *versions
<lazyPower> zchander_: quite a bit of differences under the hood with service versions, packages, etc.
<lazyPower> plus 12.04.4 is LTS, while 13.10 is not
 * lazyPower afk's briefly
<zchander> That's the reason I wanted to use 12.4 ;)
<zchander> But is the configuration I am wanting to use, so unusual?
<rick_h_> marcoceppi: jcastro either of you give me a hand? I've got a azure env where a service lost his agent?
<rick_h_> https://pastebin.canonical.com/106279/
<marcoceppi> oh no, where did he put it!
<marcoceppi> rick_h_: can you ssh in to that unit?
<rick_h_> marcoceppi: trying, getting denied atm
<marcoceppi> rick_h_: can you ping the machine? does it appear online int he console? is azure doing maintenance right now?
<rick_h_> it did maint yesterday on it. The IP address reported via the GUI in the env isn't in the list of azure machines in the azure controls
<rick_h_> but it was fine at EOD yesterday and seems to have gone awol today
<rick_h_> marcoceppi: now getting rity
<rick_h_> ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: x509: certificate signed by unknown authority
<marcoceppi> rick_h_: is the machine there? I think azure might give it a new ipaddress
<rick_h_> so it's confusing. There three machines in the azure control panel. I've ssh'd to each of them and none of them have jenkins on it.
<rick_h_> marcoceppi: but juju status was showing the gui server, and I can try to ssh to it, but it's denying me access
<rick_h_> marcoceppi: and now when I juju status againto get the address, I'm getting the cert error
<marcoceppi> rick_h_: it sounds like azure is in serious flux right now
<rick_h_> marcoceppi: heh, yea
<rick_h_> marcoceppi: sounds like I'll be rebuilding my env soon :/
<marcoceppi> that's bazaar
<marcoceppi> rick_h_: I'd wait 20-30 mins if you can then try a juju status again
<marcoceppi> see if it settles down
<rick_h_> marcoceppi: k
<marcoceppi> http://i.imgur.com/6SlZMhC.gif
<rick_h_> marcoceppi: wtf, now I've got 4 machines in my env
<marcoceppi> rick_h_: http://i.imgur.com/E1zLDEV.jpg
<rick_h_> but azure panel shows 3 still...but should only have two :/
<rick_h_> ok, env is toast, will blow up and start over tomorrow. Yay for backup procedure testing
<marcoceppi> \o/
<rick_h_> thanks marcoceppi, at least it's nothing normal I can just "xxxxxx" from
<lazyPower> zchander_: I wouldn't think so
<davecheney> psivaa: yes, assuming the ip has not changed
#juju 2014-03-12
<themonk> marcoceppi: hi
<themonk> i have a apache2 mod now i deploy apache2 now how i install my mod in it, do i make a charm for my mod and run this command "juju deploy --to=1 myapache_mod_charm" is this the only way to do this?
<marcoceppi> themonk: do you have to compile the mod specially? I think there's a config option for apache mods on the charm
<themonk> marcoceppi: this is a custome mod :) and it has a conf and load file for mods-available and i made a binary mod.so from src
<marcoceppi> themonk: I'd recommend making your apache_mod_charm a subordinate charm then
<marcoceppi> that way you can deploy it without having to use the --to command
<themonk> marcoceppi: hmm i was reading subordinate charm doc its not clear to me how i will do it. is there any charm like this. a subordinate charm to apache2 charm
<marcoceppi> there's no subordinate charm like yours for the apache2 charm, but there are quite a few subordinate charms
<themonk> marcoceppi: hi, i am back. :) can you give me a charm name?
<themonk> marcoceppi: i was looking Gunicorn
<themonk> marcoceppi: it is a subordinate charm.
<themonk> i cant understand add-relation. say juju add-relation apache2 mycharm and juju add-relation mycharm apache2, is there any difference?
<zchander> ping frankban
<frankban> zchander: morning
<zchander> Good morning frankban. I have recreated my MAAS environment this morning, using 13.10
<zchander> Going to try that
<frankban> zchander: sounds good
<zchander> I am at the point to import the PXE files. Will start juju when that's done
<zchander> Do you have any recommendations regarding the PXE system? precise, quantal, raring, saucy?
<frankban> zchander: I don't know maas enough to give recommendation. the only constraint from the GUI perspective is that the GUI node must be precise
<zchander> Ah... Going to use that
<zchander> frankban: I am going to test the 'reverse proxy route' using 'subfolders' instead of virtualhosts
<frankban> zchander: makes sense
<zchander> Yep, got to the point I am going to make the apache2 config for juju-gui
<phedny> I'm trying to setup my first juju system with the wordpress+mysql charms example, but it gets stuck in a situation where machines "1" and "2" have instance-id: pending
<phedny> I have already disabled ufw
<phedny> accorading to mailing list this my be the result of template to be downloaded, but is there a way where the download is active and how far the progress is?
<lazyPower> phedny: what version of juju are you running?
<lazyPower> phedny: if your instance id's are pending, the hosts are not spinning up. I assume you're using the local provider?
<phedny> agent-version: 1.16.6.1
<phedny> yes, I'm using the local provider
<lazyPower> do you see the machines listed in sudo lxc-ls?
<phedny> I only get "mark-local-machine-1"
<lazyPower> did you update juju after you bootstrapped your local environment?
<phedny> no, I basically followed https://juju.ubuntu.com/docs/config-LXC.html on a clean 12.04 LTS
<lazyPower> hmm...
<lazyPower> If you've waited a reasonable amount of time (5 minutes should be plenty for getting 2 lxc containers spun up) can you tryd estroyiing the environment and restarting?
<phedny> I waited over 30 minutes ;)
<lazyPower> yikes
<phedny> let me try to destroy and start again
<lazyPower> yeah, lxc containers are pretty quick, and getting quicker in one of the revisions coming down the pipeline
<lazyPower> phedny: let me know if it continues to hang and give you problems. We'll need to aggregate some facts about the environment.
<phedny> okay.. I entered all commands again, in machine-id: pending state, so let's give it some time again
<zchander> frankban: When trying the 'non-virtualhost' approach, I get 404 errors. see: http://paste.ubuntu.com/7079340/
<zchander> This is my config for now: http://paste.ubuntu.com/7079344/
<lazyPower> phedny: can you tail $HOME/.juju/local/logs/machine-0.log and look for errors?
<lazyPower> the last time I ran into this, juju was on the same network segment and i had ip address collisions.
<phedny> lazyPower: I get only there error messages:
<phedny> 2014-03-12 13:42:13 ERROR juju apiclient.go:116 state/api: websocket.Dial wss://localhost:17070/: dial tcp 127.0.0.1:17070: connection refused
<phedny> 2014-03-12 13:42:13 ERROR juju runner.go:211 worker: exited "api": websocket.Dial wss://localhost:17070/: dial tcp 127.0.0.1:17070: connection refused
<phedny> the remainder are mostly DEBUG level with some json and I saw some PGP blocks
<lazyPower> but it bootstrapped and returned without error?
<phedny> bootstrap didn't return any errors
 * lazyPower if baffled
<lazyPower> s/if/is
<lazyPower> why would your state server be denying requests if it bootstrapped ok?
<phedny> netstat shows me a listening socket on [::]:17070
<lazyPower> phedny: i dont have a good resolution for you. My thought is to open a bug against juju-core with your log output.
<themonk> for subordinate charm how do i target apache2 only, if i do not want to fork apache2 ?
<themonk> my perpous is to install a custome apache module
<marcoceppi> themonk: you don't really, you just tell people in the README to only add it to apache2
<themonk> marcoceppi: i am depending on juju-info here ryt and every charm implicitly has it, so apache2 and say nginx provides interface http and if i have both of them then my subordinate charm will triger both of them ryt?
<marcoceppi> themonk: juju-info is iplicit, yes
<marcoceppi> If you wanted to make it ONLY available for apache2 you'd have to add a new interface to the apache2 charm
<marcoceppi> but there's nothing wrong with it just being a subordinate
<marcoceppi> just prefix the charm name with apache2 so people know it's an apache2 only subordinate
<marcoceppi> apache2_mod_yourmod
<themonk> marcoceppi: i am just thinking deploy --to <apache2 machine> is much easier :)  an then i can use add-unit to replicate but will it trigger if i do config change in my modcharm?
<marcoceppi> themonk: if you add-unit to either your charm or apache neither will scale with each other
<marcoceppi> --to is not a very good solution
<themonk> marcoceppi: hmm i understand :)
<themonk> marcoceppi: i want to show you my metadata
<marcoceppi> themonk: oka
<themonk> marcoceppi: http://pastebin.com/GnHGT36w
<themonk> marcoceppi: is it ok ?
<themonk> marcoceppi: hello are you there?
<marcoceppi> themonk: the paste link didnt' work
<themonk> marcoceppi: it was set for 1h
<marcoceppi> themonk: ah, sorry, I was afk for a bit
<themonk> marcoceppi: ok doing again
<themonk> marcoceppi: no problem :)
<themonk> marcoceppi: http://pastebin.com/xQxs0FGP
<marcoceppi> themonk: well, that's one way to do it
<marcoceppi> but that implies that it'll work on haproxy, varnish, etc
<themonk> marcoceppi: yes yes how i fix it
<marcoceppi> themonk: just use juju-info
<themonk> juju-info:
<themonk>      interface: juju-info
<themonk>      scope: container
<themonk> marcoceppi: you mean remove website: interface : http and use it https://gist.github.com/anonymous/c08c66103454c2bfcacd
<marcoceppi> themonk: pretty much, though call the relation something like apache2-mod instead of juju-info. but just use teh juju-info interface
<themonk> marcoceppi: hmm ok
<jcastro> marcoceppi, did my bundles not get pushed yet?
<marcoceppi> jcastro: npt uet
<jcastro> marcoceppi, is there a way you could partially pull a PR?
<jcastro> like say, the manual provisioning page only and ignore the other parts of my PR?
<jcastro> I'd like to get the mention of null out of the docs asap
<jcastro> or, is there a trick for me to resubmit only X changes?
<marcoceppi> jcastro: it depends
<marcoceppi> jcastro: were they done in two commits?
<jcastro> yes
<marcoceppi> jcastro: then yes
<marcoceppi> jcastro: I'll cherry pick your commit after lunch
<jcastro> oh man, awesome
<jcastro> jut got a mail from a guy using Juju to deploy a wordpress blog, he's migrating from this: http://lquest.org/
<marcoceppi> jcastro: sweet, let him know he can ping me with any questions
<jcastro> seems like he's deploying to LXC, but wants to access the blog from the outside
<jcastro> http://askubuntu.com/a/282415
<jcastro> is this still our best bet?
<marcoceppi> jcastro: you def need to set up a bridge
<marcoceppi> but the dhcp settings will change depending on provider
<jcastro> yeah I recommended manual provider instead
<jcastro> before realizing it still has the null junk in it
<marcoceppi> jcastro: https://github.com/juju/docs/pull/30
<marcoceppi> jcastro: I also created a video of how I cherry picked the commit, it's uploading to youtube atm
<jcastro> brilliant
<jcastro> oh I see, you resubmitted it.
<marcoceppi> there's no sound, and it's actually pretty low qual
<jcastro> I suppose it's bad form to approve your PR of my PR?
<marcoceppi> jcastro: yeah, it still needs to be approved, I just split it out
<marcoceppi> jcastro: I mean, it lgtm, but get like lazyPower or someone to ack it
<marcoceppi> jcastro: https://www.youtube.com/watch?v=1VWsmr_HdFU
<jcastro> I think by low sound you mean no sound
<jcastro> heh
<marcoceppi> I should probably make a better video
<marcoceppi> where I narrate it
<lazyPower> jcastro: approved
<jcastro> since I have your attention(s)
<jcastro> https://code.launchpad.net/~charmers/juju-core/github-docs
<jcastro> is the place where you can click the button to import the github branch into launchpad
<jcastro> you'll want to hit the button in cases where you want the latest changes from GH to run with the next docs regen cron job
<marcoceppi> jcastro: cool, also, since this was a cherry pick, if you look at your other PR, the one that had null provider and quickstart, you'll see it only shows the quickstart stuff now
<jcastro> nifty
<lazyPower> does the button only show up when theres open differences in the branches? I see no such button.
<lazyPower> oh i'm not logged in, hang on
<jcastro> you'll see it when you're in ~charmers
<lazyPower> ah i see it
<lazyPower> oh right! i need to craft my letter to petition the group for a charmer tag
<lazyPower> so much to do, so little time in the day
<bodie_> how does Juju deal with outages?
<marcoceppi> bodie_: depends on the kind of outage
<bodie_> maybe I'm misunderstanding it a bit as a state map where it's more a system for choreographing a service network and then deploying it
<bodie_> so I guess my real question is whether juju is more about a state service which knows the state of its nodes, vs. more oriented to choreography or planning
<bodie_> provider-level outage, in other words
<bodie_> let's say a node where 3 of our services reside goes dark
<marcoceppi> sure, each agents ping the bootstrap node as a healt check
<marcoceppi> so juju knows when agents go missin
<marcoceppi> lets say there's a network blip, and your 3 nodes go offline for 10 mins, juju does nothing. It'll queue events and when the agents re-register (and come back online) it'll push the events out again
<marcoceppi> bodie_: using the API you can add additional logic to juju, say to replace those nodes, but juju doesn't do anything automatically at the moment
<bodie_> I see
<jamespage> marcoceppi, expect a ping from mattgriffin re percona-server charms/support in mysql charm
<bodie_> but it'll at least realize that something's not normal
<jamespage> we just discussed in a session
<marcoceppi> jamespage: ack, thanks
<marcoceppi> bodie_: right, juju status will reflect an outage in the machine listing and the unit
<marcoceppi> saying agent-state: down or missing
<bodie_> righto
<marcoceppi> so it actively knows about the topology it's deployed and to some extent it's health
<bodie_> okay, cool
<bodie_> so...  is there someplace I can find the program flow for what happens when a new charm is deployed?
<bodie_> I mean, obviously the code
<bodie_> but I'm still in overview mode
<bodie_> if not, i'll just get to mapping that
<marcoceppi> bodie_: the docs and then asking questions. The docs are still pretty fluffy and don't dive too deep at the moment
<marcoceppi> there's also a few blog posts floating around
<bodie_> (noticed that) lol
<bodie_> alright :)
<marcoceppi> bodie_: let me find a blog post from gustavo that might help
<bodie_> according to nate the server will bring up a replacement unit if it sees an outage?
<bodie_> awesome, thanks
<marcoceppi> bodie_: http://blog.labix.org/2013/06/25/the-heart-of-juju
<marcoceppi> that might have a bit more information than the docs
<marcoceppi> bodie_: otherwise, if need more indepth stuff feel free to ping in here
<bodie_> :D thanks
<bodie_> right now a stranger in a strange land attempting to worm my way into engaging with core code
<zchander> lazyPower: Reinstalled my MAAS, using 13.10 for the controller. Went the reverse proxy way without virtual host, but that also won't work. (juju-gui now gives me a weird webpage). The side of the story is, that I can see the requests for juju-gui on de node ;)
<lazyPower> ...wat
<lazyPower> zchander: what is de node?
<zchander> de == the (sorry, was talking to my wife and instantly wrote some Dutch words.... ;) )
<lazyPower> oh ok. i was confused about intent
<zchander> What I meant: I do see the request coming on the juju-gui node in guiserver.log
 * zchander banging head against the wall....
<lazyPower> zchander: whats this weird webpage you speak of?
<zchander> lazyPower: I'll try to upload it somewhere.... (have to rescue my MAAS interface at the moment, was a bit too fast with apachectl  :(  )
<zchander> lazyPower: http://postimg.org/image/axpl2ii2r/
<zchander> lazyPower: This is the javascript console: http://postimg.org/image/e4qr3wfe1/
<lazyPower> that was my next request :)
<zchander> Pfew.... got my MAAS web interface back
<lazyPower> ok so its missing the assets - or so it thinks.
<marcoceppi> zchander: juju-gui doen't expect to run in a sub-directory
<lazyPower> so if you look at your javascript console - its not loading anything as the juju-gui assumes everything is going to be loaded off of a root path of /juju-ui
<marcoceppi> so it uses absolute URLs instead of relative
<marcoceppi> rick_h_: ^^
<marcoceppi> zchander: what I'd recommend doing, is instaed of using sub dirs to route requests in the reverseproxy, use subdomains
<rick_h_> lazyPower: marcoceppi yea, don't think things work in non root path atm. It's something we've got to fix coming up
<rick_h_> but not a supported way to service atm
<marcoceppi> zchander: ie, juju-gui.mass-ctrl-001.nimeto.edu
<marcoceppi> rick_h_: ack, thanks for the heads up
<marcoceppi> zchander: then have maas-ctrl-001 reverseproxy route based on host name and not directory
<marcoceppi> if that's possible
<marcoceppi> zchander: it does look like you're close though!
<zchander> marcoceppi: I was doing something like that, and using reverse proxy, but that gave me some other issues (with web sockets)
<marcoceppi> oh, damn, really?
<zchander> it was what I discovered yesterday
<marcoceppi> ah, I'm not sure how to get around that
<zchander> But I would like to retry (as I now use 13.10 instead of 12.04.4)
<marcoceppi> rick_h_: any instructions on how to run juju-gui from behind a proxy?
 * lazyPower afks
<zchander> marcoceppi: Also using the reverse proxy borked my PXE environment, so when I did restart my node(s) yesterday, they didm;t get back up until this morning as I reverted my config to only a default apache environment on my MAAS
<zchander> :D
<zchander> Maybe I should install another node/server with two nics, one connected to the 'cluster lan', the other to our schoolnetwork.
<zchander> And run the proxy on that node
<mmcc> hey folks, I have a quick question - where should I file a bug against the juju.ubuntu.com website? It's just a simple broken link...
<sarnold> mmcc: I believe this is the spot: https://bugs.launchpad.net/juju-website/
<mmcc> sarnold: great, thanks! I was looking for it among the projects here https://launchpad.net/juju-project - no dice :)
<perrito666> hey, I think I have a bug, although it might be a feature:
<perrito666> I am using juju 1.16.3-saucy-amd64
<perrito666> and I created a charm which uses pgsql relation
<perrito666> when the hook for the relation change is triggered, it is triggered twice, once of these times relation-get returns no information on the bash script of the hook
<perrito666> but, if hooked with debug-hooks to the event, in both oportunities relation-get works correctly
<jose> marcoceppi: ping, you'll be running that charm school at uds tomorrow?
<jose> jcastro: ^ ?
<marcoceppi> jose: I'll be there, but jcastro is probably your POC
<marcoceppi> perrito666: that's not a bug
<jose> I wanted to see if it could be ran at ubuntuonair, since we have part of the story of the charm schools, to get it completed
<marcoceppi> jose: i dont see why not
<marcoceppi> perrito666: all hooks need to be idempotent
<marcoceppi> mmcc: which link is broken?
<perrito666> marcoceppi: I know, what I think is a "bug" is that the env in debug-hooks is different from the one the hook is run
<marcoceppi> perrito666: in what way?
<mmcc> marcoceppi: it's the "Overview" link in the footer, I filed this bug: https://bugs.launchpad.net/juju-website/+bug/1291674
<_mup_> Bug #1291674: broken "Overview" link in footer of https://juju.ubuntu.com/resources/ <Juju Website:New> <https://launchpad.net/bugs/1291674>
<marcoceppi> mmcc: ah! thanks for filing that, I'll make sure it gets updated
<perrito666> marcoceppi: this is my hook (for context) https://github.com/perrito666/mezzanine_charm/blob/master/precise/mezzanine/hooks/pgsql-relation-changed
<mmcc> marcoceppi: sure, glad it got to the right person :)
<perrito666> marcoceppi: now, this is run twice in all my tests
<perrito666> marcoceppi: one of those, the first, relation-get returns empty values
<perrito666> but
<perrito666> if I hook to said event, I can not get said behavior
<marcoceppi> perrito666: you're just running in to a race condition
<perrito666> relation-get returns results always
<perrito666> marcoceppi: that was my tought
<perrito666> marcoceppi: I tried a sleep of up to 5 mins to discard that
<perrito666> (in the hook)
<marcoceppi> perrito666: it's still not a bug, it's just that when the first run of relation-changed on mezzanine happens, pgsql hasn't sent it's data yet, so the first relation-changed (which juju guarentess will fire at least once in a relation) goes off
<marcoceppi> perrito666: but data available to the hook doesn't change while the hook is running
<perrito666> marcoceppi: I see :) thank you for your help
<marcoceppi> perrito666: put the sleep in your relation-joined
<marcoceppi> say, just 45 seconds
<marcoceppi> by then psql should be ready, and you should see the first run of relation-changed get fresh data
<perrito666> marcoceppi: Ill do, just for educational purposes, the charm actually works, I was just curious of this behavior
<marcoceppi> perrito666: right, I understand the curiosity, so to guarentee that multiple calls to relation-get work, when the hook is executed it freezes what's available in the relation data wire
<marcoceppi> that way relation-get is consistent for the time of that hook, if relation data changes while the hook is running juju just queues another relation-changed hook fire in the event queue
<perrito666> marcoceppi: makes a lot of sense, thank you again for taking the time to explain :)
<marcoceppi> perrito666: no problem! it occurs to me this would be great to put in the docs
<marcoceppi> any other questions while I'm still around?
<perrito666> marcoceppi: nope, that is it, thanks again
<marcoceppi> perrito666: np!
#juju 2014-03-13
<bodie_> anyone happen to know offhand whether there's an oh-my-zsh plugin for juju?
<rick_h_> bodie_: http://askubuntu.com/questions/108689/how-can-i-get-tab-completion-with-juju-in-zsh
<bodie_> I did see that, but I was thinking of a simple dropin for the plugins spec on oh-my-zsh (it's nice)
<rick_h_> bodie_: heh, while I <3 zsh benji and I aren't big fans of oh-my-*
<rick_h_> bodie_: so no official thing for that I know of
<bodie_> it's a little bloaty, but the lazy in me approves
<rick_h_> yea, I've had enough fun debugging broken things that I had no clue which thing did the breaking so vim, zsh, git, etc I go with my own config
<bodie_> "oh-my-abbynormal"
<bodie_> what's juju-mongodb?
<bodie_> "mongodb for juju" doesn't exactly answer that question lol
<sarnold> bodie_: iirc, it's a mongodb with the javascript engine removed
<sarnold> don't ask me how that can work :)
<bodie_> de juju
<sarnold> but we're not interested in supporting a javascript engine for five years, hence this thing..
<sarnold> .. so that juju can be supported in main
<bodie_> nifty :)
<marcoceppi> it's also mongodb with ssl enabled, which precise didn't have
<jcastro> Just Enough Mongo
<sarnold> really? why wasn't it enabled...?
<jcastro> iirc it was the TLS licensing thing
 * jcastro uses technical terms at this time of night
<sarnold> jcastro: oh. that whole mess. ugh. :)
<tvansteenburgh> jcastro, marcoceppi, et al: as someone getting ramped up on juju, i just want to say these Charm School videos are great, thanks for doing them!
<jcastro> wow awesome!
<jcastro> I am glad people are actually watching them!
<davecheney> jcastro: yup, licencing
<jcastro> I love how I have to give no details
<jcastro> "the TLS thing"
<jcastro> and everyone knows what that is
<davecheney> jcastro: bad vibes, man
<davecheney> although ironically we don't use TLS to talk to the mongodb server anymore
<davecheney> all the clients talk to the api server
<davecheney> which runs mongo locally
<davecheney> it still talks TLS
<davecheney> but this isn't as important
 * davecheney waits for someone to raise a small pedantic exception to my prevoius statement
<sarnold> hrm, the link to the copyright file from http://packages.ubuntu.com/trusty/juju-mongodb is broken
<davecheney> sarnold: broken on every single package
<hatch> Hey, is anyone working on an nginx charm now that it's going to be in Trusty?
<rbasak> frankban: thanks for looking at that juju-quickstart bug. I have another issue with a test failure - are you able to look at this for me for the MIR, please?
<frankban> rbasak: sure, what's the probem?
<rbasak> frankban: http://paste.ubuntu.com/7084383/
<rbasak> frankban: looks to me that the difference is ToMachineSpec
<frankban> rbasak: yeah, this should be fixed in trunk
<rbasak> frankban: do you know which rev, please, so I can cherry-pick for the distro package?
<frankban> rbasak: what's the output of .venv/bin/pip freeze | grep jujuclient ?
<rbasak> frankban: I also noticed that requirements.txt specifies jujuclient==0.11, but we have 0.17.5-0ubuntu1 in Trusty. I don't know if that's relevant.
<rbasak> frankban: there is no virtualenv here. The test is running as part of the package build (an MIR requirement)
<frankban> rbasak: OIC so that's relevant
<rbasak> BTW, I'm on a bad connection. Workmen outside just removed my telegraph pole :(
<rbasak> I may drop.
<frankban> rbasak: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/revision/57
<frankban> rbasak: we plan to make a new pypi release asap, with updated dependencies and some fixes required by changes in juju-core
<frankban> rbasak: we just need to wait for the new juju-core release
<rbasak> frankban: OK, thanks. I'll work with a cherry-pick of that revision if that works, then, and we can update Trusty when you can do a release.
<rbasak> frankban: please can you let me know when you do?
<frankban> rbasak: sure, and thanks for your help
<marcoceppi> Can you pass multiple units to juju remove-unit?
<rbasak> frankban: test-requirements.pip was also missing, so I had to drop that part of the patch. I also dropped the bumping of quickstart.VERSION. Does that sound OK?
<rick_h_> rbasak: he's run to lunch for a few min. I think that sounds ok
<rbasak> BTW, I'm a bit dubious about calling the top level module "quickstart". Using /usr/lib/python2.7/dist-packages/quickstart/ seems ripe for collision.
<mgz> marcoceppi: yes, you can pass N units
<marcoceppi> mgz: ta
<rbasak> rick_h_: thanks
<rick_h_> rbasak: I can understand. In checking pypi there's not much on that space https://pypi.python.org/pypi?%3Aaction=search&term=quickstart&submit=search
<rick_h_> rbasak: if it's something we need to adjust we can jujuquickstart it. I don't think quickstart will be used as a lib so
<rick_h_> rbasak: but in dist-pacakges isn't it juju-quickstart?
<rick_h_> ah, guess not
<rbasak> rick_h_: I don't have a strong opinion. I don't think it should block the MIR. But it's something that I think I should flag with a Debian Python person, to avoid any potential problems in the future.
<rick_h_> rbasak: definitely, and it's something we can adjust if required.
<rick_h_> rbasak: appreciate you looking out for us :)
 * rbasak tries to switch back to his main connection
<zchander> ping frankban
<frankban> zchander: hi
<zchander> Hi, sorry I am bothering you again, but do you (or someone you know) have any knowhow to use 2 nics in a charm? I have just deployed an apache2 charm I am intending to test (yes, again ;) ) reverse proxying traffic from our school lan to the cluster network
<zchander> e.g. how do I set up the second nic in the node to enable traffic from our school lan
<frankban> zchander: I am not sure about that, I guess it depends on whether the apache charm supports that or not. You can investigate looking at the charm's docs, sshing into the deployed service node or asking the charm's maintainer
<frankban> rick_h_: any ideas? ^^^
<rick_h_> yea, I don't think many charms support dual nics natively because most cloud environments give you one nic
<rick_h_> you might be able to write a second nic subordinate I'd guess. Anyone ever try that marcoceppi?
<zchander> Mmmmm, so much for another brainwave :D Seems the only option that is remaining for me, is to deploy a second server which isn't part of MAAS, to act as a reverse proxy (??) Or are there any other ideas to accomplish that
<jcastro> marcoceppi, ok how should I fix these bundles, reupload to new branches?
<jcastro> or can we copy over the ~charmers ones?
<marcoceppi> jcastro: we need to create new branches
<marcoceppi> and then considate multiple bundles
<marcoceppi> like the mediawiki ones
<marcoceppi> using simple namespaces
<marcoceppi> like mediawiki/simple instead of mediaiki-wiki/mediawiki-simple
<rick_h_> marcoceppi: jcastro make sure to do a test one to verify how it looks and such
<marcoceppi> get them all in a branch somewhere, point me at it and I'll express promulgate after proof
<jcastro> not all in one branch though, you mean in their own individual service branches right?
<marcoceppi> jcastro: one branch per bundle(s) for that service
<marcoceppi> jcastro: right, so there would be a mediawiki branch with the two mediawiki bundles in the bundles.yaml file
<jcastro> right, ack
<jcastro> marcoceppi, ok, pushed hadoop
 * marcoceppi looks
<jcastro> for naming, how about "single" and "scalable"?
<jcastro> for say, mediawiki
<marcoceppi> jcastro: sounds good to me
<jcastro> marcoceppi, mediawiki and mongo pushed
<jcastro> that's all of them, all that's left is rails and django
<marcoceppi> jcastro: I'll push mediawiki first
<marcoceppi> to see how it renders
 * jcastro nods
<marcoceppi> we'll see it in about 10 mins
<marcoceppi> jcastro: what's the comming-soon address for jujucharms?
<marcoceppi> apparently, I'm a little M friendly today
<marcoceppi> jcastro rick_h_ looks awesome in the gui
<rick_h_> marcoceppi: woot! and should make nicer quickstart commands
<marcoceppi> jcastro: http://i.imgur.com/BIbDB3j.png
<jcastro> marcoceppi, comingsoon.jujucharms.com
<jcastro> marcoceppi, ok so now to remove old and busted .... ?
<marcoceppi> jcastro: we can't yet
 * rick_h_ hides
<marcoceppi> not until the sometime next week
<jcastro> oh, until rick, got it
<marcoceppi> yeah, otherwise I'll start pushing the other new hotness up
<jcastro> keep on pushing
<jcastro> https://plus.google.com/hangouts/_/hoaevent/AP36tYdEL_9S543oWBGGJFmgI-6Vzdu2cLUpciThZmLeVlDfhr5Uhw?authuser=0&hl=en
<jcastro> Juju Eco Status session will be at that URL ^^ if you want to find out what's happening
<jcastro> we'll go  live in 6 minutes
<jcastro> we're in the spill over room too, so you can ask questions here or in #ubuntu-uds-hallway
<ryanlee> Hello all!  Anyone know what if there is a way to use Juju to deploy multiple Wordpress sites on the same server (using Virtual Hosts or Server blocks)?  Is this in the works?
<mgz> ryanlee: if the charm doesn't support that, you could change the wordpress charm itself to allow for it
<ryanlee> mgz, yeah, I actually was planning on contributing to it, but wanted to see if someone already had done something to make this possible.
<jose> jcastro: can we host future ones at ubuntuonair? just to keep track of all of them in one place
<jcastro> yeah sorry I just didn't have time
<jcastro> we'll do tomorrow's on UOA
<Fishy_> hi!
<marcoceppi> Fishy_: o/
<Fishy_> So looking at using juju, have a Q.  Say I have an app Foo i want to deploy. So I create a Foo charm.  The problem is, Foo needs java installed to work. Do I  a) Create a subordinate service of Java that Foo depends on?  b) Install java in my gems hooks   c) ????
<mgz> Fishy_: most simply, your foo charm installs java in your install hook
<Fishy_> I could easily put 3 services on 1 machine, that all need Java (or some common thing) installed to run
<mgz> ubuntu/debian has package management for a reason
<mgz> though, how well java plays with that has long been open to question
<Fishy_> ya that too
<Fishy_> but also:  say I have 20 instances of Foo around..  I want to upgrade java 1.7.x to 1.7.y.. but i want to roll it out slowly, to make sure it works
<Fishy_> the hook way seems not helpful for that
<Fishy_> but if i wrapped java in a charm
<Fishy_> could roll it out
<mgz> that's still perverse, even with this scenario
<Fishy_> i guess if I just made a new Foo Charm and did an upgrade, the hook could upgrade it
<mgz> java is not a charm it's a bit of infrastructure
<Fishy_> ok so java dont make it a charm
<mgz> the way people have tended to to rolling upgrades like that is have a config value that can be `juju set` on the service to pick a subset of units to upgrade
<Fishy_> do I also need something like puppet to manage the underlying OS stuff like java ?
<Fishy_> im trying to avoid puppet ;)
<Fishy_> Ok so java.version a config value to my Foo charm.. then I can slowly upgrade the config value and roll out the new Java
<mgz> no, you don't need it, but you can benefit from some management stuff off the side of a charm
<mgz> Fishy_: that kind of thing
<mgz> to do rolling upgrades you need more than just a version, because you want non-homogenous units
<Fishy_> yah thats true
<Fishy_> id rather tie version to the actual app not dependencies
<Fishy_> but config seems to do that
<mgz> a set of unit ids to upgrade would do
<Fishy_> but 3 apps on the server, may end up with 3 different java.version variables i would need to have
<jcastro> http://askubuntu.com/questions/433842/how-to-resolve-error-machine-is-already-provisioned-in-manual-provision-set-up
<mgz> then the roll back is leave the same set, and revert the version config change
<jcastro> any ideas here?
<mgz> and a rollout is add all remaning unit ids to the config
<Fishy_> i like
<jcastro> Fishy_, so how I would do it
<jcastro> is since deploying instances is an easy operation with juju I would do a java upgrade test in a seperate environment
<jcastro> rather than doing it instance per instance in an existing environment
<Fishy_> we can't big bang to prod sadly
 * jcastro nods
<jcastro> yeah so you could make it part of the charm and set the java version via config
<Fishy_> see http://en.wikipedia.org/wiki/Knight_Capital_Group
<Fishy_> for cost of failure ;)
<jcastro> heh, that is awesome man
<Fishy_> Ok so then the choice is does the charm hook use apt-get, or does it install a local java
<Fishy_> local java lets us have 3 apps with diff javas
<Fishy_> but is "wasteful"
<jcastro> a subordinate could also work
<mgz> you likely don't want your apps in the same charm or smashed as services on the same machine anyway
<jcastro> but like are you apt-get installing your java currently or do you do the whole oracle manual install stuff?
<Fishy_> right now we have a mix of 6 versions of se linux and 3 versions of ubuntu and a puppet server that is berserk and a bunch of hand configs
<Fishy_> then the IT guy quit
<Fishy_> i am trying to start fresh... thinking of a POC using juju to manage everything
<Fishy_> ya in most cases I see 1 app to 1 VM or 1 MAAS
<Fishy_> in which case I can just use apt-get like a sane person
<jcastro> yeah, in that case, it's just part of the install hook
<mgz> that sounds... much nicer
<Fishy_> would you guys reco juju on 12.04 LTS or 13?
<Fishy_> I figured deployment is cheap so we don't NEED to use LTS
<Fishy_> if we automate things right
<jcastro> LTS
<jcastro> all our charms and stuff all do LTS
<Fishy_> 14 is soon I know
<Fishy_> ok, LTS it is
<jcastro> yeah, but we're not even at 12.04's half way point in support, I'd base on 12.04, get the important things you mentioned in order
<jcastro> and target 14.04 like in the fall or something
<jcastro> we provide PPAs and updates back to 12.04 so you won't lose anything over choosing 13.x
<mgz> right, heading home time for me
<Fishy_> ya
<Fishy_> some things 12 may not have that 14 will
<Fishy_> tradeoffs..
 * Makyo is away: Lunch
 * Makyo is back (gone 00:07:43)
<ev> is it possible to tell juju about an apt proxy? Cloud init lets you, but it doesn't seem possible to pass that through.
<marcoceppi> ev: it does it automatically for local lxc deployments
<marcoceppi> ev: not sure about other deployments
<ev> marcoceppi: it's for a ctslab openstack deployment
<jcastro> ev, there's a setting you put in environments.yaml that lets you define a proxy
<jcastro> I am looking for it
<ev> apt-http-proxy?
<jcastro> 	"apt-http-proxy": "value-set"
<jcastro> that seems to be it
<jcastro> ev, I filed  a bug for thumper to document the value, I've CCed you on it
<jcastro> he usually comes online in about an hour
<ev> thanks
<jcastro> marcoceppi, I pushed the rails bundle up even though it's not passing proof
<jcastro> I wanted to get the readme and combining the 2 existing ones out of the way first
<rick_h_> jcastro: we've got the RT in progress to deploy
<rick_h_> jcastro: so hopefully have that ready in minutes vs hours now
<jcastro> excellent
<rick_h_> jcastro: actually, I'm told it's deployed
<rick_h_> jcastro: so try running charm proof on it and should work
<jcastro> I have the django one almost done, so really the only one we have to fix after is rails
<jcastro> <3
<jcastro> I am confused, how would running charm proof on it work now?
<rick_h_> jcastro: because charm proof asks charmworld for help in validating
<jcastro> oh!
<rick_h_> jcastro: and that's been deployed with a new release
<jcastro> you sir, are correct!
<jcastro> passed first time!
<lazyPower> boom!
<jcastro> marcoceppi, check out the rails bundle I just pushed please
<lazyPower> jcastro: he's oot, i'll +1 it
<jcastro> you'll have django in a minute
<jcastro> k
<bodie_> I'm curious how much charm makers follow DigitalOcean docs :P
<bodie_> I have a couple of buddies who do those full-time, so it might be fun to get you guys together
<jcastro> hook me up! send them to me
<jcastro> we work on DO no
<jcastro> err, now
<bodie_> yeah, I saw :D
<lazyPower> jcastro: link to branch with bundle? i dont see it in the revq
<jcastro> https://code.launchpad.net/~jorge/charms/bundles/rails/bundle
<jcastro> I didn't file a bug yet
<jcastro> lazyPower, I am reasonably certain the "sample-app" won't work ootb
<lazyPower> ack
<lazyPower> jcastro: is this going to be our common convention for bundles moving forward so i dont ask you this over and over again?
<lazyPower> charms/bundles/<charm>/bundle?
<jcastro> yeah, it's in the bundles doc page
<lazyPower> ah ok
<lazyPower> i haven't looked that over in a while.
<jcastro> and then the name is in the bundle itself
<lazyPower> ty
<jcastro> so this one will be
<jcastro> juju-quickstart bundle:rails/single
<jcastro> juju-quickstart bundle:rails/scalable
<lazyPower> jcastro: nix juju-gui
<lazyPower> you left it in the bundle and quickstarts freaking out
<jcastro> ah! good catch
<jcastro> lazyPower, fixed, pushed
<lazyPower> pulled & running
<lazyPower> rick_h_: love the quickstart workflow btw <3 you guys are made of awesome
<rick_h_> lazyPower: very cool, buy frankban a beverage next sprint. It's 99% his awesomeness
 * lazyPower readies his credit card for rounds
<jcastro> frankban truly crushed it this cycle
<jcastro> lazyPower, django pushed, filing the bugs now to get them in the queue
<jcastro> rick_h_, notice how I am telling people the URL stucture before you write it? That forces you to fix the ~charmers thing, mwahahah.
<rick_h_> jcastro: card is on the board and frankban started working on it today :P
<lazyPower> sneaky sneaky
<rick_h_> jcastro: jujucharms.com updated and shoiuld show recommended bundles now
<zchander> lazyPower, marcoceppi: thanks for all your help! I have just sent out a mail to the mail list with my question. I'll continue my search and (hopefully) will be able to provide us all with more info on my quest
<lazyPower> zchander: i saw that update. If you have any further questions dont hesitate to ask. We'll do everything we can to help you out.
 * zchander forgot to also mention frankban *shame on me*
<zchander> lazyPower: Maybe I should go the 'easy' way and use a separate reverse proxy server, which won't be part of the MAAS/Juju environment
<jcastro> rick_h_, well done sir, I was expecting to be up all night and here we are with 45 minutes to spare.
<rick_h_> jcastro: :) we do our best to last-minute it as much as possible :P
 * zchander is going to walk the dog and relax (playing BF4)
<jcastro> ok so all that's left is pushing these and then tomorrow I'll feature them
<jcastro> rick_h_, hey so ... the ability to feature something is on manage.j.c
<jcastro> which only shows charms
<jcastro> so how do I feature a bundle?
<rick_h_> jcastro: should be the same checkbox like a charm
<rick_h_> jcastro: on mjc
<jcastro> yeah but how do I see the bundles? it only shows charms afaict
<rick_h_> jcastro: search for bundle in the site search
<rick_h_> http://manage.jujucharms.com/search?search_text=bundle&op=
<jcastro> dude
<jcastro> that is way better than jujucharms.com searching for bundles
<jcastro> rick_h_, nope, no link to adding featured in a bundle
<jcastro> tried to URL hack it too, no dice
<rick_h_> jcastro: logged in?
<jcastro> yep
<jcastro> I can get to the charm ones no problem
<rick_h_> jcastro: k, otp, will look in a sec
<rick_h_> bac: do you recall how the bundle featuring was meant to work? I don't see links in the bundle template.
<bac> rick_h_: a bundle can be featured via the admin gui on mjc if it is promulgated
<rick_h_> bac: yea, but it's not showing and there's no <a> link in the bundle.pt like the charm.pt
<rick_h_> oh, got a url that 403s on me
<rick_h_> jcastro: try http://manage.jujucharms.com/bundle/mediawiki/single/featured/edit
<rick_h_> jcastro: k yea that works for me ^
<bac> rick_h_: http://manage.jujucharms.com/bundle/mongodb-cluster/mongodb-cluster/featured/edit
<bac> rick_h_: sorry, i was trying to figure it out.  we need to add the link on the promulgated bundles.
<rick_h_> bac: yep, added a card thanks
<lazyPower> jcastro: so, i found the other issue
<lazyPower> deployer isn't interpreting this correctly, its trying to deploy subordinate services to units - which is causing the issue.
<lazyPower> jcastro: http://i.imgur.com/BIhknum.png
<lazyPower> thats on rails-complex
<hazmat> lazyPower, hmm
<hazmat> lazyPower, config?
<lazyPower> hazmat: http://bazaar.launchpad.net/~jorge/charms/bundles/rails/bundle/view/head:/bundles.yaml
<hazmat> lazyPower, shouldn't do that there are lots of extant deploys with subordinates..
<lazyPower> yeah, i'm looking at this, and thinking i may start deleting charms from the bundle until it deploys, and slowly re-add them back to find where its going awry
<hazmat> lazyPower, ie .. that assumption isn't correct.
<hazmat> afaics
<lazyPower> well, its strange that was the error output. it may be something else causing the issue and bubbling that error message back up the stack
<marcoceppi> lazyPower: is there a num_units key on kibana?
<marcoceppi> if so, that's wrong
<lazyPower> marcoceppi: ther eis
<marcoceppi> err, logstash-agent
<marcoceppi> the subordinate in other words
<lazyPower> there is not on the logstash-agent
<marcoceppi> lazyPower: the bundle looks good to me
<lazyPower> it looks fine to me too, but i cant get it to deploy on hpcloud or local
<marcoceppi> lazyPower: via gui or deployer or quickstart?
<lazyPower> quickstart
<marcoceppi> huh
<lazyPower> also when dragging/dropping on the gui, just finished confirming that
<lazyPower> let me move to my laptop
<lazyPower> my environment may be wonky
<lazyPower> ok trying again - 1 sec while i fetch the bundle
<hazmat> marcoceppi, all roads there end at deployer
<marcoceppi> hazmat: good point
<hazmat> marcoceppi, num_units gets a log warning from deployer, but it ignores
<lazyPower> jcastro: as an aside, the readme is full of lies
<hazmat> marcoceppi, on  a subordinate
<lazyPower> the bundle name is rails-complex, not rails-scalable
<lazyPower> well, not lies, but its not correct :D
<marcoceppi> lazyPower: the name is all wrong to begin with
 * lazyPower pokes at the revq to see if his bugs are open yet
<lazyPower> oo its in here, ok doing the writeup
<lazyPower> thanks for the responses gentlemen o/
<hazmat> lazyPower, what's the error output?
<lazyPower> hazmat: do you want the info from the gui or the machine log?
<hazmat> lazyPower, either or
<hazmat> lazyPower, how bout both
<lazyPower> hazmat: the GUI error is http://i.imgur.com/BIhknum.png
<lazyPower> let me fetch the machine log, 1 sec
<hazmat> lazyPower, okay the other one
 * hazmat src dives into deployer
<lazyPower> gah i destroyed env since that screenshot, let me run this again
<lazyPower> sorry 1 moment
<hazmat> hmm
<hazmat> lazyPower, which version of core?
<lazyPower> 1.17.4-saucy-amd64
<hazmat> lazyPower, it does look like num_unit carries through on deploy
<hazmat> which it really shouldn't on a subordinate, but that's the first time its been an issue.. num_units is always 1 on deploy.
<hazmat> and deployer adds units subsequently which skips out on subordinates
<lazyPower> ok i'm getting the same thing on 12.04 too - let me pastebin these logs
<lazyPower> http://paste.ubuntu.com/7087033/
<lazyPower> Saucy ^
<lazyPower> precise > http://paste.ubuntu.com/7087044/
<mbruzek> lazyPower asked me to deploy this bundle and I am also seeing this bundle fail, but it appears mine will not connect to the GUI.
<mbruzek> http://pastebin.ubuntu.com/7087061/  <== I am using hpcloud
<mbruzek> juju-gui unit shows as started and exposed
<mbruzek> But I am unable to raise it either on port 80 or 443
<mbruzek> Hey marcoceppi would this hp problem be related to the security groups being "full"?  Don't you have a script that cleans that up?
<marcoceppi> mbruzek: probably
<marcoceppi> I'm going to tourch the hp account, one min
<mbruzek> should I destroy-environment?
 * mbruzek thinks that marcoceppi should explain the magic he is doing and when to know to do it.
<marcoceppi> mbruzek: yeah, go ahead and destroy
<mbruzek> done
<mbruzek> How can you tell if they are full?
<marcoceppi> mbruzek: I'm just running a little go program that uses the nova API to delete security groups
<lazyPower> oh man i never thought of that
<lazyPower> the sec groups being full
<marcoceppi> I mean, I don't really know, I just run it occasionally
 * lazyPower hat tips
<marcoceppi> juju is getting pretty good at cleaning up these days though
<lazyPower> orly?
<mbruzek> lazyPower, I only *just* thought of that.
<lazyPower> mbruzek: that was faster than I came up with it :D
<mbruzek> marcoceppi, does your magic script tell us how many it deletes?
<marcoceppi> yes
<mbruzek> Would that tell us if it is full?
<lazyPower> hazmat: want me to pack the rest of the logs up and ship them or are you sated with just machine-0 logs?
<marcoceppi> mbruzek: it'll tell us how many it deleted
<mbruzek> For example if 2048 security groups deleted then it was full
<hazmat> lazyPower, hmm.. what i need is the gui unit logs
<marcoceppi> mbruzek: we have a very finite limit
<marcoceppi> I think 75
<lazyPower> hazmat: ack, inc
<mbruzek> or some high number, but if only 5 were deleted then that was likely not the problem.
<marcoceppi> haha, yeah 70 were deleted
<marcoceppi> mbruzek: try to bootstrap now
<lazyPower> hazmat: http://paste.ubuntu.com/7087105/
<mbruzek> deploying that bundle
<mbruzek> bootstrapping
<mbruzek> OK I can now see the GUI
<mbruzek> That must have been it, and 70 must be our limit
<lazyPower> interesting
<marcoceppi> I'll talk to HP to get it increased, so annoying
<mbruzek> Perhaps marco should share the script too
<mbruzek> Looks to me like Quickstart thinks it deployed, but I only see 3 things on my GUI.
<mbruzek> http://pastebin.ubuntu.com/7087146/
<mbruzek> Juju-GUI, kibana, and haproxy
<mbruzek> Isn't there supposed to be a rails charm in there somewhere?
<mbruzek> yeah I only see three charms deployed
<mbruzek> http://pastebin.ubuntu.com/7087161/
<lazyPower> thanks for that deploy test mbruzek. You've validated what I found and outlined in the review
<jcastro> lazyPower, whoa! I appear to have pushed the wrong bundle to rails
<jcastro> fixing
<jcastro> it's supposed to be single and scalable
<lazyPower> jcastro: have you tried to deploy the django bundle?
<lazyPower> i'm getting the same error output ont rying to deploy the bundles about subordinate services not being able to deploy with units.
<lazyPower> so i'm not convinced this is a bundle issue as much as i'm wondering whats going awry causing this to be such a p
<lazyPower> ita
<jcastro> we haven't touched the charm itself in a long time
<jcastro> ok found the issue, pushed new rails
<lazyPower> ty - pulling update
<jcastro> it is no longer full of lies
<lazyPower> haha
<lazyPower> <3
<jcastro> ... and left in juju gui again
<lazyPower> jcastro: wipe juju-gui from scalable bundle
<lazyPower> yeah
<lazyPower> i want to stamp these as good but with them not deploying - i cant stamp them yet :( I'm sorry man
<lazyPower> mbruzek tried too and couldn't get them to deploy
<jcastro> yeah that's fine
<jcastro> I just wanted to get them in line instead of blocking
<jcastro> fixing them is no problemo!
<lazyPower> mission accomplished
<jcastro> pushed again
<lazyPower> well, phase 1 anyway
<jcastro> I'm not even sure pavel's sample-app for rails works
<lazyPower> jcastro: a good app to do this with would be stringer.
<lazyPower> its a RSS reader, and an excellent test bed
<jcastro> ok so right now the rails charm is using a sample github url
<jcastro> if you think we can just put stringer in there and that will work then nod
<lazyPower> ack. when i hear back from hazmat that he's got something for me to do differently, i'll give it another go, and if it fails i'll stick in a new rails app for ya
 * lazyPower EOD's
<jcastro> it would not surprise me if either django or rails is broken
<jcastro> neither has tests and hasn't been touched in a while
<lazyPower> its not the charms
<jcastro> wait huh?
<lazyPower> did you see the screenie i posted ealier?
<lazyPower> http://i.imgur.com/BIhknum.png
<jcastro> huh what is that
<lazyPower> the craziest thing i've ever seen in my life
<jcastro> I didn't have that error
<lazyPower> and i've encountered it on 3 machines so far
<hazmat> lazyPower, oh.. i thought you resolved the issue to limits
 * jcastro goes to EOD, we'll find the issue in the manana
<lazyPower> agreed
<lazyPower> hazmat: negative, that was with the GUI being unreachable
 * hazmat follows the path of wisdom
<lazyPower> the subordinate error message is still standing
<hazmat> EOD ftw
<lazyPower> haha :)
<hazmat> marcoceppi, i'm walking to lost dogs .. if you've got any interest.. dial me.
<marcoceppi> hazmat: I'm down, meet you there in 5 mins?
<hazmat> eta 45m
<marcoceppi> oh, see you in 45m
<hazmat> marcoceppi, walking.. its a ways.
<marcoceppi> gotchya, yeah I'll be over in about 30-45m
<jcastro> sweet, we'll EOD, you guys go to the bar and fix the bundles
<jcastro> sounds like a plan
<rick_h_> lol
<rick_h_> good try jcastro
#juju 2014-03-14
 * Makyo is away: EoD
<bodie_> oh that's annoying
<bodie_> https://github.com/kapilt/juju-digitalocean requires manual deployment of VMs before you can put services on them
<bodie_> doesn't that kinda defeat the purpose?
<davecheney> bodie_: that is why it's called the 'manual' provider :)
<bodie_> *mutters*
<rick_h_> bodie_: heh, yea that's the advantage of using full providers
<davecheney> call it a forcing function
<bodie_> digitalocean just got $37M in funding.. maybe we should think about enhancing juju's interface with 'em at some point ;) they're trying to take on AWS
<bodie_> really hits the price/performance sweet spot with all the extra fluff removed
<bodie_> not that EC2 and S3 are fluff... but for a lot of people, the bells and whistles just complicate things
<bodie_> just thinking out loud here :)
<rick_h_> I'm sure others have pondered and sent an email or two :)
<davecheney> bodie_: the ball is in their court, they need to provide an API
<davecheney> and join the CPC program
<jose> lazyPower: hey! around?
<marcoceppi> jose: I think he's off for the evening
<jose> marcoceppi: oh, I had a question (as he was the last to review the mailman charm)
<jose> I'm about to do a push and wanted to see if someone could test it (local provider has some problems as you know)
<marcoceppi> jose: I can try
<jose> sure, I should push it in ~3m
<jose> marcoceppi: mind trying the charm? config-changed was giving an error before, should be fixed now
<marcoceppi> jose: linky link?
<jose> https://bugs.launchpad.net/charms/+bug/1199052 and https://code.launchpad.net/~jose/charms/precise/mailman/trunk
<_mup_> Bug #1199052: New charm: mailman <Juju Charms Collection:New> <https://launchpad.net/bugs/1199052>
<jose> lp:~jose/charms/precise/mailman/trunk
<jose> marcoceppi: any blockers found?
<marcoceppi> jose: http://paste.ubuntu.com/7088242/
<jose> marcoceppi: you know a way of using spot instances with juju? like, manually? I *may* be able to afford a couple to test
<marcoceppi> jose: the manual provider can do that
<marcoceppi> jose: what's wrong with local provider?
<jose> last time I tried using there was a bug on LXC which prevented me from deploying
<jose> I'm going to try again
<jose> ERROR cannot find network interface "lxcbr0": net: no such interface // ERROR failure setting config: cannot find address of network-bridge: "lxcbr0" // ERROR cannot find address of network-bridge: "lxcbr0"
<jose> marcoceppi: ^
<marcoceppi> jose: sudo apt-get purge lxc juju-local
<marcoceppi> sudo apt-get install juju-local
<marcoceppi> see if that creates the lxcbro
 * jose does
<davecheney> ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju deploy cs:trusty/ubuntu
<davecheney> ERROR charm not found: cs:trusty/ubuntu
<davecheney> Y NO TRUSTY CHARM!!!
<marcoceppi> because we no promulgate trusty charms yet
<davecheney> Y U KEEP CHRM SECRETT
<jose> marcoceppi: oh, do you have a link to those trusty tests docs you mentioned?
<marcoceppi> davecheney: because charms have no tests!
<marcoceppi> jose: which trusty tests docs?
<jose> you mentioned having some docs about writing the tests for charms to be on trusty
<davecheney> marcoceppi: ubuntu charm is awesome, it is the chuck norris of charms
<davecheney> it doesn't need tests
<marcoceppi> davecheney: you bring up a good point though, we need to start testing trusty like tomorrow
<davecheney> marcoceppi: i need to test it like months ago :)
<marcoceppi> davecheney: I can push the ubuntu charm to trusty if you'd like
<marcoceppi> it's obviously going to work
<marcoceppi> davecheney: cs:trusty/ubuntu exists now, may take a few mins for the store to find it
<marcoceppi> davecheney: nope, it found it https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/ubuntu
<jose> marcoceppi: juju first downloads the precise image before deploying, right?
<marcoceppi> jose: yes, the precise clodu iamge
<jose> then it'll take a good while
<jose> I better go grab a cup of coffee
<davecheney> marcoceppi: w00000000t
<davecheney> thanks
<davecheney> i can use a local charm
<davecheney> but the whole test is that we can talk to thet charm store via a proxy
<davecheney> so local charms defeate the purpose
<marcoceppi> davecheney: I want to enable you FOR GREATNESSS
<davecheney> thank you sir
<davecheney> do you have a suitable imgur for this ?
<marcoceppi> http://i.imgur.com/1ida17K.jpg
<marcoceppi> not relaly
<sarnold> awesome though :)
<marcoceppi> though I've been abusing this one recently, davecheney, http://i.imgur.com/9EqJvVX.gif
<jose> marcoceppi: hey, it says 'instance-state: missing'
<marcoceppi> jose: that's progress, what does ~/.juju/local/log/machine-0.log have for contents?
<jose> hmm, /me checks
<jose> marcoceppi: http://paste.ubuntu.com/7088329/
<marcoceppi> jose: it looks like it's still progressing
<marcoceppi> give it a few more mins checking juju status occasionally
<jose> sure, thanks
<marcoceppi> jose: what does sudo lxc-ls --fancy show?
<jose> state: running, gives me an ip address
<jose> marcoceppi: mind a PM on another topic?
<marcoceppi> sure
<jose> marcoceppi: I cannot seem to find the error on config-changed... Everything looks sane to me
<marcoceppi> jose: let me get you the log
<marcoceppi> http://paste.ubuntu.com/7088378/ jose
<bodie_> night all
<jose> let's see
<jose> oh, I'm going to check that
<ev> is there any way to stop juju from tearing down the instance when it fails to bootstrap, so I can investigate why?
<ev> I'm seeing:
<ev> Bootstrapping Juju machine agent
<ev> 2014-03-14 06:51:09 ERROR juju.provider.common bootstrap.go:123 bootstrap failed: rc: 1
<stub> I don't suppose there is a daily package built of HEAD somewhere?
<stub> https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily no longer seems to exist
<JoshStrobl> Hey guys, where is the Charm Bundle lesson?
<JoshStrobl> marcoceppi: says you'll be on of the speakers, where's the stream?
<JoshStrobl> hmm, maybe my Google Calendar just got messed up or something and is displaying the wrong time to me
<JoshStrobl> oh yea, 1400 EST on Friday (just looked at the email). Good job Google, waking me up for no reason :\
 * JoshStrobl goes back to bed
<rbasak> hazmat: got an issue with python-websocket-client, which python-jujuclient uses.
<rbasak> hazmat: I need to shift the dependency to python-websocket, since we have a dupe. This involves effectively bumping the version in Trusty from 0.11.0-0ubuntu1  to 0.12.0-1
<rbasak> hazmat: do you see any problems with that?
<rbasak> jamespage: ^^
<jamespage> rbasak, going to give it a quick test as well
<jamespage> I use deployer alot
<hazmat> rbasak, should be fine.. i'll double check re changes
<hazmat> rbasak, yup that's fine.. i use that version already
<hazmat> via pip/virtualenv installs
<rbasak> hazmat: thanks!
<jcastro> mbruzek, lazyPower, those errors you got with the subordinates and the bundles last night, you got those in the GUI right?
<mbruzek> jcastro, I was using the command line.  I did not see any errors, I only saw 3 charms deployed from that bundle.
<mbruzek> I am sure there were errors that prevented that from deploying, but I didn't dig into it.
<rick_h_> jcastro: the gui was watching the bundle and returned the error to the user
<rick_h_> jcastro: but the error came from lower down the stack
<jcastro> mbruzek, can you see if you have the bundles you tried  in your history? I'd like to dig today
<mbruzek> jcastro, http://pastebin.ubuntu.com/7090108/
<mbruzek> I destroyed the environment at the EOD but that is how I ran it.
<jcastro> ah got it
<jcastro> I mistakingly put in the "complex", but chuck caught that and I removed it
<jcastro> pushed a new version, trying it now
<mbruzek> Out of that list of charms, I only saw juju-gui, kibana, and haproxy deployed iirc
<jcastro> yeah, rails takes like 10 minutes at least
<jcastro> it does all this ... rails stuff ...
<jcastro> pull the universe from git, etc.
<jcastro> I am trying it now
<mbruzek> OK
<zchander> Hi all... Got another (weird) error. Just reinstalled my MaaS and whenI want to bootstrap my Juju, I get iscsi errors
 * zchander seems baffled.... Somehow some ephemerals were installed twice...... :(
<lazyPower> jcastro: i've tried it on several installations. the units were never coming online
<lazyPower> that error failed the entire bundle deployment. i'm not saying its not my env being the culprit though
<jcastro> yeah rick is investigating
<jcastro> no I reproduced, and so did mbruzek just now
<lazyPower> ah ok
<jcastro> but this exact bundle was working a few days ago, so clearly something changed
<jcastro> lazyPower, I am worrying about the sample app in the rails charm though
<mbruzek> jcastro, that pastebin was from yesterday
<jcastro> mbruzek, yeah the exact same thing happened to me
<jcastro> just now
<mbruzek> Ok
<lazyPower> jcastro: ok let me wrap this subordinate I am hacking on and I'll pull that sample rails app and see how it goes
<jcastro> I am +1 if you want to replace pavel's app with another hello-world style app
<lazyPower> actually
<lazyPower> let me deploy pavels app on the rails charm now. it wont take long
<rick_h_> jcastro: [E 140314 09:52:59 utils:72] error deploying the bundle                                                                                                        âÂ·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·
<rick_h_> [E 140314 09:52:59 utils:73] error type: <class 'jujuclient.EnvError'>                                                                                         âÂ·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·Â·
<rick_h_> [E 140314 09:52:59 utils:79] error message: subordinate service must be deployed without units
<jcastro> how did it let me create that in the first place?
<rick_h_> jcastro: wow, this error was mentioned in our irc back in July
<jcastro> well, I prefer known to unknown. :)
<rick_h_> http://irclogs.ubuntu.com/2013/07/24/%23juju-gui.txt line 73
<jcastro> ok so worse case, remove the subs
<jcastro> but then the bundle is kind of less useful
<rick_h_> jcastro: pulling num_units and going to try it out again
<rick_h_> jcastro: I think just removing the unit specifier will work, but testing
<jcastro> ok
 * Makyo is back (gone 13:44:06)
<jcastro> rick_h_, the django bundle has the same errrors
<jcastro> so hopefully that's the badger
<rick_h_> jcastro: in looking at the source code here, num_units isn't valid param for subordinates. Did you export this? I thought we didn't export that value any more
<jcastro> I exported it
<jcastro> I've done no manual mangling other than renaming the envExport
<rick_h_> jcastro: will file a bug on that then. We shouldn't export that setting
<jcastro> ok so I should remove that from the bundle and try again?
<jcastro> rick_h_, remove all of the num_units right?
<rick_h_> hmm, same error
<rick_h_> jcastro: yea it's what I did to try out but failed again
 * jcastro stands by
<rick_h_> jcastro: which are sub's in here?
<jcastro> logstash agent
<rick_h_> nrpe?
<jcastro> maybe nrpe?
<jcastro> I don't remember, I made the bundle like 3 weeks ago, heh
<jcastro> iirc I thought subs would be mentioned in the file
<lazyPower> rick_h_: confirmed nrpe and logstash-agent are the subs
<rick_h_> lazyPower: k, trying another take
<rick_h_> jcastro: ok, change the num_units to 0
<rick_h_> on the subs
<rick_h_> jcastro: don't ask me why, but it's what the code says and it's deployed the rest of the services. So run with me here :)
<rick_h_> lazyPower: ^
<rick_h_> for the django one
<rick_h_> as well I'd imagine
<jcastro> neither nrpe or logstash-agent have num_units mentioned
<jcastro> do you think it's assuming one? so explicitly add it and declare 0?
<lazyPower> rick_h_: http://i.imgur.com/00Ugaft.gif
<rick_h_> jcastro: yes, it seems to assume 1 and then error. I set it to 0 and it's working
<jcastro> man, that's an awesome bug
<rick_h_> jcastro: pretty much
<rick_h_> jcastro: k, all done. rails failed on install hook error but the rest went out
<rick_h_> the sample app one that is
<marcoceppi> jcastro: I take issue with the way the rails bundle is structured
<jcastro> marcoceppi, ok
<marcoceppi> Since it's a "framework" charm it's still to just deploy it
<jcastro> fire away
<marcoceppi> We should instead model some rails software in the bundle instead
<marcoceppi> like rails/<rails-app-thin>
<marcoceppi> since bundles should model workloads
<marcoceppi> find popular rails apps and build bundles for them in the rails name space
<lazyPower> marcoceppi: I suggested stringer as a possible replacement.
<lazyPower> another one would be spree, the ecommerce solution.
<marcoceppi> another issue with the charm in general, but it's not your fault jcastro, is a lot of times it needs post-deployment commands to work properly
<jcastro> yes, I had to mention that
<marcoceppi> (db:migrate, asset"precompiile, etc)
<marcoceppi> jcastro: http://stackoverflow.com/a/487407/196832
<jcastro> basically, django and rails need things like, a config.yaml for where the code lives, etc.
<lazyPower> marcoceppi: since we cleared the security groups lastnight I haven't been able to reach anything i've deployed on HPCloud - is there a stray setting aside from the .jenv i need to wipe?
<lazyPower> wait, i can reach it via ssh, but not port80 post being exposed
 * lazyPower wat's
<marcoceppi> lazyPower: did you have anything deployed before the wipe?
<lazyPower> i did :(
<marcoceppi> yeah, they're inaccessible
<lazyPower> i had a bootstrap node chillin in there that I manually wiped from the console.
<marcoceppi> best to destroy environment and move on
<lazyPower> i just rebootstrapped
 * lazyPower wipes and tries again
<jcastro> marcoceppi, ok how about example-single and example-scalable?
<jcastro> to make it explicit that it's a hello world for you to customize?
<marcoceppi> jcastro: such compromise
<marcoceppi> jcastro: much synergy
<jcastro> rick_h_, blamo, worked first time
<jcastro> ok going to do what marco wants, push, and then we'll see about the example app
<jcastro> going to fix/push django too
<marcoceppi> so, probably needs to be on deployer than
<rick_h_> jcastro: woot thanks for the help in debugging. I've got a card for us to find the right place to file the bug.
<marcoceppi> a bug*
<rbasak> hazmat: about python-jujuclient again. test_jujuclient.py is in bzr, but not in the PyPI distribution, so I can't easily run the test suite as part of a package build (MIR requirement).
<rbasak> hazmat: I just dealt with exactly this problem in websocket-client by plucking out the test suite in a packaging patch.
<rbasak> hazmat: please can you add it to setup.py?
<hazmat> rbasak, sure
<hazmat> rbasak, i hadn't realized this was going into main
<hazmat> rbasak, i've got meetings for the next 2hrs but will come back to it today
<rbasak> hazmat: np. Unless you do a PyPI release and I update packaging I'll have to do a distro patch anyway.
<rbasak> hazmat: it's going into main because juju-quickstart needs it.
<rbasak> hazmat: "Seriously Alpha. Works now, but API *will* change." alarms me a little for main inclusion.
 * rbasak takes a break to unwind his stack
<hazmat> rbasak, yeah.. i should take that out, it was commentary from the first release against the api, but in truth it has been pretty stable to date
<rbasak> hazmat: thanks. I will quote that for the MIR :)
<onrea> fainally, I could not run Discourse.org by juju :(
<onrea> My problem is repored here: http://discourse.ubuntu.com/t/how-to-install-juju-manually-cloudimg-tar-gz-where-should-it-be-extracted/1548
<onrea> if you can help, please help
<onrea> lazyPower: ^
<lazyPower> onrea: ack, hang on i'm going to tap one of the more knowledgeable people
<marcoceppi> onrea: put them in /var/cache/lxc/cloud-precise but don't extract them
<onrea> :)
<onrea> both of them?
<marcoceppi> onrea: yes
<onrea> w8
<onrea> marcoceppi: PLease check the instruction for any missing/wrong step:
<onrea> 1. sudo juju destroy-environment -y local
<onrea> 2. juju init && juju switch local
<onrea> 3. sudo chown -R emzi.emzi ~/.juju ~/.ssh
<onrea> 4. juju bootstrap
<lazyPower> onrea:  once you've dstroyed you don't need to re-init
<onrea> 5. juju deploy --repository=$HOME/charms local:discourse
<onrea> 6. juju deploy postgresql
<onrea> 7. juju add-relation discourse postgresql:db-admin
<onrea> 8. juju expose discourse
<onrea> 9. juju status
<onrea> 10. watch juju status
<onrea> lazyPower: ok
<lazyPower> onrea: otherwise that set of instructions loks fine, i don't see anything crazy
<onrea> Ok, thanks @lazyPower, marcoceppi. I'm going to rock discourse with juju...
<jcastro> ERROR cannot use 37017 as state port, already in use
<jcastro> anyone know how to fix this one with the local provider?
<jcastro> I've blown away local.jenv and the environment/local directory
<marcoceppi> jcastro: sudo initctl list | grep juju
<jcastro> ok I see stuff
<jcastro> do I stop/restart it?
<rick_h_> jcastro: yea, I just ps aux | grep mongo and kill the mongodb instance running
<marcoceppi> jcastro: sudo stop each of those
<marcoceppi> then rm -f /etc/init/juju-*
<jcastro> ==> unit-jenkins-slave-0.log <==
<jcastro> 2014-03-14 17:37:43 ERROR juju runner.go:220 worker: exited "upgrader": cannot read tools metadata in tools directory: open /home/jorge/.juju/local/tools/1.17.4.1-prec
<jcastro> ise-amd64/downloaded-tools.txt: no such file or directory
<jcastro> I've not run into this before
<lazyPower> jcastro: this is something that happened during the 1.17.4 update - if you ln -s the saucy tools to precie it goes awy
<lazyPower> and its only log spam - it doesn't appear to have any effect over deployments in my testing.
<lazyPower> s/precie/precise
<jcastro> I don't have saucy or precise tools
<lazyPower> are you running trusty?
<jcastro> yeah
<lazyPower> probably trusty-tools then
<lazyPower> same principal
<lazyPower> but ymmv - i dont know if there was a specific difference between the series.
<jcastro> ah
<jcastro> I don't seem to have /releases/juju-1.17.4.1-trusty-amd64.tgz
<jcastro> can I sync-tools post-bootstrap?
<lazyPower> good question
 * jcastro tries it
<lazyPower> i think so
<lazyPower> juju sync-tools is referenced in this answer
<lazyPower> http://askubuntu.com/questions/285395/how-can-i-copy-juju-tools-for-use-in-my-deployment
<jcastro> it didn't work, but the service is up
<jcastro> so Good Enough
 * lazyPower nods
<lazyPower> the log spam is annoying, i'll file a bug
<jcastro> well, the tools are also missing
<jcastro> that might be a problem, heh
<lazyPower> yikes!
<lazyPower> sinzui: anything going on with streams/tools that you are aware of?
<sinzui> Nothing yet.
<lazyPower> brb
<sinzui> lazyPower, It is stable right now. When will ask for an update to get 1.17.5 when I see the arm64 and ppc packages in ports
<lazyPower> sinzui: ack, thank you for looking into this for us
<jcastro> Juju Charm School on Bundles in 2 minutes!
<jcastro> https://plus.google.com/hangouts/_/hoaevent/AP36tYdbEgmEEjOzBoN2_eYNDyWicF98hHYXAdD2H92SaNCpwqY1DA?authuser=0&hl=en
<jcastro> there's the URL
<jcastro> http://youtu.be/eYpnQI6GZTA if you just want to follow along
<JoshStrobl> Will the Youtube stream automatically start playing the video once it's being broadcasted?
<marcoceppi> JoshStrobl: yes, should start in a few mins
<JoshStrobl> cool
<marcoceppi> JoshStrobl: rather, it should be running now
<marcoceppi> may need to refresh
<JoshStrobl> yep!
<JoshStrobl> refreshed and it's buffering
<JoshStrobl> well, it's loading as in waiting...or something like that. no way it's buffering on my connection
<lazyPower> JoshStrobl: its live for me - still having issues?
<JoshStrobl> not any more. just ended up loading firefox and it was fine
<JoshStrobl> good job Chrome, good job...
 * lazyPower golf claps for chrome
<marcoceppi> Feel free to ask questions anyone watching, and I'll relay them in to the video!
<JoshStrobl> aanndd this is why I use nano in the terminal :P
<ppetraki> any questions so far?
<bac> jcastro: the ingest runs every 15 minutes, so worst case is you just miss and it takes two cycles, 30 minutes
<JoshStrobl> No questions from me :(
<JoshStrobl> * :)
<lazyPower> jcastro: you should be able to drag directly from the rails charm to that mongos instance in the middle.
<lazyPower> jcastro: crazy? that was every day in a prior life :)
<JoshStrobl> hey lazyPower, I changed my charm from Incomplete to Fix Committed again barring a response from you (regarding my response to you): https://bugs.launchpad.net/bugs/1278369 . Waiting a while and noticed there wasn't any reply on it when it hadn't been changed, so I went ahead and changed it.
<_mup_> Bug #1278369: Charm Needed: metis <new-charm> <Juju Charms Collection:Fix Committed by truthfromlies> <https://launchpad.net/bugs/1278369>
<lazyPower> JoshStrobl: thanks! i reached out and didn't receive an email response - so without it being in teh queue and no 1:1 from you it was pending re-entry into the queue
<lazyPower> i should be able to get you the +1 today before I EOD
<JoshStrobl> lazyPower: Ah, thought that since ~charmers were subscribed that maybe it'd notify others, guess not.
<lazyPower> yeah - with me not being a charmer yet (emailing the list today to petiton for membership) - i don't get those notifications yet.
<JoshStrobl> lazyPower: I changed to Fix Committed since it was more relevant to my actual post (I had changed to Fix Committed prior to you setting it as Incomplete since like 99% of everything marcoceppi talked about was resolved). Not necessarily looking for the +1 (although that'd be nice), more like "hey, the stuff you said wasn't resolved actually was, here is a long post about it".
<JoshStrobl> If you have any questions and feel it'd be more appropriate to discuss on IRC rather than mailing list, I'll obviously be around...probably for 5 or so more hours.
<lazyPower> JoshStrobl: ack. I'll ping you shortly
<lazyPower> wrapping up some expedited requests now
<jose> lazyPower: hey, if you're around and have a minute, looks like I fixed the mailman charm
<lazyPower> jose: awesome :) did you move the status of your ticket to fix committed?
<jose> lazyPower: well, to new, but moved it
<lazyPower> ack. as long as its in the revq i'll get to it before my shift ends for teh week
<lazyPower> JoshStrobl: ok moving on to metis - incoming review
<JoshStrobl> lazyPower: Thanks bud.
<lazyPower> JoshStrobl: without cryptograhic verification of file signatures I cannot pass the charm, its a hard stopper. I respect your concern of continuous delivery though
<JoshStrobl> lazyPower: Any suggests?
<JoshStrobl> *suggestions
<lazyPower> My thought would be to use git itself as the delivery mechanism, since git validates the file signatures cryptographically
<lazyPower> you can use tags in the same vein as you would be zip packages
<lazyPower> then you just deliver from your github repository using the tag, and make tag the configuration option for deployment
<lazyPower> or hash, or whatever. This satisfies a default stable release and allows for upstream deployment as well so you're not updating your charm over and over to get the new releases in
<JoshStrobl> Gonna be honest, didn't even think about using git. Feel free to mark as Incomplete barring fix, I'll implement using git as the delivery mechanism when I get the chance and will change it to Fix Committed when it's done.
<JoshStrobl> *git for delivery
<lazyPower> JoshStrobl: if you want any help/pointers ping me and I'll hop on a hangout with you
<JoshStrobl> Cool, thanks!
<lazyPower> and thank you for being patient during the review process, i know this has quite a bit of back and forth. I want to see this land in the charm store soon after seeing how much effort you've put into it
<JoshStrobl> lazyPower: Thanks for your kind words and the tip on using git (makes sense since the code is on GitHub anyways) =)
 * lazyPower hat tips
<lazyPower> jose: incoming mailman review
<jose> lazyPower: thanks!
<lazyPower> jose: correct me if i'm wrong, but i'm seeing the same failure
<lazyPower> was this corrected on the postfix charm?
<jose> lazyPower: hmm? let me double check
<lazyPower> as that may be why i'm not seeing the fix show up
<jose> no, it was corrected on the mailman charm
<jose> let me double check just in case
<lazyPower> ack
<jose> hmm, no, it was corrected on the 7th revision
<jose> which is on LP atm
<jose> I did a successful deploy with it on my local env yesterday
<lazyPower> I'm sitting on revision 5
<lazyPower> and it just updated
<lazyPower> wat...
<lazyPower> i'm slippin
<lazyPower> ok let me upgrade the charm and start over - ty for confirming
<jose> :P np
<lazyPower> good news! it passed the config-changed hook blocker
<lazyPower> moving on
<lazyPower> ok last call for anyone with last minute charm submissions before i EOD
<lazyPower> you've got 15 minutes
 * lazyPower EOD's
<lazyPower> jose: ping me when you've got those changes and i'll re-review for ya later tonight and get your +1 on record
<jose> awesome, thanks!
<lazyPower> JoshStrobl: not sure if you're still hacking away, but same goes for you.
* lazyPower changed the topic of #juju to: Welcome!! Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP
<dpb1> marcoceppi: hi -- amulet is supposed to intercept calls to deploy the "current" charm, right?  We are seeing that isn't happening as we expect.  Known issue?
<marcoceppi> dpb1: how are you executing the test with charm test or directly?
<marcoceppi> if directly you'll need to see this Ask Ubuntu question
<dpb1> hmmm.
<dpb1> charm test?
<dpb1> we are using juju test
<marcoceppi> dpb1: that's one in the same
<dpb1> reading in a deployer config file with 'branch: lp:~landscape-charm/trunk'
<marcoceppi> juju test == charm test; are you launching juju test from the charm_dir?
<dpb1> yes
<marcoceppi> dpb1: OH
<marcoceppi> that's why
<dpb1> :(
<marcoceppi> it only intercepts on d.add()
<marcoceppi> dpb1: file a bug and I'll see what I can do
<dpb1> OK
<dpb1> marcoceppi: there are other problems with the config-based deployment that I haven't filed yet.  But this one is more tricky for me to work around.
<ahasenack> marcoceppi: what do you whink about this other idea,
<ahasenack> marcoceppi: when creating a deployment, like
<ahasenack>     d = amulet.Deployment(sentries=False)
<ahasenack> marcoceppi: pass it an existing directory where I have already checked out all the branches I want deployer to use
<ahasenack> it's like pre-creating precise/<charms>, and then calling deployer
<ahasenack> it will see the charms are already there and not update them, nor check them out again
<ahasenack> so, I would call it like
<ahasenack> d = amulet.Deployment(sentries=False, charm_directory="/some/path")
<ahasenack> it would use charm_directory instead of a temporary directory to check out all the charms
<fishy_> what username and password can I do to get into a new local charm I just started?
<fishy_> assume I would do a sudo lxc-console --name <foo>
<jose> lazyPower: should be ready for review, but needs the 'password' option set for the install hook to run successfully
<lazyPower> jose: ack - do a sniff for the presence of the password config option, if its not present, dont run the hook
<lazyPower> that breaks idempotency
<jose> huh?
<jose> oh
<jose> then the charm would not be useful at all, because the service wouldn't even install
<lazyPower> $HTPASSWDPW=`config-get password`    if [ -z $HTPASSWDPW ]; # do stuff  fi
<lazyPower> im' talking about securing the mailman config interface, dont run the htpasswd generation stuff if options aren't populated
<jose> hmm, good idea, not have the htaccess if password is null
<jose> yep
<lazyPower> :)
<jose> lazyPower: aaaaand, pushed!
<lazyPower> jose: woo! updating and reviewing now
<lazyPower> http://www.youtube.com/watch?v=21OwTUEiGGM#t=231
<lazyPower> watch that while you wait
<jose> :P
<lazyPower> jose: really close - move that logic to the config-changed hook, otherwise its immutable and only runs on install
<jose> lazyPower: hmm, in what part?
<jose> like, adding support to change the password?
<lazyPower> jose: the heredoc configuration where you're generating the htpasswd and setting the apache values for the htpasswd
<lazyPower> right :)
<lazyPower> immutable configuration options will wind up tanking a review just as fast as a broken hook - because its not readily apparent to the user that its only configurable during install, and thats a pretty easy copy/paste job to move it.
<jose> lazyPower: all set now
<lazyPower> deploying
<jose> lazyPower: thanks a lot for your help, owe you a couple beers once we meet at a conference
<lazyPower> jose: nbd :) I enjoy the candor though
<lazyPower> jose:         agent-state-info: 'hook failed: "install"'
<jose> lazyPower: does it give you any clues on the log?
<jose> I'll try and deploy, but will take a while
<lazyPower> ln: failed to create symbolic link `/etc/apache2/sites-enabled/mailman': File exists
<jose> hmm? /me double checks
<jose> lazyPower: weird, I don't see that on my logs
<lazyPower> thats on a fresh local provider environment
<lazyPower> the install hook is only run once though - so if you're updating a unit, you wont see that
<jose> I just destroyed my local environment and bootstrapped again
<jose> it's deploying
#juju 2014-03-15
<lazyPower> jose: you know what I didnt do? I didn't set a domain name, then I re-ran the hook after it initially enabled the site
<lazyPower> so there are some idempotency issues with the install hook as well.
<jose> lazyPower: so, even if not setting a domain name, it did run successfully before
<jose> just failed here, I'm checking
<jose> 2014-03-15 00:00:00 INFO juju.worker.uniter context.go:255 HOOK /var/lib/juju/agents/unit-mailman-0/charm/hooks/install: line 150: warning: here-document at line 126 delimited by end-of-file (wanted `EOL')
<jose> 2014-03-15 00:00:00 INFO juju.worker.uniter context.go:255 HOOK /var/lib/juju/agents/unit-mailman-0/charm/hooks/install: line 151: syntax error: unexpected end of file
<jose> lazyPower: ^
<jose> that's the error preventing it from finish
<lazyPower> yeah. Give it s'more TLC and I'll recheck. I'm going to log out for the day.
<lazyPower> its 8:00pm here local - long day
<jose> have a nice weekend! :)
<jose> and thanks again!
<lazyPower> but if you need anything, email me, ping me, whatever :)
<lazyPower> i'm happy to help
<lazyPower> tc o/ have a good weekend
<bodie_> anyone know how to build the juju binary from source?  mine's getting hung up on the gwacl error
<bodie_> I asked in dev but it's quiet tonight
<sarnold> bodie_: you could check out the build logs, they may have some guidance about what you've overlooked: https://launchpadlibrarian.net/168405383/buildlog_ubuntu-trusty-amd64.juju-core_1.17.4-0ubuntu2_UPLOADING.txt.gz
<bodie_> ah, I see the problem
<bodie_> I need more cores
<bodie_> :{
<bodie_> that's very, very different from all the lit I've seen saying to simply "go get launchpad.net/juju-core"...
<bodie_> but, I guess if it builds it builds
<onrea> http://paste.ubuntu.com/7093712/ ==> status: pending ?!
<onrea> ^
<sarnold> "1.17.5.1", heh, the version looks like an ip..
<lazyPower> onrea: is your instance stuck in the pending state?
<lazyPower> sarnold: wish me luck, i just applied for charmer status
 * lazyPower crosses fingers
<sarnold> lazyPower: ooh! cool!
<lazyPower> :)
<onrea> lazyPower: When I run "watch juju status", nothings happens
<hazmat> geekmush1, ping
<geekmush1> hey!  still haven't circled back to juju yet â¦ had a webserver get compromised, so have been doing that fire drill
<geekmush1> (wasn't my fault!  WP bad install, I think)
<geekmush1> any updated for me to grab, tho?
<hazmat> geekmush1, no worries.
<hazmat> geekmush1, so i wanted to double check the version of juju you were using
<hazmat> geekmush1, afaics juju hadn't been initialized on that machine.. or your using something older than 1.17
<hazmat> and 1.17 +  is a pre-req for docean provider
<geekmush1> I don't have the juju server up right now, but as I recall, it was the juju development apt repo
<hazmat> geekmush1, no worries.. i still see somethings i can fix up which i'll work on.
<hazmat> trying to play around with openstack dev in containers atm
<geekmush1> cool â¦ let me know!  :)
<bodie_> wait, is there an actual docean provider now?
<bodie_> I thought it was manual provider
<hazmat> bodie_, its a plugin that automates digital ocean via manual provider
<bodie_> hm
<bodie_> but you still have to have already created the VM nodes right?
<hazmat> bodie_, ie.. bootstrap/add-machine/terminate-machine/destroy-environment  via the plugin do the right thing wrt to do
<hazmat> bodie_, no.. it creates them for you using the do api
<bodie_> oh...  I misread the docean walkthrough then, or i'm confused in some other way
<hazmat> bodie_, its not an actual provider.. its a client side provider
<hazmat> bodie_, ie.. you have to juju docean add-machine before doing juju deploy/add-unit
<bodie_> ohhhhh
<bodie_> I misunderstood that as actually adding the machine yourself on digitalocean
<bodie_> which really seemed to defeat the purpose, heh
<hazmat> hmm.. maybe i should clear up the docs there
<bodie_> oh, is that yours?
<bodie_> nice work if so
<hazmat> bodie_, yeah
<hazmat> the lxc plugin is the one i'm using on a daily basis.. manual provider + lxc-clone w/ snapshot.
<bodie_> why not make juju deploy do an add-machine first, if it's not there already?
<bodie_> yeah, that's pretty cool for sure
<bodie_> I use DigitalOcean a lot on my own, so I got really excited when I realized how simple juju would make that, until I thought I still had to make the VMs myself :S
<hazmat> bodie_, deploy relies on the provider on the state server to allocate the actual machine if one is not already available
<hazmat> bodie_, give it a whirl then.. feedback always welcome
<bodie_> I see
<bodie_> and since it's manual, it wouldn't know how
<hazmat> yup
<hazmat> in fact it throws an error on deploy now w/ manual
#juju 2015-03-09
<hazmat> blr: no.. if you want to manually configure containers, you can use the manual provider
<blr> hazmat: aware the correct thing to do is charm the other dependant service and set the IP with a relation, but the other service is super non-trivial to charm
<blr> will have a look at the manual provider though, thanks
<Muntaner> hi guys
<Muntaner> how can I detach a public address (floating IP) to a juju service?
<Muntaner> marcoceppi, I'm adapting my charm to load balancing. Have you got any suggestion? Can I simply follow the WordPress charm code?
<Muntaner> frankban, I detached a floating IP to a Juju VM; but Juju GUI isn't updating (still diplays the floating ip)
<frankban> Muntaner: where is the ip displayed in the GUI? how did you detach the floating ip?
<Muntaner> frankban, I detached it via OpenStack Horizon dashboard. I still can see the old IP by clicking on the charm, clicking on the mysql/0 - ish on the left
<frankban> Muntaner: do you see the old ip with juju status?
<Muntaner> frankban, this can sound strange - I tried to do that with mysql and haproxy. On mysql charm the status does not show the old IP, while for haproxy I still see the old one
<Muntaner> in the GUI, I see the old IP from both of them
<Muntaner> frankban, juju does not have a mechanism to detach the IPs?
<frankban> Muntaner: not sure about the how juju reacts to this kind of changes directly done by using horizon. Perhaps you can get help from someone more expert of openstack stuff. Since openstack environments have a use-floating-ip option, I guess you can run "juju environment set" to enable or disable floating ips, but never tryed
<frankban> tried even
<Muntaner> frankban, ty
<bloodearnest> heya all. Am trying to write amulet test for apache, but it keeps using the wrong charm
<bloodearnest> I do:
<bloodearnest> d = amulet.Deployment(series='trusty')
<bloodearnest> d.add('apache2')
<bloodearnest> but I get the current cs version, not my local version on disk
<Muntaner> marcoceppi, have you got a few minutes?
<stub> bloodearnest: The second argument to d.add is the path to the charm, which avoids the problem
<bloodearnest> stub, lovely, thanks
<rbasak> frankban: what is juju-quickstart 2.0's compatibility with older versions of Juju, please?
<frankban> rbasak: no changes from previous versions, so it supports juju >= 1.18.
<rbasak> frankban: OK. Thanks!
<frankban> rbasak: there is an open bug we are working on FYI and I we expect to release a 2.0.1 today or tomorrow.
<rbasak> ack. I can work on the packaging anyway, since that'll presumably be a minor change I can pull in before upload.
<frankban> rbasak: +1
<skay> hi all, I haven't run bundletester before. I need help https://code.launchpad.net/~codersquid/charms/trusty/python-django/pip-extra-args/+merge/245785
<skay> not urgently, but if you have a chance, please take a look and comment
<skay> also, would it be possible to unpin bundletester's dep on bzr and make it >= ?
<nicopace> hi whit, marcoceppi, asanjar, jcastro, arosales. A new week begins, and i return with my review requests :) This is a reminder: https://code.launchpad.net/~nicopace/+activereviews There are still 9 pending branches
<Muntaner> good mornign guys
<Muntaner> marcoceppi, toc toc
<tvansteenburgh> skay: fwiw, i branched python-django/trunk and ran `bundletester -e amazon -l DEBUG -v` and all the tests passed (using latest bundletester from github)
<skay> tvansteenburgh: thanks, I'll try that.
<Muntaner> I am deploying a haproxy charm, and trying to connect to it, but nobody seems to happen
<bloodearnest> stub, adding path as a second arg to add() doesn't seem to work for me - I still need to have JUJU_REPOSITORY set for it work
<bdx> I have a few questions regarding charm configuration is there someone who might have an extra minute or two to advise me of a best practice?
<bdx> jamespage: Could you have a look at this https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/456 ?
<bdx> charmers: Can anyone give any insight here https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/456 ?
<bdx> Any takers https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/456 ?
<whit> anyone have any good ideas for the dockercon hackathon?
 * whit means other than marcoceppi idea to go do something cool in lxc and then reveal it at the last moment
<bdx> jamespage, charmers: If a charm, say cinder is deployed, and the configs os-admin-network, os-internal-network, and os-public-network are respectivly 10.50.0.0/24, 10.60.0.0/24 and 10.70.0.0/24, must then the physical node that the cinder charm is deployed to be connected on all three seperate networks?
<jorge> marcoceppi, can you link to your actions blog post?
<marcoceppi> jorge: when I finish writing it
<jorge> oh lol
<jamespage> bdx, indeed it must be
<jamespage> otherwise the charm will just fallback to private-address from juju
<mchasal> marcoceppi, jorge I wonder if you could help with some project organization issues we're having. We've got a single project that is housing multiple charms. We've got a devel branch where we've been doing our work, but I'm having trouble figuring out how to handle publishing this to the charm store since they will be on different schedules. Can't just merge the whole devel branch with trunk as it will pull in charms that aren't ready.
<mchasal> Here's the project page: https://launchpad.net/ibmcharms
<jcastro> hi
<mchasal> Any advice?
<marcoceppi> soo/
<marcoceppi> o/ *
<jcastro> when you mean publishing to the charm store
<jcastro> do you mean like just having everything in this lp project indexed on jujucharms.com?
<mchasal> Yes, and, and so users can eventually just deploy from there.
<mchasal> My understanding is that Launchpad will automatically find any charms pushed to a trunk branch.
<jcastro> yeah
<jcastro> you need to put /charms/ in the branch name though
<mchasal> Ah, ok, not just in the path.
<jcastro> so like I see in your branches you have like
<jcastro> ~username/ibmcharms/kimchi
<jcastro> you can push to ~username/ibmcharms/charms/trusty/kimchi for example
<jcastro> mchasal, but that's just how it is now
<jcastro> soon you can push to wherever you want, then just `juju publish`
<mchasal> Yes, I understand those changes are coming.
 * jcastro nods
<mchasal> I think we're going to be pushing our first versions of these soon though, I'm guessing before publish is out there.
<jcastro> yeah
<jcastro> from there after you push I believe the threshold is 15 minutes for it to get listed
<mchasal> Ok, that's no problem. I'm just trying to get this project structured in a sensible way, which I don't think I did the first time around.
<mchasal> Trying to keep all the charms we're working on under this single umbrella.
<mchasal> But it looks like a single devel branch was too much.
<jcastro> yeah
<jcastro> also remember you need a place for the bundles too
<mchasal> I guess I'm still a little confused about the series, in your example above: "push ~username/ibmcharms/charms/trusty/kimchi" That's just going to go to whatever the development focus series is.
<jcastro> series is just linked to the distro though
<jcastro> wherever trunk development of the charm is can be anywhere
<jcastro> let me try to find how the openstack charmers do it
<mchasal> Hmm, maybe I'm mixing up my terminology.
<jcastro> they have a nice setup for devel and then propagating that to release
<mchasal> I was looking at their repos trying to understand this.
<jcastro> you want one place to do devel, and you want one place that is stable right?
<mchasal> right, I just don't want the automated process to pick stuff up before it's ready to be published. I was trying to encourage our members to push code regularly.
<mchasal> So yes, trunk/stable and devel
<jcastro> marcoceppi, do you have any insight into how the openstack guys do this?
<jcastro> I am noticing milestones, etc. in launchpad for their charms
<mchasal> Things like this confused me there too: "Merged branch lp:~hopem/charms/trusty/keystone/stable-precise-1423513"
<mchasal> So the branch with trust in its name has stuff for Precise.
<jcastro> hmm, I wonder if I can just ask them team to write up their whole workflow
<mchasal> That might be a good thing.
<jcastro> ok I'll go ahead and ask them to do so
<mchasal> COol
<jcastro> mchasal, aha!
<jcastro> https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/
<jcastro> looks like they did that already, see the "development flow" section
<mchasal> You mean they didn't just write that now?
<jcastro> heh
<jcastro> I'll go ahead and post this to the list too
<jcastro> I think I'll put this in best practices as well
<mchasal> Thanks for the help, I'll have to try and digest this all now.
<mchasal> It's still not clear to me where the trunk branch fits in.
<jcastro> Yeah, the reason I posted to the list was that if you had questions you can respond, because james is in the uk and will hopefully answer it before you start your day tomorrow
<mchasal> Ok, I'll keep an eye on it.
<sebas5384> lazyPower: ping
<lazyPower> sebas5384: pong
<sebas5384> lazyPower: hey!
<lazyPower> whats up?
<sebas5384> we have a team here that are starting to using docker + ansible
<sebas5384> and the discussion of juju vs docker came up
<sebas5384> I understand the diference
<lazyPower> two completely different, and somewhat complimentary technologies.
<sebas5384> yeah I know
<sebas5384> but
<sebas5384> the thing that was concluded at the end of the discussion was that juju is more like if you need to install a docker cluster
<sebas5384> to then
<sebas5384> use docker
<sebas5384> and orchestrate your containers with other tool like flannel (i don't know really)
<lazyPower> sebas5384: flannel isn't an orchestration tool
<sebas5384> hmmm what is then?
<lazyPower> sebas5384: flannel is a software defined networking stack that compliments docker's networking bridge, so you can do L2 over L3 networking.
<lazyPower> eg: cross host networking
<sebas5384> hmmm get it
<sebas5384> thanks for the explaining
<lazyPower> sebas5384: the way i explain this to people who ask... (give me a minute to type this out)
<sebas5384> ok
<sebas5384> :)
<sebas5384> till that, the issue here was like, why Juju doesn't use docker as a provider
#juju 2015-03-10
<lazyPower> Docker is a software delivery mechanism. You're effectively creating (arguably...) an immutable container image that you run in production with everything pre-configured. This is just the deployment phase. Nothing in docker-core tells it how to connect to complimentary/required services. Given teh mediawiki example - docker by itself has no notion of a mysql db, now to create credentials in mysql, or how to get that information back to the running
<lazyPower>  docker container. Juju is an orchestration language that can wrap these components and provide that information/expertise to any service that understands how the declarative relationship model works.
<lazyPower> sebas5384: thats preaching to the choir - but we're prototyping around it.
<lazyPower> and you may see some interesting things emerge out of virtual services which will be discussed at our upcoming sprint in malta.
<sebas5384> ooh great
<sebas5384> lazyPower: so there is some work to get docker as a provider ?
<lazyPower> sebas5384: eh, 'as a provider' is a bit of a stretch
<sebas5384> just specified the docker daemon info
<lazyPower> keep your eyes peeled for mention of virtual services and once the spec is finalized someone may be able to shed more light about it.
<lazyPower> sebas5384: also that blog post is coming this week - i have a hard cut off date to do a writeup over my docker charm work.
<sebas5384> lazyPower: yeah, well using juju as a complete workflow tool for devops
<sebas5384> is not going to happen till we have something more fast like docker to spin up the services, and sharing changes
<sebas5384> I don't know how to explained better, but I would like to see juju as my only tool for deploying and orchestrating my services
<lazyPower> sebas5384: everyone has different requirements, and building a tool that wraps everybody's workflow as it stands today (with changes to core) is going to be slow going
<sebas5384> lazyPower: yeah thats my fear
<lazyPower> this is why virtual services is a compelling option - so dont abandon hope yet
<lazyPower> and dont let end users mistake juju for just a "deploymetn" solution. we're doing lifecycle management in charms and scaling - which is more than just "deployment"
<sebas5384> lazyPower: I really hope that juju uses docker as a provider and protocol to upgrade and deploy their services
<lazyPower> sebas5384: i just stopped in to check on offlines for the OCP demo - i'm goign to bounce out and finish my swap day. If you have any pressing questions about that feel free to hit up the list and i'll do my best to get back to you shortly :)
<sebas5384> lazyPower: sure! thanks :)
<sebas5384> lazyPower: i'll be waiting that article about the future of juju and docker o/
<jobot> @lazyPower hello
<lazyPower> jobot: hi
<jobot> oh hi, I had discussed a charm with you on the e-mail list earlier, and was wondering if you had any time to discuss it
<jobot> it was a suitecrm charm. I had trouble getting the database info to automatically populate during installation
<Muntaner> good morning to everyone!
<Muntaner> I'm trying to use the load balancer charm HAProxy for my charm. I set up everything, but when I try to access to the public IP of the load balancer, I get a 503 Service Unavailable. How can I diagnose my situation?
<Muntaner> more info: if I try to connect directly to the units of my charm, the connection hangs
<lazyPower> jobot: hey sorry about the *extended* delay in reply
<lazyPower> jobot: i'm firefighting for a demo atm - I'd be happy to pick this up tomorrow?
<turicasto> hi to all! o/
<turicasto> guys I have some problem with haproxy .. can someone help me?
<Muntaner> marcoceppi, ping
<bloodearnest> bradm, heya, seems we are fixing the same issue in rabbit
<bloodearnest> me: https://code.launchpad.net/~bloodearnest/charms/trusty/rabbitmq-server/add-nagios-service-groups/+merge/251790
<bloodearnest> you: https://code.launchpad.net/~brad-marshall/charms/trusty/rabbitmq-server/nagios-fixes-sync-charmhelpers/+merge/251551
<bloodearnest> bradm, are you gonna be working on it soon?
<bloodearnest> hmm, I have a simple apache2 charm-helpers sync MP: https://code.launchpad.net/~bloodearnest/charms/trusty/apache2/update-charm-helpers/+merge/252331
<bloodearnest> can I trigger an automated test run for it?
<Muntaner> can anybody help me with HAProxy? I totally dunno what to do
<gnuoy> Muntaner, what's the problem
<gnuoy> ?
<Muntaner> hi gnuoy
<Muntaner> I'm trying to use HAproxy to introduce load-balancing to my charm
<Muntaner> I'm following the wordpress charm code
<Muntaner> but can't get my HAproxy to work, since I get a 503 error
<Muntaner> and can't find useful logs
<Muntaner> gnuoy, need more infos?
<gnuoy> Muntaner, what does /etc/haproxy/haproxy.cfg have in it ?
<Muntaner> gnuoy, paste incoming
<Muntaner> gnuoy, http://paste.ubuntu.com/10573891/
<gnuoy> Muntaner, on the haproxy node what does "nc -zvw2 10.0.0.7 8080" return ?
<Muntaner> gnuoy, just a sec
<gnuoy> Muntaner, fwiw the haproxy monitoring page is really useful to see the status
<Muntaner> gnuoy, I get  port 8080 (tcp) timed out: Operation now in progress
<Muntaner> gnuoy, how can I reach it
<Muntaner> ?
<gnuoy> Muntaner, so it sounds like it is not a problem with haproxy. whatever you have attached to the haproxy is not serving content on 8080
<Muntaner> gnuoy, that's the motivation of the 503 error?
<gnuoy> Muntaner, yes, haproxy is saying none of its backends are available
<Muntaner> mh fine, my server is running on the 80 in fact gnuoy
<Muntaner> how can I set the correct backend?
<gnuoy> Muntaner, when your charm joins with haproxy I think it should set a port if I remember correctly
<gnuoy> Muntaner, the haproxy charm has a README with the details
<gnuoy> Muntaner, yes, the README shows what to do in the "1. Single-Service Proxying" section
<Muntaner> gnuoy, thanks
<Muntaner> looking about it
<Murali> Hi Jamespage
<Muntaner> gnuoy, seems to work now, thanks! how can I test my configuration to check if HAproxy is correctly working?
<Anz> While trying to deploy the openstack bundle @ https://jujucharms.com/openstack/29  , I am getting the following error http://paste.ubuntu.com/10574023/
<gnuoy> Muntaner, look at port 8080 on your haproxy node, it has a status page
<Anz> I had earlier deployed this succesfully in the very same MAAS environment before
<Muntaner> gnuoy, I have nothing at 192.168.0.97:8080
<gnuoy> Muntaner, sorry, I meant port 10000
<Muntaner> gnuoy, I get a 403 Forbidden
<Muntaner> I need to put a password, I guess
<gnuoy> Muntaner, look at haproxy.cfg it has the credentials in it
<Anz> Can someone please tell me what the issue is ?
<Muntaner> gnuoy, how should I give the password to haproxy?
<Anz> 2015-03-10 17:18:16 [ERROR] deployer.deploy: Invalid service placement mysql to lxc:juju-gui=0 2015-03-10 17:18:16 [ERROR] deployer.deploy: Invalid service placement rabbitmq-server to lxc:juju-gui=0 2015-03-10 17:18:16 [ERROR] deployer.deploy: Invalid service placement ceph-osd to juju-gui=0 2015-03-10 17:18:16 [ERROR] deployer.deploy: Invalid service placement neutron-gateway to juju-gui=0
<philip_stoev> marcoceppi: I have the Galera Cluster charm in my own LP directory. What is the procedure to make it a reviewed/Featured charm?
<philip_stoev> Should I start by filing a ticket at https://bugs.launchpad.net/charms/+filebug? If yes, then what title/tags should I give it?
<Muntaner> gnuoy, seems working
<Muntaner> gnuoy, my HAproxy is at 192.168.0.97. When I go on this url, it auto-redirects me to 192.168.0.93: is this the expected behaviour?
<Muntaner> (92 and 93 are the units of my web service)
<gnuoy> Muntaner, That is not expected and I don't think it's haproxy doing the redirect. It'll be the web service
<Muntaner> gnuoy, so I should use the web service remaining on the proxy IP?
<Anz> Hi Jamespage
<mwak> heya
<Muntaner> hi guys
<Muntaner> I have a problem with nova security groups and juju
<Muntaner> I have 100 security groups available in my project
<Muntaner> but Juju only uses 10 of them and then gives me errors if I try to launch new VMs
<Muntaner> any suggestions?
<mbruzek> Muntaner: that is a question for the OpenStack charmers like jamespage coreycb or beisner
<jamespage> Muntaner, check your security group rule quota
<Muntaner> jamespage, it is 100
<Muntaner> jamespage, you mean in nova?
<jamespage> Muntaner, well that depends
<jamespage> Muntaner, are you using neutron security or nova security?
<jamespage> Muntaner, also security groups and security group rules are separate quota items in neutron
<Muntaner> jamespage, nova security
<jamespage> Muntaner, same applies in nova
<beisner> may also be worth noting bug 1335885 if doing repetitive deploys (there's a potential for quota consumption there)
<mup> Bug #1335885: destroy-environment reports WARNING cannot delete security group <cloud-installer> <destroy-environment> <landscape> <openstack-provider> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1335885>
<jobot> ãlazyPower: np, yeah I went to sleep. Try to catch you later today.
<whit> to hell with vendoring charmhelpers... when do we get resource streams?
<Muntaner> hey jujuers
<Muntaner> I need to set which user the mysql charm is gonna use
<Muntaner> because I need it to be shared between many charms
<Muntaner> can I do that?
<DrewT> I've run into an issue when using the openstack-installer (and landscape) where the Ceph charm is trying to use the various removable media devices on the boxes as block storage
<DrewT> I have submitted bug: https://bugs.launchpad.net/charms/+source/ceph/+bug/1420094
<mup> Bug #1420094: Ceph install fails by using removable devices <cloud-install-failure> <cloud-installer> <landscape> <ceph (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1420094>
<DrewT> but, is there any way I can force the ceph charm to only use a specific block device and ignore everything else?
 * lamont is doing battle with juju-local and losing: chown: invalid user: âubuntu:ubuntuâ
<lamont> anyone wanna help a juju-local noob?
<lamont> (anyone happen to have a working type:local juju/environments.yaml snippet they can share?
<marcoceppi> lamont: sure, what's up?
<lamont> marcoceppi: tossed you a paste with what I'm seeing, and what I have.. clearly, it's not right.
<lamont> clue would be appreciated
<redelmann> hi, im having some troubles with juju 1.22-beta4
<marcoceppi> lamont: that's weird
<redelmann> it was working fine
<lamont> marcoceppi: verily
<marcoceppi> redelmann: what are you seeing?
<redelmann> now it always say: cannot read info: lock timeout exceeded
<marcoceppi> lamont: can you boostrap with --debug and -v flags?
<redelmann> from one moment to another
<marcoceppi> redelmann: when trying to do?
<lamont> ah, that might be better than the strace -ff output I just created
<redelmann> i already try
<redelmann> 2015-03-10 17:14:49 INFO juju.cmd supercommand.go:37 running juju [1.22-beta4-trusty-amd64 gc]
<lamont> marcoceppi: would it be signifcant to say that I'm running vivid?
<redelmann> 2015-03-10 17:14:49 INFO juju.utils.fslock fslock.go:146 attempted lock failed "env.lock", reading, currently held: reading
<redelmann> 2015-03-10 17:14:50 ERROR juju.cmd supercommand.go:411 there was an issue examining the environment: cannot read info: lock timeout exceeded
<marcoceppi> lamont: maybe, but it's good to know
<redelmann> im using lxc on local machine
<marcoceppi> redelmann: for future multiline pastes it'd be useful to use http://paste.ubuntu.com
<redelmann> marcoceppi: ok, sorry
<marcoceppi> redelmann: there's an issue trying to get a lock on your environment. Is this when trying to bootstrap?
<redelmann> marcoceppi: http://paste.ubuntu.com/10575661/
<lamont> http://people.canonical.com/~lamont/bootstrap.debug <-- marcoceppi
<redelmann> marcoceppi: no, i was working without any trouble, after deploy one ganglia instance it start to faild
<redelmann> marcoceppi: after that i couldn't do anything
<marcoceppi> redelmann: can you run the following: `sudo apt-get install pastebinit; sudo initctl list | grep juju | pastebinit`
<redelmann> http://paste.ubuntu.com/10575679/
<marcoceppi> lamont: can you (after cleaning up the file) paste ~/.juju/environments/local.jenv ?
<marcoceppi> redelmann: you already have an environment running, running a bootstrap will fail. Can you run `juju status` ?
<lamont> "~/.juju/environments/local.jenv" [New File]                                                                                                                                                                0,0-1         All
<marcoceppi> damn, I thought that was going to be it
<redelmann> marcoceppi: http://paste.ubuntu.com/10575695/
<lamont> http://paste.ubuntu.com/10575698/ <-- marcoceppi the actual and for true environments.yaml stanza, albeit redacted
<marcoceppi> redelmann: did you upgrade your juju client recently after bootstrapping that environment?
<marcoceppi> lamont: you can omit the authorized-keys-path, it's redundant as ~/.ssh/id_rsa.pub will be uploaded as part of Juju's logic
<redelmann> marcoceppi: no, i was just testing some local charms
<marcoceppi> mine is just type: local and admin-secret
<marcoceppi> redelmann: what does `juju version` produce?
<redelmann> marcoceppi: 1.22-beta4-trusty-amd64
<redelmann> marcoceppi: i cant destroy enviroment too.
<marcoceppi> redelmann: can you try `juju destroy-environment -y --force local` ?
<redelmann> marcoceppi: running with --force: ERROR cannot read environment info for "local": cannot read info: lock timeout exceeded
<marcoceppi> redelmann: well, we can clean it up manually, this is highly irregular
<redelmann> marcoceppi: sound like mongodb problem?
<marcoceppi> redelmann: possibly, lets see if this helps it recover
<marcoceppi> redelmann: try `sudo restart juju-db-redelmann-local; sudo restart juju-agent-redelmann-local`
 * lamont decides to confirm that openstack environments bootstrap, since this is a reinstalled box, after all
<lamont> juju bootstrap -e openvpn
<lamont> Launching instance
<lamont> seems to be
<marcoceppi> lamont: yeah, it's just with your local, and it's trying to chown ubuntu when there's really no need
<redelmann> marcoceppi: same problem, unable to connect to enviroment "local"
<marcoceppi> redelmann: okay, so manual clean up it is. If you want to "destroy" local do the following:
<redelmann> marcoceppi: ok, im "listening"
 * marcoceppi is typing
<marcoceppi> actually, just run this
<marcoceppi> https://github.com/juju/plugins/blob/master/juju-clean
<redelmann> marcoceppi: this is the second time it happend to me, the first time I thought it was a change of ip
<redelmann> marcoceppi: im connecting eth0 with lxcbr0, and sometimes dhcp gives me a different ip for lxcbr0
<marcoceppi> interesting, that shouldn't cause an issue since technically bootstrap node is on localhost
<marcoceppi> but it might be actually
<lamont> marcoceppi: is there a good way to make it stop trying to do that?
<marcoceppi> lamont: I haven't the slightest, this is a first for me
<redelmann> marcoceppi: one last quesion: is necessary to run "--upload-tools" in bootstrap?
<redelmann> marcoceppi: http://paste.ubuntu.com/10575811/
<redelmann> marcoceppi: Still same problem after clean
<redelmann> marcoceppi: maybe deleting .juju/enviroments/local.jenv
<redelmann> marcoceppi: i solved it
<marcoceppi> what was it?
<redelmann> marcoceppi: env.lock direcory inside enviromens
<redelmann> marcoceppi: http://paste.ubuntu.com/10575825/
<marcoceppi> interesting
<redelmann> marcoceppi: think i destroy my enviroment for nothing :P
<marcoceppi> env.lock is a new direcetory
<marcoceppi> I'll add it to the juju-clean script
<redelmann> marcoceppi: Ok, after that i needed to run juju-clean again
<redelmann> marcoceppi: thank for the help
<lamont> marcoceppi: at what point should I see juju fire up a jujud on my machine?  (I don't have one)
<marcoceppi> lamont: there's a line in the local output that says something to the effect of "starting agent"
<hazmat> lamont: basically it should be there as soon as cloud init finishes, if not you should check the cloud-init-output.log in /var/log/
<hazmat> assuming this isn't the bootstrap node
<hazmat> if it is the bootstrap node.. bootstrap with --debug and you'll see the ssh interaction
<lamont> sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges? <-- I wonder if that's relevant
<lamont> oh haha.  strace
<lamont> hazmat: http://paste.ubuntu.com/10576054/ hazmat: what I see is it getting completely lost looking for tools, and then things get weird
<hazmat> lamont: ic. that just looks a  juju bug with vivid, it looks like default user ubuntu isn't in that cloud image
<lamont> hazmat: can I trivially force it to only use trusty? or does lxc mean that it must use vivid?
<lamont> I just want it to bootstrap, man.  well, and then do a bunch of deploys, I guess
<hazmat> lamont: so try just adding an ubuntu:ubuntu user on the host,
<lamont> does that user need privileges?
<hazmat> lamont: so your host is vivid? .. it looks like its trying to bootstrap on the host and assuming the 'ubuntu' user is there
<hazmat> lamont: probably .. password less sudo
<lamont> host is vivid, ubuntu user never has been there
<hazmat> yeah.. that's just broken/buggy imo
<hazmat> shouldn't assume that for local provider
<hazmat> once you get it working you can use any series, normally series gets picked up from the charm unless your doing add-machine in which case you can pass it explicitly
<lamont> http://paste.ubuntu.com/10576080/ <-- I suppose that constitutes "progress"
 * hazmat would stalk some juju devs
<hazmat> lamont: i just pinged folks on #juju-dev hopefully somebody turns up
<lamont> ta
<lamont> fwiw, no mongo processes running, though juju-mongodb has been installed
<jrwren> lamont: its an upstart not found message, could this related to yesterday's move to systemd?
<lamont> jrwren: quite possibly
<ericsnow> lamont: juju on vivid has been working fine for a while, but vivid is about to (or just did) switch to booting with systemd
<lamont> ericsnow: 2015-03-09 (yesterday)
<lamont> if this is a known thing that'll be fixed for vivid sometime soon, I'll just keep using openstack for testing
<ericsnow> lamont: we are wrapping up adding support for systemd in the next juju release (1.23)
<ericsnow> lamont: also, there's a know issue where a vivid container (running systemd) won't work on a non-vivid host (trusty and utopic can be made to work though)
<ericsnow> s/know/known
<lamont> ericsnow: does that make the workaround for the meantime "use an utopic schroot"?
 * lamont actually wants trusty containers
<lamont> maybe I'll just use a trusty box, instead of my vivid box
<lamont> sometimes, bleeding edge sucks
<ericsnow> lamont: trusty works if you've updated a few packages out of "trusty-updates"
<ericsnow> lamont: see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1347020
<mup> Bug #1347020: systemd does not boot in a container <systemd-boot> <lxc (Ubuntu):Fix Released by stgraber> <lxc (Ubuntu Trusty):Triaged by stgraber> <https://launchpad.net/bugs/1347020>
<ericsnow> lamont: for testing I've been running local provider in a vivid KVM
<lamont> ericsnow: ah, that has potential
<lamont> ericsnow: meaning your "juju-local on vivid" test box is a kvm?
<ericsnow> lamont: anyway, I'm hoping to land the last patch for systemd-on-vivid support in a little bit
<ericsnow> lamont: yep
<ericsnow> lamont: but most of my testing has been limited to just bootstrapping
<lamont> ericsnow: I would be most interested in being a tester for you.
<lamont> but first, lunchtime
<fraterlaetus> hi
<fraterlaetus> I just set up a private cloud using canonical/landscape/openstack
<fraterlaetus> as part of it, it created me a juju endpoint.
<fraterlaetus> How do I: A: get credentials for the juju endpoint; B: start playing?
<fraterlaetus> ELI5 please?
<fraterlaetus> Does anyone know how to create credentials for juju in openstack?
<fraterlaetus> ^^ ?
<jobot> lazyPower: hello, how's it going?
<fraterlaetus> :(
#juju 2015-03-11
<wgrant> ericsnow: Is there a PPA around with a vivid-compatible juju?
<marcoceppi> wgrant: doesn't look like it. I just checked devel and stable ppas they all stop a utopic
<wgrant> marcoceppi: Well, utopic's not a problem, but they all seems to stop at 1.22
<wgrant> vivid needs a 1.23 pre-release.
<wgrant> (because of systemd)
<marcoceppi> wgrant: you'll want to talk to sinzui and the release team about that
<wgrant> marcoceppi: Ah, thanks.
<apuimedo> Hi everybody
<apuimedo> I'm getting an error bootstrapping
<apuimedo> http://paste.ubuntu.com/10579001/
<apuimedo> (it happened twice)
<apuimedo> marcoceppi: ^^
<apuimedo> marcoceppi: I also wanted to know if https://jujucharms.com/cassandra/precise/17 is going to have a trusty version, so that we (midonet) can rely on it.
<Murali> apuimedo: please check if proxy or firewall settings
<apuimedo> hey Murali! did you collect those logs?
<Murali> we had issues while deploying, now we got resolved and services of openstack installed using juju-quick start
<Murali> but relations not added we now looking in to it
<stub> apuimedo: I've got a rewrite of Cassandra for trusty up for review.
<apuimedo> stub: that's great!
<apuimedo> do you know when it could be released?
<stub> apuimedo: lp:~stub/charms/trusty/cassandra/spike should do the trick
<stub> apuimedo: When it gets through the review queue
<stub> (How long is a piece of string)
<Murali> apuimedo: we will try to send today once after midonet-component deploys
<apuimedo> Murali: good
<apuimedo> Murali: can you be more specific on what you had to fix on proxy/firewall settings?
<Murali> we had some firewall rules on our gateway. it was blocking to connect to canonical sites
<apuimedo> ah,ok
<lazyPower> stub: err, i dont see the cassandra spike in the revq - http://review.juju.solutions/
<lazyPower> stub: how long ago was that submitted?
<stub> lazyPower: It got pushed to the very bottom
<lazyPower> aaahhh
<stub> https://bugs.launchpad.net/charms/+bug/1419116
<mup> Bug #1419116: New trusty/cassandra charm <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1419116>
<lazyPower> yeah i wasn't looking for cassandra, i was looking for stub
<lazyPower> herp derp, lazy needs coffee
<stub> But swings and roundabouts - I woke up an old PostgreSQL branch and it ended up at the very top ;)
<lazyPower> sweet action
<apuimedo> turns out I made the wrong assumption, that bootstrapping could be done offline from the internet :P
<apuimedo> I had to do some masquerading on the maas machine
<apuimedo> lazyPower: how long does the review process typically take?
<lazyPower> Depends entirely on the size of the queue, people available during the week giving reviews, how long they are able to work reviews without being interrupted - we strive for a week or less but that has been slipping lately with all the demo work we've had passed through the ~charmer team
<apuimedo> :-)
<apuimedo> thanks for the info
<apuimedo> lazyPower: what's the stance on puppet/ansible/salt for doing the charms work?
<lazyPower> we <3 that - please do use configuration management tools in your charm
<apuimedo> cool
<apuimedo> and for installing the configuration management, is there any preferred way?
<apuimedo> i.e., should each charm of a bundle try to install puppet?
<lazyPower> We have a few charm helpers for some of the services like ansible.
<lazyPower> there's a template for chef charms
<apuimedo> unfortunately no puppet, and that's what we use at the moment
<apuimedo> but I guess I can infer
<lazyPower> but if you're looking at introducing puppet - we dont have a good boilerplate charm for that. Typically what i've seen is either the install hook takes care of the predependencies, and what would normally go in install is moved to config-changed, or a script is called for pre-bootstrap to setup the CM framework - and any additional logic is then placed in a secondary install script that runs - but remember its only run once.
<apuimedo> good
<lazyPower> apuimedo: if you want one of us to take a look at your charm construction once you've got the puppet delivery done i'd be happy to
<lazyPower> i'm the current author/maintainer of the chef bits - they're fairly similar from what i understand
<apuimedo> lazyPower: thanks, right now I was just trying to decide if I can remove a charm that we have that is just using puppet to install repos
<apuimedo> and that charm must be deployed to each machine, which is a bit bothering
<lazyPower> seems like that could be abstracted
<apuimedo> yes, probably a single puppet-midonet charm that configured the puppet for the other services in relation-joined
<lazyPower> apuimedo: what would be nice is if we had composability in charms, so you could just inheret from that.
<apuimedo> like, puppet-midonet config.yaml has a setting called 'repo' that points to which repo/release you want
<apuimedo> then, when deploying midonet-agent, it would do nothing
<apuimedo> until you do the relation joined with the puppet-midonet controller
<lazyPower> yeah, i've got similar logic in the docker/flannel-docker charms
<apuimedo> that would tell it which puppet config to write to the midonet-agent puppet
<lazyPower> i needed to set/pass data out of band that was dependent on etcd having joined w/ flannel before we did anything with the networking.
<apuimedo> yup, sounds similar
<apuimedo> I'll have to make a charm eventually that gives nova-docker ;-)
<apuimedo> (with midonet, of course :P )
<lazyPower> Interesting :)
<lazyPower> I just wrapped up my breakdown over the work we did earlier this year with docker (completely negating anything we're doing now with kubernetes... that post is forthcoming) - http://blog.dasroot.net/2015-charming-with-docker.html   Feel free to give it a go and leave any comments about the future of this stack on the list :) We're interested in feedback
<apuimedo> cool, thanks
<apuimedo> lazyPower: what does juju do if a hook file does not exist, i.e., if install is missing?
<lazyPower> skips it with exit 0
<apuimedo> cool
<apuimedo> I want to avoid placeholder files :-)
<rbasak> sinzui: o/
<sinzui> hi rbasak
<rbasak> sinzui: I'm looking into getting new Juju uploads to Vivid done.
<rbasak> sinzui: but I'm not clear on what version we want to upload right now, as that's changed a few times.
<rbasak> sinzui: (and also Trusty)
<rbasak> sinzui: do you know what the current request is?
<sinzui> 1.21.3 is current, but we expect to propose 1.22.0 this week for general release next week
<rbasak> Will you want 1.22.0 in Trusty?
<sinzui> rbasak, eventually
<rbasak> But not yet?
<rbasak> As in - simultaneously with your general release next week, or some time after that?
<sinzui> rbasak, I think we should let 1.22.0 sit in the wild for a bit
<rbasak> How do you feel about putting 1.22.0 into Vivid, but leaving Trusty for now?
<sinzui> rbasak, +1
<rbasak> OK - so I'll wait for your 1.22.0 proposed release - thanks.
<sinzui> rbasak, I am scheduled to propose it tomorrow
<rbasak> Sounds good! We can try and release simultaneously to Vivid - I have someone helping me on this one.
<rbasak> sinzui: oh, one more question. Will 1.22.0 have systemd support? We're failing dep8 tests on Vivid I think for this reason right now.
<rbasak> So if not we'll need a solution as Vivid is now systemd.
<sinzui> rbasak, once the streams are published, I have a wee to certify the ubuntu packages, but note that it wont work with the default streams. so you need to delay or use proposed
<sinzui> I mean ubuntu proposed where people know to do something special to use it
<rbasak> sinzui: we'll hold in vivid-proposed until you've published streams - no problem.
<sinzui> rbasak, 1.23-beta1 will be the first juju to use systemd, and I can say the test results are mixed this morning. I will be working with ericsnow to discuss my vivid setup or his new features
<rbasak> sinzui: OK - but then in that case, is there much point in having 1.22 in Vivid at all - either in Ubuntu or in your PPA?
<rbasak> I suppose in your PPA users could still manually switch to upstart.
<sinzui> rbasak, yeah, that was my own concern. For myself. I have a juju env running 1.21.3, so I can no longer provision a vivid machines without upstart.
<sinzui> rbasak, so to summarise, juju-core  is fine to deploy in to clouds, but juju-local package may need to depend on upstart
<sinzui> rbasak, and for juju 1.23.x, we change juju-local to depend on systemd
<turicasto> hi guys!
<turicasto> I'm writing a charm, can i ask some questions about the command "relation-get"
<turicasto> ?
<marcoceppi> turicasto: you certainly can, it's best in this channel to just ask your question
<rbasak> sinzui: can I just confirm I understand that please?
<turicasto> marcoceppi: thank you
<rbasak> sinzui: juju < 1.23 can deploy vivid machines by requesting upstart?
<rbasak> And that's automatic?
<turicasto> marcoceppi: Can I get the public address of a loadbalancer linked to my charm, only in "loadbalancer-relation-*" hook? or in other hook too?
<marcoceppi> I don't think the loadbalancer advertises it's public-address in the http interface, you can get it's private address by doing `relation-get private-address`
<turicasto> marcoceppi: ok, but can I get some information (like private-address) of a loadbalancer in all hooks? For example can i get the loadbalancer private address in "db-relation-joined"? There is a location where i can find all the information of the services  linked to my charms?
<lazyPower> turicasto: that can be tricky to get information out of band. You have to know the relationship id #, and use relation-get -r realtion:id
<lazyPower> turicasto: its in our docs under hook environment authoring here:  https://jujucharms.com/docs/authors-hook-environment
<turicasto> lazyPower: thanks!
<sinzui> rbasak, the juju client doesn't use upstart or systemd. The init system is only relevant to what you deploy. there are no official utopic or trusty charms, so juju on vivid will just work. But developers/testers may want to run juju on their local host In that case the juju-local package will also need to depend on upstart or systemd as needed
<rbasak> sinzui: OK, but what about when you deploy a vivid system with juju? What versions of juju will support that as vivid defaults to systemd?
<rbasak> sinzui: is the answer to that "none, until 1.23?"
<sinzui> rbasak, 1.23-beta1 and above
<rbasak> OK, got it. Thanks.
<rbasak> sinzui: we're expecting a stable 1.23 before Vivid releases, right?
<rbasak> So we can expect to ship that in Vivid, and thus upon release Vivid juju will be able to deploy Vivid on systemd without breaking?
<sinzui> rbasak, it is very close to the deadline.
<rbasak> OK
<apuimedo> lazyPower: if you have several instances of a service running
<sinzui> rbasak, I will bring this up in the meeting I am going into now
<rbasak> Thanks
<apuimedo> so for example several keystones
<apuimedo> when you add-relation between something and keystone
<lazyPower> apuimedo: this is where the id's come into play. the relationship name, + the id of the relationship is specific to a host.
<apuimedo> yes, but when you do, juju relation-add myservice keystone
<apuimedo> it establishes relation between all keystones and myservice?
<lazyPower> correct
<apuimedo> so relation-joined and after that relation-changed will be called several times, right?
<lazyPower> correct, at least once for every service - possibly more if something is relation-set to send over the wire
<lazyPower> *for every unit in the service(s)
<apuimedo> that's nice
<apuimedo> thanks again ;-)
<lazyPower> cheers :)
<turicasto> lazyPower: It's that normal that the hook "loadbalancer-relation-joined" not start when i link a loadbalancer to my charm?
<rbasak> sinzui: when is 1.23-beta1 scheduled for please?
<lazyPower> that should run in context of the relationship first being made (as in, executes once - the services are not yet in a bi-directional communication pipeline yet)
<lazyPower> so, thats odd if its not.
<sinzui> rbasak, either thursday or monday. I really depends on 1.22.0 entering proposed first
<rbasak> sinzui: OK, thanks!
<apuimedo> lazyPower: is there some place where I can see all the hook commands (like relation-list) and some sample output or I just have to make dummy charms and try it out?
<lazyPower> apuimedo: its a short list of commands, iirc - relation-get, relation-set, and unit-get
<lazyPower> and config-get
<lazyPower> thats all thats rattling around up in my head - but we do appear to be missing an agent reference sheet in the docs
<apuimedo> lazyPower: what would be the most useful is to have examples of their outputs in both the json and the plain text output
<lazyPower> https://github.com/juju/docs/issues/283
<apuimedo> so charm developers can code up the parsing earlier on
<apuimedo> lazyPower: tells me "this is not the page you are looking for"
<lazyPower> well thats odd
<lazyPower> its a bug to track the missing agent command reference for inclusion into the docs
<apuimedo> lazyPower: https://jujucharms.com/docs/authors-hook-environment has only the plain text output
<apuimedo> lazyPower: ok
<lazyPower> apuimedo: I highly encourage you to file bugs against our docs for anything you feel would enhance your experience looking them over. We are continually working on teh docs trying to improve them - and your feedback is invaluable in that process :)
<lazyPower> https://github.com/juju/docs/issues/
<apuimedo> lazyPower: very well, now it loaded and I commented on the issue
<lazyPower> stellar, thanks for that
<apuimedo> lazyPower: I take it that charm-helpers is already committed to backwards compatibility, right?
<Muntaner> hey guys
<Muntaner> I have a problem
<Muntaner> an hook is never called. It is a "relation-joined". How can I investigate? May I have a problem in my yawls (config or metadata) ?
<lazyPower> apuimedo: you are correct
<apuimedo> good
<lazyPower> Muntaner: -joined is not running, but -changed is?
<Muntaner> lazyPower: none is running
<lazyPower> Muntaner: can you point me at a repository of your charm,  and show me the commands you're running in a pastebin?
<rogpeppe> marcoceppi: hiya
<rogpeppe> marcoceppi (or anyone else): do you know what the current rules are for determining whether a given bundle is promulgated?
<marcoceppi> rogpeppe: it must be owned by charmers
<marcoceppi> It does not operate like charms
<rogpeppe> marcoceppi: right, thanks
<rogpeppe> marcoceppi: that was my understanding, ta
<marcoceppi> Np, cheers
<gsamfira1>  alsi, I will change the comment I made in the function
<apuimedo> lazyPower: marcoceppi: in my 14.04 box juju help-tool relation-list does not show any example output
<apuimedo> sorry if I'm being obtuse and I should be passing something extra
<lazyPower> apuimedo: nah, i think we're jsut being unreasonably difficult about getting a listing in the docs under a heading thats less obscure than "How the innards of juju works - inflect on what that means pleb"
<apuimedo> :P
<narindergupta> jose: hazmat marcoceppi jamespage: Nuage network wrote the charm and they wants to merge the latest working code. Do we know which is good branch they can merge into their charm which will work?
<jose> narindergupta: which charm?
<jose> also, no need to highlight us all :)
<narindergupta> jose: openstac charms
<narindergupta> jose: was just wondering who can answer the query?
<lazyPower> beisner: ^
<jose> narindergupta: if you have a suggestion, then make a merge proposal against lp:charms/charmnamehere for precise, and lp:charms/trusty/charmnamehere for trusty
<marcoceppi> jose: it's different for openstack-charms
<jose> ah, sorry then
<jose> thought they had the aliases too
<marcoceppi> they do, but things must first land in a dev branch
<jose> ah, huh
<narindergupta> marcoceppi: jose: so what Nuage should do? They have charms in https://code.launchpad.net/~nuage-canonical/ and finding an issue with nova-compute and wants to merge the charm code into their code so can test and verify.
<narindergupta> marcoceppi: jose: but they are not sure which branch to take. I suggested to start with release branch but I might be wrong.
<marcoceppi> narindergupta: I'm not sure I understand the question
<jose> marcoceppi: they wanna do an MP against an openstack charm
<marcoceppi> do they though?
<narindergupta> marcoceppi: jose: merge propsal is already made https://code.launchpad.net/~nuage-canonical
<jose> nope, https://code.launchpad.net/~nuage-canonical/charms/trusty/nova-compute/next/+merge/249410
<jose> ^^^ has the MP
<marcoceppi> right, so I don't think we understand the query
<jose> marcoceppi: they wanna know if the MP they did is good or if they should choose another target branch
<jose> let's say myself, I've fixed an openstack charm and wanna open an MP for peer review
<jose> where should I point it to? lp:charms/precise/nova-compute for nova-compute?
<marcoceppi> jose narindergupta they want to target the next branch of the openstack charm
<marcoceppi> not the current one
<jose> gotcha.
<jose> narindergupta: so, your current MPs are not going to get processed since they are targetting the wrong branches
<jose> let me get you the right ones
<narindergupta> jose: marcoceppi: i am confused can someone look into those MP and say that everything is ok or different MP is required/
<marcoceppi> narindergupta: beisner and jamespage would be the best to confirm, but from what I understand unless it's a bug fix everything should target next
<narindergupta> marcoceppi: what about charm helpers that does not have next?
<marcoceppi> narindergupta: no, it doesn't
<beisner> narindergupta, please see the openstack charm development policy @ https://wiki.ubuntu.com/ServerTeam/OpenStackCharms
<marcoceppi> beisner: ta for the link
<beisner> marcoceppi, yw
<dpb1> hi -- if I run 'go test -gocheck.v github.com/juju/juju/...' I only get one thing tested.  without the -gocheck.v, I get all the test suites executed with a bunch of failures (and no output). How can I see output from the failing test cases?
<apuimedo> thanks evilnickveitch
<mgz> dpb1: the arguments and ordering for go test is finickity
<evilnickveitch> apuimedo, np
<beisner> hi jose, fyi, it's also worth noting that openstack charms are different in that we really only target 1 series (trusty), and it is intended to be backwards/forward compatible with all currently-supported versions of Ubuntu and OpenStack (except Essex).
<jose> gotcha
<jose> thanks!
<narindergupta> beisner: marcoceppi: Nuage is asking do we know the last known stable version of next for openstack charm? AS team wants to test against those first to make sure everything is good.
<beisner> hi narindergupta - the syntax for any given "next" (development) branch of an openstack charm is:
<beisner> lp:~openstack-charmers/charms/trusty/cinder/next
<mgz> dpb1: the easiest option tends to cd into github.com/juju/juju and `go test ./... -gocheck.v`
<dpb1> mgz: yes, but I think that ignores the gocheck.vv arg
<dpb1> at least, I don't see any extra output
<narindergupta> beisner: ok so I will ask them to merge the changes from this branch and test if successful then send the merge proposal to next itself.
<dpb1> just FAIL testname..., etc
<mgz> dpb1: you get more output on the failed tests
<dpb1> mgz: I'll paste
<beisner> narindergupta, so that is the example from the wiki link, and it's for cinder.   you'll need to substitute the charm name you're working with in place of cinder.
<narindergupta> beisner: gotch you thanks
<beisner> narindergupta, yw.  holler with any ?s.
<dpb1> mgz: http://paste.ubuntu.com/10581353/
<narindergupta> beisner: sure and thanks. hot right now is merge proposal into charm helper as well.
<narindergupta> beisner: like this one https://code.launchpad.net/~nuage-canonical/charm-helpers/charm-helpers
<narindergupta> beisner: i am hoping this MP is valid?
<mgz> dpb1: the tests din't fail, the build failed
<beisner> narindergupta, i think you only need to propose against lp:charm-helpers
<dpb1> mgz: ok, I'm a go newb, obviously. :)
<mgz> dpb1: did you run `godeps -u dependencies.tsv` first?
<dpb1> yes, ran that, but it produced no output, let me check it again
<narindergupta> beisner: ok deleted the merge proposal against the stable now. Hope we are good to go from here. Not sure how to make this progress. As once this MP compelte then i need to resync the other openstack charm and resubmit the merge proposal. Also what the good way to sync the latest code into existing charms?
<dpb1> mgz: http://paste.ubuntu.com/10581379/
<dpb1> mgz: same result with your ./... syntax
<dpb1> I'm working off this, btw: https://github.com/juju/juju/blob/master/CONTRIBUTING.md
<beisner> narindergupta, do you mean the /next/ charm code?   or the charmhelpers code?
<narindergupta> beisner: both as charmhelper needs to merge first then only /next charm code MP can be sent.
<mgz> dpb1: yeah, it's not test running related, just `go test -i github.com/juju/juju` should fail for you
<mgz> dpb1: for whatever reason, the copy of code.google.com/p/go.crypto/ssh it's building against is wrong
<mgz> cd into that and see what mercurial says, versus what's in dependencies.tsv
<dpb1> ok, checking now
<dpb1> ok, all those tests pass (in $GOPATH/src/code.google.com/p/go.crypto/ssh)... checking some more
<dpb1> hg summary says I'm at tip
<dpb1> but hm
<dpb1> let me get rid of my whole $GOPATH and do over
<dpb1> (juju is the only go thing I have)
<beisner> narindergupta, we re-sync charmhelpers across all openstack charms a few times each cycle.  so if the change makes it into charmhelpers, we can push it out to all of the /next/ charms.
<beisner> narindergupta, how many nuage changes to charms are just a charmhelper sync?
<narindergupta> beisner: they are SDN so additional plug in changes in charmhelper
<beisner> narindergupta, let me re-phrase:   are there any changes to openstack charms OTHER THAN what's in charmhelpers for nuage?
<narindergupta> beisner: but then they have quantum-gateway, neuton-api, openstack-dashboard, keystone, glance, nova-comute, nova-cloud-controller, and cinder
<narindergupta> beisner: needs sync based on charmhelpers
<narindergupta> beisner: plus nuage has three additional charms for openstack to implement their SDN
<beisner> narindergupta, see https://code.launchpad.net/~nuage-canonical/charms/trusty/nova-cloud-controller/next/+merge/249411/comments/622308
<beisner> narindergupta, that is also my question.
<beisner> narindergupta, what we're saying is:   don't worry about doing MPs for all of the charms --if-- it is just a charmhelper sync.
<narindergupta> beisner: yes that was done and i proposed a charm-helpers changes
<narindergupta> beisner: ok so  i will drop the MP for those charms then which does not need changes.
<narindergupta> beisner: neuton-api charm is another charm which needs more than charmhelper changes
<beisner> narindergupta, ok great.  i think that will help with clarity.  i apologize - i'm not overly familiar with the project and i'm just digging into each branch to see what's going on.
<beisner> narindergupta, right, so keep those MPs where there are add'l changes.
<narindergupta> beisner:  no proble,
<narindergupta> beisner: ok i will clean up MP a bit then
<beisner> narindergupta, thanks.  i'll have a look at their neutron-api MP.
<narindergupta> beisner: ok neuton, quantum-gateway
<narindergupta> beisner: and few other
<narindergupta> beisner: i clear it up and now we ahve total 5 MP on neutron-api, charm-helpers, quantum-gateway, nova-compute and nova-cloud-controller
<beisner> narindergupta, ok thank you, i'll post a comment on them individually.
<narindergupta> beisner: thanks
<dpb1> mgz: thx for the help.  blowing away GOPATH/* and re-going through things fixed it.
<dpb1> mgz: now, I just need to increase my /tmp since 2G is not enough for juju test apparently
<dpb1> :)
<mgz> dpb1: cool :)
<beisner> narindergupta, the charmhelpers proposal has some pep8 / python syntax issues.  see comments on the MP.
<narindergupta> beisner: ok looking into it and also on this http://paste.ubuntu.com/10179495/ it seems upstream charm also fails this test on my machine without modifying the same
<beisner> narindergupta, no, i'm talking about the charmhelpers proposal, not a charm proposal.
<beisner> narindergupta, i've added comments to MPs:  neutron-api, charm-helpers, quantum-gateway, nova-compute and nova-cloud-controller
<narindergupta> beisner: yeah for that i am checking right now
 * beisner will bbiab
<narindergupta> beisner: for charmhelpers in file charmhelpers/contrib/openstack/context.py line 189 already have the issue which i can not fix context.py:189:80: E501 line too long (81 > 79 characters)
<narindergupta> but other two issue i am fixing
<narindergupta> beisner: after fixing the error i have resubmitted the MP on charm helpers unfortunately can not resolve the error   narinder:$ flake8 charmhelpers/contrib/openstack/context.py
<narindergupta> charmhelpers/contrib/openstack/context.py:189:80: E501 line too long (81 > 79 characters) which is already existing in upstram charm helpers
<adalbas> jcastro, arosales , mchasal : i have just submitted the gpfs charm to trunk
<arosales> adalbas: ah good to hear :-)
<arosales> adalbas: I don't see it yet @ http://review.juju.solutions/
<adalbas> arosales, i believe this will be under your eyes for review as well, right?
<adalbas> or does it require other steps?
<adalbas> arosales, it says it requires about 15 min to be available, is it?
<mchasal> arosales, jcastro did mention about a 15 minute lag before it actually shows up.
<arosales> adalbas: not so just my eyes but the juju communities, and the ~charmers for the final promotion into the recommeded portion of the charm store
<arosales> adalbas: did you follow https://jujucharms.com/docs/authors-charm-store#submitting
<adalbas> arosales, es
<adalbas> yes
<arosales> adalbas: ah great, then it will show up in the queue shortly and follks will add a review in its turn
<adalbas> great!
<arosales> adalbas: thanks for your contribution, good milestone
<adalbas> arosales, and mchasal as well. one question i still have is that people would need gpfs packages to run this.
<adalbas> arosales, is there anyone in your teams that have the license for that?
<adalbas> arosales, btw, looking forward for the feedback.
<arosales> adalbas: not on canonical team, but I would suggest to document in the readme how to obtain a license and get a package?
<arosales> adalbas: does the charm assume the package is placed in a specific directory?
<adalbas> arosales, we have documented how to create a repo for those packages
<adalbas> but yes, good point on how to get the license
<mchasal> I'm not sure we'll be able to document anything other than "contact your IBM sales rep" but we'll look into it.
<arosales> adalbas: yes, as long as someone can read the readme and get GPFS running that should be a good starting point. We'll have to see in the charm on how to inject the license and GPFS package.
<beisner> narindergupta, yep i noticed that pre-existing issue in c-h too.  it's ok to just fix the things which are relevant to your changes.
<narindergupta> beisner: ok fixed now and resubmitted the MP
<narindergupta> beisner: for rest of charms i would like Nuage to work on it as they are in process of merging the new change from next so it impact the other changes as well.
<beisner> narindergupta, next I would re-sync charmhelpers (from your proposed branch) on each of the charm branches.
<beisner> narindergupta, for example, on the neutron-api charm, you would temporarily modify Line 1 here:  http://bazaar.launchpad.net/~nuage-canonical/charms/trusty/neutron-api/next/view/head:/charm-helpers-sync.yaml#L1
<beisner> narindergupta, use your custom charm-helpers branch there.   then run:     make sync
<beisner> narindergupta, on  nuage's neutron-api, quantum-gateway, nova-compute and nova-cloud-controller branches.
<narindergupta> beisner: gotch you
<beisner> narindergupta, once they all have the lint fixes, then change Line 1 back to default @ http://bazaar.launchpad.net/~nuage-canonical/charms/trusty/neutron-api/next/view/head:/charm-helpers-sync.yaml#L1
<narindergupta> beisner: do i need to create the file charm-helpers-sync.yaml
<beisner> narindergupta, no.  the file exists in each charm already.
<narindergupta> beisner: which directory i am not able to find it
<beisner> narindergupta, which charm?
<narindergupta> beisner: says nova-cloud-controller
<narindergupta> beisner: http://bazaar.launchpad.net/~nuage-canonical/charms/trusty/nova-cloud-controller/next/files
<narindergupta> i am seeing    charm-helpers-hooks.yaml and    charm-helpers-tests.yaml
<narindergupta> not sync
<beisner> narindergupta, ah.  if that file doesn't exist, look for the  charm-helpers-hooks.yaml  file.
<narindergupta> beisner: yeah that there
<beisner> narindergupta, but in no case should you have to create a charm-helpers-????.yaml file, make sense?
<narindergupta> yeah
<beisner> narindergupta, there is a good reason for the differing file names btw.  though it's unrelated to what we're working on here.
<ctlaugh> I have a change to the nova-compute charm that I would like to request to have merged.  Is there anyone particular that I need to add as a reviewer in the request?
<narindergupta> beisner: gotch you yeah i can see because those sync the directories from the charm-helpers and it make sense
<beisner> hi ctlaugh
<ctlaugh> beisner: hi
<beisner> ctlaugh, first stop should be to read up @ https://wiki.ubuntu.com/ServerTeam/OpenStackCharms
<beisner> ctlaugh, ie. to make sure you're basing and proposing against the right branch.
<beisner> ctlaugh, for the reviewer, please use  "OpenStack Charmers"
<beisner> narindergupta, can you please add OpenStack Charmers to your MPs?   (request another review)
<narindergupta> beisner: means?
<beisner> narindergupta, with each merge proposal, you request a reviewer.   instead of 1 human as a reviewer, we need to have the whole team requested to review it.
<mchasal> arosales, still not seeing that gpfs charm after about 30 minutes. Guess we didn't get something quite right.
<narindergupta> beisner: ok i did not add any reviewers before but just now added the openstack-charmers to https://code.launchpad.net/~nuage-canonical/charm-helpers/charm-helpers/+merge/252644
<ctlaugh> beisner: ok, looks like I need to redo -- I didn't start off of /next
<narindergupta> beisner: hope that should be ok
<ctlaugh> beisner: thank you for the wiki link
<beisner> ctlaugh, lp:~openstack-charmers/charms/trusty/nova-compute/next   is the dev branch
<arosales> mchasal: do you have a link to the launchpad branch?
<mchasal> https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-mq/devel
<mchasal> oops not that
<beisner> ctlaugh, you may be able to just do a bzr merge lp:~openstack-charmers/charms/trusty/nova-compute/next on your branch (might try, see how it shakes out).
<narindergupta> beisner: once i will fix the other openstack charms then i will resubmit
<mchasal> arosales, https://code.launchpad.net/~ibmcharmers/charms/trusty/gpfs/trunk
<arosales> mchasal: taking a look
<mchasal> thanks
<arosales> marcoceppi: what is the injestion time on the review queue?
<beisner> narindergupta, perfect, thank you.
<mchasal> I do see 20 minutes listed on the review page as the "don't bother us until it's been this long"
<arosales> mchasal: also depends on when that 20 min ingestion starts
<mchasal> Sure, I was assuming that meant it would have happened by then no matter where the batch kicks off, but yeah, could be. If we should wait longer, that's fine, just want to fix the problem if there is one.
<aisrael> tvansteenburgh: When running bundletester against amulet-driven tests, should allocated machines be automatically terminated?
<tvansteenburgh> aisrael: yes, unless you specify not to in tests.yaml
<tvansteenburgh> aisrael: reset=false iirc
<aisrael> tvansteenburgh: ack, thanks
<ctlaugh> beisner: I think I am messing something up trying to merge.  When I tried, I ended up getting an email that listed of a long list of changes that weren't a part of my change.  I went to my branch, clicked "propose for merging" and took the default branch that was selected.  Is that right?
<beisner> ctlaugh, can you paste your branch link that has the changes you're wanting to propose?
<ctlaugh> beisner: https://code.launchpad.net/~clark-laughlin/charms/trusty/nova-compute/arm64-patch
<narindergupta> beisner: have one question should i use the charmhelper stable branch or charm-helper  branch for changing the other charms. After syncing i am seeing multiple change into charmhelper directory of my openstack charms
<arosales> adalbas: mchasal: I think you need to propose your branch
<arosales> "To submit your charm for 14.04: bzr push lp:~your-launchpad-username/charms/trusty/your-charms-name/trunk"
<arosales> step 9 on https://jujucharms.com/docs/authors-charm-store#submitting
<beisner> naridergupta, if you sync from lp:charm-helpers, you will indeed pull in a lot of changes.   but that's not what you want.  you want just the nuage changes.
<apuimedo> lazyPower: is it possible to read the config of a relation?
<apuimedo> *of a charm you are related to
<adalbas> arosales, that is what i have: https://code.launchpad.net/~ibmcharmers/charms/trusty/gpfs/trunk
<apuimedo> nevermind, sorry. I think it is quite obvious that it is not :P
<adalbas> arosales, i'm using a group from people that write the charms
<arosales> understood, I am confirming with a new charm you may also need to follow
<arosales> https://jujucharms.com/docs/authors-charm-store#recommended-charms
<mchasal> arosales, thanks, but we were assuming that the team name could stand in for the lp user naem.
<arosales> mchasal: that bit is fine
<adalbas> arosales, ok, so that works a bit different from having it with your own name
<adalbas> i ll look over it
<arosales> adalbas: no weather its a team name or indiv it should be the same
<arosales> lp treats team and folks (in this context) the same.
<mchasal> Right, so what bit is not fine here?
<adalbas> arosales, ok, so that is also needed for individual users
<arosales> adalbas: the main point here is you don't have a target branch to propose against, so you'll need to create an lp bug and attach your GPFS branch to that bug per https://jujucharms.com/docs/authors-charm-store#recommended-charms
<adalbas> got it.
<adalbas> i understood this was a step further after review.
<arosales> adalbas: sorry this could be a bit more clear
<mchasal> Ah, step 1 there. THanks.
 * arosales makes note of that
<adalbas> arosales, no worries!
<arosales> adalbas: now that should get it into the queue.
<adalbas> ok!
<arosales> adalbas: thanks :-)
<adalbas> thank you!
<beisner> ctlaugh, thanks again for the nova-compute arch contribution, looks like the merge proposal is all set for /next/.
<ctlaugh> beisner: Thank you for all of your help!
<beisner> ctlaugh, sure thing, happy to help.
<mchasal> arosales, GPFS charm is there now, thanks for the help!
<arosales> mchasal: good to hear :-)
<arosales> G . P . F . S in the queue :-)
<bdx> charmers: https://ask.openstack.org/en/question/58473/heat-access-created-vm-permission-denied-publickey/
<bdx> jamespage: Can we make a configuration parameter for heat that allows the "instance_user" to be specified?
<bdx> jamespage: I am running into this error https://ask.openstack.org/en/question/58473/heat-access-created-vm-permission-denied-publickey/
<bdx> charmers: Can we get some support for the heat charm?
<bdx> charmers: I am experiencing this issue https://ask.openstack.org/en/question/58473/heat-access-created-vm-permission-denied-publickey/ and would like to use heat in my juju deployed openstack cloud
<bdx> charmers: Unfortunately the aforementoined issue is dissallowing the ubuntu user from sshing into any instance deployed with heat
<bdx> charmers, jamespage: The issue is entirely holding up my deployments, could we get a default of ubuntu user for the heat "instance_user"??
#juju 2015-03-12
<bdx> jamespage, charmers: Could I get an update when this issue is fixed? My email is jbeedy@darkhorse.com. Thank you!!
<ctlaugh> I started a merge proposal review that failed due to not updating a unit test.  I believe it has been fixed now.  I have not gone through this process before -- do I do anything to trigger the merge proposal to test again, or do I cancel it and submit a new one?
<ctlaugh> ^ (I forgot to say this is for the nova-compute charm)
<ctlaugh> ^ Sorry - I just found how to resubmit
<beisner> hi ctlaugh
<beisner> ctlaugh, as long as the MP status is "Needs Review," tests will automatically re-trigger after you push a new commit to the proposed branch.
<ctlaugh> beisner: Oh, sorry -- hopefully I didn't cause too much spam
<beisner> ctlaugh, no worries!  extra testing is better than not enough testing  ;-)
<beisner> ctlaugh, it does look like we have 1 minor lint issue @ http://paste.ubuntu.com/10583581/
<ctlaugh> beisner: I fixed that in my latest revision (http://bazaar.launchpad.net/~clark-laughlin/charms/trusty/nova-compute/arm64-patch-1/revision/110)
<ctlaugh> I see the latest comments about the failure about 15 min ago.  I fixed the lint problem after that -- doesn't look like it's re-run yet (or it hasn't updated the comments yet)
<ctlaugh> Or, I've confused it by resubmitting so many times? :)
<beisner> ctlaugh, yeah the bot checks MPs every 30 min, so it should re-trigger soon.
<Muntaner> good morning charmers
<Muntaner> I've my charm, and I want to connect it to an HAProxy in order to have load balancing. Btw, I don't know how to call the "relation-joined" hooks with the HAProxy. I wrote some of them, but they don't seem to be fired. How can I diagnose this situation?
<Muntaner> may this be a problem of metadata.yawl?
<Muntaner> called them "loadbalancer-relation-x", and my metadata.yawl is the following:
<Muntaner> http://paste.ubuntu.com/10584401/
<Muntaner> and, in general, how can I get the public address of the HAproxy charm? is that available?
<Muntaner> lazyPower, marcoceppi: ping
<jamespage> bdx, please can you log a bug here - https://bugs.launchpad.net/charms/+source/heat  with what you need - we'll review that alongside all the other charm work going on for 15.04 release
<jamespage> bdx, you can of course fix this yourself if you need something right now
<jamespage> bzr branch lp:~openstack-charmers/charms/trusty/heat/next
<jamespage> will get you the current development version
<Muntaner> nobody?
<beisner> hi gnuoy, the nuage nfv project folks are needing to land a c-h change.  with a couple of issues now resolved, i think the MP is ready your review.  https://code.launchpad.net/~nuage-canonical/charm-helpers/charm-helpers/+merge/252644
<Mmike> Hello, guys. Recent amulet update broke amulet - that is, python3-amulet seems to depend on pytho3-path.py which is nowhere to be found
<Mmike> E: Package 'python3-path.py' has no installation candidate
<rbasak> sinzui: a number of people have asked about systemd on Juju, so I'd like to update the bug description with a full explanation of the current status. Could you please review http://pad.ubuntu.com/ehGldKIiT4 as this is how I understand it right now?
<lazyPower> sarnold: ping when you're here, i need your input
<rbasak> sinzui: thank you! Copied to bug 1409639.
<mup> Bug #1409639: juju needs to support systemd for >= vivid <systemd-boot> <juju-core:Fix Committed by ericsnowcurrently> <juju-core (Ubuntu):Triaged> <juju-core (Ubuntu Vivid):Triaged> <https://launchpad.net/bugs/1409639>
<sinzui> rbasak, 1.22.0 vivid ppc64el and arm64 builds are failing. they cannot get gcc-go. Do I need to be patient, or do I need to change package deps
<rbasak> sinzui: could this be http://launchpadlibrarian.net/199658027/juju-core_1.20.14-0ubuntu2_1.20.14-0ubuntu3.diff.gz ?
<rbasak> sinzui: doko uploaded that a few days ago. I was planning to send you an MP when sorting out our next upload.
<sinzui> ouch.  I can make that change rbasak . Thank you for the diff
<rbasak> sinzui: however, this does bump everything to using gccgo 5, from 4.9. You won't have that in older releases.
<sinzui> rbasak, yeah. I hope I can do something like we do for the mongodb/juju-mongodb to keep one packaging branch
<rbasak> sinzui: I'm not sure that's possible for a Build-Depends :-(
<sinzui> rbasak, yeah, sad day for me
<rbasak> Maybe we can ask for a transitional package
<arosales> tvansteenburgh: any ideas on why this test result isn't showing up?
<arosales> from https://code.launchpad.net/~nicopace/charms/trusty/rabbitmq-server/all-tests/+merge/251284
<arosales> http://reports.vapour.ws/charm-tests/charm-bundle-test-11070-results
<tvansteenburgh> arosales: url is wrong, see http://reports.vapour.ws/charm-test-details/charm-bundle-test-11070-results
<tvansteenburgh> marcoceppi: does RevQ make that url, or is it passed to you by jenkins?
<marcoceppi> tvansteenburgh: it's passed by jenkins
<arosales> tvansteenburgh: thanks
<arosales> I updated the bug with that
<rbasak> sinzui: doko says that the libgo5 build dependency is "crap". I'm taking this to mean that it isn't needed.
<tvansteenburgh> arosales: marcoceppi: i just updated the jenkins job with the new url
<sinzui> rbasak, thank you!
<rbasak> sinzui: he's happy for me to add an empty gccgo-go that depends on gccgo to vivid.
<marcoceppi> tvansteenburgh: thanks
<rbasak> sinzui: so if that all works as expected, we shouldn't need to change the build-deps any more.
<sinzui> rbasak, how long does that take for Lp buildsers to see it
<rbasak> sinzui: half an hour + the time it takes to queue/build
<sinzui> rbasak, please :))
<arosales> tvansteenburgh: thanks
<arosales> any folks interested in doing a test review on
<arosales> https://code.launchpad.net/~nicopace/charms/trusty/sugarcrm/all-tests/+merge/251318
<arosales> and https://code.launchpad.net/~nicopace/charms/trusty/gunicorn/all-tests/+merge/251307
<arosales> marcoceppi or charmers can you kick a test off on these ^
<lazyPower> on it
<arosales> lazyPower: thanks
<lazyPower> arosales: gunicorn is missing from revq
<arosales> lazyPower:  hmm it has a valid merge req @ https://code.launchpad.net/~nicopace/charms/trusty/gunicorn/all-tests/+merge/251307
<arosales> lazyPower: does this look ingestion issue or a bit wasn't flipped on the MP?
<lazyPower> arosales: i'm poinging blame @ ingest, MP looks fine
<lazyPower> *pointing
<arosales> lazyPower: ack, thanks
<arosales> marcoceppi, aisrael ^ any ideas
<AskUbuntu_> Landscape is not running after a reboot with juju-core 1.20.x | http://askubuntu.com/q/596004
<aisrael> arosales: I'd also guess it's an ingest issue
<arosales> aisrael: any way we can kick it into the queue, or alternatively kick off a test on this one?
<aisrael> arosales: I'm not sure about adding it to the queue (aside from debugging why it didn't get added in the first place) but maybe tvansteenburgh can kick off the test
<arosales> aisrael: a manual test would be helpful in the near term, long term be nice to see why this didn't ingest
<arosales> #action marcoceppi ^
<aisrael> arosales: ack.
<rbasak> sinzui: uploaded a new gcc-defaults. You should be able to Build-Depend on just gccgo-go soon. But drop the libgo5 build dep.
<sinzui> rbasak, already done and uploaded. I think I'll need to rebuild the two vivids if they get to the builder before your package. Thank you very much
<sinzui> rbasak, I see gcc-defaults arriving in proposed. Will it be copied to release soon? I thought proposed required a 1 week holding period
<Muntaner> marcoceppi: I'm having troubles in understanding how your wordpress loadbalancing works
<rbasak> sinzui: that's only for stable releases. Development -proposed doesn't have a waiting period. As soon as binaries are built and the publisher runs it'll move over, unless there's some kind of regression.
<sinzui> fab, thank you rbasak
<rbasak> sinzui: it's in
<sinzui> thank you rbasak
<sarnold> lazyPower: heya :)
<lazyPower> sarnold: heyo
<lazyPower> sarnold: can i get you in a hangout for say, 15 minutes? Just some quick q/a over something i'm going to sign us up for
<sarnold> lazyPower: sure
<lazyPower> sarnold: shot details over in a pm
<bdx> openstack_charmers, charmers: Is anyone availible to help out with a network config issue??
<bdx> I am noticing unexpected traffic on certain interfaces on my juju deployed openstack.....was wondering if anyone might help me diagnose the issue??
#juju 2015-03-13
<murphyslawbbs> hi there, receiving this error doing landscape install - not sure where to look for the problem: 2015-03-12 16:37:49 [DEBUG] deployer.env:  Delta unit: landscape/0 change:error\n2015-03-12 16:37:49 [ERROR] deployer.env: The following units had errors:\n   unit: landscape/0: machine: 0/lxc/2 agent-state: error details: hook failed: "install"\n2015-03-12 16:37:49 [INFO] deployer.cli: Deployment stopped. run time: 582.60\n', 'status': 1}
<murphyslawbbs> paste: http://paste.ubuntu.com/10588361/
<redelmann> hello!
<redelmann> there any way to transfer files between services when deploy? or a correct way. Ex: pass /static from djano charm to nginx when relation is created!
<redelmann> ??
<Muntaner> good morning to everyone
<Muntaner> marcoceppi: ping
<Muntaner> guys
<Muntaner> in a charm, how can I get the IPs of other units of the same charm?
<cucumber> Hi everyone
<AskUbuntu_> Computers not reporting to landscape | http://askubuntu.com/q/596404
<bdx> jamespage, jcastro: You around?
<bdx> jamespage, jcastro: I've been battling network config issues for a while now with a juju powerd openstack/ceph deployment...I have a few questions regarding network configuration I need to run by either of you....let me know whats up if you come online. Thanks.
<lazyPower> bdx: jamespage is uk based, and jcastro is out today.
<lazyPower> bdx: I suggest emailing the mailing list so they can get back to you during their TZ's - i've seen you drop in and miss them both this week :( I'd like to help but i dont know enough about neutron and the OS networking to be of much use
<bdx> lazyPower: Thanks. Will do.
<bdx> lazyPower: Would you suggest juju@lists.ubuntu.com ?
<lazyPower> bdx: thats the one
<arosales> adalbas: re GPFS and xcat charms
<arosales> https://jujucharms.com/u/ibmcharmers/gpfs/trusty/0
<arosales> https://jujucharms.com/u/ibmcharmers/xcat/trusty/0
#juju 2015-03-14
<my_chiguai> Morning
<my_chiguai> Just curious if there are pointers on setting up secure juju machines
<my_chiguai> like a charm for securing a box
<my_chiguai> fail2ban, etc.
<my_chiguai> ok I see fail2ban
<my_chiguai> https://jujucharms.com/fail2ban/trusty/2
<my_chiguai> Are there other recommended ones?
<lazyPower> my_chiguai: thats the only security related charm that i've produced thus far. Most of the other security related topics are baked into teh charms themselves
<lazyPower> as in apparmor profiles, firewall rulesets, et-al
<lazyPower> my_chiguai: if this is a topic that interests you though - those would be a welcome contribution to the ecosystem :)
<my_chiguai> lazyPower: really I wasn't aware of that!
<my_chiguai> I am new to juju and unfortunately am a time strapped developer hence the desire to use juju
<my_chiguai> I have done some with ansible and getting some deploy books prepped for use on digital ocean
<my_chiguai> and charms don't seem to crazyâ¦
<my_chiguai> one dayâ¦ one dayâ¦
<lazyPower> my_chiguai: not all charms implement the security practices - but there are a few that do. Such as the new wordpress charm thats in dev (apparmor), and our Elastic Search charm (firewall)
<lazyPower> and juju works with Digital Ocean :)
<my_chiguai> learning that myself now. I've spun up a few.
<lazyPower> but its 3am, i'm about to head out. ANy final questions i can answer before I go?
<my_chiguai> Elastic Search is one specifically.
<my_chiguai> You've given me some to look at so much obliged
<my_chiguai> Thank you!
<lazyPower> sure, np
 * lazyPower doffs hat
<lazyPower> Enjoy the adventure
<jaywink> hi, anyone have any ideas why local environment giving this? "juju.provisioner provisioner_task.go:531 cannot start instance for machine after a retry "1": container failed to start and was destroyed:" .. juju 1.22-beta5-utopic-amd64
#juju 2015-03-15
<AskUbuntu_> JUJU Error "ERROR failed to bootstrap environment: waited for 10m0s without being able to connect: " | http://askubuntu.com/q/596929
<AskUbuntu_> Juju bundle deployment and local repository | http://askubuntu.com/q/597038
<AskUbuntu_> Agent-state forever pending or no tools available | http://askubuntu.com/q/597086
#juju 2016-03-14
<marcoceppi> rick_h__: it's been uploaded, but it's a bit...special
<rick_h__> marcoceppi: heh ty
<rick_h__> marcoceppi: yea, saw it in the charmstore
<marcoceppi> rick_h__: reminds me, next month we need to spend a bit more time, but it can be deployed / demoed on AWS. I'll make sure the readme is updated next week
<rick_h__> marcoceppi: cool ty
<rick_h__> marcoceppi: it was enough for me to check out the actions/etc and get an idea for what we did/put things together
<marcoceppi> magicaltrout: I may have gone a bit overboard in my attempt to pull out gitlab omnibus stuff, but I think it makes a pretty compelling architecture
<marcoceppi> magicaltrout: I'll have a pull req on Tuesday, pretty excited about the possibility of running gitlab "better" than their gitlab.com offering ;)
<sam__20> Hi. I'm trying to get started with this https://jujucharms.com/get-started
<sam__20> on a VirtualBoxed Ubuntu 14.04
<sam__20> juju quickstart mediawiki-single stays forever at "juju-gui/0 deployment is pending. machine 1 provisioning is pending."
<sam__20> Any ideas?
<magicaltrout> lol marcoceppi I've merged the PR, I'm very curious to see what you have coming.... :)
<TheMue> morning
<gnuoy> tinwood, got a sec to help me with some git 101 stuff?
<tinwood> Sure gnuoy, ask away.
<gnuoy> tinwood, I've just discovered "git checkout --theirs" which I think solves my issue. But thanks, sorry for the noise
<tinwood> oh.  I've NEVER used that.  What's it solve?
<magicaltrout> gnuoy: dunno if you already use it, but on a similar vein to make sure incoming merges work and stuff, git stash is very useful
<gnuoy> tinwood, my fork is out of sync with upstream but my fork has nothing I want in it so I was refreshing it by merging master from upstream but I had conflicts. I only wanted the upstream copy
<magicaltrout> slightly different usecase I admit
<gnuoy> magicaltrout, I shall hit the man page, thanks
<tinwood> gnuoy, oh.  I did git checkout master, git fetch/merge and then git rebase for the same.
<tinwood> gnuoy, it's so painful I've decided not to fork in the future!
<gnuoy> tinwood, but I need a staging area that mojo and amulet can reference, I don't think the review.o.c mp branch can be that
<tinwood> gnuoy, oh right.  Fair enough.
<BrunoR> how do I get Juju 1.25.4?
<gnuoy> BrunoR, looks like ppa:juju/proposed
<gnuoy> ( https://launchpad.net/~juju/+archive/ubuntu/proposed )
<BrunoR> gnuoy: thx
<BlackDex> Hello there..
<BlackDex> i get the following error: WARNING juju.apiserver.client status.go:677 error fetching public address: public no address
<BlackDex> Or warning actually
<BlackDex> But, deployment seems to be stuck
<beisner> gnuoy, tinwood - juju-deployer just grew a deploy from refspec feature aiui, and we could plumb our bundles/specs to use those instead of branch: lp:foo.
<beisner> ie.  every change/review has a refspec which is an addressable pointer to that change + patchset
<beisner> i do plan to wire that up so that we can optionally run relevant mojo specs against a review with more magic word commands via comment
<tinwood> o/ beisner - not sure I entirely understood that! :) "aiui"?
<beisner> tinwood, as i understand it ;-)  we need to exercise WIP/ change reviews against certain test cases which are already defined in mojo specs.  we just need to rewire the specs to optionally take a 'refspec' so that your proposed charm change can be exercised in the context of that test spec.
<tinwood> ah, I see.  That is useful.
<beisner> for ex:  someone proposes an improvement or fix for something HA or SSL.  our middle-of-the-road default tests may not exercise the thing that we really should.  we would then say something like  charm-recheck-ssl  ... which would then fire off the mojo ssl test specs.
<tinwood> so custom commands as review comments being passed into juju-deployer.  nice.
<beisner> the same thing that gets us that, also scratches the itch for needing to exercise some arbitrary gerrit change in a bundle or spec.
<beisner> everything is prepped and in place to do that today, except our specs.
<beisner> we're already passing the refspec value via env vars to every job.  the specs just need to be fitted to listen for that, and if exists, use it.
<beisner> the goal here is that a contributor or reviewer can simply ask, wait for tests, then be armed with more info for their review.   instead of having to manually stand up an deployment, poke at it, run specs, etc., he/she can move onto something else while that bakes.
<tinwood> I like that.  Obviously, it's bound into the artifact that's being reviewed.  Or are you saying an 'arbitrary' spec?
<beisner> tinwood, right, it takes a review to get a refspec.  so one would have to propose something to take advantage of that.
<beisner> tinwood, it'd also be nice to figure out how to grind off the rough edges of forking for WIPs then rebasing and proposing that as a change.  i think that workflow should exist and be usable.
<beisner> naturally, that's outside the scope of the test automation, but from a developer standpoint, you may not want to propose every bright idea that comes along, yah?  :-)
<tinwood> beisner, I've struggled with it a bit.  To update, I've had to checkout master, pull | fetch/merge, checkout branch, and rebase.  I guess I should also push back my master (as it's been synced with the original fork).
<tinwood> beisner, also I needed to gitreview -s (although I did it manually) on my fork to get the ChangeId into the commit for the review to work.
<beisner> tinwood, can we do a gist based on what you've found so far, and perhaps some of us can use it / tune it, to eventually add that alternative workflow example to our readme?
<tinwood> beisner, sure.  Can do.  I'm currently just sorting out functional_tests in a venv which is interesting :)
<beisner> i think there's value in having a solid example.  even if it has some hoops to jump through, at least it's a reference for what needs to be done if someone wants to wip it.
<tinwood> sure.
<beisner> tinwood, i bet.  that'll also be awesome to have nailed down.
<tinwood> "watch this space" :) --- I hope!
<beisner> tinwood, much appreciated
<beisner> hi gnuoy - is https://review.openstack.org/#/c/292381/ ready for a full test validation, or do you have more work in progress on that one?
<gnuoy> beisner, I'd like to run another test before asking for the full amulet run
<beisner> gnuoy, ok thanks :-)  i'll let you trigger that whenever you're ready.  i was just making a pass through the reviews to see which ones should have that, and yours is on that list. :-)
<beisner> ha.  two smiles even
<gnuoy> kk, ta
<BlackDex> I'm trying to deploy with deployer, but all the machines are currently stating: "Agent-Status": allocating - "Message": Waiting for agent initialization to finish
<cory_fu> BlackDex: What does the [machines] section say?  It sounds like they're failing to provision
<BlackDex> cory_fu: Hmm, i just rebooted the bootstrap node, and now everything seems to be continuing
<BlackDex> that is trange
<cory_fu> Odd
<beisner> cholcombe, icey - full rechecks a-ok on these.  i believe these are the ones we discussed retesting and landing.  can you have a look and confirm?  tia.
<beisner> https://review.openstack.org/#/c/288969/
<beisner> https://review.openstack.org/#/c/286779/
<beisner> https://review.openstack.org/#/c/292194/
<beisner> https://review.openstack.org/#/c/291914/
<beisner> cholcombe, icey - once those have landed, do a charm-recheck-full on https://review.openstack.org/#/c/288177/ and expect it to pass, yah?  :-)
<cholcombe> beisner, the 3rd one isn't me
<icey> https://review.openstack.org/#/c/292194/ is unrelated to our discussion
<cholcombe> but the others look fine
<beisner> cholcombe, ah indeed.  i had issued a recheck on that for a different reason.  but, that'll actually be for you two to review and optionally land now that it's had the full amulet test run. :-)
<cholcombe> :)
<beisner> cholcombe, so we're clear for takeoff on the other 3 from my perspective.
<cholcombe> awesome!
<cholcombe> beisner, land all the things
<stokachu> wallyworld: does the api call to FullStatus only return the status of the default admin model?
<stokachu> even if i switch models and call FullStatus it always return that of the admin model
<stokachu> also this call https://godoc.org/github.com/juju/juju/api#Client.Status only returns minimal status information for current model
<beisner> cholcombe, one thing:  james hadn't reviewed this one, and i'd like to get another os-charmer to code-review it with a +1.  with that, i'll be happy to +2 merge it.  https://review.openstack.org/#/c/291914/1
<cholcombe> beisner, that's fine
<cholcombe> beisner, i'm nowhere near as behind on that one as with the others
<beisner> cholcombe, it doesn't appear to be inter-dependent on the others, is it?
<cholcombe> beisner, nope
<beisner> cholcombe, have the charmhelpers/*  changes from these have all landed in lp:charm-helpers?   (i've not done the stare & compare on that for these reviews)
 * beisner seeks afternoon coffee
<cholcombe> beisner, i believe so but let me double check
<cholcombe> beisner, nope missing one still: https://code.launchpad.net/~xfactor973/charm-helpers/ceph-to-rados-fix/+merge/288559
<cholcombe> lazyPower, want to +1 this? ^^
 * lazyPower looks
<lazyPower> cholcombe - merged at revision 547
<lazyPower> beisner ^
<beisner> thx lazyPower
<beisner> hey lazyPower - on the charmers topic, since i've got the necessary +1s via email, what's next to get added to the charmers LP group?
<lazyPower> beisner - Just a hangout with marcoceppi to get added to the lp group :) Plus the spiel about having the keys to the porche, and dont scratch it
<lazyPower> he'll be back in tomorrow, so lets follow up with him then
<beisner> lazyPower, ack, thanks!
<cholcombe> lazyPower, thx :)
<magicaltrout> marcoceppi: one of our guys says he'll probably send over some cards PR's when he gets bored, not sure what they entail, but if you see anything from breno polanski land, thats who it is
<marcoceppi> magicaltrout: sweet!
<pmatulis> when registering (juju register) a user specifies a password. where is this password used? silly question i know
<beisner> cholcombe, cache tier and rolling upgrade changes merged.  initiated full amulet recheck on rolling upgrades.
<cholcombe> beisner, woo!
<beisner> cholcombe, err uh, rolling upgrades for ceph-mon landed, rechecking rolling upgrades for ceph-osd of course.
<magicaltrout> when you delete your work directory that included a version of juju 2 alpha which you are using in production.........
<magicaltrout> thank god for github
<rick_h__> magicaltrout: ouch
<magicaltrout> hehe
<rick_h__> magicaltrout: trying b2?
<magicaltrout> i just needed to work out roughly when i spun up the bootstrap node and pick a commit ;)
<magicaltrout> rick_h__: my dev box runs trunk i do a nightly sync a rebuild
<magicaltrout> i just have a random prod box running an old alpha cause i needed M4 instances and they weren't in 1.25, so I just went to 2.0 alpha, which works fine, but of course the config files have all changed :)
<magicaltrout> its pretty static though so it doesn't really matter, the boxes it controls just run some mysql nonsense
<rick_h__> magicaltrout: cool
<wallyworld> stokachu: FullStatus should return the correct status for the relevant model. do you have an examle where that's not the case?
<stokachu> wallyworld: https://paste.ubuntu.com/15387713/
<stokachu> so basically I juju switch mydev:staging, then load up my api code
<stokachu> and run a status against it
<stokachu> you can see on line 36 the model name doesn't match the currently selected model
<stokachu> but juju status works as expected
<wallyworld> stokachu: is this the python client?
<stokachu> wallyworld: yea
<stokachu> wallyworld: well mine https://github.com/Ubuntu-Solutions-Engineering/macumba
<stokachu> not python-jujuclient
<wallyworld> ah
<wallyworld> i'd day that client needs work to properly support multi-model (as a guess)
<wallyworld> the current model is stored locally in the ~/.local/share/juju directory
<stokachu> do i have to connect to each model's api server?
<wallyworld> that model uuid would need to be passed with the FullStatus request
<stokachu> or does each model have its own?
<wallyworld> from memory, there's the one api server but the model uuid forms part of the request
<stokachu> wallyworld: so the FullStatus isn't documented on godoc any longer
<stokachu> just Status
<stokachu> and it only takes patterns of some sort
<wallyworld> that i was not aware of. i'll have to dig in and see what's been happening
<wallyworld> off hand, i suspect it's just a matter of passing the correct model uuid along with the request
<stokachu> wallyworld: https://godoc.org/github.com/juju/juju/api#Client.Status
<wallyworld> that's api, not apiserver
<wallyworld> you want to look at the apiserver docs
<stokachu> ah right
<wallyworld> https://godoc.org/github.com/juju/juju/apiserver/client#Client.FullStatus
<stokachu> wallyworld: so the status params just talks about patterns
<stokachu> where is it defined on what parameters can be passed to that endpoint?
<wallyworld> i think the model uuid forms part of the url eg 192.168.1.1/models/<uuid> but i'll need to check
<wallyworld> i'm not sure where that's documented off hand
<wallyworld> i'll find out
<wallyworld> stokachu: so yeah, you form the base of the websocket url by appending /model/<uuid> to the ip address of the controller
<wallyworld> that's how it knows what model it is using
<stokachu> so currently my URL is wss://192.168.1.1/model/<uuid>/api
<stokachu> so i just need to make sure to relogin with the updated uuid
<stokachu> when i want to 'switch' models effectively
<wallyworld> stokachu: yes, correct
<wallyworld> that's what the juju cli does
<stokachu> wallyworld: ok cool, thanks for clearing that up
<wallyworld> np
<stokachu> ive just been using the 'controller' uuid
<wallyworld> lwt me know if you have any other issues
<stokachu> which is essentially the admin model
<wallyworld> yep
<wallyworld> the controller uuid and admin model share a uuid at the moment
<wallyworld> probably forever
<stokachu> yea once those name changes come into effect it'll be much clearer
<wallyworld> stokachu: hopefully beta3 this week will have the latest multi-model goodness with a default admin model and a host model the user can name on bootstrap
<stokachu> wallyworld: ok cool man
<stokachu> wallyworld: cool just tested making sure to relogin to the new model uuid and it works as expected
<wallyworld> stokachu: great, it works?
<stokachu> wallyworld: yea works great now
<wallyworld> awesome
<naye> hello
<naye> hola
#juju 2016-03-15
<sam__344> Hi. I asked this last night but maybe everyone was asleep
<sam__344> Is there a trick to running "juju quickstart mediawiki-single"
<sam__344> under virtualbox using Ubuntu 14.04..
<sam__344> Both the computer and the virtualized computer are Ubuntu 14.04
<sam__344> It just hangs on machine 1 provisioning is pending
<BlackDex> sam__344: Did you start the second box? Is it running via maas? etc..
<sam__344> BlackDex: I did nothing but follow the instructions here, up to step #2. https://jujucharms.com/get-started
<sam__344> I'm running it inside virtual box, not deploying to virtualbox
<BlackDex> Ah, so the machine you need to deploy it to is bare-metal
<sam__344> Well I'm just playing with it for fun. But I don't want it to mess up my laptop so I'm using VirtualBox. I'd expect it to just work the same as if I was following the directions directly on my laptop
<BlackDex> sure
<BlackDex> if you just select the create a local environment
<BlackDex> You need to have JuJu know where to deploy stuff to. That may be virtual, lxc, bare-metal, cloud etc..
<sam__344> okay. So what should I type instead of "juju quickstart mediawiki-single"
<sam__344> By the way BlackDex - I just rebooted the virtual machine and tried it again. Got  INFO jujuclient:328 Juju upgrade in progress...
<sam__344> over and over again
<sam__344> until finally "juju-quickstart: error: cannot retrieve the environment type: upgrade in progress - Juju functionality is limited"
<BlackDex> hmm
<BlackDex> that is strange
<BlackDex> never did a local deploy btw
<BlackDex> Hello there, on my setup juju seems to timeout after a while. The bootstrap node is running on a KVM-Instance and can connect to MAAS etc.. the deployed nodes are also receiving commands from juju, but after a while it seems to stop
<BlackDex> if i then reboot the bootstrape node, some of those machines come to life without doing anything.
<BlackDex> Is this a problem with the juju-api or mongodb? what can i do to try and solve this?
<shruthima> Hi, We are developing IBM HTTP Server as subordinate charm we want to test the charm with ubuntu-devenv .((http server is a webserver which can be used by other  ibm products Eg: WAS .we are developing it as a layer and decide to use http interface which is present in interfaces.juju.solutions.)) so could you please include http interface in ubuntu-devenv metadata.yaml file under provides...//?
<marcoceppi> shruthima: what is ubuntu-devenv? Do you have a link to it somewhere?
<shruthima> this is the link  https://jujucharms.com/u/kwmonroe/ubuntu-devenv/trusty/5/
<icey> any chance of get ting https://code.launchpad.net/~chris.macnaughton/charm-helpers/pids-can-be-a-list/+merge/288014 reviewed soon?
<beisner> icey, i'll review/comment
<icey> thanks beisner :)
<cory_fu> shruthima: I'm not sure that ubuntu-devenv makes sense to support the http interface, as it provides a developer environment and not anything related to HTTP or web services.  Maybe it would make more sense to test the IBM HTTP server with the existing haproxy charm?
<cory_fu> https://jujucharms.com/haproxy/
<shruthima> ok will explore on how i can use haproxy charm to test http server . if any queries il get back . Thank you :)
<beisner> coreycb, thx for the swift-* reviews.  with your +1 and the full test pass, i think we're clear to land those, yah?
<coreycb> beisner, yes I think so
<coreycb> beisner, I've also tested with jamespages nova-cc patch successfully but that should probably have a more active charmer review it
<beisner> coreycb, yep thedac is queued up on the n-c-c review.
<coreycb> cool
<beisner> icey, remind me, which charm test were you updating to take that list validation?
<icey> a ceph-mon test
<icey> looking...
<icey> beisner: https://review.openstack.org/#/c/287446/7/tests/basic_deployment.py
<icey> line 185, changed from {'ceph-osd': 2} to {'ceph-osd': True}
<icey> would rather be: {'ceph-osd': [2, 3]}
<beisner> icey, thx. see review comment.
<icey> beisner: saw it, thanks
<beisner> icey, i'd be +1 to rename to just e_pids in that whole method
<beisner> as it's also a funky name for the existing bool scenario
<beisner> icey, or just "expected"
<narindergupta> jujucharms.com is down
<urulama_> narindergupta: seems a company network issue, we're looking into it
<urulama_> narindergupta: thanks
<narindergupta> urulama: thanks
<magicaltrout> this is why juju needs multicloud models, so you can fail over outside of the core network ;)
<rick_h__> magicaltrout: :)
<urulama> :D
<jcastro> jamespage: do you have the bundle you used openstack on your laptop in brussels pushed somewhere?
<jcastro> I'm ready to melt my PC
<lazyPower> yessssss
<marcoceppi> jcastro: I think jamespage is on vacay
<lazyPower> marcoceppi - do we know if 1.25.x is capable of using the devel channel in the store or is that a 2.0+ only feature?
<marcoceppi> lazyPower: no idea, urulama ^?
<urulama> lazyPower: 2.0 only
<lazyPower> ack, ta
<gnuoy> tinwood, novaclient.v1_1.client fix landed
<tinwood> great stuff.  Thanks gnuoy!
<gnuoy> np
<dames> beisner: you said jamespage's nova-cc PR has already passed full amulet tests? Or I need to just aprove the workflow bit?
<beisner> thedac, re: https://review.openstack.org/#/c/291721/   Yep, if you're not seeing it, hit the Toggle CI button to expand the history a bit.
<beisner> thedac, my only hold-back was the self-comment on https://review.openstack.org/#/c/291721/1/hooks/nova_cc_hooks.py
<thedac> ok
<lazyPower> jcastro - bite sized PR if you have a moment to TAL - https://github.com/juju-solutions/bundle-logstash-core/pull/1
<jcastro> +    juju deploy ~containers/bundle/logstash-core
<jcastro> is that right? wouldn't it not be in the containers namespace?
<lazyPower> thats what works today
<lazyPower> when is promulgated, either/or
<lazyPower> wait, i just committed an act of heresy, i just reference a bundle as "promulgated"
<beisner> thedac, fyi it'll take a code-review +2 along with that workflow +1 to trigger the merge.  lmk if you don't have privs for the +2.
<jcastro> it just seems that you would document where it will be at with a clean namespace
<lazyPower> if it doesn't work in a copy/pasteable format, i'm hesitant to plug it in there ya know?
<jcastro> who is going to remember ~containers/logstash-core?
<jcastro> I just want to remember logstash-core
<thedac> beisner: I do. I am going to respond back to jamespage about the liberty-> mitaka upgrade path.
<lazyPower> also jcastro - should i rename it ot elastic-stack?
<beisner> thedac, ok cool, thx
<lazyPower> or elk-stack?
<jcastro> yeah
<jcastro> elk-stack
<lazyPower> ok, will rename the repository after PR feedback, already updating the README
<jcastro> looking at the bundle, one charm is in ~containers, one's in the promulgated store, and the jdk is in kwmonroe's personal namespace
<jcastro> nod, don't block on me
<jcastro> I'm just saying we should be pushing for bundles using reviewed charms, not that I don't trusty kev, heh
<kwmonroe> :)
<lazyPower> its in the revq ;)
<lazyPower> currently at what? #7?
<kwmonroe> lazyPower: 'zulu8' is a drop-in layered promulgated openjdk replacement if you'd rather use that.
<jcastro> heh, he just went from reviewing a readme diff to "retest the whole thing with a new java layer"
<lazyPower> jcastro - this is all pretext work to propose for ~charmer, things have to work when you submit for review or we tend to nack them. charms are never done after all ;)
<lazyPower> kwmonroe - you're not helping me by adding work
<lazyPower> <3
<kwmonroe> lolz.
<lazyPower> but thats easily done
<lazyPower> actually, kwmonroe - want me to kick the tires on testing that?
<kwmonroe> testing what?  java is java.  just use it: https://jujucharms.com/zulu8/
<kwmonroe> AMIRITE MATT?!?!
<lazyPower> the one day java was set up for a slam dunk, and matt is in Hawaii
<kwmonroe> no doubt
 * lazyPower grins at the irony
<magicaltrout> i read ironing
<magicaltrout> which was a little odd
<lazyPower> indeed
<thedac> gnuoy: I am thinking the keystone case issue, a compromise would be not to create as lowercase but in the checks. read only. I see that keystone/hooks/manager.py may be partialy at fault.
<gnuoy> thedac, sorry, you're suggesting we create case sensitive but read case-insensitive ?
<thedac> gnuoy: yes, one sec
<thedac> gnuoy: something like http://pastebin.ubuntu.com/15393100/
<gnuoy> thedac, that makes sense to me
<thedac> gnuoy: ok, I'll submit a pull request
<gnuoy> kk
<cholcombe> beisner, looks like the tests on the ceph-osd charm were deploying the wrong services
<stokachu> when you destroy-model the model still shows up in list-models but as 'no longer alive'
<stokachu> is this expected?
<cholcombe> beisner, it was deploying ceph and not ceph-mon
<beisner> cholcombe, indeed.  the test in ceph-osd deploys the ceph charm.  https://github.com/openstack/charm-ceph-osd/blob/master/tests/basic_deployment.py#L47
<stokachu> nm found the bug
<cholcombe> beisner, yeah i changed it to ceph-mon which should fix the problem
<beisner> cholcombe, ok.  be aware, that marks the beginning of the end of ceph+ceph-osd functional integration.   i'd suggest that we add ceph-osd to the ceph charm's amulet test @ https://github.com/openstack/charm-ceph/blob/master/tests/basic_deployment.py#L47 right along with these changes so we don't completely lose coverage.
<cholcombe> beisner, yeah goo dpoint
<cholcombe> beisner, yeah i'll cut a branch for that integration
<beisner> cholcombe, sweet, thanks
<thedac> gnuoy: fyi: https://review.openstack.org/293043
<jcastro> marcoceppi: https://bugs.launchpad.net/juju-core/+bug/1557633
<mup> Bug #1557633: status has duplicate entries for relationships <juju-core:New> <https://launchpad.net/bugs/1557633>
<jcastro> look at how huge that list ended up being
<thedac> marcoceppi: nuage charms:
<thedac> https://jujucharms.com/nuage-vsc/trusty/
<thedac> https://jujucharms.com/nuage-vsd/trusty/
<thedac> https://jujucharms.com/nuage-vrs/trusty/
<thedac> https://jujucharms.com/nuage-vrsg/trusty/
<gnuoy> tinwood, +2'd your keystone change. Thanks for all your work on that
<tinwood> gnuoy, sadly OSCI doesn't agree!  (I'm guessing keystone auth problems).
<beisner> tinwood, gnuoy - hook failed: "install" for trusty and wily on that keystone change, inspecting unit logs now..
<tinwood> thanks beisner
<beisner> tinwood, gnuoy 2016-03-15 17:09:55 INFO install ImportError: cannot import name get_admin_domain_id
<tinwood> beisner, oo, nasty - that must be me.
<beisner> tinwood, gnuoy - http://pastebin.ubuntu.com/15393468/
<beisner> gnuoy, gotta wait for both "Jenkins" and "Canonical CI" to +1
<beisner> looks like patchset 3 is the culprit
<tinwood> I will check and get back to you both.  My box is broken (until I can get an install of amulet working).
<tinwood> yeah, definitely me with merge conflicts.  However, there's no test for get_admin_domain_id() - i.e. it passes unit tests.  I'll dig into that too.
<cholcombe> beisner, where does amulet get ceph-mon from?
<cholcombe> beisner, i realize this is a vague question haha.  What i'm wondering is which version of ceph-mon is it using.  There's a few different ceph-mon's under different namespaces
<beisner> cholcombe, if it's in other_services, launchpad.   if it's the ceph-mon charm test itself, it gets it from wherever the change originated (refspec)
<cholcombe> beisner, yeah it's in other_services
<beisner> cholcombe, it should be pulling from ceph-mon/next
<cholcombe> beisner, ok that's what i was wondering.  I'm failing to deploy on precise and I'm wondering if it exists
<beisner> cholcombe, it uses the trusty charm for everything currently (precise through xenial)
<cholcombe> beisner, hmm ok
<cholcombe> i must've broken something then
<bdx> whats up everyone? I'm trying to bootstrap lxd provider using juju2, does anyone know where I can find an example of a config.yaml to feed juju2?
<icey> bdx `juju bootstrap lxd lxd --upload-tools --config="default-series=trusty"` is what I've been doing
<icey> anybody have suggestions for subordinate charms being a mix of layered and old-school charms?
<bdx> icey: thanks
<marcoceppi> thedac: thanks
<marcoceppi> thedac: these are already promulgated though?
<thedac> marcoceppi: I suspected that. jamespage promulgated them last week. Again I am trying to get straight the review process for future changes to those charms.
<marcoceppi> thedac: yes, so that's not 100% clear, I'll look into it to find out exactly how they were uploaded, etc
<thedac> Sounds like http://review.juju.solutions/ will be (but is not yet) the correct location for nuage (or anyone else) to submit change proumulgation requests. Is that correct?
<thedac> marcoceppi: ok, thanks. We could surely use some documentation on this. That or I have not had enough coffee today.
<marcoceppi> thedac: documentation definitely, we're locking down a new reviewqueue with the new charm command due out this month (charm command)
<marcoceppi> thedac: but basically yes, nuage, or whomever, would upload charms to their development channel - since those charms are promulgated, they'll have to got through a review to get them published to the stable channel
<marcoceppi> but development will be done wherever the code for the charm lives, where previously anyone could contribute by just opening a merge requests against an lp branch
<marcoceppi> so if they house the code for teh charms in gerrit, or github, or lp, that's where people will contribute to, and it's up to them to do uploading/submitting to the store
<thedac> ok
<tinwood> yay! amulet reinstalls under xenial :)
<cory_fu> rick_h__: Hey.  Has anyone suggested adding a message param to `charm publish` so that we can indicate just what is included in the new rev?
<urulama> cory_fu: yes, that part is still missing
<rick_h__> cory_fu: yes, it's supposed to be updated to take one like a 'commit message'
<cory_fu> Ok, cool, so it's already planned.  Nice
<cory_fu> I'm finding that the lack of info about the charm revs is making my development process more difficult because I can't recall what I've released when
<beisner> tinwood, just to confirm, we need to tackle keystone @ master as a crit.  she's bust.
<beisner> tinwood, ie.  with keystone install hook failing, all other amulet tests for other peeps will also be blocked.
<beisner> tinwood, two paths forward:  post a change to fix it, or post a change to revert that last one.  whaddaya think?
<tinwood> beisner, I've sorted it out.  I'm just finishing the merge and will push again.
<beisner> tinwood, awesome
<bdx> charmers, core, dev: I see spaces can be assigned like so -> juju deploy mysql --bind "server=database cluster=internal"
<bdx> charmers, core, dev: does this indicate that I should have an affinity between subnets and spaces?
<bdx> charmers, core, dev: if my space-0 has multiple subnets e.g http://paste.ubuntu.com/15393950/
<bdx> charmers, core, dev: how can I `bind` a specific subnet in a space? .... Is this a thing yet?
<tinwood> beisner, it seems that my review is closed.  Do I need to branch again and push a new review?
<lazyPower> bdx - I would redirect that at the list. The primary author of the spaces feature is in EU time, and is the most well equipped to answer those questions
<bdx> lazyPower: totally, thanks
<tinwood> beisner, or do I hit the revert button?
<beisner> tinwood-dinner, since that change was merged, it'll have to be a separate proposal
<tinwood-dinner> Okay, will do. Just finishing eating.
<beisner> me too
<tinwood> beisner, I'm just running some tests to make sure it is all still okay.  Be about 5-10 minutes for the review to pop up (I hope!)
<beisner> tinwood, excellent, thank you
<cory_fu> bcsaller: I went ahead and added the --show-report option to charm-build: https://github.com/juju/charm-tools/pull/135
<bcsaller> cory_fu: utils.delta_signatures wasn't helpful there? (thanks btw :)
<cory_fu> ...
<cory_fu> It probably would have been
<bcsaller> the validate method above this commit is similar, but not the same
<cory_fu> bcsaller: Ah, yeah.  delta_sigs checks if the files on disk don't match the manifest, but by the time the files on disk are updated, the manifest has been overwritten as well.  I guess I could call report before write_signatures
<cory_fu> I could do the same with clean_removed.  Hrm
<pmatulis> should this "just work"? i get 'ERROR cmd supercommand.go:448 no registered provider for "lxd"' : 'juju bootstrap mycontroller lxd'
<tinwood> beisner, it's gone up and failed it's CI?  It failed very quickly, so I'm wondering if that's because it's blocked?
<beisner> tinwood, fail fast ;-)  ...
 * beisner looks
<marcoceppi> tinwood: yeah, sorry about that, amulet is fixed again though
<marcoceppi> pmatulis: what version of Ubuntu?
<tinwood> beisner, hey, no that's fine.  This is, after all, of my doing sadly.
<pmatulis> marcoceppi: 2.0-beta2-0ubuntu1~16.04.1~juju1
<pmatulis> sorry, Xenial
<marcoceppi> pmatulis: when do you get that error? is there a bunch of text first or is it almost immediately, if it's the former --upload-tools is needed for now, otherwise that's another issue
<pmatulis> marcoceppi: oh yeah, it runs for a good while
<pmatulis> marcoceppi: lemme try --upload-tools . why do i need that again? b/c it tries to use a trusty container?
<beisner> tinwood, unit test really did fail on that
<marcoceppi> pmatulis: because the trusty agent doesn't have lxd provider compiled in
<tinwood> beisner, hmm, strange, everything passed on my bastion.  what was the problem?
<pmatulis> marcoceppi: roger. trying now...
<beisner> tinwood, see priv channel for priv link
<icey> beisner: any chance on more review on https://code.launchpad.net/~chris.macnaughton/charm-helpers/pids-can-be-a-list/+merge/288014 ?
<pmatulis> marcoceppi: thank you - works
<beisner> icey, on a hot issue atm, will circle back
<cory_fu> bcsaller: Actually, I can't use delta_signatures for clean_removed after all, because the whole point is that they don't get removed, so d_s won't pick them up.  :/
<icey> no worries beisner
<bcsaller> cory_fu: :-/
<bcsaller> heh
<lazyPower> jcastro - how much ram do you ahve in your rig? and what did resource usage look like  with openstack in lxd on your lappy?
<cory_fu> bcsaller: PR updated
<cory_fu> Also, lazyPower and marcoceppi, since you both commented
<cory_fu> marcoceppi: Your :BOAT: didn't sail.  ;)
<roryschramm> is it possible to specify a custom apt repository when juju deploys an app to an lxc container? ie the lxc container will use http://myrepo/ubuntu in /etc/apt/sources.list
<stub> roryschramm: Not globally. Each charm needs to add its required custom repositories. Charms that need custom repositories generally provide a config item for them (or hard code them).
<stub> roryschramm: You might also find the apt_ environment settings in your juju environment can help (eg. juju set-env apt-mirror=...)
<roryschramm> aha the apt-mirror setting is what i was looking for
<roryschramm> thanks
<roryschramm> will that override the default repos in the trusty lxc image?
#juju 2016-03-16
<axino> hi
<axino> has anyone ever tested a reactive charm on xenial ?
<jacekn> and I would like to remind you about my collectd subordinate: https://bugs.launchpad.net/charms/+bug/1538573 review :)
<mup> Bug #1538573: New collectd subordinate charm <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1538573>
<fstyrell> I just found the Juju is a great tool.
<magicaltrout> fstyrell: you're late! ;)
<fstyrell> haha,ð
<magicaltrout> jacekn: http://review.juju.solutions/ you're not in the review queue
<fstyrell> I am thinking play Juju with ansible.
<magicaltrout> ah cool, well lazyPower was the guy that gave the talk about juju & ansible in Belgium this year
<magicaltrout> when he wakes up you should prod him about it :)
<fstyrell> oh, thanks. Can i find the talk video at youtube ?
<magicaltrout> erm
<magicaltrout> should be able to
<fstyrell> found it.ð
<magicaltrout> https://www.youtube.com/watch?v=0eymk93lY8k
<magicaltrout> quicker than me :P
<fstyrell> thanks, you are very nice.
<magicaltrout> I'm not, i'm just bored :P
<jacekn> magicaltrout: so what do I need to do to be there? I was told in the past that setting my bug to "fix commited" was good enough
<magicaltrout> jacekn: thats the $1m question, I don't know that either :)
<jacekn> magicaltrout: I've been trying to get that charm merged since January....
<marcoceppi> axino: it should work, what's the problem?
<stub> marcoceppi: axino's problem is his charm is attempting to pull in charmhelpers from pypi, which isn't going to work in his environment.
<stub> marcoceppi: I think the problem is he specified to use a venv and not fall back to system packages in his layer options, but I'm not sure.
<stub> marcoceppi: sorry, not charmhelpers. setuptools.
<stub> 2016-03-16 07:52:42 INFO install Installing setuptools, pkg_resources, _markerlib, pip, wheel...
<stub> 2016-03-16 07:52:42 INFO install   Complete output from command /var/lib/juju/agents...-0/.venv/bin/python3 - setuptools pkg_resources _markerlib pip wheel:
<stub> 2016-03-16 07:52:42 INFO install   Collecting setuptools
<stub> And then it explodes, because it can't collect setuptools
<marcoceppi> axino: stub: yeah looks you'll want to use both venv and system-packages options in the layer.yaml cory_fu ^^
<dosaboy> gnuoy: qq on https://code.launchpad.net/~gnuoy/charm-helpers/keystone_authtoken/+merge/289042
<jcastro> lazyPower: 16gb of RAM, usage seems fine, it's IO that gets wailed on
<jcastro> lazyPower: I'll fire up the bundle again next daily and you can observe
<BrunoR> "import amulet" yields an "ImportError: No module named 'path'" in python3 for amulet 1.13.0-0ubuntu1~ubuntu15.10.1~ppa1 ~ is this a missing dependency?
<tvansteenburgh> marcoceppi: ^
<marcoceppi> BrunoR: it's being worked on
<BrunoR> marcoceppi: can you give me a work-around or an estimate how long this will take?
<magicaltrout> \_____________________o_________________/
<rick_h__> best answer ever?
<magicaltrout> hehe
<magicaltrout> rick_h__: marcoceppi someone who knows me and jacekn want to know how you get stuff that has been reviewed and rejected back into the review queue
<marcoceppi> BrunoR: 2 hours, pip install amulet into an activated python virtualenv for now
<marcoceppi> magicaltrout: move the bug to new or fix committed
<magicaltrout> fair enough
<magicaltrout> jacekn: dunno then, you're just in limbo somewhere :)
<marcoceppi> magicaltrout: this/next month new review queue where this will be streamlined
<marcoceppi> jacekn: ^^
<magicaltrout> cool, *finally* got Saiku 3.8 cut
<magicaltrout> so i *am* going to get this fscking charm finished :P
<lazyPower> magicaltrout schenanigans ;)
<jacekn> marcoceppi: yes I'm aware of that. Are you saying I just have to wait and there is no way around it?
<magicaltrout> jacekn: can you set the bug to new?
<jacekn> marcoceppi: (I've been trhing to get this charm into the charmstore since Jan)
<magicaltrout> might trigger the regrepping of the issue and pick it back up
<jacekn> done
<jacekn> marcoceppi: magicaltrout: there is also another thing that is problematic - because charmstore submissions can take months and we have to keep working I had to "freeze" that layer for submissions and I work on it's fork. That fork is moving furgher and further away from what you are reviewing
<marcoceppi> jacekn: again, these are all growing pains as we wait for teh new charm upload command and review queue
<marcoceppi> that goes away come the new charmstore
<marcoceppi> jacekn: I found the issue with teh review queue, give me a min to address
<jacekn> marcoceppi: ok, I thoujgh there was also resources problem but if it's just the queu itself it's easy to solve
<marcoceppi> jacekn: trhe problem is the review queue is tied to the old charm store method of "everything in lp" going forward, you'll just submit a charmsto0re url, like cs:~jacekn/collectd-10 for review and you can continue to dev/rev, the review queue will be quicker to pick things up, quicker to test, and quicker to land fixes while also adding a lot of observability to you and charmers
<marcoceppi> to do this we're decoupling from the lp, like the charmstore is currently, but until the new charm command lands (hopefully this week) we can't really switch over or finish the new review queue
<marcoceppi> so we're in a weird transition state
<cory_fu> axino, stub, marcoceppi: Sorry I'm late to the conversation, but does your charm layer have its own wheelhouse.txt?  Also, did you do the initial charm-build on a xenial box?  That error looks somewhat similar to https://github.com/juju/charm-tools/issues/117 though not exactly the same.
<marcoceppi> jacekn magicaltrout I've just kicked the reviewqueue with a large boot, in the next few hours it should be up-to-date (after it finishes crawliing lp)
<marcoceppi> jacekn: in the meantime, I'll take a look and review your charm now!
<magicaltrout> ta
<jacekn> thanks!
<marcoceppi> jacekn: I've just kciked off a test against AWS, pending that coming back pass it LGTM
<jacekn> marcoceppi: great! thanks!
<marcoceppi> tvansteenburgh: something just crossed my mind, bundletester isn't really packaged anywhere and now is the best time to deprecate charm test for bundletester
<tvansteenburgh> marcoceppi: okay. what would you like me to do?
<marcoceppi> tvansteenburgh: does that sound like a good idea?
<marcoceppi> or should we just package bundle tester seperate?
<tvansteenburgh> marcoceppi: separate from what?
<marcoceppi> charm-tools
<tvansteenburgh> yes
<tvansteenburgh> marcoceppi: package separate, then we can change the impl of `charm test` to call bundletester, or charmbox, or whatever
<marcoceppi> ah, yeah, true
<beisner> hi marcoceppi, tvansteenburgh - os-charms aren't clear yet to break from juju test (need to be able to preserve enviro variables a la `juju test -p`)  if i'm mistaken on that, thump me on the noggin.
<lazyPower> +1 to that
<marcoceppi> beisner: well, adding preserve env variables is easy enough, but I'll keep that in mind
<beisner> marcoceppi, tyvm.  for ref:  https://github.com/juju-solutions/bundletester/issues/17
<tvansteenburgh> beisner, marcoceppi: bundletester already preserves all envvars by default
<beisner> tvansteenburgh, sweet.  thank you for confirming.
<jcastro> hey bdx, I'm going to mail the fiche author and let him know the charm has been promulgated
<jcastro> I figured it'd be cool to let him know
<marcoceppi> rick_h__: urulama the charm push command doesn't upload dot files?
<rick_h__> marcoceppi: nope, due to size/etc it's not a replacement for git clone
<marcoceppi> rick_h__: wtf, .build.manifest is not a version control file
<marcoceppi> you can't blanket assume any dot file or directory is for vcs
<marcoceppi> rick_h__ urulama I can apprecaite a whitelist of thigns like .git, .bzr, .gitignore, but there are files in charms that are dot files that are needed for operationa nd we're stripping them out.
 * marcoceppi opens bug
<magicaltrout> you need .charmignore! ;)
<lazyPower> you gest, but i think thats a great idea ;D
<lazyPower> s/gest/jest/
<jrwren> hidden files look to have been excluded since 2011: https://github.com/juju/charm/commit/ddf98e0f66ebad7ccb9c41d409b64c1febbd4cf3#diff-59640b4e3d1c61f83bdd75d573589453R154
<marcoceppi> jacekn: what. this is stupid, it only hides on the top level
<magicaltrout> don't abuse the wrong person :P
<rick_h__> marcoceppi: fair enough, please open a bug. This is good feedback from testing things out
<marcoceppi> jrwren: **
<marcoceppi> rick_h__: bug opened, I'll open one against charm as well
<rick_h__> marcoceppi: appreciate it
<jrwren> i agree. it is stupid.
<marcoceppi> <3 didn't realize how long that's been a thing
<jrwren> I also agree, a .charmignore would be nice.
<lazyPower> marcoceppi - sounds great, but the base layer is GPL-3'd as well :-\
<marcoceppi> lazyPower: sure, we should change that cory_fu ^
<lazyPower> https://github.com/juju-solutions/layer-basic/issues/47
<lazyPower> i bug'd it
<cory_fu> o_O  I've been making all of my layers Apache licensed.  I had no idea that basic was GPL.
<lazyPower> thats what i considered then i saw the base layer was GPL'd, soooo
<lazyPower> i figured i had to follow suit
<cory_fu> bcsaller: I think you chose the original license for the basic layer.  Any reason you chose GPL?
<bcsaller> cory_fu: no, we can issue it under a new license at any time
<cory_fu> lazyPower: I'm not seeing the comment that was the original context for you noting that the basic layer is GPL
<lazyPower> cory_fu - ah thread origin started in the logstash layer - https://github.com/juju-solutions/layer-logstash/pull/11
<cory_fu> So I certainly have no objections to changing the license, and I'm sure none of the other committers or members of juju-solutions would object, but is there a formal process we need to follow?
<magicaltrout> technically afaik you need written consent from the copyright holders
<cory_fu> magicaltrout: The copyright is assigned to Canonical
<cory_fu> Would a PR from a Canonical employee count as written consent?  :p
<lazyPower> i vote ben saying we can at any time on IRC as the word of good
<bcsaller> the only commiters I see are canonical as well
<cory_fu> Yeah
<magicaltrout> depends who commits I guess if its canonical, who cares
<magicaltrout> you guys have no ICLA in place for outside commits
<magicaltrout> not that I think you'll get into issues, but there's no formal joint copyright holding or migration of ownership
<magicaltrout> but IANAL, so just going from past experience
<bcsaller> I'd rather err of the side of too permissive than make a choice that made people feel unable to use this code
<magicaltrout> cory_fu: for example I remember when PDI swapped from GPL to ASL, and they had to find every committer and get them to sign off on the license change as there was no CLA just adhoc contributions from the outside world :)
<magicaltrout> we did the same with Saiku and now have a CLA for committers to sign
<magicaltrout> and obviously in Apache land we all have to sign a CLA before committing anything
<matt_dupre> Hi!  I was wondering if anyone knew roughly when OpenStack charms for Mitaka on Xenial will be available (pre-releases / testing are fine)?
<matt_dupre> I see there are some mentions in the store: https://jujucharms.com/q/openstack?series=xenial, but 0 deploys on most of them still
<cholcombe> anyone know how to mock os.lstat?  I'm trying to instantiate posix.stat_result manually and it's trickier than i thought
<cholcombe> nvm i just figured it out.  posix.stat_result wants a list not a dict
<marcoceppi> matt_dupre: beisner or coreycb might be able to help. We've been deploying them on Xenial for a bit, and I think that the last charm release in January helped carve out Mitaka support
<beisner> hi matt_dupre - the "next" charms track the development version of the charms (beware, they have a lot of movement currently).  https://jujucharms.com/u/openstack-charmers-next/
<beisner> wolsen, can you have a cruise through these?:
<beisner> https://review.openstack.org/#/c/293616/
<beisner> https://review.openstack.org/#/c/293608/
<beisner> https://review.openstack.org/#/c/293625/
<wolsen> beisner, sure
<beisner> wolsen, ta
<wolsen> beisner, np
<fritchie> Hi all, if 'juju status' just hangs how can the issue be diagnosed?
<beisner> hi fritchie - i'm out shortly, but i'd do `juju status --debug` to get more info about where it's hanging.
<marcoceppi> fritchie: yup --debug is a good start. Also, out of curiosity, what is the environment you're using and juju version?
<lazyPower> cory_fu - didn't you write a layer for templating to break that out of CH?
<cory_fu> lazyPower: I did: https://github.com/juju-solutions/charms.templating.jinja2
<lazyPower> i just found it, gracias
<cory_fu> lazyPower: The main reason I did that was because I needed to add the ability to provide custom filters & tests, and didn't want to keep CH alive
<lazyPower> I completely respect this decision
<lazyPower> so, i need to add this to my layers wheelhouse.txt correct?
<lazyPower> charms.templating.jinja2>=0.0.1<=1.0.0
<cory_fu> Yes, though I started it at 1.0.0
<lazyPower> o, even better
<fritchie> marcoceppi, juju and maas on same node
<fritchie> for version, I am reinstalling now :-)
<marcoceppi> fritchie: does maas show the bootstrap node as still running?
<fritchie> right now 5 hp dl380s, 2 nics each, 2nd nic being used for dhcp, no external router
<lazyPower> cory_fu I just added that ot my wheelhouse, re-built, and upgrade-charm'd, however i get this during baselayer updating from the wheelhouse - https://gist.github.com/chuckbutler/5b7a70a8a2e944cfa31b
<cory_fu> I could swear that was fixed
<cory_fu> lazyPower: That was fixed in 1.0.1, 20 days ago: https://github.com/juju-solutions/charms.templating.jinja2/commit/9df7ef886ec6e3f570f103422c0804501ca56d31
<cory_fu> Did your charm-build pick up 1.0.1 or 1.0.0?
<cholcombe> beisner, my test failure on 287500 is quite odd.  the unit test works locally but fails when i upload it
<lazyPower> cory_fu 1.0.0
<lazyPower> let me try again, and see if it pulls in 1.0.1
<magicaltrout> here's a question for you marcoceppi et al https://jujucharms.com/q/?text=pentaho
<cory_fu> lazyPower: Yeah, pypi definitely has 1.0.1
<beisner> cholcombe, looks like dev_name != 'sda'  re:  http://logs.openstack.org/00/287500/4/check/gate-charm-ceph-osd-python27/ae7b39a/console.html#_2016-03-16_19_15_09_758
<magicaltrout> how does the charm store come to its conclusion, for example, i write a charm, its not recommended but there is nothing else pentaho related in the store
<cholcombe> beisner, yeah i saw that.  the odd thing is that works fine on my local box
<cholcombe> i patched python's open function
<marcoceppi> magicaltrout: you should talk to rick_h__ about this one. I can't explain the searching results stuff, but I know that it's something our web team is looking into.
<magicaltrout> how come i get 54(!) recommended charms
<magicaltrout> fair enough
<cholcombe> beisner, maybe marcoceppi is there a better way to patch open in python?
<magicaltrout> it just seems a bit loaded, i'm all for recommended charms clearly, but when the search must return basically 0, how it ends up so far down the page is a bit tedious
<magicaltrout> and hard for users who just want to see if anything pentaho related happens to be in the store
<marcoceppi> magicaltrout: I agree
<marcoceppi> cholcombe beisner how can I help?
<lazyPower> rick_h__ - have we thought about talking to merlijin and team about a recommendation engine for the charm store? Might make our search story significantly better
<beisner> cholcombe, destroy your venvs and re-run with `tox -e py27` ?
<cholcombe> ok
<lazyPower> rick_h__ - and i cant think of anyone better to ask than data scientists
<lazyPower> magicaltrout - you're completely included in this list as well ^
<magicaltrout> hehe
<lazyPower> i can see it now
<magicaltrout> well sometimes i put the scientist hat on, but most of the time I hide it behind the sofa
<lazyPower> "You just deployed wordpress. Can i interest you in VARNISH?"
<magicaltrout> it just strikes me that there should be some ranking going on, keyword relevance, recommended vs non recommended, times deployed, age, last updated etc
<magicaltrout> put it in a pot and give it a stir and come up with a search ranking algo that makes it better
<cholcombe> lazyPower, can I pay to have my charm moved up the list? lol
<lazyPower> magicaltrout - best SOW ever
<beisner> charmwords(tm)
<magicaltrout> hehe
<lazyPower> cholcombe - thats unethical
<cholcombe> hehe
<lazyPower> small merge or new charm?
<cholcombe> i'm just kidding
<lazyPower> hey  i try to bribe with pizza all the time
<cholcombe> hah
<lazyPower> i guess people dont like bread and cheese as much as they used to
<axino> cory_fu: I don't know if the charm was built on xenial
<cory_fu> axino: It may be that pip has different requirements on xenial, though I would expect it to not matter since it's a python lib.
<lazyPower> cory_fu - pebkac in the wheelhouse.txt, i had >=1.0.0, so it stopped. >1.0.0,<=2.0.0 seems to have pulled in the right dep.
<cory_fu> lazyPower: Odd.  I would have thought that >=1.0.0 would still have pulled in the highest version
<lazyPower> didn't appear to, i got 1.0.0 otherwise
<axino> cory_fu: "include_system_packages: false" in layer.yaml
<axino> cory_fu: perhaps I should change that ?
<cory_fu> axino: It's certainly worth a shot, but shouldn't be necessary
<cory_fu> axino: If it works, please let me know
<axino> cory_fu: it does have a wheelhouse directory with tar.gz in it, but no wheelhouse.txt afaics
<cory_fu> axino: Is that the built charm or the source layer?  I don't suppose you can provide a link?
<axino> the built charm
<axino> cory_fu: try https://launchpad.net/~canonical-sysadmins/canonical-is-charms/collectd/ ?
<axino> I doubt it though
<axino> cory_fu: https://code.launchpad.net/~axino/canonical-is-charms/collectd should work for you
<cory_fu> axino: I can access the first one, actually  :)
<axino> ho
<axino> well
<cory_fu> axino: So, that's the built charm artifact, so I wouldn't expect it to have the wheelhouse.txt; that gets converted to the wheelhouse/ directory during build.
<axino> ok good
<cory_fu> (Though, now that I think about it, it should probably preserve the combined wheelhouse.txt as well, just in case)
<cory_fu> axino: That wheelhouse looks entirely reasonable, except that it has two versions of charms.reactive in it
<axino> does that include setuptools ?
<axino> looks like not
<cory_fu> No, it doesn't.
<cory_fu> However, if pip depends on it, it ought to.  My guess is that there is a difference in how venvs are created between xenial and trusty and perhaps setuptools is included by default in the former.
<axino> cory_fu: https://pastebin.canonical.com/151985/ is the error I get, in case you didn't see it
<cory_fu> Quite possibly, doing the charm-build from the source layer on a xenial box might fix it.
<axino> ok
<cory_fu> axino: Ok, so that's not even getting to the wheelhouse.  It's actually failing trying to create the venv
<axino> cory_fu: if you have any additional insight, I'll take it :)
<cholcombe> beisner, i'm pushing up a patch set with more logging.  It def works fine locally
<cholcombe> beisner, i tried a clean docker env also and it's fine
<cory_fu> axino: I think it's actually a problem with xenial.  Creating a virtualenv apparently requires setuptools but the python3-virtualenv package isn't listing it as a dependency
<cory_fu> axino: Normally, that wouldn't be too big of a deal, as it gets pip installed on demand when creating the venv, but in that network-restricted environment, it fails.
<axino> cory_fu: note that I have this behaviour even with python3-setuptools installed
<cory_fu> axino: Ok, what about with python-setuptools?
<axino> cory_fu: same
<cory_fu> axino:  If you have a restricted network xenial env, can you try manually doing the following:
<cory_fu> sudo apt-get install python3-virtualenv
<cory_fu> python3-virtualenv testenv
<cory_fu> (That last one might be virtualenv3)
<cory_fu> Probably is
<axino> ok, trying now
<cory_fu> And then also try `virtualenv --python=python3 testenv2`
<axino> cory_fu: I have no virtualenv3, and no python3-virtualenv binary
<cory_fu> axino: Ok, I'm not surprised.  Try the other one, please.
<cory_fu> I saw the python3-virtualenv package in your error and got optimistic
<cory_fu> :p
<axino> :)
<axino> cory_fu: yup that's failing the same way
<axino> timing out
<cory_fu> axino: Yeah.  The problem isn't reactive charms, per se.  It's that virtualenvs don't work in network-restricted envs in xenial
<cory_fu> axino: What *should* happen is that, if python{,3}-setuptools is installed, it should use setuptools from that and not try to pip install it
<axino> cory_fu: just tried virtualenv --python=python3 --system-site-packages testenv2, same error
<axino> hmm, Ubuntu/Debian install in dist-packages though
<axino> "virtualenv --python=python3 --no-setuptools --no-pip testenv2" now it's timing out on "installing wheel"
<cory_fu> axino: Honestly, I don't know why virtualenv is trying to install anything from pypi.  It shouldn't.
<cory_fu> axino: What version of pip does xenial have?
<axino> cory_fu: 8.1.0-2
<axino> cory_fu: !! virtualenv --python=python3 --never-download testenv2 <= that worked
<axino> of course this option is not in the man
<axino> http://ccnmtl.columbia.edu/compiled/released/new_features_in_virtualenv.html found it here
<cory_fu> axino: That's terrible.  If it can succeed with that option, that means it has the packages locally and so why did it even attempt to download them in the first place?
<axino> cory_fu: yeah. :(
<cory_fu> axino: That option seems to work on trusty's virtualenv as well, so I'm fine with adding it to layer-basic
<cory_fu> axino: I'm a little bit concerned about any repercussions that might have on trying to install the wheelhouse after that.  I don't suppose you have the wheelhouse dir handy on that unit?
<axino> cory_fu: I have, this is the unit where the charm is failing its install hook
<cory_fu> Ok, I was hopeful.  Can you try doing: testenv2/bin/pip install -U --no-index -f wheelhouse wheelhouse/*
<axino> cory_fu: https://github.com/pypa/virtualenv/pull/412 looks like this may become the default ? or something, just skimmed over the comments
<axino> cory_fu: https://pastebin.canonical.com/152054/ LGTM
<cory_fu> axino: Ok, great.
<axino> let me hack lib/charms/layer/basic.py on disk and juju resolved -r that install hook
<marcoceppi> cory_fu tvansteenburgh BrunoR amulet 1.14.0 fixes all issues for trusty and xenial
<marcoceppi> it's out, it's tested, it's working
<tvansteenburgh> yay, thanks marcoceppi!
<cory_fu> axino: https://github.com/juju-solutions/layer-basic/pull/48
<axino> cory_fu: cool ! thanks
<cory_fu> marcoceppi: Awewsome!  Thanks
<marcoceppi> tvansteenburgh: bleh @ your pull req
<tvansteenburgh> ?
<tvansteenburgh> marcoceppi: you don't have to do another release
<marcoceppi> tvansteenburgh: Oh I won't
<tvansteenburgh> marcoceppi: i was just about to upload new docs and figured i'd do that first
<marcoceppi> tvansteenburgh: ack, lgtm
<kwmonroe> cory_fu: will this fire if a different function (like quorum_add on line 43) changes zoo.cfg?
<kwmonroe> https://github.com/juju-solutions/layer-apache-zookeeper/blob/master/reactive/zookeeper.py#L33
<tvansteenburgh> marcoceppi: thanks, docs uploaded
<kwmonroe> cory_fu: i'm seeing stuff like "Invoking reactive handler: reactive/zookeeper.py:41:quorum_add" when a peer comes along, and i know that function updates zoo.cfg, but i don't see a subsequent firing of the method gated by @when_file_changed(zoo.cfg)
<kwmonroe> even when i go on that unit and type naughty words into zoo.cfg, i don't see that method being called on the next status_update.
<cory_fu> kwmonroe: Yes.  Any time that file changes, it should trigger that handler.  However, combining @when and @when_file_changed may run you up against the open issue(s) with @when_file_changed
<kwmonroe> ah, yeah, you warned me of that
<cory_fu> kwmonroe: Actually, even without the @when, I think you're running up against those issues.  I'm pretty sure zkpeer.dismiss_joined() is removing a state, which can cause the @when_file_changed to get dropped
<cory_fu> kwmonroe: https://github.com/juju-solutions/charms.reactive/issues/44
<kwmonroe> yeah, i need to double check if we really need to do the dismiss_joined.  i think we're doing that so we pick up subsequent peer joins.
<kwmonroe> but dunno if that's really needed.
<cory_fu> I doubt that it's necessary
<kwmonroe> ack cory_fu.  is the "any_file_changed" helper safer than @when_file_changed whilst issue 44 gets worked?
<cory_fu> Yes
<kwmonroe> roger dodger.  thanks.
<cory_fu> That will avoid the issue.
<cory_fu> kwmonroe: I'd very much like to spend some time trying to fix @when_file_changed because it's a great decorator.  But I have to EOD soon
<fritchie> is there a way to view the porogress when importing boot images to a new MAAS install - seems to be taking longer than I would imagine
<rick_h__> fritchie: on the images page in the webui?
<rick_h__> fritchie: I know they were working on a new page there, not sure if progress is on the new one vs the one you're using
<fritchie> sorry rick, message was meant for maas channel, the wheel is just spinning
<rick_h__> fritchie: understand, we try to help here too :)
<cos1> Hey guys. Hi @arosales
<fritchie> has anyone seen this error? DEBUG juju.provider.common bootstrap.go:259 connection attempt for 172.16.100.101 failed: /var/lib/juju/nonce.txt does not exist
<fritchie> juju.network address.go:504 removing unresolvable address "dnjostack01.maas": lookup dnjostack01.maas: no such host
#juju 2016-03-17
<rick_h__> cos1: howdy
<cos1> not bad, man!
<cos1> What about yourself?
<rick_h__> cos1: having too much fun :)
<marcoceppi> fritchie: that's a new one for me.
<cos1> is it even a thing? ;)
<cos1> I wasn't even aware that someone can have too much of it, rick_h__ :)
<rick_h__> cos1: on definitely, it's called 'red-lining' :)
<cos1> ah ;_
<fritchie> is there a way to delete a maas environment besides maas destroy-environment, it just hangs on that
<arosales> cos1: hello and welcome :-)
<cos1> thanks arosales!
<cos1> Good to be here indeed
<arosales> cos1: just in time for the juju 2.0 goodness
<cos1> wheee! ;)
<cos1> Would be a lot to learn in the first day or two ;)
<marcoceppi> o/ cos1
<marcoceppi> good to see you again
<cos1> likewise man!
<axino> marcoceppi cory_fu : now I get "INFO install The executable =python3 (from --python==python3) does not exist" , we want -ppython3 actually (without the =)
<lazyPower> axino o/ isn't it silly late for you?
<axino> o/ lazyPower
<axino> cory_fu marcoceppi : we also need to install the "virtualenv" package, else it's not there sometimes apparently !
<saadraza92> hey there
<saadraza92> any juju guru here?
<saadraza92> facing problems regarding ssh from a juju machine
<tinwood> gnuoy, have you got a moment for a quick question?
<Sophie__> hello :)
<Sophie__> i have big trouble with juju maybe some1 could help me
<Sophie__> :D
<Sophie__> I am trying to install juju on maas with vms, but although juju has deployed on the node it seems like it is not installed
<Sophie__> i cannot make the maas server to auto start the node and I do it manually every time, i dont know if this is the problem
<Sophie__> btw I am awesome <3
<saadraza92> there?
<jcastro> magicaltrout: I see you had a problem with juju's search results
<magicaltrout> jcastro: i don't have problems, i just think they're a bit useless :)
<jcastro> heh, yeah
<jcastro> so, I've filed a few bugs on it
<jcastro> and also on our general SEO stuff
<jcastro> which is terrible also
<jcastro> just letting you know mramm will be leading the effort to make search, SEO, and general "why can't people discover this?" problems less sucky
<magicaltrout> cool.
<magicaltrout> I just think that the non recommended stuff shouldn't get pushed so far down when nothing in the recomended namespace matches, basically.
<magicaltrout> at first i didn't think my charm was listed cause I couldn't find it without Ctrl+F :)
<jcastro> anyway, the more people who are non-me who complain about it, the more attention it will get
<jcastro> so basically, being more squeaky wheel helps me get resources
<magicaltrout> want me to complain on the mailing list as well? :)
<jcastro> because why even have a search at all?
<jcastro> yes, that would be great
<magicaltrout> k, i'll put something together over lunch and dispatch it
<magicaltrout> i'm british we like a good moan
<jcastro> yeah plus when markS sees our little papercut it helps get us the focus we need to just fix the little things
<jcastro> sometimes we're so worried about the little problems that we forget the little things
<jcastro> I meant the big problems, heh.
<cory_fu> axino: Fixed.  It already does install python-virtualenv: https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/basic.py#L34
<tvansteenburgh> what's the best way to get a list of all the trusty charms in the charm store?
<jrwren> tvansteenburgh: http://api.jujucharms.com/charmstore/v5/list?series=trusty
<rick_h__> https://api.jujucharms.com/charmstore/v4/search?text=&series=trusty&limit=2000
<rick_h__> doh
<tvansteenburgh> fight!
<tvansteenburgh> thanks guys!
<jrwren> rick_h__: haha, beat ya! ;]  and I like my way better
<rick_h__> jrwren: I do to!
<jrwren> you got the https right though. I got it wrong.
<tvansteenburgh> jrwren, rick_h__: is there a way to filter this down to only recommended charms?
<rick_h__> well I entered it into a browser first
<jrwren> tvansteenburgh: add &promulgated=1 to the querystring
<rick_h__> tvansteenburgh: I forget if the query arg is promulgated=true or what
<tvansteenburgh> jrwren: thanks
<urulama> tvansteenburgh: its owner= (empty)
<marcoceppi> wait, it's not approved=1 anymore?
<urulama> marcoceppi: never was
<urulama> marcoceppi: well, at least last 2 years :)
<tvansteenburgh> urulama: owner= gives me no results
<urulama> tvansteenburgh: https://api.jujucharms.com/charmstore/v4/search?text=&owner=&limit=100
<jrwren> promulgated=1 works.   | to jq '.[]|length and there are 1436 trusty charms, and 186 promulgated trusty charms.
<jrwren> oh, urulama is right if using /search, but I do not like search, so I use /list ;]
<urulama> jrwren: don't use list!
<tvansteenburgh> urulama: https://api.jujucharms.com/charmstore/v5/list?series=trusty&owner=
<urulama> list is not indexed and is not meant to be used in this cases
<tvansteenburgh> oic
<urulama> tvansteenburgh: don't use list
<jrwren> urulama: but... but... :[
<urulama> tvansteenburgh: https://api.jujucharms.com/charmstore/v4/search?text=&owner=&limit=100&series=trusty
<urulama> increase the limit if you want more
<urulama> jrwren: :) yeah. just don't :D
<tvansteenburgh> urulama: ok, thanks
 * urulama is going to block the list and will work with macaroons only :P
<jrwren>  the /search is much faster.
<urulama> jrwren: yeah. its ES (search) vs mongo collection sweep (list)
<jrwren> urulama: yeah, i hate ES, hence my love of /list ;]
<cholcombe> cory_fu, question for ya.  how do you properly mock open in python?  I've found a bunch of crap blog posts but they all don't work right
<jrwren> cholcombe: i dare you to ask voidspace
<cholcombe> jrwren, i'll ask whomever :D.  I can get it to work locally but it fails when i push it to jenkins
<cory_fu> :)
<cory_fu> I'm happy to help, but obviously voidspace is the expert.  :)
<cory_fu> cholcombe: Do you have repo link?
<cholcombe> cory_fu, sure
<cholcombe> lemme link it up
<cholcombe> https://review.openstack.org/#/c/287500/6/unit_tests/test_replace_osd.py
<cholcombe> cory_fu, jrwren voidspace ^^  line 101
<marcoceppi> cholcombe: I do this
<cory_fu> cholcombe: The most helpful bit of advice I've found is: http://www.voidspace.org.uk/python/mock/patch.html#where-to-patch
<cholcombe> i mean line 95
<marcoceppi> cholcombe: http://paste.ubuntu.com/15408036/
<marcoceppi> cholcombe: thats for both py2 and py3
<cholcombe> marcoceppi, i'll give that a try
<cory_fu> marcoceppi: Whoa.  That seems unnecessary
<cory_fu> marcoceppi, cholcombe: http://www.voidspace.org.uk/python/mock/helpers.html#mock-open
<marcoceppi> cory_fu: why? it's the only way I've found for `with open`
<marcoceppi> meh
<cholcombe> cory_fu, yeah i can't seem to get mock_open to work with patch correctly
<jrwren> __main__, builtins, or __builtin__, that is the question.
<cory_fu> cholcombe: Did you include the create=True?
<cholcombe> cory_fu, i did
<cholcombe> it's perfectly happy when i test locally.  it's jenkins that throws a wrench in it :D
<cory_fu> cholcombe: You shouldn't be patching in __main__.  That's going to change depending on how the code is invoked
<cory_fu> You should be patching replace_osd.open
<cholcombe> cory_fu, yeah that's prob the issue
<cholcombe> ugh neither replace_osd.open nor builtins.open works locally in my charmbox
<jrwren> cholcombe: did you try __builtin__ ?
<cory_fu> cholcombe: Can you point me to the source of replace_osd.lookup_device_name?
<cholcombe> cory_fu, sure
<voidspace> jrwren: cory_fu: hah, just off to pick up my daughter from school - back soon
<cory_fu> jrwren: You always want to patch closest to where the function you're patching is called.  Patching in __builtins__ is the wrong place
<cholcombe> cory_fu, https://review.openstack.org/#/c/287500/6/actions/replace_osd.py
<cholcombe> line 30
<jrwren> cory_fu: nonsense.
<jrwren> cory_fu: or rather, I strongly disagree for my use cases.
<cory_fu> jrwren: I'm not saying it definitely won't work, but it's a bad habit to get in to and will tend to end you up in situations where your mocks don't work like you expect
<cholcombe> i'll just comment and say the function works trust me ;) lol
<cory_fu> jrwren: And with mocking open in particular, patching it in __builtins__ can make debugging, error reporting, and a host of other things screwy
<jrwren> cory_fu: I don't agree, but I think I understand your concerns.
<cory_fu> I know because I used to run in to this stuff all of the time  :)
<cholcombe> cory_fu, i was considering changing the way my code in replace_osd is written to make it easier to patch
<cory_fu> cholcombe: Can you give me the output of the test failure?
<cory_fu> cholcombe: That is not a bad idea.
<cholcombe> cory_fu, yeah it says sda == None fails
<cholcombe> cory_fu, yeah i was thinking of calling os.open or something easier to patch
<cory_fu> cholcombe: Perhaps a nicer way would be to split the open() call into its own method (get_disk_stats) and have lookup_device_name call that instead.  Then you don't really need to test that you can open and read a file, and you can test the logic in l_d_n by itself
<cory_fu> And just mock get_disk_stats
<cholcombe> cory_fu, yeah that's a method i use in rust also.
<cholcombe> cory_fu, that sounds good to do
<cory_fu> A slightly "better" way would be to have lookup_device_name take the disk_stats as a param, so it's truly functional, but at that point you're trading some calling convenience for a trivial mock and it's probably not worth it
<cory_fu> But, in general, isolating your external dependencies and making all of your logic live in purely functional ... functions makes them much easier to test
<cory_fu> And often results in cleaner, easier to use code
<cory_fu> cholcombe: For that test failure, what is the actual "dev_name: {}" output?
<cholcombe> cory_fu, it outputs None
<cholcombe> so i suspect my patch failed in that case
<cory_fu> cholcombe: Looks like mock_open() doesn't support `for line in fh`: http://pastebin.ubuntu.com/15408195/
<cholcombe> cory_fu, ah wow yeah that's prob the issue
<cholcombe> cory_fu, i changed it around so i have a function that just get diskstats and put that up for review :)
<icey> beisner: can you take a look at https://code.launchpad.net/~chris.macnaughton/openstack-charm-testing/add-ceph-multi-az/+merge/289387
<icey> also want to re-look at https://code.launchpad.net/~chris.macnaughton/openstack-charm-testing/next-ceph-osd-bundle/+merge/285890 beisner
<icey> ?
<beisner> icey, 1 landed, 1 reviewed :)
<icey> beisner: yeah, going to have to redo the reviewed one from scratch :-P
<icey> easier than modifying methinks
<ryotagami> I have a question regarding charm review. I have a charm that currently in review, and I have an update to that charm that is not related to review items. Should I create a new branch and a bug, or can I update the currently ongoing branch and bug?
<beisner> icey, so the az bundle that landed in o-c-t is structured for 1 machine per unit, and sets vdb for the disk, which is what we need for serverstack.   to exercise on metal, i'd set osd-devices to "/dev/sdb /dev/vdb"
<icey> new mp coming soon ;-)
<beisner> icey, this will be 7 physical machines.  is there anything you can do to co-locate in lxc to get us down to 4 machines?   also, will ephemeral unmount /mnt error when used on metal?
<icey> beisner: shouldn't fail, because 'e_mountpoint and ceph.filesystem_mounted(e_mountpoint)'
<icey> will work on wrapping up the mons
<beisner> icey, ack thx
<icey> beisner: https://code.launchpad.net/~chris.macnaughton/openstack-charm-testing/add-ceph-multi-az/+merge/289394
<icey> beisner: alternately, can I remove the machine specifications because trhe ceph-mon associates to lxc:ceph-mon/# ?
<cory_fu> cholcombe: https://github.com/testing-cabal/mock/pull/343
<cory_fu> Not that it helps you now.  :)
<wolsen> beisner: https://review.openstack.org/#/c/292599/ is that ready to land you think?
<beisner> wolsen, i do.  shall i hit the button?
<wolsen> beisner, we're gonna have to sooner or later
<wolsen> :)
<thedac> narindergupta: Congrats on your OPNFV award!
<thedac> belatedly ^^
<narindergupta> thedac: thanks and nothing could have been done without your team.
<narindergupta> thedac: and ward is for Canonical as I represent Canonical there.... :)
<thedac> I suspect you had a lot to do with it
<beisner> wolsen, ok that's ackd.  once it merges, you'll wanna rebase the other ceilometer stable update.
<wolsen> beisner: yes indeedy thx!
<lazyPower> bdx ping
<beisner> wolsen, thanks for paving that path
<wolsen> yeah big congrats narindergupta! (btw, I'll merge the m-d proposal you made a bit later today)
<narindergupta> wolsen: thanks
<narindergupta> thedac: :)
<natefinch> marcoceppi: min-juju-version landed, finally.
<lazyPower> nice
<lazyPower> natefinch thats in metadata.yaml right?
<natefinch> lazyPower: yep
<tvansteenburgh> "The LXD local provider will not work on Ubuntu 12.04 LTS (Precise) and backporting to Ubuntu 14.04 LTS (Trusty) is incomplete."
<tvansteenburgh> is this still true re Trusty? ^
<marcoceppi> tvansteenburgh: AFAIU yes
<marcoceppi> charm and charm-tools 2.0 are building in the devel ppa!
<tvansteenburgh> \o/
<lazyPower> \o/
<marcoceppi> tvansteenburgh: if you have a min, could you take a look at this today? https://github.com/juju/charm-tools/issues/137 if not tomorrow morning would be great
<marcoceppi> tvansteenburgh: esp since we will ahve "plugins" show up in the help output of charm 2.0 by default
<tvansteenburgh> marcoceppi: will do
<axino> cory_fu: but python-virualenv doesn't provide virtualenv anymore, apparently
<axino> t*
<cory_fu> axino: o_O
<cory_fu> That doesn't make any sense
<cory_fu> axino: Oh, you're saying they changed it to just "virtualenv"  Hrm
<axino> cory_fu: yeah
<cory_fu> axino: I thought I saw python-virtualenv referenced in your output, though
<axino> (also, I think we need python3-virtualenv - which is pulled by the "virtualenv" package on xenial)
<cory_fu> axino: Line 83 from your previous link: https://pastebin.canonical.com/151985/
<cory_fu> 2016-03-16 07:52:24 INFO install The following NEW packages will be installed:
<cory_fu> 2016-03-16 07:52:24 INFO install   python-virtualenv python3-virtualenv virtualenv
<axino> yeah, on that specific unit, the package got pulled
<axino> but not on another unit
<cory_fu> I don't understand.  Why would it be different?
<axino> I do not know
<axino> https://pastebin.canonical.com/152206/
<axino> looks like python-virtualenv does pull virtualenv. Ugh. I'm not sure what happened yesterday
#juju 2016-03-18
<axino> cory_fu: still about ?
<axino> cory_fu: https://pastebin.canonical.com/152219/ I repro'ed
<axino> cory_fu: OK found the difference : APT::Install-Recommends "false";
<axino> cory_fu: python-virtualenv only recommends the virtualenv package, so I think we should "force" its installation
<Sophie_> brothers in arms I need help
<gnuoy> jamespage, have you got a sec for https://code.launchpad.net/~gnuoy/charm-helpers/keystone_authtoken/+merge/289042 ?
<icey> I've deployed juju (1.25.4) onto MAAS configured with zones, but the charm environment still doesn't seem to be setting JUJU_AVAILABILITY_ZONE
<tvansteenburgh> hey guys, i have a fresh xenial with a fresh juju 1.25.3. `ps -aef |grep juju` returns nothing. how do i get juju running, or figure out why it won't start?
<icey> tvansteenburgh: have you 'juju bootstrap'ed
<tvansteenburgh> icey: says i'm already bootstrapped, but i can't destroy b/c jujud isn't running
<icey> local environment tvansteenburgh?
<tvansteenburgh> hmm, that gives me an idea though
<tvansteenburgh> yeah
<tvansteenburgh> icey: got it going again with the juju-clean plugin
<icey> nice tvansteenburgh :)
<icey> hopefully my problem is as easily solved, though I fear not
<marcoceppi> Sophie_: how can we help?
<Sophie_> i thinki i found something i will tell you if it doesnt work :P
<beisner> icey, can you point me at that az bug for 1.25.x ?
<beisner> my search foo is failing me ... ++coffee..
<icey> beisner: https://bugs.launchpad.net/juju-core/+bug/1546790
<mup> Bug #1546790: availability zone not set <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Released by anastasia-macmood> <https://launchpad.net/bugs/1546790>
<icey> that should be fine on MAAS too as it is not a provider specific change
<beisner> icey, still getting 'None' ?
<icey> on MAAS, yes; works fine on AWS
<beisner> icey, can you push a new patchset to 293694 with log("AZ Info: " + az_info) in your az_info() method?
<beisner> or the slightly adjusted equiv that is
<icey> heh sure, I did have that in there at one point :)
<beisner> that'll be something we want in place for t-shooting purposes, both now, and down the line.
<beisner> safe to leave in place
<icey> beisner: incoming
<beisner> icey, thx sir
<beisner> icey, i'm going to tear that down and redeploy.  need to catch the tiger by the tail.
<icey> beisner: I was just about to say I'll do that :)
<icey> I'll let you drive
<icey> beisner: did you want to update the bundle to deploy changset 5?
<beisner> icey, oh heck.  yes.
<icey> on the plus side, it failed to deploy anyway beisner
<beisner> icey, yeah i suspect a separate bug in 1.25.4, as it did that on me as well.  but a retry succeeded.   and it didn't do that with the same bundle on 1.25.3.
<beisner> but one at a time
<icey> by the way, apparently 1.25.4 is DOA for another bug, but it's the minimum that has a fix we're testing :)
<icey> beisner: ^
<beisner> it is
<beisner> but if we want to move this az thing fwd, we either try-and-see, or shelve it until there is a juju version where az does what the charm change requires
<beisner> icey, ha.  the controller had the patchset 4 rev of ceph-osd.  will upgrade-charm...
<icey> yay controller -_-
<jamespage> thedac, beisner: had another run at https://review.openstack.org/#/c/291721/3 which should deal with upgrades as well
<jamespage> its hard to follow the logic, but basically if the nova_api db is not created, we skip migration on service restart on upgrade, clear the dbstate marker in leader storage and then migration and restart on the next db-changed event...
<beisner> icey, ok, charm upgraded.  now to look at the unit logs for az info dump...  drumroll
<icey> beisner: the place we call that happens in emimt_cephconf
<icey> emit_cephconf rather
<icey> beisner: look at /etc/ceph/ceph.conf ; it JUJU_AVAILABILITY_ZONE is, then it will be present there
<icey> in "osd crush location"
<icey> no AZ is set
<beisner> but at least we see that in the juju unit log now
<icey> true
<beisner> icey, ok this is where i bail on deploy/test efforts and let you drive the bug(s).   az ceph changes should be kept wf -1 until we can actually exercise the proposed changes.  we'll keep those maas machines avail to you though.
<icey> beisner: they are fine on AWS :-P
<beisner> until thedac needs 'em back that is ;-)
<icey> but yeah, I think this is blocked until we can get some juju insight on it
<beisner> icey, right, but the actual use case is on metal.
<icey> beisner: one can only hope ;-)
<beisner> icey, ok thx for diving into that with me.  lmk how it goes with bug chasing.
<beisner> jamespage, ack, thx re: ncc 291721, will look for thedac to re-review.
<beisner> hi tinwood, gnuoy - re: the enhanced pause/resume work - should we be adding pause/resume amulet tests to go along with those?  (similar to the early-adopter swift-* ones)
<gnuoy> beisner, yes, I think we should
<tinwood> hi beisner, yes, I've added that to my instructions in the gist: https://gist.github.com/ajkavanagh/bb16cd911dfbac2e5651
<beisner> gnuoy, tinwood - ok great, i agree.  i'd like to see those accompany the proposals.
<tinwood> beisner,  "proposals"?
<beisner> errr uhm, gerrit changes.  /me still blurs git/gerrit/bzr terminology ;-)
<tinwood> ah, right.
<beisner> if we defer to add tests later, we endure test debt which may or may not be revisited.
<beisner> hence, the accompany-changes-with-tests preference
<tinwood> beisner,  we singing from the same songsheet.
<beisner> woot
<beisner> ðð
<tinwood> :)
<beisner> wow that +2 button is no-confirm one-click madness
<beisner> tinwood, ok yep i also had refresh the browser issues on my wf-1 for your ceilo.  wf cleared to 0
<tinwood> beisner, you too eh.  I also think I had a osci blow up on the charm-recheck-full on charm-glance :(  -- or I misunderstood the error trace.
 * beisner looks
<beisner> tinwood, indeed "ERROR failed to bootstrap environment:"  might have been during the network loop/storm.  feel free to retrigger
<tinwood> beisner, yes - that makes sense.  Lost network access to the bastion for about 2 mins around 12.00 today -- IIRC.
<tinwood> I'll trigger a recheck.  Thanks!
<beisner> tinwood, ack thx too
<beisner> hi tvansteenburgh, i'm seeing something that i think is an amulet bug in the sentry list population, with subordinates.  caught it here:  http://pastebin.ubuntu.com/15414895/   ideas?
<tvansteenburgh> beisner: can you file that here and i'll take a look https://github.com/juju/amulet/issues
<thedac> jamespage: I'll take a look at your nova-cc PR shortly
<tvansteenburgh> beisner: can you include the full yaml formatted status too
<beisner> tvansteenburgh, yep, raised, will add full yaml
<tvansteenburgh> beisner: also, does self.d.sentry['lxd'][0] work?
<tvansteenburgh> (if you know)
<beisner> tvansteenburgh, i'm guessing so, per: https://github.com/openstack/charm-lxd/blob/master/tests/basic_deployment.py#L127
<tvansteenburgh> beisner: k, thanks
<beisner> tvansteenburgh, i wonder if the passing runs have matching subordinate and principal unit ids and if it's failing when they aren't matching?  aiui there's no guarantee that they will match.
<beisner> tvansteenburgh, indeed, when the sub and princ unit id's match, it passes.
<tvansteenburgh> beisner: could be a red herring, i can't see the relevance in the code
<tvansteenburgh> of course i could be wrong
<beisner> tvansteenburgh, yah it could be, i've not dug into it.
<jamespage> thedac, hey - looking at that unison merge/bug you referenced now
<thedac> jamespage: sweet, thanks
<magicaltrout> marcoceppi: couple of random questions from todays delving into charm world
<magicaltrout> a) why can't you trigger actions from juju gui?
<magicaltrout> b) can you trigger actions from within a bundle?
<marcoceppi> a) the GUI hasn'
<marcoceppi> t had time add that as a feature yet
<marcoceppi> b) not yet, we had an interesting conversation about it and it's a feature I'm interested in for benchmarking but you can't atm
<jcastro> marcoceppi: for policy the "must pass bundletester" ... that replaces must pass charm proof and bundle right?
<jamespage> thedac, not sure I quite understand how that's impacting you?
<jcastro> for your proposal I mean
<marcoceppi> jcastro: yes
<magicaltrout> booo
<magicaltrout> okay
<magicaltrout> I wanted to come up with a useful "demo bundle"
<thedac> jamespage: keystone on xenial segfaults when trying to copyt the ssl files via unison
<jcastro> do we have bundletester documented? I can't seem to find a page for it
<magicaltrout> but i'd need to run some actions to get the test data stuff in there
<marcoceppi> magicaltrout: yeah, I do as well. It might be good to reply to the roadmap email for actions in bundles and actions in GUI
<jamespage> thedac, between units all on the same version?
<marcoceppi> magicaltrout: I keep forgetting about those
<thedac> jamespage: yes
<magicaltrout> i'll add them in then
<marcoceppi> jcastro: for now, just have it as `charm test` we'll make charm test do the right thing
<thedac> jamespage: and I can confirm manually scp'ing works
<jcastro> ack
<jamespage> thedac, Unison segfault when transferring data, "input_value: bad bigarray kind"
<jamespage> that kinda thing?
<thedac> similar. I'll have to deply again to get the exact error
<jamespage> thedac, but you def saw a segfault right?
<thedac> yes, that is confirmed. While running the command by hand
<cory_fu> axino: https://github.com/juju-solutions/layer-basic/pull/49
<cory_fu> tvansteenburgh (or anyone who can help): We ran into an issue with our bundle test for Zeppelin in that Zeppelin requires Javascript to render anything so our Amulet test can't verify that it's actually working.  That ended up biting us because it in fact isn't.  Any suggestions on how to charm test a service that requires JS?
<magicaltrout> cory_fu: can't you prod endpoints to check its responding correctly?
<tvansteenburgh> cory_fu: i dunno, maybe shell out to casperjs or something
<tvansteenburgh> cory_fu: might be a good question for hatch
<cory_fu> magicaltrout: I don't know the protocol the zeppelin websocket uses
<tvansteenburgh> i assume you'll have to shell out to something though
<hatch> ahoy
<cory_fu> hatch: Trying to figure out how to create an automated test for Zeppelin.
<hatch> cory_fu: if you want to test that zeppelin renders something properly (although thats probably not recommended because you're effectively testing Zeppelin at that point)
<lazyPower> cory_fu : if you're willing to incur the dep cost, phantomjs is a resonable headless test driver that by its very nature understands js.
<hatch> you 'simply' ;) need to load it up in something like phantomjs and then query the dom
<hatch> using a test driver
<lazyPower> cory_fu : splinter is a nice abstraction for talking to phantom from python...
<cory_fu> Nice. Those are exactly the suggestions I was hoping for.
<magicaltrout> last time I had to test websockets, I trapped some output with wireshark and hacked up curl to test it :)
<hatch> cory_fu: although I'd still question weather the test is necessary
<lazyPower> hatch - i think its more of a smoke test to find out if zeppelin is doing the right thing
<tvansteenburgh> ERROR unrecognized command: juju init
<tvansteenburgh> wtf
<cory_fu> hatch: The background is that Zeppelin starts up and runs fine, but if you actually try to run the notebook, it fails because of a classpath configuration issue
<hatch> ohhh I see
<hatch> downloading and installing phantom is such a time consuming process :(
<lazyPower> cory_fu - i'm curious to see how that evolves over time, if it becomes a noisy test due to DOm changes between releases, or if it stays relatively consistent
<lazyPower> hatch - we can use a container to make that part faster
<hatch> mmm true true
<hatch> it's really too bad everyone is going to these client-only rendering schemes
<cory_fu> Yeah, I had thought of phantomjs but figured it would be a big dep just for a test.  And I also wasn't sure about bindings, but if splinter is good, maybe it'll be worth it
<hatch> it only takes a few hours to set up an isomorphic rendering setup
<lazyPower> as a webdev that pushed for the client to do more, i regret nothing... but i also got out of webdev :D
<magicaltrout> i'll take websockets headaches over php any day ;)
<lazyPower> ^
<lazyPower> and that
<lazyPower> bushel baskets full of that
<hatch> lol
<cory_fu> ha
<cory_fu> magicaltrout: I'm really not inclined to start reverse-engineering ZK, though
<hatch> if I can't load a 'content' site without javascript and still see the content - they did it wrong ;)
<magicaltrout> it is true though, I'm not a fan of stuff that is entirely Javascript, even though i write webapps for a living.
<hatch> cory_fu: I'd imagine others would also need to do similar tests with charms, might be worth abstracting it into a module of sorts
<magicaltrout> yup, if it becomes generic, I don't mind reusing someone elses effort ;)
<aisrael> Did I dream juju 2.0 beta 2 was released? I've got ppa:juju/devel added but still don't see beta 2
<aisrael> Ohh. The package was renamed from juju-core2 to juju2
<kwmonroe> yeah, thank lazyPower for that ^
<lazyPower> i got bit by it too
<lazyPower> had to update charmbox
<lazyPower> kwmonroe what did i do?
<cory_fu> lazyPower: I tihnk kwmonroe was referring to the splinter suggestion
<cory_fu> Or maybe he was blaming you for the juju-core2 -> juju2 rename
<cory_fu> Either way, it's all your fault
<lazyPower> yeah, some would say that
<magicaltrout> hehe
<lazyPower> but some people just want to watch the world burn cory_fu
<cory_fu> lazyPower: When you made your earlier comment about encouraging client-heavy pages and then leaving web dev, I pictured you throwing a match over your shoulder while walking away, after having convinced everyone to hoard gasoline in open containers
<jamespage> beisner, hey https://review.openstack.org/#/c/291139/ is still kicking around - nice to get that landed if possible...
<hatch> cory_fu: lol
<beisner> jamespage, indeed.  so we had our own ski trip this week, but it was more off-path, through the trees with a few cliff jumps ;-)   i think we're clear of any fires and back to regular business.
<jamespage> beisner, oh did we?
<jamespage> beisner, what exploded?
<lazyPower> hahaha
<beisner> jamespage, first stable charm update with the new flow revealed:  stable charms needed tox and gerritreview file housekeeping, and 16.01 stable charms are set to test amulet against next which is no bueno;  WIP by wolsen and i
<jamespage> beisner, urgh...
<beisner> jamespage, the master charm makefiles were still using system pkgs which was causing inconsistency in tests, that's fixed on all @ master (except lxd, which has a wip)
<beisner> jamespage, and we broke and reverted two charms at master. ;-)
<jamespage> eeek
<beisner> plugged one of those holes with an amulet test, the other was just process
<marcoceppi> tvansteenburgh: juju init is dead
<marcoceppi> just autoload-credentails
<beisner> and everyone survives :-)
<marcoceppi> wtf do you need to init ;)
<tvansteenburgh> marcoceppi: thanks, i figured it out :)
<tvansteenburgh> marcoceppi: well it's in the docs, and it's still in the command list for juju2
<marcoceppi> and so ends one of the longest running disagreements between me and evilnickveitch "init vs generate-config" ;)
<marcoceppi> tvansteenburgh: that's just beta cruft, it's gonzo
<tvansteenburgh> cool
<evilnickveitch> marcoceppi, yes, it must be great for you not to be quite so wrong any more :)
<marcoceppi> evilnickveitch: aww, that's what I was hoping you would say. I miss our spirited debates
<evilnickveitch> I'm sure we will find something to take its place!
<jamespage> beisner, the revert was the 'blocked' status on ceph-osd?
<beisner> jamespage, ack that one and a keystone install-hook fail.
<gnuoy> beisner, I'm failing to grok the CI comments on https://review.openstack.org/#/c/292897/ , has full amulet passed?
<beisner> gnuoy, yep i cleared my wf -1 to 0;  then prematurely +2'd (via the one-click no-confirm +2 button, yikes);  then set my code-review to 0;  most recent patchset (5) has Canonical CI verify+1;  so it's clear to review.
<gnuoy> beisner, ok, ta
<beisner> gnuoy, yw.  apologies for the noise there.
<jamespage> gnuoy, thedac, beisner: hey I was going to try to spend some time next week on nova-cc and nova-compute to a) rollup old config files and b) extract neutron
<jamespage> any thoughts?
<gnuoy> jamespage, Sounds great, thank you
<thedac> nova-compute would still run nova-api-metadata when in dvr mode, correct?
<jamespage> gnuoy, this would mean removal of the legacy neutron support which I think would be a win for all
<gnuoy> agreed
<jamespage> based on my current experience of the nova-cc charm at least
<jamespage> thedac, correct
<jamespage> so its aware of neutron, but only provides nova services...
<thedac> jamespage: then I am a big +1
<jamespage> thedac, I reckon it will strip out about 50% of the codebase..
<jamespage> esp in nova-cc
<thedac> nice
<jamespage> thedac, unison is merged btw
<jamespage> so that should fix keystone syncs again
<thedac> jamespage: thanks. I'll test
<jamespage> but it does mean that a trusty->xenial sync will not work
<jamespage> I think
<jamespage> its a bit of a mess with cross version compat afaict
<thedac> gnuoy: is this the only nrpe change? https://code.launchpad.net/~gnuoy/charms/trusty/nrpe/sibling-subordinate/+merge/288888  That one failed automated testing
<gnuoy> thedac, that's the one. It'll probably be next week before I can get to checking why it failed
<thedac> gnuoy: ok, I'll still do the code review for now
<gnuoy> thedac, excellent, thanks
<thedac> gnuoy: it might be a test rig failure. import amulet failing http://juju-ci.vapour.ws:8080/job/charm-bundle-test-aws/3192/console
<thedac> tvansteenburgh: Is this a problem with the automated testing? ^^
<gnuoy> wolsen, hardening io ch change landed
<thedac> nice
<tvansteenburgh> thedac: amulet pkging prob, but resolved since that test ran
<thedac> tvansteenburgh: great, is there a magic way to retest?
<tvansteenburgh> thedac: yes :)
<tvansteenburgh> thedac:  are you in ~charmersL
<tvansteenburgh> ~charmers ?
<thedac> tvansteenburgh: haha, I was when I was in IS. I need to make that request. my bad
<tvansteenburgh> thedac, np, if you were you could kick off a test from here http://review.juju.solutions/review/2606
<tvansteenburgh> but i'll do it for you
<thedac> thank you, sir
<tvansteenburgh> thedac: retest queued, np
<wolsen> gnuoy \o/
<jamespage> thedac, did a quick upgrade check on nova-cc liberty->mitaka - worked OK
<jamespage> in that it did the series of things I expected it todo.
<thedac> sweet.
<jamespage> and is functional afterwards...
<thedac> that is always good
<thedac> I'll watch the amulet run and +2 when it completes. (unless we are supposed to have different reviewers do the second review) /me still learning the process
<narindergupta> marcoceppi: hi
<narindergupta> marcoceppi: do we know whether juju published feature is there in latest juju client? As we have to start preparing for OPNFV C release now so want to make sure i published the various charm in opnfv dev space and use it? How can i do that?
<thedac> jamespage: oh, amulet already succeded. So again policy wise should I be the +2 or should that be a second reviewer?
<jamespage> thedac, +2 approval from you is fine, and then +1 on workflow to land it...
<thedac> cool
<jamespage> thedac, we're only enforcing a no-self-review policy right now
<thedac> got it
<thedac> jamespage: approved
<marcoceppi> narindergupta: that will be released either today or monday
<marcoceppi> narindergupta: and it's not in the juju client, it's in the charm command
<narindergupta> marcoceppi: ok i need to learn how to do and how its going to help me in C release. Ad most importnant for me is openstack charms in git repo though
<thedac> jamespage: seems the unison merge fixed that issue. Thank you.
<jamespage> thedac, np
<jamespage> narindergupta, openstack charms are in git repos now
<narindergupta> jamespage: yes thats in git repos and my queston was whether juju feature of publishing charm in dev will work for openstack charms in git repo also or not?
<jamespage> narindergupta, tbh the new workflow is agnostic of VCS
<jamespage> its basically 'shove this directory and contents to the charmstore here please'
<narindergupta> ok that sounds good then
<narindergupta> so that we can control what should go in opnfv dev charmstore space
<jamespage> narindergupta, I'm a little unclear as to why you need a separately namespaced set of charms?
<cholcombe> no crontab helpers in charmhelpers?
<cholcombe> pip to the rescue!
<fritchie> anyone here familiar with openstack-base?
<icey> lazyPower: can you install python-tox on the base docker image for https://github.com/juju-solutions/charmbox ?
<lazyPower> if you give me a bug to do so
<lazyPower> do you want it in stable, devel, or both?
<icey> lazyPower: development? I want to be able to start up the box, cd to the charm directory, and run make test; most of our (openstack) tests are using tox to manage the testing environment
<lazyPower> so you want it on the 2.0 flavor only?
<icey> lazyPower: I suppose I misunderstood, I'd like it to have tox on all versions that I could run tests on :)
<lazyPower> icey - ack, gimme a bug# and i'll submit to the builders
<icey> bug# on LP, GH?
<lazyPower> GH
<lazyPower> @ the repo you linked above
<icey> https://github.com/juju-solutions/charmbox/issues/13 lazyPower
<lazyPower> icey : https://github.com/juju-solutions/charmbox/pull/14
<lazyPower> icey : https://github.com/juju-solutions/charmbox/pull/15
<lazyPower> ~ 20 minutes after those are merged you'll have new toys in charmbox
<icey> :)
<lazyPower> https://hub.docker.com/r/jujusolutions/charmbox/builds/ - if you wanted to follow along at home
<icey> heh lazyPower, the reactive base layer is using tox for unit testing :)
<lazyPower> we've been using tox all over the place for quite a while
<lazyPower> good shout tho. lmk if you need anything else icey
<icey> I think I'm good lazyPower thanks!
<cholcombe> lazyPower, want to review a 4 liner?  https://code.launchpad.net/~xfactor973/charm-helpers/action-params/+merge/289537
<lazyPower> cholcombe - sure - if you review mine https://github.com/juju-solutions/layer-logstash/pull/13
<cholcombe> lazyPower, :)
<lazyPower> obey the space walrus
<cholcombe> hah
<cholcombe> lazyPower, it looks sane to me
<cholcombe> lazyPower, i don't have a lot of layer experience though so if i missed something that's why :)
<lazyPower> cholcombe - time to change that ;)
<cholcombe> yep
<lazyPower> approved/merged
<lazyPower> cholcombe - beware though, i dont think that method is python3 safe. iteritems was removed i'm pretty sure
<cholcombe> lazyPower, uh oh
<lazyPower> dict.items() is the python3 idiom
<cholcombe> gotcha
<thedac> Finally sent my offical ~charmers application email
#juju 2016-03-20
<TrustInAllah> I will post a video of a series of lectures on the Hereafter on what happens to us after this life, I know you're all busy with your works and this might be irrelevant to your interests but this is  extremely important. Please pause whatever is you're doing and put it on hold as death is a reality which none of us can escape, https://www.youtube.com/watch?v=J6POzsLaKP4&list=PLyIDfFGMrsvtUiDND0b
<TrustInAllah> zdKagGyejGWYJU
<lamertje> hi all, how do I expose a port on a unit (service) which was not defined in the charm?
<lamertje> WINDOW LEVEL -CRAP
<lamertje> oops
<lamertje> brb
<magicaltrout> lamertje: there's actually a charm in the charm store that lets you open arbitrary ports
<lazyPower> lamertje - oneliner hack is juju run --service <myservice> "open-port ##"
<lazyPower> o/ magicaltrout
<lazyPower> magicaltrout - i have something i want you to see
<lazyPower> http://i.imgur.com/ABw9G9r.png  - for starters
<magicaltrout> hey lazyPower
<magicaltrout> hehe what you hacking together?
<lazyPower> http://i.imgur.com/IgYlsbl.png
<lazyPower> Thats the running dashboard for TopBeat - which is like distributed HTOP for anything juju deployed (bonus!)
<magicaltrout> oooh
<lazyPower> its also collecting packet data, logs, and docker metrics
<lazyPower> are you interested in having a go with these charms? :)
<magicaltrout> sure am!
<lazyPower> give me a min to tweak perms and upload the core bundle
<magicaltrout> cool
<lazyPower> I'm going to send something to the list on Monday about this :D
<magicaltrout> it'll be cool for my apachecon demo
<lazyPower> magicaltrout - https://jujucharms.com/u/containers/
<lazyPower> beats-core bundle, and all the charms should be there. lmk if you have an issue getting to them
<lazyPower> they are terribly documented, and hot out of a spike, so i'm certain theres dragons in there
<lazyPower> but feedback welcome, if you deploy the kibana out of ~containers, there's an action to deploy the demo dashboard that you see in the screenshot. All the agents self-register upon joining the relationship with elasticsearch
<lazyPower> oh, and i had ot relate them via CLI, as the juju-info relationship thats being used there, isn't represented in the GUI presently. so juju add-relation filebeat:beats-host myservice   and you'll be g2g
 * lazyPower will set aside some time this evening to clean them up and get some proper readme's written
<magicaltrout> okay, i've got 2.something trunkish running with an LXD, lets see how this goes then
<magicaltrout> lazyPower: do you know what the juju 2.0 command to deploy a bundle from the CS outside of the recommended charms is?
<magicaltrout> i tried last week and failed miserably to work it out
<lazyPower> juju deploy ~containers/development/bundle/beats-core
<magicaltrout> interesting
<magicaltrout> I got the first bit and the last bit
<lazyPower> well its devel series :)
<magicaltrout> wouldn't have guessed the middle :)
<lazyPower> when its deemed good enough, i'll pubish it and it wont be devel
<lazyPower> *publish
<magicaltrout> well i needed to know for my own stuff as well, i couldn't find it written down anywhere
<lazyPower> navigate to one of your store listings and its in teh top right corner
<magicaltrout> yeah but thats juju quickstart with a different url
<lazyPower> ah, right
<magicaltrout> lazyPower: kibana failed
<lazyPower> magicaltrout - can you shoot me the unit log?
<magicaltrout> yeah 2 secs
<magicaltrout> looks tivial
<magicaltrout> http://paste.ubuntu.com/15439951/
<lazyPower> weird, thats new
<magicaltrout> dodgy LXD image? ;)
<magicaltrout> next question. I'm in an AirBnB, can you tell me how their TV works? ;)
<lazyPower> Most of the AirBnB's i've been to have a guide for stuff like that by the door.
<magicaltrout> yeah i've heard that rumour
 * magicaltrout looks blankly at the door
<lazyPower> pure schenanigans huh?
<magicaltrout> well, AirBnB charge me Â£50 for using their service, but they use Saiku Analytics for free, so I'm tempted to email them to see if i can get a deduction as I'm using their service which uses my service ;)
<magicaltrout> more time for hacking anyway
<magicaltrout> embedding a bunch more card stuff in various websites tonight
<magicaltrout> trying to advocate juju as the best saiku deployment method
<magicaltrout> i'm looking forward to when you guys get the very top-not secret store stuff done
<magicaltrout> so it handles license purchases for us
<magicaltrout> lazyPower: ping
<magicaltrout> oh well. There is a kibana bug open but the guy submitted a patch which is wrong
<magicaltrout> there is a 1 line LXD fix: https://bugs.launchpad.net/juju-core/+bug/1539806/comments/6
<mup> Bug #1539806: [ARM64][LXD Provider][ 2.0-alpha1-0ubuntu1~16.04.1~juju1] kibana 'hook failed: "install"' <juju-core:Invalid> <kibana (Juju Charms Collection):New> <https://launchpad.net/bugs/1539806>
<magicaltrout> https://bugs.launchpad.net/juju-core/+bug/1539806/comments/7
<mup> Bug #1539806: [ARM64][LXD Provider][ 2.0-alpha1-0ubuntu1~16.04.1~juju1] kibana 'hook failed: "install"' <juju-core:Invalid> <kibana (Juju Charms Collection):New> <https://launchpad.net/bugs/1539806>
<aisrael>    0
<magicaltrout> 0 indeed!
<aisrael> the hazards of spring cleaning
#juju 2017-03-13
<kjackal> Good morning Juju world!
<hoenir> good morning to you kjackal
<kklimonda> is there a way to define, and later reference, variables in a bundle file?
<kklimonda> it's painful to embed gpg key for each and every service
<kjackal> kklimonda: I haven't seen variables in a bundle
<cnf> morning
<kjackal> hi cnf
<cnf> another week, another try at getting stuff to work :P
<cnf> is there any documentation on how to put the juju api behind a reverse proxy?
<alexlist> Hi... just trying Juju-as-a-Service. At the deploy step, 10mins ago I got an option to choose the target public cloud. Now I have this spinning circle and don't get any options to choose. Are we being slashdotted? ;)
<alexlist> I see nothing on Twitter regarding JaaS ...
<rick_h> alexlist: not that I'm aware of. Are there any errors in the JavaScript console? Did you get.to the point to enter credentials?
<zeestrat> kklimonda, kjackal: We've been using variables for a short while now after coming over this example bundle: https://launchpadlibrarian.net/298175262/bundle.yaml
<alexlist> rick_h: I get to the point "Choose cloud to deploy to" but no buttons to choose gce,aws,azure anymore. That worked earlier today. http://pastebin.ubuntu.com/24170595/
<rick_h> alexlist: and this is on jujucharms.com/something ?
<rick_h> alexlist: can you please post a bug at https://github.com/CanonicalLtd/jujucharms.com
<alexlist> rick_h: will do
<rick_h> alexlist: screenshots, urls, etc that would be really helpful
<kklimonda> zeestrat: thanks, that does seem to work :)
<zeestrat> kklimonda: np :) You reminded me that I had should add a bug for docs on that. See https://github.com/CanonicalLtd/jujucharms.com/issues/433
<zeestrat> kklimonda: Came over that example bundle by luck in the #openstack-charms channel I think.
<kjackal> nice zeestrat I did not know you could do that! Cool!
<alexlist> rick_h: https://github.com/CanonicalLtd/jujucharms.com/issues/434
<alexlist> rick_h: I got this far using Firefox. Will restart my Chrome to see if it's something in the cache that stopped me from selecting the cloud provider.
<zeestrat> kklimonda, kjackal: Somewhat related: Passing dynamic stuff (perhaps --config) at deploy time for bundles is on the roadmap according to Rick.
<jamespage> rick_h: hey - aware of any v4 charmstore API type issues?
<jamespage> we just started hitting
<jamespage> https://www.irccloud.com/pastebin/gO5ykMTA/
<rick_h> jamespage: not yet, looking
<beisner> hi all.  Is https://api.jujucharms.com/ --> 'Not Found' a known issue?
<beisner> oh /me sees james just asked here.  thx
<rick_h> beisner: yea, looking. https://api.jujucharms.com/charmstore/v4/~openstack-charmers-next/percona-cluster/meta/any loaded for me
<rick_h> is that loading for you beisner jamespage ?
<jamespage> rick_h: yup
<rick_h> hmm, putting series back in worked: https://api.jujucharms.com/charmstore/v4/~openstack-charmers-next/xenial/percona-cluster/meta/any
<rick_h> I wonder if something flipped...
<beisner> rick_h, yes, but this is not:
<beisner> https://api.jujucharms.com/v4/~openstack-charmers-next/xenial/percona-cluster/meta/any
<jamespage> s/charmstore//g
<beisner> which is the url we get when using bundletester + amulet + theblues + charmstore et al
<rick_h> beisner: oic, with the /charmstore
<rick_h> beisner: jamespage ok, so the /charmstore is supposed to be there. It says what service API to hit. I'm not sure if that changed recently but it kind of worked w/o by accident due to "first thing in the list wins" rules.
<rick_h> beisner: jamespage I'll see if something's changed and if we can get the "magic" behavior back, but we need to file bugs/get tools updated to use the right urls.
<jamespage> rick_h: ack
<jamespage> rick_h: please on restoring magic
<jamespage> rick_h: gate blocked atm
<rick_h> jamespage: working on a cowboy to production to add a rewrite rule atm
<rick_h> jamespage: will try to get it back asap with webops help
<beisner> jamespage, as a work-around, i can have osci set env var for libcharmstore to consume @ https://github.com/juju-solutions/libcharmstore/blob/master/charmstore/lib.py#L37
<beisner> that should unblock on the short term, but we should defo raise an issue @ libcharmstore (i think) to track the real fix
<rick_h> beisner: ty for finding the bad url source. I'll get a PR to them.
<rick_h> RT is filed for the apache redirect, will hopefully get that through soon
<beisner> rick_h, jamespage - raised https://github.com/juju-solutions/libcharmstore/issues/5 -- will have a PR up momentarily to jig that default global URL.
<rick_h> beisner: so there's a default url in theblues that the libcharmstore should just reuse
<rick_h> beisner: was going to do a pr for it once I get the RT picked up
<beisner> rick_h, cool, i'll hold off, let you drive that.  thx
<cnf> anyone know how to run the juju api behind a reverse proxy?
<rick_h> beisner: jamespage please check it again, cowboy in place
<beisner> rick_h, yeehaw!  and yep, the url works now.  thx
<mbruzek> bdx: is it too early to ping?
<hoenir> juju can add storage to machine with add-storage?
<hoenir> or this options is only with units that support..
<hoenir> this option?
<stormmore> o/ juju world
<bdx> mbruzek: sup
<mbruzek> bdx: I heard you have your own haproxy charm? Is that right?
<bdx> mbruzek: I wish I was that cool
<mbruzek> bdx: I am working on reworking the Canonical Distribution of Kubernetes to use haproxy load balancer instead of nginx. And my experience with haproxy is minimal. Wondering if you had any tips/tricks or advice/pointers.
<bdx> mbruzek: https://github.com/jamesbeedy/juju-layer-lxd-proxy
<bdx> ^ non haproxy based
<bdx> just uses iptables, but that may be what you are referencing
<mbruzek> bdx:  I was misinformed. This charm looks super interesting in its own right.
<bdx> mbruzek: when I was setting up deis, I had to manually configure haproxy to proxy to the deis router/component ports on each of the nodes
<mbruzek> oh maybe that was the intel I got. OK
<bdx> mbruzek: let me see if I can find that for you for reference real quick
<jrwren> mbruzek: haproxy charm is very nice. I got a bit familiar with it. I cna help too if needed.
<cholcombe> can juju deploy centos7 at this point?  i thought it could in the past but i can't seem to find the centos image
<mbruzek> jrwren thanks I might hit you up.
<mbruzek> bdx: I would be interested in the configuration if you could share it.
<bdx> mbruzek: here is an example with multiple frontends and backends ... this (multiple frontend/backend) can be accomplished with the haproxy charm too -> http://paste.ubuntu.com/24171930/
<tvansteenburgh> mbruzek: here's the haproxy config from the revq bundle, in case that helps http://pastebin.ubuntu.com/24171951/
<bdx> mbruzek: I'm currently working on some haproxy relations for one of my apps to accomplish creating the multiple frontend -> multiple backend routing via juju relations, I'll keep you posted when I have something worth sharing
<mbruzek> bdx that would be great. Thanks
<skayskay> is there a way to remove a resource?
<jrwren> no. there is no way.
<skayskay> ouch. so, if I have a charm that uses the snap layer, and I've attached a snap so that I can test the snap before publishing it, then I am stuck using a local file after that and can't go back to using the snap from the store
<skayskay> I want to be able to switch
<skayskay> I'm trying to remove-application and it's not working
<skayskay> I can resort to removing the machine by force, but I should figure out why the application won't go away
<zeestrat> skayskay: Could you try pasting "juju status name-of-your-application --format yaml"?
<skay> zeestrat: it's not in the same state. I gave up and removed the machine
<zeestrat> skay: Gotcha. I've run into such situations where it was stuck upgrading.
<skay> zeestrat: aha, my upgrade step was failing
<skay> zeestrat: I released a new charm to pick up a fix in the snap layer
<skay> zeestrat: what did you end up doing?
<zeestrat> I got hit by #1671428 so I ended up killing the controller. I logged #1671476 for being stuck while upgrading.
<mup> Bug #1671428: deploying with default binding prevents upgrade-charm <juju:Fix Committed by jameinel> <juju 2.1:Fix Committed by jameinel> <https://launchpad.net/bugs/1671428>
<mup> Bug #1671476: destroy-model does not work when charm is stuck in upgrading state <juju:New> <https://launchpad.net/bugs/1671476>
<skay> zeestrat: did you try remove-machine with --force? that seemed to work for me
 * skay adds self to bug
<zeestrat> skay: Not yet. I can give it a go.
<kklimonda> ha, I was just about to report that bug
<Guest20118> I am rendering a list of ipaddress in my charm template
<Guest20118> I want the rendered output to be like this servers = ["192.168.1.252", "192.168.1.253", "192.168.1.254"]
<Guest20118> I have my template entry like this 'servers = [{{ '\"'~servers|join('\", \"')~ '\"' }}]
<Guest20118> My input.yaml file to 'juju config <application> --file= input.yaml' looks like this
<Guest20118> servers: "192.168.1.252 192.168.1.253 192.168.1.254"
<Guest20118> The rendered output looks like this
<Guest20118> servers = ["1", "9", "2", ".", "1", "6", "8", ".", "1", ".", "2", "5", "2", " ", "1", "9", "2", ".", "1", "6", "8", ".", "1", ".", "2", "5", "3", " ", "1", "9", "2", ".", "1", "6", "8", ".", "1", ".", "2", "5", "4"]
<Guest20118> in the config.yaml it is of type string
<Guest20118> In the charm code i, yaml load it like this servers_list = yaml.load(config.get("servers"))
<Guest20118> What is wrong here?
<Guest20118> Why is very character interpreted a string here?
<Guest20118> Any help is much appreciated
<tvansteenburgh> Guest20118: servers = {{ servers }}
<tvansteenburgh> it's already a list
<tvansteenburgh> Anyone know how to find out in which regions a particular aws instance type is available?
<tvansteenburgh> I'm trying to deploy a p2.xlarge in us-east-1 (juju 2.1.0) controller and I'm getting 'invalid constraint value: instance-type=p2.xlarge'
<tvansteenburgh> Well I just deployed a p2.xlarge into us-east-1 with the AWS console, so I'm not sure why Juju won't do it. :/
<anastasiamac> tvansteenburgh: instance types support was updated in juju 2.1.1
<tvansteenburgh> anastasiamac: Oooh. I was trying to remember if they were baked in or downloaded from somewhere - I guess it's the former.
<tvansteenburgh> anastasiamac: Thanks!
<anastasiamac> tvansteenburgh: it requires manual intervention. but we try to keep on top of it for every new release
<tvansteenburgh> anastasiamac: So there's no way for me to use a p2 instance type w/o upgrading juju?
<anastasiamac> tvansteenburgh: potentially
<tvansteenburgh> anastasiamac: I upgraded to 2.1.1 and get the same error. Any ideas?
<tvansteenburgh> doh
<tvansteenburgh> anastasiamac: I upgraded to 2.1.1 and get the same error. Any ideas?
<anastasiamac> tvansteenburgh: wallyworld might have a better idea if p2.xlarge was added .. m sorry i have issues with my machine atm, can't look at codebase
<anastasiamac> tvansteenburgh: i can confirm a bit later on
<tvansteenburgh> anastasiamac: k thanks
#juju 2017-03-14
<Guest20118> @tavansteenburgh, thanks
<kklimonda> when is 2.1.2 being released? launchpad suggests last friday, but there are no packages I can find
<kklimonda> zeestrat:  looks like I can't reference variables in other variables? I guess that would be cheating ;)
<kjackal> Good morning Juju world!
<zeestrat> kklimonda: Yeah, I tried that too ;)
<cnf> can you register multiple users on one machine with juju?
<cnf> and switch between them?
<kjackal> cnf you can register multiple users on the same controller
<cnf> kjackal: yes, but can I log in to different users on the same local machine
<cnf> using the juju command
<cnf> i don't want to be admin all the time
<kjackal> cnf: I have never seen that
<cnf> hmm
<cnf> and no ACL's either, it seems
<kjackal> you mean do a "juju ssh myapplication/0" and you get a shell that is not a sudoer user
<kjackal> That is an interesting feature. What is the use case you want to serve with this?
<cnf> no, i mean juju register
<cnf> multiple users
<cnf> right now, everything i do with the juju command is as admin
<cnf> have to pick up some guests at reception, brb
<cnf> back
<cnf> kjackal: i basically want to restrict myself when i don't need to be admin
<kjackal> cnf: your juju client can be a non-priviliged user
<kklimonda> I just had juju fail to bring a couple of containers on two machines, with error cannot start instance for machine "0/lxd/15": unable to setup network: no obvious space for container "0/lxd/15", host machine has spaces: "management", "two-ceph-private", "two-ceph-public"
<kklimonda> but that actually worked fine for other units of the same application, and for other containers on the same machine
<kklimonda> (I'm testing 2.1.2 from git right now)
<cnf> kjackal: right, but do i need to delete the admin credentials?
<cnf> or can i swap between them?
<kjackal> cnf: what kind of credentials?
<cnf> kjackal: the admin user you are authenticated with
<cnf> kjackal: now, my juju command is registered as full admin, right?
<cnf> i can destroy models, delete users, etc etc
<kjackal> you can create a juju user (juju add-user) and then grant permissions (eg juju grant myuser add-model)
<cnf> right, i did that
<cnf> but when i want to register it, it says i can't because i am already registered
<cnf> so is the only way to unregister the admin user, and register the new user
<cnf> and when i need admin the other way around?
<kjackal> I ahven't tried to register a juju user with a local user that is already registered
<kjackal> I guess it is expected for juju to complain
<kjackal> can you have a second local user to register with the controller with limited permissions?
<cnf> you mean add a new local user?
<cnf> that's a lot of extra work for this :P
<cnf> maybe i'll set up a docker container or something
<hoenir> can anyone recommand me a charm that supports adding storage?
<kklimonda> ceph and ceph-osd
<tvansteenburgh> hoenir: the postgres charm does
<kklimonda> when juju is deploying containers on MAAS, what is responsible for assigning IPs? I have a reservation for IP range, but Juju still deployed LXD containers with IPs from this range
<cnf> kklimonda: did you have free ip's?
<kklimonda> cnf: I should have 100+ free IPs in that netwokr
<kklimonda> (based on quick math and what MAAS tells me)
<cnf> k
<cnf> i had all ip's in either dynamic or static pool
<skayskay> resources question. I have a snap charm and made a bad assumption about resources as optional things. I thought I could remove a resource. The charm is for a public snap, so I want to grab it from the store.
<skayskay> but when I want to test a change in a fully deployed environment, I'd like to attach a snap resource
<skayskay> that is a bad assumption since I can't remove a resource.
<skayskay> so, how do people normally test things in that situation? I'd rather not push a candidate snap if I'm doing something like adding debugging code to get more info, etc etc etc
<stub> skayskay: If you are using the snap layer, attaching a 0 byte resource is effectively the same as removing the resource.
<stub> skayskay: You should be able to have your edge charms with a snap attached as a resource, and your stable channel charms with no snap or 0 byte resource.
<skayskay> stub: thanks, I didn't think of attaching a new zero byte resource. I feel sheepish now.
<skayskay> :)
<skayskay> (I am using the snap layer)
<stub> skayskay: Its a hack, but works until we can drop this resources-are-required nonsense.
<Zic> lazyPwr: hey, long time since we didn't talk, I have a question for you (or for marcoceppi too), can I update the nginx-ingress-controller deployed by CDK manually?
<Zic> I need this functionality recently merged: https://github.com/kubernetes/ingress/pull/246/commits/5cc5669938108ab7429bc7eee40c18a6ba18150a
<lazyPwr> Zic: hey, 1 sec let me see whats in teh link
<lazyPwr> Zic: so this looks like k8s golang bin code... do you know if this is landing in the addon container?
<lazyPwr> Zic: if so, you should be able to just update the image reference in /etcd/kubernetes/addons/ingress-*.yml
<lazyPwr> Zic: however, you might need to set it in the Template dir of the charm, so it doesn't get autogenerated right back out of the template before its re-scheduled
<lazyPwr> stub: hey little bit of an update on that btw, i spoke to rick about optional resources @ the last sprint. It's now acknowledged that its a potential issue, but no resolution has been offered as of yet.
<Zic> lazyPwr: the last message is what I feared :( can I do this simply without breaking future updates of the charm ?
<lazyPwr> skayskay: also, one workflow tip that mbruzek and I have done is resource-revision 0 is always a zero byte resource (by convention, we touch and push) so you can always re-publish with a zero byte resource simply.
<Zic> lazyPwr: or do you know if this PR is already in the image used by the kubernetes charm in 1.5.3? I'm always on 1.5.2 currently
<lazyPwr> Zic: certainly if you patch the template and toggle ingress=true it will get your update. on teh next charm-upgrade it will ovewrite the changes to that template and you should be back in alignment with our upstream releases
<lazyPwr> Zic: i'm not positive on if its in the 1.5.3 release, it depends on when it was cut and added.
<Zic> yeah, I saw this PR have 26 days, but I don't know if it was merged for the 1.5.3 release
<lazyPwr> i'm going to err and say it wasn't
<Zic> https://github.com/kubernetes/ingress/pull/246 <= thr PR associated
<lazyPwr> Zic: the trouble here is the issue wasn't attached to a release https://github.com/kubernetes/ingress/issues/180
<lazyPwr> so its hard to discern when it was actually pulled into a release or if its just sitting in trunk
<lazyPwr> Zic: i would probably ping one of the authors of this pr and ask when it was/will-be released.
<Zic> lazyPwr: thanks, also, just seeing the tag "Coverage 46%" in the Issue, seems that it's sure that it's not released so :(
<Zic> I will try to ping the author anyway
<mbruzek> Zic: I can get you a resource if you can examine the binary files to see if the fix is in there.
<mbruzek> Zic: Alternately if you check out the tag branch "v1.5.3"  You could check for the code in there
<Zic> mbruzek: good idea, it seems to be this one: https://github.com/kubernetes/ingress/releases/tag/nginx-0.9.0-beta.2
<Zic> I will check
<Zic> ok so
<Zic> 1.5.2 and 1.5.3 of Kubernetes in CDK's charm both use 0.8.3 of this nginx-controller
<Zic> the proxy-set-headers I need appeared in 0.9.0-beta2
<Zic> (but it's beta as you can see...)
<Zic> but a later stable version is 0.9.2
<Zic> are you planning to switch to 0.9.2 in next release so? :D
<Zic> https://github.com/kubernetes/ingress/releases <= oh, I do a mistake, it's not Nginx which is in 0.9.2, it's GCE ingress...
<Zic> the latest version of nginx-ingress-controller is still 0.9.0-beta.2, which contains the feature I wanted
<Zic> lazyPwr / marcoceppi : for waiting, as I really need to customize nginx header for the launch of this customer, can I simply "kubectl edit rc nginx-ingress-controller", swap the image to "gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.2" instead of "gcr.io/google_containers/nginx-ingress-controller:0.8.3" (which CDK deployed) ?
<Zic> as I understand, nex-upgrade will overwrite this change
<Zic> but I just need to recall myself to re-put it, no?
<Zic> I don't feel confident in hacking the CDK template and deploy it for a production cluster :/
<marcoceppi> Zic: good question, Cynerva ryebot ^ ?
<Cynerva> catching up, gimme a minute :)
<Zic> :)
<Zic> haha, I just realize that I confused marcoceppi & mbruzek for my earlier highlight-ing of CDK's maintainers :)
<Zic> sorry :]
<Cynerva> Zic: it looks like kubernetes-worker won't override the ingress RC until the charm is upgraded
<Zic> and do I need to rollback to the original version of CDK kubernetes-worker charm before the next upgrade ?
<Cynerva> Zic: so I think as a temporary workaround that should work. but i'm not 100% sure
<Cynerva> Zic: hmm good question. all the charm does is `kubectl apply -f ingress-replication-controller.yaml` so i would think you won't have to roll it back before charm upgrade
<Zic> ok thanks
<Zic> I think I will upgrade from 1.5.2 to 1.5.3 before testing this
<Zic> planned for tomorrow, I will let you know if it works :)
<Zic> (the ingress upgrade part, I'm confident for 1.5.3 upgrade part)
<Cynerva> cool :D
 * Zic fix lazyPwr's eyes for the second part of his message
<Zic> :}
<lazyPwr> O_o
<lazyPwr> o_O
 * Zic begins to search "juju rollback command"
<Zic> xD
<lazyPwr> wait for snaps my friend, it'll make your roll forward/backwords life a bit easier.
<lazyPwr> Zic: have you seen the etcd 3.x migration bits using snaps?
<Zic> nop, the last time we talked about this, it was not publicly released
<Zic> s/publicly/officially/
<Zic> does it now?
<stormmore> I still have the the thought about using snaps on switches / routers to load the maas and juju controllers onto them instead of servers
<lazyPwr> stormmore: you're not alone in that thought :)
<lazyPwr> stormmore: however storage on a switch is going to be hairy at best... you'll likely want to run your rack controller on a unit with some storage
<lazyPwr> Zic: its pending a merge against layer-etcd, i have it published in my namespace though
<Zic> oh, I can test it in the lab so :)
<lazyPwr> Zic: it supports moving between channels, and if you dont attach external storage (read: ebs/gce volumes) it'll version your data
<lazyPwr> so say you upgrade to 3.0/stable channel and things get funky, NO PROBLEM!
<Zic> currently, we have deployed our 2nd CDK cluster, full-AWS this time
<lazyPwr> revert back to 2.3/stable
<lazyPwr> and it'll reload your data from the version of the snap that was installed using 2.3, you may incur some minor data loss, but this is expected with a rollback no?
<Zic> and I convert the LXD labs into a real lab
<lazyPwr> yeah?
<stormmore> lazyPwr, yeah I realize that but storage is only a problem when you are a boot strapping the data center. once the servers are up, the db, etc. can be moved into the cluster
<lazyPwr> nice man :) You're getting your hands all kinds of dirty with cdk
<Zic> lazyPwr: yeah, I'm just using NFS & ISCSI volume
<stormmore> lazyPwr, that just leaves the core services running on the switches / routers, i.e. pxe, etc. from maas and the juju controller agent
<Zic> (for the first CDK cluster actually)
<lazyPwr> Zic: i was talking to cholcombe and it appears that gluster+heketi is going to be problematic moving forward
<lazyPwr> some mailing list drama popped up about this :/
<Zic> for the second one, we're using AWS-EBS
<lazyPwr> i read into it a bit, and they are wanting to not support existing glusterfs deployments, which baffles me
<cholcombe> i find it odd also
<Zic> (the first-one is the one I gave you the Architecture Plan, hybrid between baremetal servers / on-premise VMs & EC2@AWS)
<Zic> (the second-one is full-AWS)
<lazyPwr> cholcombe: <3 can we send them a gentle reminder to not stab their users in the face with a hot branding iron?
<cholcombe> i tried on the irc channel and they shot me down
<lazyPwr> because $reasons again?
<cholcombe> yeah because deploying onto an existing server that they didn't setup is hard
<cholcombe> i get it but at least try
<lazyPwr> so what if we dont support existing clusters and instead make it a charm deployed glusterfs endpoint the only one we support in cdk?
<lazyPwr> or am i missing something
<lazyPwr> i dont think its out of the question to have a storage admin provision some bricks and enlist them in a gluster charm deployment, then xmodel relate them to cdk workers
<magicaltrout> lazyPwr: http://pastebin.com/E4ZrqzNN
<magicaltrout> http://pastebin.com/ewUELFwT
<magicaltrout> got any suggestions?
<cholcombe> lazyPwr: suggesting we just take over for heketi?
<lazyPwr> magicaltrout: how did you deploy this?
<magicaltrout> maual
<magicaltrout> manual
<Zic> lazyPwr: basic question, does the "juju upgradecharm <app>" have a special order recommended? because between the insights.ubuntu.com news and https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/, it's not the same
<lazyPwr> Zic: follow the kubernetes.io docs
<Zic> upgrade-charm*
<magicaltrout> just walked through the bundle
<Zic> ok :)
<lazyPwr> we've kept that up to date
<lazyPwr> magicaltrout: are these local copies of the charms?
<magicaltrout> nope
<magicaltrout> i've got 2 running workers and 2 stalled
<lazyPwr> magicaltrout: well at the end of teh day it appears the resources didn't make it out of the charm store. You'll want to fetch the resources from jujucharms.com/u/containers/kubernetes-worker and juju attach them
<Zic> At this time rolling back etcd is unsupported. / At this time rolling back Kubernetes is unsupported. <= you already prepare this section about snap :D
<lazyPwr> Zic: not until it lands as GA
<lazyPwr> but yeah, i'll be adding subsections there about rollbacks using the snaps and what to expect
<Zic> the only snap-in-production that I used today is Rocketchat
<lazyPwr> Zic: i'm expected to have this fully landed and r2g by the time we cut the 1.6.x release
<lazyPwr> i've got some really good early tests in, i'm hacking on fixing the whole "i killed the master and my cluster just pooped the bed" bug
<Zic> :}
<lazyPwr> which is really obnoxious if you're not paying attention to what you're doing... juju remove-unit etcd-master, and suddenly things brick
<lazyPwr> *sadtrombone.wav*
<Zic> I need to switch to multimaster again some day also
<Zic> I'm also on monomaster in production for now
<Zic> the lab is in multimaster with your patch for token
<lazyPwr> Zic: we have incoming work rn to hack in place an haproxy load balancer instead of that nginx based one
<lazyPwr> my colleague is hacking on that rn
<lazyPwr> magicaltrout: lmk if that doesn't resolve it, and i'm going to point a finger at a juju bug that i hvaen't found yet, but it seems like it just bailed during grabbing the resource, which is unfortunate :( i've seen this once before but it was back in the 2.0 beta days
<lazyPwr> magicaltrout: actually, are you still using a beta or did you finally upgrade to GA?
<magicaltrout> thanks lazyPwr testing
<magicaltrout> this is a new deploy for the  JPL folks so nothing beta here :)
 * lazyPwr snaps
<magicaltrout> 2.0.2
<lazyPwr> i was kind of hoping you would say beta-18 again, so i could easily point to why it happened
<magicaltrout> it might have been connectivity betwen the openstack units and the charm store, but it would be nice for juju to recover if that were actually =the case
<ybaumy> huhu juju
<ybaumy> can somebody tell me how to filter hosts to use for a cloud by zones in maas
<ybaumy> i tried adding zone = foobar to the yaml file for the cloud
<ybaumy> but that didnt work
<andrew-ii> If a MAAS node is released while it is a Juju controller... can I get that controller removed? It seems hung on `juju destroy-controller someController`
<ybaumy> have you tried unregister
<andrew-ii> Not yet... one moment
<andrew-ii> oh
<andrew-ii> Well, that was fast.
<ybaumy> did it work
<andrew-ii> Thanks! I think I can rebootstrap it now
<ybaumy> yes you can
<ybaumy> had a similar problem and that helped me too
<ybaumy> do you happen to know how to filter maas nodes for a cloud by zones?
<ybaumy> i need to know if that is possible
<andrew-ii> oh man, I am barely getting this thing to download images from ubuntu's cloud repo
<andrew-ii> I vaguely remember that... one sec
<andrew-ii> Nuts, that's next on my list of things to try
<andrew-ii> That's what works with the HA zones, right?
<ybaumy> well i want to create nodes for customers and add them to zones. then create a cloud for that particular zone
<Zic> lazyPwr: I have a lot of apt updates also on the 1.5.2 cluster I'm planning to upgrade tomorrow, do you advice me to firstly run juju upgrade-charp <app> *before* apt update/upgrade ?
<Zic> (to bypass some problem like the time apt upgrade etcd without the charms :/)
<andrew-ii> ybaumy: I was going about that upsidedown and was going to use Openstack to partition customers. But you make an interesting point; if I had my old pile of blade servers that sounds pretty good
<magicaltrout> okay i think we can safely say Juju doesn't like deploying stuff to low power vms
<ybaumy> andrew-ii: a customer should be able to create his own cloud by a webinterface with vmware and maas. that the target.
<andrew-ii> I don't have vmware, but my customers really only need containerization, so I probably have a different use case
<ybaumy> andrew-ii: true. thats different. i have thought about that too. and will look into it once i am able to do that ..
<ybaumy> im creating POC's for my company
<ybaumy> so its just try and play at the moment
<andrew-ii> ybaumy: I get the feeling it's jumping right into the deep end to go straight-up containerization. But I only have a few machines for maas, so I can't afford to dedicate to each customer. But man, that sounds like a nice idea.
<andrew-ii> ybaumy: same here; if I can get the cloud bootstrapped and somehow lock it down _and_ get it to be usable, then it'll be a nice playground.
<ybaumy> andrew-ii: we have vsphere vrealize scripted to create the vm templates and distribute them across the esx farms. then i use maas to commission them and juju to create the cloud
<ybaumy> but now i need something to filter those vm's
<andrew-ii> ybaumy: slick. It does sound like zones are exactly what you'd want (if I understand why they were added).
<ybaumy> andrew-ii: yes its really working now. its one last piece to put it together and close the POC
<andrew-ii> Best I can figure is the `juju deploy someCharm --to zone=maasZone1`, but I bet you're not really looking to use the --to command
<ybaumy> andrew-ii: does that work?
<ybaumy> i have to try
<andrew-ii> (For my setup I'm using maas tags to filter machines, sadly, so I may be a terrible example)
<andrew-ii> ybaumy: note that I just sorta stole that command and assumed it worked! It may be aws specific (or maybe maas emulates that too) - sorry if it fails utterly
<ybaumy> andrew-ii: great this seems to work. at least it used now for bootstraping the foobar zone i specified
<andrew-ii> ybaumy: holy mackeral, whelp, I'm more optimistic now (I actually thought it'd fail...).
<ybaumy> maybe its luck but i will try that a few times
<andrew-ii> That's the spirit!
<lazyPwr> magicaltrout: yeah it tends to yield a pretty crummy experience when you starve the unit resources
<lazyPwr> Zic: probably do the upgrade charm then run the apt update/upgrades
<lazyPwr> Zic: keep your change set to the least viable change in order to validate things are functional after making the change
<ybaumy> andrew-ii: sadly this --to zone= seems to be ignored. i bootstrapt it then i wanted to enable-ha --to zone=foobar and one node was created in default one in foobar
<magicaltrout> indeed lazyPwr i was hoping the units would at least start though :)
<ybaumy> so i need something else
<andrew-ii> ybaumy: sorry - I was afraid it wouldn't work with maas yet
<ybaumy> andrew-ii: thanks anyway .. better die trying then havent tried at all
<andrew-ii> Might be worth checking if a newer version manages to use it (though I think I got that command from 2.1.1)
<ybaumy> im using devel
<andrew-ii> ouch, nevermind then
<andrew-ii> Did you try `--constraints zone=foobar` ?
<ybaumy> hmm no :D
<ybaumy> will do
<ybaumy> hehe
<andrew-ii> I have some real goofy machines to play with, and some are only good at certain things (like one's basically a bank of hard drives), so I use `--constraits "tags=storage"` for that one
<ybaumy> what is your goal what are you trying to accomplish?
<andrew-ii> Though just in case, make sure when boostrapping a controller you use `--boostrap-constraints` instead (otherwise the controller sets ALL nodes to use that constraint)
<ybaumy> k
<andrew-ii> I have a hodgepodge of random servers to play with, and I need a test rig that can simulate a network; plus host some in-house tools that will get replaced often
<andrew-ii> Literally random machines collected off craigslist for a few months
<ybaumy> is that you homelab?
<ybaumy> your
<andrew-ii> It's my equipment, but it's hosted in the office for it's fancy 220V line, space, and dedicated network connection
<ybaumy> i started also with some few blades but now the project has management attention
<ybaumy> so i got everything i requested
<ybaumy> that neat
<andrew-ii> haha always the best when people with checkbooks take notice
<ybaumy> true
<ybaumy>  juju deploy --to zone=test cs:bundle/openstack-base-49
<ybaumy> ERROR Flags provided but not supported when deploying a bundle: --to.
<ybaumy> also something that should work
<andrew-ii> hmmm, yeah, that's what I thought to try
<ybaumy> i will try single charms to see how that goes
<ybaumy> nope ignored as well
<ybaumy> juju deploy --to zone=test -n4 cs:ubuntu-10
<ybaumy> creates random machines in all zones
<ybaumy> i will try tags
<andrew-ii> That should work, though it's a pain to tag all the machines
<ybaumy> yep
<ybaumy> seems like that you cannot assign tags to all machines in a zone
<andrew-ii> Nuts. Need to do something complicated like a script to assign them all? (Overkill maybe?)
<ybaumy> you are right. i will have to script it but thats not the problem. it would be nice if something like that would be supported out of the box
<andrew-ii> I think there is a goal for it, it's just not added in yet?
<ybaumy> we have to ask the devs
<ybaumy> i signed up on the mailing list maybe i get an answer there
<andrew-ii> ybaumy: I don't know too much about navigating launchpad, but check https://launchpad.net/juju to see if that feature is slated for addition
<ybaumy> juju deploy --constraints tags=test  cs:bundle/openstack-base-49
<ybaumy> ERROR Flags provided but not supported when deploying a bundle: --constraints.
<ybaumy> ;)
<zeestrat> ybaumy: 99% sure --constraints/--to don't work with bundles
<zeestrat> ybaumy: same with --config
<ybaumy> zeestrat: thats too bad. shouldnt they?
<zeestrat> --config is on the roadmap
<ybaumy> single charms work now with contraints with tags thats nice so i have to script the whole bundle setup as single charms
<zeestrat> constraints and to are (or at least can be) defined in the bundle so the idea is that you set them there
<ybaumy> ok so i can generate a yaml file with --contraints?
<ybaumy> the format with all the : at the end is really hard to script
<ybaumy> hmm
<ybaumy> i will try and see
<zeestrat> have you checked out https://jujucharms.com/docs/stable/charms-bundles ?
<ybaumy> before not. but i can just generate it one time and then use perl or sed to change the tags=test to tags=somethingelse
<ybaumy> nice
<ybaumy> :)
<ybaumy> thanks zeestrat
<ybaumy> that will do
<zeestrat> ybaumy: glad to help :) There are no examples of using variables in the docs at the moment, but here's a openstack HA bundle you can look at: https://launchpadlibrarian.net/298175262/bundle.yaml
<ybaumy> no need for variables. i just sed -i 's/tags=test/tags=somethingsomethign/g' in the file for each process before i start juju deploy bundle.yaml
<ybaumy> and thanks for the HA link
<ybaumy> will try tomorow. now football
<stormmore> lazyPwr, trying to put together my budget ask, is there any conference, etc. that would be good for me to try and attend? any suggestions?
<magicaltrout> all of them \o
<ybaumy> zeestrat andrew-ii adding constraints to the bundle works. thanks for helping me.
<stormmore> magicaltrout, yeah I wish I could get the budget for that :-/ I have to be more realistic than that and target kubernetes, juju, maas related ones as well as the automotive ones since that is the industry we are actually in
<magicaltrout> hmm wtaf, my deployment is green but the ingress proxy just gives me a 504 on  absolutely everything =/
<magicaltrout> what country you in stormmore ?
<hatch> can a 'requires' relation be related to two 'provides' at the same time?
<lazyPwr> stormmore: well, the charmer summit is great if you want facetime with us to hack on projects :)
<hatch> ex) kibana1 to elasticsearch1 and kibana1 to elasticsearch2
<lazyPwr> stormmore: however if you want k8s focus, you're more than likely going ot have success attending kubecon's but our presence there isn't very big. Mostly what I would call guerilla community ops, where we roam hallway tracks and find people to engage with
<lazyPwr> hatch: depends on how the charm is coded to use those relationships, but yeah.
<hatch> lazyPwr ok so there is no Juju restriction to that effect?
<lazyPwr> interfaces as the abstraction, you should be able to interface with both es clusters, but its up to the app to implement that, and up to the author to correctly implement the data coming from the interfaces.
<lazyPwr> afaik, nope
<hatch> the GUI explicitly prohibits that interaction
<lazyPwr> why?
<lazyPwr> seems....arbitrary
<hatch> my guess, a limitation in Juju 1?
<lazyPwr> kidna like not letting me unrelate a subordinate :P
<lazyPwr> yeah, you're probably right
<hatch> or from PyJuju even?
<lazyPwr> juju1 had fun quirks like that
<hatch> yeah
<hatch> ok thanks
 * hatch creates a model on jujucharms.com to test for sure
<stormmore> lazyPwr, yeah I would love to go to a "charmer summit" but I don't see another one setup yet
<lazyPwr> stormmore: i dont think we'll get it scheduled until mid spring.  jcastro might have more details as to when the next summit will be however
<jcastro> we haven't really talked about it
<magicaltrout> somewhere hot
<stormmore> and of course finance want to know like yesterday :-/
<stormmore> lazyPwr, fyi I think the better question is whether you guys want to suffer the pain of meeting me ;-)
<magicaltrout> any idea how to debug a 504 on the ingress router, no kubernetes dashboard etc lazyPwr ?
<stormmore> @jcastro, I will look forward to hearing about when you do have those discussions
<jcastro> \o/
<skayskay> hey, trying to remove a unit that is in an error state for the config-changed hook doesn't work, as far as I can tell
<skayskay> there's ab ug about a failing upgrade state that already exists, maybe this is related
<skayskay> oh, this may be something else. lp:1671476 is about destroying a model
<skayskay> I'm unable to remove a unit or application
<magicaltrout> you need to mark the unit resolved first skayskay
<magicaltrout> juju resolved unit/0 --no-retry
<skayskay> magicaltrout: thanks! that's it. I didn't know about that --no-retry option. handy
<firl> hello all; anyone have an example bundle of openstack using network spaces ?
<magicaltrout> oooh shiugar
<magicaltrout> sooo lazyPwr i'm not convinced that each k8s worker should be on its own flannel subnet, am I right?
<stormmore> this is really odd, having it hang during fetching juju agent
<stormmore> I suspect a network issue but I can't log into the instance using the key that I added to the MaaS user! hmmmm
<lazyPwr> magicaltrout: why not?
<magicaltrout> okay in that case i'm just wrong :)
<magicaltrout> i assumed they had to share a subnet
 * magicaltrout returns to wondering why they aren't working
<stormmore> magicaltrout, no each worker needs it's own subnet to manage it's containers with
<magicaltrout> fair enough
<magicaltrout> i'm spinning one up on aws for comparison, but i assumed they'd be on the same subnet. Obviously not :)
<stormmore> anyone have an idea where to look when I can enlist and commission nodes in maas but I can't bootstrap juju?
<rick_h> stormmore: juju bootstrap --debug and then check the maas logs during bootstrap.
<stormmore> rick_h, thanks, I keep forgetting about that. building a "clean" environment to try again
<zeestrat> firl: The #openstack-charm people have a bundle in their dev repo: https://github.com/openstack-charmers/openstack-bundles/blob/master/development/openstack-base-spaces/bundle.yaml
<firl> zeestrat thanks!
<zeestrat> firl: There's a OpenStack HA bundle laying around using networks defined in config (not the new juju network bindings): https://launchpadlibrarian.net/298175262/bundle.yaml
<firl> interesting
<firl> I am trying to figure out the best way to do the networking I need to, and I just finished configuring all of the physical net, so trying to make sure I have MAAS setup the way I Want to deploy the bundle
<firl> it seems like âspacesâ is where the bundles are going
<firl> charms rather
<zeestrat> firl: I recommend checking out #openstack-charm channel as well. I'm working on a HA bundle with spaces if you're interested. Send me a pm and I can get back to you
<firl> I will jump on that channel too
<firl> hrmm no one in that one.
<zeestrat> firl: sorry, #openstack-charms
<firl> perfect
<zeestrat> there are also some docs on https://docs.openstack.org/developer/charm-guide/ with release notes for the latest stable releases of the openstack charms
<zeestrat> I'm off for now, but pm me and I can get back to you
<firl> thanks
<stormmore> rick_h, http://paste.ubuntu.com/24179043/ shows the output from --debug, I am not seeing anything obvious in the regiond.log, rackd.log or the instance messages log to show why it isn't bootstrapping :-/
<stormmore> rick_h, but this time I was able to log in, apparently I am missing a default gateway
<stormmore> rick_h, which seem odd considering it did a apt update / apt dist-upgrade
<stormmore> one problem down, no telling how many to go :-/
<stormmore> gotta love weird networking issues
#juju 2017-03-15
<Budgie^Smore> miss me?
<xavpaice> anyone here using juju-deployer with 2.1 and spaces?
<kklimonda> how can I list bindings for the deployed application?
<kjackal> Goog morning Juju world!
<kjackal> kklimonda: by bindings you mean relations?
<kklimonda> kjackal: with 2.1, I have to bind all my containers to spaces, and it's failing randomly - I'm trying to understand what spaces did the unit request, and failed to get
<zeestrat> kklimonda: Yeah, there's not a lot of visibility at the moment. I created #1672997.
<mup> Bug #1672997: Missing overview over charm bindings <juju:New> <https://launchpad.net/bugs/1672997>
<cnf> hmm
<cnf> how do i get juju to reprovision a machine?
<cnf> one machine failes to come up, and juju just stops :/
<cnf> retry-provisioning maybe...
<cnf> no, that doesn't seem to do anything
<cnf> hmz
<cnf> juju really doesn't seem to like machines not doing the right thing
<cnf> :/
<disposable2> cnf: hmmm... i see you still haven't given up on your juju powered openstack dream.
<cnf> disposable2: i'm close to giving up
<cnf> it really should not be this difficult
<disposable2> cnf: same here. while i'm still allowed to continue testing, my management will not allow me to use this in production. primarily because of all the guesswork involved. the absence of proper documentation is the showstopper. this is the 3rd time over last 5-6 years i've tried using maas/juju for something and it just isn't improving. there are still no books, there are still no useful manpages, no useful examples/howtos.
<cnf> yep
<cnf> while i'm the one deciding, not management :P
<cnf> i'm very much advising NOT to use it, at this point
<cnf> i'm trying to find out how to replace a failed node
<cnf> and i can't found out how to do this
<cnf> o,O
<disposable2> cnf: well, i wish i could help you.. did you ever find out whether MAAS needed to be aware of all the networks juju was going to use?
<cnf> no
<jamespage> cnf: disposable2: reading backscroll a bit then I'll try answer some of your questions
<jamespage> cnf: re your failed provisioning of a machine - as a workaround try juju remove-machine --force <ID of machine>
<jamespage> and then re-add the application units that removes using juju add-unit
<cnf> i didn't, i added a bundle
<jamespage> that's a bit of a workaround but I agree that retry-provisioning should dtrt there
<jamespage> disposable2: cnf: on the query re MAAS needing to be aware of networks juju is going to use - yes that is the case; MAAS holds the underlying map of actual servers, network fabrics, vlans etc...
<cnf> how do i see what units are running on a machine?
<jamespage> cnf: lemme check that
<cnf> also, juju should have a migrate function, or something similar
<jamespage> cnf: hmm other than 'grep' I can see a nice way to figure out services -> machine mapping for a specific machine
<cnf> hmz
<jamespage> cnf: that said juju deploy <bundle> should figure out what's missing a re-add it if you run it again
<cnf> i'm trying to get cs:bundle/openstack-base-49 working
<jamespage> cnf: ok so juju remove-machine --force <ID> the failed machine
<jamespage> cnf and then juju deploy cs:bundle/openstack-base-49 again
<disposable2> jamespage: does that maintain state? i.e. bring up the missing machine with the configuration the previous machine had (if the configuration was done via juju)
<cnf> and now to wait 15 minutes
<cnf> (HP servers are slow to boot)
<jamespage> cnf: I can related to that... esp if they have lotza different cards in them
<cnf> i also need to figure out how to force the use of specific machines or maas tags for specific services
<cnf> ugh, and now MAAS is being difficult
<cnf> >,<
<cnf> (retry-provisioning  seems to do nothing at all, ever, btw)
<cnf> jamespage: i do apologise for the frustration leaking through
<cnf> i have been at this for a while
<cnf> wow, juju doesn't even see the machine coming up, now...
<cnf> o,O
<cnf> maybe i'm doing something wrong, but it seems impossible to actually get anything working reliable with juju :(
<cnf> "message: agent is not communicating with the server" ...
<disposable2> cnf: well, at every single FOSDEM, marco ceppi demonstrates deploying and scaling up wordpress. so i'd guess at least that has had all its bugs ironed out.
<cnf> wordpress is the last thing i care about :P
<disposable2> then again, on my computer even that fails setting up the mysql server.
<junaidali> cnf: I'm also a juju user and alot of improvements came up recently in juju 2.X. are you facing this issue with a specific machine?
<cnf> no, in general
<cnf> a machine failed because i did something silly
<cnf> but getting juju to recover has been a pain
<cnf> (among all the other issues)
<junaidali> is that machine now in 'deployed' state in MAAS?
<junaidali> which has the status in juju "message: agent is not communicating with the server"
<cnf> deploying
<cnf> HP machines take a LONG time to boot
<cnf> oh, it was deployed when it showed that
<cnf> i removed it (again) and ran juju deploy cs:bundle/openstack-base-49
<junaidali> btw when the status is 'deployed' in MAAS, it means the machine is now provisioned. Then juju will install some packages and deploys the charm that we specified.
<junaidali> charm/charms*
<cnf> uhu
<cnf> i expect it to go to "pending" shortly after maas says "deployed" though
<cnf> not sit at down for 10 minutes
<cnf> at least it is at pending, now
<junaidali> machine status in juju goes to pending as soon as we run the bundle, which eventually changes to 'started' after the 'deployed' status in MAAS
<cnf> we'll see how that goes
<cnf> junaidali: yes, except it wasn't :P
<cnf> so i had to remove the machine, again, and deploy, again
<cnf> which takes 15+ minutes, again
<junaidali> what are the specs of these hp machines, for me it usually takes <10-12 mins even with a slow internet
<cnf> this is one of the slowest ones
<cnf> 32 cores, 96G ram
<cnf> hw boot always takes a long time on HP servers
<cnf> i'll wait until juju debug-log quiets down
<cnf> i do find it troubeling how hard it seems to replace hardware with juju
<cnf> well, "hardware", "a machine instance"
<junaidali> Getting started with juju is not very helpful due to the docs but once we spend some time, imo it turns out to be a great tool
<cnf> plausible, but i'm struggling figuring out how to use it properly
<disposable2> junaidali: there won't be much adoption if there's no good documentation.
<junaidali> I second ya disposable2
<cnf> and if this gets deployed in production will be largely based on my reccomendation ^^;
<cnf> just finding the right juju command is hard o,O
<junaidali> yes, its not easy for a newbie
<junaidali> and this is due to the documentation
<cnf> i'll admit i also need(ed?) to figure out MaaS at the same time
<cnf> and some of my problems is me doing silly stuff with maas
<cnf> hmz
<cnf> k, i think everything came up?
<cnf> but openstack is in full error mode
<cnf> but that will have to be for after lunch
<junaidali> cnf: what is the output of juju status ?
<cnf> ceph-osd blocked, neutron-gateway in error
<cnf> http://termbin.com/uk1p
<cnf> k, i need a short break, and some food :P
<cnf> bbl, thanks for the help so far
<junaidali> cnf: ok, ssh to neutron gateway (juju ssh neutron-gateway/0) and share output of /var/log/juju/unit-neutron-gateway-0.log
<junaidali> when you are back :)
<junaidali> i think the issue is most probably due to the neutron-gateway config "bridge-mappings" which you should update as per your environment
<stub> Mmike: I think we already have your mongodb changes in the git branch at https://launchpad.net/mongodb-charm. Its got everything up until March 6th, including your patches from January and February
<stub> Mmike: (I've responded to your email)
<jamespage> junaidali, cnf: yup due to slot based naming, we can't write a bundle atm that just works everywhere - you'll need to set the data-port value according to your server wiring
<stokachu> junaidali: and there is always http://conjure-up.io
<zeestrat> Anyone got an example file of a yaml file formatted as a string so it can be inputted as config for a charm?
<tvansteenburgh> zeestrat: http://pastebin.ubuntu.com/24171951/
<tvansteenburgh> zeestrat: lines 11-26 are string-formatted yaml
<rick_h> Reminder Juju Show #8 this afternoon: https://twitter.com/mitechie/status/841997038808125441
<zeestrat> tvansteenburgh: Thanks, managed to sort it out I think.
<zeestrat> tvansteenburgh: P.S. The syntax for the ssl_keys have me intrigued. Where does that include-base64:// come from and is it native juju?
<cnf> ok, back
<cnf> junaidali: and juju ssh neutron-gateway/4, it seems...
<tvansteenburgh> zeestrat: No, I think that's a juju-deployer thing
<cnf> and it can't find eth0
<cnf> makes sense
<cnf> jamespage: that was my next question, the bundle seems to not take care of networking / disk storage well
<cnf> how do i deal with this?
<junaidali> cnf: sorry, you need to update data-port instead of bridge-mappings in the bundle
<cnf> uhm
<cnf> how do i do that?
<junaidali> now as the charm is deployed, run $juju config neutron-gateway data-port="br-ex:<external-interface-name>"
<junaidali> external network interface*
<junaidali> stokachu: nice, I looked at it a few days back. I will surely check it
<cnf> hmm, i should sort out the networking for openstack, and how it relates to juju, i guess
<cnf> (and maas)
<cnf> as a side note, can I create links between models in juju?
<rick_h> cnf: that's in development atm
<cnf> hmm, ok
<cnf> i'm not very comfortable putting all of ceph and all of openstack on the same model
<cnf> k, adding some vlan's on the qfabric
<cnf> junaidali, jamespage so I need to configure the openstack network in MaaS before i deploy the juju components?
<cnf> no way to add it afterwards?
<rick_h> cnf: no, MAAS is kind of the 'state of existance' and MAAS only ingests data in there when the machine comes up. So Juju can't rely on changes made afterwards in MAAS
<cnf> right
<cnf> and juju can't set ip
<cnf> and mount disks either, right?
<cnf> so, then how can I get juju to pick certain machines when i deploy things?
<cnf> because not all machines should have ip's in all networks, for example
<cnf> or not all machines have big storage for ceph etc
<zeestrat> cnf: Check out machine constraints: https://jujucharms.com/docs/stable/reference-constraints
<cnf> zeestrat: yeah, so that;s on cpu and ram etc, but network spaces only work on ec2?
<rick_h> cnf: the networks are meant to be handled by defining spaces and then using the endpoint binding in charms so that you can tell ceph to get a management network interface on network X, a data transmission interface on network Y, etc.
<cnf> and i don't see a way to use raw disk space?
<rick_h> cnf: heh, network spaces work in maas better than ec2
<cnf> oh, ok
<rick_h> cnf: what do you mean by "raw disk space" ?
<cnf> docs say "EC2 is the only provider supporting spaces constraints. Support for other providers is planned for future releases."
<cnf> ok, so i'll have a look at spaces
<rick_h> cnf: you can constrain based on disk space available and then do some stuff with https://jujucharms.com/docs/2.0/charms-storage
<cnf> rick_h: so ceph doesn't want a raid5 partition, it wants just raw disks
<cnf> well, ideally
<rick_h> oic, hmm. You can specify size and such, but not sure if there's a way to read that level of data about a disk to decide if the machine is ideal or not.
<cnf> so you'd want ceph to deploy to the machine that has 10 x 2T of disks
<rick_h> cnf: I think folks tend to tag their machines they want for storage, as you mention, they tend to be phyically different and setup specifically for that purpose
<cnf> yeah, indeed
<cnf> ok, i'll focus on networking first
<cnf> so atm all my networking in maas is in space-0
<cnf> because i didn't get what they where for
<rick_h> cnf: yea, they take a second to get around
<cnf> hmm, especially the vlan , fabric , spaces thing is a bit weird
<cnf> i still don't quite get the distintions
<cnf> distinction
<rick_h> cnf: https://jujucharms.com/docs/2.1/network-spaces hopefully helps
<cnf> yeah, i have that open together with https://docs.ubuntu.com/maas/2.1/en/intro-concepts
<rick_h> so spaces are any group of subnets that are routable and have similar ingress/egress rules. e.g. juju can help spread workloads across subnets in this space and it'll work out.
<cnf> "that are routable" ?
<cnf> among themselves, you mean?
<rick_h> cnf: yes, within that space
<cnf> ok
<rick_h> cnf: so if I deploy 10 of something and they get on different subnets it's important to know they'll still be able to behave in the same way
<cnf> right
<cnf> and how do spaces and fabric differ?
<Zic> lazyPwr / mbruzek : hi, just to let you know, my upgrade of CDK in production from 1.5.2 to 1.5.3 was successfull, I just encountered a little "bug" at "juju status"-side, master was stuck at: kubernetes-master/0*      waiting   idle   2        mth-k8smaster-01           6443/tcp        Waiting for kube-system pods to start
<Zic> but pods of kube-system namespace was in fact Running
<Zic> I waited some minutes with no evolution, so I just restarted the juju controller VM and went it was back online, all was simply green/idle
<mbruzek> great
<mbruzek> Zic: We are interested in feedback if you have any thing we can improve
<cnf> rick_h: also, can an ipv6 and an ipv4 subnet be in the same space?
<cnf> or would juju / maas expect 2 spaces for them?
<stormmore> o/ juju world
<ybaumy> maybe somebody here can help
<ybaumy> why is that if a disable proxy arp on a interface intervlan routing doesnt work anymore?
<ybaumy> disable on the asa firewall which is also a router
<lazyPwr> \o stormmore
<stormmore> hows it going today lazyPwr
<lazyPwr> stormmore: still feeling poorly so I'm trying to keep on trucking
<stormmore> lazyPwr, I feel you there... took me a couple of hours yesterday to figure out that I was having routing issues
<lazyPwr> ahh networking, so fun :)
<stormmore> lazyPwr, ain't that the truth! :P hence why I have asked if we can hire a network engineer ;-)
<stormmore> oh and type MASS instead of MAAS definitely doesn't help
<stormmore> lazyPwr, was troubleshooting why juju bootstrap was hanging at fetching the juju agent even though it could do apt update / apt dist-upgrade
<lazyPwr> stormmore: ah that seems...fun?
<lazyPwr> what was the trouble?
<stormmore> lazyPwr, my MaaS server isn't masquerading the traffic right
<stormmore> lazyPwr, it is basically to do with the fact that the maas server has multiple NICs and I choose the "wrong" one to be the outbound
<lazyPwr> aaahhh that'll do it
<lazyPwr> wrong gateway and all that fun business
<lazyPwr> i would have thought that you'd have seen that much earlier though like when doing a single unit validation on just the maas setup
<stormmore> lazyPwr, yeah I would have too
<stormmore> lazyPwr, but I could do enlistment and commissioning... even most of the initial deploy install before it failed
<lazyPwr> heh
<lazyPwr> gremlins man
<lazyPwr> i hate it when its intermittent like that, because its only 10k times harder to debug
<stormmore> yup true dat!
<lazyPwr> glad you got it sorted though, i dont know that i would have been much help in that scenario
<lazyPwr> "did you try turning it off and on again?"
<stormmore> it isn't quite sorted, I know what the issue is but I am trying to decide which path to use to fix
<stormmore> the problem is if I change the NIC then the traffic is going to be double nated, so I am currently attempting to change the default gateway to go out to the not NAT NIC
<stormmore> I think people seem to forget that there is sometimes reason to set a gateway address on each interface!
<rick_h> juju show hangout url:  https://hangouts.google.com/hangouts/_/75g7b4wrhvgfff66e6howu2dlqe
<rick_h> juju show viewing url: http://youtu.be/tjp_JHSZCyA
<rick_h> marcoceppi: lazyPwr arosales bdx and anyone that wants to join ^
<stormmore> patiently waiting rick_h
<rick_h> stormmore: wheeee
<stormmore> not if I could come up with a non-"hackish" way to solve my gateway problems
<stormmore> now*
<stormmore> oh rick_h btw I don't believe in best practices per say ;-)
<rick_h> stormmore: fine, "somewhat potentially nice to have practices" :P
<rick_h> externalreality: you can join as well ^
<rick_h> perrito666: ^
<rick_h> if any core folks want to join in
<stormmore> rick_h, yeah that is a bit better phrasing, I just like to push the limits of the tools to the max
<rick_h> stormmore: I'll update it for you
<rick_h> ok, going once ... before we start
<jrwren> ooh, i'm back JUST in time for the show
<zeestrat> Any date on 2.1.2?
<zeestrat> Hit some binding bugs in 2.1.1
<stormmore> I really should look at snaps
<jrwren> lazyPwr: link?
<lazyPwr> https://jujucharms.com/charmscaler/
<jrwren> lazyPwr: WOW!!!!
<lazyPwr> jrwren: ikr? :)
<stormmore> lazyPwr, CDK ftw on that :)
<lazyPwr> stormmore: interesting times indeed :) we're getting more features thanks to our great community
<stormmore> lazyPwr, oh and that is what is awesome :)
<stormmore> lazyPwr, I wouldn't mind having the juju data in the same grafana as the k8s stuff
<lazyPwr> i'm pretty sure you could do that
<lazyPwr> multiple promethius's with a single grafana
<lazyPwr> i'd want to pilot that before i commit though
<stormmore> lazyPwr, yeah adding it on my list of things to look at
<lazyPwr> there ya go stormmore :)
<stormmore> :)
<stormmore> oh I can think of 2 other things that would be nice to merge into grafana
<zeestrat> rick_h: Any ETA on 2.1.2?
<rick_h> zeestrat: sorry, not sure. perrito666 any hints I should be aware of? ^
<bdx> rick_h: the controller monitoring setup is really sweet
<bdx> rick_h: I almost want my controllers back
<rick_h> bdx: cool, yea it's a road paved by our folks internally running controllers for JAAS
<rick_h> bdx: :P always good to keep a couple controllers over on the side to play with
<rick_h> its' not really cheating...
<zeestrat> rick_h: No worries. Dropped out for a bit. Links for Prometheus stuff coming in the show notes?
<lazyPwr> famous last words
<lazyPwr> :D
<lazyPwr> "its not really cheating if only have one side controller... and i only use it once in a while"
<rick_h> zeestrat: yes, I'll give you the first look: https://github.com/juju/stressjuju/tree/master/prometheus-config
<zeestrat> Cool. Thanks!
<stormmore> that was a really cool discussion, thanks guys
<stormmore> man I feel sorry for the ops team to have a dev that believes they aren't paid enough to be on call for their application!
<stormmore> lazyPwr, so since I have upgraded to 1.5.3 I am no longer getting logs into the kubernetes-dashboard
<stormmore> "an error on the server ("unknown") has prevented the request from succeeding (get pods" is the error I am getting both from the UI and kubectl
<andrew-ii> I am getting an `Incomplete relations: identity` though keystone is active, ready, and idle. Is there a good way for me to troubleshoot it?
<stormmore> lazyPwr, I suspect a DNS issue
<andrew-ii> May as well rebuild. I'm going to try again from the bundle instead
<lazyPwr> stormmore: yep
<lazyPwr> stormmore: if your units to not have FQDN kubectl logs and kubectl exec are broken for you atm
<lazyPwr> stormmore: that other issue however, get po was giving you an "unknown" error? thats new... that typically happens in an HA control plane scenario and only on specific commands. get po is not one of those...
<stormmore> lazyPwr, the one that is broken right now kubectl logs
<stormmore> lazyPwr, https://paste.ubuntu.com/24185553/ is what I get just trying to get the logs from the default http backend
<stormmore> lazyPwr, collecting an output from kubectl --v=8
<stormmore> lazyPwr, https://paste.ubuntu.com/24185633/
#juju 2017-03-16
<stormmore> actually looks like a CA issue :-/
<hardys> any one can help -> Problem with juju bootstrap
<hardys> the command.log is under https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/1042 , and the first lds server is in deployed state under maas...
<ybaumy> is there a way to logon to a failed commission machine in maas
<ybaumy> i need to debug
<ybaumy> i tried ubuntu/ubuntu
<kjackal> Good morning Juju world!
<Zic> hi here :)
<Zic> lazyPwr: just discovered a bug after 1.5.2 -> 1.5.3 upgrade:
<Zic> root@mth-k8smaster-01:~# kubectl exec -it nginx-ingress-controller-0lxzg /bin/bash
<Zic> Error from server: error dialing backend: x509: certificate signed by unknown authority
<Zic> it just affect the "kubectl exec" subcommand
<Zic> all other kubectl subbcommands works with no certificate error
<Zic> any clues?
<kjackal> Hi Zic, thank you for reporting this
<Zic> another one: "kubectl logs" is also affected
<Zic> as I regularly do other subcommand, I think only exec & logs are affected
<kjackal> would you be able to open an issue so we can track this down?
<kjackal> Zic: https://github.com/kubernetes/kubernetes/issues
<Zic> yep
<kjackal> Zic many thanks
<Zic> for information, the kubectl logs error is a bit more explicit: Error from server: Get https://mth-k8s-02:10250/containerLogs/development/phpbackend-w0bnv/phpbackend: x509: certificate signed by unknown authority
<Zic> so I just curl'ed this
<Zic> (openssl s_client -connect mth-k8s-02:10250 actually)
<Zic> http://paste.ubuntu.com/24187612/
<kjackal> And this is after upgrading from 1.5.2 to 1.5.3, right? I will try to repro today
<Zic> and it fact, certs was updated if I observe their date:
<Zic> http://paste.ubuntu.com/24187616/
<Zic> kjackal: yep, all charms of the CDK bundle to latest version
<Zic> including EasyRSA
<kjackal> Do you have the issue URL?
<Zic> I'm writing it, just a moment :)
<kjackal> Thanks
<Zic> was collecting some more logs to add to it ^^
<Zic> hmm, s/just a moment/I will ping you with the issue's URL/ (because morning do disaster: "GitHub: There have been several failed attempts to sign in from this account or IP address.")
<Zic> it seems that I don't know to type my GitHub's password without a coffee
<Zic> "Please wait a while and try again later."
<kjackal> :)
<Zic> just got access to my GitHub's account :D I'm preparing the issue :)
<Zic> kjackal: https://github.com/kubernetes/kubernetes/issues/43209
<kjackal> Awesome, thank you Zic
<Zic> don't know if I need to tag something because it's about CDK
<Zic> (I precised it in the title and "Install tools")
<kjackal> ok, Zic
<cnf> morning
<cnf> if you add a maas to juju, does juju use your credentials to do things for all users? or does every user needs their own maad credentials?
<BlackDex> Hello there. I'm using maas togher with juju (or the other way arround ;) ). Now i wonder if i want to use the latest LXD version 2.11 instead of 2.8, is that possible with juju?
<BlackDex> cnf: Depends, if you share your juju credentials, then yes.
<kjackal> cnf: looking here https://jujucharms.com/docs/2.1/clouds-maas each user should/could have its own maas certs that need to be passed to juju
<cnf> kjackal: could, or has to?
<cnf> kjackal: so a user needs some maas credentials to use the juju command to provision against maas?
<BlackDex> cnf: Yes
<BlackDex> without credentials juju can't connect and control maas
<cnf> BlackDex: after bootstrapping
<cnf> kjackal: so that means anyone using juju, at any time, needs credentials for the controller, AND the cloud juju is running on?
<kjackal> cnf: correct
<cnf> hmm...
<cnf> that's a lot of account-making
<kjackal> cnf: the benefit is that changing cloud (eg moving from maas to aws and back) is transparent
<cnf> how so?
<cnf> hmm
<cnf> kjackal: so how does the juju webui work?
<cnf> that caches credentials, doesn't it?
<kjackal> I have credentials for aws, openstack, local deployment with lxd and google's GCE. I imported the credentials once and I can switch between clouds with juju switch, everyhing else stays the same (juju deploy kubernetes everywhere)
<cnf> kjackal: but those are juju credentials
<cnf> kjackal: so if i make a juju controller on AWS, and i make a user on that controller for you
<cnf> do you then need AWS credentials to use that controller?
<kjackal> cnf: have a look here: https://jujucharms.com/docs/2.1/tut-users
<kjackal> cnf: here is a better explanation on the users in juju https://jujucharms.com/docs/2.1/users
<cnf> yeah, been reading that
<cnf> it's not entirely clear to me, still
<cnf> kjackal: https://jujucharms.com/docs/2.1/tut-users seems to imply juju caches the cloud credentials used during bootstrap, and uses that for all juju users
<anrah_> Can I introduce new relation on existing charm?
<anrah_> Meaning that I'm running some version of the charm and now implemented new relation and when I upgrade the charm it seems like the charm does not recognize that it has should have relation
<kjackal> cnf: seems so!
<kjackal> anrah_: You cannot do a add-relation?
<anrah_> No, it says No relations found
<cnf> ok, i think i have stuff sorted, now
<cnf> made a special juju user for maas
<cnf> now to figure out how to get a _working_ openstack deployed with juju
<kjackal> anrah_: can you double check that you have updated both the metadata.yaml and the layer.yaml with the interfaces of the relation?
<anrah_> yes, when I deploy from scratch the relation is available
<anrah_> But when upgrading the charm the new relation is not available
<kjackal> I see so it only through the update that the relation is not available
<anrah_> Yes
<kjackal> can you please open a bug or send an email to the list so that you raise awareness?
<anrah_> Sure!
<erik_lonroth> Hello, I'm looking for a good example charm for interfacing against "postgresql" (interface:pgsql). I'm about to create my first charm with juju and have read up alot but still find it a bit daunting to create and use juju with my application.
<erik_lonroth> Any help apprechiaed
<kjackal> hi erik_lonroth here is the list of charms using the pgsql relation https://jujucharms.com/requires/pgsql . The postgresql client seems a good place to start: https://jujucharms.com/u/postgresql-charmers/postgresql-client/3
<erik_lonroth> kjackal: Thanx!
<kjackal> Hey rick_h where was this zeppelin based dashboard you have? I want to steal some metrics from there:)
<kklimonda> how can I get IP addresses of all application units? any code I could look at
<kklimonda> hmm, probably relation_ids with correct relation
<kjackal> kklimonda: https://github.com/juju-solutions/interface-zookeeper-quorum/blob/master/peers.py#L41
<kklimonda> thanks
<disposable2> cnf: i don't know whose balls you had to scratch to get this much help from this channel but bravo
<cnf> disposable2: just persistence, i guess :P
<erlon> guys does anyone knows how do I connect to a mysql server that juju installed as admin user?
<erlon> I do can log using the credentials of the services (like cinder nova), but I need elevated permissions
<BlackDex> does juju support lxd 2.10/2.11? So can i use the lxd ppa? (ppa:ubuntu-lxc/lxd-stable)
<BlackDex> i see that conjure-up now supports it, but does that implicate that juju supports it?
<rick_h> BlackDex: yes, conjure-up uses juju so it supports it.
<BlackDex> oke nice
<cnf> hmm, how does machine affinity work in bundle .yml files?
<cnf> i see things like to: lxd/1, but  lxd on what machine?
<BlackDex> cnf: in a bundle file that would be lxd:1 then
<BlackDex> which means lxd container on machine 1
<cnf> ah, ok
<BlackDex> to define specific machines i suggest to create tags in maas
<BlackDex> like machine1, machine2 etc...
<cnf> can i also use space affinity do do that?
<BlackDex> and add those as constraints
<BlackDex> yea you can do that also. If you only want specific network space affinity
<andrew-ii> I have a small test setup, and each machine is pretty specialized, and I actually use the machine name in the tags
<cnf> andrew-ii: how do you define that in the yml file?
<andrew-ii> In a bundle, I think you can put the `tags=myMachineTag` in the constraints clause
<cnf> the file i have doesn't have constraints
<cnf> i'll have to look up how to do that
<cnf> (or to apply a bundle.yml file, for that matter)
<andrew-ii> machines:   '0':     series: xenial     constraints: "tags=myMachineTag"
<cnf> jamespage gave me an example over at #openstack-charms i'm adopting for my needs
<andrew-ii> I think it's like that
<cnf> ah, hmm
<cnf> interesting
<cnf> hmm, so i could make tags like "controller" and "computer" and "storage"
<cnf> hmm
<andrew-ii> I think so. I did that. Then realized that my machines are a bit junk and have to manually deploy specifically for the test
<cnf> :P
<cnf> the lightest machine is a 16 core, 24G ram gen7 HP  with 500G storage
<cnf> so i'll be fine, i think
<andrew-ii> nice
<cnf> got 2 32 core, 96G ram machines, and a 64 core 192 G ram machine as well, for compute
<andrew-ii> That'll do
<cnf> and 3 ceph nodes with a ton of disks coming in
<cnf> i want to put the network gateway, and dbase and dashboard on the lightest machine
<andrew-ii> I'm currently just trying to figure out how to deploy the components without them getting hung. I keep getting incomplete relations, though I also have a mess of VLANs and spaces likely messing it up
<cnf> yeah...
<cnf> it's a bit of a learning curve
<cnf> thankfully, $currentclient is willing to pay my hours for it :P
<cnf> so i can set to: lxd right? without specifying a machine after it? or does it need a machine right there?
<andrew-ii> I think you specify the machine
<andrew-ii> But the machine may be anonymous (unless your constraints limit it to one)
<cnf> hmm, you can use to: to units as well
<cnf> it seems
<cnf> to: lxd:neutron-gateway/0
<andrew-ii> I think that is pretty great, if only for planning. It makes it much clearer what machine is getting what grouped with it
<cnf> but form what i can see no "put it in an lxd container on a machine matching these constraints"
<cnf> yeah
<andrew-ii> The constraint matching happens in the machines: clause
<andrew-ii> From then on the machine numbers are consistent
<cnf> you can match constraints on application level as well
<cnf> https://jujucharms.com/docs/stable/charms-bundles
<andrew-ii> I forgot about that, but I'm not sure "tags=maasTag" works for applications (though I need to try it to be sure)
<BlackDex> cnf: You can use the constraints for lxd placements
<BlackDex> if you use a constraint it will ask maas for a machine with that constraint
<cnf> BlackDex: ok, so how do i tell it to put it in LXD, and add constraints?
<cnf> from what i can see, the to:lxd expects something behind lxd
<cnf> either a machine, or a unit
<BlackDex> a machine in the case of juju
<cnf> uhm
<cnf> i don't follow
<BlackDex> you define machines by number, and allocate them using constraints. After that you can use lxd:<machine-number> to place that specific application on that machine on an lxd
<cnf> yes, i know
<cnf> that's not what i was asking, though :P
<BlackDex> ow :p
<cnf> i want to know if i can put it in an lxd container. and NOT define a machine, but have a constraint instead
<jam> cnf: we don't do scheduling to lxd containers. I believe if you use just "lxd:" we'll let you, but we'll allocate a new top level machine and then put it into a container on that machine.
<cnf> jam: right
<cnf> jam: that's too bad, but i can work with it
<narinder> mwenning, yes
<stormmore> so lazyPwr, looks like the issue with logs might be something cert related. once I downloaded the newer 1.5.3 client I got: "Error from server: Get https://ip-172-31-12-41:10250/containerLogs/default/default-http-backend-9wcl3/default-http-backend: x509: certificate signed by unknown authority"
<Zic> lazyPwr: around?
<stormmore> he has been unresponsive so far Zic
<Zic> not important, thanks :)
<ybaumy> can tags be seperated by comma?
<catbus1> ybaumy: is this what you are looking for: https://docs.ubuntu.com/maas/2.1/en/manage-cli-tags
<tvansteenburgh> stormmore: Zic: lazyPwr is out sick today
<Budgie^Smore> ugh! somehow I am not surprised tvansteenburgh with how his schedule has been lately
<ybaumy> catbus1: thanks yes thats what i was looking for. and i remember that i even saw this page before. but couldnt recall it
<otis> Hi.  I'm looking for information about Juju adoption.  Are there any data, any charts, or anything else one could see/use?
<ybaumy> otis you mean like a powerpoint presentation?
<ybaumy> or documentation?
<otis> ybaumy - anything that shows any numbers and, ideally, trends
<otis> I'm asking because I've recently been asking people about Juju and most of them have either not heard of it or are not using it.
<otis> And I've been aware of Juju for *years*.  So now I'm wondering if Juju is stagnant or growing or ....
<ybaumy> hmm better ask the devs then. maybe they have something. would be interessting for me too though. if i can show management something. they think ubuntu is a kiddies OS
<ybaumy> and juju too
<ybaumy> alone the name they laughed about
<Budgie^Smore> I am surprised that I don't see it on job descriptions for sure
<ybaumy> in the last 12 month or so. when i was getting job offers left and right. i only encountered ubuntu in a job offer once
<ybaumy> im from germnay
<ybaumy> germany
<ybaumy> maybe in the US its more popular
<otis> Ubuntu is popular.  But Juju != Ubuntu :)
<otis> Juju is NOT popular from what I can tell.
<ybaumy> true but ubuntu is pushing it
<ybaumy> ive never seen it yet on the redhat or suse sites
<ybaumy> maybe they adopted it too
<ybaumy> in germany everythings suse pretty much. a little redhat
<Budgie^Smore> in my experience there is a lot of use of Ubuntu or Ubuntu based distros in the US but not juju by any stretch
<otis> Sounds like there is nobody from Ubuntu here with numbers :(
<BlackDex> i use juju a lot
<BlackDex> to deploy OpenStack mainly
<BlackDex> But also CEPH Clusters
<BlackDex> But, i'm a ubuntu (debian) fanboy ;)
<roadmr> hello jujuers. Has anybody seen insert juju.system.indexes keyUpdates:0 exception: BSONObj size: 61366220 (0xCC5FA803) is invalid. Size must be between 0 and 16793600(16MB) First element: : ?type=92 code:10334 locks(micros) w:10805 5ms from juju's mongodb?
<ybaumy> the gui is deployed to the controller right? how do i access the gui?
<ybaumy> if i try to connect to one of the ips in the show-controller output nothing is thre
<ybaumy> there
<tvansteenburgh> ybaumy: `juju gui`
<ybaumy> ahh
<ybaumy> nice
<ybaumy> i seee
<ybaumy> this is cool
<bdx> I'm experiencing some very odd behavior it seems when I deploy an application multiple times in a model, almost like I'm not getting the latest version of the charm on subsequent deploys .... I don't seem to get an actual current revision that I deploy until I modify the application name
<bdx> geh ... that was tattered
<bdx> basically, my deploys seem to be deploying an older an older rev of the charm, even though I am specifying the latest rev when redeploying
<bdx> butchered again
<bdx> moreover, my lxd local deploys are acting strangely different then my lxd deploys on aws
<bdx> here is a lxd local deploy http://paste.ubuntu.com/24191166/
<bdx> and here is a deploy of the same charms, but to an instance on aws http://paste.ubuntu.com/24191170/
<bdx> this has been working consistently for me across both providers up until today
<ybaumy> in the gui is it possible to add constraints like tags for maas?
<andrew-ii> When juju's provisioner complains about there being no obvious space for a container (like a maas space), is there a way I can configure that in the bundle or gui?
<andrew-ii> My controller is on 2.1.1, if that helps (or makes things worse...)
<andrew-ii> Or perhaps a better question: does `juju gui` version 2.4.3 allow space configuration constraints?
#juju 2017-03-17
<ybaumy> please make remove-unit really work
<ybaumy> also does set-model-constraints tags=test work for all machines und unit deployments?
<ybaumy> the problem im having is that constraints do not work when add-unit is used
<ybaumy> so to scale out there is no way to use a specific machine set or is there?
<ybaumy> this really a showstopper if i cant scale out to machine sets who share the same tags
<pranav_> Hi Folks. I am facing issue in publishing our charm for review
<pranav_> charm list resources shows
<pranav_> [Service] RESOURCE REVISION install  -1
<pranav_> but running "charm release cs:~vtas-hyperscale-ci/hyperscale-0 --resource install-1 --channel edge" Gives error
<pranav_> ERROR cannot release charm or bundle: bad request: charm published with incorrect resources: cs:~vtas-hyperscale-ci/hyperscale-0 resource "install/1" not found
<kjackal> Good morning Juju world!
<Guest50267> Hey all. Any one has idea on charm push-term?
<Guest50267> getting error ERROR unrecognized command: charm push-term
<Guest50267> charm version is 2.2.0-0ubuntu1~ubuntu16.
<tejaswi> hi team, I am trying to install all OpenStack services using Juju. However, due to this bug - https://bugs.launchpad.net/charms/+bug/1417407, the haproxy cfg files are getting overridden by new services.
<mup> Bug #1417407: haproxy enabled by default for keystone, cinder, openstack-dashboard, nova-cloud-controller and glance breaks deploying multiple light services to the same node. <Juju Charms Collection:New> <https://launchpad.net/bugs/1417407>
<tejaswi> How to fix this issue ?
<tejaswi> Is there a way to install OpenStack without haproxy ?
<ybaumy> hmm
<ybaumy>   '3':
<ybaumy>     series: xenial
<ybaumy>     contraints: tags=devcloud,node
<ybaumy> ah forget it
<ybaumy> i should learn how to write constraints
<cnf> ybaumy: what is wrong with it?
<ybaumy> i wrote constraints instead of constraints
<ybaumy> -s
<ybaumy> in the first
<cnf> ah :P
<cnf> dem morning typos
<ybaumy> im up since 5 so its forgiven
<ybaumy> cnf have you ever had the problem to add a unit with constraints?
<cnf> uhm, i learned of constraints yesterday
<cnf> i have yet to successfully use them
<ybaumy> i wonder if i have to add-machine first then add-unit --to
<cnf> ask me again in 20 minutes, i'll tell you if my srtuff came up :P
<kjackal> tejaswi: You could ask at #openstack-charms
<kjackal> ybaumy: you do not need to first add a machine and then deploy the app. You just do a juju deploy .... --constraints "mem=4G ...."
<ybaumy> kjackal: no its about scale out with add-unit
<ybaumy> how do i make constraints inherited
<ybaumy> if that is the correct term
<tejaswi> kjackal: ok
<magicaltrout> need a hack, how do i manually unset a state?
<magicaltrout> lazyPower: ping
<lazyPower> magicaltrout: charms.reactive remove_state
<magicaltrout> I actually had another question, but that will hopefully help resolve it
<magicaltrout> ever seen this
<magicaltrout> 2017-03-17 14:30:26 INFO install Generating RSA private key, 2048 bit long modulus
<magicaltrout> 2017-03-17 14:30:27 INFO install unable to write 'random state'
<magicaltrout> 2017-03-17 14:30:27 INFO install e is 65537 (0x10001)
<lazyPower> O_o
<lazyPower> unable to write random state?
<magicaltrout> the weird thing is if i actually run the command it runs fine
<lazyPower> thats a new one on me
<lazyPower> marcoceppi: ^ have you seen this?
<lazyPower> you've seen like every nit noid thing we've come up with
<magicaltrout> its in your code, thats why i'm asking :P
 * lazyPower crosses fingers
<lazyPower> magicaltrout: well lets not point fingers
<lazyPower> what code?
<magicaltrout> hehe, k8s master
<magicaltrout> but this is on my weird openstack deployment platform, so i'm not blaming you, its probably entropy rubbish
<lazyPower> yeah thats what i was about to say is that it sounds like the unit hasn't generated enough entropy
<magicaltrout> but my openstack cluster and canonical k8s really hate each other :)
<lazyPower> and we host entropy.ubuntu.com
<lazyPower> which should have given you enough of a random seed for entropy
<magicaltrout> I'm gonna remove authentication.setup
<magicaltrout> in the hope a rerun will kick it enough
<magicaltrout> cause it just stops, but weirdly, i wouldn't have thought it got set
<magicaltrout> so I don't know why it isn't run a second time
<magicaltrout> bombed again
<magicaltrout> what the
<magicaltrout> weird and interesting
<marcoceppi> magicaltrout: not enough /dev/random bits?
<magicaltrout> http://pastebin.com/5WUhAr7Y
<magicaltrout> well
<magicaltrout> if I run the hook
<magicaltrout> it fails
<magicaltrout> if I run the command via juju run
<magicaltrout> it fails
<magicaltrout> if I ssh into the box and run it manually
<magicaltrout> it runs
 * magicaltrout gets out the big # based crowbar
<marcoceppi> magicaltrout: is there a .rnd file in /root ?
<magicaltrout> yup
<magicaltrout> sorry lazyPower not trying to grumble, just trying to figure out juju/k8s weirdness on a random openstack cluster I have zero control over but have been asked to deploy kubernetes to
<magicaltrout> :)
<magicaltrout> anyway, i've commented it out, we'll see how we go
<lazyPower> magicaltrout: oh not even upset man, just trying to keep my head above water atm. I'm sick, heavily medicated, and in/out of meetings for the last hour.
<magicaltrout> join the club, my nose was streaming on the way back from NYC
<magicaltrout> i'm not sure my fellow passengers were overly impressed
<lazyPower> yeah, must be going around.
 * lazyPower reads more of the backscroll
<lazyPower> magicaltrout: this does seem like an issue with entropy
<lazyPower> i'm not sure why its working when you manually run it vs script execution though.
<magicaltrout> yeah its a bit odd
<lazyPower> perhaps the fact you've logged in and issued the command gave it the bump it needed in terms of entropy
<lazyPower> this is outside my scope of knowledge in crypto
<magicaltrout> but also fails in juj run as well
<magicaltrout> so its happy when you have a shell open
<magicaltrout> oh well
<lazyPower> i would probably be poking dustin about this and asking him to teach me to fish, or links so i can read about fishing.
<magicaltrout> this is possibly the slowest openstack cluster the US Govt could possibly own
<lazyPower> pfft
<lazyPower> you had to challenge them didnt you?
<lazyPower> your next stack will be a bunch of minnowboards
<magicaltrout> well i got more ram
<magicaltrout> but apt update takes ~25 minutes per server :)
<magicaltrout> I think i might be a bit IO bound
<jrwren> magicaltrout: welcome to my slow-server case. There are some apt tunings you can do.
<Budgie^Smore> o/ juju world!
<Budgie^Smore> hope your feeling better today lazyPower
<jrwren> magicaltrout: I've always felt that charms should be optimized to run apt-update minimally, but instead they run it rather often. It really makes for slow charm deploys when things are on slow IO :(
<lazyPower> Budgie^Smore: i'm mostly dead inside because of all the medication, but i'm present and accounted for.
<magicaltrout> tell me about it jrwren, slow or completely time out
 * rick_h ships lazyPower some OJ
<lazyPower> Budgie^Smore: how are things giong for you and your maas k8s deploy?
<magicaltrout> i spin up units manually and run apt update befoe dumping juju workloads on them
<lazyPower> rick_h: <3
<lazyPower> magicaltrout: are you using the daily image stream?
<Budgie^Smore> lazyPower oh I keep hitting hurdle after hurdle there and all of them of my own making probably
<lazyPower> magicaltrout: if you're using daily images your deltas should be pretty minimal
<magicaltrout> there aren't that many lazyPower, but it takes forever installing a new kernel
<lazyPower> magicaltrout: i know if you're using the "stable" image stream you could be somewhere near 3 months of package updates, depending on patch release and which image.
<Budgie^Smore> lazyPower the latest one is having me rethink using VBox in favor of kvm due to not be able to change the power types in MaaS 2.1
<jrwren> magicaltrout: do you find that dumping juju workloads on them is also slow because the juju workload apt update / upgrade as well?
<magicaltrout> na thats not as bad jrwren cause the delta is 0 by this time
<Budgie^Smore> lazyPower still need to figure out how to solve the cert issue on my clound k8s cluster too
<jrwren> magicaltrout: ah, well that is good.
<lazyPower> Budgie^Smore: - cert issue? i think i've missed context here... sounds like you've told me about this one and i forgo about it....
<lazyPower> Budgie^Smore: do you mind re-iterating and i can try to help?
<Budgie^Smore> lazyPower but that one is getting some larger instances as dev created a tool that will swallow memory like it is going out of fashion
<lazyPower> hah
<magicaltrout> I spent about 6 hours on tuesday trying to get the k8s routing working and it kept failing, i suspect because the update times were so rubbish juju failed or hadn't updated some services
<lazyPower> is it java based? :D
<magicaltrout> I have more ram now, just slow disks, so hopefully I'll get further :)
<lazyPower> magicaltrout: k8s routing... meaning ingress?
<magicaltrout> yeah, and dashboard
<magicaltrout> they all failed to route out
<Budgie^Smore> lazyPower sure, give me a few mins to pull the acctual error but basically it looks like one of the tools is complaining about an unknown CA which is causing it not to display logs either in the dash board or from kubectl logs
<lazyPower> ok, you do know that we dont enable external dashboard access outside of proxy by default right?
<lazyPower> you can easily default that, but we dont make it easy because its a huge security hole
<magicaltrout> yeah i run the kubctrl proxy
<magicaltrout> just get 504's
<lazyPower> Budgie^Smore: ok, that sounds like 1 of 2 things. I"ll wait for the error before i diagnose
<magicaltrout> anyway, i'm not there yet today, when I am, we'll see :)
<lazyPower> magicaltrout: ok, when you do get there, make sure you have my attention and i'll help
<lazyPower> we have a bug open from another user that ran into unexpected behavior
<lazyPower> stuff that i haven't been able to reproduce
<magicaltrout> i mean i've only been spinning up openstack nodes for it for like 3 hours! :P
<lazyPower> so i'm highly interested in findign out wtf is going on
<magicaltrout> yeah i saw that ticket
<magicaltrout> it looked similar
<lazyPower> yeah man, if its the same, lets find it and nail it to the wall
<lazyPower> i dont like bugs i cant reproduce
<Budgie^Smore> I have one of those with the MaaS team right now lazyPower ;-)
<Budgie^Smore> oh I just noticed that I am using IPv6 at home!
<lazyPower> Budgie^Smore: you mean a non-reproduceable bug by the maintainers?
<lazyPower> Budgie^Smore: kill it with fire
<Budgie^Smore> lazyPower yeah, install related issue where the rack controller doesn't register to the region controller
<lazyPower> :S
<lazyPower> fun times, that one
<lazyPower> Budgie^Smore: i'm guessing nothing in the logs of the region controller? Nothing indicative that the network is not the culprit?
<Budgie^Smore> lazyPower I saved a copy of the virtual disk one of the times it happened but haven't heard from the maintainers if they would like it... there is an error in there but didn't point to the culprit, I suspect network latency issues though
<stormmore> ok so lazyPower, here is the output from kubectl --v=8 logs - http://paste.ubuntu.com/24195846/
<lazyPower> ok, i see the x509 errors in here. This is consistent with a couple problems that might have arisen...
<stormmore> lazyPower, it is worth noting that I only started getting this error once I upgrade my kubectl client version to 1.5.3, with 1.5.1 it was an annoying generic catch all failure
<lazyPower> 1 sec, let me finish gettign this multi-cloud test run of the etcd3 stuff going. Can you get me the output of juju run-action kubernetes-master/0 debug
<lazyPower> post that somewhere secure, it'll have logs + config files that you dont want to leak
<lazyPower> stormmore: that sounds like some of the extra debugging that landed in 1.5.2, so it makes sense that was expanded when you upgraded.
<lazyPower> but i'll want the output of the debug action on your master so i can verify the tls components were installed correctly
<stormmore> I am wondering if this is an affect from upgrading the cluster
<stormmore> (and messing it up when I just did a juju deploy over the top of the current one)
<stormmore> lazyPower, OK to DDC it to you?
<arosales> hatch: I added a comment to https://github.com/juju/docs/issues/1651
<arosales> hatch: I also opened up https://github.com/juju/docs/issues/1723
<hatch> kewl thanks
<lazyPower> stormmore: hang on and i'll see about deploying a secure upload
<lazyPower> i'm on znc + weechat and haven't used DCC since the 90's
<lazyPower> that combination means i'm probably going to have tears at the end of it :P
<stormmore> right! yeah it has been awhile for me too... not even sure how well Hexchat handles it
<magicaltrout> DCC! jesus, i'd forgotten that was a thing
<magicaltrout> those were the days
<magicaltrout> it didn't work then
<magicaltrout> it won't work now :)
<psarwate> Hey folks. I am unable to get juju terms to work with my charm.
<psarwate> Eventhough the charm is not agreed upon, juju still doesn't prompt me
<psarwate> the terms is not agreed upon*
<stormmore> OK I have the debug log :) reminds me of sosreport back in the day
<magicaltrout> I figured out my dashboard faux pas lazyPower , no UDP routes between the nodes
<magicaltrout> oops :)
<arosales> hatch: one more https://github.com/juju/docs/issues/1724
<lazyPower> magicaltrout: ah interesting
<arosales> hmm seems I missed psarwate
<arosales> I wonder if Juju was actually deploying his charm though . .  .
<hatch> thanks arosales
<arosales> also if psarwate was deploying locally then terms will be bypassed
<lazyPower> cs:~containers/etcd-25  (edge channel) was just released, introducing deb=>snap migration path and roll forwards to etcd 3.1.3  (juju config etcd channel=3.1/stable)  -- you'll need to follow the migration path in the readme however. All early feedback appreciated
<lazyPower> plus sesnding a notice to the list with a bit more details than this blurb ^
<rick_h> lazyPower: congrats!
<lazyPower> rick_h: its pretty cool to see the capability of rolling forward and rolling backwords using a single config option. (potential data mismatch if you're actively reciving data during the forward jump, rollback will restore to the state just prior to the upgrade). but its nice to know we support this now in the event of troubled clusters.
<rick_h> lazyPower: yea, cool how things are moving
<petevg> cory_fu: you did some work to making rebuilding the python-libjuju _client easier, right?
<stormmore> btw lazyPower I am looking at using SDN in this cluster
<cory_fu> petevg: Yes.  Are you planning to rebuild it?
<petevg> cory_fu: yes. Though we may have to tackle the multiple versions thing sooner rather than later.
<petevg> cory_fu: filing a bug and pushing a repro right now ...
<petevg> cory_fu: issue at https://github.com/juju/python-libjuju/issues/90, and test reproducing it at https://github.com/juju/python-libjuju/pull/91
<petevg> cory_fu: do the docs on building live anywhere?
<cory_fu> petevg: Yes, but my Makefile changes seem to have disappeared
<petevg> cory_fu: that's why I couldn't find them :-/
<cory_fu> wth
<petevg> cory_fu: git ate your homework!
<cory_fu> petevg: Well, I can't for the life of me figure out what happened to the Makefile changes I made, but they're not strictly necessary and were relatively minor.  The important bit is at https://github.com/juju/schemagen
<cory_fu> petevg: Build and run that, directing the output to juju/client/schemas.json, and then run the "client" target: https://github.com/juju/python-libjuju/blob/master/Makefile#L13
<petevg> cory_fu: cool. thx.
<petevg> cory_fu: since the alpha has breaking changes, this is also the time to worry about different versions of the _client.py in python-libjuju, right? As in: I shouldn't just slam these changes in ...
<cory_fu> petevg: Well, it's just one API, and we could work around it in the wrapper around FullStatus that we definitely should have.  But we do need to support facade versions eventually so if you can come up with a good way to handle that, I'm down
<magicaltrout> so lazyPower if I run the microbot service and then want to check it
<petevg> cory_fu: cool. That sounds more fun than downgrading juju and having to deal with halfway destroyed models cluttering my env :-)
<magicaltrout> do I have to munge my hosts file to make it resolve?
<cory_fu> petevg: It would be good to have _client.py split up anyway, and splitting it by facade version shouldn't be much harder.
<cory_fu> petevg: The hard bit would be figuring out which facade versions to use based on the controller.  I don't know if there's a way to query that
<cory_fu> petevg: Also, I would imagine that the object layer code would need to know how to work with the different facade versions as well.
<petevg> Ayup.
<cory_fu> petevg: Aren't the facades supposed to keep us from having version-specific logic in the code?  I'm a little unclear on how they're supposed to help
 * magicaltrout is getting 502's and nothing else \o/
<petevg> cory_fu: My expectation would be that if you do nothing, you are operating against stable, and if you pass in a flag somewhere, you operate against some other version.
<petevg> cory_fu: it would be cool to do some magic with imports, but I don't think that import time is the right time.
<petevg> connection time probably isn't right, either.
<cory_fu> petevg: Maybe tvansteenburgh has some insight for us here?
 * tvansteenburgh wakes up
 * tvansteenburgh reads scrollback
<tvansteenburgh> petevg: cory_fu: https://github.com/juju/python-libjuju/issues/49. we can dynamically use the right facade version pretty easily. the trick will be handling changing api signatures in the object layer
<tvansteenburgh> happy to discuss that at some point, but that point is not today :)
<magicaltrout> okay... lazyPower my microbot containers are all paused... no idea why or what that is, answers on a postcard when you get bored
<petevg> tvansteenburgh: Cool. I'm going to head out to dinner soon, anyway. Thank you for the linky :-)
<tvansteenburgh> sure thing
<lazyPower> magicaltrout Budgie^Smore - i think i foudn the issue with your x509 validations - https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/238
<lazyPower> magicaltrout Budgie^Smore - if you could check your /etc/default/kubelet file's for the presence of the tls flags + disabling anonymous auth on kubelet, that would be choice to validate its the root cause of the validation issues post 1.5.3 update
<magicaltrout> i don't have cert issues :)
<magicaltrout> not yet anyway
<magicaltrout> http://pastebin.com/raw/gSWGEk1E
<magicaltrout> any idea lazyPower \o/ :)
<magicaltrout> even docker run -d dontrebootme/microbot:v1
<magicaltrout> is failing on me
<magicaltrout> which is weird cause I have other containers running fine
<lazyPower> whats this about ipv6
<lazyPower> and it cant seem to find any of the image layers
<lazyPower> i'm not sure how you got into this state but this is certainly fun magicaltrout
<magicaltrout> lol
<magicaltrout> this is just post install
<lazyPower> not without some effort it isnt
<lazyPower> how do you get docker to know about the meta of the image but have none of the data to back it up?
<magicaltrout> i swear gov'ner over than installing the charms i've not touched it from base xenial
<lazyPower> yeah i'm not sure what to recommend here magicaltrout
<lazyPower> i've not seen this before. I suspect i'm missing pieces to the puzzle
<lazyPower> magicaltrout best i can suggest at this juncture would be to capture the model with a juju-crashdump report and post that for post analysis
<magicaltrout> reboot managed to make things worse \o/
<magicaltrout> ho ho, nothing better on a friday night
<stormmore> oh nice lazyPower! let me look, sorry I have taken today as a chance to write some documentation
<stormmore> you still there lazyPower? http://paste.ubuntu.com/24197670/ is the /etc/default/kubelet from one of the workers
<lazyPower> stormmore yeah looks like the tls flags + auth flags didn't make it in the upgrade
<lazyPower> Cynerva not sure if you're still here, its pretty late in the day. ^
<lazyPower> i filed https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/238 in reference to this.
<lazyPower> stormmore thanks for validating, we should have a patch or working fix for this soon
<lazyPower> the manual fix is pretty simple too, but i'd rather the charms take care of themselves and update that defaults file.
<stormmore> so the "workaround" would be to add those flags?
<lazyPower> yeah
<stormmore> yeah no problem, I think I have a bought a little bit of time on that anyway. need to add 3 larger instances and remove 3
<magicaltrout> lazyPower: the ipv6 stuff is cause flannel has an ipv6 address and dishes them out to the container eth adapters
<magicaltrout> i removes /var/lib/docker which seems to have resolved the layer issues
<magicaltrout> what is amazing though is
<magicaltrout> nginx-ingress-controller runs fine on the same machine?!
 * magicaltrout needs hard liquor
<petevg> cory_fu: my first (probably naive) attempt at "make client" failed with this error: https://pastebin.canonical.com/182956/  (This is using a schema.json that I generated with schemagen).
<petevg> cory_fu: it's dinner time, though, so I'm going to do that, and then worry about things more on Monday.
<petevg> Have a happy weekend!
<magicaltrout> oooh fsck
<magicaltrout> you can't docker exec into microbot
<magicaltrout> that explains that then
<cory_fu> petevg: Damnit!  That was the error I fixed in the same code that I modified the Makefile target
<cory_fu> petevg: I really don't want to have to re-do that.  It was a bit of a PITA
<petevg> cory_fu: darn!  I will try doing some git Magic on Monday. Maybe I can fin your change ...
<petevg> *find
<magicaltrout> oooh blimey microbot is running
<magicaltrout> i take it all back lazyPower
<magicaltrout> its an amazing platform
<magicaltrout> never questioned it!
<magicaltrout> lazyPower: other question, trying to understand ingress stuff.  Is the microbot supposed to route through the loadbalancer?
<magicaltrout> or mbruzek you're on the hook as well :P
<magicaltrout> ooh the loadbalancer is only for the masters?
<mbruzek> magicaltrout: no microbot is not going through the kubeapi-load-balancer, it goes through a kubernetes load balancer
<mbruzek> when you create ingress rules
<cory_fu> petevg: ah ha!  It's in the branch bug/77-deploy-resources!  You can easily see the changes I made in this commit: https://github.com/juju/python-libjuju/commit/ef59035b2596a1998615cb0ad3f73fe539531898
<mup> Bug #77: Maybe drop you in the 'edit bug' page after adding a bug? <lp-bugs> <Launchpad itself:Invalid by bjornt> <https://launchpad.net/bugs/77>
<petevg> cory_fu: yay! Thx.
<cory_fu> petevg: If you want, I could submit that commit by itself as a PR
<cory_fu> Probably worth doing
<petevg> cory_fu: sure. Thx.
<cory_fu> petevg: https://github.com/juju/python-libjuju/pull/92
<stormmore> lazyPower, you don't have any toys to help devs assess the resource usage - cpu, mem - of their containers do you?
#juju 2017-03-18
<lazyPower> stormmore: beats, all day long.
<lazyPower> stormmore: i haven't deployed this in about 5 months, but https://jujucharms.com/u/lazypower/dockerbeat/
<lazyPower> is the beat in particular I used to profile containers.
<lazyPower> stormmore: the alternative is the kubernetes dashboard where you get a window into it, but no long term metrics.
<stormmore> yeah I am thinking something that they can use outside of the infrastructure to at least give them an idea of what we should start for their limits in Kubernetes
<stormmore> The grafana dashboards do a pretty good job of giving me the data once the containers are deployed :)
<ybaumy> juju upgrade-juju
<ybaumy> ERROR Authorization Error: 'Expired timestamp: given 1489837307 and now 1489865847 has a greater difference than threshold 300'
<ybaumy> hmm
<ybaumy> ntp times are synced on all nodes as well as on the machine running the juju command
<ybaumy> how to install ntp on juju controller?
<ybaumy> and why isnt it installed in the first place
<ybaumy> i cant login to the controller with the juju login
<ybaumy> it says
<ybaumy> juju login testmaas-controller
<ybaumy> ERROR "testmaas-controller" is not a known public controller
<ybaumy> but its the controller name
<blahdeblah> ybaumy: You should be able to "juju switch controller; juju deploy cs:ubuntu --to 0; juju deploy cs:ntp; juju add-relation ubuntu ntp"
<ybaumy> blahdeblah: thanks but ntp is running everywhere already on the controllers
<ybaumy> so there is some other problem
<ybaumy> and when trying to deploy
<ybaumy> i get his
<ybaumy> this
<ybaumy> root@openstacksa2:~# juju deploy cs:ntp
<ybaumy> Located charm "cs:ntp-17".
<ybaumy> Deploying charm "cs:ntp-17".
<ybaumy> ERROR cannot add application "ntp": Authorization Error: 'Expired timestamp: given 1489876526 and now 1489905066 has a greater difference than threshold 300'
<ybaumy> clocks are 2 seconds apart as far as i can tell
#juju 2017-03-19
<codezomb> Is anyone aware of a way to autoscale charms? For example, running my workers needs to scale based on metric X. I could probably do something with SQS / Lambda to hit the juju api, but I thought I would ask if anyone knew of any existing solutions.
<blahdeblah> ybaumy: I'm curious to know what part of the system is producing the error, since it implies that it's more than 5 minutes, not 2 seconds.  Might be best to log a bug about that.
<jrwren> codezomb: https://jujucharms.com/charmscaler/
<ybaumy> Sun Mar 19 03:24:04 UTC 2017
<ybaumy> Sun Mar 19 04:24:04 CET 2017
<ybaumy> Sun Mar 19 03:24:05 UTC 2017
<ybaumy> Sun Mar 19 04:24:05 CET 2017
<ybaumy> Sun Mar 19 03:24:06 UTC 2017
<ybaumy> Sun Mar 19 04:24:06 CET 2017
<ybaumy> Sun Mar 19 03:24:06 UTC 2017
<ybaumy> Sun Mar 19 04:24:06 CET 2017
<ybaumy> Sun Mar 19 03:24:07 UTC 2017
<ybaumy> Sun Mar 19 04:24:07 CET 2017
<ybaumy> blahdeblah:
<ybaumy> maybe the CET UTC ?
<ybaumy> but that shouldnt matter right
<ybaumy> CET is on the host i am executing the command
<ybaumy> nope thats not it
<ybaumy> changed tzdata to UTC
<ybaumy> same error
<ybaumy> and there is no error when i print unixtime with +%s
<ybaumy> hmm im out of ideas
<blahdeblah> ybaumy: 7.927 hrs; doesn't sound like anything to do with TZs
<ybaumy> but what can it be
<blahdeblah> ybaumy: Can you pastebin your juju status --format=yaml (obfuscated if necessary)?
<ybaumy> http://pastebin.com/Qhr8JRea
<blahdeblah> ybaumy: and you can't deploy any charms at all?
<ybaumy> wait a sec. let me try and add-machine + unit
<blahdeblah> ybaumy: But you don't appear to have any services to add units to
<blahdeblah> s/services/applications/
<blahdeblah> What does juju status --format=tabular show?
<ybaumy> blahdeblah: that the output of the controllers
<ybaumy> blahdeblah: im getting the same error when switching to model default
<ybaumy> blahdeblah: with add-machine --constraints tags=prodcloud,node
<blahdeblah> ybaumy: So in which model were you seeing the "Expired timestamp..." error from above?
<ybaumy> blahdeblah: default or it seems it doesnt matter
<ybaumy> blahdeblah: its broken
<ybaumy> ii  juju                               1:2.2~alpha1-0ubuntu1~16.04.1~juju1 all          next generation service orchestration system
<ybaumy> ii  juju-2.0                           1:2.2~alpha1-0ubuntu1~16.04.1~juju1 amd64        Juju is devops distilled - client
<blahdeblah> My guess is something to do with replication on the controllers, but I'm not expert enough in mongodb to advise on that.
<ybaumy> maybe i will open a bugreport
<ybaumy> will downgrade later to stable on my testbox
<ybaumy> if that is even possible
<ybaumy> i opened up a bug
<ybaumy> i hope i have something ready and working by tuesday. i have to hold a presentation about the current status of the POC :D .. broken here .. maas bug. problems with openstack in general
<ybaumy> that will be a mess
<ybaumy> im gonna watch some seinfeld. i need my dosis of george in order to cope with reality :D
<ybaumy> hmm on my other environment i have the same error
<ybaumy> 2.0.2-0ubuntu0.16.04.1
<ybaumy> and thats the version
<ybaumy> so it must be something else
<ybaumy> the strange thing is
<ybaumy> on my veeam backup server the jobs failed with an error that the time is out of sync between client and server
<ybaumy> lol
<ybaumy> i found it
<ybaumy> on my maas server there was a time set to 1400 and its now 0618
<ybaumy> i installed ntp there and now everythings working
<ybaumy> but veeam backup is still broken
<ybaumy> one of my esx servers had no ntp config
<ybaumy> damn
<codezomb> jrwren: I couldn't get that to be stable, it also required a paid subscription to scale to anything beyond 4 nodes :/
<ybaumy> damn
#juju 2018-03-12
<BlackDex> hello there, i have a juju that has gone out of controll
<BlackDex> it's cpu load i 6 and counting
<BlackDex> 300% cpu usage
<BlackDex> wich is all cpu's
<BlackDex> how can i check what is the issue?
<BlackDex> I tried restarting the bootstrap node, but that didn't resovled the issue
<jam> BlackDex: do you see anything informative in either "juju debug-log" or by ssh'ing to the bootstrap node and tailing /var/log/juju/machine-0.log ?
<BlackDex> not someting i can figure out what is wrong
<BlackDex> the juju debug-log is not responding
<BlackDex> jam: http://paste.openstack.org/show/yw0NXzEMEyXW8rjuZiCu/
<jam> BlackDex: something like "fortress operation aborted" makes me think something internally is failing, causing lots of things to restart, but I think we're missing the root failure in your traceback.
<jam> you could try changing the logging config, with: juju model-config -m controller logging-config="<root>=DEBUG;juju.apiserver=INFO"
<jam> which might make it a bit less noisy
<BlackDex> watcher loop failed: read tcp 127.0.0.1:41456->127.0.0.1:37017: i/o timeout
<BlackDex> oke
<BlackDex> one moments
<jam> BlackDex: so i/o timeout to 37017 is saying that Mongo stopped talking to us
<jam> are you running in HA, or just a single bootstrap node?
<BlackDex> just a single node
<jam> BlackDex: so the other thing to consider is juju version (should be in the top of "juju status -m controller")
<BlackDex> 2.2.4
<BlackDex> it states an upgrade is available
<jam> BlackDex: I know there were several load-related fixes in 2.2.9
<BlackDex> ah
<jam> and even more for 2.3.* but you may want to go 2.2.9 first
<BlackDex> but i can't install that version as a client
<BlackDex> is that a problem?
<jam> BlackDex: you should be able to "juju upgrade-juju -m controller --agent-version=2.2.9" even if your client is older.
<BlackDex> normally i install the updated client first and then the server
<BlackDex> oke
<BlackDex> cool
<BlackDex> lets see what that does
<jam> BlackDex: one caveat is if you're uploading the agent version from the client, rather than downloading it from streams.canonical.com, but that would depend on whether you have internet access, etc.
<jam> Sorry I need to go for a bit, will check back in later
<BlackDex> npt
<BlackDex> np, thx
<BlackDex> this is a good start
<rick_h> magicaltrout: ping, was thinking of showing the updated ssl terminitation charm as a juju show demo Wed and wanted to see if that's ok
<magicaltrout> rick_h: not mine, do what you like :P
<rick_h> oh bah
<rick_h> why do I always confuse you folks in irc?
<rick_h> need a real nickname...like "rick" :P
<magicaltrout> i'm not named after a harry potter movie
<rick_h> how goes magicaltrout? having fun?
<rick_h> magicaltrout: no, just a fish in the zelda game :P like voltfin trout and such
<magicaltrout> busy away, getting some bundle stuff cleared away for our store page the ux folks are working on
<rick_h> magicaltrout: yea, was working with them last week at the sprint. Fun times
<magicaltrout> along with 2 new contracts on random stuff
<magicaltrout> and not being paid since December because of a screw up from the US govt.
<magicaltrout> you know
<magicaltrout> the usual ;)
<rick_h> ouch
<rick_h> anyone home in that us govt? :P
<magicaltrout> they tend to like shutting down then leaving the contractors to keep stuff working, then feel like not paying them for doing so :P
<magicaltrout> have just kicked off an interesting project on cancer early detection with a hospital in upstate NY
<magicaltrout> thats some interesting stuff
<rick_h> magicaltrout: https://youtu.be/UnPI4xKvf0c?t=449
<rick_h> magicaltrout: that's cool
<magicaltrout> https://cancer.jpl.nasa.gov/ a spin off from that
<rick_h> oh man, what was that 80s flick where they take a space ship into a body
<magicaltrout> ha, it is true, trump doesn't like giving jobs to people
<magicaltrout> when all he does it tout employment ;)
<zeestrat> Anyone got some tips on how to further troubleshoot https://bugs.launchpad.net/juju/+bug/1755155?
<mup> Bug #1755155: charm hook failures after controller model upgrade from 2.1.2 to 2.3.4 <juju:New> <https://launchpad.net/bugs/1755155>
<zeestrat> No fun getting stuck after only upgrading the controller model to 2.3.4 when I want to try out the new features!
<BlackDex> jam: It seems that upgrading to juju v2.2.9 did the trick mostly. After upgrading the agents also to 2.2.9 it seemed to settle a little bit.
<vern> does anyone know how I can make juju run an arbitrary command on the controller as part of the bootstrap process? I need to configure the host with a new ca cert so that it can talk to some ssl urls that have certs signed by a company certificate authority
#juju 2018-03-13
<rick_h> vern: so hml is working on that as part of her work enabling a config option for some init commands for just that kind of case
<rick_h> vern: she's out today but might be worth an email to the list perhaps? I'm not up to date on the latest of the work.
<vern> thanks rick_h. for now I was able to ssh in and do the config while the bootstrap was in progress
<rick_h> vern: gotcha
<apes> I tried installing the Canonical Kubernetes installation via conjure-up. Now I've got LXD causing a hard lock on my Ubuntu host when it starts up -- anyone have thoughts on what may be going on?  I've put CPU/Memory/Task limits on the service, and it's still hard-locking.
<blahdeblah> apes: Hard lock as in the machine has become completely unresponsive to ping, ssh, etc.?  If so, make sure you're running an up-to-date kernel, and check logs/console for any kernel oops info.
<apes> blahdeblah: I'm just running it on my local machine -- let me see if it will even respond to ping. Kernel is up to date. There's some stuff in the logs about disks, but I'm not sure if it's related.
<apes> blahdeblah: Here's the relevant syslogs: https://gist.github.com/apeschel/a7b2e08b88c6c24cc6335b20892b5860
<utking> Hi guys!
<utking> Still struggling a bit with openstack and juju
<utking> do any of you guys use gnocchi without ceph?
<BlackDex> what does gnocchi has to do with ceph?
<utking> I was wondering the same thing :)
<BlackDex> haha, so why do you ask?
<utking> we used the telemetry base, and removed anything that had to do with ceph
<utking> but cannot seem to find out how to tell gnocchi to use anything else than ceph
<utking> https://gyazo.com/c4ee1fa9942b5a89e2cc30108cf6eca8
<BlackDex> hmm
<BlackDex> that is an oversight i think
<BlackDex> very bad to in my opinion to force ceph
<BlackDex> but as it looks like now, it forces ceph for the storage
<utking> Yes that's what i thought as well :/
<utking> so i was wondering if you guys know any way to tell it to use local storage instead ^^
<BlackDex> not using the charm i think
<utking> hmm, i see. So we have to scrap that idea as well then? >_< haha, we've been struggling to get openstack up and running for over a month now
<BlackDex> you btw have better luck asking this question in #openstack-charms
<BlackDex> utking: you can ofcourse still deploy ceph
<BlackDex> just use an image file on 3 seperate nodes as storage instead of a blockdevice
<BlackDex> the official documentation supports redis and swift
<BlackDex> of gnocchi that is
<utking> Yeah i know, but we are trying to deploy an "older" classic way of openstack, and then comparing it to a hyper-converged openstack :)
<BlackDex> but doesn't seem to be available for the gnocchi charm
<utking> i saw that
<utking> Been looking through the config files of the charm as well
<BlackDex> else you need to modify the template of the gnocchi config to support an other type of data-storage
<BlackDex> but you don't need to use ceph for instances storage, just remove the relations of ceph to cinder/nova and you will not have a "hyper-converged" env
<BlackDex> just use it for gnocchi storage
<utking> Ah, and still deploy ceph you mean?
<BlackDex> yea :)
<utking> Could do that yes
<utking> hmm, nice, thanks BlackDex! :)
<BlackDex> yw :)
<kumar> hi
<magicaltrout> there's still some pretty funky stuff going on with juju gui, jaas, bundles, machine allocation and so on
<rick_h> magicaltrout: the one issue got a fix landed in the gui and should go out in release soon
<magicaltrout> i just ended up with 3 apps and 6 machines
<rick_h> magicaltrout: is there a backlog for what you mean there?
<zeestrat> rick_h: you run into anything like this when upgrading juju https://bugs.launchpad.net/juju/+bug/1755155?
<mup> Bug #1755155: charm hook failures after controller model upgrade from 2.1.2 to 2.3.4 <juju:New> <https://launchpad.net/bugs/1755155>
<rick_h> zeestrat: hmm looking. There was an upgrade bug that thumper fixed that missed an upgrade step when jumping versions but I thuoght that was in 2.3.4. Let me double check
<rick_h> lol zeestrat https://bugs.launchpad.net/juju/+bug/1746265 was what I was thinking but guess that's not the same
<mup> Bug #1746265: juju-upgrade from 2.2.9 to 2.3.2 fails with state changing too quickly <upgrade-juju> <juju:Fix Committed by jameinel> <juju 2.2:Won't Fix> <juju 2.3:Fix Released by jameinel> <https://launchpad.net/bugs/1746265>
<zeestrat> rick_h: Nah, that looked to be fixed in 2.3.4 as we didn't see those those in staging.
<rick_h> zeestrat: yea, that was in 2.3.3
<rick_h> zeestrat: I'll ask around. let me see what I can do
<zeestrat> rick_h: thanks a bunch. If there's any further info or troubleshooting needed just shout. Kinda need to get this one unstuck :)
<rick_h> zeestrat: no doubt
<rick_h> zeestrat: I pinged someone on the juju team about it and they're going to get it some eyeballs.
<rick_h> zeestrat: sorry, folks just getting back from travel has the eyeball count a little light the last few days but getting on it
<zeestrat> rick_h: No problemo, thanks for asking. Juju agents are rather hardheaded so they'll keep on retrying in the mean time ;)
<rick_h> zeestrat: yea :/
<SuneK> I have a case where the kubernetes-master node is in a waiting state, it gives the following message "Waiting to retry addon deployment". Etcd is running just fine.
<SuneK> Rebooting and restarting snap services doesn't help
<SuneK> Any ideas?
<magicaltrout> boo he went
<magicaltrout> i hja
<magicaltrout> had the same
<rick_h> magicaltrout: yea? kwmonroe / tvansteenburgh ^
<magicaltrout> yeah, although in the end i just switched off the dashboard and dns via juju config
<magicaltrout> and then switched them back on
<magicaltrout> seemed to fix it
<kwmonroe> hm, ryebot mentioned something about kubefed having trouble.. maybe ^^ that's the issue?
<ryebot> hmm
<ryebot> SuneK: magicaltrout did that persist no matter how long you waited?
<ryebot> oops, just magicaltrout I guess
<magicaltrout> i got bored after about 15 minutes
<magicaltrout> if that helps
<magicaltrout> on a different note
<magicaltrout> juju add-ssh-key blah..... juju ssh 9... unauthorized
<magicaltrout> have i missed a step?
<rick_h> magicaltrout: hmm, nope...should show the key in .authorized_keys
<magicaltrout> hmm weird
<magicaltrout> we gave a colleague access to a controller
<magicaltrout> juju status works
<magicaltrout> we've added his key, i can see it on the remove units and we can login using ssh ubuntu@....
<magicaltrout> using that key
<magicaltrout> but juju ssh 9.. for example says "unauthorized access"
<rick_h> ? is it what you think it is?
<magicaltrout> is that a question or a prohetic statement?
<magicaltrout> we have tested a default key and a newly generated one both do the same
<magicaltrout> i'm assuming its something we've done but its a bit weird
<rick_h> heh, I mean that using juju ssh 9 maybe isn't the model you think it is or something?
<rick_h> I'm not sure, as you note if you can ssh ubuntu@... then not really sure what juju is doing different for you there that would fail
<magicaltrout> well
<magicaltrout> juju status shows us all the machienes/units etc
<magicaltrout> so i'm assuming juju ssh will then access the correct box
<magicaltrout> https://gist.github.com/buggtb/89252ab1a378dd5c3a48ab372c5e71fd
<magicaltrout> tried the same with unit names as well
<magicaltrout> same output
#juju 2018-03-14
<Hey__> is it possible to deploy windows 10 as a juju charm on bare metal?
<bdx> Hey__: technically yes
<Hey__> hmm.
<Hey__> I would expect technically.. yes
<Hey__> bdx: would you say this is not a very useful application of juju?
<bdx> Hey__: read the "Enterprise support for MAAS" section https://maas.io/
<bdx> Hey__: its a great way to deploy Win to bare metal .... you just have to have support, if get the support package then its possible and super useful for those doing windows deploys
<Hey__> point taken.
<Hey__> understood.
<Hey__> bdx: your saying it's only possible with support?
<bdx> Hey__: for sure it is
<Hey__> is there a feature that is not enabled.. or you saying I'm gonna have to roll my own?
<bdx> neither ... you must pay $$
<bdx> you can use maas all day long to roll your own deploys of ubuntu and centos
<Hey__> bdx: I noticed that.
<Hey__> I was reading that I need to customize an init for it to work with Maas
<bdx> for what to work with MAAS?
<Hey__> Creating the windows image I wish to deploy
<bdx> ahhh yeah ... you may encounter many unforeseen issues and processes that are not documented trying to do the things in the $$ tiers
<bdx> but hack away!
<bdx> don't let me stop you :)
<Hey__> lol
<bdx> does JAAS have controllers in every region? e.g. if I spin up an instance in eu-west-2, will the Juju agent on that instance talk to a JAAS controller in eu-west-2, or are there only controllers in some regions?
<SuneK> kwmonroe, how is your work on vsphere support faring? The 1.9.4 upgrade breaks vsphere cloudprovider support for CDK, so I'm pretty much in limbo here.
<rick_h> one hour heads up until Juju show #31 kwmonroe hml bdx cory_fu magicaltrout and anyone else interested
<rick_h> cory_fu: going to cover the charm changes if you can make it
<cory_fu> rick_h: Sure
<cory_fu> rick_h: By charm changes, you mean the changes to layer:basic?
<rick_h> cory_fu: rgr, call out to folks on actions, etc
<rick_h> cory_fu: does that effect juju run as well?
<cory_fu> rick_h: Should be completely transparent to juju run
<rick_h> cory_fu: cool
<cory_fu> Except in the very edge case of charms installing Python libs that have CLI tools that they use
<rick_h> cory_fu: right, like a juju run to execute a django scipt or something is what I was thinking
<cory_fu> rick_h: So the work-around would be: juju run unit/0 -- charm-env myscript args
<rick_h> cory_fu: yea, or setup make to call the script with the right env and such. Just want to note it out so folks recognize 'wtf'
<rick_h> juju show 20min warning
<rick_h> get your coffee and tea ready to go
<rick_h> the "join the fun" url is https://hangouts.google.com/hangouts/_/atvgoe55qra33nvrw5ogthx6eye
<rick_h> and the "watch the fun" url is https://www.youtube.com/watch?v=Zp9DIQ-0NI4
<cory_fu> ryebot: Juju show?
<cory_fu> Cynerva: Perhaps?
<rick_h> party people, starting in 3...
<ryebot> can't, stuck on phone internet until next week
<rick_h> bdx: what kind of coffee are you making :P
<wpk> hm, how to set TRACE logging for some modules for bootstrap?
<zeestrat> Hey question for the show. Any hope for some charmhelpers docs love? https://github.com/juju/charm-helpers/issues/27 Where are y'all getting your docs fix currently if not on pythonhosted.org/charmhelpers?
<kwmonroe> doh!  sorry zeestrat, we missed your question.  bad rick_h.
<rick_h> oh damn
<rick_h> sorry zeestrat! I don't know if cory_fu are we using the pythonhosted docs or I know there's some patches going into the jujucharms.com docs around this lately?
<cory_fu> rick_h: I noted on that issue that PythonHosted.org is deprecated, and it's actually reached the point that you can't even update docs on it any more.  We need to move to ReadTheDocs.io, but I don't have access to that repo to enable it.
<rick_h> cory_fu: oooooh
<cory_fu> rick_h: It would also be really great if jujucharms.com/docs/ could also host Python library docs, but they're in a completely different format have different themes, so I don't see that being feasible any time soon
<rick_h> cory_fu: yea, so the jujucharms.com/docs are moving to docs.jujucharms.com and on the standard ubuntu docs setup
<rick_h> cory_fu: like maas and other products
<cory_fu> Maybe we should open a jujucharms.com doc issue to create a Sphinx theme that matches JujuCharms.com and then have a way to hose the library docs there
<rick_h> cory_fu: but yea, don't think it's going to be readthedocs compatible that I'm aware of
<rick_h> cory_fu: bug antdillon about it and see if there's something they can do
<cory_fu> rick_h: RTD is pretty much the standard for Python libraries now, anyway, so I don't think it's terribly urgent to have them co-hosted on docs.jujucharms.com and it would be quite a bit of work
<cory_fu> Still, having a Juju theme for Sphinx in and of itself would be pretty awesome
<rick_h> cory_fu: yea just not sure what's easy vs hard with their setup. Figure it's worth a mention.
<cory_fu> zeestrat, rick_h: Oh, shoot.  It looks like javacruft might have given me access when I originally commented on that issue and I just never realized it
<zeestrat> Oops!
 * cory_fu goes to enable RTD for charmhelpers.
<zeestrat> Awesome. Maybe check out if there's any way to redirect from pythonhosted or remove it somehow to optimize those Google results
<cory_fu> zeestrat: Unfortunately, I've looked into that already.  There's no way to do the redirect.  Best I can do is remove the docs from PythonHosted entirely and add a link to the new docs in the README
<bdx> https://unixsurplus.com/collections/4u-servers-1/products/freenas-server-36-bay-supermicro-4u-2x-e5-2680-2-8ghz-192gb-2-port-10gbe-sfp-nic - these are the chassis I'm using for my ceph
<bdx> 5 x ^
<rick_h> bdx: niiiiice
<rick_h> bdx: full disks ?
<bdx> yeah 6T
<bdx> 36*6T*5 = 1080T
<bdx> not sure how it will be replicated and all, so I don't know what my usable will be .... possibly will have to swap out some of the hhd for ssd to use as journal, cache pool etc
<bdx> I'll be doing a little write up on it
<bdx> rick_h: I'll be sure to keep you posted
<zeestrat> bdx: On their way or already got them? We've been running pretty similar chassis/MB for a about a year with ceph.
<bdx> on thei rway
<bdx> zeestrat: are yours filled with spinning disk only?
<zeestrat> bdx: Yeah, we've been doing spinners only for that seutp. Got 12 boxes with 12x8TB regular 7.2k and 12x8TB SMR archive disks in each. 8 more on the way now. The latter disks are a fun experiment in trying to get real cheap ceph workloads on SMR disks.
<bdx> I see
<zeestrat> We've been looking at how we want to do ssd pools and will probably end up with other nodes with just ssd's though you quickly end up hitting network bottlenecks there.
<bdx> zeestrat right ... been there
<zeestrat> Used a lot of SuperMicro before?
<bdx> yeah
<bdx> I've had to beef up the networking for ssd ceph clusters too .... totally hit that first hand
<bdx> zeestrat: I ordered them full of spinning disk so I can get baseline metrics with full spinning disk with journal on the osd drive
<bdx> zeestrat: then I'm just going to iterate from there
<bdx> making one change at a time and benching inbetween each change
<zeestrat> Sounds like a plan. Will be fun to hear about your experiences. The ceph charms have been getting a bit more love lately.
<bdx> yeah, so legit
<bdx> zeestrat: I have 5 racks all in a row, my plan is to just build ceph, and the rest of the openstack evenly across the 5 racks
<bdx> the ceph nodes across the bottom, 10G networking across the top, and compute in the middle
<bdx> I've already go the HA MAAS going on (deployed via my maas charms)
<bdx> I know there will be a workload upgrading that maas and doing the whole bionic dance
<zeestrat> Yeah that's pretty much what we did, though started with 3xHA over 3 racks
<bdx> cool
<zeestrat> HA in MAAS for region controllers was more pain than I wanted though when we started with Maas 2.1 so planning to just drop that to 1 region and just do multiple rack controllers
<bdx> zeestrat same
<bdx> its much nicer now in 2.3
<bdx> but there is still the proxy issue
<bdx> in the sense that you have to mitigate things manually that aren't immediately obvious when setting up ha maas
<bdx> zeestrat: I tried to address a good amount of those paper cuts and bumps in the road in my rendition of the maas charm
<bdx> zeestrat: https://jujucharms.com/u/omnivector/maas/1
<zeestrat> Cool. I'll check it out. I guess I was hoping for something a bit more opinionated or ready packaged but I guess I'm just spoiled.
<zeestrat> *regarding the maas ha docs that is
<bdx> zeestrat: right, they want paying customers
<zeestrat> :)
<zeestrat> Not us freeloaders right?
<bdx> aha right
<zeestrat> Speaking of SuperMicro. The cluster I mentioned above was my first rodeo with them (both using and procuring) so I presumed those BMC's would have a nice and easy way to update BIOS firmware from the CLI or web just like iDRAC which I was used to. Was a fun day at the office (and not DC) and I wanted to do just that and I found out you need buy this separate OOB license to do that. So now every time I hear someone
<zeestrat> (like you mentioned above) buying SuperMicro, I instinctively want to tell them "remember to buy those damn licenses".
<bdx> zeestrat: thanks for the heads up, I'lll look into this
<zeestrat> bdx: sft-oob-lic is the part#. Everything else works fine in the web interface, but BIOS (and perhaps BMC itself, I can double check if you want) upgrades via web are locked down. There are workarounds/hacks, but those licenses paid for themselves pretty quickly.
<bdx> zeestrat: how do I know if I need it? Possibly it is already the latest?
<zeestrat> bdx: We have a bit newer MB and I'm having a hard time finding anything on the SuperMicro specs page about what's included with OOB mgmt. It wasn't included with ours (X10DRi-T) though that's might be just our VAR forgetting.
<bdx> zeestrat: this sounds like a darn rat trap
<zeestrat> bdx: Welcome to supermicro.com. If it's important on day 1, I'd ask your seller/VAR or just support@supermicro.com directly.
<bdx> zeestrat: so .. yeah purchasing these from unixsurplus .. outside of our vendor
<bdx> zeestrat: I have 1 of them already ... it appears to be functioning just fine, how can I tell if I need the update?
<cory_fu> zeestrat: https://github.com/juju/charm-helpers/pull/131
<zeestrat> cory_fu: Great stuff. Thank you very much!
#juju 2018-03-15
<morty> any way to deploy browbeat with juju?
<rick_h> morty: hmm, I don't see any charm for that. Might be worth an email to the juju list and see if anyone's working on one that they've not made public yet.
<morty> alright, thanks rick_h :)
<TheAbsentOne> What is actually the best way to create a file with the reactive framework? Is there an example somewhere that shows what the cleanist approach is?
<stokachu> TheAbsentOne, like a charm that uses reactive?
<TheAbsentOne> stokachu: yes! I want to create (what should be) a very simple charm. Let's say it runs apache or nginx, installs php and I want to create a phpfile with only phpinfo() function. What would be the best approach inside the python charm code?
<TheAbsentOne> And the same for copying pre-existing files (no templates, just files ready to be copied)
<stokachu> TheAbsentOne, i think resources is what you want for the files to be copied
<stokachu> TheAbsentOne, https://github.com/battlemidget/juju-charm-ghost thats my example one
<stokachu> uses resources and reactive
<TheAbsentOne> aha nice thanks for the help stokachu
<fallenour> hey everyone. Im having issues with my browser consoles loading in openstack. I looked into: juju config openstack-dashboard, but I dont see a setting for SPICE. I think I need to change a setting in there from AUTO to SPICE in order to fix the problem as per this: https://ask.openstack.org/en/question/26123/horizon-sends-wrong-rest-request-when-spice-is-enabled/ but im not sure. I think the issue may be my console is trying to load 
<fallenour> instead of the DNS name as well. I did notice that the browser keeps trying to load a 10.X address instead of the DNS name. Your thoughts?
<fallenour> address bar: 10.0.0.16:6082/spice_auto.html?token=d5ff7eaa-d411-4595-b315-e8eba399fdf6&title=test2(73f3e8f3-b5f6-4f8c-93ac-9bc78bfa35a8)
<fallenour> Ok so I think I have a better handle on the question, my problem is the direct opposite of this: https://ask.openstack.org/en/question/58938/dashboard-problem-with-url-of-vnc-console/ My client is Spice
<kwmonroe> admcleod_ or beisner, got any suggestions for fallenour ^^  i dunno what config the openstack dashboard supports
<fallenour> kwmonroe: from what I can tell, based on juju config openstack-dashboard, quite a lot. Do you think it might be easier to convert everything to a DNS based process isntead of an IP based one. Even if I did, would it stop the placement of IP addresses for the console URL?
<beisner> hi fallenour kwmonroe - the vnc/spice console settings are a nova config, set on the nova-cloud-controller charm.  ref: https://github.com/openstack/charm-nova-cloud-controller/blob/master/config.yaml
<fallenour> beisner: So i checked at console access protocol, and it shows spice, so spice is configured correctly in that regard, what would make it change from a DNS name to an internal IP address? and how would I change that?
<fallenour> also, for reference: juju config nova-cloud-controller console-access-protocol is the command, with the respective setting for those who dont know
<beisner> fallenour: are you able to access the ip address from your local machine?  mine generally gives an ip address in the url.
<beisner> it is the unit ip address of nova-cloud-controller that terminates the console addresses
<fallenour> beisner: No, the initial address is a wan routable DNS address. It then converts from a DNS address to the IP internal, which screws the pooch. Anythoughts?
<beisner> fallenour: what ip does the initial dns address resolve to?  i think the assumption for console access is that you can also reach the nova-cloud-controller address.
<beisner> (when using the default console proxy == local)
<fallenour> horizon.eduarmor.com/horizon -> http://horizon.eduarmor.com/horizon/project/instances/73f3e8f3-b5f6-4f8c-93ac-9bc78bfa35a8/ -> http://10.0.0.16:6082/spice_auto.html?token=578c2277-0899-46a6-b077-eab257d39bee&title=test2(73f3e8f3-b5f6-4f8c-93ac-9bc78bfa35a8)
<fallenour> The nova cloud controller IP is: 10.0.0.16
<fallenour> so its using the nova-cloud-controller to connect to the session.
<fallenour> oops. beisner sorry*
<fallenour> beisner: meant to @ you earlier with the previous. So yea, what are your thoughts? Do I need to change here? Im not sure exactly how to fix this issue whiel also keepign access wan routable
<beisner> fallenour: Yes, exactly.  You have to be able to reach that address, whether resolved via DNS, or directly called by IP, when using 'local' for the console proxy.
<fallenour> beisner: what is the easiest way to eliminate this issue? Without making major changes more sepcifically/hopefully?
<beisner> fallenour: I take it that address isn't accessible/routable from the machine you're trying to use for a console client?
<fallenour> beisner: I can make it WAN accessible via a loadbalancer if necessary. I guess my question with that is what setting(s) would I need to change to implement that?
<fallenour> I take it I would need to: HAproxy -> Nova-Cloud-Controller
<fallenour> Id need to set a route any rule for HAproxy because I dont knwo what port itll send to, and id need to give the nova-cloud-controller a DNS name
<fallenour> beisner: that should get the traffic into the network, but my question is, what, if anything, will that break on openstack? Also, just because I pass the traffic, does that stop it from trying to route to the IP via console? how do I fix that issue?
<fallenour> beisner: how do I make it go from 10.0.0.16:xxxx to novacloudcontroller001:xxxx via juju config nova-cloud-controller / juju config openstack-dashboard ?
<beisner> i'm not aware of a config to achieve that, fallenour
<fallenour> beisner: so theres no way to have it try to terminate at the novacloud controller via its dns name instead of its IP address?
<beisner> fallenour: all of the use cases i've been in, and all of the docs for vanilla openstack upstream reference nova_ip:port as the method of reference.
<fallenour> beisner: I did find this: https://ask.openstack.org/en/question/58938/dashboard-problem-with-url-of-vnc-console/ which is the complete opposite of what we are trying to do
<fallenour> beisner: so then how do people normally access the consoles?
<fallenour> beisner: sorry, via WAN. Becuase unless you were on the network, it wouldnt be possible to route to an internal addresss. If nothing else, you dhave to give a nova-cloud-controller a wan ip address to make it work?
<beisner> https://docs.openstack.org/nova/latest/admin/remote-console-access.html#spice-console
<beisner> specifically: "Replace IP_ADDRESS with the management interface IP address of the controller or the VIP."  translate:  the ip address of the nova-cloud-controller unit.
<beisner> (or if HA, the VIP of nova-cloud-controller)
<fallenour> beisner: yea, I saw that. Hmm...do you think if we just "put" a dns name there, that itd work?
<beisner> fallenour: if you want to access this from the outside of the next hop on your network, that would likely be configuration of routers outside openstack.  ie. port forwarding, nat mapping, etc., on whatever is separating the networks.
<fallenour> beisner: I mean, I knwo the documents SAY it requires an IP, but has anyone actually tried via a DNS name?
<beisner> no, i think if you can't get to the IP address directly from the client machine right now, no DNS tricks on the planet will solve that.
<beisner> ie. if the L3 address is not routable, it's not routable, and you'd have to address that.
<fallenour> beisner: what about the second idea? make it WAN routable
<beisner> i doubt you want your nova-cloud-controller ip address on a wan
<fallenour> beisner: yea that was my thought to. i see that ending...badly
<beisner> haha right!?
<fallenour> beisner: it was make one hell of a news story though XD
<beisner> apologies, have to step away for an appt
<fallenour> beisner: its alright. Ill see if I can figure out a way to make an internal IP internally routable without know what port itll be on
<beisner> no pressure ;-)
#juju 2018-03-16
<Stormmore> Miss me?
#juju 2020-03-10
<stickupkid> this is interesting, never spotted this in github - https://github.com/juju/python-libjuju/network/dependents?package_id=UGFja2FnZS01MjI0MzQ2NA%3D%3D
<stickupkid> see whom is a dependant on pylib in github
<rick_h> hah that's cool
<rick_h> though seems odd layers are depending on it. Maybe testing/etc?
<achilleasa> did we make any watcher-related changes to develop? I am getting lots of random watcher-related test failures on CI
<rick_h> achilleasa:  lots of thumper stuff around watchers?
<rick_h> stickupkid:  what's up with the root job build queue listing the nw-deploy-eoan-amd64-lxd a ton of times? Any ideas?
<stickupkid> wow
<rick_h> stickupkid:  yea, cancelling them up right now
<stickupkid> looks like this is 2.7 issue
<stickupkid> no wait, I'm wrong
<rick_h> ok, cleaned those out...
 * rick_h moves to internal chat
<skay> I added a postgresql unit after ripping out the old one and this one's status message is 'Installing wal-e snap' and it's been like that for quiet a while now
<skay> how do I get it unstuck?
<achilleasa> rick_h: for the remote-lxd use-case can we assume that the client can _always_ talk to the remote-lxd or do we assume that only the local controller can do so (e.g. very strict fw rules)?
<stickupkid> we want both right?
<achilleasa> for juju login the fingerprint fetch/check happens client-side whereas for the above I could imagine that this might not always be possible (for the remote)
<rick_h> achilleasa:  yes, in this sample case the client probably can, but not always
<rick_h> achilleasa:  right, I think that's jam's point is that our lxd uses are very client driven
<rick_h> achilleasa:  and so the logic isn't avilable on the server side when running add-cloud to a different controller
<rick_h> achilleasa:  however we can't trade one use for for the other. In the end we need both
<rick_h> achilleasa:  but it's a bit of work. I'd prefer if we identify issues, file bugs, and see what we can do to unblock folks vs biting the whole thing off
<stickupkid> achilleasa, what rick_h said
<stickupkid> :)
<rick_h> achilleasa:  as I think there's a lot in there. You can see the same story with things like maas checking endpoints when you add-cloud a maas, or the same sanity checks we do with openstack when you add an openstack cloud
<rick_h> achilleasa:  there's a fundamental design we've missed in that juju add-cloud local vs to a controller should be more in line
<rick_h> it's just one more thing in "multi-cloud controller makes life interesting"
<stickupkid> rick_h, achilleasa maas is client only, yeah - that was a big miss
<rick_h> stickupkid:  achilleasa so from my PoV I'd like to identify how it should be "done right" and spec/file bugs on that vs trying to just make the lxd case work better
<stickupkid> rick_h, achilleasa agreed, it's not just LXD as you pointed out
<achilleasa> still investigating... for the lxd case in particular, the fix must live in the controller (in the lxd provider to be precise). however, my question is whether we could have our client try to connect to the remote (its endpoint is known to the client)
<rick_h> achilleasa:  no, because it's no promise the controller will work from where it sits
<rick_h> achilleasa:  this case of adding a lxd cloud to a k8s controller is the perfect example. Nothing says those two work together
<rick_h> achilleasa:  and the client is the perfect middle man providing the "best case" vs the worst one
<rick_h> stickupkid:  you free for a sec then if you're still around?
<achilleasa> still, the problem (as far as this bug is concerned) lies in that lxd behaves in a certain way (jam has linked an issue where they explain why it is implemented like this) which means that we need to do a custom TLS verification step
<rick_h> before I break CI to bits?
<stickupkid> rick_h, yeah in daily
<achilleasa> (just as lxc does)
<stickupkid> rick_h, i'll trade you for writing tests in goose
<achilleasa> happy to jump in on a HO later to explain my proposal for a solution (that may be applicable to other providers)
<rick_h> achilleasa:  it'd be good to write up (tomorrow maybe, getting late) and that way more folks can comment/discuss
<rick_h> I think jam, wallyworld, etc would like to think about it as well
<achilleasa> rick_h: as a discourse post or an email?
<rick_h> achilleasa:  either/or
<achilleasa> argh! still cannot replicate the TLS validation issue with remote lxd. I will ping John tomorrow for more details and try with k8s
<thumper> morning
 * thumper waves at alexisb
<thumper> alexisb: I hope you and family are staying healthy
<rick_h> morning thumper
#juju 2020-03-11
<evhan> thumper: I think it was you who recommended No Such Thing as a Fish a while back? If so, thank you, it's hilarious.
<thumper> evhan: no worries, I love it too
<tlm> wallyworld: when you get back I have a question for you
<timClicks> eyes are welcome on a "feature matrix" doc for providers (k8s compatibility and OS support to come) https://discourse.jujucharms.com/t/juju-feature-and-compatibility-matrix/1589
<wallyworld> tlm: what's up?
<tlm> got time for HO ?
<tlm> wallyworld:
<wallyworld> sure
<wallyworld> tlm: am in standup
<tlm> k
<wallyworld> kelvinliu: you'll let me know when our PR is ready again for review?
<kelvinliu> wallyworld: stil fixing tests.
<wallyworld> no worries, just wanted to mnake sure i wasn't blocking you
<kelvinliu> wallyworld: mostly done!
<kelvinliu> almost.
<wallyworld> manadart: this got accidentally left off the 2.7-current fork. had already landed into 2.7. so re-proposing my (landed) branch against 2.7-current. can you pretty please +1 or whatever? https://github.com/juju/juju/pull/11305
<kelvinliu> wallyworld: it's ready to review now.
<wallyworld> kelvinliu: ty, looking
<kelvinliu> ty
<manadart> wallyworld: Ticked it.
<achilleasa> manadart: can you also take a look at https://github.com/juju/juju/pull/11261. The CI gods have finally deemed it worthy of a green tick
<manadart> achilleasa: Sure.
<manadart> achilleasa: Approved it with a few minor things.
<achilleasa> manadart: I have addressed your comments so I will go ahead and merge
<manadart> achilleasa: Yup.
<hml> achilleasa:  do you have a few minutes?
<achilleasa> sure
<achilleasa> daily?
<hml> achilleasa: omw
#juju 2020-03-12
<narispo> hi, what can one do to deploy a recent hadoop/spark/solr/hbase stack? Apache Ambari ships Hadoop 2.7, Apache Bigtop, Hadoop 2.8, Slor 6.5. Jujucharms are based on Bigtop so also ship these unsupported/outdated/with-unfixed-cve versions.
<narispo> Solr *
<thumper> narispo: to be honest I'm not sure, but perhaps ask on our discourse?
<narispo> thumper: I guess. Should probably reach to Canonical sales/engineering directly.
<thumper> narispo: canonical doesn't own those charms as far as I'm aware
<narispo> bigdata-charmers is community work?
<thumper> ah... I think it is at the moment...
<thumper> it didn't used to be
<rick_h> thumper:  narispo yes, it's community work
<rick_h> we've got some close folks in the community that leverage them but there's no team in canonical that maintains them
<narispo> rick_h: okay! well I'm looking into improving Bigtop itself with version upgrades right now so that we can deploy a recent Hadoop cluster. We care about Spark, Solr, HBase, with Hadoop. So Bigtop's next release (1.5) plans to update to Solr 6.6 (unsupported, very bad, latest is 8.4.1), Spark 2.4.5 (latest, very good), HBase 1.5 (outdated, bad, latest is 2.2.3), and Hadoop 3.2.1 (latest, very good).
<narispo> So that gives me HBase and Solr to look into and upgrade inside Bigtop.
<rick_h> narispo:  yea, I think you're finding the ones more used (up to date) and less used (out of date). It'll be awesome to have them brought up to speed. Thanks!
<narispo> rick_h: another disadvantage is that Bigtop doesnt seem to do patch releases.. so individual components may stay vulnerable to security issues for months until the next Bigtop release is out.
<narispo> And that includes the big ones used by tons, such as Spark or Hadoop.
<thumper> https://github.com/juju/juju/pull/11310 for anyone that wants a faster juju status
<tlm> can take a look in a bit thumper just wrapping something up
<thumper> tlm: thanks
<tlm> lgtm thumper
<thumper> tlm: thanks
<thumper> I'll merge it once the 2.7.4 release branch has merged it
<thumper> s/it/in/
<babbageclunk> uh, what's happening with the 2.7 merge run?
<babbageclunk> https://jenkins.juju.canonical.com/job/github-make-check-juju/4364/console
<babbageclunk> looks like dep has hung?
<thumper> babbageclunk: it has only been going two minutes
<babbageclunk> oh duh, missed that it was new
<babbageclunk> that would do it
<thumper> :)
<thumper> it's off and racing
<achilleasa> rick_h: is it even possible for a unit to depart a peer relation?
<rick_h> achilleasa:  ...thinking. The destroy process always confuses me because there is "I'm going away"
<rick_h> achilleasa:  but it's not like a relation you can choose to opt out of
<achilleasa> yes, with the relation-created changes units will automatically be in a peer relation (even if they are is only a single unit)
<rick_h> achilleasa:  right, makes sense
<achilleasa> hml: just to confirm, the TODO in `runCharmProcessOnRemote` in 11257 will be handled with an upcoming PR, right? I remember seeing a comment in the other PR
<hml> achilleasa:  yes
<hml> achilleasa:  working on the unit tests for the pr that resolves the TODO now
<achilleasa> hml: I think 11257 is good to go with your changes. Running the QA steps
<hml> achilleasa:  cool, ty
<achilleasa> hml: is this passing for you? WorkerSuite.TestInvalidDeploymentChange
<hml> achilleasa:  checking
<hml> achilleasa:  yes.  running with stress script
<hml> achilleasa:  130 successful runs
<achilleasa> hml: 11257 approved
<hml> achilleasa:  awesome!  ty
<achilleasa> hml: if you push the other one later today assign it to me so I can review it in the morn
<hml> achilleasa: ack
<wallyworld> kelvinliu: tlm: bug 1867168 ... why would they be connecting to pods and not the service? I want to push back and tell them to use the service front end. do you agree it's bad k8s practice for extermal actors to use the pods and not the service?
<mup> Bug #1867168: No easy way to retrieve pod fqdn <juju:New> <https://launchpad.net/bugs/1867168>
<tlm> taking a look
<tlm> wallyworld: want me to reply to it ?
<wallyworld> tlm: do you agree with my assertion?
<tlm> yep, there is use cases for what they want but there is an accepted way todo this through multiple services
<wallyworld> tlm: gr8, if you could suggest the approach that would be good
<tlm> wallyworld, we could implement what they want FYI
<wallyworld> we could but would prefer not to if it's bad practice
<wallyworld> we support valueRefs now etc, i asusme we'd use that if needed
<tlm> do we support multiple services ?
<wallyworld> or they could use that, assuming k8s exposes such info that way
<kelvinliu> probably they want to maintain the mongodb replica set connection string
<tlm> the cases where I have seen this is where you have a db replicas and want to talk to masters and or slaves
<tlm> but the solution has always been run two services
<wallyworld> we support a core service for the app plus a headless one
<tlm> or n services
<tlm> want to HO this before I finish reply ?
<wallyworld> sure
<babbageclunk> anastasiamac: could you take another look at https://github.com/juju/juju-restore/pull/8? I've made changes from your comments and also added getting ha-nodes from the backed-up agent.conf
<anastasiamac> babbageclunk: looking
<babbageclunk> thanks!
#juju 2020-03-13
<thumper[m]> added
<tlm> matrix thumper
<thumper[m]> I've added a #juju channel in matrix.org with an IRC bridge
<timclicks[m]> removed it from the juju-devops room I created
<thumper[m]> Just messing around testing just now
<tlm[m]> howdy
<thumper> it looks like the matrix bridge only creates users on demand...
<timClicks> I think we confused the bot because there were two matrix rooms bridged
<thumper> have you removed the second one?
<thumper[m]> https://github.com/juju/juju/pull/11313 up for review
<TimM[m]> <thumper "have you removed the second one?"> yes, that room is now empty
<tlm[m]> thats working
<TimM[m]> lol yup
<thumper[m]> uh ha, I see many new folks
<thumper[m]> also, I was curious as to how the reply would look in irc
<TimM[m]> pretty keen to charm up a matrix home server now
<tlm[m]> was having the same thought
<thumper[m]> I think ec0 has done that
<thumper[m]> or at least some aspects of that
<TimM[m]> https://github.com/alchemy-charmers/charm-matrix
<ec0[m]> yep, that one :)
<ec0[m]> Tim M:
<ec0[m]>  * Tim M: let me know if you get stuck on it
<ec0[m]> there's still some rough edges but the snap stuff has been merged upstream, and the charm does deploy a working homeserver
<TimM[m]> I was thinking about Juju for web workloads, and discovered that the latest series that fail2ban supports is trusty
<TimM[m]> I made several edits yesterday after work and I have it working for more recent series also
<TimM[m]> it's still based on charmhelpers, but that can change too over time
<wallyworld> timClicks: just saw this "Controller independent of the k8s cluster: A Juju controller must sit outside of Kubernetes."
<wallyworld> in the mapping juju concepts
<timClicks> Oh right, yes I meant to clarify that
<wallyworld> that's no longer true
<wallyworld> used to be early on
<timClicks> Cool, I thought so, will update
<wallyworld> ty
<tlm[m]> wallyworld kelvinliu pushed up the tmp work around
<kelvinliu> yup, will have a look, ty
<thumper> wallyworld: this is the PR we talked about https://github.com/juju/juju/pull/11313
<wallyworld> sorry, getting to it, will look now
<thumper> ack
<wallyworld> thumper: lgtm. love deleting tests from state
<thumper> thanks
<wallyworld> if we delete enough, maybe no more timeouts
<thumper> if we move the check tests to github actions, we may have the same
<wallyworld> indeed
<TimM[m]> ec0:  here is the fail2ban charm I was talking about https://github.com/timClicks/fail2ban-charm
<stickupkid> manadart, did you land the model cache changes in 2.7 or 2.8 ?
<stickupkid> manadart, https://mail.google.com/mail/u/0/#inbox/FMfcgxwGDNVHpPHvPqQWhcTLDkdQLjNz
<stickupkid> manadart, https://bugs.launchpad.net/juju/+bug/1860970
<mup> Bug #1860970: SetCharmProfiles is called too frequently <juju:Triaged> <https://launchpad.net/bugs/1860970>
<stickupkid> manadart, wtf is this https://github.com/juju/juju/pull/11279#issuecomment-598669584 ?
<manadart> Â¯\(Â°_o)/Â¯
<stickupkid> silly bot
<manadart> stickupkid: Got a sec for https://github.com/juju/juju/pull/11316 ?
<stickupkid> manadart, done
<manadart> stickupkid: Ta.
<hml> stickupkid:  why does https://github.com/go-goose/goose/pull/82 include the deprecated commit as well?  got really confused in review.  :-D
<rick_h> sorry achilleasa looking
<stickupkid> hml, I wanted to rebase once deprecated one has landed
<stickupkid> :)
<achilleasa> rick_h_: so I am nearly there with the relation-created hook https://pastebin.canonical.com/p/CJkg76rpKS/ I am still trying to get rid of that spurious relation-departed hook
<achilleasa> is this the right order of hooks? install, xxx-relation-created, leader-elected, ... ?
<rick_h> achilleasa:  yea, so after the install (deps/etc are available on the system) and before leader-elected. So that it can check if there are/will be other units coming in.
<stickupkid> rick_h, achilleasa manadart https://github.com/juju/juju/pull/11317
<achilleasa> rick_h: and this is how it looks for the non-leader unit: https://paste.ubuntu.com/p/3vGczmCQ7v/
<stickupkid> rick_h, exactly, doing that step now
<rick_h> achilleasa:  cool!
<stickupkid> rick_h, offically /usr/bin/env python should work, but it doesn't - shame
<rick_h> stickupkid:  well it's not "python" it's python3
<rick_h> that works
<rick_h> the thing is that if you want it to work you'd have to symlink python3 to just python
<rick_h> it's the "official way"
<stickupkid> :(
<rick_h> stickupkid:  for our purposes, given we know the system, we should just prefix the .py script command in the dh with the right python for the system
<rick_h> stickupkid:  e.g. HOME=obj-x86_64-linux-gnu/home /usr/bin/$PYTHON /<<PKGBUILDDIR>>/src/github.com/juju/juju/scripts/generate-docs.py man -o obj-x86_64-linux-gnu/juju.1
<rick_h> where $PYTHON is figured out with shell foo for "should it be path to py2 or py3"
<stickupkid> rick_h, yeah, works for 2.7 and 3 https://github.com/juju/juju/pull/11317/files
<hml> stickupkid: approved 81
<hml> looking at 82
<achilleasa> hml: can you take a look at https://github.com/juju/charm/pull/305 ?
<hml> achilleasa:  will do after current review in progress.  :-)
<achilleasa> hml: not in a hurry
<hml> stickupkid: 82 is approved with some suggestions.
<manadart> Bionic packages for 2.7.4 are in stable. Confirmed and tested. Working on the others.
<hml> achilleasa:  approved
<manadart> Eoan is there.
<admcleod> having a problem fetching interfaces, e.g. https://juju.github.io/layer-index/interfaces/haclster.json
<admcleod> feels like a faulty node in a pool somewhere
<admcleod> or a firewall rule here somewhere
<hml> admcleod: looks like the whole site is down.  not sure who is around right now to help.  maybe an RT?  grasping here.  :-)
#juju 2020-03-14
<sdhd-sascha> Hi, i try to install "openstack lxd" charm, and get:
<sdhd-sascha> ```
<sdhd-sascha> DEBUG install charmhelpers.fetch.SourceConfigError: Unsupported cloud: source option bionic-stein
<sdhd-sascha> ```
<sdhd-sascha> Is there some ppa, which i need inside the lxd-containers ?
#juju 2020-03-15
<TimM[m]> sdhd-sascha: I would ask this question in the discourse (https://discourse.jujucharms.com/) or the #openstack-charms irc channel
