#juju 2012-04-23
<imbrandon> zomg , jcastro you round ?
 * imbrandon just figured out a nginx loadbal config that allows the site to do 600+ concurrent req/s AND stay under 50ms ( yes 50 not 500 ) response time
 * imbrandon does a lil dance
<imbrandon> ( oh, off a m1.small still )
<SpamapS> so quiet in here all weekend
<SpamapS> imbrandon: clearly you have been drinking :)
<imbrandon> nah
<imbrandon> lol
<imbrandon> why is that tho ?
<SpamapS> figured maybe you were a quiet drunk
<imbrandon> :)
<flepied> any help needed with charms ?
<imbrandon> SpamapS: check this hottness out
<imbrandon> http://paste.ubuntu.com/942087/
<imbrandon> put that bad boy in the /etc/nginx/loadbalancer config and boom , sweetness enchews
<imbrandon> even works with admin logins :)
<imbrandon> well chang the IP's to something other than my internal ones but yes
<imbrandon> next trick is gonna see what the limit on the cache size is, so i can throw /mnt/nginx on a ramdisk
<imbrandon> safely
<imbrandon> and no, i am a quiet coder, loud thinker, been coding alot this weekend ( php ) , more than normal
<imbrandon> SpamapS: think we could try to psudo implment that new way of storage at UDS ? i'm keen on getting it done but i havent grasp the juju codebase yet, mostly due to me still not clear on a few of the basics and trying to run before i walk but I'm sure 10 min of facetime with marcoceppi, you, or someone else will clear that right up at uds ( just how i initially learn things i guess )
<imbrandon> oh and Go rocks, not as much like php as i first thought, but still rocks
 * imbrandon goes back to his php code for the moment :)
<imbrandon> SpamapS: oh and my non scientific test do show that for some strange reason unix:/some/php.sock is indeed slower ( well not slower but fails faster with 503's ) than 127.0.0.1:9000 , no idea WHY yet, like if its open file descriptors or what is the issue because that just _seems_ wrong in my gut, but yea
<SpamapS> why would you do a ramdisk? can't nginx just cache in RAM?
<imbrandon> ummm not certain, probably not without a sep module like the memcache module
<imbrandon> it does most everything filebased by default and most things are modules
<SpamapS> memcache as in, memcached, or it has another cache module for RAM cache?
<imbrandon> that said there likely is noe
<imbrandon> one*
<imbrandon> memcached
<imbrandon> only used as a example cuz its a sep module in nginx
<SpamapS> that would be silly
<imbrandon> what would ?
<imbrandon> that it can only do file based in core ?
<imbrandon> nginx tries to be very very slim in code and make all extras modules, even some of the stuff we use like proxy is technicaly a module and not in core proper
<imbrandon> its like php and all its blah.so extensions
<SpamapS> imbrandon: well if its one big file like varnish does, that would make sense... you can just use VFS then
<imbrandon> but they are done at compile time only iirc
<imbrandon> nah its tons of small files
 * SpamapS notes that his laptop has but 10 minutes of battery left
<SpamapS> imbrandon: thats a huge fail
<SpamapS> IMO
<SpamapS> closing a file == syncing a file
<imbrandon> like /mnt/nginx/[1-9]/[a=f]
<imbrandon> a-f
<SpamapS> yeah, so thats nice for simpler coding, but you dn't get to take much advantage of vfs
<imbrandon> well yea i'm sure there are better ways , but thats just how i set it up to begin with , see how its specified on line ....
<imbrandon> proxy_cache_path /mnt/nginx levels=1:2 keys_zone=microcache:5m max_size=1000m;
<imbrandon> so i'm sure there is optinos to that line where we could make it even more uber
<imbrandon> but even like that it did 625 concurrent users and 0 errors or time outs from blitz.io
<imbrandon> and stayed under 100ms , mostly 50ms
<imbrandon> response time from clai , and the server was in vegas
<imbrandon> s/was/is
<imbrandon> cali*
<SpamapS> imbrandon: nice.
<imbrandon> but yea , that was just the "refrence" line from the wiki, i'm sure we can tweak it lots more
<imbrandon> and research a little etc
<SpamapS> ok, battery is about to go dead even with powertop showing 8.0W of power usage
<imbrandon> heh ok, gnight
<SpamapS> imbrandon: should just thieve varnish's mmap method
<imbrandon> still in san fran ?
<imbrandon> kk
<SpamapS> nooo
<imbrandon> lol
<SpamapS> I was only there from the morning to evening
<imbrandon> ahh
<SpamapS> kids.. wife.. all get in the way of fun stuff like conferences ;)
<imbrandon> cool cool, i got some stuff to do early in the morning, but i've already woken for the day so just ping me later and i'll show yta the whole config set
<imbrandon> that i'm working on
<imbrandon> hahaha yea
<imbrandon> btu yea that was a great start i thought, and its a dropin for our current LB config on omg
<imbrandon> but*
<SpamapS> need to start thinking in more generic terms
<imbrandon> so really anything like apache or rails could sit on the other side of that upstream in this config too
<SpamapS> I want to get omg's specific stuff into a subordinate
<SpamapS> anyway
<imbrandon> yea i have been, i've been making sure all the stuff is sep
<SpamapS> battery.. dead.. later
<imbrandon> infact even the web and lp i want sep
<imbrandon> later
<imbrandon> lb*
<imbrandon> hrm , yea infact i'm going to make this into a sub charm right now
<imbrandon> its in a perfect state to do so
<imbrandon> as a nginx loadbal microcache proxy
 * imbrandon looks for that charm init command
<marcoceppi> imbrandon: I hope that's in the omg-wp repo
<imbrandon> i'm actually commiting it now
<imbrandon> or trying to .
<imbrandon> had some conflicts
<imbrandon> but yea
<imbrandon> it is or will be in less than 5 min
<imbrandon> marcoceppi: good weekend ?
<marcoceppi> imbrandon: excellent
<marcoceppi> yes, lots of little wordpress tweaks, but if this does what it needs to we'll be golden
<imbrandon> marcoceppi: yea i got lots of impovements i've tested over the weekend while it was quite, bad part is i'm not QUITE ready like inches away though, but i got somewhere to be this morning till like lunch
<marcoceppi> That's fine, we can wait to deploy later this afternoon
<imbrandon> nice, and i was lookign too its best if we do use totalcache to use apc backend not file, then nginx dont have to be touched as far as total cache, its just a normal setup + our other tweaks at that point
 * imbrandon heads to the other room
<jcastro_> m_3: jamespage when we make the juu blueprints, it needs to be "servercloud-juju-blah-blah"
<jcastro_> m_3: I have 3 charm growth blueprints I will file too.
<jamespage> jcastro, servercloud-q-juju-blah-blah please :-)
<jcastro> jamespage: you don't need the q, but whatever
<jamespage> jcastro: hmm - has that changed?
<jcastro> lp tracks the UDS series, it's just people always put in the letter anyway
<jcastro> you don't need it, but if you want to do it that way that's fine too
<jamespage> robbiew specifically asked us todo it that way for the servercloud track
<jcastro> oh ok then, do what he tells you
<jamespage> jcastro, BTW can you change the message for this channel - might be a little out-of-date 'Charm content ends monday!...'
* jcastro changed the topic of #juju to: Charms at http://jujucharms.com || Want to write a charm? http://juju.ubuntu.com/Charms
<jamespage> jcastro, ta!
<jcastro> jamespage: you were correct on the animal letter btw, mail sent to -devel again
<jamespage> jcastro, glad to be of nit-picking service!
<jcastro> robbiew: hey, can we put juju backports in the shiny new cloud repository?
<jcastro> that would be cool I think
<robbiew> jcastro: No, I'd prefer folks use the PPAs and/or Backports for juju
<jcastro> ok
<robbiew> I would have pushed openstack the same way
<robbiew> but there will be times when folks want to freeze on a certain version
<robbiew> I guess the same could be said about juju
<robbiew> jcastro: tbh, there's really no difference between the cloud archive and a ppa
<robbiew> just naming
<robbiew> but people get worried when you ask them to add a ppa :P
<jcastro> ok, I was just wondering if delivering juju with that at the same time would be a good idea like milestone wise, etc.
<jcastro> "you not only get the backend, you get the front piece too!"
<robbiew> juju needs a cadenced release first ;)
<jcastro> well I was hoping that would make us do that, heh
<SpamapS> robbiew: won't the cloud archive also use the regualar ubuntu signing key?
<SpamapS> jcastro: juju is going to have something similar, but it should not be coupled to openstack.
<robbiew> SpamapS: I guess...it's just a PPA mirrored off archive.ubuntu.com ;)
<SpamapS> robbiew: so they'll still have to add an apt key
<SpamapS> which, IMO, would freak people out *more* than a PPA
<robbiew> SpamapS: your opinion in the minority ;)
<robbiew> it's not about the tech...it's about the "name"
<robbiew> Personal Package Archive scares people
<robbiew> I admit it might not be logical...but neither are people :P
<jcastro> https://bugs.launchpad.net/charms/+bug/966484
<_mup_> Bug #966484: New Charm: Kusaba X <new-charm> <Juju Charms Collection:Fix Committed> < https://launchpad.net/bugs/966484 >
<jcastro> https://bugs.launchpad.net/charms/+bug/964936
<_mup_> Bug #964936: Drupal Charm: superchared Drupal charm with nginx,, apc, php-fpm, all setup to scale to the moon and be Best Practices. <new-charm> <Juju Charms Collection:Fix Committed by imbrandon> < https://launchpad.net/bugs/964936 >
<jcastro> 2 in the queue
<jcastro> SpamapS: we can get these in by thursday right? For some sort of cycle-ending WOO?
<SpamapS> robbiew: I suppose the one win is that you'll get it as part of the mirroring of the archive and won't have to poke a hole in a firewall to get to ppa's
<robbiew> exxxxxactly ;)
<SpamapS> jcastro: need to be available to do 0-day SRU reviews but I'll try to squeeze these in
<_mup_> juju/retry-client-for-cli r532 committed by kapil.thangavelu@canonical.com
<_mup_> use retry client for cli
<SpamapS> negronjl_: hey, how would you feel about moving your REST api into juju-jitsu?
<avoine> negronjl: great works by the way (jrapi)
<flepied> is there any plan to support dynamic creation of vm in juju based on load or other metrics ?
<SpamapS> flepied: you can do that now. stick the client on a thing that knows what the load is, and when load goes up, 'juju add-unit X'
<flepied> SpamapS, any example of this ?
<SpamapS> flepied: none I've seen, but its such a simple concept.. you can do it with icinga/nagios
<flepied> SpamapS, seems easy, I'll try
<flepied> another question is there any plan to use chef/puppet with juju ?
<SpamapS> flepied: I created puppet charms last week...
<SpamapS> flepied: and some people have toyed with using puppet to assert the system state they want from install/etc.
<SpamapS> flepied: juju really doesn't want to define that.. it executes stuff ... you choose what it executes :)
<flepied> SpamapS, yes I got that. Just wanted to see if this was going to be the way to write charm in the future or not...
<SpamapS> flepied: If we define a single way, we will be losing all the existing goodness that people have for their services.
<SpamapS> flepied: the main advantage of juju is that we can connect these unrelated stacks to form a new, bigger stack
<flepied> SpamapS, ok makes sense but you also need to ease the integration of charms together so having standard ways to do thing could help
<SpamapS> flepied: right, we've been doing a lot of shell scripts so they're easy to read for that reason.
<flepied> SpamapS, is there any way I can help ? I have some spare time...
<SpamapS> flepied: are you an expert on any service that might be useful in the cloud?
<SpamapS> flepied: if so, write a charm... using puppet or chef would be a bonus so people can see how that works
<SpamapS> flepied: one method I think that will work is to use the facter custom facts plugin to have a charm's hooks store relation/config settings data, and then just keep running the puppet ruleset using those facts.
<flepied> SpamapS, ok I'll look at that
<SpamapS> flepied: Also the charms we have now are all kind of untested.. we need people to put them through the paces and apply real world scaling/configurability to them
<SpamapS> flepied: oh, and if nobody said this to you yet.. WELCOME! :)
<flepied> SpamapS, thx :)
<flepied> SpamapS, I'll try to see how to test charms. I saw there is a ftest service running
<SpamapS> flepied: yeah that just bootstraps and runs a few of the basic charms
<flepied> do you have a jenkins server testing the charms ?
<flepied> SpamapS, from this table http://jujucharms.com/interfaces, it seems monitoring (nagios) and ngnix (gunicorn) cannot work as they require something that is not provided anywhere...
<SpamapS> flepied: actually we just landed a feature which will enable that
<SpamapS> flepied: its called 'subordinate charms' and we need to work on the documentation a bit :)
<SpamapS> flepied: re charms in jenkins, 'http://charmtests.markmims.com' .. but there is one running precise charms now too
<SpamapS> m_3: ^^ I can has precise, preeeaassseeee
<flepied> SpamapS, yes I experimented it the other day and it's working fine
<SpamapS> flepied: also nagios I think can be modified to be able to relate to anything since there is now a 'juju-info' relation for every service
<flepied> SpamapS, yes that's the trick to avoid having explicit relations
<SpamapS> flepied: though I think there should be a general 'monitoring' interface which can feed back basic instructions on what to monitor...
<SpamapS> flepied: like, mysql can tell nagios to monitor it, and if the nagios charm has mysql specific monitors, it will use them
<flepied> SpamapS, yes that'd cool
<SpamapS> flepied: make it generic enough and we can sub in newer, more scalable monitoring stuff :)
 * SpamapS pushes support for subordinates into charm-tools
<SpamapS> m_3: why didn't I think of this. the charmtester should run 'charm proof' against all charms as well
<SpamapS> bac: hrm, I feel like we left something undone with charm helpers and your buildbot stuff
<bac> SpamapS: gmb and i have a couple of proposed branches and there was the packaging issue.
<bac> SpamapS: it is on our radar but we haven't bugged you about it assuming you were swamped ATM
<SpamapS> bac: I seem to recall that we wanted to get python-shelltoolbox packaged on its own
<bac> SpamapS: yes, and portable to lucid
<bac> as needed by our buildbot slaves inside the containers
<xmltok> when using juju, are people using chef/puppet to do the base system configuration? I understand writing charms to do an application, but when configuring the system (ldap, accounts, mounts, etc), it seems like chef/puppet make more sense then a bunch of charms. I'd think that there should be a charm to deploy/configure/run chef/puppet, right?
<SpamapS> xmltok: There's a new way to deploy puppet/chef/??? along side your charms to do things like system policy.
<SpamapS> xmltok: http://jujucharms.com/search?search_text=puppet
<SpamapS> xmltok: I'm clint-fewbar btw ;)
<xmltok> aha! perfect
<SpamapS> http://jujucharms.com/~clint-fewbar/precise/puppet
<SpamapS> xmltok: its still just a proof of concept though.
<xmltok> exactly what i was thinking
<xmltok> oh hey cool, mod_spdy charm. nice
<SpamapS> xmltok: yeah that needs some work too.. it just assumes 127.0.0.1:80 will have a service to forward to :)
#juju 2012-04-24
<jamespage> SpamapS, m_3 (or anyone else): any objections if I promulgate the hbase charm? it been pretty solid for me for at least a month now...
<_mup_> Bug #987853 was filed: Juju Zookeeper node agent does not handle reboots <juju:New> < https://launchpad.net/bugs/987853 >
<negronjl> jamespage: I'm ok with it.
<jamespage> negronjl, marvellous - ta
* jcastro changed the topic of #juju to: Charms at http://jujucharms.com || Want to write a charm? http://juju.ubuntu.com/Charms" || OSX client: http://jujutools.github.com/
<jcastro> ok folks, we have a Mac client!
<jcastro> thanks to imbrandon! Round of applause please!
<SpamapS> jamespage: has nobody reviewed it?
<hazmat> bac, ping
<hazmat> imbrandon, rockin
<bac> hi hazmat, thanks for the patch.  i haven't had a chance to test it yet.  i'll do so right after lunch.
<bac> hazmat: i assume that's what you wanted.  :)
<imbrandon> :)
<hazmat> bac, cool thanks, indeed it was.  i wasn't able to reproduce the original issue, but i've seen reports of it before relating to other cli commands, this should hopefully generically resolve them.. IFF the issue is the zk connection and not the ssh tunnel. if its  the tunnel or ssh process management then it won't help.
 * imbrandon did not do too much, basicly the equiv of packaing a rpm/deb, but charm-tools is next and i'm FRACKIN exstatic on cloud 9 about omgubuntu.co.uk right now
<bac> hazmat: ok, i'll let you know.  the original is easily reproduced so we should be able to see if it helps.
<imbrandon> gotta spam this one line for our deploy a min ago me marcoceppi did : This rush generated 25,661 successful hits in 1.0 min and we transferred 1.98 GB of data in and out of your app. The average hit rate of 414/second translates to about 35,796,365 hits/day.
 * imbrandon wants to frame those numbers
<imbrandon> thats the juju omg wordpress charm on a single m1.small :)
<hazmat> nice
<imbrandon> me and marcoceppi gonna work on getting it split up now that there is suborainates into a nginx-proxy nginx wp-install and wp-site, i think is the tentive plan now :)
<_mup_> Bug #987930 was filed: MAAS provider - Failure to bootstrap when no port is specified for maas-server <juju:Confirmed> <juju (Ubuntu):Confirmed> < https://launchpad.net/bugs/987930 >
<hazmat> DevOp Boratâs words: âIs all fun and game until you are need of put it in production.â
<fwereade> hazmat, he's an icon to us all ;)
<jcastro> SpamapS: anything to promulgate today?
<jcastro> Last call for juju contributor release notes!
<marcoceppi> jcastro:  I've got some bandwidth to do a review/promulgate
<jcastro> it'd be nice to get drupal done and in
<jcastro> imbrandon should totally be in there
<imbrandon> ?
<imbrandon> oh yea i broke the drupal one a little bit ago, if your finaly gonna prom it give me a few!
<imbrandon> jcastro: and i think releaseing the omg one with marcoceppi was a good step too :)
<robbiew> jcastro: ping
<jcastro> robbiew: yo
<adam_g> given the new features that allow hooks to act on other relations, what is the correct way to test that a relation actually exists?
<jimbaker> adam_g, use relation-ids
<adam_g> jimbaker: thats what i was trying to do. that will give me the list of interfaces, correct?
<jimbaker> it will give a list of relation ids for a relation name
<adam_g> relation-list seems to list names of related service units, which can be arbitrary depending on how its deployed
<jimbaker> where the default is $JUJU_RELATION (if defined, as it would be in a relation hook)
<adam_g> jimbaker: so, if i need to test the presence of a relation that provides some specific interface, i'd need to use a combination of relation-list + relation-ids ?
<adam_g> (first time using any of this stuff, btw)
<jimbaker> adam_g, you would need to something about the charm from metadata.yaml for any interface support
<jimbaker> it was intentionally not added in core juju
<jimbaker> speaking of non core juju, you might find this command useful: https://code.launchpad.net/~jimbaker/juju-jitsu/juju-do/+merge/103366
<jimbaker> adam_g, i'm pretty certain one could readily write a command that parses the metadata, then does the test you asked, with this proposed juju-jitsu addition
<adam_g> jimbaker: i need this to happen from within hooks, not outside
<adam_g> jimbaker: i essentialy need to something like:  if RELATION_TO_FOO_EXISTS: configure_this_way() else: configure_that_way()
<adam_g> jimbaker: since i can't count on service foo being named foo, i should be able to test that a relation to something that provides a known interface to foo exists, right?
<jimbaker> adam_g, it's available in the topology, but was excluded from the support i just mentioned. maybe we could pilot something in juju-jitsu for that support, to see if it really makes sense?
 * adam_g shrugs
<jimbaker> adam_g, curiously enough, hazmat and bcsaller are discussing probably a better approach in #juju-dev
 * hazmat unwinds a shrug
<jimbaker> which is to convey the interface and the charm name in the relation, as i'm reading the discussion
<jimbaker> much like ip addr
<hazmat> adam_g, re some specific interface.. from the charm's perspective it knows what interface each rel name corresponds to
<hazmat> adam_g, so relation-ids on the rel_name should suffice
<hazmat> unless you also want to establish that its been joined at least in which case + rel-list
<hazmat> hmm. i really want a list of subordinates
<adam_g> hazmat: thats what i had originally thought, something like: for r in `relation-list` ; do relation-ids $r ; done
<jimbaker> adam_g, that wouldn't work - you are getting members of the relation in relation-list
<jimbaker> but you need a relation name for relation-ids
<hazmat> adam_g, you've got your nesting inverted
<hazmat> adam_g, so what's the use case?
<adam_g> hmm. looks like i need to get a debug-hooks session going to grok this for real
<hazmat> adam_g, for example if i'm in mediawiki  and i want to check on mysql from some other hook.. i could go rel_ids=`relation-ids mysql `  and then check if any of those have units.. although realistically in this case its only one.. (from the client side)
<hazmat> unless its read-slave
<_mup_> juju/relation-ids-whitespace-separated r532 committed by jim.baker@canonical.com
<_mup_> Support smart formatting for relation-ids
<jimbaker> hazmat, fyi, i need to get the above branch in to properly support things with relation-ids - currently relation-ids only output json
<jimbaker> i will get it in shortly - just need a test
<hazmat> jimbaker, gotcha
<adam_g> hazmat: i'm basically trying to find a good common way of managing config files in this swift rewrite. i'd like to be able to use templated config files that change depending on relations to other services (specifically keystone).
<adam_g> so that i can just write out a new template in every hook, instead of updating bits of config
<hazmat> adam_g, templates in shell or via puppet?
<hazmat> or where those in python?
<adam_g> hazmat: python
<adam_g> hazmat: just messing around right now to see what works best
<jimbaker> adam_g, this seems closer to what is done in charm tools, such as charm splicing
<adam_g> jimbaker: ?
<jimbaker> in terms of ops on charms
<adam_g> jimbaker: i dont know what charm splicing is.
<jimbaker> adam_g, i'm not certain what the current state is, but conceptually it allows for one to compose a charm out of a set of mixin charms. most of this need goes away with subordinates, fwiw
<_mup_> juju/relation-ids-whitespace-separated r533 committed by jim.baker@canonical.com
<_mup_> Add verifying test
<_mup_> Bug #988065 was filed: Support smart formatting for relation-ids command <juju:In Progress by jimbaker> < https://launchpad.net/bugs/988065 >
<jimbaker> hazmat, can you take a look at the above trivial?
<SpamapS> jcastro: I'll hit the charm review queue today
<hazmat> jimbaker, done thanks
<jimbaker> hazmat, so is that a +1? ;)
<hazmat> jimbaker, i dunno, does it do what its supposed to? that's unclear
<hazmat> ie. should be newline separate as impl, or space separate per the doc string
<hazmat> what's the spec say in regards to this
<hazmat> and what's the common shell usage for iteration
<jimbaker> hazmat, so shell takes whitespace separated. i think convention is one per line in shell too
<jimbaker> the other convention in our code is relation-list, which does one per line
<jimbaker> if for example, we have $ids=$(relation-ids db), then this will result in say "db:0 db:1"
<hazmat> jimbaker, whitespace separate  .. means space separated
<hazmat> to me anyways
<hazmat> actually thats the common def
<jimbaker> hazmat, it's a good question. my natural inclination was to join with a space, but we do have the existing convention in relation-list
<jimbaker> but it's all good
#juju 2012-04-25
<jimbaker> i will say whitespace separated does has some wiggle room. the spec states "The output is a whitespace separated list of relation ids, if any."
<jimbaker> reading     http://docs.python.org/library/stdtypes.html#str.split, it discusses the whitespace separation issue as well
<hazmat> jimbaker, newline and whitespace separation aren't commonly understood as the same thing
<hazmat> jimbaker, that doesn't talk about newlines
<hazmat> jimbaker, i'm fine with it being newlines if thats what we're already using elsewhere and its easy for shell usage, but please update the docs to reflect it as newline separated
<jimbaker> hazmat, it doesn't explicitly. but split does split on newlines as whitespace
<jimbaker> as does the shell
<hazmat> jimbaker, then its rather ambigious
<hazmat> jimbaker, if you google around for common usage you'll see most people make a distinction
<jimbaker> http://tldp.org/LDP/abs/html/special-chars.html#WHITESPACEREF
<hazmat> jimbaker, yes its part of the definition, but its ambigious
<hazmat> your outputting something specific, be specific in describing what it is
<jimbaker> hazmat, should we adjust the spec accordingly? because it is ambiguous there
<jimbaker> presumably, it should say "space separated" or "newline separated"
<jimbaker> not "whitespace separated"
<jimbaker> if only we chose to CSV, that's a format that's completely unambiguous ;) (and i'm of course completely joking)
<jimbaker> hazmat, anyway, reading the review, i think the best thing to do is update the docstring to say "newline separated" and maybe add a comment this implies whitespace per our above conversation
<hazmat> jimbaker, sounds good
<_mup_> juju/relation-ids-whitespace-separated r534 committed by jim.baker@canonical.com
<_mup_> Update docstring/comments to describe more precisely relation-ids, when using smart formatting, outputs newline separated ids; and that this is also whitespace separated
<SpamapS> imo, newline separated is more consistent w/ the other tools
<SpamapS> relation-list and relation-ids should basically work the same
<_mup_> Bug #988115 was filed: upgrade-charm fails to change a symlink to a regular file <juju:New> < https://launchpad.net/bugs/988115 >
 * SpamapS rings the bell
<SpamapS> charm promulgated: loggerhead
 * SpamapS tinkers w/ the mysql charm
<imbrandon> morning SpamapS
<SpamapS> imbrandon: you wake up with the roosters or just back from the karaoke bar?
<SpamapS> the mysql charm is so F***'d ..
<SpamapS> I should just rewrite it
<imbrandon> just back from blondies's
<imbrandon> working on the nginx charm i dident finish last night
<SpamapS> imbrandon: which one is blondie, Bo or Luke? :)
<imbrandon> hahaha
<imbrandon> cooter
<imbrandon> i like the overhauls
<imbrandon> but it was Beau really :) /me careses the 1/8th scale diecast "General Lee" on his bookshelf
 * imbrandon loves old moopars, general probably got me started but , '71 Cuda ... orignal "plumb crazy purple" with polished chrome hood pins shine against a flat black hood so you dont see the cowl induction only the numbers 427 in red along the ridge , chrome lined steel "fish gill" air vents just infront of the door seams on the front quarter , original black vynal interior and foe wood trim on the dash and wheel, 8 track with KISS detroit rock cit
<imbrandon> and the body #'s and engine #'s gotta match, no throwin a Hemi in the other one with some sickers later, had to be original rebuild :)
<imbrandon> ahhh i found one, .... /me sets his wallpaper for the day
<imbrandon> http://3.bp.blogspot.com/_gfXupHOEhH0/SzkT2Urio5I/AAAAAAAANxo/D0pnw7csTPk/s640/1971+Plymouth+Hemi+Cuda.jpg
<SpamapS> looks like a batmobile
<imbrandon> that one has a full blower and widend drag wheels, but puretty much that car
<imbrandon> is my dream car
<SpamapS> a redneck batmobile :)
<imbrandon> since i was like 15
<imbrandon> lol
<imbrandon> dude you ever stand next to one, thats pure stock not some crap some guy did to make it loud
<imbrandon> and it will for real make your body shake from the low rumble at idle
<imbrandon> 427 hemi with a huge carb and basicly no muffler stock
<SpamapS> I was traumatized by my father's love of racing as a child, so I kind of hate all big motors
<imbrandon> heh
<imbrandon> i only like mopar
<imbrandon> no idea why really
<SpamapS> so nice of my dad to add half of the drag strip he owns as part of my inheritance when he kicks the bucket
<imbrandon> but like 67ish to 73ish mopars of any kind
<imbrandon> heh
<imbrandon> sell it out, its what i did with my dads computer shop last year, i dont wanna run a repair shoow
<SpamapS> Fitting, since its in "Clint" Texas
<imbrandon> shop
<SpamapS> http://elpasomotorplex.com/Home/
<imbrandon> oh wow, i think i been there
<SpamapS> Wow, gotta get dad to fix that
<imbrandon> east tex
<imbrandon> like near longview and kilgore ?
<imbrandon> oh wow, default wordpress pagelines theme
<SpamapS> http://elpasomotorplex.com/
<SpamapS> ahh thats the real page
<imbrandon> well almost default
<imbrandon> heh
<SpamapS> ok :)
<imbrandon> ahh much better
<imbrandon> heh i seen the leaf logo at the bottom of the other and was like ohhhh pagelines, i know their themes
<imbrandon> heh infact i own the same one
<imbrandon> not the "right one" the wrong one
<imbrandon> heh
<SpamapS> http://elpasomotorplex.com/images/igallery/resized/801-900/IMG_8260-886-500-400-80.JPG
<SpamapS> There's my dad's car
<imbrandon> mmmm summit
<SpamapS> alcohol :)
<imbrandon> SWEET
<SpamapS> Yeah, my sons love it
<imbrandon> yea those frakers are nuts
<SpamapS> I'm like, meh :-P
<imbrandon> they are worse than bull riders
<SpamapS> 0-200mph before you can blink twice
<imbrandon> yea i love it too, well when there i dont follow it at all
<imbrandon> and cant stand nascar
<imbrandon> but funnycars and stuff like that or drag bikes
<imbrandon> those are all fun to watch
<imbrandon> in person
<imbrandon> tv , meh
<SpamapS> yeah I feel the same way about hockey :)
<imbrandon> you got to feel the engines as the roar oir it dont count, and smelll the fuel
<imbrandon> yea i'm probably the strangest dude you will ever meat sports wise, i was all into it up till i graduated HS, no i never even watch ANY on tv, not football, baseball, dont keep up , no march madness
<imbrandon> etc
<imbrandon> i'll PLAY baseball, but thats the extent, seriously
<imbrandon> like i get adgitated at the bar and everyone is into the football game, i just go home
<imbrandon> heh
<imbrandon> no idea, why but like i just am , meh about them all, all my buddies are like , "are you gay" ..... even the gay ones !! hahaha
<imbrandon> they mean it with love those before someone gets upset :)
<SpamapS> so, moodle has to be the most sigusting, sad, slow php app ever made
<SpamapS> sigusting.. worse thand disgusting
<imbrandon> hahah ever run stock drupal 6 with no mods?
<imbrandon> about 20 second page load times
<imbrandon> like ootb, default content
<imbrandon> give moodel some apc and a bit of tweaking i bet it could hum tho, i've always ment to get deeper into it, i've installed it like 5 times over the years but never finish using it/filling it out
<imbrandon> moodle*
<SpamapS> I'm just poking at the half-done charm somebody submitted to see if I can make it go
<imbrandon> ahh
<SpamapS> so far.. no luck
<SpamapS> http://ec2-50-112-14-19.us-west-2.compute.amazonaws.com/login/index.php#maincontent
<imbrandon> :)
<SpamapS> thats as far as I've gotten
<imbrandon> crap this is slow as hell
<imbrandon> its not a micro is it
<imbrandon> hhe
<imbrandon> ahhh
<imbrandon> it loosk like
<imbrandon> let me check
<imbrandon> one sec
<SpamapS> m1.small
<SpamapS> trying apc now
<imbrandon> oh yea with no apc even phpinfo will be slow
<imbrandon> but there is something up with the config and the current domain
<SpamapS> yeah
<imbrandon> its missing an include it looks like
<imbrandon> or something
<SpamapS> links are wrong or something
<imbrandon> cant spot it tho
<imbrandon> wonder if they do it like wp, idiots
<SpamapS> yeah I'm reading the code
 * imbrandon was glad i could bypass it in wp without a core hack
<imbrandon> probably cant in moodle
<imbrandon> and holly mother of jesus , look at the way yui is loading with inc in cdata
<imbrandon> that another reason its takin so long to render
<SpamapS> "render"
<imbrandon> heh
<SpamapS> thats an overstatement :)
<imbrandon> right
<imbrandon> hehe
 * imbrandon opens dev console
<imbrandon> in dev console one of the styles.php is empty and one javascript.php is
<SpamapS> no errors of course
<SpamapS> we wouldn't wnat it to be easy to track this down
<imbrandon> might have something to do with it or lead ya where does if you care that much
<imbrandon> lol yea
<imbrandon> one javascript.php fills, and all the yui-combos do but one php css dont and oen php js dont
<imbrandon> afk a few, gotta get a little fruity pebbles or something brb
<SpamapS> just doing one page hit pegs the CPU
<SpamapS> even w/ apc
<imbrandon> did you restart the php after installing it
<imbrandon> e.g is it actually caching
<imbrandon> i goof that part regularly
<imbrandon> quick phpinfo is the easy way to tell
<SpamapS> yeah it is
<imbrandon> or php-cgi -m on the cli
<imbrandon> but it will segfault
<imbrandon> hrm
<SpamapS> http://ec2-50-112-14-19.us-west-2.compute.amazonaws.com/phpinfo.php
<imbrandon> hrm, nice
<SpamapS> I set error_reporting to E_ALL
<SpamapS> and display_errors On
<imbrandon> fskin sousin is enabled that might screw with it, gotta kill it with drupal , well drupal contrib
<SpamapS> ugh but they abuse error_reporting all over
<imbrandon> heh
<imbrandon> error_reporting.scream
<imbrandon> i thing
<imbrandon> think*
<imbrandon> will overide all of them if you set it to 1
<SpamapS> [Wed Apr 25 08:42:58 2012] [error] [client 76.94.217.164] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 72 bytes) in /usr/local/share/moodle/lib/moodlelib.php on line 7837
<imbrandon> i *think* its been foreever since i used it
<SpamapS> YAAAY
<imbrandon> ahhh
<imbrandon> yea
<imbrandon> that would make it slow as hell too
<imbrandon> bump that bad boy to 512 like it should be
<imbrandon> and i bet things get better
<imbrandon> or atleaste show an error
<SpamapS> 24082 www-data  20   0  463m 139m  23m R 92.2  8.4   0:06.88 apache2
<SpamapS> so awesome
<SpamapS> I forgot how much fun it was to watch PHP eat your server
<imbrandon> heh thats only 23m
<imbrandon> resident
<SpamapS> [Wed Apr 25 08:44:50 2012] [error] [client 76.94.217.164] PHP Fatal error:  Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes) in /usr/local/share/moodle/lib/setuplib.php on line 367
<SpamapS> debug is for winning!
<imbrandon> HAHA
<SpamapS> I set the moodle debug = 1 flag
<imbrandon> wow thats got to be an infinate look
<SpamapS> This yak is just about bald
<imbrandon> loop
<imbrandon> what version is that , i'm gonna grab it clean and try on my server
<imbrandon> just to see
<SpamapS> git
<SpamapS> Here I'll push the charm up
<imbrandon> oh no wonder, git branch or tag ?
<imbrandon> kk
<SpamapS> stable tag I thin
<SpamapS> k
<SpamapS> forgot to check ;)
<imbrandon> btw dont bother reviewing the drupal one yet, decided to go ahead and tear it down to use the nginx base server as a sub
<SpamapS> cool!
<SpamapS> remember tho..
<imbrandon> if ya get there today
<SpamapS> subs can't open ports
<imbrandon> k
<SpamapS> tho you can work around that by making the primary open ports for the sub
<imbrandon> thats fine, i was gonna have the nginx actualy control the whole 80 and 8080 configs
<imbrandon> and just dropa drupal specific in sites/enabled
<SpamapS> lp:~clint-fewbar/charms/precise/moodle/slow
<imbrandon> no need for ports in ther
<SpamapS> git checkout MOODLE_22_STABLE
<imbrandon> , even so though couldent we kinda cheat and do like on relation-join , drupal config set nginx ineedport80 , nginx config-changed notices and does it ?
<imbrandon> hehe
<SpamapS> yeah thats how you do it
<imbrandon> ahh kk
<SpamapS> as long as primary service opens port, its all good
<SpamapS> (and devs are working on fixing this)
<imbrandon> erm
<imbrandon> wait only the primary
<SpamapS> why oh why doesn't php have a real debugger yet? :-P
<SpamapS> I mean I know it does
<SpamapS> but I want it to be easy to use
<imbrandon> fudge, i really wanted to do this set on jeos. even if its not for all charms it kinda makes sense here
 * SpamapS installs xdebug to see what havoc it plays
<imbrandon> SpamapS: xdebug
<imbrandon> SpamapS: thats ok, the jeos will just have the job of manageing all the ports then, not giving that up, cuz i'm dropin them all in the store at once TODAY i hope
<imbrandon> all being the jeos-webbase with either zend-server-ce 80 and spdy OR nginx with phpfpm for 80
<imbrandon> thats 3
<imbrandon> then another sub of jeos for the nginx rev prox 30s cache
<imbrandon> to one of those others
<imbrandon> then drupal or wp base with no default site, just install screen
<imbrandon> and then my blog or omg or something on top of that ( but sub of jeos )
<imbrandon> thats how i got it worked out
<jamespage> morning folks
<imbrandon> and then others can be added and removed too but that is some nice default options
<imbrandon> morning jamespage
<jamespage> hi imbrandon
<jamespage> bit of late night charming SpamapS :-)
<imbrandon> i'm rubbin off on him, soon he'll be going on 3 hours sleep 4 or 5 nights a week :)
<imbrandon> lol
<SpamapS> jamespage: indeed.. not sure why I'm poking at moodle when the real problem is mysql :-P
<jamespage> lol
<SpamapS> imbrandon: I'm training up for having an infant in the house
<imbrandon> oh SpamapS been watching the omg load and such, it hit 10.x earlier for almost an hour, it was pushing 25Mb/s out and 13Mb/s in said byobu
<jamespage> SpamapS, it will be a real test to see if you can charm whilst settling a baby at 2am!
<imbrandon> i allllllllllmost did a juju add-unit
<SpamapS> jamespage: I may need Siri to help w/ that. :)
<imbrandon> but it calmed back down, was just before you poped in
<SpamapS> imbrandon: hah cool
<imbrandon> funny thing was tho with the 10.x load , i still it the page fine
<imbrandon> without any extra lag, so thats why i dident rush to add a unit
<imbrandon> if it starts to creep tho i will, running one extra for a day or two wont be much
 * imbrandon is suprised its holding up on two smalls as well as it has been
<SpamapS> jamespage: I may have fixed the problem hive had w/ mysql actually
<imbrandon> i mean i know this cruft is good but damn i'm thinking about starting a shared host on a m1.small and selling 100000000 accounts at $1
<SpamapS> should probably abandon moodle and try hive instead :-P
<imbrandon> and come out ahead
<imbrandon> lol
<imbrandon> SpamapS: did you see a small patch from marcoceppi for mysql charm
<imbrandon> he said he had one for you to fix some utf8 things we got to fix wevery redeploy
<jamespage> SpamapS, I'll have to read - that was at least a month about and my ringbuffer memory has looped a few times since :-)
<SpamapS> jamespage: I poked at the hive charm in new-charm .. looked good to me
 * SpamapS officially gives up on moodle
<jamespage> SpamapS, sweet - i'll promulgate it then
<jamespage> SpamapS, as hadoop, hbase, zookeeper and hive will all be in the charm store I was going to do a trivial update to all of their readme's to stop using a local repo
<SpamapS> cool
<SpamapS> I am not so excited about cs:* until we get an ability for people to fork a running service's charm
<SpamapS> https://code.launchpad.net/~clint-fewbar/charms/precise/mysql/add-binlog-format/+merge/103427
<SpamapS> There's the fix
<jamespage> SpamapS, nice
<SpamapS> imbrandon: I don't see anything from marco, I'll ping him tomorrow
<SpamapS> sad.. us-west-2 seems to be more laggy than us-east-1, despite being baout 1000 miles closer to me. :-P
<SpamapS> imbrandon: mysql and charsets is always a nightmare. :-/
<imbrandon> yea, he said the fix is in that shelr.tv prov feed he gave me and you
<SpamapS> ok, sleep
<imbrandon> just fyo
<imbrandon> gnight
<imbrandon> see ya in a few hours /me will still be here
<jamespage> hive charm promulgated - thanks bbcmicrocomputer!
<bbcmicrocomputer> jamespage: ah no problem :)
<jcastro> imbrandon: you're working on the nginx subordinate right?
<imbrandon> jcastro: yea
<imbrandon> like right now
<imbrandon> will be done before lunch
<imbrandon> jcastro: and an apache zend server one too that will be done same time as it shares 90% of config
<jcastro> imbrandon: so what I was thinking about, is to make an nginx ppa for 1.2.0 an option in the charm, for people who want to use it, that would be sweet.
<imbrandon> yea i'm definaly using the upstream nginx ppa
<imbrandon> i do on my site and depends on some of the new stuff
<jcastro> <3
<imbrandon> its packaged by upstream and stable release
<imbrandon> so should be good too
<imbrandon> and i've been using it since it came out on my site
<imbrandon> ( i have the daily ppa on )
<SpamapS> jimbaker: so, I'm experimenting with relation-ids
<jimbaker> SpamapS, cool
<SpamapS> I can getthe relation id..
<SpamapS> but I want to re-run a hook as if it was changed again
<SpamapS> so I need to set, like, JUJU_REMOTE_UNIT
<SpamapS> any idea?
<jimbaker> SpamapS, you can only do settings on the local unit
<SpamapS> hm, so do I do relation-list ?
<SpamapS> ahh relation-list is what I want. :)
<jimbaker> SpamapS, good :)
<SpamapS> jimbaker: basically I want to write a "refresh *everything*" script
<jimbaker> SpamapS, that's a bit challenging in the scope of what is provided - you would need to ensure this runs in some hook on a service unit for every relation
<jimbaker> but if you can use "jitsu do" (which i will merge in shortly to juju-jitsu), it's pretty straightforward
<jimbaker> given it's rather powerful capabilities ;)
<jimbaker> my feeling is that this would be a good place to start at least
<SpamapS> jimbaker: jimbaker http://paste.ubuntu.com/946143/
<SpamapS> jimbaker: there's my first attempt
 * SpamapS tries it
<SpamapS> jimbaker: note that is the whole upgrade-charm hook
<SpamapS> doh, have to enumerate the relation name myself
<jimbaker> SpamapS, yes, there's no generic support for getting relation names from juju itself. the expectation is that charms know the relation name. leaving this issue to some sort of charm tooling that can work with the metadata.yaml
<SpamapS> which is what I'm writing right now :)
<SpamapS> actually
<SpamapS> no
<SpamapS> I only have one relation
<SpamapS> I can be explicit in this case
<jimbaker> SpamapS, sounds good
<jimbaker> SpamapS, re line 14 of that paste, does that exec the script?
<SpamapS> yes
<SpamapS> but I think it may fail because it doesn't do what I would have expected, which is that the presence of JUJU_RELATION_ID would be enough to give me a context
<jimbaker> SpamapS, right, the overall script has that flaw
<jimbaker> it needs to make changes on relation settings, which is restricted to the local unit
<SpamapS> huh?
<SpamapS> It actually just needs to do a few relation-get's
<jimbaker> SpamapS, if that's the case... then fine, you can do that on remote units of course
<SpamapS> yeah I think I just need to add an explicit '-r $JUJU_RELATION_ID' to the hook it is calling
<SpamapS> which, seems like a bug
<SpamapS> if I have no context, but I do have $JUJU_RELATION_ID .. that should be equivilent to passing -r $JUJU_RELATION_ID
<SpamapS> jimbaker: jitsu do seems too general. I don't know exactly what it is for.
<jimbaker> SpamapS, the way to think about jitsu do is that it allows you to execute the command + args as if it were a hook
<jimbaker> so for example, $ jitsu do mysql/0 relation-get -r db:0 -
<jimbaker> this is as if this were called as a nonrelational hook (a relational hook automatically gets an implied relation, including $JUJU_RELATION, $JUJU_RELATION_ID)
<SpamapS> so, I had hoped that implied relation would simply be carried in the env vars mentioned...
<SpamapS> that would make things more self contained.. I don't want to included jitsu in charms just so they can do the right thing and refresh their relations on upgrade-charm
<SpamapS> actually IMO juju should do it automatically.. but .. baby steps
<SpamapS> jimbaker: here's the diff I'm adding to the munin charm..
<SpamapS> jimbaker: http://paste.ubuntu.com/946171/
<jimbaker> SpamapS, agreed on that. jitsu do for now should be considered a useful backdoor for trying out things
<SpamapS> jimbaker: I shouldn't need the '-r' .. its implied by the environment.
<SpamapS> this works btw
<SpamapS> its just that it shouldn't need to be so invasive
<jimbaker> SpamapS, i understand your perspective re not needing -r if JUJU_RELATION_ID is specified *or* changed
<jimbaker> this could be done in a reasonable way. right now, the implied relation is special since the invoker knows it's in a relation  hook context
<hazmat> m_3, jamespage you guys have talks in already for strata ny+hadoopworld?
<hazmat> just got  a reminder that their due on may7
 * hazmat finishes up his presentation for openstackdc meetup
<jcastro> http://podcast.ubuntu-uk.org/live/
<jcastro> I am on this podcast talking about juju!
<jamespage> hazmat, sure have
<jamespage> arosales and m_3 are working on a charm school as well
<arosales> ya, hopefully we can have a tutorial session at Strata/Hadoop world on how to build off James' Haddop charms, and also use the charms in different deployments.
<arosales> Hope to have that submitted by end of the week.
<jcastro> Announcing the UDS Charm Contest!
<jcastro> http://cloud.ubuntu.com/2012/04/announcing-the-uds-juju-charm-contest-for-uds-attendees/
<imbrandon> ^^
<imbrandon> so mine
* jcastro changed the topic of #juju to: Coming to UDS? Write a charm for a chance to win one of 3 Dell XPS 13 ultrabooks! http://goo.gl/uTGU2 || Charms at http://jujucharms.com || Want to write a charm? http://juju.ubuntu.com/Charms" || OSX client: http://jujutools.github.com/"
<SpamapS> hey
<SpamapS> somebody put a dell logo on my laptop
<imbrandon> heh
 * imbrandon is soooooooooooooooooooooo got one of those this time
 * imbrandon polishes more turds to combine them alll
<imbrandon> :)
<imbrandon> and if not least i lost fair and square from the start this time :)
<imbrandon> heh
 * imbrandon gets food
<jimbaker> that xps 13 looks rather rather nice
<SpamapS> hrm.. poking at making an autoscaler w/ munin+juju .. one real pain is that you have to know *all* of the SSH keys that you want to be able to use to talk to juju before you bootstrap
<jcastro> SpamapS: Got ~5 for G+?
<jcastro> I have quick questions
<SpamapS> but
<SpamapS> the daisies
<SpamapS> the pirates will be sad
<SpamapS> will try.. fighting pink eye onset and lacking a headset :)
<imbrandon> steal a patch from on of dem pirates
<lifeless> SpamapS: pink eye... what have *you* been up to ?
<SpamapS> lifeless: no good
<RichardRaseley> I have a question regarding scaling things like mongodb or cassandra via juju. If you look at the command juju add-unit -n 2 cassandra its purpose is clear - but how does it know what computers to configure those two additional nodes on?
<RichardRaseley> Is that specified after the fact (I haven't actually ran these commands, FYI)?
<RichardRaseley> Or rather, as part of the input asked for after the command?
<SpamapS> RichardRaseley: it decides where to scale onto the same way it decides when you run 'deploy'
<SpamapS> RichardRaseley: the only difference is that there is already one unit in that service.
<SpamapS> RichardRaseley: so, it uses a combination of the placement policy and constraints
<RichardRaseley> If I am SSH'd into "server00" and I do a cassandra deploy - it won't go to that particular server? Where are those policies defined?
<SpamapS> RichardRaseley: the default is to place everything on an "available" machine, or to ask to have one provisioned if there are none. The default constraints are different per provider but basically mean "any machine"
<RichardRaseley> I am just looking over the juju.ubuntu.com site and I don't see that information...
<SpamapS> RichardRaseley: juju is in charge of provisioning, so by the time you can ssh in, its too late. :)
<RichardRaseley> Obviously if I have 1000 production machines in an environment - I don't want JuJu grabbing a mailserver and make it a mongodb node.
<SpamapS> RichardRaseley: since juju's use case is more "cloud like", it expects to be able to install a new OS on a clean machine every time.
<RichardRaseley> What controls those placement policies?
<SpamapS> RichardRaseley: the provider defines the constraints that are available.. and there are only two placement policies right now.. the "available machine" and "local". Local is used for doing local dev.
<RichardRaseley> What does "provider" define in this context.
<RichardRaseley> ?*
<SpamapS> well realistically, ec2, or maas
<RichardRaseley> If I want to deploy Keystone on the server to which I am currently logged into via JuJu, I cannot do that?
<SpamapS> no, juju does not do that currently
<RichardRaseley> Similarly - if I want to create a mongodb deployment, then extend it to server00 and server01, I cannot do that?
<RichardRaseley> Oh, wow - that is hugely dissapointing.
<SpamapS> RichardRaseley: why's that?
<SpamapS> Those machines are already busy
<SpamapS> If you have clean machines
<SpamapS> use MaaS
<RichardRaseley> No, they aren't - I just created them.
<RichardRaseley> They aren't physical machines.
<SpamapS> Ahh, well if you create them w/ MaaS, then yes you can do that. :)
<SpamapS> And if they're VM's, then let juju create the VM's.
<SpamapS> RichardRaseley: It would not be hard to write a juju provider which SSH's to boxes and runs juju's agent.
<RichardRaseley> That just doesn't make sense to me. I mean, that is awesome that it supports that but it seems a no-brainer that I should be able to specify (IP, FQDN, etc.) the machines that I want to extend the services to.
<RichardRaseley> Not hard for a developer. =]
<SpamapS> RichardRaseley: Why exactly are you so interested in creating the VM's yourself?
<RichardRaseley> Does it matter why?
<RichardRaseley> There could be any number of reasons.
<SpamapS> yeah, it might motivate me to advocate for that use case :)
<RichardRaseley> Well, for example we are using a combination of VMware & Hyper-V so I don't know if Juju hooks into that.
<RichardRaseley> There are change control issues with allowing an automated script to hook into production infrastructure.
<SpamapS> No, it doesn't. It needs an API to talk to, and right now, it only speaks EC2 and MaaS
<SpamapS> RichardRaseley: only one machine, the juju provisioning agent machine, has access to the infrastructure.
<SpamapS> RichardRaseley: and those change control issues are handled by keystone and nova if you use OpenStack.
<RichardRaseley> Right, but it is an "unknown" as far as most people would be concerned. Our process for provisioning VMs is "X" and deviation from that is painful for operations to overcome (that is a whole other issue).
<SpamapS> Whatever access creds you're using can be limited to numebr of nodes and types and such.
<SpamapS> RichardRaseley: So you'd like to manually define the VM's that are available to juju. I think thats a worthy goal, you're the 3rd person to ask for that functionality.
<RichardRaseley> Yes, it *could* be done that way - but that isn't the way I would want to use it in this case. I think having the ability to interface with MaaS or with EC2 or OpenStack is awesome, but also being able to say something like "juju mogodb deploy --server server00"
<SpamapS> RichardRaseley: one option is to make those VMs owned by MaaS, so they act more like real servers. The only requirement is that they be able to PXE boot from the network where MaaS is.
<RichardRaseley> then "juju add-unit -n 2 mongodb --server server01, server02"
<SpamapS> ugh
<RichardRaseley> PXE and WoL, right?
<SpamapS> RichardRaseley: the WoL isn't required, just makes things easier
<RichardRaseley> What if you have existing PXE servers in the environment doing other things (WDS for example)?
<SpamapS> RichardRaseley: --server is a bit of a problem. You are limiting the scale quite a bit. How about when you deploy, you say 'deploy --constraints mem=10G,cpu=10' and then add-unit will find the machines that suit that?
<RichardRaseley> I don't recall if you can define multiple PXE servers in a DHCP option.
<SpamapS> RichardRaseley: you can tell DHCP servers to only respond to known MAC's
<SpamapS> RichardRaseley: or just --constraints class=mongoserver .. and then have the machines classified arbitrarily
<RichardRaseley> But what is creating the pool of available machines?
<SpamapS> RichardRaseley: the reason --server server01 is in your head is that you are limited by your organization's unwillingness to actually meter their infrastructure with a real cloud-like solution.
<SpamapS> RichardRaseley: the success of amazon comes largely from letting go of "but we can't let just anybody take one of our precious compute units!" and instead just billing everybody who uses things.
<RichardRaseley> We aren't "billing" anyone - it is all internal use.
<RichardRaseley> And they don't use a chargeback model.
<SpamapS> So why would you be so concerned about letting services that need resources take the resources they need?
<SpamapS> And then putting governor's on.. a-la "that environment only gets X compute and Y ram"
<SpamapS> RichardRaseley: I'm not trying to change your business model, but rather, let you know the business model we've targetted first w/ juju.
<RichardRaseley> Not going to disagree with you in principal - but I think having that flexibility would speed adoption of Juju which will have a net effect of moving things faster towards that model.
<RichardRaseley> I can say "Look what Juju can do Mr. Manager" "Holy, crap really?" Yes, and if I deployed Maas (etc.) it could do that +X and +Y"
<SpamapS> Perhaps, but at what cost? Instead of migrating to OpenStack, users now have this clunky juju thing on top of their old servers that can't scale.
<SpamapS> RichardRaseley: MaaS is laserbeam-targetted at making it really easy to deploy a "seed" openstack cloud.
<SpamapS> RichardRaseley: something where you take a few real boxes and throw openstack up and then show how juju can manage apps easily ontop of openstack.
<SpamapS> (in theory.. :)
#juju 2012-04-26
<SpamapS> RichardRaseley: its possible MaaS can be coaxed to own nodes w/o PXE... but it definitely requires its own pre-seeded install to be in charge of the machine.
<RichardRaseley> Can you create classes of machines in MaaS, for example I might configure hardware in such a way that it is specifically for swift-storage
<RichardRaseley> or swift-proxy
<RichardRaseley> or nova, etc.
<SpamapS> RichardRaseley: that is the plan, but IIRC, not in the current release. Right now the only constraint juju+maas suppors is (don't hit me) server name. :)
<RichardRaseley> Ha
<RichardRaseley> OK
<SpamapS> which, btw, I think is a huge mistake ;)
<SpamapS> should have been class, not name
<RichardRaseley> Again, it is dissapointing because it takes Juju off the table for us in the foreseeable future. =[
<SpamapS> but, I think time ran short on dev and they wanted to get something out for Ubuntu 12.04
<RichardRaseley> Anyways - I have to go - time got away from me.
<RichardRaseley> thanks for the conversation.
<SpamapS> RichardRaseley: :) thanks for your interest!
<xmltok> do the juju charms for openstack build openstack quickly and easily on maas already? i have a few POC investigations into openstack and maas right now, juju was going to come later
<xmltok> perhaps it should be maas, juju, then openstack.
<SpamapS> xmltok: yes, there's a bit of polling/sequencing that needs to be refactored (juju grew some new things recently that alleviate the need to order the deployment) so it should get even better/faster soon.
<SpamapS> xmltok: we had the deploy/destroy on a loop at ODS ... it would just bring up all 8 nodes w/ openstack, then tear them back down, over and over. I think it takes < 10 minutes on crap hardwware.
<SpamapS> xmltok: (assuming a fast mirror :)
<xmltok> nice
<xmltok> encouraging
<SpamapS> xmltok: I think the instructions to do it are hiding somewhere on wiki.ubuntu.com
<xmltok> i have high hopes for juju. i would like to replace the lion's share of our app deployment with it
<SpamapS> xmltok: https://wiki.ubuntu.com/ServerTeam/MAAS/Juju
<SpamapS> xmltok: \o/
<xmltok> yep, seen that guy. are you very familiar with maas? I was wondering how it triggers builds, i didnt see ipmi hooks or anything like that
<SpamapS> xmltok: it uses cobbler on the backend
<SpamapS> xmltok: so, any power control that cobbler supports
<xmltok> got it
<SpamapS> xmltok: though I think there is a strong desire to take cobbler out of the loop
<SpamapS> since it kind of complicates things
<SpamapS> xmltok: so, IPMI is supported, WoL, a few other things
<SpamapS> alright, I have to run
<xmltok> we have rackable/sgi blades, and none of them have ipmi or wol. garbage.. but we do have scripts to locate nodes and control the power
<xmltok> thanks for clearing some things up
<SpamapS> xmltok: good luck.. we're all counting on you. ;-)
<hazmat> jimbaker, that jitsu do thing needs a serious warning
<hazmat> that its executing locally without any access to the charm or remote unit
<hazmat> ie. its a remote hook context on a local script
<bkerensa> imbrandon: let me know what day is going to work best for the Cloudflare tour so I can set it up with their CEO
<imbrandon> bkerensa: kk will do , i'm thinking probably monday late afternoon OR wed lunchish , but let me confirm that first and think a bit more
<imbrandon> just wakin up so not fully aware of my brain yet
<bkerensa> yeah just ping the others and see what works best and I will make it happen :P
<imbrandon> kk, not 100% whom all besides me, gonna TRY and drag jcastro and marcoceppi at minimum maybe SpamapS if he wants to he would love it too but not sure what their schedules are gonna be like i know clints is booked and i bet jcastro;s is tooo
<imbrandon> hell mine is for that matter
<imbrandon> lol
<imbrandon> but i'll make time
<imbrandon> ill try to find out from them sometime today if i can tho
<gmb> Hi all. A quick question: I'm working on something for UDS and what I really need is a way of having Juju start up all the nodes for a particular charm using a specific AMI. Obviously I can't use default-image-id or default-ami in environments.yaml any more to do this. Is there a way I can do it with juju set-constraints, or when passing --constraints to juju deploy?
<gmb> I can't find any reference to it in the constraints documentation.
<SpamapS> gmb: default-image-id still works, its just not recommended since you lose the ability to specify most of the other constraints since your image id might not boot on all instance types.
<SpamapS> gmb: what exactly do you want on this image id though? As a potential judge for the charm contest, I'd dock points for needing a specific image.
<jcastro> SpamapS: group hug bro
<gmb> SpamapS, Here's the scenario:
<gmb> We're running Launchpad clinics at UDS
<gmb> It takes a long time to set up LP on you machine
<SpamapS> jcastro: :)
<gmb> Instead of requiring it for everyone who wants to take part we'll sping up EC2 instances with LP already set up (add keys and bzr whoami and Bob's your Auntie's live in lover)
<gmb> It's be lovely if I could just type juju delpoy ... and pass it some config options rather than having to spent time faffing around. Of course, I can script it myself, but Juju is nicer :).
<SpamapS> gmb: there's an enormous advantage to using the charm's install hook rather than an image id.. mainly that you don't have to then duplicate your image id in ever region and architecture you want to use.
<SpamapS> every region, rather
<gmb> SpamapS, In this instance, I'll take the advantage of not having the install hook take 40 minutes.
<SpamapS> gmb: wtf!
<SpamapS> 40 minutes?!
<gmb> I told you: LP takes a long time to set up.
<SpamapS> gmb: I've thought long and hard about having juju take a system snapshot right after the 'install' hook runs, and then using that for subsequent add-unit's
<gmb> SpamapS, So would I if I'd known that was an option... tell me more!
<SpamapS> gmb: well its not
<SpamapS> but it might be doable with very little coding.
<SpamapS> :)
<SpamapS> gmb: 40 minutes is indeed totally unacceptible for an install hook.
<SpamapS> gmb: what in blazes is it doing for 40 minutes?
<gmb> SpamapS, Installing builddeps, getting the source, building the source... 40 minutes is, I'll grant you, on the far edge of normal. On a good day, though, it's still in the tens of minutes.
<gmb> You could file this under "buildout is a bugger"
<gmb> BUt that might be unfair.
<gmb> SpamapS,  Anyway, my point is that I want to be able to spin up a new instance quickly, and Juju would let me do that. But I accept that I might not be doing things the right way (and I wouldn't do things this way for general usage).
<gmb> Also, default-image-id makes Juju shout at me and exit. How can I make it not?
<SpamapS> gmb: there's still a way to use image ids, I just forget it now
<gmb> SpamapS, Hum. Okay. If you remember it let me know. I'll investigate alternatives anyway, since I acknowledge that this way of doing things is a bit mucky.
 * gmb -> otp
<SpamapS> is juju.ubuntu.com down?
<SpamapS> <html><body><h1>It works!</h1></body></html>
<SpamapS> Oh, I didn't give a Host: header
<SpamapS> not down, but very slow
<SpamapS> probably related to the www.ubuntu.com problems -P
<SpamapS> http://www.ubuntu.com/ ... wtf? Why are there 18 miles of whitespace on each side of that page?
<marcoceppi> SpamapS: I don't see much white space
<SpamapS> marcoceppi: how wide is your window?
<SpamapS> mine is about 1440 pixels wide.. ;)
<marcoceppi> 1920
<marcoceppi> well 1920 x 2
<SpamapS> maybe its a chrome thing..
 * marcoceppi is using chrome
<SpamapS> ah Ok for whatever reason I was zoomed out a bit
<SpamapS> but its still *a lot*
<marcoceppi> yeah, the default ubuntu template has a bit of white space :)
<marcoceppi> since it's only 980px wide
<SpamapS> http://imgur.com/9bRxv
<SpamapS> hideous
<marcoceppi> wow
<marcoceppi> that is a lot
<marcoceppi> http://i.imgur.com/BfKhe.png
<marcoceppi> I feel like yours is more zoomed than mine
<SpamapS> I went to Actual size
<SpamapS> but, yeah, I get that a lot
<gary_poster> SpamapS, some installations take a long time--40 minutes or more might represent an outlier, but not a "wtf" outlier in my guess (just a guess).  examples include many packages needing to be installed (think fresh lxc download/configuration), many packages needing to be built/compiled (LP uses sdists and has a lot of them, and mailman takes a long time to build for some reason I don't know, and we build WADL and docs and...).
<gary_poster> bac, mars posted something to cloud I thought you'd be able to reply to...looking for subject line...
<gary_poster> bac, "Juju Charms: How Do I..."
<gary_poster> you've experimented with sending private information
<gary_poster> not sure if you think it is worth sharing, but if so, wanted to call it out
<bac> gary_poster: i'll look
<gary_poster> thanks
<RichardRaseley> So Juju currently supports deployment against MaaS and EC2, but not Nova, correct?
<jamespage> RichardRaseley, its possible to use with OpenStack using the ec2 provider - but you openstack deployment must support both the ec2 API and the s3 API
<RichardRaseley> jamespage: Thank you for that information. Is "native" OpenStack support on the roadmap?
<jamespage> RichardRaseley, I don't think it is at the moment - this was discussed at the Openstack Design Summit last week - http://www.ubuntu.com/cloud/private-cloud/awsome
<SpamapS> RichardRaseley: native OpenStack isn't really all that necessary. The needs that juju has from ec2 and s3 are very tiny, and openstack's compatibility layer supports them fully
<SpamapS> RichardRaseley: That said, I'd like to see native support so that we can use OpenStack's ability to enumerate instance types to match the generic 'mem' and 'cpu' constraints.
<jamespage> but like SpamapS says thats prob overkill for juju requirements (unless the cloud you are trying to use does not expose the ec2 API).
<jamespage> SpamapS, that would be nice.
<SpamapS> Seems like a gaping hole in EC2's API that you can't programattically say "how much RAM does an m1.small have"
<SpamapS> but, it makes sense that they wouldn't focus on that, since its *always* the same number
<RichardRaseley> Is the EC2 & S3 compatibility layer built into OpenStack or is that something that has to be installed seperately.
<SpamapS> built in
<SpamapS> RichardRaseley: its built in now. Note that it may be moved to a separate proxy, as some openstack based clouds don't want EC2 compatibility for political or even possibly technical reasons.
<SpamapS> RichardRaseley: Canonical developed said proxy, its called AWSome
<RichardRaseley> OK, I can see the political or pride aspect. "OpenStack is awesome, and we are fully behind it, but you have to use this compatibility layer built to support a competing platform to use our automation software."
<RichardRaseley> Seems a little weird from an outside perspective.
<imbrandon> RichardRaseley: well its a stopgap, we dont want to keeop using it for openstackm maybe others but os will be fully native *sometime* its some man hrs etc etc
<RichardRaseley> I understand that.
<RichardRaseley> And am sympathetic.
<imbrandon> and really its the storage bits on os
<imbrandon> not the compute
<imbrandon> and SpamapS has a great idea to rid that need anyhow
<imbrandon> and just store the nneded info on the bootstrap node
<imbrandon> then it woulent be needed for OS at all then, others yea
<SpamapS> RichardRaseley: think of it another way. "AWS only does these 8 things. OpenStack intends to do 100 things that AWS will never do."
<SpamapS> RichardRaseley: for that reason, separating the EC2 bits out into a separate proxy makes a lot of sense.
<RichardRaseley> SpamapS: I was referring to "native" support for Nova, Swift, etc.
<RichardRaseley> I am not opposed to seeing the proxy functionality seperated out.
<RichardRaseley> I mean, that makes sense.
<SpamapS> RichardRaseley: well I guess my point is, juju is intended to use *both*
<SpamapS> So if we wrote a native OpenStack provider, we'd not gain much, because all the clouds that juju supports need to support the same functionality (which is a very tiny footprint btw... start/stop/list machines is the krux of it)
<SpamapS> We only just now added the constraint ability.. which is where native support becomes more attractive because it enhances capabilities without needing anything fundamentally different.
<RichardRaseley> I suppose that is true from a technical point of view - but there is something that just seems "off" about having to proxy requests to OpenStack from Juju through an ec2, s3 proxy. :: shrugs ::
<RichardRaseley> Right
<SpamapS> RichardRaseley: to be clear, right now, there is no proxy needed.
<SpamapS> OpenStack's EC2 capabilities are built in
<RichardRaseley> It is a compatibility layer though, correct?
<SpamapS> Sort of
<SpamapS> EC2 is done at the same level as OSAPI
<RichardRaseley> So JuJu makes ec2 calls, that layer translates those to nova?
<SpamapS> Nova-API supports both EC2 and OSAPI
<SpamapS> so.. the same thing that translates OSAPI to nova :)
<RichardRaseley> I am not familiar with OSAPI - I am just dipping my toes into OpenStack
<SpamapS> Its just possible that the EC2 will be moved out of Nova API as OSAPI grows as the dominant use case.
<SpamapS> OSAPI == Native OpenStack API
<RichardRaseley> Ah
<hazmat> RichardRaseley, the ec2 calls that juju makes to openstack are implemented at the same layer/level as the native openstack calls
<hazmat> but in the context of public clouds built on openstack, not all choose to expose those implementations
<hazmat> the proxy offers compatibility usage in that context, and going forward maybe adopted as a preferred mechanism by ostack for ec2 compat
<hazmat> that's tbd though
<bkerensa> jcastro: Why you offer XPS laptops at UDS?
<bkerensa> >.< now you know I must write more charms
<jcastro> bkerensa: why not?
<jcastro> SpamapS: hah, nice hack (the subordinate ssh thing)
<jcastro> you know, why not have an "auth" subordinate that does just that?
 * SpamapS is good with the hatchet :)
<SpamapS> jcastro: I am working on a pam-mysql subordinate actually :)
<SpamapS> I'm telling you.. once subordinates are fully understood.. everybody's heads will explode with good ideas
<bkerensa> jcastro: So if we are attending UDS and we start pushing Charms this week will those count or do we actually have to write them at UDS?
<hazmat> bcsaller, please do an ml announce of subs
<SpamapS> Yeah it would go well with the 12.04 release
<bcsaller> hazmat: writing something up
<hazmat> bcsaller, awesome
<SpamapS> I think we have to accept any charm from now until judging.. otherwise people will cheat and bring pre-baked charms anyway. ;)
<bkerensa> SpamapS: I cannot bring anything pre-baked because I need you to roll out my dough first before I put it in the oven
<bkerensa> :D
<RichardRaseley> So - this is a question from a non-developer and someone with no experience using charms - are most charms written in a specific language such as Python?
<hazmat> RichardRaseley, no.. they can be written in any language and with any tooling.. that said.. most of the 'official' charms (ie been through a review process) are written in shell/bash with a handful in python.
<RichardRaseley> hazmat: Thanks for that information.
<jml> hi
<jml> I'm getting lots of log-spam in /tmp/juju-local/jml-local/machine-agent.log
<jml> 2012-04-26 19:23:25,336:1064(0x7f845c6e3700):ZOO_WARN@zookeeper_interest@1461: Exceeded deadline by 486569ms
<jml> 2012-04-26 19:23:25,337:1064(0x7f845c6e3700):ZOO_WARN@zookeeper_interest@1461: Exceeded deadline by 486569ms
<jml> 2012-04-26 19:23:25,337:1064(0x7f845c6e3700):ZOO_ERROR@handle_socket_error_msg@1528: Socket [192.168.122.1:50887] zk retcode=-7, errno=110(Connection timed out): connection timed out (exceeded timeout by 0ms)
<jml> I suspect that it crashed my computer earlier (when it ran out of disk space)
<SpamapS> jml: doh!
<SpamapS> jml: more recent versions don't seem to do that as much
<jml> yeah.
<jml> well, this is whatever is in precise today
<SpamapS> jml: there was a change in txzookeeper that made the client more robust
<SpamapS> ah ok
<SpamapS> hazmat: ^^
<SpamapS> jml: the deadline stuff... makes me wonder if there was a time skew of some kind?
<jml> I guess there should probably also be a circuit breaker in the logging code to prevent killing computers
<jml> although maybe in the cloud it doesn't matter if computers die :\
<hazmat> we need to disable the log verbosity on zk log
<hazmat> its bad
<jml> what do I do to stop the problem?
<jml> it's also chewing cpu
<hazmat> jml, ? cpu logging is chewing up cpu?
<hazmat> er. logging is
<jml> hazmat: the process doing the logging is
<jml> that's how I identified the issue
<jml> fwiw, it's spammed 3G+ while I've been talking here.
<hazmat> jml this is the bug https://bugs.launchpad.net/juju/+bug/958312
<_mup_> Bug #958312: Change zk logging configuration <juju:New> < https://launchpad.net/bugs/958312 >
<hazmat> the short answer is we can just disable the zk log
<hazmat> on the clients
<hazmat> the long answer is a an os.pipe that filters the output of the log to just relay relevant things
<hazmat> eta 10m on the disable fix
<jml> sorry, what I meant was how can I save my computer? just kill the rogue process?
<jml> actually,  screw it, I just did that.
<hazmat> jml, just delete the logs.. or data-dir
<jml> hazmat: I tried that first, still left me with something using approx 100% cpu
<hazmat> jml, that sounds very odd, unless that's a cascading problem
<hazmat> ie. disk full triggers something else bad
<jml> hazmat: well, the earlier disk full was on a previous boot
<jml> but I did have to hard kill
<_mup_> juju/zk-log-client-disable r532 committed by kapil.thangavelu@canonical.com
<_mup_> disable zk client log on agents
<jml> because it's running as root, it uses *all* the disk space
<jml> not just almost all
<jml> so 'sudo reboot' wouldn't work
<hazmat> jml, i've always just removed the offending log file first.. but yeah.. that's ugly
<hazmat> the one line fix  is https://code.launchpad.net/~hazmat/juju/zk-log-client-disable/+merge/103753
<jml> hazmat: cool.
<jml> hazmat: although I have to confess I'm not in a huge rush to switch away from using the package
<hazmat> SpamapS, the zk server isn't up on local provider on reboot...
<hazmat> ie not upstartified
<SpamapS> ahhhh
<SpamapS> hazmat: so perhaps we should back off logging/retries?
<hazmat> SpamapS, its the c library logging, we have to do some magic to get it to do things sanely
<hazmat> like pass it an os.pipe we have a reader on that does something like a  ring buffer before it flushes to the log file
<SpamapS> hazmat: REST API to the rescue? ;)
<jml> anyway, I'm off. thanks guys.
<hazmat> SpamapS, not really.. this an agent problem.
<jml> REST :(
<hazmat> SpamapS, oh you mean rest EVERYWHERE ;-)
<hazmat> rip ;-)
<SpamapS> hazmat: Yeah I think eventually that will happen
<hazmat> that one liner does the safe/simple thing of just disabling the c library logging.
<hazmat> it does occassionally have useful info, but not at the cost/risk it has
<jimbaker> hazmat, +1 on that trivial re zk log, i think you made the right case
<hazmat> jimbaker, thanks.. committing
<cyberplop> Alguien habla espa;ol?????
 * hazmat hits the road enroute to an openstack meetup
<jcastro> SpamapS: all you bro: http://askubuntu.com/q/125640/235
<bobweaver> Yes there is a juju channel
<bobweaver> how do charms work in-comparison to .debs ? are there control files rules ect where can I find tutorials ? besides the ones in the topic. thanks for your time.
<bobweaver> sorry if I missed anything  router geeked out
<SpamapS> doh
<SpamapS> 7 minutes from "how does that work" to /part .. doh
<bobweaver> dang sorry if I missed anything my router stoped working for a little bit.
<mars> SpamapS, ^
<SpamapS> bobweaver: welcome back :)
<bobweaver> I am reading a bunch like the tutorials juju.ubuntu.com/docs/ I am also going to join the mailing list
<bobweaver> Thanks SpamapS
<SpamapS> bobweaver: Charms define services, where as .debs define local, single machine program installations.
<bobweaver> sorry about the break in the tunnel
<SpamapS> bobweaver: there is a metadata file, not unlike debian/control in a debian source package.. and hooks are somewhat like maintainer scripts (preinst, postrm, etc), though their purpose is quite different.
<bobweaver> The real reason that I would like to see more about juju is becasue I watched the keynote for last years UDS and there was something in there like getting away from packaging the way that it is. So I thought that now is the time as I was learing making .debs
<bobweaver> I am going to fire up the virtual machine and install drupel and have a play
<bobweaver> thanks for them tips.
<bobweaver> Is it true that ubuntu is going to try to start usingt juju more and more ? like a re-placemesnt for apt? if too harsh sorry :)
<SpamapS> bobweaver: Its not a replacement for apt at all.
<SpamapS> bobweaver: packaging makes juju charms more robust and easier to write.
<SpamapS> bobweaver: there are some things, however, that are really hard to package in a way that is generically useful.
<SpamapS> bobweaver: for instance, if you have a web app that is changing rapidly, it may be better to deploy with juju and have users always get the latest release, rather than some frozen app from the archive 2 years ago.
<bobweaver> I see so it is mainly for lamp and other fast pace stuff
<SpamapS> not really
<bobweaver> I have been fighting packing this up https://launchpad.net/zpanelcp   may juju would be good ?
<SpamapS> its for integrating that stuff, with the slow moving rock solid stuff
<SpamapS> bobweaver: is it useful in a multi-node deployment?
<bobweaver> yeah
<SpamapS> bobweaver: it looks like a great candidate for juju integration actually
<bobweaver> I am going to give it a shot but we will see. I like to play around with stuff
<SpamapS> bobweaver: documentation is severely lacking on that project
<SpamapS> or well hidden
<bobweaver> I might be able to help I see that there is a juju charm school
<bkerensa> jcastro: You around
 * bkerensa wonders if Canonical (Juju) would like to sponsor the next shirt http://i.imgur.com/ZIzUO.png and get the Juju logo on the sleeve
<bkerensa> :) Eucalyptus sponsored our last edition
<SpamapS> bkerensa: that would be cool
<bobweaver> bkerensa:1st wow & cool. do you know how there are the green love oregon stickers ? maybe make the ubuntu circle into heart. but I think that I would like one of them shirts. they look great.
<bkerensa> bobweaver: :D
<bkerensa> SpamapS: It cost about $497 for us to have 30-40 shirts printed they come out real nice... I wear the Ubuntu Oregon/Eucalyptus shirts often
<bkerensa> :P
<bkerensa> Is kind of sad we have to go to other companies to have them sponsor CD's/Banners etc for us though :P
<SpamapS> bkerensa: if Canonical sponsored every Ubuntu user group we wouldn't have any money to make *Ubuntu*
<SpamapS> In a way, Canonical sponsors anything and everything that has the Ubuntu logo on it. :)
<bkerensa> SpamapS: They give CD's, Banner and Table Cloth to all approved LoCo's
<bkerensa> :P but we continue to be denied approval even though we exceed the criteria :)
<SpamapS> bkerensa: oh, whats up with that?
<SpamapS> bkerensa: IIRC, thats also how you get approval to use the Ubuntu Trademark.. so.. be careful about those t-shirts w/ Ubuntu logo :P
<bkerensa> SpamapS: To be honest? I have no idea and our entire loco is pretty disappointed at it.... We escalated the issue to the CC because we felt we were treated unfairly.... If you look at loco.u.c. see how many U.S. approved LoCo's are having release parties? not many but we are and for three cycles in a row we have the largest release party in the U.S. :) also 20% of our members had commits in 12.04
<bkerensa> so idk
<bkerensa> We have people who work for Canonical in the LoCo who were like "Why did we get declined?"
<bkerensa> idk its a hot mess :P
<SpamapS> bkerensa: but there must be a reason
<bkerensa> SpamapS: I think it was because the LC did not throughly examine our application and had new members...
<bkerensa> they ended up changing the approval criteria right after we were declined because they tried to make up criteria on the fly
<bkerensa> They didnt even bother creating minutes for the meeting
<bkerensa> https://wiki.ubuntu.com/LoCoCouncil/Minutes/20120117
<bkerensa> I had to add them myself
<SpamapS> bkerensa: ouch
<bkerensa> yeah
<SpamapS> so, churn + ineptitude
<SpamapS> bkerensa: perhaps things are better now then?
<bkerensa> yeah and someone from the LC actually told me later flat out we should have been approved
<bkerensa> SpamapS: perhaps but we still have to wait a cycle I guess or response from the CC.... Either way it impacts us getting CD's into the hands of potential users
<bkerensa> and everytime people ask us for printed CD's I have to explain why we don't have them
<SpamapS> bkerensa: you guys going to put a booth up at OSCON?
<SpamapS> Thats been one of my favorite conferences for years
<SpamapS> and its right there in Portland
<bkerensa> SpamapS: yes of course.. We have had one every year
<bkerensa> :D
<bkerensa> and we will be at OSBridge
<bkerensa> and PuppetConf and pretty much everything in our region :)
<SpamapS> bkerensa: if you can't get t-shirts w/ juju logos for your loco.. let us know.. we'll make sure you have a mountain of juju shwag
<SpamapS> jcastro: ^^
#juju 2012-04-27
<bkerensa> SpamapS: Yeah maybe I can do a Juju talk at PuppetConf this year :)
<SpamapS> bkerensa: actually we're looking at doing just that
<bkerensa> SpamapS: They had one last year
<bkerensa> Marc Cluet and Adam Gandelman and some other Canonical guys I dont know
<imbrandon> heya guys just popin in a sec then be back in after bit, but SpamapS , bkerensa knows a few people on the inside of CloudFlare and got the ceo dude to give us a lil tour ( and personally i wanna talk nginx magic with em as its their backbone to 4 billion views a month ) anyhow i thought you may want to try and sneek away at lunch too and go
<imbrandon> SpamapS: bkerensa ^^
<imbrandon> yea billion not mill
<SpamapS> with a b
<bkerensa> SpamapS: http://imgur.com/9GFjR <-- I know Adam G and Marc C but no idea who the rest are
<imbrandon> any how i;ll let you to talk it over more i got to run for a bit , but nothing set in stone yet cept we're definatly invites
<imbrandon> invited*
<imbrandon> back in a while , btw heya bk and anyone else lurkin
<SpamapS> bkerensa: some of our IS guys, I don't know most of them well either ;)
<bkerensa> SpamapS: Btw... What does Paul Oh do? he was walking around OSCON like a big shot and came to our booth and gave me his card and said if we needed anything to e-mail him ;p
<bkerensa> he did have a pretty cool Canonical shirt
<SpamapS> bkerensa: business something ;)
<SpamapS> bkerensa: at 500 people.. its become impossible to know everybody :P
<bkerensa> No wonder his shoes were so well shined
<bkerensa> SpamapS: there needs to be a Public Employee Directory :D
 * bkerensa cannot even figure out exactly how many live in Portland 
<SpamapS> bkerensa: thats by design. Canonical is the most serious about employee privacy that I've ever seen a company.. which is funny because we all work so publicly :)
<bkerensa> SpamapS: Yeah... I usually have to ping someone I know and then have them e-mail our local canonical mailing list for events
<mars> Hi guys, I have a problem that appears to be synchronization between the postgresql db-relation-changed hook and the service that is using the db interface
<SpamapS> mars: sync in what way?
<mars> When I use debug-hooks in my custom charm and run the same commands as db-relation-changed does, then it connects to the database fine
<mars> But when running the db-relation-changed hook script from 'juju add-relation', then the command bombs out with a database connection error
<SpamapS> mars: the environment might be slightly different
<mars> ah
<SpamapS> mars: but it should be mostly the same...
<mars> that does not sound like a fun thing to debug
<SpamapS> mars: is it possible you are not checking to make sure the values are already set in the changed hook
<SpamapS> mars: relation-changed is run once no matter what, at the start, sometimes that is before the other side has set the values
<mars> SpamapS, the values passed in by the database relation?
<SpamapS> mars: basically, you need to assume that things returned by 'relation-get' are actually valid, as they may not have ever been set.
<SpamapS> mars: you can gracefully exit a hook if the values you require are not set yet... your hook will get called again when they are set.
<mars> SpamapS, ok, I have these lines in my hook: user=`relation-get user`
<mars> [ -z "$user" ] && exit 0
<mars> Straight out of the charm tutorial
<mars> Does that check for the user, gracefully exiting if it isn't set?
<SpamapS> mars: yeah
<SpamapS> mars: ok so in that case, perhaps the pgsql charm is broken in some way
<SpamapS> mars: because you should  be able to assume the user/pass/dbname you were given is open for connecting
<mars> SpamapS, could be, I already had to patch it once.  The DB wasn't starting because of a bogus pg_hba.conf entry.
<SpamapS> mars: did we get that fix into the main charm yet?
<mars> SpamapS, got to run, here's what I had to fix: http://pastebin.ubuntu.com/948657/
<mars> later!
<mars> btw, that's the precise charm
<SpamapS> mars: thanks!
<imbrandon> Wow, I knew they did this with Xcode 4.2+ but never knew why, SpamapS still around ? ready this ( fairly short blog post ) and tell me Apple cant be cool in their own way, yea its not Ubuntu open-ness but its beats the hell outa any other propritary vendor including Novel/Mono , yea I'm looking at you charging 200$ for the mobile iOS api , meh
<imbrandon> http://kennethreitz.com/xcode-gcc-and-homebrew.html
<imbrandon> anyhow that just put a very big smile on my face
<bkerensa> imbrandon: ping
<bkerensa> :D
<imbrandon> heya
<bkerensa> imbrandon: so what do you use for irc?
<imbrandon> irssi mostly, just cuz i'm too lazy too properly evaluate subway :)
 * bkerensa uses znc but their push notification module stopped working and I need push notification and something that sits on a vps or instance since I dont leave me laptop on 24/7
<bkerensa> imbrandon: yeah well I dont know how to deploy my charm to EC2
<bkerensa> :P
<bkerensa> only lxc
<imbrandon> irssi plus some php perl and bash glue for all kinda stuf :)
<imbrandon> hahah
<bkerensa> but then again I like gui client or cli not browser based
<imbrandon> ok one sec
<bkerensa> ^
<bkerensa> nvm
<bkerensa> maybe weechat
<imbrandon> subway is nice because its persistant
<imbrandon> thats really all i care about cuz i may actually close my irssi term like 50x a day
<imbrandon> or get to it from 5 diff computers
<imbrandon> thats it, feautres i can always hack something in if i need it in another
<imbrandon> :)
<imbrandon> and apparently according to jcastro i can do that with subwayfine
<imbrandon> :)
<bkerensa> imbrandon: ok run me through it how do I deploy charms on EC2 instead of lxc?
<bkerensa> ahh I got it
<imbrandon> i was gonna say its the same
<imbrandon> just a diff env.y
<avalanche123|h> getting a Error: Permission denied - /tmp/homebrew-juju-0.5.531-PkyV/juju_0.5+bzr531.orig/build/bdist.macosx-10.7-intel when installing juju on OSX using homebrew
<imbrandon> avalanche123|h: ahh you had it installed prior
<avalanche123|h> imbrandon had juju installed?
<avalanche123|h> this is the first time I'm trying to do this
<imbrandon> i need to fix that but yea that tar
<imbrandon> hrm ok
<imbrandon> that last bit is easy
<avalanche123|h> imbrandon anything I can do to fix it?
<imbrandon> um for not the best thing to do ( this si how i got to updatye the forumla to do correctly )
<imbrandon> is download that same tar from LP
<imbrandon> open it and run
<imbrandon> well open it cd to the dir and run
<imbrandon> sudo python setup.py install
<imbrandon> and you'll be good
<imbrandon> one sec let me get you the tar url
<avalanche123|h> thank you!
<imbrandon> np, it did the hard part for you already
<imbrandon> getting teh deps intalled
<imbrandon> thats was the last part
<avalanche123|h> gotcha
 * imbrandon maintains that brew formula btw, got lucky in the timing :)
<avalanche123|h> indeed, fastest response I've received on irc :)
<avalanche123|h> 14 seconds :)
<imbrandon> https://launchpad.net/ubuntu/quantal/+source/juju/0.5+bzr531-0ubuntu1/+files/juju_0.5+bzr531.orig.tar.gz
<imbrandon> hehe yea me and bk was just talkin
<avalanche123|h> nice, thanks again
<imbrandon> np
<imbrandon> if that still dont work let em know
<imbrandon> i;ll be here all morn
<avalanche123|h> kk
<avalanche123|h> imbrandon got it installed, thanks!
<imbrandon> np
<imbrandon> now when its time to update
<imbrandon> you MAY have to manualy uninstall
<imbrandon> because brew wont know its already there
<imbrandon> but just do unstalll instead of install
<imbrandon> or pop back in here
<imbrandon> but there proaably wont be an update for a week or so i;m guessing ( dunno tho )
<avalanche123|h> imbrandon cool, sounds good
<imbrandon> np
 * imbrandon goes to fix the formula
<avalanche123|h> imbrandon ping
<imbrandon> yup
<avalanche123|h> getting this now:
<avalanche123|h>     import zookeeper
<avalanche123|h> ImportError: No module named zookeeper
<avalanche123|h> when running juju bootstrap
<imbrandon> brew install zookeeper
<imbrandon> brew install bzr too
<avalanche123|h> gotcha
<imbrandon> if you dont have bzr
<imbrandon> hrm it should have dine that for you tho
<avalanche123|h> mind if I add it to formula dependencies?
<avalanche123|h> lemme check
<imbrandon> no,please do
<avalanche123|h> brew list | grep zookeeper
<avalanche123|h> zookeeper
<avalanche123|h> I have it
<imbrandon> any help is welcomed, i'm a ubuntu dude and run osx too, but a brew newb
<imbrandon> heh
<avalanche123|h> it is indeed already listed as a dep
<imbrandon> ok hrm hal sex
<imbrandon> yea i thought so
<avalanche123|h> maybe python bindings are not included?
<imbrandon> do you have brew python or just sys python
<avalanche123|h> sys python
<imbrandon> well the forum should install those too
<imbrandon> iirc
<imbrandon> zkpython
<imbrandon> or something
<avalanche123|h> txzookeeper==0.9.5
<avalanche123|h> got this in pip freeze
<imbrandon> k one moment
<avalanche123|h> k
<imbrandon>   system "sudo","/usr/bin/easy_install","txzookeeper","PyYAML", "txaws", "pydot","oauth"
<imbrandon> yea no zkpython , let me see if its actually needed or somethign else
 * imbrandon looks on lp
<imbrandon> sorry it does work local and on a few others but i guess i'm missing a dep somewhere where
 * imbrandon looks
<imbrandon> i wish there was a pbuilder for brew
<imbrandon> lol
<avalanche123|h> heh
<avalanche123|h> I'll try diggin
<avalanche123|h> might end up with a pull request
<imbrandon> sure thing
<imbrandon> like i said i'll be here as well
<imbrandon> i'm gussing thats what it is tho is the pythong zk glue isnt installed and i had it already or soemthign
<imbrandon> if LP would ever load it should hvae the deps listed for my on the official linux deb page
<imbrandon> btw undocumented but brew install --HEAD juju should pull right from bzr
<imbrandon> tooo
<imbrandon> fyi
<imbrandon> for update
<imbrandon> Build-Depends: debhelper (>= 7.0.50~), python, zookeeper, python-twisted, python-txzookeeper (>= 0.9.5~), python-txaws, python-yaml, python-pydot, python-apt, python-oauth, help2man
<imbrandon> ok no need for help
<imbrandon> oauth loisted dot listed
<imbrandon> no apt needed
<imbrandon> yaml good
<imbrandon> yxaws good
<imbrandon> txzookeeper versiion
<imbrandon> Frak
<imbrandon> oh wait you got 0.9.5
<imbrandon> k
<imbrandon> twisted is preinstalled in 10.5 +
<imbrandon> zk is there
<imbrandon> hum
<imbrandon> avalanche123|h: can you try to launch it in a fresh shell
<avalanche123|h> sec
<imbrandon> k
<avalanche123|h> same thin
<imbrandon> kk
<imbrandon> is zkpython in pip ? i cant rember
 * imbrandon looks to see if i have that installed
<avalanche123|h> looking at brew zookeeper formula, there is option to install with python and c bindings
<imbrandon> ahh
<avalanche123|h> by running brew install zookeeper --c --python
<avalanche123|h> lemme try that
<imbrandon> cruft ok
<imbrandon> kk
<imbrandon> wonder how mines workin then
<imbrandon> lol
<avalanche123|h> run brew info zookeeper
<avalanche123|h> what does it say?
<imbrandon> bholtsclaw@ares:~$ brew info zookeeper
<imbrandon> zookeeper 3.4.3
<imbrandon> http://zookeeper.apache.org/
<imbrandon> /usr/local/Cellar/zookeeper/3.4.3 (191 files, 11M) *
<imbrandon> https://github.com/mxcl/homebrew/commits/master/Library/Formula/zookeeper.rb
<imbrandon> bholtsclaw@ares:~$
<imbrandon> i bet your correct i just dont know how i got around it
<imbrandon> but this install is been upgraded manny times from many diff macs
<imbrandon> lol
<imbrandon> i think it started life ina g3 ibook
<imbrandon> i need to setup ci tests on commit , just havent took the time with release "comming" the last few days
<avalanche123|h> haha,  gotcha
<avalanche123|h> I still can't get python module
<imbrandon> ok so
<avalanche123|h> but I'm gonna try completely re-installing zookeeper now
<avalanche123|h> maybe brew is messed up
<imbrandon> this is hokey but now that it has them easy install the others again
<avalanche123|h> sure thing
<imbrandon> brb one sec, got hit the little boys room quickly
<imbrandon> afk
<imbrandon> btw way i planed on adding charm-tools and charmrunner to the brews too so not just now but anytime pull req are very much welcomed if i goof, still pretty new to brewin, old hat on the other side of the fence, funny i use osx for photoshop and Espresso.app traditionally so the last month with the role reverse its kinda funny ( been doing lots of css stuff in linux for a diff proj )
<imbrandon> and prog etc etc on my ubuntu boxen :)
<avalanche123|h> haha
<avalanche123|h> totally
<avalanche123|h> I'm just starting with juju
<imbrandon> i dont really like that i cant pre-build it in a "clean" install tho like a chroot or pbuilder
<avalanche123|h> yeah, no real packages on osx
<imbrandon> yea i've been packaging debs for 6 or more yeas, not much on the osx side till lately
<imbrandon> well fink is almost
<imbrandon> fink actually uses .debs and dpkg and apt
<imbrandon> but fink is a PAIN
<avalanche123|h> heh
<bkerensa> who knew label printing was easy in Ubuntu
<imbrandon> but its about the closest, macports being like bsdports
<imbrandon> heya bkerensa
<imbrandon> but yea packing for fink is actually simple if your used to deb packages, essentiually the same
<imbrandon> but installing fink for a "end user" sucks ass even for me
<imbrandon> and i've done it 100000000 times
<bkerensa> :D
<imbrandon> thats why i think brew took off so well, its really a "lite" juju
 * bkerensa is burning 250 12.04 cd's and and and.... wait for it... Testing each and every CD 
<bkerensa> :D
<imbrandon> where it can do anythging
<imbrandon> bkerensa: thats what the interns are for, like a blonde brunette and re^W^W^W^W ummmm yea
<imbrandon> avalanche123|h: so yea if you like making brews tho you'll love juju , imagin me being able to install a brew from here onto your mac and then a second and have it on bk's mac and then they can talk to each other and config them self based on that talking
<imbrandon> thats the lowdown
<imbrandon> there is lots more to it but easy way to explain it to a brewer
<avalanche123|h> yeah, I'm looking for a nice configuration management / services orchestration solution that's why exploring juju
<avalanche123|h> can it run services in lxc's?
<imbrandon> its still young, so expect bumps but nothing terrible
<avalanche123|h> right, oss
<imbrandon> yea there is one cactch with lxc tho
<imbrandon> they dont persist reboots
<imbrandon> heh
<imbrandon> better off usein MAAS if you need a persistant local
<imbrandon> more than just testing
<imbrandon> avalanche123|h: yea not just oss tho , juju is moving very fast , its a good thing, i love it but yea
<imbrandon> quick iteration and releases are the norm
<avalanche123|h> right, totally undestood
<imbrandon> like weekly or so it seems , not sure it will continue like that with 12.04 out
<avalanche123|h> wow
<imbrandon> but likely for a while untill 1.0
<avalanche123|h> that's fast
<imbrandon> yea and the guys ( and gals ? ) are religipous aobut ttd and stuff
<imbrandon> so never much breakage, just once in a while backwards compat stuff is iffy
<avalanche123|h> that sounds awesome
 * imbrandon is a ubuntu core dev but not a juju dev , i only make charms like your starting to do and happend to package the brew app since i seem to be the token Mac guys arround :)
<imbrandon> just fyi
<avalanche123|h> haha, got it
<imbrandon> same with bkerensa here, infact he just won the last charm contest
<imbrandon> i'm determined to win this one, well one of the 3
<imbrandon> ;)
<bkerensa> imbrandon: and if I win this one coming up well hot damn I will be the new juju evangelist everday
<bkerensa> :D
<imbrandon> heh , psudo am anyhow, just not a great evanglist
<imbrandon> lol
<avalanche123|h> :)
<SpamapS> bkerensa: you ready to join ~charmers yet btw?
<SpamapS> bkerensa: I would normally say if you have two charms promulgated, you're pretty much ready.
<jcastro> let's wait until UDS and make up some silly ceremony
<jcastro> involving beer
<jcastro> (just throwing that out there)
<bkerensa> SpamapS: I need to push openphoto maybe monday or tues for u took peek at
<SpamapS> jcastro: saki bombs for all new ~charmers!
<SpamapS> bkerensa: cool. I would be seriously grateful for another pair of eyes to look at charms as they come in.
 * SpamapS notes that he has *4* submitted for review.
<SpamapS> and ELB as a subordinate is about to drop as well. :)
<bkerensa> saki bombs?
<bkerensa> jcastro: Q: can we byob to UDS?
<bkerensa> :D
<jcastro> hmm, we need to whine about reviews tomorrow
 * bkerensa noticed photos showing bottles of liquor at previous UDSes
<bkerensa> :d
<bkerensa> like at tables
<bkerensa> :D
<SpamapS> bkerensa: after sessions, if you don't go find beer, beer will usually find you
<SpamapS> and frankly... in Oak town.. you want to do your own beer finding. :)
<imbrandon> bkerensa: you need a strong liver for uds
<imbrandon> you have to porepare all yea
<imbrandon> r
<imbrandon> SpamapS: hahaha
<bkerensa> SpamapS: I lived in Bay Area for a few years
<bkerensa> ;p
<imbrandon> SpamapS: i was thinking about trying to find that damn kereoke bar with mrs two teeth in it and dragging all to it, there was some kiler sushi accross the screet too
<bkerensa> Oak Town is not my fave :P
<imbrandon> but it is on the other side of the bay
<bkerensa> imbrandon: dude in chinatown sf they have asian karoke
<bkerensa> :D
<bkerensa> funny as hell
<bkerensa> :D
<imbrandon> hahah
<imbrandon> there is a story bhind the other and it ended with jono dancing with a bottle of beer
<imbrandon> on camera
<imbrandon> no less
<imbrandon> :)
<bkerensa> SpamapS: http://i.imgur.com/3SdUp.jpg
<bkerensa> ;p
<SpamapS> http://tu-349002179.us-west-2.elb.amazonaws.com/
<imbrandon> fairly certain jcastro was there too, i know kenethwimher was and oh hell simon and all of us
<SpamapS> ELB controlled thinkup
<SpamapS> (haven't related mysql yet ;)
<jcastro> what? no spdy?
<imbrandon> jcastro: we doing elb so we have 5x the 37mill numbers from nginx
<imbrandon> :)
<SpamapS> jcastro: you sir, are eeevil ;)
<imbrandon> thirty seven frakin milllion
<jcastro> it's just one more relation!
<bkerensa> If I win XPS I will donate my Dell 14z to Partimus
<bkerensa> :D
<bkerensa> which is only a few months old itself
<imbrandon> Partmius ?
<bkerensa> partimus.org they setup nix boxes in the bay area for non profits and schools etc
<bkerensa> pleia2 and a few Ubuntu CA folk are on the board
<bkerensa> :D
<imbrandon> ahhh nice, in that case i'll bring the older of my two macbooks and make the same deal, if i win one i'll donate it
<imbrandon> :)
<imbrandon> sounds like a great cause
<imbrandon> and its not a terrible macbook, its the white one before the unibodys
<imbrandon> intell core 2 duo 2gb ram
<imbrandon> not a speed demon but good to ssh and surf
<bkerensa> :D
<bkerensa> jcastro: we should instantly win ^ for our charitable natures
<bkerensa> :P
<imbrandon> lol
<imbrandon> nah
<bkerensa> heh
<bkerensa> I would actually trade a XPS for a old macbook LOL
<bkerensa> :D
<bkerensa> ok time to get cracking on charms
<bkerensa> energy drinks ready
<bkerensa> :D
<imbrandon> well if i DONT win i'll trade ya, honestly that one is my beater i take on things like this incse it dont make the trip
 * bkerensa is going to work till 2am (its 11:04pm now)
<bkerensa> imbrandon: which one is it?
<imbrandon> i mean its not tore up or anythign but you know what i mean, stickers everywhere , 4 gens old
<bkerensa> the brushed metal one
<imbrandon> etc
<imbrandon> a1181
<bkerensa> or the ugly white ones
<imbrandon> is the model, white
<bkerensa> hmm
<bkerensa> yeah I want a brush metal one :D
<imbrandon> http://www.everymac.com/systems/apple/macbook/specs/macbook-core-2-duo-1.83-13-specs.html
<imbrandon> its that one
<imbrandon> i have a 17inch mbp i use for work/contract and then my mini
<imbrandon> and i use that white one for camping trips and uds
<imbrandon> and stuff like that
<imbrandon> where it might not make it home
<imbrandon> ;)
<imbrandon> but yea aside from being not the uber latest and i'm spiled its honestly a great machine for someone
<imbrandon> spoiled*
<imbrandon> and really if it had a display port and not mini vga
<imbrandon> i would use it more
<imbrandon> but i need screens
<imbrandon> when sitting at a desk, even with a lappy
<imbrandon> mbp has thunderbot == 3 dvi off one port :)
<imbrandon> more if i was not so $$ cheap
<imbrandon> ok SpamapS and jcastro and bkerensa yall are whitness to me saying that , hold me to it, but i'm not gonna bring it up again cuz i dont want anyone thinking i am trying to bribe a win
<imbrandon> :)
<bkerensa> :D
<bkerensa> imbrandon: is it possible to piggy back on another charm?
<bkerensa> like deploy apache ?
<imbrandon> you mean a sub
<imbrandon> sure
<imbrandon> ots got to be designed that way but there isnt much to the "design"
<imbrandon> SpamapS: is the current expert on it but i can fumble threw one atm
<imbrandon> jcastro: whom has control over the charms import into github nightly
<imbrandon> like where is the script that the cron runs
<imbrandon> heh, it has the old url in the descriptions
<imbrandon> http://charms.kapilt.com/charms/oneiric/haproxy
<imbrandon> etc etc
<jcastro> m_3 runs the github import stuff
<imbrandon> kk
<imbrandon> i'll prod him next time i think about it
<SpamapS> bkerensa: you probably want the new 'subordinate' charm type.
<bkerensa> >.<
<imbrandon> k back to charming for me for a lil while
<bkerensa> screw it I will just write it all
<bkerensa> :P
<SpamapS> hrm.. so this kind of sucks.. if I make ELB a subordinate.. we never get the 'stop' hook called so there's no simple way to know that the other nodes have left.
<SpamapS> Perhaps a peer relation.. hm
<imbrandon> yea a peer-relation so ip can be both added and removed
<imbrandon> i'd like that better than start stop anyhow
<SpamapS> well the issue is that the subordinates run on the same box as the "remote" unit
<SpamapS> so.. its a bit tricky
<imbrandon> right , so check the service type too ? heh
<imbrandon> lol
<imbrandon> too bad subs got to be all at the same level, i can imaging some nice trees that would mimic inheritance
<imbrandon> visually if dran
<imbrandon> drawn
<imbrandon> or cacade maybe is better word
<imbrandon> cascade
<SpamapS> yeah
<SpamapS> I think we'll have to make that a reality at some point
<SpamapS> subs of subs
<imbrandon> yea
<SpamapS> we can call that middle-management
<imbrandon> :)
<avalanche123|h> imbrandon any idea what ERROR Could not find any .pem files. means?
<avalanche123|h> I get this when running juju boostrap
<imbrandon> hrm
<imbrandon> its not finding your ssh key
<SpamapS> .pem?
<imbrandon> so its not likely setup int env y file to point to your auth_keys
<imbrandon> SpamapS: yea osx mixes em
<avalanche123|h> hmm, I must be missing some init steps, where can I read about this?
<avalanche123|h> I could put it in the formula for the future I guess
<imbrandon> ava please do if its part of the install
<imbrandon> but i would not addd bootstrap stuf in there
<imbrandon> can you run
<imbrandon> whatever juju cmd you was doing | tee pbcopy
<imbrandon> then pastebinti
<imbrandon> err pastbinit
<avalanche123|h> don't have pastbinit
<imbrandon> also might open a second term tab ( cmd t ) and keep juju debug-log , going for now
<imbrandon> ava thats what pbcopy is
<imbrandon> its built into osx
<avalanche123|h> gotcha
<imbrandon> it will copy the ourtput to you clipboard
<imbrandon> also might open a second term tab ( cmd t ) and keep juju debug-log , going for now
<imbrandon> and watch as you run things ( it will lag a few  behind and seem "stuck" for 30ish sec or more sometimes in the debug log
<imbrandon> just ewait for it
<avalanche123|h> https://gist.github.com/c607887c23c8b9742cdd
<avalanche123|h> when I rub debug-log
<imbrandon> now as far as whatever those output , SpamapS can proibably help ya better then
 * imbrandon looks
<avalanche123|h> *run
<imbrandon> hrm
<imbrandon> oh
<imbrandon> same issue
<avalanche123|h> yeah
<imbrandon> it cant find your priv ssh key
<imbrandon> eg your env.y is wrong
<imbrandon> likely
<avalanche123|h> which is just ~/.ssh.id_rsa
<avalanche123|h> ~/.ssh/id_rsa
<imbrandon> right and is that listed in ~/.ssh/authorized_keys
<imbrandon> ?
<avalanche123|h> heh, I don't have that set up
<avalanche123|h> ~/.ssh/authorized_keys doesn't exist
<imbrandon> heh ok make sure its listed there and then in the env,y make sure authorized-keys-path: ~/.ssh/authorized_keys
<imbrandon> then bootstrap the env
<imbrandon> and it will have your key copied and work at that point
<avalanche123|h> kk
<imbrandon> SpamapS: every time ssh complains on mac about it wanting a .pem file its the priv key, and some priv keys are .pems for vertain programs like cyberduck needs it like that
<imbrandon> the keygennon osx makes both most of the time default
<imbrandon> iirc
<imbrandon> but the error only ever says one
<imbrandon> and its confusing as shit
<SpamapS> weird
<imbrandon> SpamapS: http://paste.ubuntu.com/949112/
<imbrandon> see i only got one
<imbrandon> and man i need to clean those up
<imbrandon> ugh
<imbrandon> and no idea what those .keystore ones are but likel;y another mac thing
<imbrandon> oh no there is two .pem's in there id_rsa.pem and me@bradnonholtsclaw.com.pem
<avalanche123|h> I run cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys
<imbrandon> just missed one
<avalanche123|h> still same issue
<imbrandon> did you re bootstrap
<imbrandon> the env after
<avalanche123|h> ah
<imbrandon> it needs to ahve the pub key in the bootstrapped env
<imbrandon> so you can ssh in and run juju stuff
<imbrandon> or nadda works
<imbrandon> :)
<avalanche123|h> would opening a new shell do that?
<imbrandon> and with that i'll be right back
<imbrandon> no
<imbrandon> juju bootstrap
<imbrandon> , it makes the first "control" nde
<avalanche123|h> that fails because it can;t find key
<imbrandon> mode*
<imbrandon> that one dont need a key
<imbrandon> well it does
<imbrandon> but it needs the auth
<imbrandon> you just setup
<imbrandon> the pubkey
<imbrandon> make sure authorized-keys-path: ~/.ssh/authorized_keys
<imbrandon> is in your env.y before you bootstrap
<imbrandon> ok i got to be afk a few, SpamapS or bkerensa should be arround if you still need more, at this point you should not have any more specific osx problems
<imbrandon> your past all that
<imbrandon> brb
<avalanche123|h> thanks a lot
<imbrandon> np
 * SpamapS doesn't like helping other dudes w/ their osx-y problems, but if he must.. he will take one for the team. :)
 * bkerensa dances
<imbrandon> SpamapS: promis, as long as bootstrap there works , then its golden, just a matter of knowing what order to run stuff in
<bkerensa> https://code.launchpad.net/~bkerensa/charms/precise/locker/trunk <- jcastro Y CAN HAZ
 * bkerensa goes on to pinry
<imbrandon> cuz i used it on like 10 omg dep[loyds
<imbrandon>  deploys*
<imbrandon> and near every command
<SpamapS> http://tu-349002179.us-west-2.elb.amazonaws.com/ ...
<SpamapS> two instances
<SpamapS> 10.252.25.165 - - [27/Apr/2012:07:02:30 +0000] "GET /assets/img/favicon_googleplus.png HTTP/1.1" 304 186 "http://tu-349002179.us-west-2.elb.amazonaws.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/536.9 (KHTML, like Gecko) Chrome/20.0.1115.1 Safari/536.9"
<SpamapS> mac users
<imbrandon> hey teh modern internets was made on that OS
<imbrandon> maybe fore it was called Mac OS X but still :)
<SpamapS> ok, so I'm sieging that url.. both instances are CPU bound
<imbrandon> was still NeXT then on Tim Burns Lee or showever its spelled
<imbrandon> nice
<SpamapS> adding another one
<imbrandon> here ina  bit i'll have ya try ti on 2 or 3 of my nginx boxen
<bkerensa> exploding wax
<imbrandon> and see how many thousand we can all toss at it
<SpamapS> heh.. sucks to use the amazon EC2 tools.. because they need java :-P
<SpamapS> I wonder if boto has grown elb yet
<imbrandon> threre is a rest api
<imbrandon> curl it
<SpamapS> I'm eh-scared :)
<imbrandon> heh
<SpamapS> also wouldn't that mean I'd need a CERT, precluding use of IAM ?
<SpamapS> or is that the SOAP?
<imbrandon> dont be scared lil boy there nice shaggy carpet back there in the back .... of the van
<SpamapS> I can never remember
<imbrandon> well not precluding the use of it
<imbrandon> but yea
<imbrandon> you can use the cert or 509 or keypair or pass or
<imbrandon> ummm one more
<imbrandon> oh mfa
<imbrandon> with iam
<SpamapS> the keypair requires all that HMAC magic tho
<imbrandon> and yea soap needs 509, rest uses header with the aws keys
<imbrandon> nah the example code uses wget and the does -D for data
<imbrandon> and plain txt keys
<imbrandon> etc
<imbrandon> or maybe curl and -d but still
<imbrandon> one of the two
<SpamapS> and, hooray, 3rd node joins, boxes drop to load of 0.5
<SpamapS> takes a while tho
<imbrandon> stickey sessions
<SpamapS> I'm not using those
<imbrandon> oh
<SpamapS> because I think they're *silly*
<imbrandon> hrm
<SpamapS> no I mean from add-unit to unit being ready..
<imbrandon> they may be silly but saved my asss more than once without any new code
<SpamapS> took about 1 minute for amazon to do its thing
<imbrandon> oh yea
<imbrandon> that always takes a long time to me
<SpamapS> then another 3 to get everything installed
<imbrandon> i thought it was just part of juju
<imbrandon> heh i kick off the scripts from bootstrap to expose as one long chain cmd
<imbrandon> and it comes bacl to promt
<imbrandon> but then its 40ish min
<imbrandon> beofre they are all ready
<imbrandon> on omg
<SpamapS> well thats because there's a 20 minute DB restore
<SpamapS> because mysqldump *SUCKS*
<imbrandon> nah i watched thats like 30 sec
<SpamapS> no, what?
<imbrandon> the db is only 74mb now
<imbrandon> we trimed it
<SpamapS> Oh haha was it like, every user from back when they did comments?
<imbrandon> there was tons of extra crap in there
<imbrandon> yera and 40k play drafs
<imbrandon> and more
<imbrandon> plus*
<imbrandon> oh
<imbrandon> not just back when they did em
<imbrandon> fksin discus was
<imbrandon> doing it in js
<imbrandon> then posting it to the wo
<imbrandon> wo*
<imbrandon> wp*
<imbrandon> so it would clear the cahe on us
<imbrandon> i was like gah
<imbrandon> turn that crap off
<imbrandon> yea so double of ALL comments old and new
<SpamapS> imbrandon: you falling asleep?
<imbrandon> and each time it deployed discus would "sync " and more than double the comments
<SpamapS> missing quite a few letters :)
<imbrandon> yea  and i really need to get this other fished so i'ma ignore chat a bit ;)
<imbrandon> but yea its 74mb now, heh
<imbrandon> quite nice
<bkerensa> SpamapS: you want to review :D  Locker? :P
<SpamapS> well the good news is the departed hook is called when subordinate units are removed
<SpamapS> so ELB can scale up/down properly
<imbrandon> nice, cant wait to try it here in a bit
<SpamapS> only real trouble is that its hard to know when it is ok to delete the ELB fully
<SpamapS> its also really hard to know when its ok to add/remove availability zones
<SpamapS> but I err on the side of enabling them
<imbrandon> so dont, only do it on config chang and make an option
<SpamapS> imbrandon: yeah perhaps we don't need to be super automatic on that
<imbrandon> yea its just cleanup
<SpamapS> imbrandon: problem is juju is kind of random about AZ's unless you specify it as a constraint.
<imbrandon> juju leaves aton of that crap now anyhow
<SpamapS> which I think we need to work out
<SpamapS> I should be able to set a constraint on a service like 'ec2-zone: a,b,c,d' and have it balance the service accross them
<imbrandon> oh yea i think thats a bug imho
<imbrandon> erm well yea but multi zone elb is mucho $$ per hr
<SpamapS> is it?
<SpamapS> like how much more?
<imbrandon> yea like 4x
<SpamapS> oh suck
<SpamapS> Ok I'll just register it in the first AZ and print in debug log where it ended up
<imbrandon> gotta see a man about a horse, afk
<SpamapS> and encourage use of ec2-zone in the README
<imbrandon> yea sounds sane
<imbrandon> for noe
<imbrandon> now*
<imbrandon> i can be iterated through too if we thing about a nother way once it s in real use somewhrere too
<imbrandon> a few places
<imbrandon> etc
<imbrandon> hell thats how the others get so good
<imbrandon> is actual use
<imbrandon> imho
<bkerensa> yay yet another e-mail address :P
<dpkingma> Good friday world!
<dpkingma> Hello #juju! Does anyone have a Juju Charm for MongoDB 2.0+ ?
<bkerensa> dpkingma: http://jujucharms.com/charms/precise/mongodb
<bkerensa> is 2.0+
<dpkingma> bkerensa: thanks!
<dpkingma> Hi again! Can anyone link to information on how to deploy with juju on my own OpenStack cloud? Can't find much info on that...
<bobweaver> Hello there all again I was just looking over open week and am not seeing anything for juju. are you all not doing anything for it ?
<phschwartz> When an add-unit is called, is the <rel>-relation-changed run on every unit in the given relation? or only on the new node?
<phschwartz> should relation-list fail on a node launched by juju?
<jamespage> phschwartz, https://juju.ubuntu.com/docs/charm.html#hooks has a good explanation of which relation hooks fire when
<jamespage> and relation-list only works in the context of a relation hook
<phschwartz> hmm, from my changed hook, it fails to output anything. But I am seeing from the joined that the relation was set.
<phschwartz> Any change if I do a paste of the log you can take a look for me and see if you can point me in the right direction?
<jamespage> phschwartz, sure - can I see your charm as well?  that would help
<phschwartz> All of it or just the changed and joined? the charm works to start a single node fine. But fails when there is a join.
<phschwartz> Here is the log snip. http://paste2.org/p/1997476
<phschwartz> And probally easier for you to see the base charm which I have been trying to figure out why it fails on add-unit.
<phschwartz> https://code.launchpad.net/~negronjl/+junk/hpcc
<phschwartz> That is a link to it in Juan Negron's repo on LP.
<jamespage> phschwartz, ugh - so you are seeing issue trying to scale out?
<jamespage> I suspect that the bit of code in hpcc-cluster-relation-joined which determines the netAddress does not work that well
<jamespage> phschwartz, that charm needs updating to use the private-address stuff provided by juju rather than trying to figure it out itself.
<jamespage> i.e. relation-get private-address $MEMBER
<hazmat> phschwartz, when add-unit is called, every other unit will get joined & changed event for the new unit. the new unit added will get a joined/changed for all the other units.. assuming a peer relation.
<phschwartz> I was thinking that, but if you look at the pastebi, it looks like the relation-set is being called correctly.
<phschwartz> relation-set name=ec2-23-20-114-5.compute-1.amazonaws.com netAddress=10.80.215.254
<phschwartz> relation-set name=ec2-23-20-152-190.compute-1.amazonaws.com netAddress=10.116.202.39
<hazmat> the other problem with that charm is that it never removes entries from that list
<hazmat> the ip temp stuff
<hazmat> negronjl, ping ^ hpcc
<phschwartz> it is far from complete. Only a start of the charm I have been working towards with Juan.
<hazmat> jamespage, it is using the private-address stuff just resolving it as well to ip from dns entry
<jamespage> hazmat, thats not terrible reliable tho
<phschwartz> Is the Flush of values for the hook correct? All of the settings changed are saying (was unset).
<hazmat> phschwartz, the values are automatically flushed if the hook exists successfully (exitcode 0)
<phschwartz> ok, so that is fine. Now just not sure why it seems like that changed hook is not seeing them.
<hazmat> phschwartz, the change hook isn't seeing what?
<phschwartz> returns from relation-list
<hazmat> phschwartz, the change hook may be executed multiple times for a single unit.. ie if the unit changes its setting
<hazmat> phschwartz, we have this alias expansion going on to make things a bit easier.. ie. a join always is accompanied by a change hook.. but if the unit does actually change its settings, a subsequent change hook will be invoked for it on the related units
<phschwartz> In the logs I see each run of the changed hook and I did a juju-log "IP: ${UNIT_ADDRESS}" for the address I should get with UNIT_ADDRESS=`relation-get netAddress ${MEMBER}`
<phschwartz> But I see an error that ${MEMBER} is undefined and because of that I never get the address.
<phschwartz> This is done for UNIT in `relation-list`; do
<hazmat> phschwartz, that's what i'm saying though.. the change hook will be executed subsequently with the value, because of the alias expansion it doesn't nesc have that value because its join hook hasn't executed
<phschwartz> The errors for it are when the changed runs after the join in the logs.
<phschwartz> I doubt that it is logging out of order.
<m_3> imbrandon: github.com/charms all have precise links now... need to decide how to handle multiple series there, but at least they're correct for the moment
<jimbaker> jamespage, you can now use relation-list outside of a relation hook if you specify -r RELATION_ID
<jimbaker> so you just need to know the relation ids. $JUJU_RELATION_ID is specified for relation hooks; and you can use relation-ids RELATION_NAME to get a list of relation ids for that name
 * jamespage stands corrected
<jamespage> I'd not realised that had landed
<jamespage> jimbaker, nice
<jimbaker> jamespage, i still need to update the docs - right now, it's just in the specs
<jamespage> jimbaker, right-oh
<jamespage> phschwartz, re-looking at the hook - MEMBER should be UNIT or vica verse
<phschwartz> I will try swapping them around. That and I am going to go on the nodes and try the relation-list with the -r ID to see if I can figure out what the return is and why it is failing
<jamespage> phschwartz, they need to be one or the other - not both :-)
<phschwartz> oh. That might be the issue. Which is the prefered UNIT or MEMBER?
<jamespage> phschwartz, for UNIT in `relation-list`places each unit name in UNIT in turn
<jamespage> but MEMBER is then used to get the netAddress
<jamespage> so its up to the hook but I would use UNIT
<phschwartz> so I should be using for MEMBER in `relation-list` and then place MEMBER in netAddress
<jamespage> phschwartz, something like http://paste.ubuntu.com/949906/
<jamespage> which deals with hazmats point that netAddress might not be set at the point that the changed hook runs
<phschwartz> hmm, that would be an issue for me. I need it set or the program run below will not work correctly.
<jamespage> phschwartz, note that I can't type ADDRESS
<phschwartz> lol
<hazmat> phschwartz, it will be called again when the address is set
<phschwartz> ok, let me try that and see what happens
<hazmat> and lines 15/16 could be put inside of the conditional block
<jamespage> that would be a good idea
<jamespage> phschwartz, the point is that it will eventually get the right information  -changed will fire multiple times
<phschwartz> Would that loop only return 1 ip or will it loop more then once and place all ip's from the relation in the file.
<jamespage> hazmat, thats why if possible I normally use relation-get private-address $UNIT - I believe that is implicitly set
<phschwartz> The reason I ask is I need the full list of ip's, not just one.
<hazmat> jamespage, yup.. that is always set
<jamespage> phschwartz, that loop will populate the list of ip's with all the related units that have set a 'netAddress' in their -joined hook
<phschwartz> ok, good. That is what I want.
<jcastro> jamespage: m_3 marcoceppi nijaba lynxman- : clint has like 4 charms he's submitted that need reviews
<jcastro> https://bugs.launchpad.net/charm/+bugs?field.tag=new-charm
<jamespage> jcastro, good - I need a break from bug triage
<jcastro> I think clint is a subordinates fan!
<jcastro> https://bugs.launchpad.net/charms/+bug/977552
<_mup_> Bug #977552: Charm Needed: Terraria server <new-charm> <Juju Charms Collection:Confirmed for h5-chuck-9o> < https://launchpad.net/bugs/977552 >
<jamespage> I'll take munini-node
<jcastro> if someone wants to do that one he's  been waiting all month ^^
<jcastro> hmmm, we'll need to figure out a better github workflow at UDS
<jamespage> jcastro, I also want a 'review-charm BUGNUMBER' tool
<jamespage> jcastro, I'll take a look at that one as well
<jamespage> I'm starting to really appreciate subordinates
 * jamespage wonders if m_3 is going todo ganglia as one soon (or whether I should jump in :-))
<m_3> jcastro: will catch up on reviews when testing is updated for precise and ec2
<jcastro> ooh, I missed shelr.tv being promulgated
<m_3> jamespage: by all means... the primary ganglia charm needs to use the packages in the repo, not the ppa BTW
<jcastro> http://jujucharms.com/charms/precise/shelr.tv <--- really awesome service
<jamespage> m_3, yeah - I spotted that - I'll take a sweep through ganglia next week then
<m_3> there's a whole slew of subs that can be written now
<jcastro> jamespage: oh hey, jenkins needs a readme too, I'd like to ask the QA team to start using it
<jamespage> m_3, I want to try some stuff with the hadoop charm and subordinates so that both ganglia and hadoop send information to the ganglia master....
<jamespage> jcastro, so does zookeeper
<jcastro> they are currently not using juju for jenkins and I'd like to change that
<jamespage> jcastro, historical....
<m_3> jcastro: I'll start with the terraria review
<jcastro> yeah, they're keen on doing it
<jcastro> they were just waiting for you know, us to ship, heh
<phschwartz> jamespage: just did an add-unit so will let you know if that change worked.
<m_3> jamespage: yeah, hadoop's a tough call on that one... there's builtin ganglia integration... but we still need a ganglia-node sub in general tho
<jamespage> m_3, yeah - but I'd like to faciliate that through either the subordinate OR directly with the ganglia master
<m_3> yes, great idea.. config options
<jamespage> its working direct in the current charm with your generic hook and some reconfig of hadoop
<m_3> I guess it's really a config option to enable the builtin integration.... the sub would be ignorant of that... perhaps they'd even need to work if _both_ were accidentally enabled
<jamespage> m_3: gonna scratch my head about that next week
<jamespage> 1600 on a Friday is not a good time todo that kinda thinking :-)
<m_3> jamespage: the current hook is not using the hadoop builtin integration though... I'd imagine that'd potentially have more instrumented stuff... dunno though
<m_3> ha! yes
<jamespage> m_3, the new one for precise does
<m_3> cool
<jamespage> its a bit nasty cause you have to restart the hadoop daemons to get it to start sending metric....
<m_3> dang
 * m_3 still don't have a good feel for ramifications of service restarts on data integrity
<m_3> seems like there'd have to be some serious sequencing going on if you're using a lot of different bigtop components
<hazmat> gmb, ping
<gmb> hazmat: Hi
<jamespage> m_3: yeah - I need some sort of super-orchestrator
<hazmat> hi gmb i just wanted to followup on the lp installs taking a while.. i was trying to understand what the slow points are
<hazmat> gmb, gary_poster had mentioned you had tried to stuff some of the bits into s3, but it was too slow to download?
<gmb> hazmat, Yes. So, LP dev environments are slow to install.
<gmb> We can't change that any time soon.
<gmb> ~30 minutes is the norm, ~40 on a small instance. More if we're installing lxc and creating containers...
<hazmat> gmb, that's probably the best solution, so i'm trying to understand what's slwo about them?
<gmb> hazmat, Lots of stuff. We have to:
<gmb> Install build deps.
<gmb> Grab the source
<gmb> Build all the sdists (there are a lot)
<gmb> Build mailman (takes ages, don't know why)
<gmb> Build WADL for the API (also takes ages)
<gmb> Create the sample DB (shorter than it used to be, so maybe not a big issue any more)
<gary_poster> checking out the branch alone takes awhile :-/
<hazmat> gmb, could you see a src tarball onto s3?
<hazmat> s/seed
<niemeyer> gmb, gary_poster: If you're happy with a snapshot, you may as well snapshot that procedure by uploading the final state onto S3
<gary_poster> gmb, didn't you determine that S3 itself was not as snappy as you liked?
<gmb> hazmat, niemeyer: Trouble is, the tarball would be in the order of 1.5G once everything is built. And as gary_poster said, s3 was pretty damn sluggish.
<niemeyer> There are huge pipes between S3 and EC2
<gmb> Maybe they were clogged.
<gary_poster> heh
<hazmat> gmb, you should be parallel download from s3
<hazmat> er. able to
<niemeyer> gmb: I was transferring 8GB just the other day.. it doesn't feel bad at all
<gmb> niemeyer, Oh. In that case my experience was not representative. However, I don't have time to try it all over again today. I'll give it another shot when I'm in Oakland, since I'm going to have to re-do things on us-west-1 anyway.
<niemeyer> gmb: Cool, please ping me if you'd like someone to be brainstorming this with
<niemeyer> gmb: Will be there as well
<gmb> niemeyer, Will do, thanks.
<gmb> Excellent. There may be questions, then :)
<gary_poster> niemeyer, gmb, we'd like speed reliability, so while a single experience of slowness might not be representative, it is worrisome: if people are unable to participate in the hack session after 10 or 15 minutes, the value is gone IIUC
<gmb> Yes, exactly. But the only way to really decide is to stress-test it, I guess :)
<niemeyer> gary_poster: There's no such thing as speed reliability when talking about shared ip networks.. that said, there are huge pipes between S3 and EC2.. if these pipes are not enough, I'm not even sure that image snapshots would help.. there's still transference going on to get image snapshots into place.
<niemeyer> gary_poster: There are other possibilities too, like EBS, etc
<gary_poster> ack about no complete speed reliability, niemeyer, and about transference to get image snapshots into place.  I believe the image transference is cached in a way that S3 is not, but I could very well be wrong there, since that's merely an impression.  EBS: yeah, I looked at that briefly for this, but simultaneous sharing seemed to not be supported AFAICT.  I'm sure you know much more about this than I; thank you for your off
<gary_poster> er to help with brainstorming with gmb.  I bet that would be a big help.
<gmb> niemeyer, gary_poster: My "I don't have time" turned into "This is bugging me..." much, much, _much_ faster this time, so it might actually be workable after all.
<gary_poster> gmb, which, S3?
<gmb> gary_poster, Yep.
<gary_poster> cool gmb
<gmb> took seconds instead of several minutes. I must have just hit a bad pipe :)
<gary_poster> heh
<gary_poster> If the max for getting a new LP instance to hack on is < 10 minutes that's pretty good, I'd guess.  If the median is < 5 that would be awesome.  You'll still need to run make schema I suspect
<gmb> Yes. Plus all the install steps. But if I can have mailman and wadl built a lot of the problems diminish relatively quickly.
<gary_poster> you could make the dev do this as a "learning experience" to put it in their hands sooner :-)
<gmb> Heh :)
<gary_poster> and the eggs
<gmb> And those, yes.
<senior75151> juju is basically an appliction that controls your devops deployments. In my case I'm testing the set up of a hadoop cluster (just starting) so I need to set up my keys in my yaml config and that's it ?
<senior75151> I'm wanting to deploy this on ec2
<SpamapS> gary_poster: I'm really curious as to why you are building mailman instead of putting it into a .deb
<SpamapS> gary_poster: all thoe sdists seem ripe for .debs
<SpamapS> senior75151: right, just setup your EC2 access creds and then bootstrap/deploy away
<gary_poster> SpamapS, mailman: it is a hacked version of mailman done by barry because mailman 2 was not designed to be used as a library.  mailman 3 has changed that, fwiw.
<senior75151> SpamapS: deam that's easy!! just found the tutorial here https://juju.ubuntu.com/Documentation Thanks a lot. I honsetly spent like 2 days setting up hadoop on my local computer, ha! I'm not a devops I'm just a developer.. soo crossing fingers this works well :)
<SpamapS> senior75151: so are we :)
<SpamapS> gary_poster: but ultimately, it sticks a bunch of files on the filesystem, right? .debs are good for that sort of thing. :)
<senior75151> SpamapS: can one tell the charm which computer type to use. e.g.: which amazon ec2 instance type. Like Mid, Large, etc. While keeping the same configâ¦ Say for staging we only need like a Mid but for prod we need Large
<SpamapS> senior75151: juju deploy hadoop --constraints instance-type=m2.xlarge
<SpamapS> senior75151: or, more generically   juju deploy hadoop --constraints cpu=16,mem=10G
<jamespage> SpamapS, I'm struggling with jitsu gource - does it work on precise?  all that happens to me is gource whinges about the log format and everything dies...
<SpamapS> senior75151: btw, you need to be on Ubuntu 12.04, or have the latest juju from the PPA or Brew (OS X) for that to work.
<SpamapS> jamespage: I think you might need to try the latest version
<SpamapS> jamespage: it was quite broken in 0.4
<jamespage> senior75151, the README for hadoop has some guidance on sizing for the different roles within hadoop - you will need to tweak the config of each to make sure hadoop uses it all
<jamespage> SpamapS, ack - I'll give it a spin
<gary_poster> SpamapS, sdists vs. debs: this is a years-old argument circling around what is the proper packaging for consuming Python packages for a non-system non-commodity application under development.  There is absolutely no need to rehash it now for LP's sake, for many reasons.  In Canonical now, fighting the deb route would be a challenge for future projects, but some might still be willing to take up that challenge.  I'm on the no
<gary_poster> n-deb side actually for this, but not enough to fight the Canonical tide.  Debs are moderately alright with me for development, especially for a project that does not have >150 Python egg dependencies like LP.
<senior75151> SpampS: thanks for the tips will doâ¦ I'm getting an error on MACOSX goign to try to install  on ubuntu.
<senior75151> jamespage: thanks for the heads up. WIll keep in mind.
<SpamapS> gary_poster: but can't you basically just change the setup.py args to build a deb?
<gary_poster> More important SpamapS, IMO it's worth noting from juju's perspective that this *is* an argument.  "You're doing it wrong, package everything in debs" is not a great answer for all potential adopters IMO.
<jamespage> SpamapS, thanks for that pointer - works great from trunk
<SpamapS> jamespage: probably worth making a release, though I want to talk to jimbaker about renaming 'do'
<jamespage> ack
<SpamapS> jimbaker: hey, the name 'do' is too confusing. Can we rename that command to be more clear about what it actually "does"
<jimbaker> SpamapS, certainly. "do" is very generic
<jimbaker> SpamapS, maybe exec-in-hook-context ?
<SpamapS> jimbaker: that seems long winded.. but maybe it needs to be :)
<jimbaker> SpamapS, it does sort of convey the backdoor aspect of what's being done here
<jimbaker> almost want to call it "jitsu poke" ;)
<SpamapS> jimbaker: All the other sub commands are very obvious as to what they're for. open a port, run gource, get unit info.
<SpamapS> jimbaker: exec-in-hook-context doesn't tell me what it is for
<SpamapS> It requires deep juju knowledge to know what its for, rather
<SpamapS> jimbaker: run-hook-cli ?
<jimbaker> SpamapS, or maybe run-as-hook?
<SpamapS> *perfect*
<jimbaker> cool, i will make that change
<SpamapS> jimbaker: if you can mege in a rename, I'll release as 0.6
<gary_poster> SpamapS, change the setup.py args: you mean of LP?  No, it's not nearly that easy, I'm pretty sure.  Of the dependencies: building debs from reasonably well packaged Python code is impressively easy these days from what I've seen, but it's still not clearly documented (we recently found the wrong way on the wiki and carefully tried to clean it up, for instance, only to be pointed elsewhere once we asked an expert to review i
<gary_poster> t) and still has plenty of potholes for the uninitiated (for instance, getting deb numbering right in PPAs has tripped us up several times lately).  I'm not saying that these are a problem for experts, but I am saying that it is not trivial and it is not without issues.  It won't happen for LP given the current focus, I predict.  For other projects, IMO the cost of packaging is not negligible and not as clearly a win to ever
<gary_poster> yone that the juju project will encounter, which is the only message I really feel like conveying.  As I said, rehashing the LP argument really doesn't have a lot of value, I think.
 * gary_poster likes walls of text.  So pretty.
<SpamapS> gary_poster: setuptools has an option to automatically build a .deb instead of a .tar.gz
<gary_poster> yes it does, SpamapS.
<gary_poster> We also could build eggs
<SpamapS> yeah
<gary_poster> Which have the same characteritics
<SpamapS> that seems better :)
<gary_poster> but these have caused problems in the past across architectures
<SpamapS> :) yeah
<gary_poster> we have devs on different architectures, and as of a few months ago even different architectures in production unfortunately
<SpamapS> gary_poster: well given all of that, I think the idea of just tarring up all your needed stuff and sticking it in S3 is the best option.
<SpamapS> gary_poster: the EBS idea is sound too... but juju won't help you much there unfortunately
<SpamapS> hm, unless.. I make an EBS subordinate. :)
 * SpamapS cannot stop coming up with ideas for using subordinates to take over the world
<gary_poster> SpamapS, S3: certainly in the short term, yeah.  I think that's the approach that gmb is working on now.  My only remaining interest in this topic TBH is that I think there's a real-world scenario that juju would ideally support easily, rather than demanding a world view of their potential adopters.  "Don't do it that way" responses may be appropriate and necessary sometimes, but should be challenged and probably even docume
<gary_poster> nted (in part to make sure there are not too many of them).  I understand from other conversations that this use case isn't necessarily all that easy to handle, particularly within the juju vision.  But "the real world is messy" may be a reasonable response to some of this.
<gary_poster> (and so juju should consider handling at least some of the messiness)
<gary_poster> but this has gone well past the immediate needs of my squad :-)
<gary_poster> so...yeah!  yay, subordinate charms! ;-)
<SpamapS> gary_poster: LP is not alone in the long-build-time camp
<gary_poster> Yeah, that's really all I'm saying
<SpamapS> gary_poster: in fact I see *huge* value in being able to do things like run your full test suite on the first deploy of something, and then snapshotting that so its a known good build.
<gary_poster> All that I care about communicating, at least ;-)
<gary_poster> +1 yeah
<jimbaker> SpamapS, i renamed "jitsu do" to "jitsu run-as-hook", so it's ready for release now
<m_3> jimbaker: nice... that makes sense
<SpamapS> jimbaker: thanks!
<SpamapS> also just added --version to jitsu
<SpamapS> anybody want to squeeze anything else into juju-jitsu 0.6?
<m_3> SpamapS: yes, but it's not going to happen this week... so perhaps 0.7
 * SpamapS pulls the release lever then
<bobweaver>  \0/
<bobweaver> I made a little into video to juju  for youtube today. once I start to understand more about It I am going to make many many more :)  So flippen cool after I watched the classroom video I understand the power that it could have.
<m_3> bobweaver: awesome!... links?
<bobweaver> http://www.youtube.com/watch?v=495V7FokwBU&webm=1
<bobweaver> It started out as how to file a bug
<bobweaver> but I just could not help but talk about juju
<SpamapS> :)
<mars> Hi everyone, I saw there was a fix-committed bug for a Cloud Foundry charm.  Has anyone tried it out?
<SpamapS> mars: negronjl wrote those.. and there are some issues with them.. namely that they use their own "special" mysql/mongodb/etc. charms.
<SpamapS> negronjl: ^^ whats happening with the cloudfoundry charms? anything?
<negronjl> SpamapS: i haven't done anything with them.
<negronjl> SpamapS: What's the main issue ?
<mars> I just wanted to try them out, to see if I could use them to get a Django app onto a juju/cloudfoundry environment.
<mars> I see the instructions are in the bug, but I was wondering if anyone else had tried them out.
<SpamapS> negronjl: that they don't use the stock mysql/mongodb charms IIRC
<negronjl> SpamapS: CF adds a lot of "glue" code to their db's.  Enough to justify having their own charms
<SpamapS> negronjl: we discussed this in the past, that this glue would still benefit from living in the main mysql charm.
<SpamapS> negronjl: so that you can, say, tune the mysql with the same 'juju set' commands
<negronjl> SpamapS: What we didnt realize is the amount of glue that is required .... There are several daemons that need to "live" where the mysql/mongodb daemon is at as well.
<negronjl> SpamapS: We would have to add substantial code to the mysql/mongodb charms to make them "play nice" with CF
<negronjl> SpamapS: doable yes ... advisable ... not so sure
<SpamapS> daemons??
<SpamapS> like, mysql proxy?
<SpamapS> negronjl: those daemons can be started when the relationships are established.
<SpamapS> negronjl: I'm mostly concerned about fracturing the space.. if you do something awesome for CF's mysql that is a generic mysql improvement.. it should benefit all juju mysql users if possible.
<mars> Isn't making things live on the same unit as a service what subordinate services were designed to do?
<SpamapS> mars: in this case.. not really. If its directly related to the service working or not, it belongs in the main charm, as part of the relations.
<mars> ah
<SpamapS> negronjl: if its a ton of work, no big.. but it should still be a goal. I am not convinced that anything "special" that CF does to the mysql server is special enough to keep it out of the main mysql charm.
<SpamapS> The idea is to group devops knowledge around the best way to run a service in one place.
<negronjl> SpamapS: Let me finish a call and I'll talk to you more about it
<negronjl> SpamapS: Give me a few minutes
<SpamapS> and fork only when necessary. :)
<SpamapS> negronjl: sure no problem. Just triaging bugs. :)
<mars> I just changed my reviewboard charm from postgresql to mysql: three lines changed in the hooks, plus the juju commands to upgrade and deploy the new services.  Wow, very cool.
<SpamapS> mars: you can leave both in there if you want. "requires" is a bit misleading.. admins can choose one or the other.
<_mup_> Bug #989967 was filed: juju should ignore dotfiles in local charm repositories <juju:New> < https://launchpad.net/bugs/989967 >
<senior75151> how to set a default on juju
<senior75151> i get this error
<senior75151> There are multiple environments and no explicit default (set one explicitly?)
<negronjl> SpamapS: There is significant work that would be needed to add the CF bindings into the existing mysql/mongodb charms.
<negronjl> SpamapS: It can be done but, I am not sure we should do it
<negronjl> SpamapS: Another way would be to use the cf-specific charms to launch the initial DB ( ie: mysql master ) and have the regular charms do the slave ones
<negronjl> SpamapS: For mongodb, It would work in a similar mannger ( cf-mongodb as master and regular mongodb charms as slaves )
<m_3> boolean config params are _much_ harder to use than they were before typechecking was enabled
<SpamapS> negronjl: I'll take a look.. I think I need to  understand the problem space better before I expect you to do more work. :)
<bkerensa> nathwill: SpamapS  and jcastro are the chiefs here
<bkerensa> :D
<hazmat> yeah.. i looked at the cloud foundry stuff its non trivial for generic usage
<nathwill> thx bkerensa
<nathwill> anyone got tips on how i can troubleshoot issues with locally deployed services ending up with  agent-state: pending, public-address: null?
<jcastro> senior75151: you can add default: in your environments.yaml for that
<jcastro> senior75151: mine is "defaults: ec2"
<hazmat> senior75151, you can specify a default: env_name in your environments.yaml.. or specify one directly on the command line with the -e flag.. or specify one with the JUJU_ENV environment variable
<SpamapS> nathwill: its possible the first machine is still downloading/booting
<hazmat> nathwill, the first provisioning on local service can take a little while
<jcastro> bobweaver: I'd be more than happy to link to any juju videos you make from juju.ubuntu.com!
<SpamapS> we need a better log watcher for that
<SpamapS> debug-log doesn't show anything IIRC
<hazmat> nathwill, ps aux | grep lxc
<nathwill> spamaps, hazmat: this is the bootstrap?
<nathwill> kk
<hazmat> nathwill, post bootstrap.. adding the first unit to a local env, has to download a bunch of packages..
<hazmat> effectively a minimal distro
<senior75151> jcastro: thanks
<senior75151> ok how does one search for like juju instances
<senior75151> ala apt-cache search
<senior75151> I tried juju deploy hadoop
<senior75151> didn't work
<hazmat> nathwill, if your on fast conn it can take like 10m
<senior75151> I'm sure there has to be a site or a CL command to search
<hazmat> senior75151, http://jujucharms.com
<senior75151> hazmat: thank
<senior75151> errâ¦ Thank you.
<nathwill> hazmat: ok.. thanks for the tip. i see a lot of lxc activity in ps, so i'll give it some time.
<senior75151> sooo if one does precise on the configurations on amz it works.. ? has anyone tried?
<senior75151> that is for the default-series: precise
<mars> hazmat, what do you mean by 'non-trivial for generic usage'?
<jcastro> yep, it does
<hazmat> mars, just the cloud foundry stuff has some specific bits in each of their services which are not nesc. appropriate for generic usage
<senior75151> jcastro:thanks
<jcastro> senior75151: I do believe that just not setting a default-series defaults to precise, but not sure (hazmat or spamaps?)
<adam_g> hmm
<hazmat> jcastro, it does when generating it, but that key/value needs to be present in the file
<mars> hazmat, but it still works fine for end-users?
<jcastro> ah ok
<hazmat> mars, you mean cloudfoundry will? or the cloud-foundry services used outside of cloud-foundry?
<mars> hazmat, just to play around with
<adam_g> im assuming im doing something wrong here using relation-ids + relation-list + relation-get, any ideas? http://paste.ubuntu.com/950464/
<hazmat> mars, i haven't tried the cloud-foundry charm in a while, but it works afaik
<hazmat> mars, negronjl is the man to ask when it comes to juju+cf
<m_3> jimbaker: ^^ (adam)
<hazmat> adam_g, woah
<hazmat> adam_g, you should have something in the unit agent log as well
<hazmat> adam_g, could you paste that also
<negronjl> mars:  hello
<adam_g> hazmat: sure, one sec. the charm log is spewing: juju.state.errors.RelationStateNotFound: Relation not found
<hazmat> adam_g, could you paste one of the tracebacks
<hazmat> pastebin that is
<adam_g> hazmat: unit agent log == charm.log ?
<hazmat> adam_g, yup
<mars> negronjl, unping, just finishing off that earlier conversation about cf :)
<negronjl> mars: np
<adam_g> hazmat: http://paste.ubuntu.com/950474/
<bkerensa> jcastro or SpamapS can you help nathwill with a juju issue he is having :D
<SpamapS> senior75151: to search the charms, install charm-tools, and use 'charm search'
<SpamapS> senior75151: its *very* limited
<SpamapS> senior75151: basically just greps the list
<jcastro> nathwill: what's the problem?
<SpamapS> senior75151: there are plans to ad full search capabilities into juju though
<jimbaker> adam_g, so no relation state for that relation id
<nathwill> jcastro, not much right now, trying to wait for the 15 min recommended by hazmat...
<nathwill> thanks. i'll hit you up if it's not working after that
<hazmat> jimbaker, but he has the that rel-id immediately proceeding as the output of relation-list
<hazmat> er. relation-ids
<jimbaker> hazmat, yes, that definitely looks like a problem - it's with respect to that service unit
<senior75151> SpamapS:
<senior75151> thanks
<jimbaker> swift-proxy/1
<senior75151> How does one know how many instances a charm will launch, Like I did juju deploy hadoop-master and it deployed 2 small instances
<senior75151> does the charm-tools give you that info
<senior75151> say I do charm search hadoop-master âinfo
<senior75151> or smth
<senior75151> like that
<senior75151> dunno
<SpamapS> senior75151: charm will only ever launch one per deploy
<senior75151> ohh ok
<SpamapS> senior75151: unless you pass '-n #'
<jimbaker> the other thing here is that we need to register RelationStateNotFound with amp so it doesn't default to the unknown error
<SpamapS> senior75151: add-unit/remove-unit to control the size of the service itself
<senior75151> soo weird, the first deployed failedâ¦ (as in the error message) but succeeded on ec2
<SpamapS> senior75151: bootstrap launches one as well
<senior75151> ohhh
<senior75151> ok
<hazmat> jimbaker, yes on relstate not found.. but what do you mean respect to that unit
<senior75151> so that must be it
<senior75151> SpamapS: soo one more question. Now that it's deployed I just write apps against those services and that's it ? no way! that's awesome
<jimbaker> hazmat, i would expect that if relation-ids returns an id, it's there for subsequent use in the hook (such as this debug hook session)
<senior75151> Also I did $man juju; juju help deploy â¦ how do I know the switches for deploy
<jimbaker> i don't explicitly test this scenario with respect to debug hooks, but it's not what i would expect. anyway... i will take a look at this issue
<senior75151> say I want to give a name to the instance i deployed where to look for this info
<adam_g> jimbaker: i can try executing during normal hook execution (outside of debug-hooks) if you'd like
<jimbaker> adam_g, sounds good
<hazmat> jimbaker, aren't you assuming its not there anymore?
<hazmat> adam_g, could you pastebin your status?
<hazmat> adam_g, you didn't modify the rels/units while you where in debug hooks?
<SpamapS> senior75151: juju deploy --help
<adam_g> hazmat: no, i havent touched anything. im just trying to query the private-address for each of those relations.
<hazmat> jimbaker, so there's a bug of a different sort it sounds like
<jimbaker> hazmat, indeed
<hazmat> adam_g, thanks
<adam_g> juju status -> http://paste.ubuntu.com/950511/
<senior75151> SpamapS: sweet thanksâ¦
<hazmat> SpamapS, how are you release juju-jitsu?
<hazmat> SpamapS, into the distro?
<hazmat> SpamapS, ppa .. or pypi?
<nathwill> hazmat: no change :( http://paste.ubuntu.com/950525/
<adam_g> hazmat: jimbaker i should mention that only fails when im executing those against relations other than the current, if that makes sense..
<hazmat> nathwill, what version is the host?
<hazmat> nathwill, is the host precise as well?
<nathwill> hazmat precise upgraded from beta 2
<nathwill> yessir
<nathwill> or ma'am...
<hazmat> :-)
<hazmat> nathwill, any other files in /home/nathan/.juju-data/nathan-sample/units/mysql-0/  .. ie. is there an agent log there?
<jcastro> SpamapS: charm policy question ... your spdy charm installs something beta. Do we care about the state of an upstream whenn considering putting something in the charm store?
<nathwill> hazmat: container.log, output.log, unit.log
<nathwill> hazmat: unit.log has some zookeeper handle_socket_error socket connection timeout msgs
<hazmat> nathwill, could you pastebin the unit.log
<nathwill> hazmat: sure thing
<hazmat> that's from the unit agent which is what's setting values reported by the status cmd
<nathwill> hazmat: http://paste.ubuntu.com/950553/
<hazmat> nathwill, do you have any firewalls/iptables on that machine?
<nathwill> hazmat, running ufw in default deny mode
<hazmat> nathwill, bingo.. that's the problem
<nathwill> heyo... alright, i'll disable, destroy-environment and try this again :)
<hazmat> nathwill, you might not even need to do that if your up for modifying the firewall rulz live.. the container agent will continually try to poll
<hazmat> to connect to zk
<hazmat> but its probably better to destroy-env and start again
<hazmat> nathwill, the host has a zookeeper instance binding to the bridge address 192.168.122.1 .. and the containers which are connected on the subnet off the bridge attempt to connect back to the zk instance
<hazmat> sounds like the firewall rules stop that connectivity, which is the problem
<nathwill> hazmat, ok, that makes sense.
<mars> I just saw my db-relation-changed hook get executed twice in a row.  Is that normal?
<nathwill> hazmat, i think that got it, the units have public-addresses now, and tailing the unit.log, i can see them pulling in packages
<nathwill> hazmat: thanks so much for your help :)
<senior75151> how come http://pastebin.com/zmGqs8Qc I get an install error
<senior75151> even though the deployment was 'successful'
<bobweaver> so I was thinking of a way to make a video for juju and would like too interview one of you. Is there any way that I could get some one on one time with one of you ?
<senior75151> juju status says agent-state: install-error
<bobweaver> I was thinking like  Saturday ? If I could set up interview ? ping me if you like the idea
<jimbaker> adam_g, that's what we call the "implied relation". were you able to run this in normal hook execution?
<adam_g> jimbaker: working on that now. strange, im actually using the same logic elsewhere in the charm with another relation, and it seems to have worked fine until i hit that problem, then it became broken.
<nathwill> hazmat: definitely working now :D time to take this puppy for a test drive!
<hazmat> nathwill, sweet!
<hazmat> senior75151, so basically that means the machine is up and running, but the charm install hook had an error
<hazmat> senior75151, and the unit transitioned to an error state
<senior75151> ohh hazmat: thanksâ¦ so how to fix
<hazmat> senior75151, you can use debug-log in conjunction with resolved --retry to watch what goes wrong.. or you can log into the machine via juju ssh hadoop-master/0 and look at the charm.log at /var/lib/units/hadoop-master-0/charm.log
<senior75151> redeploy I guess ?
<hazmat> senior75151, the juju resolved --help
<senior75151> ahh thanks
<senior75151> excellent will do
<SpamapS> jcastro: re spdy being beta.. no. We only care (for now) that it is verifiably the source you intended.
<senior75151> hazmat I think that might be the problem juju ssh: error: unrecognized arguments: hadoop-master/0
<SpamapS> jcastro: once we have tagging and default search.. we will start being more picky. :)
<senior75151> it prolly couldn't do itâ¦ I'm going to change from precise to oneric and see if that helps
<hazmat> senior75151, hm.. that seems like a bug in juju ssh
<adam_g> jimbaker: oh, disregard that. it just happened to be working because of the ordering of the relations (it was only ever being executed from an implied relation).  it looks like the same issue happens during non-debug-hooks execution
<hazmat> senior75151, you can juju ssh 1
<hazmat> to login directly to the machine the hadoop-master unit is running on
<senior75151> $ juju ssh 1
<senior75151> usage: juju ssh [-h] [-e ENV] unit_or_machine [command]
<senior75151> juju ssh: error: unrecognized arguments: 1
<senior75151> how can that not work but juju status work?
<senior75151> weird
<hazmat> huh
<SpamapS> were it me, I' use juju debug-hooks hadoop-master/0
<hazmat> SpamapS, debug-hooks takes some explaining..
<hazmat> juju ssh works fine for me.. something is fishy
<senior75151> soo that worked
<senior75151> I think what happened
<senior75151> was that I didn't accept the public key
<senior75151> cuz when I did debug
<senior75151> it asked me if I would accept the public key
<senior75151> errâ¦. fingerprint
<senior75151> for ssh
<senior75151> and then i'm in...
<SpamapS> debug-hooks puts you in the charm root
<SpamapS> and you get the right context with the right env vars
<senior75151> got youâ¦.
<SpamapS> The only confusion is that you have to exit the shell when you want juju to run the next hook
<senior75151> i think it automatically starts screen or smth
<SpamapS> senior75151: right
<SpamapS> tmux, but yeah
<SpamapS> Its weird, sometimes I get tmux+byobu, sometimes just tmux
<senior75151> anoying cuz i'm using tmux on my host
<jimbaker> adam_g, thanks for the feedback
<senior75151> so now is double tmux
<senior75151> errrr...
<senior75151> soo I think I found the error but not sure whyâ¦ Started service unit hadoop-master/0
<senior75151> 2012-04-27 18:33:55,073:4640(0x7f7d675b6700):ZOO_WARN@zookeeper_interest@1461: Exceeded deadline by 57ms
<senior75151> that's from /var/lib/log/machine-agent.log
<senior75151> there is a bunch of timeouts
<senior75151> any ideas ?
<senior75151> I don't think is the precise vs oneric
<senior75151> doing an lsb_release -a shows 12.04
<senior75151> soo i think that part is not itâ¦ wondering.
<SpamapS> senior75151: no thats just noise
<SpamapS> senior75151: the install error will be very clearly shown in the charm log
<SpamapS> senior75151: /var/lib/juju/units/hadoop-slave-0/charm.log
<adam_g> jimbaker: np, ill keep the environment up for a while. let me know if there is anything you'd like me to test, or i can give you ssh access
<SpamapS> adam_g: you have a knack for finding all the weird bugs in juju :)
<senior75151> SpampS: http://paste.ubuntu.com/950654/
<senior75151> Couldn't find any package by regex 'hadoop-0.20-namenode'
<senior75151> basically
<senior75151> didn't isntall
<senior75151> :(
<SpamapS> senior75151: aha!
<senior75151> i gess that's a bug ?
<SpamapS> perhaps, looking at the charm now
<senior75151> k
<SpamapS> apt-add-repository ppa:mark-mims/hadoop
<SpamapS> m_3: hey! that doesn't look right
<SpamapS> m_3: don't we have a better place to get hadoop than your PPA ?
<jimbaker> adam_g, sounds good, thanks
<senior75151> SpamapS: do you know if the oneric works ?
<SpamapS> senior75151: probably, but I think we can fix precise fairly easily
<SpamapS> I think we just need to point it at https://launchpad.net/~hadoop-ubuntu/+archive/stable
<senior75151> command line argument ?
<senior75151> or smth
<SpamapS> I'm deploying with that new PPA right now
<senior75151> SpampS: wow! awesomeâ¦
<senior75151> :)
<SpamapS> senior75151: the power of debug-hooks :)
<senior75151> manâ¦. this IRC is awesome! hehe...how to reinstall on the same host?
<senior75151> i'm hoping i figure juju out well enough to port our shitty datacenter to ec2 soon :)
<SpamapS> senior75151: simplest thing is to just deploy again and throw that host away
<senior75151> sounds good.
<senior75151> soo on the host that has juju
<senior75151> sudo apt-get update ?
<senior75151> first
<senior75151> or is all dynamic
<senior75151> how to blow away the cache
<senior75151> so it doesn't use the local copy if any
<SpamapS> oh you want the new charm?
<SpamapS> I'm still testing that :)
<senior75151> ok
<senior75151> I'll wait
<senior75151> ok I terminated the instances
<jimbaker> adam_g, i was able to reproduce your error, so i will take a look at what's going on here
<jimbaker> adam_g, feel free to destroy that env
<SpamapS> senior75151: initial test looks good
<SpamapS> ugh, except the part where we have to download 30MB of hadoop package from ppa.launchpad.net ;)
<senior75151> SpamapS: sweetâ¦
<senior75151> haha
 * SpamapS wishes it were in the archive. :-P
<SpamapS> senior75151: let me run a terasort just to be sure it works
<senior75151> sure thing...
 * senior75151 goes to HN for a second while SpamapS's test pass
<SpamapS> yeah just waiting for slave (also needing updates) to deploy
<SpamapS> senior75151: looking better, just running my terasort now
<senior75151> SpamapS: excellent
<dpkingma> Good evening gentlemen
<SpamapS> 12/04/27 20:21:41 INFO mapred.JobClient:  map 24% reduce 0%
<SpamapS> woot
<senior75151> :)
<SpamapS> senior75151: ok, so it will take a bit for that to publish into the charm store.
<senior75151> excellent
<senior75151> how long ?
<SpamapS> senior75151: good question!
<SpamapS> niemeyer: I just made commits to two branches in launchpad. How long would you expect it to take for the charm store to see them?
<SpamapS> senior75151: you can pull them locally if you want
<SpamapS> senior75151: mkdir -p ~/charms/precise && cd ~/charms/precise && charm get hadoop-master && charm get hadoop-slave
<SpamapS> senior75151: then 'juju deploy --repository ~/charms local:hadoop-master'
<SpamapS> senior75151: not nearly as easy or automatic, but .. it gets you the latest crack. :)
<senior75151> ahh k
<senior75151> let me give that a go
<senior75151> thanks soo much
<senior75151> going to try it and let you know
<senior75151> fetching charm
<senior75151> deploying...
<senior75151> SpamapS: state: pending
<senior75151> what does that mean ?
<senior75151> i suppose is still configuring
<senior75151> ?
<senior75151> or smth
<senior75151> or do I have to 'publish' the charm
<senior75151> is not enough to 'deploy'?
<senior75151> soo juju ssh doesn't work
<senior75151> SpamapS: is that what juju expose is ?
<SpamapS> senior75151: instance-state means you are waiting on Amazon
<SpamapS> senior75151: agent-state means you are waiting on your instance to start the agent
<SpamapS> I have seen a few times where agent-state says 'not-started' but it is stuck.. and a 'service juju-machine-agent restart' fixed it
<SpamapS> senior75151: juju expose opens the ports that the charm thinks should be exposed.
<senior75151> ohh ok
<senior75151> so I should defâ¦ do that for hadoop
<senior75151> cool
<senior75151> thanks a lot SpamapS
<senior75151> So I assume is typical to set up a 'dev' or staging environment for a developer then destroy it at the end
<SpamapS> senior75151: saves money that way :)
<senior75151> that's pretty awesome...
<senior75151> soo say I have hadoop, mongodb, mysql, nginxâ¦ etc..  I can build my own script and that basically runs juju deploy X or can you save that config ?
<senior75151> once you have it running
<senior75151> does 'destroy' terminate the machines orâ¦. turns them off ?
<senior75151> ec2 speak
<hazmat> senior75151, terminate
<SpamapS> well
<SpamapS> destroy-environment terminates
<SpamapS> destroy-service only de-allocates
<SpamapS> which, btw, I think we should re-think
<SpamapS> it makes sense if we clean up what we did
<SpamapS> but right now we can't do that, so we should just terminate the machine when we remove-unit and destroy-service
<senior75151> ahh got you
<senior75151> thanks for being such an awesome source of info
<senior75151> :)
<senior75151> SpamapS does your juju ssh
<senior75151> work ?
<mars> Alright!  I have a reviewboard charm up and running.  SpamapS, I used the Drupal charm from the tutorial as a template; can you suggest and example I could look at next to make this new charm cleaner?
<SpamapS> senior75151: not sure I understand what you are asking.
<senior75151> so i do juju ssh hadoop-master/0
<senior75151> doesn't work
<senior75151> then juju ssh 1
<senior75151> doesn't either
<SpamapS> mars: got it in a branch somewhere?
<senior75151> but I do juju status
<senior75151> and it shows is running with correct tcp ports open
<mars> SpamapS, not yet, I'll push it
<SpamapS> senior75151: juju ssh works fine for me with machine number or unit id, yes.
<senior75151> hmm weird.  thanks
<mars> SpamapS, pushed: lp:~mars/charms/precise/reviewboard/trunk
<mars> SpamapS, one thing I would like to figure out is how to unroll running the application setup script after the XXX-relation-changed hooks.
<mars> The Drupal example does the site setup once the DB settings are available
<mars> I copied that pattern, but I have /two/ settings that I need available before running the site setup: db, and memcache
<SpamapS> mars: what I do in that case is just write settings to a file, and then run a shared script that checks for both, and once they are satisfied, runs the setup
<SpamapS> mars: pip installs, btw, are not suitable for charm store inclusion btw. :-/
<SpamapS> mars: they do nothing to cryptographically verify the sources
 * flepied found that juju-create has the gateway ip hardcoded and that was making my setup fail...
<SpamapS> mars: looks good other than that. :)
<SpamapS> mars: ideally with this case, you'd be able to configure the cache/db independent of rb-site
<SpamapS> mars: otherwise it will be hard to do things like migrate to a new database service
<mars> SpamapS, +1 for saving the settings.  That is a good idea.
<mars> SpamapS, as for pip: reviewboard recommends easy_install for installation: pip is better, obviously, but neither does any verification.
 * mars wonders if the .tar.gz on PyPI has an md5
<SpamapS> mars: I would imagine that rb-site just writes to settings_local.py .. so what you really need is to just regenerate that file in total every time relations change
<mars> Yep, that's what I was thinking
<SpamapS> mars: pypi has no SSL
<hazmat> 10 subordinates, SpamapS has like 7 of them
<SpamapS> mars: so you have to do all the MD5's yourself anyway
<mars> Save a copy as a template, then rewrite it, and run rb-site once everything is available
<SpamapS> hazmat: heh.. I have 2 more in the works
<mars> Ah darn, PyPI doesn't have a signature, but reviewboard.org does have sha256 for each release.
<mars> hazmat, out of curiosity, what is the list?  I read the subordinate charm spec, but it doesn't really give a good idea of the types of subordinates I may consider writing
<mars> It's a proposal, not a tutorial or design guide :)
<hazmat> mars its kinda of raw.. but here it is .. http://pastebin.ubuntu.com/950950/
<mars> hazmat, ran it through ipython: http://pastebin.ubuntu.com/950963/
 * hazmat adds a bug for charm browser to view just subordinates
<m_3> SpamapS: we need to remove the hadoop-xxx charms from precise... they're only good for oneiric.  precise is just lp:charms/hadoop
<m_3> which should be pointing to the correct packages... in universe. I think
<m_3> SpamapS: the readme in lp:charms/hadoop is the place to go
<senior75151> m_3: sooo I should be juju deploying to oneric only?
<m_3> senior75151: unfortunately, it's different charm names for oneiric than it is for precise.  They _might_ have made lp:charms/hadoop backwards compatible with oneiric, but I don't know offhand
<m_3> SpamapS: dang, wish I would've caught this before you pushed changes to the lp:charms/hadoop-xxx branches... those need to be deprecated, but I don't know how to do that in lp
<senior75151> ok, good to know.
<senior75151> sooo I'll destroy the thing and use oneric for now.
<senior75151> thanks
<m_3> senior75151: here's the doc: http://bazaar.launchpad.net/~charmers/charms/precise/hadoop/trunk/view/head:/README.rst
<m_3> senior75151: no, actually, I recommend using precise, but using the precise charm
<m_3> i.e., lp:charms/hadoop
<m_3> I'm sorry, I know that's not clear from the list of charms in the store.. we need to figure out how to remove lp:charms aliases from deprecated branches
<SpamapS> m_3: HAH ok yeah those should have been deprecated yes
<SpamapS> m_3: hence the need for 'unpromulgate'
<m_3> SpamapS: they should be just lp:~charmers/charms/oneiric/hadoop-xxx/trunk
<SpamapS> m_3: should just be the reverse of the calls that promulgate makes
<m_3> b/c they're still good for oneiric
<m_3> oh, really?  I was poking around but couldn't figure out how to remove the alias without deleting the branch
<m_3> SpamapS: btw, we still have to fix several of adam_g's branches too... they're hosed
<senior75151> m_3: sooo I did it wrong then, cuz all i did was juju deploy hadoop. Where does one look to know how to install a charm precisely
<SpamapS> m_3: its doable, I just don't know how
<senior75151> like this readme for example
<m_3> senior75151: http://bazaar.launchpad.net/~charmers/charms/precise/hadoop/trunk/view/head:/README.rst covers the latest info for precise
<senior75151> that covers for hadoop
<senior75151> i'm saying in general
<m_3> oh
<senior75151> say I want to deploy mysql and nginx
<senior75151> and mongodb
<senior75151> and ....
<m_3> in general, most of the precise charms are working... and deployable from the store
<senior75151> hmmm well.. great, but how can I know for each one wether it does or doesn't. It's important for production to know if I've done it right
<m_3> senior75151: thought you were just asking about hadoop (and naturally getting confused because of the stale links in the repo)
<senior75151> thanks..
<mars> SpamapS, could you point me to the charm that you used that 'save the relation settings for later' recipe in?
<m_3> senior75151: working on charm tests right now as a matter of fact... it will look something like charmtests.markmims.com when done
<m_3> senior75151: but those are still oneiric... precise should be up this weekend
<senior75151> m_3: thanksâ¦ will they be there  on this same site
<senior75151> orâ¦.
<m_3> senior75151: we'll be testing only the charms in the charm store... so to have them autotested here, you should submit them for review and inclusion in the store
<m_3> charmtests.markmims.com is temporary... we'll roll them up to jenkins.qa.ubuntu.com next week
<senior75151> ahh good to know...
<senior75151> I'm not developing charms, just using them now.. I tihnk I just started using this a couple hrs ago and still confused about somethings
<senior75151> like why ssh doesn't work and that sorta thing
<senior75151> meaning juju ssh
<hazmat> senior75151, i'm confused why it doesn't work for you either
<m_3> senior75151: understand... we're still working on putting the overall "experience" together for new users... with the charm store open, we should be good once all the links have been fixed for the precise charms
<senior75151> does juju run as root
<m_3> senior75151: yeah, juju ssh is one of the parts that usually works pretty well
<senior75151> like I need to add the mongodb-hadoop library
<senior75151> and wondering if I need to install as root
<senior75151> err.. easy to to fix
<senior75151> look at permissions on folder
<hazmat> senior75151, the agents on container run as root, and charms execute as root
<m_3> ah, gotcha
<senior75151> yeah.. dunno.. I assume juju is installed correctly since it deploysâ¦ but juju ssh gives me errors.
<senior75151> is fine cuz I can do debug-hooks
<senior75151> and it works
<m_3> wow, that's strange
<SpamapS> senior75151: can you paste the whole error you see?
<m_3> SpamapS: I see that james built oneiric versions of the hadoop-ubuntu ppas too, so your changes should stay when we revert those packages to lp:~charmers/charms/oneiric/... the charms have never been tested against those packages though, so I'll make a note to do that
<m_3> s/revert those packages/revert those charms/
<senior75151> SpamapS: sure
<senior75151> thing
<senior75151> hold on installing something on the charmâ¦ weird that hadoop depends on java but didn't install java
<senior75151> $ juju ssh hadoop-master/0
<senior75151> usage: juju ssh [-h] [-e ENV] unit_or_machine [command]
<senior75151> juju ssh: error: unrecognized arguments: hadoop-master/0
<SpamapS> m_3: its not reverting.. its porting
<senior75151> SpamapS: that's the error
<senior75151> I tried 0 and 1 as well as haddop-master
<senior75151> with the same error
<senior75151> though I think that 0 is the host pc that has juju as an app running
<senior75151> let me know if you need anything else
<senior75151> ok sooo it says that the instance is running and the ports are open and the machine is started whyen I do juju status
<senior75151> but i sshe'd into the machine
<senior75151> and do a ps aux | grep hadoop
<senior75151> and nothing comes up
<senior75151> sooo it didn't start
<senior75151> that's weird
<senior75151> prolly because lack of the java sdk on the server
<senior75151> any ideas why it didn't install the requirements
<SpamapS> m_3: perhaps until we can remove hadoop-* we should put a big warning in the description?
<m_3> yes, that's a great idea
<m_3> SpamapS: well... now that I think about it
<SpamapS> we should think about ways to express "replaces" like dpkg does
<senior75151> any idea how to restart the service
<senior75151> without reinstalling ?
<SpamapS> like ideally you'd say 'juju upgrade-charm my-hadoop-master' and it would say "this charm has been replaced by 'hadoop', see README for migration instructions"
<m_3> SpamapS: the big reason we were going to keep them for oneiric and the new one for precise is the packages... the precise and oneiric packages were in different ppas
<m_3> SpamapS: but if the new ppa works for both releases, then that simplifies things
<bkerensa> SpamapS: http://www.youtube.com/watch?v=5-SmNPjMcRQ
<senior75151> SpamapS: I can ssh into the machine later and test anything else you need me tooo...
<senior75151> thanks for the support
<senior75151> juju looks great
<senior75151> I'll try oneric see if that works better
<senior75151> I'll drop by here when I get a minute
<senior75151> thanks again
<senior75151> m_3 too
<senior75151> later
 * senior75151 has to rush to dinner 
<SpamapS> m_3: we also can't be removing charms from an existing release :)
<hazmat> have a good weekend folks
<m_3> hazmat: u2
<m_3> SpamapS: understood
<SpamapS> m_3: which one is "right", rabbitmq, or rabbitmq-server ?
<m_3> SpamapS: rabbitmq-server
<SpamapS> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~charmers/charms/precise/rabbitmq-server/precise/".
<m_3> SpamapS: so it's really confusing... we _had_ a lp:charms/rabbitmq-server that pointed to an oneiric branche
<m_3> adam also had a lp:~charmers/charms/precise/rabbitmq-server/trunk
<m_3> as well as several branches stacked on top of the latter
<SpamapS> m_3: so promulgating his branch should have worked.. no?
<m_3> then when we pulled the crank last weekend (previous weekend?  who knows)... we changed the alias to lp:charms/rabbitmq-server and it promoted the oneiric branch over the other
<m_3> so lp:charms/rabbitmq-server has been placed at the base of a stack of branches... it can't be removed unless the branches stacked above it are removed
<SpamapS> m_3: but we never stack on the alias
<m_3> SpamapS: additional complication is that I merged that branch to bring it up to the same version as the previous precise branch... thinking this would be enough to get it working
<SpamapS> m_3: I think we only need to promulgate the one we want as lp:charms/rabbitmq-server .. the others don't matter
<m_3> there're merge proposals and additional branches associated with the _other_ precise branch
<m_3> so we'd be dumping those
<m_3> it's really not that big of a deal here b/c it's adams... he can delete and/or fix things the way he'd like.  We need to make sure we don't do this again
<m_3> so the series promotion needs to do something different when there are existing branches for that charm on that new series
<SpamapS> m_3: I love how Ebay's hadoop is RHEL for the namenodes, but CentOS for the data nodes.. perfect example of how RHEL doesn't scale out :-P
<m_3> SpamapS: $$
<_mup_> juju/debug-relation-hook-context r533 committed by jim.baker@canonical.com
<_mup_> Log actual caching of relation hook contexts
<bkerensa> marcoceppi: welcome
#juju 2012-04-28
<SpamapS> m_3: I think I have an 'unpromulgate' ready
<SpamapS> m_3: and I unpromulgated hadoop-master
<SpamapS> m_3: I'll leave hadoop-slave there for you to test.. btw https://code.launchpad.net/~clint-fewbar/charm-tools/add-unpromulgate/+merge/103965
<koolhead17> morning all
<koolhead17> morning/evening
<imbrandon> SpamapS: still up ?
<SpamapS> imbrandon: up now, sup?
<imbrandon> new charm, first sub , wanted you to eyeball it ( not full review or nuttin )
<imbrandon> mostly the metadat
<imbrandon> a
<SpamapS> Heh, I meant to review your other charms today...
<SpamapS> got bogged down in a bazillion other things
<imbrandon> np i got like 4 half done, i'm like ready to push all 4 if this is good
<imbrandon> cuz they all almost the same
<imbrandon> lol
<imbrandon> SpamapS: should be at lp:~imbrandon/charms/precise/newrelic-php/trunk
<SpamapS> sure just point me there
<imbrandon>  but i tyyped from memory so
<imbrandon> if not its close to that
<imbrandon> very simple charm so far soo not much to checkout, but my first sub
<imbrandon> its actually ready to prom too , as it its complete, some things i'd like to add later but fully functional now
<imbrandon> as in*
<SpamapS> imbrandon: metadata looks fine
<imbrandon> cool, ok thats where i wasent sure
<imbrandon> ok one more q
<SpamapS> no hooks
<SpamapS> config-changed is not executable
<imbrandon> no hookes ?
<imbrandon> oh
<imbrandon> oops
<SpamapS> website needs a hook
<imbrandon> hrm
<imbrandon> it would do nothing
<SpamapS> imbrandon: this is no bueno wget -O - http://download.newrelic.com/548C16BF.gpg | apt-key add -
<SpamapS> imbrandon: you need to embed that file in the charm
<imbrandon> ok can do
<imbrandon> ok fix hooks +x , add gpg file
<imbrandon> now the website hook, if its not gonna do nuttin still need it ?
<SpamapS> wait
<SpamapS> does it actually *need* an HTTP server?
<SpamapS> or does it benefit any php running on the box?
<imbrandon> not really, it needs a php install
<imbrandon> but there isnt really a php interface
<SpamapS> imbrandon: change that to interface: juju-info
<imbrandon> k
<SpamapS> imbrandon: that is an implied 'provides' on all charms
<imbrandon> kk, yea cuz i got other newrelic-* for other programing lang
<imbrandon> that will follow this mold
<imbrandon> and then there is one for just sysmon
<imbrandon> eg no need for anything
<imbrandon> not even prog lang
<imbrandon> that will be newrelic-sysmon
<imbrandon> or maybe just newrelic
<SpamapS> imbrandon: or if you want to make it tighter, you can require interface: php5 and then go around adding a provides: php5 scope:container to all php5 based charms :)
<imbrandon> yea thats was part of the "like to add later " list
<imbrandon> but working now
<SpamapS> imbrandon: and then we'll realize that we should add package info to metadata.yaml and then packages will provide scope container stuff... and then my head will explode with delight ;)
<imbrandon> hehe
<imbrandon> ok so if i change the juju-info no extra hook needed
<SpamapS> right
<imbrandon> ok so in the config-change called on install too right ?
<SpamapS> and you can stick it on pretty much any box
<imbrandon> right
<imbrandon> thats what i wanted
<SpamapS> right, all deploys do install->config-changed->start
<imbrandon> just wasent sure how
<imbrandon> rockin
<imbrandon> ok
<SpamapS> I've found more and more that config-changed is where most of the magic needs to happen
<imbrandon> yea few small changes then this will be ready in just a few minutes
<imbrandon> sweet
<imbrandon> yea me too
<imbrandon> just today i came to that realizatino
<imbrandon> bah
<imbrandon> not awake too many typos
<imbrandon> need caffeine
<SpamapS> yeah seriously you should consider something like redshift so you won't be so insomniac
<SpamapS> bad for your heart
<imbrandon> i slept ALL day today, as in i went to bed at 8am localtime friday morn
<SpamapS> using redshift my sleep hours per day went up from 5 -> 7
<imbrandon> and woke up like 2 hours ago
<imbrandon> yea i need to do something, my sleep is like 3 hours tops
<imbrandon> normally
<imbrandon> like 2 or 3 times in a 24 hr peroid
<imbrandon> but random
<imbrandon> but i think 99% of that is the meds i take but if i dont take them other things are much worse, i hate pills , need to find another way, but been working years on it  ( since about 19yrs old on rittalin ) and not much progress
<imbrandon> i just learn to adapt
<imbrandon> well sorta
<imbrandon> :)
 * imbrandon takes strattera 30mg day ( one dose ) and Adderall ( 60mg day , 2 30mg doses )
<imbrandon> and nothing else
<SpamapS> yeah that stuff will mess with your internal clock for sure
<imbrandon> does what its supse to but really screws with my sleep
<SpamapS> if you haven't given redshift a try tho.. do.. definitely helps signal your brain that its dark outside and you need to sleep
<imbrandon> definatly never heard of it
<imbrandon> but will check it out
<SpamapS> apt-get install gtk-redshift
<imbrandon> kk
<SpamapS> your screen will look funky at night
<imbrandon> kinda like an rsi thing for your whole body ?
<SpamapS> but you'll find that not shining a bright sunlight-colored monitor in your face leads to easier natural sleep
<imbrandon> :)
<imbrandon> dude i soooo want to put those light tubes in my house
<SpamapS> basically shifts the color from "sun" to "campfire"
<imbrandon> well the next place i own
<imbrandon> ahh
<imbrandon> i forget the real name for them but basicly a prism on the roof with a tube into any place(s) you want inside
<SpamapS> yeah thats nice for day light
<imbrandon> then light covers inside the ceiling to disperse so its like a real light
<imbrandon> yea they make them with solar panels too and led's inside for night
<imbrandon> so it works 24/7 too
<imbrandon> and really they are cheap, likeeven initial cost on the prebuilt ones i;ve looked into is like 100$ per room/light
<imbrandon> unless you have a mansion where you would need like 700 yards of tube or something
<imbrandon> heh
<SpamapS> ok well speaking of sleep.. time for me to.
<imbrandon> but hell i already put led light bulbs in all sockets at home
<imbrandon> so thatsd like $25 per bulb
<imbrandon> heh night
<imbrandon> see ya in a few hrs
<imbrandon> err wait its sat
<imbrandon> see ya in a few days
<SpamapS> I want switch LED bulbs
<imbrandon> :)
<imbrandon> dude they rock been using them about a year now for everything
<imbrandon> never look back
<imbrandon> and never had to replace one yet
<SpamapS> specifically the Switch brand
<imbrandon> :)
<SpamapS> http://www.switchlightingco.com/
<imbrandon> 2.w watts per 100watts of "normal bulb" light
<imbrandon> rocks
<imbrandon> 2.5w*
<SpamapS> so supposedly these will last even longer
<imbrandon> yea
<SpamapS> because they use a gel to disperse the light
<imbrandon> the ones i get are like a 17year life
<imbrandon> or something
<SpamapS> and it happens to conduct heat better
<SpamapS> THe Phillips ones are the next best thing
<imbrandon> yea i think thats what i got is phillips
<SpamapS> but these switch bulbs are, IMO, quite sexy. :)
<imbrandon> i get them at microcenter here local
<imbrandon> i think i'm gonna switch my blog to jeykell instead of drupal
<imbrandon> hrm nother proj for weekend
<SpamapS> ok sleep
<SpamapS> enjoy
<imbrandon> http://www.microcenter.com/single_product_results.phtml?product_id=0383924
<imbrandon> those ( diffrent variations they have too for diff situations )
<imbrandon> but basicly the same
<imbrandon> l8tr
<imbrandon> ty for the quick review too
<imbrandon> SpamapS: wow these look awsome ( switch bulbs ) [ goto bed if your not reading this in backscroll ]
<imbrandon> ahhhhh HA ! i figured out why i dont like Unity, SpamapS rember when me and you a week or two ago had the chat about what/why i dont like unity and i said i couldent really name one thing blah blah blah. Also that you noted alot of the "Tech" oriented people you talked to also did not like unity.  Well I just figured out WHY I dont like it, and likely never will, for certain, maybe not but definately not 12.04 , and its possibly the same reason th
<imbrandon> SpamapS: you +1'd the video so i know you seen it ( for context ) but the exact convo part i'm talking about is :14 min in or so, but really has nothing to do with the above, just for refrence incase you want to look at that part again
<imbrandon> ( and maybe its just my ADD too, but still, i know WHY now )
<m_3> SpamapS: thanks, I'll try it out this morning
<imbrandon> heya m_3 , the link on the desc on the charms when imported to github is  the older one, no biggie as it redirects, just making sure you know/now know incase you do wanna update it ( or not )
<m_3> imbrandon: older one?  it should point to precise now
<imbrandon> oh i mean the older domain
<m_3> oh, you mean the url base
<imbrandon> sorry not jujucharms.com
<imbrandon> yea
<imbrandon> :)
<imbrandon> sorry wasent clear
<m_3> gotcha... it's an easy fix (go github api!)
<imbrandon> like i said no biggie, just wanted to be sure you saw it
<imbrandon> :)
<m_3> thanks
<imbrandon> btw whats your importer written in and would you mind sharing ? i was thinking aobut a use ( not at all juju or ubuntu ) related that that would be awesom for
<m_3> it's github.com:mmm/gitpad
<m_3> uses a tool called git-bzr-ng
<imbrandon> really i'd love to just bite the bullet and write a 2 way hg/git mirror scripts
<imbrandon> oh awesom, i use that localy ( all bzr stuff is doing via git on my local machine )
<imbrandon> ty
<m_3> git-bzr-ng can be pretty squirrelly... there are plenty of situations where it will fail, but I've got it set up as a one-way mirror... _not_ sync... that'd be harder
<imbrandon> oh yea , i'm very familiar :)
<imbrandon> like i said i use it so i can "git bzr branch blah" and such
<imbrandon> then use git as normal
<m_3> my github-api-based plugins are in the bin dir of that project
<imbrandon> then git bzr push
<m_3> right
<m_3> imbrandon: yeah, different behavior when others are on the project and you have to pull a bunch... often crashes
<imbrandon> sweet, yea its for some hg<-->gitub stuff anyhow , so i'd likely swap alot of it to hg-git
<m_3> imbrandon: also if I haven't pushed in a while and there're a bunch of commits staged, then it often crashes then too
<imbrandon> ahhh fun
<imbrandon> doesnt it use git / bzr fast export/import internally thou
<imbrandon> that may be another one i'm thinking aobut that i tried when loking for one
<m_3> bzr-fastexport yes... that's been the moving target I think
<m_3> not sure though... it's been a pet-peeve, but not enough for me to dig in and figure out what the problem really is
<imbrandon> one was like a 150 line shell script that just did imports/export on pull/push , rest of the time it was native git
<m_3> I'll just sit back and complain about it :)
<m_3> oh, yeah... I saw that one
<imbrandon> ahhahah right on
<imbrandon> thats the one i'm using
<imbrandon> so i may not be on -ng
<m_3> chose the current git-bzr-ng b/c of the interface... I liked the command
<m_3> s
<imbrandon> ahh
<imbrandon> yea , i think i actually use a diffrent one then, it was not native git or bzr commands but it only matters when i initially clone or push upstream
<m_3> git bzr {clone,init,import,push} all made sense... and work from a lp remote as expected for the most part
<imbrandon> so i choose it because the rest there was less touching from a 3rd party code
<m_3> yup
<imbrandon> i also use hub alot too , infact my git is aliased to hub
<imbrandon> so that had to keep working ;)
<m_3> well I'm interested in a good solution... if the one you use crashes less
<m_3> I can pretty much recover from crashes, but it's still a pain
<imbrandon> well its never crashed on it, but can be very slow on initial checkout or first push
<imbrandon> and i mean VERY
<m_3> right... _fast_ export... <snicker>
<imbrandon> but i dont push it alot either, only for this charms stuff or when pressflow/drupal used launchpad for moving to github
<imbrandon> heh
<imbrandon> not much else i do uses bzr ( read: none )
<imbrandon> :)
<imbrandon> i'll make certain whitch one i'm using and shoot ya a note later today
<m_3> imbrandon: cool thanks
<imbrandon> hey btw if you dont mind i'm gonna add you to the jujutools org on github just for the bus rule if thats cool, not expecting anything but more trustworthy ppl with admin ( me and marcoc*eppi ) are it for now , that also know github a bit , the better imho
<m_3> imbrandon: sure
<imbrandon> kk
<imbrandon> on the other side feel free to update/change too , i'm not saying you _cant_ just that its not an expectation :)
 * imbrandon starts to remove some extra webheads from omgubuntu this morning ...
<imbrandon> man i really wish there was a way to follow a repo and only get the commits/merges in your timeline and not all issue creation & comments
<imbrandon> makes following like twitter bootstrap a mess
<imbrandon> or any larger proj
<imbrandon> but overall i do love me some github :)
 * SpamapS wakes up.. too early
<SpamapS> imbrandon: ok, so, tell me, why don't you like Unity?
<m_3> morning
<imbrandon> SpamapS: heya
<m_3> wow... unity discussions first thing in the morning... dang
<SpamapS> I know
<SpamapS> should not IRC w/o coffee
<imbrandon> SpamapS: i did, because it makes it very hard for me to operate the way i'm used to , e.g when working on webpages i have photoshop open on sscreen as well as 2 ide's chat 2 browsers
<imbrandon> all VISABLE
<imbrandon> not counting others
<imbrandon> etc
<imbrandon> etc
<imbrandon> unity dosent like that workflow
<imbrandon> it wants 1 task 1 app let you concentrate
<SpamapS> imbrandon: eh, but it specifically supports splitting the screen w/ 2 apps
<imbrandon> but yea not impossible
<imbrandon> SpamapS: sure
<imbrandon> but thats one thing
<imbrandon> and gtk3 does too
<imbrandon> ( and osx and windows )
<SpamapS> FTR, I am a full screen type person
<imbrandon> so thats not unity thing
<imbrandon> yea see i'm totaly not i may have litterlyu , lets see i have 7 windows visable right now
<imbrandon> and i dont just mean the corner of one
<SpamapS> usually I just have browser in one fullscreen, and Terminator split 4-6 ways in the other
<imbrandon> i mean resized and positioned
<imbrandon> etc
<imbrandon> right
<imbrandon> imagine if you used every app the way you use cli apps in terminator
<imbrandon> would not be nice in unity, possible, but not nice
<imbrandon> thus me not being able to name it right off
<imbrandon> but made sense when he said it
<imbrandon> me working with alot of visual apps its the same for me as with screen split 4 to 6 ways or terminator
<imbrandon> but one a brower for docs, one for the page working on, one for google, then irc , then ssh ( with lots of tabs/splits ) then photoshop , then an IDE
<imbrandon> that i want to use all at once
<imbrandon> not task swtich
<imbrandon> then when doing something else another "set"
<imbrandon> same with alot of geeks
<imbrandon> thus maybe the same issue
<imbrandon> and yea like i said , this isnt impossible in unity
<imbrandon> just not as easy , thus irritating but not defineable from the getgo
<imbrandon> imho
<imbrandon> and yea i use that split screen at the edge thing contantly in OSX too, infact in osx i can set it to hotkeys so cmd+right arrow is right half , left is left half and then up and down down does quarters if its halved already
<imbrandon> :)\
<imbrandon> anyhow, wth you doing on , on a saturday :)
<imbrandon> lol j/k
<SpamapS> just woke up suddenly
<m_3> and naturally decided to attach to irssi...
<m_3> :)
<imbrandon> :)
<m_3> SpamapS: when's your actual due date?
<m_3> imbrandon: yeah, I pretty much do apps fullscreen... do miss my multiple monitors when I'm on the road though
<SpamapS> m_3: June 5
<m_3> usually use multiple desktops to task switch
<m_3> SpamapS: ah, cool
<imbrandon> see thats just it tho i'm not task switching , well not to me
<imbrandon> just a diffrent tool for another part of the task
<imbrandon> and yea, i lub multi heads
<SpamapS> I attached to irssi and sup.. the never ending stream of email... so ... tired..of..deleting..
<m_3> omg, I'd get nothing done if my tmux session with irssi's wasn't on it's own desktop
<imbrandon> every computer i tuch must have them :)
<imbrandon> lol
<m_3> imbrandon: ha!
<imbrandon> m_3 for realz, i even bought a thunderbolt to 3x dvi adapter for my laptop
<m_3> SpamapS: I've thought of switching over to sup... but the single stream would kill me
<imbrandon> :)
<m_3> I found a way to do a pane of folders along the side of mutt and that works pretty well
<m_3> imbrandon: yeah, having to use unity-2d with nvidia xinerama, but that ends up working pretty nicely
<imbrandon> and when on the road, as in not just going to the officee where i have 2 more monitors setup, but road road, like uds, i have my ipad that has a 1024x768 driver for extra screen over wifi ( slow but useable ) and a 16.5 inch usb driven display that slides in the laptopbag perfect and has a foldout stand when in use
<SpamapS> m_3: the single stream is all that keeps me sane
<imbrandon> :)
<m_3> (still want my command key back to ctrl though)
<imbrandon> heh
<SpamapS> folders mean I get hundreds of messages behind on a topic, and have to just let it go
<m_3> that's hard muscle memory to break... command-c, command-v, etc
<m_3> SpamapS: ha!... well... yes
<m_3> :)
<SpamapS> the single stream.. I at least just know I'm hundreds of messages behind *all* messages
<imbrandon> m_3: tell me about it
<imbrandon> i STILL hit cmd v and wonder why it dident paste
<SpamapS> m_3: I tag by list-id, so I do sometimes just search for a list tag and power through all the messages in that one context
<imbrandon> goto recopy
<imbrandon> and repaste
<SpamapS> m_3: also remember its a stream of threads, not messages
<imbrandon> and THEN figure out it was the wrong key
<imbrandon> lol
<SpamapS> imbrandon: I swap alt and cmd .. makes a lot more sense
<m_3> SpamapS: right, I figured you had some set up to skip inbox... you'd have to segment accounts or verp extensions or something
<SpamapS> imbrandon: but yeah, cmd-v still popped out for a few months :-P
<imbrandon> SpamapS: my thumb can hit cmd easy, not ctl or alt
<SpamapS> m_3: no, it still goes in inbox!
<SpamapS> all goes to inbox
<m_3> wow
<SpamapS> if its not worthy of my 0.5s of review time, it gets unsubscribed
<imbrandon> no way, i get way too much mail for that
<m_3> linkedin groups, google groups, wow
<m_3> oh, I see
<SpamapS> otherwise why do I have it?
<imbrandon> ah
<imbrandon> i use mine as an archive of sorts, but i see your point its not a good one
<imbrandon> better to just not try and use as inteneded and then get used to other tools that are made for job
<m_3> gmail filters were so easy to create... made me promiscuous with groups
<imbrandon> but man, thats a bigger switch than unity, maybe in 16.04 for me :)
<m_3> ha!
<imbrandon> m_3: hahaha yea
<m_3> yeah, agree
<imbrandon> all my mail goes to a google domains accoutn address
<imbrandon> from all addresses i own
<imbrandon> so filters + lables + 25gb == love
<m_3> I do separate quite a bit using verp extensions... mark.mims+craplist@gmail.com
<imbrandon> i really only use that for stuff i know will be automated , like cron email or from a webapp
<imbrandon> etc
<m_3> yup
<m_3> newrelic
<imbrandon> hehe
<SpamapS> I don't really like having static filters
<m_3> things like that :)
<SpamapS> I kill threads rapidly
<SpamapS> but I'd rather read the first message or the subject line and decide for myself
<SpamapS> see, cron email from a webapp == a shitty webapp
<SpamapS> don't cron me crap I don't *need* to know
<SpamapS> log it.. and email me when shit breaks
<imbrandon> see i scan subjest only unless its a thread thats new with 1000 replies then i see if its really good or flaimbait
<m_3> I'm really slow at it... need to spend less time more often, but it usually sucks up time... oooh, shiny thing
<imbrandon> SpamapS: well like i said , i use it like an archive, so i can tell anytime my domain was unreachable from japan in 2009 by seartching email
<imbrandon> not the best way to kkep that info
<imbrandon> but a big switch not to
<SpamapS> yeah I used to do crap like that too
<imbrandon> also stuff that mailman list archives are just as good for etc
<SpamapS> and maybe gmail makes that better
<SpamapS> IMAP was always a huge fail for that
<imbrandon> its too easy to find all in one place
<imbrandon> oh man, gmail search changed my life
<imbrandon> for real
<SpamapS> yeah thats why sup is good
<imbrandon> its what makes keeping every email i ever got ( except blatent spam ) since 1997 , worth it
<imbrandon> and in my active account not archived
<m_3> sometimes, it's almost passive agressive... oh, I _won't_ clean out my spam tags... serves you right for changing privacy policies!!
<imbrandon> heh
<SpamapS> m_3: they just use that as more datapoints.. their hard drive supply is *endless*
<m_3> toyed with gmailfs for a bit, but then thought better of it :)
<SpamapS> they figured out a way to turn every byte stored into more profit
<imbrandon> hehe yea
<m_3> ha!  yes, excellent point
<imbrandon> google drive
<SpamapS> diminishing returns, sure, but they really do have an incentive to give everyone GB's of mail storage for free
<m_3> sure
<SpamapS> imbrandon: btw, did you see the question about the brew install hit the juju ml?
<imbrandon> see i dont care though, i should , but i dont, i like the grey area i know google isnt not evil but i'm not gonna go all RMS on em either, they provide me with real value in their services in exchange for a lil provacy that i'm not unwilling to give up, that dont mean i want it all gone
 * m_3 'll have to find some new way to rage against the machine
<imbrandon> heh
<imbrandon> oh no
 * imbrandon looks now
<imbrandon> ahh yea
<imbrandon> i seen that from some one else
<imbrandon> i'm getting ready to push a new version that clears that and a few other things up
<imbrandon> SpamapS: ^^
<imbrandon> ( was in the github issue queue a few hours ago )
<imbrandon> i really need to fund a way to let some ci tests run on the commits
<imbrandon> not real easy to setup a osx ci server heh, well not cheap anyhow
<SpamapS> imbrandon: an old used mini would do the trick :)
<m_3> there're actually a few different versions floating around still though... not everybody's up on lion
<m_3> does virtualbox run osx on osx hardware?
<m_3> or vmware fusion, I guess
<imbrandon> SpamapS: ahhh good call
<imbrandon> m_3: yea
<SpamapS> m_3: certainly Snow Leopard would be the oldest we care about
<imbrandon> m_3: 10.7 and 10.8 will "legitly" run in fusion
<imbrandon> SpamapS: apple only supports 2 releases, current and one prior, and umm if you dont upgreade your screwed in alot of ways unlike alot of other vendors "unsupported"
<imbrandon> so only 10.7 and 10.8 once release is ok, 10.6 still for now tho
<imbrandon> apples unsupported is actually actively tried to be broken imho, and at very least actively made not to work even if just arbitrarily with other apple services and hardware, like try to use a 10.4 itunes install with your iphone
<imbrandon> heh
<imbrandon> good luck
<imbrandon> but yea i can setup a VM of 10.7 and then install jenkins ( yea it runs great on osx too ) and snapshot it right away
<imbrandon> and revert to that snapshot before every set of tests etc
<m_3> wife from airport... talk to y'all later
<imbrandon> but i was thinking more of a way the public / other contribs could also use it
<SpamapS> imbrandon: I'd be interested in hearing whether or not juju's unit tests pass entirely on os x
<imbrandon> howto run them ? i'll do it now
<imbrandon> or start it now
<SpamapS> ./test
<imbrandon> kk
<imbrandon> any other req that juju its self dont have ? like phpunit
<imbrandon> or something :)
<imbrandon> bholtsclaw@ares:~/Projects/local/juju/misc/juju_0.5+bzr531.orig$ ./test
<imbrandon> Traceback (most recent call last):
<imbrandon>   File "./test", line 5, in <module>
<imbrandon>     from twisted.scripts.trial import run
<imbrandon> ImportError: No module named twisted.scripts.trial
<imbrandon> twisted is the version that came with osx
<SpamapS> imbrandon: interesting
<imbrandon> SpamapS: when using like juju ssh ... or juju blah ... can you tell it what remote user you want to use or login as ? like in a config hopefully and i'm sure said user needs sudo w/ nopasswd access correct ?
<imbrandon> like i want it to use bholtsclaw, not ubuntu , etc
<SpamapS> imbrandon: no
<SpamapS> it always uses ubuntu
<imbrandon> m_3: and yea vbox, vmware, parallels ( no windows version, and the linux version is $$ and closed src so not many know about it ) , and a really old un-supported by ms anymore version of VirtualPC and only upto like OS X 10.4, all run great on osx, with any guest OS you want, win/bsd/darwin/linux EXCEPT OSX, and only due to how it was licensed before, but the license changed with 10.7 and beoynd that allows it to run on virtual hardware legally, a
<SpamapS> imbrandon: any luck running it on kvm?
<SpamapS> I looked into it, and it looks pretty hopeless
<imbrandon> SpamapS: ugh , thats bytes /me contemplates patching juju or doing alot of scripting to rid login as a non existant user name ubuntu and then switch to the real one
<SpamapS>     args.extend(["ubuntu@%s" % ip_address])
<imbrandon> SpamapS: no, but never really tried, i know it will run on kqemu
<imbrandon> but SLOW
<SpamapS> imbrandon: Just needs some argparse love
<imbrandon> sweet
<SpamapS> I kind of want it to work different
<imbrandon> SpamapS: but you need to have kqemu pretend its an intell too
<imbrandon> intel*
<SpamapS> I'd rather have ssh -l spamaps `juju get-unit-info mysql/1 public-address`
<imbrandon> because even with vmware and the others you still cant run osx on amd
<imbrandon> or non intel
<imbrandon> no idea how the hell intel brokered that deal
<imbrandon> but its a killer for them :)
<SpamapS> meh, nobody likes AMD anymore
<SpamapS> I was a huge fan for years
<SpamapS> but Intel seems to be crushing them again
<SpamapS> once they let go of Itanic
<imbrandon> oh and arbitrary too, its been patched out as its only a check and a single check on boot
<imbrandon> but still there none the less
<imbrandon> yea
<imbrandon> i was a huge amd fan while they was good for the cpu vs cost
<imbrandon> but that was gona aroudn the time the c2d came out
<imbrandon> done*
<imbrandon> and not regained
<imbrandon> and not i dont care anymore
<imbrandon> lol
<imbrandon> now*
<imbrandon> core 2 duo 's c2d
<imbrandon> they are still making bank tho , learned a trick from MS and are licensing x86_64 stuff to intel
<imbrandon> as they have all the goodies on that one, but as soon as intel can make a real 64 only platform work like the titanic should ahve been
<imbrandon> then they can drop that but AMD has some extra pocket cash to build new fabs until then :)
<imbrandon> heh i do wonder why debians debs still say amd64 tho and not more generic even tho it really is amd tech
<imbrandon> SpamapS: how much of a pain is it to add more juju * commands that run with the credentials etc , is it as easy as adding git commands and just make a juju-blah wrapper for juju blah .... ?
<imbrandon> i ask cuz i want juju rsync *
<marcoceppi> imbrandon: there's already a juju scp
<imbrandon> but not willing to spend much time on it, as i can just get the info needed and do it otjher ways
<imbrandon> scp is not good for large files that may die mid copy or whole dirs that need to be syncs
<imbrandon> with 1000's files
<SpamapS> imbrandon: so, juju-jitsu (which you should package for OS X btw ;) adds commands if you run 'jitsu wrap-juju'
<SpamapS> imbrandon: but the juju team is concerned about confusing users so they don't like the idea of cli plugins
<SpamapS> imbrandon: you can add as many commands as you want to jitsu :)
<imbrandon> sweet, yea i was gonna package it but i couldent find even a help file or how to use it, i installed it then was like ummmmmmm now what
<imbrandon> lol
<SpamapS> reminds me, I forgot to upload 0.6 to the PPA
<imbrandon> not even sure what exactly it is fully
<imbrandon> but yea charmrunner charm-tools and now juju-jitsu are on the .plan to do real soon now ( hopefully before uds )
<SpamapS> imbrandon: https://launchpad.net/juju-jitsu .. just add-ons that don't belong in juju core
<imbrandon> ahh
<SpamapS> I think we might fold charmrunner into it
<imbrandon> SpamapS: ophhhhhh why does python settings.py install NOT install the bash competition file ? shame
<SpamapS> just to consolidate things
<imbrandon> SpamapS: rockin then i'll hold off on it to last
<imbrandon> charmrunner that is
<SpamapS> imbrandon: because it wouldn't know where to put it?
<SpamapS> kinda like me in 10th grade..
<imbrandon> SpamapS: bash is bash , whatabout the users homedir ?
<imbrandon> even on windows bash looks for things in the same places
<SpamapS> completion has to be sourced
<imbrandon> sure check for a .... ok ok i see wanted to be simple
<imbrandon> and let the packager do it
<imbrandon> np
<imbrandon> i was just mad when it dident
<imbrandon> :)
<SpamapS> OS X probably puts it somewhere different
<imbrandon> nope
<imbrandon> same spot, bash is bash, osx is actually certific unix3
<imbrandon> same fsh
<imbrandon> certified UNIX 3
<imbrandon> bleh
<imbrandon> now bash 4 , thats some sexy, and in brew
<imbrandon> ohhhhhhhh and your gonna fskin kill me for this one
<imbrandon> brew is ported and works good on Linux, thinking about packing it
<imbrandon> :)
<imbrandon> then ppl can compile their own crack
 * imbrandon would hide under a rock
<SpamapS> and I'm out
<imbrandon> l8tr
<imbrandon> marcoceppi: btw i'm working on taking 1 or 2 of the servers offline
<marcoceppi> imbrandon: I'm about to leave for the afternoon: http://www.meetup.com/stackoverflow/DHS-MD/653302/
<imbrandon> and getting an upgrade polished up that encapsulates our recient changes
<imbrandon> okies
<imbrandon> sweet
<imbrandon> but yea just fyi incase
<imbrandon> gonna see if we can get down to 3 without issues
<imbrandon> 1 db and the 2 webhead
<imbrandon> cuz still more traffic than normal but alot less than yesterday
<imbrandon> marcoceppi: have fun, ttyl :) i wont do nothing crazy or that i might need help with since most ppl that could help me are afk today
 * imbrandon puts the cowboy hat away and will stick to nginx configs, php code  or simple juju tasks, and only the latter on OMG :)
<imbrandon> marcoceppi: oh holly crap , i just notices thats a world wide thing
<imbrandon> congrats
<imbrandon> :)
<bobweaver> hello I would like to learn how puppet and juju can be brought together. Like puppet scripts into juju charms ? is that possible ?
<bobweaver> any links would be great thanks for your time.
<nyr0x> hey, i'm running juju on a ubuntu orchestra server (12.04) to deploy a locale environment. is there a way to reintegrate a compute node that has crashed? for example i have only 1 node wich is running a mysql db deployed by juju, now i just shut down the node and reboot via pxe and cobbler reinstall the wohle system. if i now execute 'juju --verbose status', i get 'ERROR SSH forwarding error' 'ZOO_INFO@zookeeper_init@727: Initiating client connection,
<nyr0x> 2012-04-28 21:05:23,287:7295(0x7fe393df3700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:46972] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
<nyr0x> '
<nyr0x> any body knows how to fix this?
<imbrandon> not certain but you could try "juju destroy-environment && juju bootstrap"
<nyr0x> tried it, doesn't help
<imbrandon> dosen't help isnt very useful, and if it dident bootstrap correctly you';d get the status error from above, but if thats the case you most certainly got a diffrent error
<imbrandon> mind sharing that one >
<imbrandon> ?
<imbrandon> afk
<nyr0x> imbrandon: the boot strap is successful, but the error stays the same.
<imbrandon> i'll be back ina few , but that means the ssh pub keys were not copied from the environments.yaml file to the zk server then
<imbrandon> it seem
<imbrandon> gotta run, but yea check that authorized keys is correct in the env.y
<nyr0x> thx
#juju 2012-04-29
<imbrandon> SpamapS: ahhhh i'm an idiot :)
<imbrandon> ( not that that is new )
<imbrandon> re: better apple testing , we dont use any of the gui stuff , brew et.al is cli  , apple cli + kernel == darwin , darwin == opensource w/ iso installers and will work on and VM platform
<imbrandon> in other words i can installed 10.6 10.7 and 10.8 clean environments to match the commercial countarts minus the gui. but i dont care about that infact its good its not in my way
 * imbrandon gets started, then will worry about a place to house the VM's , maybe if it works out well canonical will put them in the DC ( in a DMZ so non employess like me can admin / etc ) cuz iirc even bzr has an official apple package, could be used for lots of cross breed stuff
<imbrandon> plus sounds like a fun challange
 * imbrandon wonders if there is a Debian Mach-O distro, since there was/is a GNU Hurd one , and a Solaris one i wouldent doubt it 
<imbrandon> heh
<imbrandon> halp! heh, how do i get out of this error
<imbrandon> http://paste.ubuntu.com/954360/
 * imbrandon will be glad if marcoceppi is up warly today
<imbrandon> easy*
<tog> hi imbrandon
<imbrandon> hello tog
<imbrandon> give me justa  few here, i got a website burning to the ground with a few thousand visitors
<imbrandon> active atm
<imbrandon> then we'll get ya fixed up
<imbrandon> be done in ~15 or 20 min toops i hope
<tog> ok no pb
<_mup_> juju/debug-relation-hook-context r534 committed by jim.baker@canonical.com
<_mup_> Add missing invoker.start call
<jimbaker> the above commit fixed the issue that adam_g saw, just need to put a test together for this one-line change
<imbrandon> jimbaker: should i snag it into the osx package , or wait for that >
<imbrandon> its at 532 now
<jimbaker> imbrandon, it should not have anything to w/ osx - it's a fix for the unit agent
<imbrandon> ahhh kk
<imbrandon> thats why i was askin
<imbrandon> :)
<imbrandon> if i needed to bother , basicly
<jimbaker> imbrandon, no worries - glad someone is working on the osx client side
<imbrandon> i guess i should lurk on a list if there is one, jimbaker is there any kind of juju release list other than the normal mailing list ?
<imbrandon> jimbaker: heh well i may not be the best at it , but i'm something for now :)
<jimbaker> imbrandon, that's really it - not everything is announced there however. following code seems to be the best approach at this time :)
 * imbrandon will feel much better when the go client is ready, just not that confident in python :)
<imbrandon> jimbaker: rockin, yea i've just been kinda eyeballin the code and my normal hangin in here :)
<imbrandon> sounds good for now, not like there is 5 a week or something
<imbrandon> and if i'm a few hours behind no one gonna notice likely ( although m_*3 ) has access too "just in case" for bus rule
<jimbaker> imbrandon, well i think following the merges into trunk & corresponding bugs doesn't requre too much python knowledge - we do try for a reasonably detailed commit message for example. plus the merge proposals are much more detailed too
<imbrandon> ahhh yea, and i'm not uber terrible, else i wouldent have volenteered :) just a tad outside the comfort zone tho, but thats not always bad
<imbrandon> keeps ya on your toes
<jimbaker> imbrandon, :)
 * imbrandon will stick with the black sheep php for day to day :)
<imbrandon> hrm, thinks i'm gonna find me a nice snack, its stroming here still , good time to sit on the porch and listen to the thunder, its the only time i'm "outdorsey" hahaha
<imbrandon> back in a bit
<imbrandon> *just thinking out loud* Hrm, I wonder if , even as popular as Brew is if it would not be more beneficial both short and long term to whip a little Make/shell build script up that would basicly just be a thin vale with a tiny bit of extra logic for the platform arround setup.py ( to make sure zookeeper is installed bacsicly , other than that setup.py should use the systems easy_install to get the other deps if i'm not mistaken
<imbrandon> )
<imbrandon> and have that in with the offical package
<imbrandon> hrm ... , maybe both? one option for the many that already have brew installed and are comfortable with it, and those who arent simpley download the official juju and run install.sh themselfs
 * imbrandon contemplates it a bit before emailing the list
<adam_g> SpamapS: you around by chance?
<SpamapS> adam_g: I am
<SpamapS> adam_g: just hiding from the Joshua Tree heat in my air conditioned room :)
<adam_g> SpamapS: :)
<adam_g> SpamapS: im at a loCo release party, was gonna demo juju but the mediawiki charms seem broken?
<SpamapS> adam_g: mediawiki has definitely bitrotten a bit
<adam_g> SpamapS: seems to not do antyhing with the database after a relation is added, other than create the juju specific table
<SpamapS> adam_g: phpmyadmin, thinkup, statusnet, all seem ok in precise
<adam_g> SpamapS: wordpress seems a bit wonky too, after adding haproxy
<SpamapS> adam_g: yeah I need to take a look at it, There's a new mediawiki version out too that has a much better cli installer
<SpamapS> adam_g: yeah wordpress is broken because of the Host: header
<SpamapS> adam_g: imbrandon and marco are adressing that in the turbocharged WP charm that they're working on
<adam_g> ok
<SpamapS> adam_g: we def need to sit down and write real tests for the charms to make sure they actually work :)
<SpamapS> meant to have that done by 12.04 release but I suspect it will get done in the next few weeks
<SpamapS> adam_g: also I think we are going to add some new optional values to the HTTP interface so that we can get the Host: handling right on loadbalancers and proxies of various types
<SpamapS> anyway, time for a nap
<imbrandon> SpamapS: yea i figured i was going to do that for mine this week but then the contest came so i wanna fiinish a few more and will likely do the "proper" tests for all of them not just the ones i care about late at uds or just after
<imbrandon> l8tr
<hazmat> is omgubuntu serving media from s3 or cloudfront?
<hazmat> feels like s3
#juju 2013-04-22
<jcastro> aculich: hey I linked up with tim last week
<jcastro> marcoceppi: do you have the juju go PPA handy?
<davecheney> jcastro: ppa:juju/devel
<jcastro> ta
 * davecheney melts into the background
<jcastro> hmm, so I've noticed we haven't written that down anywhere
<davecheney> jcastro: mgz and davey are in charged of putting juju somewhere more official
<jcastro> yeah, I'm writing the drafts for the getting started pages today
<jcastro> so we can flip them over on thursdayish
<marcoceppi> hum, I've been using the wrong PPA
<evilnickveitch> jcastro - i'm doing a getting started as part of the go docs...
<jcastro> evilnickveitch: ok, so what do I do with the page on the website?
<jcastro> do we just remove it when newdocs lands?
<evilnickveitch> jcastro - yes, thats what the thinking was, it should be able to go on Thursday, though the rest of the docs won't be finished
<marcoceppi> jcastro: we could could just update the header link to go to the getting started page of the docs as the doc layout is nearly identical to the website atm
<jcastro> that would be perfect!
<jcastro> evilnickveitch: I think the only thing we should do is add a little snippet for python users.
<jcastro> "Looking for older versions of Juju?" and then send them someplace.
<evilnickveitch> hurrah!
<evilnickveitch> heheh! yes, I can think
<evilnickveitch> that would be a good idea. I will make sure to flag it up - i guess i can just point to the old docs (though that seems cruel)
<evilnickveitch> maybe some sort of intermediary page
<marcoceppi> jcastro: here's an earlier draft of the design, for reference: http://hostmar.co/canonical/go-juju-docs-go/getting-started.html
<jcastro> evilnickveitch: well, if they're on python then i think giving them the old-non-changing docs would be the best bet
<jcastro> at least for thursday
<evilnickveitch> jcastro, agreed.
<jcastro> man dude, that is looking _excellent_ btw
<evilnickveitch> jcastro, thanks! marcoceppi has helped out a lot!
<jcastro> we're preserving URLs right? Like with rewrites and whatnot?
<jcastro> I take it the silence means we're burning the ships? :)
<mgz> I think it means that no one knows who the we-s are in that context
<marcoceppi> Does pyjuju work with raring on cloud providers?
<jcastro> yeah
<jcastro> well, it was for me last week
<marcoceppi> must have just been a bad bootstrap
<jcastro> man guys
<jcastro> just followed the directions
<jcastro> and deployed wp with juju-core with mysql
<jcastro> Just Worked(tm)
<jcastro> this will be awesome
<ahasenack> 2013/04/22 14:38:23 ERROR agent died with no error
<ahasenack> :)
<jcastro> hah!
<jcastro> gary_poster: hey, thanks for that tablet update last week
<gary_poster> jcastro, np! Thanks for bug report.  Sounds like it was a great event
<jcastro> hey so I think the only real problem I noticed is everytime m_3 went to deploy something the twitchiness of the click-to-hold + a touchpad gets a bit wonky
<jcastro> I so want to right click on the box
<m_3> jcastro: sounds about right... was hard to catch a right click without a move involved too
 * m_3 chalks it up to coffee... not nerves ;)
<FunnyLookinHat> Have you guys ever set up a wildcard subdomain redirect scenario for scaling?  I.e. have a single box redirecting / managing requests that need to be handled by specific boxes?  I can go into more detail, but don't want to waste your guys' time.  :)
<jcastro> SpamapS: any objections to the categories: thing in metadata.yaml as policy?
<jcastro> I know you don't like the entire idea. :)
<SpamapS> jcastro: I am adamantly opposed to it.
<SpamapS> its ridiculous and a waste of time. I wish you had brought it up at the summit so I could have lit it on fire :)
<jcastro> ok well, you hate it, but the gui team needs them to make the GUI look nice for 13.04
<jcastro> so, how can I make you at least not care about it? :)
<SpamapS> jcastro: no they don't
<SpamapS> jcastro: use tags. Weight the tags.
<jcastro> I don't think they're doing that
<SpamapS> jcastro: the reason I care about it is that categories are almost always poorly maintained in software
<SpamapS> Its good to categorize flora/fauna, because you don't have whole new categories of flora/fauna every day
<SpamapS> jcastro: go ahead and do it.. and while you're at it, tell yahoo to go back to categories too. :)
<jcastro> ok
<jcastro> well, as long as you don't hate me
<jcastro> I don't like categories either
<jcastro> but it won't matter
<jcastro> people will use google for 95% of the pagehits anyway
<SpamapS> I lurve you all mang
<SpamapS> just think this idea is a time filling "because we can't think of anything interesting to do" waste
<sarnold> which reminds me, is there any plan for the juju equivalent of apt-cache search?
<SpamapS> sarnold: jitsu search
<sarnold> (I haven't really -looked-, but I'd like to know the apt-cache search and apt-cache show equivalents..)
<SpamapS> sarnold: hits jujucharms.com live tho
<sarnold> SpamapS: if it saves me the effort...
<sarnold> nice, .29s :) hehe
<sarnold> thanks SpamapS :)
<marcoceppi> There's charm search as well, but that runs against launchpad
<jcastro> marcoceppi: branch proposed
<jcastro> we need to sort out icons in policy too
<jcastro> marcoceppi: you're putting the svg template thing in charm tools right?
<jcastro> for `charm create`?
<sarnold> marcoceppi: hrm, that didn't find the first one I searched for.. ('charm search powerdns' didn't return the same results that 'jitsu search powerdns' returned..)
<marcoceppi> jcastro: yeah, I'll have a merge for that shortly
<jcastro> we need to merge that into docs too
<jcastro> but I am mulling waiting for newdocs
<jcastro> then just have that be the first submission to that
<marcoceppi> jcastro: or we could just tell evilnickveitch to slide it in as he writes them. Don't want to be too far out of sync. Though I guess that'd be a good first "test" merge
<jcastro> sure
<marcoceppi> jcastro: we should also document the workflow for submitting changes to the docs when newdocs land
<jcastro> http://askubuntu.com/questions/52063/how-do-i-contribute-documentation-to-juju
<jcastro> is what I use
<marcoceppi> ah, perfect
<jcastro> we need to snag the content from the mailing list wrt. that default image id stuff
<evilnickveitch> marcoceppi, jcastro  What am I signed up for now?
<jcastro> actually, doing that now
<marcoceppi> jcastro: it's already listed as depreciated in the docs, just need to update AU and make sure it's removed going forward
<jcastro> evilnickveitch: we need to add the icon stuff to policy, I sent you a mail just now
<jcastro> marcoceppi: on it
<evilnickveitch> okay, cool
<evilnickveitch> I also have a "contributing" page that I have been working on that will be okay to go live at the same time
<evilnickveitch> It details the use of the HTML tags I have made use of, etc
<marcoceppi> cool
<jcastro> perfect
<jcastro> evilnickveitch: hey so what happens to things that you haven't converted yet?
<jcastro> will you just pull in the pages as is?
<jcastro> marcoceppi: hey so bkerensa approved my MP for the docs, lol
<marcoceppi> jcastro: merged
<jcastro> are you not entertained?
<jcastro> what's next!
<evilnickveitch> jcastro: hmmm, we'll wait and see on that. I am planning on having all the user guide stuff ready by Thursday
<jcastro> mgz: which PPA will Juju 2.x live for 13.04?
<jcastro> stable releases I mean, not devel, unless we're reusing ppa:/juju/devel
<jcastro> jamespage: ^^ in case you know
<mgz> jcastro: devel I would think
<mgz> but we can work out if we want a stable-unstable one at the sprint in a few weeks
<mgz> before actually getting 2.0 we don't need it
<jcastro> ack
<ahasenack> hi, does gojuju work with lxc yet? I don't remember
<gary_poster> hey jcastro.  https://juju.ubuntu.com/docs/service-config.html (in "Creating charms") it says that config.yaml supports "str", "int" and "float" as types.  We also see "boolean" and "string" used, and we support them in the GUI.  (1) are there any other types? (2) The haproxy problem you saw was because we treat str values as text lines (no newlines) not text fields (with newlines)
<jcastro> ahasenack: nope
<ahasenack> jcastro: ok, thanks
<jcastro> gary_poster: lots of sections of the docs are out of date
<gary_poster> IOW the diff between <input type="text" and <text
<jcastro> if you want to fix it and submit a mp that would be <3
<gary_poster> <textarea
<gary_poster> jcastro, ack, and would like to.  Right now we are asking in order to fix the ODS bug you filed though
<jcastro> yeah so I have no clue, I usually read the docs heh.
<jcastro> this seems like a hazmat question
<gary_poster> jcastro, lol cool thanks
<smoser> so https://codereview.appspot.com/8648047/ is merged in, right?
<smoser> can i get someone to back that out?
<smoser> i've been told by ubuntu foundations that this will not be a problem.
<hazmat> gary_poster, only supported types are string, int, float, boolean
<gary_poster> ack hazmat thanks, found in go code
<jcastro> gary_poster: ack on having the series in the URL
 * jcastro wonders if putting the version # in there would be better
<gary_poster> jcastro, I think we need both
<gary_poster> but could be wrong :-)
<jcastro> in the url?
<gary_poster> yeah, because isn't precise/wordpress-5 potentially different than raring/wordpress-5?
<jcastro> I was thinking 12.04/wordpress
<jcastro> and so on
<gary_poster> oh
<gary_poster> that might be better for being future-proof...
<gary_poster> though in that vein maybe we should wait for the future to be hardened before we change that stuff
<gary_poster> either way is fine with me
<gary_poster> though less work is better than more work, in isolation from other considerations :-)
<jcastro> I am for whatever gets us through to thursday. :)
<gary_poster> lol +1
<orospakr> hey, I've Stopped all of my EC2 VMs owned by juju except for the boostrap node/zookeeper.  I'd like to ask juju to ensure that every has been started that needs to be.
<orospakr> s/that every/that every VM and service/
<jcastro> so you killed the VMs after you deployed stuff?
<smoser> who here can answer my query above ?
<smoser> can we revert the cloud-init config change at https://codereview.appspot.com/8648047/
<jcastro> smoser: I think core is in #juju-dev
<orospakr> jcastro, I did. note that they are EBS backed and I shut them down cleanly.
<jcastro> ok so you want juju to be able to just fire them back up?
<orospakr> I'm worried that there are plenty of real circumstances that can cause cloud-hosted VMs to reboot, and as such, I'd like to test that.
<orospakr> jcastro, well, that would be nice.  If I fire them back up myself, they get stuck in the agent down state.
<orospakr> or at least, that's how juju status reports them, and the services they are meant to host appear inoperative.
<orospakr> is it possible that I'm asking the wrong questions?
<jcastro> questions seem fine to me
<jcastro> I am just not sure how juju agents handle being shutdown
<jcastro> hazmat: ?
<marcoceppi> jcastro: I would have thought it was added to upstart, but that might not be the case.
<orospakr> my general goal is to be sure that I can bring the entire system back up from virtually cold (assuming the EBS volumes remain intact).
<jcastro> yeah, this might be a better question for the list I think, I think the people who know for sure aren't here right now
<orospakr> alright, I'll start one up manually, and rummage around via ssh to see if everything obvious is running.
<hazmat> orospakr, its not really supported at the moment because the address changes when the instances are started dont ripple through the graph
<hazmat> ie updating relation addresses
<orospakr> hum. okay. so, generally, a restart really should involve a redeploy?
<orospakr> for instances hosting services that are effectively stateless, like application servers, that's not a big deal. for instances hosting more persistent things, like postgres and mongo, I'm keen to have a better story. Is the final answer just automatic backups?
<orospakr> fwiw, I just confirmed that jujud does come up on my instances when I manually restart them.
<orospakr> they remain agent-down, however.
<orospakr> (according to bootstrap node/juju status)
<hazmat> orospakr, final answer atm is not supported, long term instances should re-record their address and propogate to their relations
<orospakr> hazmat, OK. is there a best practice to avoid losing data and bringing platform back up quickly after solar flares happen to, say, knock out EC2 East Zone for a while?
<FunnyLookinHat> Is there any way for me to deploy multiple "instances" of a service to a single VPS? i.e. let's say I have a simple PHP app that manages a to-do list and I want to deploy a copy of it for each user I have on the fly - can that be currently accomplished with Juju ?
<FunnyLookinHat> As far as I can see right now - each "instance" gets it's own VPS
<sarnold> FunnyLookinHat: that's a long-term goal for the golang juju implementation; you can bodge it together using the jitsu 'deploy-to' command, but that isn't exactly a supported mechanism
<FunnyLookinHat> sarnold, Right right - I read up on that... if I were to use deploy-to I'd have to put some fancy into my charms to handle that as well, correct?  Otherwise they'd probably just go ahead and overwrite themselves.
<sarnold> FunnyLookinHat: yes, you'd need to write the charms to be careful; that's probably going to be required of the eventual golang supported solution too
<FunnyLookinHat> sarnold, Ok great - thanks :)
<hazmat> orospakr, atm its manual snapshot and cross region snapshot copy
<hazmat> orospakr, i've been putting together  a suite of aws services exposed as charms.. rds, elb, route53
<hazmat> was just working on an aws-snapshot one
<hazmat> the other ones are @ http://jujucharms.com/search?search_text=aws
<orospakr> hazmat, well, the restoring from snapshots still would seem to suffer from the issue you described before: address changes not properly re-propagating after a restart.
<hazmat> orospakr, yup
<hazmat> orospakr, but the data is around as a sanity check
<hazmat> orospakr, volume management is slated for juju for13.10 at which point hopefully this will get better. i expect we'll have a public roadmap out mid may. all the devs has been working hard to get the new version/rewrite out the door
<orospakr> oh wow, cool.
<orospakr> well, thank you very much. :)
<hazmat> FunnyLookinHat, -force-machine to force non conflicting services to the same machine in go juju.. in pyjuju its available as the jitsu deploy-to add on
<thumper> morning hazmat
<hazmat> thumper, greetings
<b1tbkt> did a 'destroy-environment' and released all nodes from maas (at which point they showed 'Ready). subsequent juju deploy is now just hanging at 'connecting to environment' after four hours.
<b1tbkt> do I need to delete ssh keys somewhere, maybe?
<b1tbkt> nm...system console was waiting for me to see its complaint about pre-existing lvm on its disk
<mwhudson> does juju-go work on arm?
<davecheney> mwhudson: it should
<davecheney> i've tested the client a few times on arm a while back
<davecheney> there are no problems compiling it
<mwhudson> davecheney: ok
<mwhudson> davecheney: https://launchpad.net/~juju/+archive/devel doesn'
<mwhudson> davecheney: https://launchpad.net/~juju/+archive/devel doesn't appear to have arm builds
<davecheney> mwhudson: it will for the next build
<davecheney> it wasn't a priority before
<mwhudson> cool
<mwhudson> thanks
<davecheney> if you are running armhf you can build from source
<mwhudson> yeah
<davecheney> if you are running raring, you might even be able to run all the unit tests
<mwhudson> i might just wait 24 hours :)
<davecheney> mwhudson: probably a better move :)
#juju 2013-04-23
<m_3> marcoceppi: setting up that control env now
<m_3> should be done for your morning
 * m_3 making fun of one of your keys though... "Windows"... harumph
<m_3> :)
<imbrandon> m_3: heya, sooo check this out , been working on / tweaking a theme for a new site I've been tinkering with launching a week or so â¦ themes only about 80% done or so, but thats not the cool part â¦ check out this hack ( note the comment system ) http://www.cloudhero.net/hello-world ( most of the content is just dummy content while I work on the theme )
<imbrandon> its got the G+ commenting system thats only been released for blogger, and only a day or so there even â¦ and that is a self hosted wordpress.org install on RAX using it :P
 * imbrandon is happy with himself, so much so infact he is making it into a WP plugin for others.
<m_3> imbrandon: oh, nice
<m_3> imbrandon: yeah, that looks great
<m_3> add the plugin to the wp charm too!  :)
<imbrandon> :) ty still rough edges but its almost there
<imbrandon> m_3: for sure :)
<m_3> like the theme in general too...not just the comments bit
<m_3> nice and clean
<imbrandon> thanks :)
<imbrandon> its the first one i've done from scratch in a long time
<marcoceppi> m_3: sounds good, how will I know the address?
<imbrandon> well its still bootstrap based, but barely
<m_3> marcoceppi: still in progress :)... I'll send you the node once I have it bounced
<m_3> marcoceppi: I'm adding the env config so you can pull that from the node once it's there
<marcoceppi> m_3: awesome, I'm curious to see if this works properly now so I'll check back after the gym
<m_3> marcoceppi: that way you can control it too... and your keys get injected into everything (tpaas) in that env
<m_3> marcoceppi: ack
<marcoceppi> m_3: \o/
<imbrandon> m_3: here is alot of the elements you dont see on the page as well, developing it as a full theme â¦ http://www.cloudhero.net/misc/styleguide.html
<imbrandon> about half of the form elements are still funky ( select, combo box, checkbox[alignment] ) and still adjusting the colors a bit â¦ but yea i'm happy with it over all too, tis something fresh to work on that dosent seem like a cheap copy of something else :)
<m_3> imbrandon: ack
<evilnickveitch> what causes  "error: cannot log in to admin database: auth fails" ?
<smgz> mattyw: ^did you get an answer to that error when you ran into it?
<smgz> (looking at https://lists.ubuntu.com/archives/juju/2013-April/002301.html attachment)
<smgz> evilnickveitch: possibly trying to deploy before stuff is ready, what were the steps you took to get that error?
<evilnickveitch> hmmm. well, just recently - "juju bootstrap" followed by "juju status". so...
<mattyw> smgz, sorry - just in a call
<smgz> presumably just the current breakage then, not sure which of them caused that
<smgz> could be the upstart/cloudinit one or something else
<evilnickveitch> smgz ok, was just curious :)
<smgz> are you running from the devel ppa, and have you updated recently? the package from yesterday should be okay
<smgz> ...then the issue is the tools in the bucket aren't updated yet...
<evilnickveitch> smgz - ah, where should i be getting it from, just to make sure
<smgz> https://launchpad.net/~juju/+archive/devel
<mattyw> smgz, I seem to remember that I was trying to do juju status too quickly
<evilnickveitch> yeah, that's the one i have. I will make sure it is up to date
<smgz> only built latest at the end of yesterday
<rogpeppe1> evilnickveitch: you will get that error if the bootstrap instance has failed to bootstrap successfully
<rogpeppe1> evilnickveitch: can you try ssh'ing to that instance (you can't use juju ssh for that though) and looking at the contents of /var/log/cloud-init-output.log
<evilnickveitch> rogpeppe1,  thanks. Some more investigating to do.
<smgz> rogpeppe1: you should really make that error less lame
<rogpeppe1> evilnickveitch: yeah. i think we should probably change that error message
<smgz> where you=we
<rogpeppe1> smgz: snap
<rogpeppe1> smgz: it's bad because clients connect directly to mongo
<rogpeppe1> smgz: in the near future, command line clients will connect to the API
<rogpeppe1> smgz: so you won't get that error - you'll just get endless "connection refused" messages, which is arguably better, i suppose
<rogpeppe1> evilnickveitch: the "auth refused" error means that the bootstrap instance got as far as starting mongo at least.
<smgz> well, no, but I need to persuade you guys that bootstrap should be console-log aware still
<rogpeppe1> smgz: yeah, i agree, but it's awkward to do
<rogpeppe1> smgz: the command line tools can't know when the environment is bootstrapping vs when it's genuinely unavailable
<smgz> they can, for several common classes of problems
<smgz> if you don't get to cloud-init's happy message, you know something has gone wrong
<rogpeppe1> smgz: i suppose juju bootstrap itself could know; perhaps juju bootstrap --debug --wait could wait until the instance comes up, ssh to it and tail -f cloud-init-output.log
<smgz> right, and then make --no-wait --quiet the non-default passable flags :)
<rogpeppe1> smgz: juju status on the other hand has no idea if it's waiting for the environment to bootstrap
<smgz> you don't need to ssh to get the log
<rogpeppe1> smgz: no?
<smgz> you just call into the nova api (on openstack at least, ec2 has the 4 minute delay thing or whatever)
<rogpeppe1> smgz: to get any log file on the system?
<smgz> no, to get the log you care about (dmesg + cloudinit redirection)
<rogpeppe1> smgz: the one that i find all the useful info in is cloud-init-output.log, which i don't think is the one you're talking about there.
<smgz> there's this nice little line in our cloud config, that goes like this:
<smgz> output: {all: '| tee -a /var/log/cloud-init-output.log'}
<rogpeppe1> smgz: do you think we should change that?
<smgz> or, in the go code, environs/cloudinit/cloudinit.go line 183:
<smgz> c.SetOutput(cloudinit.OutAll, "| tee -a /var/log/cloud-init-output.log", "")
<rogpeppe1> smgz: or does the output also end up in the other log. i'm afraid i am shamefully ignorant of the cloudinit detais
<rogpeppe1> details
<smgz> right, what you see in cloud-init-output.log also appears in the console log.
<rogpeppe1> smgz: ah, ok
<rogpeppe1> smgz: i wonder if it might be nicer to have a bootstrap-log command. that way even if i bootstrap silently, i can later inspect what went on in the bootstrap process
<smgz> nicer than having bootstrap just working? no. in addition, perhaps.
<rogpeppe1> smgz: i'm not sure what you mean by "just working" there.
<smgz> erroring when there's an error, with a clear message, returning 0 when it succeeds.
<rogpeppe1> smgz: i'm not sure i want the bootstrap command to wait for minutes by default
<smgz> we'll have this argument in a few weeks :)
<rogpeppe1> smgz: i think i'm on niemeyer's side on this on
<rogpeppe1> this one
<rogpeppe1> smgz: if the bootstrap process was more reliable, i'm not sure we'd be as concerned about this. there are definitely some places where a retry loop could help things (for instance the metadata service can fail transiently in ec2)
<orospakr> say I want to fork a charm (because I want to add an interface to it or something) after I've deployed it.  can I switch the charm or is a redeploy necessary?
<marcoceppi> orospakr: not really. There's a bug about not being able to upgrade a charm from the store using a local repo
<orospakr> oh wow, yeah, that's the feature I'd want. well, so long as there's already a ticket filed. :)
<marcoceppi> So if you've always deployed it from your local repo you can use juju upgrade-charm to update the charm to the newer version, but if you deploy from store then try to upgrade from local - no go
<orospakr> alright, here's a fun question: what is Canonical's business model for this project? consulting?
<marcoceppi> orospakr: https://bugs.launchpad.net/juju/+bug/1040210
<_mup_> Bug #1040210: can't upgrade a store-deployed service from a local repo <upgrade-charm> <juju:Confirmed> <juju-core:Triaged> <https://launchpad.net/bugs/1040210>
<ahasenack> hi, there seems to be a packaging problem in pyjuju in raring
<ahasenack> zookeeper is "suggested", as is apt-cacher-ng
<ahasenack> but lxc deployments won't work without it
<ahasenack> is that expected?
<orospakr> hm, where is the reference documentation of all the fields permissible in charm metadata?
<smgz_> ahasenack: yes. you can use juju without the lxc provider, why should those people have to install zookeeper locally?
<ahasenack> smgz: ok, makes sense
<orospakr> ah, probably https://juju.ubuntu.com/docs/charm.html
<orospakr> what's the best way to automate charm upgrades? the goal here is some form of continuous deployment. :)
<SpamapS> orospakr: bump 'revision', 'juju upgrade-charm service-name' , the upgrade charm hook will run on all units in parallel
<orospakr> SpamapS, okay. I figured that would be the approach. thank you. :)
<jcastro> m_3: do you have that text file from your charm school section? the one where you had an agenda, etc.
<jcastro> or did you just generate that on the fly?
<jcastro> marcoceppi: 1 week warning on LISA13 submission deadline
<marcoceppi> jcastro: thanks, I've got a draft I'll send over to you if you don't mind giving it a once over
<jcastro> fo sho
<jcastro> m_3: Strata deadline is 5/16
<m_3> jcastro: one sec
<jcastro> hey marcoceppi
<marcoceppi> jcastro: yo
<jcastro> we need to do a virtual charm school for 2.0ish
<marcoceppi> cool
<jcastro> how does next Friday float for you? I'm thinking G+
<marcoceppi> jcastro: that sounds fine to me
<jcastro> ok I'll schedule something
<jcastro> ok everyone
<jcastro> I've redone the messaging around 2.0 timeline
<jcastro> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoW1nhI7IMt3dGc1dmN6YUpxVXBidlYyX3VNOXNYclE#gid=0
<jcastro> this gives us goals as to what to talk about based on when things land in 2.0
<jcastro> and we have "general advocacy" on top of that
<jcastro> so if like, a milestone slips in core we can do other stuff
<m_3> jcastro: that was one-off... I can reproduce it if you want
<m_3> jcastro: usually just make notes for myself before each talk... based on the anticipated audience
<jcastro> m_3: yeah so what I'm going to do
<jcastro> is break up a charm school into "15 minute" chunks
<jcastro> and then write them all down
<m_3> smart
<jcastro> so we can assemble them like legos
<jcastro> so like "this is not a toy example" is one
<m_3> I can reproduce my general notes
<m_3> maybe next week
<m_3> yeah
<m_3> convert them to video segments
<m_3> :)
<m_3> relation sequencing
<m_3> managing service lifecycle
<m_3> adding and removing relations
<m_3> anatomy of a charm
<m_3> service config
<m_3> I like a "juju basics" right up front... "the point"
<jcastro> right
<m_3> then charms, then advanced juju
<jcastro> right
<imbrandon> sounds like what http://lullabot.com does with http://drupalize.me  â¦ its a huge hit
<imbrandon> most vids are like 10 to 12 min but then they combine for an overall topic of about 1.5 to 2 hours total
<imbrandon> jcastro / m_3 / marcoceppi ^^
<imbrandon> http://drupalize.me/videos/overview-drupal-theming  <-- like that one on D7 theming is 7 min
<m_3> imbrandon: yup... exactly
<m_3> trick imo is to keep each vid to a single topic
<m_3> one problem at a time
<m_3> then it's easier to tag/search for what you want
<m_3> and link from askubuntu and jujudocs
<imbrandon> less seeking in the vid too trying to get to "the good part" whatever that is at the moment
<imbrandon> the actual drupal "distribution" ( read: drush makefile ) that lullabot uses for drupalize.me storage and playback interface is opensource / well maintained too , should you all decide u wanted to use it â¦ i'm sure something less complex to begin with tho
<imbrandon> even just a wiki with youtube links is a start
 * imbrandon heads back to lurking mode and off to do some more work/tweaking on cloudhero 
<robbiew> jcastro: m_3: http://www.openstack.org/summit/portland-2013/session-videos/presentation/juju-with-openstack-workshop
<robbiew> :)
<jcastro> Thanks! I was wondering when that was going to come up
<jcastro> will share right after this call
<m_3> robbiew: thanks
 * m_3 watching now
<jcastro> http://www.youtube.com/watch?v=YenD4oxfEa4
<jcastro> is anybody else getting a "your browser doesn't recognize the video format blah blah" on this page?
<marcoceppi> jcastro: nope, it works fine here
<jcastro> man, I do say "Ummmm" too often in charm schools
<robbiew> works good for me
<jcastro> ok posted to the world
<jcastro> 43 views so far
<marcoceppi> I'm ~45 mins in, great job so far
<jcastro> I am glad I switched to the gray ubuntu shirt
<jcastro> instead of those white snowball polos they had
<robbiew> lol
<scuttlemonkey> jcastro: ++
<mwhudson> jcastro: i get the format blah message in firefox
<jcastro> mwhudson: do you have flash installed?
<mwhudson> yes, but i think i have the "html5 trial" or whatever enabled
<mwhudson> there is a link to youtube.com/html5 where the video should be
<scuttlemonkey> jcastro: I haven't played w/ juju much on an openstack setup...how is it for deployment there on grizzly/havana stuff shaping up?
<scuttlemonkey> all my juju testing has been on ec2
<jcastro> scuttlemonkey: you should be good to go
<jcastro> the openstack provider doesn't do constraints yet I don't think
<scuttlemonkey> cool
<scuttlemonkey> ah
<jcastro> but they'll be doing like biweekly releases of core now
<scuttlemonkey> nice
<jcastro> and the nice thing is juju is upgradable now
<jcastro> so you can wait for what you need, then upgrade
<scuttlemonkey> yeah, my plan is to move my entire test rig over to DreamCompute
<jcastro> without tearing it all down
<scuttlemonkey> since I'm on the hook for an in-ceph-tion-y talk about deploying ceph on ceph there
<scuttlemonkey> that's great news
<jcastro> yeah so the idea is
<jcastro> if you want a core feature faster
<jcastro> whine more
<scuttlemonkey> while it isn't hard to destroy environment on a test rig...the ability to have many other things running live will be happy-making
<scuttlemonkey> hahaha
<jcastro> we're almost to feature parity so sooon we'll be moving forward instead of trying to reach the line of scrimmage again
<scuttlemonkey> well in that case I will be the squeakiest wheel that ever squeakied :)
<scuttlemonkey> but first I need a platform...so I'll go squeaky at Dreamhost first
<jcastro> yeah I am waiting for Rackspace's cloud to be fixed so we can run on there
<jcastro> but they posted how they plan on getting closer to trunk or whatever, so the openstack provider should Just Work there soon
<scuttlemonkey> awesome
<scuttlemonkey> aight, time to go hunt down some dinner.  Great vid
<jcastro> ta
<jcastro> I'll ping you later, I should get a list of things you want from you
<jcastro> and then we can bug mramm together
<sander_> Is there a video tutorial I should watch to learn how to write charms?
#juju 2013-04-24
<orospakr> hey, can I ask juju to shrink the number of machines if they are not being used as any service units?
<orospakr> or do I just have to manually use destroy-machine?
<sidnei> orospakr: you have to do it manually
<orospakr> fair enough.
<orospakr> tx. :)
<marcoceppi> orospakr: terminate-machine for reference :) Juju will try to make sure it saves your data as best as possible!
<orospakr> iirc terminate-machine and destroy-machine are aliases?
<sidnei> stub: https://bugs.launchpad.net/charms/+source/postgresql/+bug/1172086 when you get around
<_mup_> Bug #1172086: Database creation fails with syntax error <postgresql (Juju Charms Collection):New> <https://launchpad.net/bugs/1172086>
<stub> Indentation wars are starting
<sidnei> he
<sidnei> some of it i could have left alone but flake8 is really picky
<sidnei> i see that in create_user it uses  action.append('"{}"'.format(user))
<sidnei> but maybe the right way to do it is to sanitize the database name like the username is sanitized
<sidnei> stub: any suggestion?
<stub> sidnei: just added comments
<stub> sidnei: I've linked code to do the quoting correctly. Sanitizing is good too, because if we create things like databases or roles with names requiring the quotes it causes headaches
<sidnei> great, thanks!
<stub> Because nobody ever remembers to add the quotes, and you are left scratching your head because the tablename is in mixed case and without the quotes it gets munged by the SQL parser
<stub> CREATE TABLE "Foo" (a text); SELECT * FROM Foo; -- Fail
<stub> sidnei: I'm torn. I'd normally recommend sanitizing the database name to avoid the quoting foot gun. Even if you write good code that always quotes the identifiers correctly, not every tool you might want to use is good code.
<stub> sidnei: But that creates namespace issues, and annoys people who want to shoot themselves in the foot.
<sidnei> in the specific case (-joined hook) where the database name comes from the service name, i believe it makes sense to sanitize
<sidnei> not sure if it should be also sanitized in the -changed hook for consistency or left alone for the shoot-themselves-in-the-foot crowd
<sidnei> also, can't decide if im annoyed that "SELECT datname FROM pg_database WHERE datname = %s" doesn't complain about the single quote
<mwhudson> sidnei: you do know the difference between single and double quotes in sql, right?
<sidnei> is it the same difference as in shell scripts? *wink*
<mwhudson> no :)
<mwhudson> single quotes are string literals
<mwhudson> double quotes are for identifiers
<sidnei> the distinction is a bit blurry, i guess. but it makes more sense now.
<sidnei> stub: in the create role, does the password need to be quoted too?
<stub> sidnei: The password is not an SQL identifier, just a string, so needs standard single quoting
<stub> sidnei: yay SQL standards committee
<sidnei> stub: http://paste.ubuntu.com/5597272/
<stub> I'm sure there is a reason. Maybe parser implementation. Maybe LSD.
<stub> sidnei: that looks fine
<stub> I should submit quote_identifier to psycopg2 to add as an extension
<sidnei> progress. and fail. and progress and fail. http://paste.ubuntu.com/5597289/
<stub> yay. guess the publication of the names needs to be moved then.
<stub> Or dump AsIs and do the interpolation yourself, safe with quote_identifier.
<sidnei> stub: is that related to the error above? if so im confused ;)
<stub> There is so much of this sort of cruft... branches get scope creep.
<stub> sidnei: Yes. I suspect you will find we are now calling 'relation-set user="foo"' instead of 'relation-set user=foo'
<stub> Assuming it was working before this change ;)
<sidnei> stub: nope, im using quote_identifier inside create_user(), so it doesn't leak the quoting outside to db_relation_joined_changed which is what calls relation-set
<stub> mmm...
<sidnei> stub: the error here is that relation-get didn't return a user for a relation
<stub> There might be race conditions in the hook logic still
<sidnei> maybe because it wasn't flushed yet, or something
<stub> one end trying to get the username before the remote end set it. Needs a guard.
<sidnei> something like that yes
<stub> My functional tests are on hold until I'm back from leave.
<sidnei> but also, we just created the user above, why not pass it to generate_postgresql_hba directly instead of getting it from relation-get?
<stub> sidnei: Probably no reason at all
<stub> sidnei: except I've been trying to limit my diff sizes - too tempting to just rewrite the whole thing in one hit.
<sidnei> i'll hack it until it works (tm) then let's see about splitting this diff
<stub> sidnei: I've been promising myself to just make minimal changes until I've got some sort of test harness
<stub> http://bazaar.launchpad.net/~stub/charms/precise/postgresql/tests/view/head:/test.py
<sidnei> stub: ah, nice. i'll see about adding some unit-y tests instead.
<mwhudson> hm
<mwhudson> juju bootstrap (pointed at a maas install) fails with "error: no tools available"
<mwhudson> any ideas?
<sidnei> mwhudson: being really nosy, i saw mention of using --upload-tools to fix that
<sidnei> no idea if it actually fixes the problem
<mwhudson> hm
<mwhudson> sidnei: thanks, that just gets me stuff like
<mwhudson> 2013/04/24 04:18:39 ERROR command failed: build command "go" failed: exit status 1; can't load package: package launchpad.net/juju-core/cmd/jujud: import "launchpad.net/juju-core/cmd/jujud": cannot find package
<mwhudson> do i need to go install a bunch of things?
<mwhudson> or whatever the command is
<sidnei> sorry, haven't got to that part yet.
<mwhudson> "Ahh, yes, --upload-tools is a developer flag, it won't work unless you have built juju from source."
<mwhudson> i guess i'm going to give up on this until some more devs are around
<AskUbuntu> juju with openstack on precise | http://askubuntu.com/q/284846
<marcoceppi> jcastro: the first of the gojuju related problems are coming in to AU now
<jcastro> excellent. :)
<orospakr> how do I ask juju debug-log to give me more lines of tail?
<orospakr> (I'm running -core, if that matters)
<jcastro> hey mgz
<mgz> hey jcastro
<jcastro> hey so for the packages
<jcastro> can you explain how that will work?
<jcastro> like, apt-get install juju does both python and go with an alternative or what?
<mgz> apt-get install juju will install python juju
<mgz> but, you can install juju-core, and that also provides the juju binaries and so on
<mgz> so, if you just install that, go juju is what you get when you run juju
<mgz> install both and you can pick which you want under the juju name with alternatives, or run under the juju-0.7 and juju-core names
<jamespage> mgz, gah :
<jamespage> src/launchpad.net$ find . -size +1000
<jamespage> ./juju-core/cmd/juju/juju
<jamespage> 9.8MB
<jamespage> ooops
<mgz> this is.. not unusual
<mgz> yeah, it's painful
<mgz> but at least it's only *one* 10MB binary rather than three these days
<jamespage> mgz, yep - can we get that cut from the tar.gz please
<mgz> wait, the binary is *in* the tar?
<mgz> gah
<mgz> okay, I'll start from scratch on that, also omitting the junk we don't need
<mgz> but could really do with some confirmation on exactly what we're trying to ship from someone else
<mgz> fwereade: we don't need lbox for juju-core, right?
<fwereade> mgz, we shouldn't no
<jamespage> great - that solves one problem!
<mgz> we do need, from code.google.com/p/go.net and mgo from labix.org
<mgz> then of...
<mgz> go/src/launchpad.net/:
<mgz> gnuflag  gocheck   gomaasapi  goyaml	 lbox  tomb
<mgz> goamz	 goetveld  goose      juju-core  lpad
<mgz> we want everything but lpad and lbox?
<mgz> ...and not goetveld
<marcoceppi> I've got some jitsu questions
<marcoceppi> Can jitsu watch for a machine-state in addition to agent-state?
<jcastro> mgz: seen this before? http://askubuntu.com/questions/284846/juju-doesnt-bootstrap-due-to-error-command-failed-no-tools-available-error
<m_3> marcoceppi: don't remember, but `jitsu watch -h` is pretty verbose
<marcoceppi> m_3: yeah, doesn't appear so
<fwereade> jcastro, that indicates that we need to upload the new tools to the juju-dist bucket
<fwereade> mgz, AIUI you have the keys necessary to do so?
<jcastro> fwereade: ok
<ahasenack> jcastro: that was happening to me too a few times this week, they said it was "broken on purpose until the right fix lands"
<fwereade> mgz, pretty sure that's correct -- if you want to be really really sure move your src out of the way and go get juju-core into a fresh src/ again ;)
<jcastro> ahasenack: so if we redeploy over and over will it eventually work?
<jcastro> also does anyone have a bug report handy?
<mgz> I do, when we have something built (I could upload from the ppa for now... but would prefer not to)
<fwereade> mgz, ah, what's the problem with the ppa?
<fwereade> mgz, just not the same in actuality even if it is in theory?
<jcastro> this guy would be using juju from the PPA no?
<ahasenack> jcastro: I don't know, I haven't tried today
<mgz> fwereade: no problem, just doing the stuff we need for the archive has to happen like, now
<fwereade> mgz, ah, ok: yes, I agree that it takes precedence
<jcastro> fwereade: ok so I can just tell the guy to sit tight for a bit until we sort ourselves?
<fwereade> jcastro, I'm afraid that's the best we can do right now
<jcastro> no worries, I prefer to tell people to wait than be silent, heh.
<jcastro> man, I wasn't expecting people to be playing with juju on openstack so soon after ODS.
<jcastro> arosales: ok so there's no way to record a meeting from the G+ URL in the calendar invite
<jcastro> so I am going to try launching the hangout early and updating the link on the invitation
<jcastro> if that ends up not working I'll ask you to send everyone from the hangout to the new URL so we can record the charm meeting
<arosales> jcastro, I looked at this last week.
<arosales> jcastro, what the person launching the G+ has to "check box" hangout on air
<arosales> jcastro, from I can see that can't be done via google cal invite
<arosales> jcastro, what you can do is fire up a indiv hangout, check box on air, and then capture the embedded link
<arosales> jcastro, only question if that persists week to week
<jcastro> right
<jcastro> I think what I will do is fire it up early, and see if I can replace the existing link in the invite with the new one
<jcastro> so people get the updated URL in the invite
<marcoceppi> jcastro: I wonder if you can find a URL variable that you can overload the hangout link to force it to be on-air
<arosales> jcastro, sounds good lets see if it works.  I am sure it will work this week, I am just not sure if it will persist week-to-week. But good experiment to find out.
<jcastro> nod
<jcastro> OK everyone
<jcastro> here's the hangout URL for the charm call in 10 minutes:
<jcastro> https://plus.google.com/hangouts/_/ca6e8841c9aed5e51daf941607b9613f93bd0261?authuser=0&hl=en
<jamespage> jcastro, charmers hangout?
<jcastro> weekly call
<jcastro> we're just recording them now so we can make them public, etc.
<marcoceppi> jcastro: may be a few mins late. About to reboot
<jcastro> no worries
<m_3> arosales: how do you get that banner on the bottom
<m_3> it's perdy
<marcoceppi> m_3: "hangout tools" on the left
<arosales> m_3, add the hangout tool box
<arosales> m_3, http://pad.ubuntu.com/Q01gbDLLfh
<arosales> m_3, ubuntu orange is able.virginmedia.com) has joined #juju
<arosales> * eschnou has quit (Quit: Leaving)
<arosales> wrong paste
<arosales> dd4814 is the ubuntu orange
<arosales> m_3, http://newraycom.com/how-to-set-up-google-hangout-lower-third/
<m_3> arosales: thanks
<arosales> sorry about my clipboard buffer being defunc
<jcastro> aha
<jcastro> arosales: for next time I'll add a pad.u.c to the invite, so we don't split brain again
<arosales> jcastro, ok thanks. Sorry for not thinking of that earlier
<jcastro> it's ok, first one's always rough
<jcastro> or second
<jcastro> or third. :)
<marcoceppi> jcastro: FYI for the notes: https://jenkins.qa.ubuntu.com/view/Precise/view/Precise%20Charms/
<jcastro> got it!
<marcoceppi> it takes about 3 years to load, but it has all the tests so far
<m_3> marcoceppi: we might need to get james or somebody to create other/better views in there
<marcoceppi> m_3: yeah, there is a Charms view, but it doesn't have openstack
<m_3> marcoceppi: those're custom views... created by somebody with auth into j.q.u.c
 * m_3 doesn't know how to do it
<imsplitbit> I wonder if anyone here has experience connecting juju with rackspace cloud
<imsplitbit> https://juju.ubuntu.com/get-started/rackspace/
<imsplitbit> if you look there it says "heres an example configuration..." but theres no example :-)
<imsplitbit> I tried using the openstack_s3 provider as some google searches said to do but it fails because the api returns a 404 for os-security-groups
<imsplitbit> not sure if thats a bug or if there's some special things you need to do with rackspace to make it all go
<marcoceppi> imsplitbit: rackspace provider does not work as they have a non standard open stack. they're changing this soon which will fox this problem in juju
<marcoceppi> not sure an eta... jcastro ?
<rshade98> I keep getting no matching tools on amazon.
<rshade98> Is there a package I need to upload to s3
<jcastro> they said "soon" and wouldn't really commit to anything
<marcoceppi> rshade98: see this: http://askubuntu.com/q/284846/41
<rshade98> oh, haha, sorry for the ask guys, I saw this, just didn't realize it was 5 hours ago
<marcoceppi> rshade98: NP, still a bit of a new issue :)
<jcastro> rshade98: that's inprogress
<jcastro> the fix for that
<jcastro> mgz: you still around doing distro things or will we likely see this fix tomorrowish?
<rshade98> thanks guys
<mgz> I'll sort it out tonight
<mgz> jcastro: ^
<jcastro> <3 thanks dude
<mgz> okay, tools in the ec2 public bucket for the ppa
<mgz> I don't have credentials for any of the other ones
<mgz> also need to do a release announcement...
<mgz> well, four release announcements now
<jcastro> heh
<jcastro> rshade98: wanna give it a shot now?
<rshade98> looks good
<jcastro> ok so it worked?
#juju 2013-04-25
<b1tbkt> silly question but shouldn't my maas/juju nodes contain a juju executable?
<sarnold> b1tbkt: I think the 'juju' executable is just for the human-controlled machine; I think the others are controlled by agents called something more like juju-agent ..
<b1tbkt> 'locate juju' with an updatedb db yields nothing
<b1tbkt> on naything except machine 0
<sarnold> b1tbkt: how about a find /usr -name '*juju*' ? I like locate, but between never being sure what is visible to it, what it indexes, and how often, I tend to like an explicit 'find' when looking for things...
<sarnold> well, rather, when _troubleshooting_ I prefer to use 'find'.
<b1tbkt> root@10-10-21-23:~# find / -name juju*
<b1tbkt> root@10-10-21-23:~#
<sarnold> well that is odd :)
<sarnold> b1tbkt: does this machine show up in 'juju status'? or is still an unprovisioned node?
<b1tbkt> i can ssh into the boxes with native ssh ubuntu@[IP] but juju ssh is always 'waiting for maching to come up'
<b1tbkt> yes, it shows up in juju status
<b1tbkt> agent-state: not-started
<b1tbkt> the agent should natively be a part of the maas isos, no? or does juju deploy the agent itself?
<sarnold> b1tbkt: I'm used to juju deploying the agent, but I've not yet tried maas
<b1tbkt> if juju normally deploys it then maas shouldn't interfere in any way
<freeflying> hi all, where can I find the source of juju's doc https://juju.ubuntu.com/docs/, are they under juju's trunk? or some other place?
<sarnold> freeflying: http://askubuntu.com/questions/52063/how-do-i-contribute-documentation-to-juju
<mfisch> freeflying: l... nm!
<freeflying> sarnold: mfisch awesome, thanks :)
<mfisch> marcoceppi: still awake ?
<ahasenack> hi guys, I can't seem to juju bootstrap using juju-core and canonistack (openstack), I get "error: no tools available". I was just able to bootstrap on ec2, though
<ahasenack> 2013/04/25 09:37:19 INFO environs: reading tools with major version 1
<ahasenack> 2013/04/25 09:37:19 INFO environs: falling back to public bucket
<ahasenack> 2013/04/25 09:37:19 ERROR command failed: no tools available
<mgz> I haven't got creds on whatever the bucket we have on canonistack is, so they've not been updated. you can copy the tools from ec2 to your own container.
<ahasenack> I have no idea how to do that, nor what "tools" are. I'm coming from pyjuju
<ahasenack> who has those creds?
<marcoceppi> mgz: how is this tools thing handled for private clouds that we don't have access to in order to upload the tools?
 * marcoceppi thinks of documenting how to upload tools
<ahasenack> marcoceppi: good point
<ahasenack> marcoceppi: like, someone from Company downloads juju and wants to try it with their own openstack deployment, it won't work out of the box, right?
<marcoceppi> ahasenack: I'm not sure, trying to figure that out :) It sounds like there's something you can do based on mgz's response. I'm just not sure what that /thing/ is
<ahasenack> sounds like there is a hardcoded path somewhere, path to a bucket
<ahasenack> maybe s/hardcoded/control-bucket/
<ahasenack> but that's unique for each one of us, right, it's random
<marcoceppi> ahasenack: it sounds like each "provider" has a global bucket maintained by the core team. If the tools arent' there it looks in your own bucket specified in the environments.yaml
<ahasenack> I tried --upload-tools, but it requires something else
<ahasenack> so I checked out "juju-core" from lp:
<ahasenack> https://pastebin.canonical.com/89978/
<ahasenack> time to read the README ;)
<ahasenack> hm, the checkout needs to be in $GOPATH
<ahasenack> is the goal to have the tools available as normal ubuntu packages at some point?
<ahasenack> hm, make still explodes
<ahasenack> hmm, I have a silli question: does the charm directory have to match the charm name in metadata.yaml?
<ahasenack> like, I have ~/charms/precise/keystone-ha
<ahasenack> but the charm name in keystone-ha/metadata.yaml is just keystone
<ahasenack> I can't seem to deploy it, juju complains about not finding the charm
<ahasenack> ah, never mind, got it, I was missing the <release> directory
<orospakr> hmm, is there an example out there (perhaps in the charm store?) of a charm that uses chef(-solo) for config and provisioning?  it seems like at least a little bit of glue is required, and I wouldn't mind being able to crib off someone! ;)
<dpb_> Hi all -- how well does jitsu work with juju-core?
<jcastro> marcoceppi: check out the post from bjorn on the mailing list
<jcastro> dpb_: it does not, but the core team is real responsive
<jcastro> so we plan on rolling in things people want relatively quickly
<dpb_> jcastro: should I file a bug report?
<jcastro> I think a tracking bug wouldn't hurt
<jcastro> mramm: what do you think?
<ahasenack> wasn't jitsu always a "temporary tool", with things that would eventually make it into core?
<ahasenack> might make more sense to file a specific feature request against core instead of asking to "port" jitsu to juju-core
<marcoceppi> jcastro: yeah going to make an au post on it. make sure it find its way in to the docs
<jcastro> ack
 * marcoceppi needs to test first
<AskUbuntu> How can I copy Juju tools for use in my deployment? | http://askubuntu.com/q/285395
<mgz> marcoceppi: is that still borked for you?
<jcastro> it's still borked for one guy
<jcastro> I think he's just writing up a question to FAQ/link
<mgz> that was what I suspected,
<jcastro> I also only just now noticed that this was mentioned in the release notes and I totally missed that.
<marcoceppi> mgz: what castro said
<mgz> but didn't want to accuse him of reputation farming :)
<jcastro> ok so mgz
<jcastro> moving forward
<jcastro> people who set up internal clouds
<jcastro> will they need to sync as part of the initial set up?
<mgz> people are still having issues, but I'm not clear on the contexts of all of them...
<jcastro> or will this be automated at some point?
<mgz> jcastro: there's logic to copy tools from a public location to your personal container in your tenant
<jcastro> ok if this next guy still has a problem, I will ask him to file a bug and we can dig in
<mgz> I need to recheck what circumstances everything gets triggered in though
<jcastro> yeah
<ahasenack> right now ec2 seems to have the tools correctly
<jcastro> I am just wondering where in the instructions we add that.
<mgz> because there were quite a few changes across development and I'm now really confused about the current state :P
<ahasenack> I bootstrapped a couple of hours ago with the latest version from the ppa
<ahasenack> sync-tools isn't working for me, though
<dpb_> mramm: what should I do for jitsu?  file a bug to have it ported?  File feature requests in juju-core?
<jcastro> marcoceppi: are you working on an answer or want me to chip in for that tools question?
<marcoceppi> jcastro: if you have an answer, go for it. I've been playing around trying to replicate the error so I can post the solution
<jcastro> hmm
<jcastro> so is it supposed to be just "juju sync" or what?
<robbiew> jcastro: is it a known bug that "juju status <servicename>" doesn't work? e.g. juju status wordpress, should show me the status of all units in the wordpress ser
<robbiew> only asking to know if I should file a bug or not
 * robbiew using juju-core in 13.04....\o/
<ahasenack> jcastro: see juju@, I posted a similar question there
<jcastro> I think that's a known bug
<ahasenack> jcastro: sync-tools, but it didn't work for me just now
<jcastro> right
<jcastro> and would a random person's openstack have access to that url?
<ahasenack> in s3 it's public afaik
<ahasenack> so the idea is to copy it from the aws bucket into your private cloud's bucket
<ahasenack> that's what I understood sync-tools does
<jcastro> nod
<robbiew> jcastro: ack..good ;)
<ahasenack> with the caveat "Due to some internal limitations, you have to have Ec2 credentials to do
<ahasenack> this (our ec2 code requires creds even though the bucket is public)."
<wkharold> just installed 13.04, doing the Juju Getting Started, want to use LXC, setup an environments.yaml stanza that uses 'type: local', juju bootstrap sez 'unknown provider type "local"'
<wkharold> pls tell me LXC will be supported ...
<mgz> wkharold: `apt-get install juju`, juju-core will support local lxc deployments, but not in this release
<mgz> the good news is you can continue using juju for local charm testing, and deploy those charms with juju-core if you wish
<wkharold> mgz: tnx
<jcastro> Daviey: hey, I'd like to update all the websites/AU questions/docs about how to install Juju from backports
<jcastro> right now it's all pointing to the PPA.
<jcastro> But I've not done backports before, what are the steps?
<Daviey> jcastro: Desktop, it should be enabled by default.
<Daviey> Server, i believe it is aswell.
<Daviey> However, it's possible people might have disabled it.
<jcastro> ok so on a clean install
<jcastro> and I apt-get install juju-core
<Daviey> For most people, it's just a simple case of sudo apt-get install juju-core
<jcastro> over time I'll get backports
<jcastro> ok so other than that, it's just the same as distro
<jcastro> other than a link to how to reenable backports on a server if they explicitly turned it off
<jcastro> anything else?
<Daviey> jcastro: Usually, you have to specific juju-core/raring-backports .. his ISN'T required because it's not in a primary pocket aswell
<jcastro> ok so as far as the instructions are concerned, same commands as distro
<Daviey> jcastro: https://help.ubuntu.com/community/UbuntuBackports#Enabling_Backports
 * jcastro nods
<jcastro> ok I'll update everything now then, thanks
<Daviey> jcastro: "If you previously disabled Backports, or the apt-get command doesn't find juju-core - it is most likely you need to enable it by.."
<jcastro> right
<jcastro> Daviey: when do you anticipate the backport landing in 12.04?
<Daviey> jcastro: I wouldn't like to comment.
<jcastro> days, weeks, or months would be good enough?
<Daviey> hopefully soon
<jcastro> because otherwise I need to write version specific instructions
<Daviey> I'd suggest ~3 weeks, which should leave some bounce room.
<Daviey> I am not in the Ubuntu backports team, so i can't be more firm.
<jcastro> close enough, thanks.
<jcastro> Daviey: is pyju in backports as well?
<Daviey> no
<Daviey> jcastro: https://wiki.ubuntu.com/RaringRingtail/ReleaseNotes#Juju useful?
<jcastro> hah, yeah
<jcastro> thanks
<mgz> release notes there are pretty neat
<mramm> dpb_: file feature requests for juju-core
<mramm> or for tools to go alongside juju-core that do what jitsu did
<dpb_> ok
<dpb_> mramm: thx
<jcastro> marcoceppi: check out manage.jujucharms.com and see if that works for you
<jcastro> might need to wait for DNS
<marcoceppi> jcastro: it loads for me. What should I expect?
<mramm> we are also experamenting with a python API to talk directly to the juju state server over a websocket, so that some jitsu-ike commands can still be written in python
<jcastro> marcoceppi: a UI to be able to score charms, etc.
<mramm> hazmat has a very experimental branch up on launchpad already
<mramm> https://pypi.python.org/pypi/jujuclient/0.0.1
<marcoceppi> jcastro: I just see the charmworld
<jcastro> do you see a login button on the right?
<hazmat> mramm, its not that experimental..
<hazmat> mramm, i mean the gui and landscape have been using it for months..
<hazmat> oh. that one
<hazmat> python websocket confusion
<mramm> right
<mramm> it is like 2 days old ;)
<hazmat> mramm, i want agents in python too
<mramm> hazmat: interesting
<marcoceppi> jcastro: yeah, and I logged in, but no idea what/where to go from there
<jcastro> I was just making sure it resolved for you
<marcoceppi> jcastro: ah, cool
<mramm> hazmat: new kinds of agents, or replacing machine and unit agents with python?
<mramm> I think there are quite a few advantages to the core agents being a self contained binary
<jcastro> marcoceppi: we should have the new UI for managing ratings, etc tomorrow
<marcoceppi> jcastro: awesome
<jcastro> mramm: arosales: ok instructions all updated everywhere and pushed, just waiting for the RT response, last bit will be to announce to the mailing list.
<arosales> jcastro, thanks :-)
<mramm> jcastro: rock and roll!
<dpb_> mramm: https://bugs.launchpad.net/juju-core/+bug/1172814, https://bugs.launchpad.net/juju-core/+bug/1172811
<_mup_> Bug #1172814: Need a way to run an end-to-end test on a juju environment. <juju-core:New> <https://launchpad.net/bugs/1172814>
<_mup_> Bug #1172811: Need a way to watch juju-core environements <juju-core:New> <https://launchpad.net/bugs/1172811>
<arosales> jcastro, m_3: other charmers. Your guys' thoughts on adding lp:charms & lp:charm-tools to to lp:juju-project?
<jcastro> didn't know we had -project
<arosales> re the juju-dev list thread subj="juju-project
<arosales> jcastro, I think Danilo _just_ added it
<jcastro> I haven't gotten the mail yet
<arosales> jcastro, https://lists.ubuntu.com/archives/juju-dev/2013-April/000943.html
<jcastro> that seems pretty straightforward and beneficial
<jcastro> arosales: mramm: forgot to eat lunch, bbi ~30. The RT for the website is #61095 if you want to follow along
<_mup_> Bug #61095: Crash trying to open tomboy preferences <tomboy (Ubuntu):Invalid> <https://launchpad.net/bugs/61095>
<marcoceppi> arosales: I'm not sure if charms would work as it's already it's own distro, but charm-tools would be a good idea
<arosales> marcoceppi, ya may not want to mess with lp:charms since it it is tied to the charm store.
<marcoceppi> We don't have a rabbitmq charm?
<hazmat> mramm, new kind
<hazmat> marcoceppi, we do
<marcoceppi> hazmat: "rabbit" in charmworld returns nothing
<ahasenack> rabbitmq-server probably
<hazmat> http://jujucharms.com/charms/precise/rabbitmq-server
<marcoceppi> odd
<hazmat> marcoceppi, substring searching needs ie. rabbit*
<hazmat> needs star
<marcoceppi> hazmat: Ah, didn't realize it needed wildcard for searches
<marcoceppi> thanks
<hazmat> marcoceppi, rabbitmq would work as well.. its tokenizing.
<ahasenack> hi, what's the right update-alternatives command to switch back to juju-core? The command from the release notes isn't working
<ahasenack> https://wiki.ubuntu.com/RaringRingtail/ReleaseNotes#Juju
<ahasenack> $ sudo update-alternatives --set juju /usr/lib/juju-1.10.0/bin/juju
<ahasenack> update-alternatives: error: alternative /usr/lib/juju-1.10.0/bin/juju for juju not registered; not setting
<mgz> ahasenack: just run `update-alternatives --config juju` and pick from the list
<mgz> I'm guessing the version number change has messed with it... really it should be 1.10 only or something
<ahasenack> mgz: doesn't work
<ahasenack> $ sudo update-alternatives --config juju
<ahasenack> There is only one alternative in link group juju (providing /usr/bin/juju): /usr/lib/juju-0.7/bin/juju
<ahasenack> Nothing to configure.
<ahasenack> mgz: I'm using juju-core from the ppa, is the distro one different?
<mgz> it is.
<mgz> (for now)
<ahasenack> ok, that explains it
<ahasenack> so the ppa one for now can't coexist with the py one
<mramm> we will update the PPA package recipe to match the release soon
<ahasenack> ok
<jcastro> marcoceppi: nice work on those icons!
<marcoceppi> cant' wait to see them in the UI
<arosales> marcoceppi, +1, thanks for knocking those out
<jcastro> marcoceppi: ~20 minutes is what rick tells me for the site to update
<jcastro> mramm: arosales: RT pushed through, we're now all up to date doc wise.
<jcastro> at least until like tomorrow or whenever you guys decide to switch over to PPA builds. :p
<arosales> jcastro, thanks I see that @ https://juju.ubuntu.com/get-started/
<mramm> jcastro: I think we will just push "supported" updates into the backports repository
<mramm> and use the PPA for development releases
<jcastro> I like that
<mramm> so we should not have to change the docs
<jcastro> indeed
<jcastro> in hindsight
<jcastro> we should have done this for the previous releases too
<mramm> agreed
<jcastro> but whatever
<mramm> it is what it is
<jcastro> the ships are ablaze as you have ordered my conquistador.
<mramm> haha
<mramm> was watching the game of thrones last night -- you win or you die
<mramm> ;)
<jcastro> I just posted to the list to see if there's any other major transition issues people would like to see handled
<jcastro> heya marcoceppi
<marcoceppi> heya jcastro
<jcastro> a follow up mail to mine wrt. the status of charm-tools with 1.10.x would probably help
<jcastro> let people know that those tools are all set to go
<jcastro> mramm: we've had some issues with juju sync not working for some people wrt. getting the tools in their buckets
<jcastro> ahasenack: is yours still broken?
<marcoceppi> jcastro: Well, they only really live in PPA, the distro version won't have the pretty new charm create in it
<mramm> well, we should just mention that, and how to enable them.
<ahasenack> jcastro: I can deploy on aws without any hack, and on canonistack after I set that public tools url in the environments file
<ahasenack> jcastro: I haven't tried sync-tools anymore since this morning, when it didn't work
<mramm> as for sync-tools -- any bugs on that will get very high priority
<ahasenack> I get this: http://pastebin.ubuntu.com/5602223/
<jcastro> mramm: ok so in the case of this guy: http://askubuntu.com/questions/284846/juju-doesnt-bootstrap-due-to-error-command-failed-no-tools-available-error
<mramm> is there a bug filed for that?
<jcastro> how do people get the tools on their own internal openstack?
<ahasenack> mramm: sync? no, I emailed the list about it because I wasn't sure I was using it correctly
<mramm> ok
<jcastro> or do they put our canonistack url in their environments.yaml? (that can't be right)
<mramm> they should be able to sync them into local buckets
<mramm> until the tools were in the right place in amazon that would not work
<ahasenack> that was my understanding. That the source is always aws, and the target is what you say with -e
<mramm> but it should work now
<mramm> if not, that's a critical bug which should be addressed ASAP
<ahasenack> can someone else try?
<mramm> even if the solution is just to provide a workaround script that does the copy
<mramm> and a real fix pushed in an update release
<jcastro> does anyone have the URL to the s3 bucket?
<jcastro> the release notes only mention canonistack and hp cloud
<ahasenack> it's hardcoded in juju, you shouldn't need it
<ahasenack> it's in the code, I mean
<ahasenack> (or so I think)
<ahasenack> oh, for a workaround script
<ahasenack> jcastro: https://s3.amazonaws.com/juju-dist/tools/juju-1.10.0-precise-amd64.tgz?Expires=1682453601&Signature=zak2C4ARkuqMDG24lxQwVPNhpQc%3D&AWSAccessKeyId=AKIAIE2BLLQVB4JVA6RQ
<ahasenack> but that was locally generated, probably with my credentials
<jcastro> nod
<ahasenack> meaning, not good for a blog post
<ahasenack> I got it with juju sync-tools -e canonistack -v
<ahasenack> the -v showed it
<ahasenack> but I can actually download it, it works (wget, web browser)
<sidnei> removing all the query params works too
<ahasenack> ah, good
<ahasenack> ok, I remember now
<ahasenack> they said that juju requires creds, even though it's a public bucket
<jcastro> ok so for a normal openstack user
<jcastro> just "juju sync-tools" is the answer?
<ahasenack> hm, here is another command line incompatibility
<ahasenack> 2013/04/25 20:17:51 INFO worker/uniter: HOOK error: flag provided but not defined: -r
<ahasenack> 2013/04/25 20:17:51 INFO worker/uniter: HOOK subprocess.CalledProcessError: Command '['relation-list', '-r', 'swift-storage:2']' returned non-zero exit status 2
<sidnei> jcastro: it should be, but it requires you to have valid aws credentials
<ahasenack> jcastro: I think so, bar that "use of closed network connection" bug
<ahasenack> and what sidnei said
<mwhudson> juju bootstrap (pointed at a maas install) fails with "error: no tools available"
<mwhudson> any ideas?
<ahasenack> mwhudson: raring? which version of the package?
<mwhudson> ahasenack: no, precise
<mwhudson> from https://launchpad.net/~juju/+archive/devel/+packages
<ahasenack> mwhudson: 1.10.0 something?
<mwhudson> yeah, i think so
<ahasenack> 1.10.0-1~1189~raring1 is what I have (raring)
<mwhudson> 1.10.0-1~1189~precise1
<ahasenack> I was having that tools error earlier today and some days ago
<ahasenack> mwhudson: and the default-series you are targeting? precise too?
<mwhudson> um
<mwhudson> yes
<ahasenack> mwhudson: I don't know then, should be the same I have deployed right now in aws. precise, 64 bits, 1.10.0
<ahasenack> maybe with maas it behaves differently, was it working "before", for some definition of before?
<mwhudson> no, this is a new install
<mwhudson> i sort of had it working with juju-py
<ahasenack> ah, ok, so many variables
<ahasenack> mramm: https://bugs.launchpad.net/juju-core/+bug/1172895, fyi
<_mup_> Bug #1172895: relation-list incompatibility with pyjuju: -r <juju-core:New> <https://launchpad.net/bugs/1172895>
<mramm> ahasenack: for the command line tool incompatibility type things, or anything else you find -- feel free to file bugs.   Even if they are just temporary issues or you don't know if they are reproducable -- we should be able to handle that with our bug triage process.
<mramm> ahasenack: perfect!
<ahasenack> thanks
<mramm> ahasenack: I added the relation list issue to the immediate dev queue
<ahasenack> mramm: nice
<ahasenack> someone fixed a similar issue earlier today with --log-level vs -l
<mramm> Frank was just working on that stuff, so I think it should be fresh in his mind
<ahasenack> mramm: https://bugs.launchpad.net/juju-core/+bug/1172717 it says "merged", but the bug is open and the review request still pending
<mramm> ok, I'll look into it
<ahasenack> probably something to do with the rietveld integration (if I spelled that correctly)
<mramm> yea, we don't have it all wired up to automatically close things in LP
<mwhudson> ahasenack: you said you had the same problem, and now you don't?
<mwhudson> did you do anything to fix it, or did it just go away?
<ahasenack> mwhudson: it just disappeared, they uploaded the right set of tools to that public amazon bucket
<mwhudson> ah
<ahasenack> mwhudson: try sourcing aws creds, I think juju requires those even though the s3 bucket is public
<mwhudson> where do i put s3 creds in the set up for a maas environment?
<ahasenack> mwhudson: I'm just guessing now, but try sourcing them in your shell for starters
<mwhudson> oh right
<ahasenack> mwhudson: and re-run the command with -v, might have more useful output
<mwhudson> tried that:)
<mwhudson> mwhudson@lava-leg01:~$ juju -v bootstrap
<mwhudson> 2013/04/25 21:32:12 INFO environs: reading tools with major version 1
<mwhudson> 2013/04/25 21:32:12 INFO environs: falling back to public bucket
<mwhudson> 2013/04/25 21:32:12 ERROR command failed: no tools available
<mwhudson> error: no tools available
<mwhudson> mwhudson@lava-leg01:~$
<ahasenack> ok :(
<ahasenack> did you source the aws creds in that run?
<mwhudson> no
<mwhudson> trying to find some, haven't used aws in a while ...
<ahasenack> that's the "public bucket" bit I believe
<jcastro> imbrandon: ping
<mwhudson> ahasenack: i forget, how do you even set AWS creds?
<ahasenack> mwhudson: EC2_SECRET_KEY, EC2_ACCESS_KEY,
<ahasenack> I think that's it
<mwhudson> oh right
<ahasenack> you grab them from the aws console somewhere
<ahasenack> EC2_URL too, but probably not needed in this case
<ahasenack> https://ec2.us-east-1.amazonaws.com is mine
 * mwhudson finds the right bit of his .bashrc
<mwhudson> no difference
<mwhudson> mwhudson@lava-leg01:~$ juju -v sync-tools
<mwhudson> 2013/04/25 21:46:20 INFO environs/ec2: opening environment "juju-public"
<mwhudson> 2013/04/25 21:46:20 ERROR failed to initialize the official bucket environment
<mwhudson> 2013/04/25 21:46:20 ERROR command failed: environment has no access-key or secret-key
<mwhudson> error: environment has no access-key or secret-key
<mwhudson> ^ this looks like the sort of thing you were saying?
<ahasenack> hm, yeah
<ahasenack> but you got it when you *used* the aws creds? :)
<mwhudson> no
<mwhudson> but!
<mwhudson> i have now fond
<mwhudson> *found
<mwhudson> http://bazaar.launchpad.net/~goamz/goamz/trunk/view/head:/aws/aws.go
<ahasenack> you didn't specify an env above
<ahasenack> -e
<mwhudson> which tells me which env vars to set :/
<ahasenack> AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
<ahasenack> to tell you the truth, I have both sets :)
<ahasenack> EC2_* and AWS_*
<mwhudson> yeah, different tools look at different vars i think :(
<mwhudson> ok, that's doing something
<mwhudson> however
<mwhudson> it only seemed to copy i386 and amd64 tools and i'm going to be deploying armhf...
<mwhudson> so i guess that's going to be another problem
<ahasenack> it is :)
<ahasenack> ok, but this is important
<ahasenack> you had to set the aws creds
<mwhudson> yes
<ahasenack> even when not using aws
<mwhudson> and then run sync-tools
<ahasenack> what did it output this time?
<mwhudson> (i don't know if bootstrap would have worked, to be fair)
<mwhudson> ahasenack: http://paste.ubuntu.com/5602338/
<ahasenack> cool!
<ahasenack> I haven't gotten that far yet with canonistack
<ahasenack> mwhudson: so you were using juju before with armhf, right?
<ahasenack> pyjuju I mean
<mwhudson> yeah
<ahasenack> jcastro: ^^^ pastebin, a sample of sync-tools working after exporting aws creds
<mwhudson> but i didn't get it quite working either
<ahasenack> mwhudson: ok, I don't know if this will work with arm, I'm thinking "mongodb on arm...?"
<mwhudson> i got it bootstrapped
<mwhudson> this time
<mwhudson> bootstrap completed quickly
<mwhudson> and status is now just hanging
<ahasenack> bootstrap is more like a request
<ahasenack> when it comes back, it doesn't mean it's done, just that the request was made
<ahasenack> juju status hangs because the bootstrap isn't actually done yet
<ahasenack> it could return saying that, I think, but it doesn't and there was an almost-flame-war on the mailing list about this once ;)
<mwhudson> heh
<jcastro> marcoceppi: ^^ see the pastebin for a possible answer for that question
<mwhudson> i would be very surprised if this bootstrap ever succeeds
<ahasenack> mwhudson: this is bootstrapping via maas, right?
<mwhudson> yeah
<marcoceppi> jcastro: excellent thanks
<ahasenack> without having tools built for armhf :)
<mwhudson> yes
<ahasenack> yeah, you might need to ssh into that node to see what is going on, /var/log/juju
<ahasenack> if it's up already
<marcoceppi> jcastro: btw, merge request for icon.svg that I've sat on for a while is up: https://code.launchpad.net/~marcoceppi/charm-tools/icon-template/+merge/161020
<mwhudson> and if my juju-py experience is anything to go by, it will be asking maas for a amd64 node
<mwhudson> which it doesn't have
<jcastro> marcoceppi: ooh nice
<mwhudson> ah well
<mwhudson> a node is allocated
<jcastro> m_3: or negronjl, got time to check out marco's mp?
<negronjl> jcastro: give me a link and I'll check it out ...
<mwhudson> so maybe juju-core doesn't have *that* problem
<marcoceppi> negronjl: https://code.launchpad.net/~marcoceppi/charm-tools/icon-template/+merge/161020
<negronjl> marcoceppi, I'm on it
<marcoceppi> negronjl: thanks!
<negronjl> marcoceppi, 1313 lines!!!
<marcoceppi> negronjl: Most of it is just template stuff!!
<negronjl> marcoceppi, sigh ... I'll review it :/ ... j/k
<marcoceppi> There's like 5 copies of the same SVG in it
<mwhudson> ahasenack: part of the fun is that maas allocating a node is a netinstall
<mwhudson> so it takes a while
<ahasenack> :)
<ahasenack> mwhudson: I'm eod, will peek back in in about 3h
<mwhudson> ahasenack: thanks for the hints so far
<ahasenack> good luck
<mwhudson> ahasenack: is there a bug for this 'requires creds' thing?
<marcoceppi> negronjl: if it makes it easier, the only thing that I added is in scripts/lib/proof.py
<ahasenack> mwhudson: no, we were just talking about it here during the day
<mwhudson> ok
<negronjl> marcoceppi, I was j/k .. reiewing it now
<marcoceppi> negronjl: Ah, thanks
<ahasenack> mwhudson: it seems to be known by the developers, as it was in the release notes, but maybe the implication for sync-tools isn't
<negronjl> marcoceppi, Approved and Merged.
<jcastro> \o/
<marcoceppi> negronjl: \o/ thanks!
<negronjl> marcoceppi, np
<dpb_`> Hi all -- someone have a clue what's going wrong with this lxc ubuntu deploy on top of raring? http://paste.ubuntu.com/5602655/  looks like somehow python3 is being used?  But I don't see how, /usr/bin/python is showing 2.7, etc.
<sarnold> dpb_`: hrm, I thought that had been fixed
<sarnold> dpb_`: https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1130809
<_mup_> Bug #1130809: lxc scripts break when user has PYTHONPATH set <apparmor> <apport-crash> <i386> <raring> <juju:Incomplete> <juju (Ubuntu):Fix Released by gz> <lxc (Ubuntu):Invalid> <https://launchpad.net/bugs/1130809>
#juju 2013-04-26
<mwhudson> hah
<mwhudson> + wget --no-verbose -O - http://localhost/MAAS/api/1.0/files/?key=8a8b1d56-ae02-11e2-a65a-ac162d8ba8b8&op=get_by_key
<mwhudson> in cloud-init-output.log
<mwhudson> i can see two problems here: 1) i put localhost in the environment config
<mwhudson> 2) this is an armhf node...
<mwhudson> + tar xz -C /var/lib/juju/tools/1.10.0-precise-amd64
<ahasenack> mwhudson: how did the bootstrap go?
<mwhudson> ahasenack: getting there
<ahasenack> ah, it fetched the amd64 tarball?
<mwhudson> well
<mwhudson> it didn't
<mwhudson> but for reasons that are pebkac
<mwhudson> if i hadn't made that mistake, i don't think the next bit would have gone very well though
<ahasenack> ok
<mwhudson> thumper: oy, are you here?
<sarnold> do the tools exist for armhf? I thought I saw in #ubuntu-release earlier that juju-core had incorrect architecture lines...
<mwhudson> sarnold: not that i can tell
<mwhudson> sync-tools just grabs stuff for amd64 and i386
<mwhudson> so i guess i wasn't expecting the bootstrap to _work_
<mwhudson> but i also wasn't expecting it to blithely try to grab the amd64 tools
<mwhudson> i guess i should try pyju again, i hear this actually works with armhf...
<thumper> mwhudson: oh hai
<mwhudson> thumper: i'm having fun with juju-core on (well, deploying to) armhf
<mwhudson> thumper: would you expect this to work?  or am i rubbing myself across the bleeding edge again?
<thumper> mwhudson: hmm...
<thumper> mwhudson: which version of go are you using?
<mwhudson> thumper: no idea
<mwhudson> i don't think i have go installed actually
<mwhudson> hm no i do
<thumper> golang is the package
<mwhudson> mwhudson@lava-leg01:~$ dpkg -l golang
<mwhudson> No packages found matching golang.
<thumper> well, since we don't build for arm yet, I'd be very surprised if you got juju-core working on arm
<mwhudson> ah
<mwhudson> ii  golang-go                                     2:1-5                                         Go programming language compiler
<thumper> hmm... mine is 2:1.0.2
<mwhudson> this is precise fwiw
<thumper> mwhudson: I've been told by davecheney that go prior to 1.1 is crackful on arm
<mwhudson> why does this matter though?
<thumper> so no, I wouldn't expect it to work
<mwhudson> does stuff get compiled on the fly?
<thumper> we don't build arm binaries
<thumper> so how are you running it if not compiling yourself?
<mwhudson> i'm running on an intel box
<mwhudson> pointed at maas
<mwhudson> that has a bunch of arm nodes enlisted
<thumper> hmm...
<thumper> there are no arm tools built
<thumper> so no, I don't think it will work
<mwhudson> ok
<thumper> you'd have to build your own
<thumper> which is a bit more work
<mwhudson> it seems to try to fetch the amd64 tools on my node
<mwhudson> which i guess is a bug?
<thumper> yeah, that's kinda hard coded :(
<mwhudson> ok
<thumper> so, yes a bug, arm isn't supported yet
<thumper> through the wonders of a compiled lanuage
<thumper> language
<mwhudson> who can i talk to to find out if this is a priority?
<thumper> mramm
<mwhudson> ok
<thumper> np
<davecheney> can I get some help with the juju gui ?
<gnuoy`> Hi, I'm trying to debug an issue I'm seeing between 2 charms I'm testing on lxc. I have a debug-hooks session running and if I remove-relation between the charms the debug-hooks session immediately kicks in and gives me a session in the charm dir. However add-relation does not, the debug hooks session is silent as if there is no attempt to run any hooks.
<gnuoy`> http://paste.ubuntu.com/5604164/
<gnuoy`> hmm, I'm going to redeploy and try and recreate.
<idioteque> clear
<idioteque> exit
<marcoceppi> Should a charm ever need to "require" a juju-info interface? I thought that subordinates were supposed to provide it, but all "other" communication was to be done via other interfaces
<SpamapS> marcoceppi: nothing provided is useful without at least one requirer
<jcastro> hey marcoceppi
<marcoceppi> hey jcastro
<jcastro> now that your charm tools stuff got merged maybe you can post the status on the list?
<jcastro> in my transition thread?
<marcoceppi> jcastro: we still haven't figure out what to do about the PPA. Adding the juju/pkgs ppa will "break" go-juju installs
<marcoceppi> I'd hate to say "Yeah, charm-tools update, break your juju to install"
<jcastro> core is in backports, maybe we should put charm-tools there too?
<marcoceppi> jcastro: probably
<jcastro> non-PPA workflow for everything would be quite nice.
<marcoceppi> I know we talked briefly about just putting charm-tools in it's own ppa, but backporting would be nice
<jcastro> marcoceppi: ok so that would be either Daviey, mgz, or jamespage, all in the UK and probably at the bar, can you sync up with them on Monday?
<marcoceppi> jcastro: yeah
<m_3> marcoceppi: I think juju/pkgs ppa wonn't break juju-core once 0.7 lands in the ppa
<marcoceppi> m_3: ah, any idea when that'll happen? I know it's failed to build in there the last few times
 * m_3 looks to see if that's done
<m_3> ah that's why then
<m_3> I was wondering what the deal was
<m_3> marcoceppi: so, no, no clue
 * marcoceppi nods
<marcoceppi> looks like quantal built, but raring is still no-go
<m_3> marcoceppi: precise still no
<m_3> at least it doesn't show up on my updates
<marcoceppi> unfortunate
<ali1234> i have a dedicated server with 12.04. can i manage it using juju?
<sarnold> ali1234: it's not exactly ideal for that; you can definitely use the 'local' lxc provider to deploy services into lxc containers on that one machine, but juju really shines at allocating machines and services from clouds, like from MAAS or EC2 or rackspace...
<ali1234> why is there even a difference?
<sarnold> ali1234: you -can- use the 'jitsu deploy-to' command to force a deployment on a specific machine, without forcing containers, but that's not exactly promoted with the python version of juju; the go version is supposed to do that 'natively', without using the same kinds of hacks, but I haven't followed that closely enough to know if it will work that way or not
<ali1234> i want to use juju to manage virtual machines in a cloud
<ali1234> the only caveat being i want the cloud to run on my server
<ali1234> so i guess i need lxc for that
<ali1234> but how is that really different than using AWS?
<marcoceppi> ali1234: You'll need an underlying provider for juju to talk to. The difference between AWS and just running VMs on a machine is AWS offers a channel for juju to talk to. Juju doesn't actually do the heavy lifting of turning on and provisioning machines, it simply requests them. There are already tools out there (re: Amazon, OpenStack, MAAS) to manage machine instances
<ali1234> ah yes, openstack
<ali1234> why does it need a minimum of 7 machines?
<marcoceppi> Juju is really more interested in setting up those instances and then orchestrating communication between the services and units deployed
<marcoceppi> ali1234: why does what need a minimum of 7 machines?>
<ali1234> openstack
<marcoceppi> Well, if you're using devstack, you only need one machine. 7 machines is the "recommended minimum hardware" for running openstack. You'll need "computer" nodes, servers for management, servers for authentication, storage, etc etc
<marcoceppi> s/computer/compute/ nodes
<ali1234> no, the recommended minimum is 10. 7 is the absolute minimum according to the document i read, and now cannot find
<marcoceppi> It's not recommended (for HA, etc) to have everything for openstack on one machine. It doesn't scale very well
<marcoceppi> If you're looking to play around with OpenStack you can do so on one machine: http://devstack.org/ as for reasons why OpenStack says this or that I'd give #openstack a go :)
<ali1234> i'm not looking to play around
<ali1234> this is a production server
<ali1234> i want a better way to manage it
<ali1234> preferably one that won't increase the cost by a factor of 10...
<marcoceppi> OpenStack isn't really a tool to just manage a server, it's a tool to build cloud environments
<sarnold> marcoceppi: wow, devstack needs to be better advertised :)
<ali1234> the way i see it, a cloud environment just means running virtual machines
<marcoceppi> ali1234: that's a really simplistic view of it
<ali1234> perhaps
<marcoceppi> Just off the top of my head, you have things like: storage management, networking management, images to build virtalmachines, and actual "compute" nodes you deploy vms to
<marcoceppi> All of that and more go in to building a cloud environment. It all takes hardware to do so
<marcoceppi> I'm not OpenStack expert, the people over in #openstack would be far better equiped to answer questions about how it may or may not help you
<ali1234> and there is nothing else that could do it?
<marcoceppi> ali1234: could do what?
<ali1234> give me a private cloud on a single server
<ali1234> which is suitable for production use
<sarnold> ali1234: fiddle around with juju's local provider on your workstation for a little bit and see what you think. You could use it to manage lxc instances on your server; that'd probably be the least-overhead sort of setup like this, short of just running all the services on the one machine as we have for the last 30 years....
<ali1234> i'm running all the services on the one machine now, the problem is they all conflict with each other
<sarnold> aha :) darn
<marcoceppi> ali1234: Someone was able to get Juju local provider to work on a server and map public ips to different machines http://askubuntu.com/a/282415/41
<marcoceppi> that may or may not work for what you're doing
<ali1234> it's running 4 wordpress, 2 drupal, moinmoin, some random ecommerce site...
<ali1234> a gitlab (which needs a load of unpackaged ruby gems), and several static pages
<ali1234> oh and a git server, and a bitcoind
<sarnold> no wonder you want something better :)
<sarnold> marcoceppi: nice.
<ali1234> it costs 60 euros/month... last time i checked that will get me 4 instances on amazon...
<sarnold> hetzner? :)
<ali1234> right
<sarnold> hehe, I've thought about that too. ridiculous amouts of hardware for cheap cheap cheap.
<ali1234> and the thing is we're only using about 10% of the resources it has
<ali1234> but adding more services just makes it unmanagable
<ali1234> so i'd like to be able to spin up VMs on it, please
<marcoceppi> I don'
<marcoceppi> I don't know if I'd call LXC production vm/containerization, but it's certainly worth a shot
<marcoceppi> But that might be splitting hairs at this point
<sarnold> ali1234: I've heard the MAAS group uses libvirt VMs for their testing... it's not exactly the intentional usage of MAAS on a pile of VMs but it might also work. At least on
<sarnold> ali1234: at least on my laptop, I often run ten or so VMs simultaneously (lighjtly loaded..) and things mostly work fine, those hetzner machines are bonkers compared to my laptop...
<marcoceppi> sarnold: the only thing I'd be worried about using MAAS out in the ether is it kind of gets network hungry (last I checked it) and tries to own everything
<sarnold> marcoceppi: heh, true, hosts wouldn't be pleased to find that thing aimed outwards :)
<ali1234> got a 10TB soft bandwidth limit...
#juju 2013-04-27
<marcoceppi> uh oh, drupal6 charm is double broken. Wrong metadata.yaml and it's stacking against a personal branch
<SpamapS> marcoceppi: ping the maintainer.
<_mup_> juju/trunk r622 committed by kapil@canonical.com
<_mup_> local provider, strip python envvars, fixes raring
<denisura> howdy
<denisura> trying to use type:local with juju-1.10.0. Getting error: environment "sample" has an unknown provider type "local". Is this type is available?
<hazmat> denisura, its not
<hazmat> denisura, try this to separate pyjuju and gojuju..  mkdir ~/.juju-core ... export JUJU_HOME=$HOME/.juju-core  ... juju init > ~/.juju-core/environments.yaml
<hazmat> marcoceppi, fwiw we do lots of dev on our openstack charms & on a single beefy servers using the vmaas charm, which slices up the hardware into multiple kvms, it would be nicer with kvm inside of lxc, but at the moment its nested kvm.
#juju 2013-04-28
<sarnold> hazmat: what kind of performance losses do you see with the nested kvms using vmaas? where can one find the vmaas charm? (it isn't on jujucharms.com, anyway..)
<hazmat> sarnold, http://jujucharms.com/~virtual-maasers/precise/virtual-maas
<sarnold> aha :) thanks hazmat
<sarnold> looks nice
<hazmat> sarnold, i don't have exact benchmarks offhand, its a significant loss, but passable on good hardware
<hazmat> marcoceppi, i have a drupal7 charm that does a basic install based off one of the drupal6's that was floating around
<sarnold> hazmat: ah, bummer. still neat. :)
<hazmat> sarnold, its sliced bread cool :-)
<sarnold> hahaha
<marcoceppi> Just installed juju-core alongside juju-0.7
<marcoceppi> having issues when trying to bootstrap an environment I added: ERROR command failed: cannot query old bootstrap state: Get https://s3.amazonaws.com/<control-bucket-from-config>/provider-state: read tcp 207.171.163.33:443
<mwhudson> is it possible to install juju 0.7 on precise?
<mwhudson> with lxc-create i guess
#juju 2014-04-21
<sridher> Error:  worker: exited "environ-provisioner": failed to process updated machines: cannot start machine 1: no matching tools available
* mbruzek changed the topic of #juju to: Weekly Reviewer: mbruzek || Welcome to Juju! || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP
<Tug> Hi, I have a few questions about customizing a deployment of mongodb with mongodb charm
<Tug> Like what would be the recommanded way to add authentication? Should I clone the mongodb charm, include the keyFile in it and modify the install hook to copy the file to the right place?
<hazmat> Tug, keyfile being ssl?
<hazmat> Tug, ideally that would be config
<hazmat> Tug, but yeah.. in general fork, modify & test, submit pull request/merge proposal
<Tug> hazmat, yeah ssl
<Tug> hazmat, you mean modify the config-changed hook ?
<hazmat> Tug, yeah
<hazmat> Tug, and config options on the charm
<hazmat> Tug, config.yaml
<Tug> hazmat, yeah add a new config option for the path of the file for instance right ?
<hazmat> Tug, for the contents of ssl cert / ssl key / ssl ca
<hazmat> Tug, the config-hook drops those onto disk, and configures mongodb to use ssl if their present..
<Tug> hazmat, the content directly into the config.yaml you think ?
<hazmat> Tug, no.. config.yaml is the schema, but yeah.. the service config would have the ssl key/cert config..
<Tug> hazmat, ok I see. Well why not. Not sure how it's going to render on juju-gui :)
<hazmat> Tug, not to pretty, but should be fine, just gets collapsed into a text field  i've done this with some of the other charms
<Tug> Ok thx, I'll try this then ;)
<hazmat> Tug, there's one ancillary alternative  which is having the mongodb service act as its own ca, but that implementation is a bit more advanced (have to replicate the ca files across replicaset and potentially to shard servers).
<hazmat> the config options for key/cert/ca usage is pretty straightforward
<Tug> hazmat, Mmm I see, but I guess I would have to play with openssl to have this right ?
<Tug> and add multiple hooks
<hazmat> Tug, don't worry about the service being its own ca.. its complicated.. there's some helpers in charm-helpers..
<Tug> ok hazmat
<lazyPower> hazmat: ping
<hazmat> Tug, the config option around ssl is pretty straight forward.. add additional options to config.yaml for key/cert/ca .. detect those in config-changed and configure mongodb for ssl.. also probably one more.. which is for clients to pass the ca
<hazmat> unless its a system recognized ca
<hazmat> lazyPower, pong
<hazmat> lazyPower, yeah.. i'm on it :-)
<hazmat> lazyPower, re DO
<lazyPower> hazmat: I did some work on that api parser actually
<hazmat> lazyPower, oh?
<lazyPower> its made me realize how weak i am with regex :P
<hazmat> lazyPower, api parser?
<lazyPower> oh sorry, context
<Tug> hazmat, out of curiosity, do you have a link to the charm-helpers you were talking about ?
<lazyPower> i'm working on exact matches so we dont match their prefab app boxes.
<lazyPower> eg: 12.04 dokku
<hazmat> lazyPower, if you mean jujuclient.. rog has something that will use parse the golang client api to json
<mbruzek> Hello Tug
<hazmat> lazyPower, ah.. so i'm not quite sure what the best option is.. i was thinking of a unit test that verified all the default images chosen
<lazyPower> i want to abstract away the list if i can, because it wont scale. They deprecate the vanilla images pretty often.
<hazmat> lazyPower, and then tossing it into ci
<Tug> Hi mbruzek
<hazmat> lazyPower, basically i want to avoid clients having to do the api call, call its time consuming, but still keep constant check that the images are valid..
<mbruzek> Tug, sorry I was catching up I see that hazmat answered your questions.
<hazmat> it does sort of assume that clients get updated when images are invalid
<hazmat> lazyPower, i just pushed a quick change that gives a nicer error message then just the traceback on api error (ie tell the user what the do said was in error)
<lazyPower> awesome
<lazyPower> do i need to rebase? or are you going to handle that?
<hazmat> lazyPower, new output is http://pastebin.ubuntu.com/7299388/
<hazmat> lazyPower, i'll handle.. i'm adding support to the mini do client for image fetching so i can add a unit test to verify the default image selection, and then merge your mp
<lazyPower> + 1 on the new response message.
<lazyPower> ack. Thanks for taking a look
<hazmat> lazyPower, np.. thanks for the mp
<hazmat> Tug, http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/ssl/service.py
<hazmat> Tug, its used in a few charms for generating server and client certs for mutual auth with tls
<Tug> thank you hazmat
 * hazmat makes a note to add some charm-helper docs
<Tug> yeah it's not so simple but it might not be impossible to adapt it for mongo
<Tug> I'll have a look
<hazmat> lazyPower, yeah.. i was hoping to avoid the image check on every plugin invocation. its only about 1.5s though..  so probably worthwhile to just bake it in.
<lazyPower> hazmat: would probably be prudent to cache the response and expire every N hours?
<lazyPower> unless it reaches a 404 on image creation, then refetch, THEN throw exception?
<hazmat> lazyPower, that sounds pretty reasonable
<hazmat> albeit more complexity
<lazyPower> i agree that it adds complexity but it enhances the UX
<hazmat> lazyPower, the issue is that we get user images/backups as well in that api call
<hazmat> yeah
<lazyPower> yeah, i was considering that.. i wonder if this is where we dont explore an opportunity presented by other mediums, and interrupt with an interactive list and let the user choose
<lazyPower> that deviates pretty far from the vanilla juju ux, but makes sense
<hazmat> argh.. battery dying.. back in a bit
<lazyPower> sinzui: re: https://bugs.launchpad.net/juju-core/+bug/1309805 - shall i re-open the bug with my output or file a new bug?
<_mup_> Bug #1309805: LXC / Local provider machines do not boot in 1.18 / 1.19 series <juju-core:Incomplete> <https://launchpad.net/bugs/1309805>
<fro0g> will juju support spot instances?
<lazyPower> fro0g: on AWS correct?
<sinzui> lazyPower, The bug isn'
<sinzui> t closed. There is no information for en gineer to reproduce the bug and make a fix
<lazyPower> sinzui: ok, i was asking because it looked like a community member was trying to help by adding their output and it wasn't helping.
<lazyPower> I'll attach machine agent logs + commands. I can reproduce this on 2 systems
<sinzui> lazyPower, The other error in the bug is not about tools
<sinzui> thank you lazyPower
<lazyPower> np, thanks for taking a look sinzui
<lazyPower> has anyone else bootstrapped on hpcloud today? Looks like i'm seeing a new bug here as well: https://bugs.launchpad.net/juju-core/+bug/1310645
<_mup_> Bug #1310645: Bootstrapping on HPCloud fails with package Hash Sum Mismatch <hp-cloud> <juju-core:New> <https://launchpad.net/bugs/1310645>
<sinzui> lazyPower, abentley reports the same issue on joyent and azure
<lazyPower> ack. looks like monday hasn't lost its edge
<fro0g> lazyPower: yes
<lazyPower> fro0g: i'm not aware of any active efforts to support spot instances. You can request spot instances and work them into your environment with the manual provider - but i do not believe that juju supports provisioning spot instances as a provider option.
<lazyPower> sinzui: attached logs to https://bugs.launchpad.net/juju-core/+bug/1309805
<_mup_> Bug #1309805: LXC / Local provider machines do not boot in 1.18 / 1.19 series <juju-core:Incomplete> <https://launchpad.net/bugs/1309805>
<lazyPower> i have mbruzek doing the same
<fro0g> lazyPower: ok
<sinzui> thank you lazyPower
<fro0g> lazyPower: thanks!
<lazyPower> Np problem fro0g. if you'd like to see it as a feature, i would open a feature request against juju-core. I can't promise anything above the core-team will take a look at it and triage it appropriately. but you'll be the first to know if it lands by doing so.
<mbruzek> Hey guys it seems I have got past the "pending" problem on Trusty, just now.  Talking about https://bugs.launchpad.net/juju-core/+bug/1309805  lazyPower and cory_fu
<_mup_> Bug #1309805: LXC / Local provider machines do not boot in 1.18 / 1.19 series <juju-core:Incomplete> <https://launchpad.net/bugs/1309805>
<lazyPower> mbruzek: randomly started working or did you do something specific?
<mbruzek> I destroyed my environment, ran the cleanup script that removed lxc containers.  But I think what solved it was running juju sync-tools before my bootstrap
<mbruzek> I am able to get a charm to started this morning.
<lazyPower> ah, excellent. Let me try syncing tools and trying again
<mbruzek> I believe it was due to the juju sync-tools, can lazyPower  or cory_fu  confirm?
<cory_fu> How do I add the dev ppa to get juju 1.19?
<lazyPower> cory_fu: sudo add-apt ppa:juju/devel
<lazyPower> s/add-apt/add-apt-repository
<cory_fu> Ah, right, of course.  Thanks
<mbruzek> I may have claimed victory too soon guys, I got the "ubuntu" charm to start, but my other tests are still in pending.
<mbruzek> Try a charm other than "ubuntu"
<mbruzek> please
<lazyPower> ack, i'll deploy a bundle
<lazyPower> however it appears my ubuntu charm is still pending... and i'm geting the same output in machine-0.log
<mbruzek> I got the ubuntu charm to start...because that one is trusty ?
<lazyPower> mbruzek: it didn't appear to fix it. bundle:mediawiki/single is pending. with the same scrolling log output
<sinzui> mbruzek, lazyPower do either of you specify the default-series in your env?
<mbruzek> no I do not
<lazyPower> sinzui: i have specified precise in my local env config, yes.
<sinzui> I do, I   local:
<sinzui>     type: local
<sinzui>     default-series: precise
<hazmat> lazyPower, fwiw. i eschewed the regex .. http://pastebin.ubuntu.com/7299864/
<lazyPower> hazmat: nice approach. I didn't think to look at the public: flag in the json output
<lazyPower> s/flag/property
<lazyPower> does it match on their single-click-deploy appliations? wrt dokku-wiki and gitlab? That was my other concern was matching on those and potentially launching an application along with juju.
<lazyPower> oh line 10 takes care of that. awesome. great work hazmat
<mbruzek> sinzui, I am setting that and testing it now
<lazyPower> ah i apologize i jumped the gun, i set default-series on everything but local provider.
<mbruzek> sinzui, That seems to work for me
<mbruzek> sinzui, I have found a new problem however, and I need guideance on where to open it against.
<cory_fu> Setting the default series as trusty or precise?
<mbruzek> precise
<mbruzek> I don't think local was uploading the tools for precise
<sinzui> mbruzek, interesting. does : trusty work?
<lazyPower> sinzui: are a lot of these problems related to the fact that we now have 2 LTS's to track? Where default-series wasn't mandatory before, but is now?
<mbruzek> sinzui, I was able to deploy tomcat and ubuntu
<mbruzek> sinzui, Both charms deploy.  tomcat failed in the install hook doing a apt-get update.
<mbruzek> I sshed to ubuntu charm and ran apt-get update and that fails in the same way.
<sinzui> mbruzek, my logs claim they were upload both tools...and since I know I don't have precise, It should have gone to the network to get them...there is no guarantee that the series and archs have the same tools
<lazyPower> oh snap, that did appear to fix it. bundle:mediawiki/single is now deploying as expected.
<sinzui> lazyPower, In my release notes for 1.18.1 I recommended default-series because I was getting a lot of issues that were caused by ambiguous envs
<lazyPower> sinzui:  i remember that email now that you call attention to it. Sorry for not heeding the advice earler. Do we have default-series being added to the boilerplate environment config for new users now? We should probably add a ticket for that if not.
<sinzui> lazyPower, I have not seen it yet. I think it is the sane thing to do.
<mbruzek> sinzui, I believe apt-get update is failing for trusty charms.  What component would that be against?
<lazyPower> mbruzek: is the output the same as i linked you earlier about a hash-sum mismatch?
<mbruzek> Yes
<sinzui> mbarnett, That's ubuntu, not charms or juju
<lazyPower> mbruzek: elmo pushed a fix for that, its propigating - i can confirm it resolved my issues on hp-cloud....
<cory_fu> lazyPower: I am getting the hash-sum mismatch on local, now, yes
<lazyPower> however that was a precise host - do you know if that fix was pushed for trusty as well sinzui?
<sinzui> mbruzek, lazyPower I believe the same package in in both series
<cory_fu> And the local-machine that go the error was precise... Is there a way I can... encourage the propagation?
<lazyPower> cory_fu: speak with a stern voice and shake your finger at it profusely
<cory_fu> lol
<cory_fu> I meant, is there any caching done by the LXC that I could explicitly expire?
<lazyPower> its not an image update, it was a fix server side on the SUM file that apt uses for CRC checking.
<mbruzek> so lazyPower I don't understand how the fix will be delivered.  If it is fixed on the server side how did I get it just now?
<lazyPower> mbruzek: apt fetches the CRC during apt-get update and validates teh package list against that CRC file. It wasn't something that was pushed out to clients. So when it propigates to your apt mirror it will be available to you.
<jose> lazyPower: that bug in wordpress is fixed, MP is up
<tvansteenburgh> when amulet deploys a charm, where does it get the config.yaml from?
<tvansteenburgh> i have a config.yaml that i've updated on disk, but amulet isn't using it
<jose> tvansteenburgh: afaik it's the config.yaml file that's on the charm, but you can specify options by doing d.configure('servicename', {'option': 'value', 'option': 'value'})
<tvansteenburgh> jose: that's what i assumed too, but that's not what i'm seeing.
<jose> tvansteenburgh: oh, I'm not sure if it deploys the local charm, I think it gets it from the charm store
<tvansteenburgh> well i have JUJU_TEST_CHARM set, which is supposed to make it deploy the local copy, but i'm not sure if it's working or not
<tvansteenburgh> i guess i'll continue my debugging there
<jose> for now I suggest you go ahead and set the options where needed
<lazyPower> tvansteenburgh: when you run the test from the command line: eg ./100-deploy - it uses the charm store, if you're using the testing harness charm test -e <environment> it will deploy teh local charm.
<lazyPower> not sure if that helps or answers the question but i thought maybe it would.
<lazyPower> jose: woot. if its in the queue mbruzek will be taking a look at it.
<jose> awesome, then :)
<marcoceppi> jose: lazyPower we're mailing the list in a little bit, but future doc contributions should be done in the src/en/ markdown files
<jcastro> marcoceppi, I am confused
<jcastro> https://github.com/juju/docs/blob/master/src/en/charms-constraints.md
<jcastro> juju bootstrap --constraints "cpu-power=0 cpu-power=0 mem=512M"
<jcastro> is entirely correct in the MD
<jose> marcoceppi: ack, will re-do my stuff and commit as soon as I get home
<lazyPower> marcoceppi: thanks for the update. I'll keep that in mind when accepting PR's.
<jcastro> jose, I'm fixing it now no worries
<marcoceppi> lazyPower: very soon the htmldocs will be gitignored, so it won't be a problem, but fyi until then
<jcastro> but from looking at the markdown source, it appears to be correct?
<marcoceppi> jose: he removed cpu-power from the output
<jose> in university I have only found a workaround to connect to IRC, so I can't do much
<marcoceppi> jcastro: ^^
<lazyPower> jose: sshuttle is your friend
<jose> jcastro: thank you :)
<jcastro> oh oh
<jcastro> so cpu-power=0 doesn't work anymore?
<lazyPower> jcastro: it was duplicated. that was the fix
<jcastro> I could have sworn we used to not have it, and then at some point had to explicitly say 0
<rick_h_> jcastro: there's cpu-power and cpu-cores
<jose> marcoceppi, jcastro: I removed one of the cpu-power=0, it's doubled
<jcastro> oh!
<jcastro> now I see it'
<rick_h_> jcastro: that had two cpu-powers vs one of each
<rick_h_>  juju bootstrap --constraints "cpu-power=0 cpu-cores=0 mem=512M"
<rick_h_> would be the better update perhaps?
<jose> I can confirm "cpu-power=0 mem=512M" works, no need to specify cpu-cores
<jose> lazyPower: sshuttle?
<rick_h_> ok cool
<lazyPower> jose: https://github.com/apenwarr/sshuttle
<jcastro> lazyPower, new PR with fix incoming
<jose> lazyPower: dns servers don't work here and if i set 8.8.8.8 I cannot connect :P
<lazyPower> jose: sshuttle creates a VPN tunnel to your host of choice - so you could route all your traffic around whatever barrier you've got via ssh. Assuming you can ssh out.
<jose> I cannot SSH out :P
<lazyPower> but id ont know what your universities network policy is, so YMMV on if you're being a trouble maker
<jose> nah, sysadminds are good with me messing with networks, I'm going to try with a personal VPN later on
<jose> for now, /me runs to have lunch and take an exam
<jcastro> lazyPower, don't accept my PR yet, let me see what rick's does
<renier> Hi. within a hook, would there be a magic variable that has the name of the charm?
<jcastro> rick_h_, yours is more explicit so I think I'll do that
<rick_h_> jcastro: up to you. I like the shorter, but was trying to get at what I think the original line was meant to be/demonstrate
<lazyPower> ack
<jcastro> yeah longer, but better example
<jcastro> lazyPower, I can confirm rick's modifications to the command still  fires up a t1.micro, so we're all set.
<lazyPower> woo awesome
<jcastro> jose, oh, I only fixed your accepted PR btw
<jcastro> OMG
<jcastro> arosales, did you add the joyent page to every file by hand?
<jose> jcastro: ok, will fix as soon as I'm homr
<arosales> jcastro: no, the make did that for me.
<jcastro> oh ok
<sinzui> lazyPower, mbruzek : I reposted the my default-series recommendations: http://curtis.hovey.name/2014/04/21/working-with-ubuntu-12-04-precise-and-14-04-trusty/
<jcastro> arosales, I did another submission if you want to use that one
<arosales> jcastro: for the joyent provider?
<jcastro> yeah
<lazyPower> sinzui: reblogging now. thanks for this!
<jcastro> arosales, yeah
<jcastro> https://github.com/juju/docs/pull/70
<jcastro> arosales, that's how you add a page, we can either fix yours or accept that one, up to you
<jcastro> <--- lunch
 * arosales looking
<arosales> jcastro: can you help me understand what is incorrect about https://github.com/juju/docs/pull/68 ?
<renier> hi, arosales. think he means that you added the html generated page. I'm guessing only the markdown is needed
<jcastro> yeah, but marcoceppi's .gitignore will fix that
<jcastro> arosales, basically, we don't generate the pages, the build system does
<jcastro> arosales, but we'll fix it so the generated html is ignored
<renier> hey, so anyone using http://cloud-images.ubuntu.com/vagrant/precise/current/precise-server-cloudimg-amd64-juju-vagrant-disk1.box lately? it's giving errors when bootstrapping
<renier> what are people using here for a vagrant jujubox?
<jcastro> renier, I just reported it's brokeness to the maintainer today
<utlemming> renier: do you have a paste for that?
<jcastro> but yeah, something changed in 1.18 that we need to fix and regen the boxes
<jcastro> utlemming, lazyPower was the one trying them out
<jcastro> utlemming, I think for starters it needs to explicitly install juju-local
<jcastro> which was causing some pain
<renier> jcastro, something changed in juju 1.18 you mean, or another piece?
<renier> utlemming, I'll get that for you
<jcastro> renier, I believe 1.18
<renier> ok, yea, juju version 1.18.1 in the box
<lazyPower> utlemming: do you need anything from me re: juju box investiation?
<lazyPower> i can send logs and the vagrantfile if you'd like. what i saw was some missing components, and after installing them manually i ran into other issues with regard to missing a default-series in the environments.yaml (which we sussed out this morning)
<cory_fu> Is it possible for a charm's config-changed hook to tell if it's being run as part of charm upgrade vs just a config-set?
<lazyPower> cory_fu: set a sentinel file in $CHARM_DIR and act on it, when finished acting, rm said sentinel file?
<cory_fu> Not sure I understand
<lazyPower> cory_fu: during upgrade-charm at the end touch $CHARM_DIR/.upgrading
<lazyPower> look for if [ -f $CHARM_DIR/.upgrading]; then   #do stuff rm $CHARM_DIR/.upgrading fi
<lazyPower> theres your idempotency guard against running said code if being called directly after upgrade-charm
<cory_fu> Ah, I see
<arosales> renier: Hello, and thanks for the feedback :-)
<arosales> jcastro: understood, I think all your pull (re: 70) is missing the png
<jcastro> I just fixed it
<tvansteenburgh> bzr branch
<tvansteenburgh> wrong win
<lazyPower> tvansteenburgh: bzr: ERROR: command 'branch' requires argument FROM_LOCATION
<tvansteenburgh> so i finally figured out how to get my amulet tests working
<lazyPower> woo!
<tvansteenburgh> i had to bzr ci my local changes before amulet/juju-deployer will use them
<arosales> jcastro: +1 for your commit then
<marcoceppi> tvansteenburgh: yeah
<tvansteenburgh> seems not good
<marcoceppi> that should be addressed in the next rlease of amulet
<marcoceppi> it's a known issue
<tvansteenburgh> ok cool
<renier> utlemming, https://gist.github.com/renier/11150973
<tvansteenburgh> so now i have a patch for haproxy. do i file a bug against https://launchpad.net/~charmers/charms/precise/haproxy/trunk and push my changes to ~tvansteenburgh/charms/precise/haproxy/trunk ?
<renier> utlemming, that's what I saw upon vagrant up. let me know if you need logs of anything ^
<lazyPower> tvansteenburgh: indeed
<lazyPower> you dont need to specify /trunk as your local branch through, you can name it whatever you like
<tvansteenburgh> lazyPower: thanks
<tvansteenburgh> lazyPower: do i need to subscribe ~charmers to this, or change the status? https://bugs.launchpad.net/charms/+source/haproxy/+bug/1310732
<_mup_> Bug #1310732: Enable sticky sessions <haproxy (Juju Charms Collection):New> <https://launchpad.net/bugs/1310732>
<lazyPower> tvansteenburgh: nah,  create a MP for your branch and it will show up in the REV Q
<tvansteenburgh> anyone want to get on a hangout and discuss a good way to do a master election using peer relations?
<marcoceppi> haha
<marcoceppi> tvansteenburgh: I'd love to, but that's a long hangout
<tvansteenburgh> marcoceppi: i got nothin but time :P
<tvansteenburgh> even if we time-box it, i'd like to hear your thoughts
<tvansteenburgh> i need to find some way to solve my problem, even if it's not proper leader election
<lazyPower> tvansteenburgh: there's an effort to resolve this for cassandra to
<lazyPower> so let me know what your ideas are. I'll be assuming responsibility for that behemoth soon
<renier> jcastro, given juju 1.18 has that problem, should I use juju/stable or another branch? I'm going to try this on a trusty box
<jcastro> renier, trying with 1.16 might help
<renier> jcastro, ok. is that 'juju/unstable'? (not familiar with the branch names?
<renier> I can look it up. don't worry
<jcastro> 1.16 is old stable
<jcastro> 1.18 is current stable
<jcastro> 1.19 is current devel
<renier> ok, thanks
<jose> jcastro: are the juju docs good for translating?
<jose> because if so, I can try and translate them to spanish
<jcastro> jose, gimme a few days to sort out some minor issues first
<jcastro> we need to connect it to launchpad, etc.
<jose> no worries, just ping me once it's good to go and I'll do my best to translate them
<utlemming> er, so why would I be seeing this: "machine-0: 2014-04-21 21:40:53 ERROR juju.provisioner provisioner.go:175 environ provisioner died: failed to process updated machines: cannot start machine 1: no matching tools available" in the logs?
<lazyPower> utlemming: it needs a default-series property in teh environment config
<utlemming> lazyPower: thanks
<lazyPower> anytime
#juju 2014-04-22
<jose> jcastro: so, Nathan Williams deactivated his LP account and hasn't responded to my email, I wonder if it's good to take ownCloud maintainership by now
<bloodearnest> hello charmers - I have a gunicorn MP here: https://code.launchpad.net/~bloodearnest/charms/precise/gunicorn/upgrade-path/+merge/213236
<bloodearnest> it does not appear in the review queue, I think because Michael Nelson +1'ed it, and he is a member of ~charmers (although unsure as to his official status as able to merge)
<bloodearnest> also it fixes 3 minor outstanding MPs, listed on the MP comments
<bloodearnest> so, if some one could land it, that would clear 3 MPs of the charm review queue. As well as including all the fixes
<marcoceppi> bloodearnest: yeah, so because of the way charmers is structured, people like inactive-charmers and former charmers are also in the group, so if a now defunct member of the team +1's a review but doesn't merge it - it gets lost :(
<marcoceppi> bloodearnest: we have plans to address that next week
<bloodearnest> marcoceppi: good to know
<circ-user-kFtev> #juju-core
<jcastro> jose, yeah, might as well
<marcoceppi> mbruzek: can you review/merge this?
<marcoceppi> https://code.launchpad.net/~bloodearnest/charms/precise/gunicorn/upgrade-path/+merge/213236
<mbruzek> marcoceppi, Yes I can
<marcoceppi> mbruzek: thanks
<bloodearnest> mbruzek: thanks. cheat sheet for testing the upgrade path: https://pastebin.canonical.com/108935/
<mbruzek> marcoceppi, bloodearnest There is another gunicorn MP before this one, do either of you know if they depend on each other?
 * marcoceppi heavy shrug
<bloodearnest> mbruzek: this one includes the fixes from all 3 currently in the queue (see comments on MP)
<bloodearnest> mbruzek: 2 of those are duplicate fixs of the same problem, anyway
<mbruzek> bloodearnest, ack
<bloodearnest> mbruzek: this one is actually older than all those 3, but got lost
<bloodearnest> mbruzek: I just updated it today to include all those issues, and fix an issue michael found about not removing the old service
<bloodearnest> mbruzek: you partially reviewed this originally, IIRC, so hopefully is familiar?
<mbruzek> yep, I just need the time to review it.
<mhall119> jcastro: marcoceppi: what am I doing wrong?
<mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/summit/charms/trusty/certification$ sudo juju bootstrap
<mhall119> uploading tools for series [trusty]
<mhall119> Bootstrap failed, destroying environment
<mhall119> ERROR bootstrapping a local environment must not be done as root
<marcoceppi> mbruzek: don't use sudo?
<jose> maybe he's doing local
<marcoceppi> mbruzek: as of 1.17, bootstrap on local no longer requires sudo
<jose> oh
<marcoceppi> mhall119: ^^ jose ^^
<jose> that's news for me :P
<mbruzek> ?
<mhall119> oh, must *not* be done as root
<mhall119> I fail at reading
<mhall119> I assumed it was the old message
<marcoceppi> mhall119: np, it's a depature from the previous functionality
<marcoceppi> mhall119: you may also need to do some permission fixes in you ~/.juju directory
<jcastro> marcoceppi, https://github.com/juju/docs/pull/79
<jcastro> can you confirm the syntax on Note: pls
<jcastro> I fixed the other stuff
<jose> mhall119: make sure to set the default series on your environments.yaml to precise or trusty (I recommend precise) or LXC machine creation will fail
<mhall119> jose: it's set for trusty
<jose> it's up to you :)
<mhall119> well, I'm targetting trusty, so that's what I need :)
<mhall119> 2014-04-22 14:30:37 INFO config-changed OSError: [Errno 2] No such file or directory: '/etc/postgresql/9.1/main/postgresql.conf'
<mhall119> using the IS charm for postgresql on trusty, any idea why I get that error?
<marcoceppi> mhall119: postgresql is 9.3 on trusty
<marcoceppi> mhall119: the charm store charm has already compensated for this
<marcoceppi> fwiw, you can mix series in your deployment. IE, deploy IS postgresql from precise, your charm from trusty
<mhall119> ok, thanks marcoceppi
<mhall119> how do I do that with juju?
<marcoceppi> mhall119: just deploy with the series in the deploy command
<marcoceppi> mhall119: juju deploy cs:precise/postgresql
<marcoceppi> will give you postgresql on precise
<marcoceppi> same with local:
<mhall119> ok
<mhall119> marcoceppi: now I'm seeing a lot of:
<mhall119> machine-0: 2014-04-22 14:55:09 ERROR juju runner.go:220 worker: exited "environ-provisioner": failed to process updated machines: cannot start machine 1: no matching tools available
<mhall119> machine 1 is my precise target
<marcoceppi> mhall119: ah, local provider doesn't upload multiple tool sets :\
<mhall119> so I can't mix and match trusty and precise with the local provider?
<marcoceppi> doesn't seem so, there might be a beter way
<mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/summit/current_work/summit$ juju deploy cs:postgresql postgresql
<mhall119> ERROR charm not found: cs:trusty/postgresql
<mhall119> what am I doing wrong now marcoceppi ?
<lazyPower> mhall119: There isn't a trusty version of the charm in the store.
<lazyPower> mhall119: you can do some testing locally if you have charm-tools installed.  charm-get postgresql  in a trusty directory in your local c harm repository
<lazyPower> then deploy from there.
<mhall119> marcoceppi said the charmstore charm was ready for trusty :(
<lazyPower> marcoceppi: has postgres been promulgated for trusty? i dont see it... but that doesn't mean I missed it.
<lazyPower> s/missed it/didn't miss it/
<lazyPower> mhall119: we're in a meeting, and i'll follow up once we're out.
<mhall119> lazyPower: I'm jumping on a call now myself, so whenever you're free
<mhall119> thanks
<jose> hey guys, I'm having some troubles with charm helpers, http://paste.ubuntu.com/7307816/ is giving me ImportError: No module named lib.charmhelpers.contrib
<mhall119> lazyPower: marcoceppi: one more issue, though postgresql charm didn't work, my django and gunicorn charms say they started, but I can't connect: http://paste.ubuntu.com/7307845/
<mhall119> not even to get a django error message
<lazyPower> mhall119: i'm fairly certain we haven't reached those charms in the audit. It may be experiencing silent failure on the charm. Without interfacing directly with that deployment i'm not sure.
<marcoceppi> hey stub, is postgresql ready for trusty? Should I test for compat?
<bigtree> juju bootstrap is timing out when using /etc/rc.local to set up a raid0 and mount it...the script is running fine but juju hangs on 'attemping to connect' when it finishes...any ideas?
<renier> bigtree, I read somewhere that the firewall could interfere with juju. I had to disable it `sudo ufw disable` in my trusty vagrant box.
<bigtree> @renier, thanks -- I added a 'sleep 60' to the beginning of the script ....that solved the problem but I'm not sure why
<Tug> how can I force a unit to stop when I have an error ?
<Tug> I ran juju destroy service myservice
<Tug> as it was already in an error state it could not stop
<Tug> I ran juju resolved myservice/x
<Tug> I didn't want to run debug-hooks for each unit (because I just wanted to stop them) so I tried several times
<Tug> now I have an error if I try debug-hooks: ERROR cannot set resolved mode for unit "shard1/1": already resolved
<Tug> is there a way to force this? I would prefer not destroying the environment nor the machines
<avoine> Tug: not that they are  in the resolved status you can't destroy them?
<Tug> they are not in resolved status, resolved brought them back in error state
<Tug> (because I did not run juju debug-hooks to return 1)
<Tug> alright
<Tug> I just needed to be patient
<Tug> they just got removed
<Tug> :)
<bigtree> Using juju bootstrap on MaaS is successful, but when trying to add units/other machines juju hangs on login and the juju agent is never started.
<bigtree> Anyone have any ideas?
<bigtree> Does juju prevent rc.local from running?
<marcoceppi> mbruzek cory_fu: https://github.com/marcoceppi/amulet/pull/28#issuecomment-41081228
<mbruzek> marcoceppi, we both commented on this.  The changes are safe to make
<tvansteenburgh> when i terminate a unit in a peer relationship, is it possible to determine in the relation-departed hook which of the two peers is going away?
<hedin> hey, I just installed a 14.04 server and put juju-quickstart on it but when I try to run it, I only get this traceback https://dpaste.de/CEh4
<rick_h_> hedin: looking
<hedin> rick_h_: thanks :)
<rick_h_> hedin: yea, that's odd and not seen that. Filing a bug and will try to replicate.
<rick_h_> hedin: ever do much python development?
<rick_h_> hedin: I wonder if getting quickstart from another source has the same issue.
<rick_h_> hedin: https://bugs.launchpad.net/juju-quickstart/+bug/1311321 at the moment
<_mup_> Bug #1311321: ascii can't decode error in 14.04 server install <juju-quickstart:Confirmed> <https://launchpad.net/bugs/1311321>
<Tug> is it possible to run a hook again, even when the status is `started` ?
<hedin> rick_h_: no, just a bit of scripting...
<rick_h_> hedin: ok, I've filed the bug and will work on seeing if I can replicate in a VM
<tvansteenburgh> hedin: curious what the output of `echo $LANG` is on your juju-quickstart machine?
<hedin> $ echo $LANG
<hedin> en_GB.UTF-8
<hedin> I have installed ubuntu-14.04 LTS server on top of proxmox... After ubuntu installation, with only openssh-server selected, I ran:
<hedin> sudo apt-get update && sudo apt-get upgrade
<hedin> rebooted and sudo apt-get install juju-quickstart
<hedin> and then juju-quickstart, as you saw in the dpaste
<hedin> hmm... locale might give an answer... https://dpaste.de/qCeb
<tvansteenburgh> try this:
<tvansteenburgh> $ python -c "import locale; locale.setlocale(locale.LC_ALL, ''); print locale.getlocale()[1]"
<hedin> tvansteenburgh: output: https://dpaste.de/oO2v
<hedin> there is no locale.gen file in /etc/ on 12.04 and debian, I just uncomment the fo_FO.UTF-8 line and run locale-gen
<tvansteenburgh> hedin: i don't follow...you fixed it?
<rick_h_> hedin: this is 12.04? I thought you were on 14.04?
<hedin> it is 14.04
<hedin> Linux ubuntu 3.13.0-24-generic
<tvansteenburgh> i would try:
<tvansteenburgh> sudo locale-gen en_GB.UTF-8 fo_FO.UTF-8
<tvansteenburgh> dpkg-reconfigure locales
<hedin> tvansteenburgh: that fixed it, now juju-quickstart runs
<tvansteenburgh> \o/
<hedin> thanks for the help :)
<hedin> maybe there should be added a check if locale's are configured ?
<tvansteenburgh> hedin: you're welcome, of course
<rick_h_> thanks tvansteenburgh, notes added to the bug. We'll look into a good way to watch for that
<tvansteenburgh> rick_h_: sure thing
 * tvansteenburgh goes back to minding his own business
<james_w> hi, I have an environment using lxc on trusty, and machine 1 doesn't seem to be starting. Where would I find the logs for that machine?
<james_w> ~/.juju/<env>/log only has machine-0.log
<james_w> (and a couple of other files)
<tvansteenburgh> james_w: any clues in the all-machines.log ?
<james_w> ERROR juju runner.go:220 worker: exited "environ-provisioner": no state server machines with addresses found
<james_w> that's the only error-looking thing
<james_w> to my eye at least
<tvansteenburgh> james_w: using local provider?
<james_w> yeah
<james_w> https://bugs.launchpad.net/juju-core/+bug/1248800 has that message
<_mup_> Bug #1248800: worker/provisioner missed signal to start new machine <deploy> <hs-arm64> <juju-core:Triaged> <https://launchpad.net/bugs/1248800>
<james_w> and says "restarting the provisioner fixed the problem"
<james_w> how would I try that?
<tvansteenburgh> i would just destroy the environment and start over
<james_w> tried that
<james_w> I can try again
<tvansteenburgh> :(
<bloodearnest> james_w: do you have juju-mongodb installed?
<james_w> yeag
<james_w> yeah
<james_w> re-bootstrapped and the same message trying to deploy cs:ubuntu
<bloodearnest> james_w: do you have default-series: specified in your env config?
<james_w> no
<james_w> only type and admin-secrey
<james_w> secret
<bloodearnest> james_w: when you bootstrap, does it say "uploading tools [trusty, precise]" or similar?
<james_w> [trusty[
<bloodearnest> so, not sure it this is the issue here, but it will be an issue with some charms, but you need default-series: precise to get juju to upload precise tools
<james_w> http://paste.ubuntu.com/7310317/ is the all-machines.log
<jose> jcastro: hey, the 'Please remove jenkins from trusty' bug, would adding the source specified on that page you mentioned and apt-getting work?
<jcastro> yes
<jcastro> the charm needs to get from their repo
<jcastro> since it's not in ubuntu
<jose> ok, I'll see if I can work in getting that fix into the queue
<lazyPower> Hey so, question
<lazyPower> with our current juju boxes not being in alignment with the tutorial that we have on the docs, we should probably temporarily remove that doc section? There's not a planned fix on the horizon for the juju vagrant boxes - pending additional work from hazmat from what i observed earlier today
<lazyPower> s/work/assessment
<lazyPower> jcastro: ^
<jcastro> lazyPower, I agree
<lazyPower> ok just so i'm on the right path, i need to make that fix in the MD docs in the /EN branch?
<jcastro> yes
<jcastro> the instructions are up to date
<jcastro> check contributing.html
<lazyPower> thanks! i'll mmake that PR before i EOD for the morning.
<jcastro> on the live website
<lazyPower> wow that came out all janky. I'll make a PR for first thing in the morning.
<jose> how should I specify that a charm can relate to *all* interfaces?
<jose> (in the metadata.yaml)
<lazyPower> jose: what do you mean?
<jose> lazyPower: I have the pagekite charm and I want it to be able to relate to literally any other charm
<lazyPower> jose: well, thats tricky. there's no catch-all.
<jose> oh
<lazyPower> my suggestion would be to either define an interface for pagekite, or impelement the interfaces that pagekite should work with, eg: http, reverseproxy, et al.
<lazyPower> and go from there. breaking off the expected workload in chunks after its been verified to work. If you do that you'll take care of most of the charms you're concerned with supporting, and users that want something specific can open a feature request
<james_w> jose: juju-info I think is the name of the minimum interface supported by every charm
<jose> hmm, ok
<jose> I'll work in that one tomorrow I think, apparently I have to do some homework today :)
<lazyPower> james_w: while that works, it only exposes the remote IP address. I'm not sure how pagekite works but i assume it requires more than just the ip?
#juju 2014-04-23
<hazmat> lazyPower, well i wasn't able to reproduce the issue utlemming was having
<hazmat> but i was using trusty.. i'll try again with precise
<lazyPower> hazmat: did the redirect daemon work ootb?
<hazmat> lazyPower, the underlying symptom was exception on connection
<hazmat> lazyPower, which didn't occur
<lazyPower> Hmmmm.. curious
<jose> negronjl: pushed fixes+additions to seafile, if you could review them
<jose> sorry for the branch name being a little bit... long
<negronjl> jose: no worries ... I'll review a bit later tonight
<jose> thanks :)
<Tug> how can I access juju's bootstrap env ?
<Tug> i'd like to hack into the db and remove an entry :)
<ghartmann> do we already have any clue why add-machine doesn't work for local providers anymore ?
<james_w> hi
<james_w> I'm unable to deploy any charms to a local environment on my trusty box
<james_w> http://paste.ubuntu.com/7310317/ is all-machines.log
<james_w> anyone have any ideas of how to debug further?
<cory_fu> james_w: I believe that's the error I ran into a few days ago.  Try adding "default_series: precise" to your local entry in environments.yaml
<cory_fu> Sorry, default-series: precise
<james_w> cory_fu: no change
<cory_fu> Hrm.  mbruzek, tvansteenburgh: Do you recall what ended up being the fix for the environ-provisioner error on LXC?
<mbruzek> Yes
<mbruzek> setting default series and cleaning up the local env.
<james_w> "cleaning up"?
<cory_fu> Oh, let me pastebin the cleanup script
<mbruzek> Just as econd
<cory_fu> http://pastebin.ubuntu.com/7314725/
<cory_fu> You may need to change line 21 to: sudo rm -rf ~/.juju/local
<mbruzek> http://paste.ubuntu.com/7314726/
<bloodearnest> mbruzek: gunicorn readme fix:
<bloodearnest> https://code.launchpad.net/~bloodearnest/charms/precise/gunicorn/fix-readme/+merge/216836
<cory_fu> james_w: Also, do you have encrypted home dirs enabled?  If so, you may need to set the root-dir in the local env to outside of the home dir (e.g., /var/juju, as in my cleanup script)
<mbruzek> I saw that bloodearnest thank you.
<james_w> I don't
<cory_fu> Ok, then mbruzek's version is what you want, then
<cory_fu> james_w: NB: You should run the cleanup script *after* doing juju destroy-environment --force -y local
<cory_fu> And you will get several "file not found" responses from the script, which is fine
<james_w> ok, machine 0 is reporting:    agent-state: down
<james_w> now I did deploy ubuntu and it has agent-state: started
<james_w> and I still have the environ-provisioner message
<james_w> cory_fu: any other ideas?
<cory_fu> Hrm.  Other than trying juju destroy-environment --force -y local ; clean-lxc ; juju bootstrap a couple more times, not really.  :-/
<cory_fu> What versions of juju and juju-local do you have?
<james_w> hmm
<james_w> they weren't installed
<james_w> trying again after installing them
<james_w> 1.18.1-0ubuntu1
<cory_fu> Ok, that's the current version
<james_w> still looks to be the same
<james_w> https://bugs.launchpad.net/juju-core/+bug/1248800 mentions the error and says "restarting the provisioner fixed it"
<james_w> how would I try that?
<_mup_> Bug #1248800: worker/provisioner missed signal to start new machine <deploy> <hs-arm64> <juju-core:Triaged> <https://launchpad.net/bugs/1248800>
<cory_fu> Hrm.  I'm really not sure
<james_w> I can't get my work done without a working environment
<james_w> I guess I could try deploying to ec2
<cory_fu> I think the provisioner should be restarted when you destroy-env and bootstrap
<mbruzek> james_w, Are you still having problems with juju and local?
<james_w> mbruzek: yep
<mbruzek> Can you pastebin the error you are seeing or your log file?
<james_w> mbruzek: http://paste.ubuntu.com/7315103/ is the all-machines.log
<mbruzek> OK james_w try this please
<mbruzek> juju destroy-environment -e local -y --force
<mbruzek> (run clean script)
<mbruzek> juju sync-tools
<mbruzek> juju bootstrap -e local
<mbruzek> (with the --upload-tools flag)
<mbruzek> james_w, I am assuming your ~/.juju/environments.yaml file already has the default-series: set to something valid.
<james_w> mbruzek: precise
<mbruzek> james_w, Any progress?
<james_w> mbruzek: still looks the same
<mbruzek> james_w, What is this bit about you not having juju-local installed?  Was this working at some point, or is this your first attempt at getting juju local running?
<james_w> mbruzek: first attempt with juju-core
<mbruzek> james_w, Can you describe what is not working for you?  The log on pastebin looks mostly OK.
<james_w> mbruzek: no services start
<mbruzek> Are they all stuck in pending?
<james_w> http://pastebin.ubuntu.com/7315210/
<lazyPower> james_w: is your LAN using the 10.0.3.0 segment?
<qhartman> I'm working on getting a MAAS / Juju deployment setup to manage an Openstack cluster, and I've gotten to the point that I have Juju basically going, but any host I add gets stuck in "pending".
<qhartman> oh hey, looks like james_w is facing something similar maybe...
<james_w> lazyPower: 10.0.1
<lazyPower> james_w: ok, i ask because ip collision will prevent the lxc containers from booting
<james_w> qhartman: mine is with lxc
<qhartman> and any nodes I try to destroy get stuck in "dying".
<qhartman> james_w, ah
<lazyPower> if you're not using 10.0.3.0 you'll be fine.
<lazyPower> for that issue anyway
<lazyPower> qhartman: logs?
<mbruzek> qhartman do you have a pastebin of the logs?
<qhartman> lazyPower, Love to. Which ones?
<lazyPower> all-machines / machine-0
<qhartman> rgr
<mbruzek> ~/.juju/local/log/all-machines.log
<lazyPower> mbruzek: thats fine for lxc, but he's working with maas.
<lazyPower> s/he's/qhartman
<mbruzek> Thanks lazyPower
<lazyPower> np bruddah
<qhartman> There's machine-0.log: 2014-04-22 23:00:34 INFO juju.cmd supercommand.go:297 running juju-1.18.1-trusty-amd64 [gc]
<qhartman> 2014-04-22 23:00:34 INFO juju.cmd.jujud machine.go:127 machine agent machine-0 start (1.18.1-trusty-amd64 [gc])
<qhartman> 2014-04-22 23:00:34 DEBUG juju.agent agent.go:384 read agent config, format "1.18"
<qhartman> 2014-04-22 23:00:34 INFO juju.cmd.jujud machine.go:155 Starting StateWorker for machine-0
<qhartman> 2014-04-22 23:00:34 INFO juju runner.go:262 worker: start "state"
<qhartman> 2014-04-22 23:00:34 INFO juju.state open.go:81 opening state; mongo addresses: ["localhost:37017"]; entity "machine-0"
<qhartman> 2014-04-22 23:00:34 INFO juju runner.go:262 worker: start "api"
<lazyPower> qhartman: pastebin plz
<qhartman> 2014-04-22 23:00:34 INFO juju apiclient.go:114 state/api: dialing "wss://localhost:17070/"
<qhartman> 2014-04-22 23:00:34 INFO juju runner.go:262 worker: start "termination"
<qhartman> 2014-04-22 23:00:34 ERROR juju apiclient.go:119 state/api: websocket.Dial wss://localhost:17070/: dial tcp 127.0.0.1:17070: connection refused
<qhartman> 2014-04-22 23:00:34 ERROR juju runner.go:220 worker: exited "api": websocket.Dial wss://localhost:17070/: dial tcp 127.0.0.1:17070: connection refused
<qhartman> 2014-04-22 23:00:34 INFO juju runner.go:254 worker: restarting "api" in 3s
<qhartman> 2014-04-22 23:00:34 INFO juju.state open.go:119 connection established
<qhartman> 2014-04-22 23:00:34 DEBUG juju.utils gomaxprocs.go:24 setting GOMAXPROCS to 16
<qhartman> 2014-04-22 23:00:34 INFO juju runner.go:262 worker: start "instancepoller"
<qhartman> 2014-04-22 23:00:34 INFO juju runner.go:262 worker: start "apiserver"
<qhartman> 2014-04-22 23:00:34 INFO juju runner.go:262 worker: start "cleaner"
<qhartman> 2014-04-22 23:00:34 INFO juju runner.go:262 worker: start "resumer"
<mbruzek> qhartman please use pastebin
<qhartman> 2014-04-22 23:00:34 INFO juju.state.apiserver apiserver.go:43 listening on "[::]:17070"
<qhartman> 2014-04-22 23:00:34 INFO juju runner.go:262 worker: start "minunitsworker"
<qhartman> 2014-04-22 23:00:37 INFO juju runner.go:262 worker: start "api"
<qhartman> 2014-04-22 23:00:37 INFO juju apiclient.go:114 state/api: dialing "wss://localhost:17070/"
<qhartman> 2014-04-22 23:00:37 INFO juju.state.apiserver apiserver.go:131 [1] API connection from 127.0.0.1:56002
<qhartman> 2014-04-22 23:0
<qhartman> oh balls, sorry
<qhartman> yeah
<qhartman> there: http://pastebin.com/44wjjRvA
<qhartman> though I had copied the URL when I hadn't
<lazyPower> qhartman: on the machine that's in 'pending' is this machine registered in the maas region controller?
<qhartman> yup
<qhartman> and when I juju-created it it correctly started up and did the fastpath install
<lazyPower> ok
<qhartman> and then... nothing
<lazyPower> i'm curious because the logs state mysql has no node associated
<lazyPower> line 57
<qhartman> right, I've been futzing around with trying to add/ remove serivces and machines since then
<qhartman> and a lot of that is weirdly not reflected in that log
<qhartman> probably a good place to start would be how to clean up this "dying" machine-1 so I can start again from a clean-ish spot
<lazyPower> juju remove-unit <unit #> --force
<qhartman> aha
<lazyPower> er
<lazyPower> where am i this morning
<qhartman> heh
 * lazyPower needs coffee
<qhartman> so say we all
<lazyPower> juju destroy-machine <machine #> --force
<qhartman> right
<lazyPower> remove-unit :P hah
<lazyPower> i'm clearly working on something else with that command
 * lazyPower whistles innocently
<qhartman> heh
<qhartman> alright, now it says it's dead with a pending agent-state
<qhartman> aaand, gone
<qhartman> ok
<lazyPower> boom
<qhartman> alright "juju deploy mysql", it seems to have grabbed the same machine it used for machine-1 before, but now it's calling it machine-3
<qhartman> everything is "pending....
<lazyPower> right juju will assign its own alias to the machine
<lazyPower> it increments +1
<lazyPower> for each
<qhartman> right, makes sense
<qhartman> is there any activity I can look for on the machine?
<qhartman> the machine-0 log hasn't changed much
<qhartman> here are the new lines: http://pastebin.com/wFyGGTYF
<lazyPower> did the node ever get bootstrapped into juju? when i boot my kvm maas units, it takes ~ 2 minutes for them to come online and register with the juju bootstrap node
<lazyPower> also, can your maas units reach the bootstrap node?
<qhartman> they should be able to. Do they try to reach it by IP or name?
<lazyPower> most of my help will be anecdotal qhartman, i've got a physical hardware machien as my region cluster, and all my maas nodes are KVM
<lazyPower> it tries by name first, then by ip
<qhartman> ok
<qhartman> yeah, I'm trying to set things up so everything is multi-homed which seems to be confusing things somewhat.
<qhartman> so, "juju bootstrap" from my MAAS controller spun up and bootstrapped the juju node machine-0
<qhartman> but I didn't do any "bootstrap" on any other machine.
<lazyPower> you dont need to
<lazyPower> and your juju bootstrap controller came online right?
<lazyPower> its up, running, and communicating with you  - i guess thats the case since you could issue a juju deploy mysql
<lazyPower> hummm
<qhartman> I guess so, here's my juju status: http://pastebin.com/D25ANbyw
<qhartman> yeah, everything for machine-0 seems right as far as I can tell
<lazyPower> it seems like the agent isn't doing what it needs to.
<qhartman> right
<qhartman> how does that get installed?
<qhartman> does machine-0 try to ssh as some user over to it or something?
<lazyPower> ^
<lazyPower> during cloud init it pushes the proper ssh keys to the node
<lazyPower> then the bootstrap node ssh's into it and kicks off the agent installation
<qhartman> hm, ok
<lazyPower> i'm thinking this may be wrt the tools
<lazyPower> try donig a juju sync-tools and retry the provisioning
<qhartman> destroy the service and the machine, and remove and re-add them to maas? All the way to the beginning?
<qhartman> I see the ubuntu user on machine-3 has a bunch of juju keys in it's authorized_keys
<qhartman> so that seems to have worked....
<qhartman> I wonder if the keys got out of sync somewhere...
<lazyPower> its doubtful but possible.
<qhartman> ah, I think I figured it out
<qhartman> the routing is messed up on machine-3, it's default path is super wrong
<qhartman> so it can't download the tools from canonical
<qhartman> ok
<qhartman> whee
<qhartman> now I have somewhere to go
<qhartman> Thanks for the help
<qhartman> I'll be back if I hit another wall.
<qhartman> :D
<lazyPower> np qhartman, glad that helped
 * qhartman enters lurk mode
<mhall119> marcoceppi: can I deploy both precise and trusty units in Canonistack?
<mhall119> while I wait for a trusty-enabled postgresql charm
<james_w> mbruzek: found the problem. I had to disable ufw on my hos
<james_w> host
<james_w> mbruzek: now the units start
<james_w> but the unit agent fails with
<mbruzek> james_w, that is GREAT
<james_w> 2014-04-23 16:47:19 ERROR juju runner.go:220 worker: exited "uniter": ModeInstalling cs:precise/ubuntu-4: git init failed: exec: "git": executable file not found in $PATH
<james_w> is that part of the 'tools'
<mbruzek> Thanks for sharing that
<james_w> or a problem with the charm?
<mbruzek> Looks like git is not installed in the charm
<james_w> there's also 2014-04-23 16:49:35 WARNING juju.worker.uniter.charm git_deployer.go:200 no current staging repo
<mbruzek> james_w, Did you get the 1.18 to work or did you update to the latest version?
<james_w> mbruzek: I upgraded
<james_w> mbruzek: not to say 1.18 wouldn't have worked with the disabled firewall
<mbruzek> Based on your statement I suspect that the ufw could have been disabled with 1.18
<james_w> the git thing is because the package install during cloud-init failed
<james_w> apparently because there's something wrong with dns in the container
<qhartman> lazyPower, I ended up needing to nuke and pave the host that was formerly machine-3, but adding the ip-forwarding on the MAAS controller so the route works ended up allowing "juju deploy" to work
<qhartman> I now have nodes joining the juju and deploying services
<qhartman> \o/
<lazyPower> qhartman: awesome!
<lazyPower> glad you got it sorted :)
<james_w> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1205086 is the dns problem
<_mup_> Bug #1205086: lxc-net dnsmasq --strict-order breaks dns for lxc non-recursive nameserver <libvirt (Ubuntu):New> <lxc (Ubuntu):New> <https://launchpad.net/bugs/1205086>
<qhartman> calamity! Trusty doesn't have a nova-volume charm!
<qhartman> is that by design?
<lazyPower> qhartman: there's an audit going on for charms to have series promotion
<qhartman> which means this doc doesn't apply correctly: https://help.ubuntu.com/community/UbuntuCloudInfrastructure . Is there a version that has been updated for Trusty? I have not found one.
<lazyPower> right now, you're best bet is to target precise - if you need a trusty charm, you can be one of the brave beta users and just specify trusty, deploy, and pray it works correctly
<lazyPower> most of the charms will be ok, but there are some discrepancies between precise => trusty deployments.
<qhartman> right
<qhartman> so, I'm on trusty, so to deploy the precise charm I use "juju deploy cs:precise/nova-volume"?
<lazyPower> so in order for you to do that, you need to create a local charm repository, and charm-get the charm you want to deploy on trusty into the trusty series directory
<qhartman> ah, ok
<lazyPower> then juju deploy local:trusty/nova-volume --repository=../../ (from within the nova charm dir)
<lazyPower> but be warned, if it blows up
<qhartman> yeah
<lazyPower> as of right now, you're accepting a backwoods warranty. if it blows up in half, you own both halves.
<qhartman> I get to keep all the pieces
<lazyPower> :P
<qhartman> well, this is testing deployment anyway
<lazyPower> your feedback will be gold
<lazyPower> if you run into any caveats make sure you ping the juju list with them
<qhartman> once I get a feel for things I'm going to kill it and re-deploy anyway
<qhartman> will do
<lazyPower> thanks qhartman
<qhartman> sure thing
<qhartman> What's the state of the ceph charms on Trusty? Big picture I'm planning on using that for storage on this deployment
<lazyPower> not sure. check the charm store
<qhartman> k
<lazyPower> i think most if not all of the openstack charms have trusty releases
<lazyPower> i know they were sprinting to get them pushed day of trusty release.
<flohack> Hey, am I doing something wrong or is there simply no charm for memcached / wordpress on trusty?
<lazyPower> but i'm not sure of anything beyond that, i've been busy with other areas of focus
<qhartman> flohack, no trusty charm that I see
<lazyPower> flohack: there is not. The trusty charms are part of an audit, and slow going.
<qhartman> lazyPower, sure.
<lazyPower> if you want to be a +1 reviewer to charms in the trusty series, we'd appreciate the extra hands on deck, and possible amulet test submissions
<flohack> lazyPower: ok, thanks! anything I could do about it? Like copy it locally, try and see if it works when modifying the series!?
<lazyPower> flohack: theres 2 requirements you'll need to be aware of. it has to pass a full blown charm review, and contain deployment tests (amulet flavored is preferrable)
<lazyPower> but the caveat here is series support in amulet is pending a merge last i checked. so it may blow up on you attempting to write tests
<lazyPower> marcoceppi: any updates on that to speak of?
<lazyPower> he's at lunch, so responses may be latent.
<marcoceppi> lazyPower: what's the tl;dr?
<flohack> lazyPower: Ok, I'm not familiar with writing/testing/auditing charms so far, I'm a professional dev though, so maybe with a few pointers, I'll be able to contribute!?
<lazyPower> marcoceppi: trusty / series support in amulet.
<lazyPower> flohack: i ran a charm school yesterday on it. let me fish up the link
<marcoceppi> lazyPower: that will be fixed in 1.5, to be released early next week
<lazyPower> flohack: https://www.youtube.com/watch?v=2Y1MiSPox5I#t=31
<lazyPower> here's how to get acquainted with the rev Q, and there is a docs page on writing amulet tests https://juju.ubuntu.com/docs/tools-amulet.html
<flohack> lazyPower: anything to read? I so much quicker when reading compared to watching a video ;-)
<lazyPower> flohack: https://juju.ubuntu.com/docs/reference-reviewers.html
<lazyPower> flohack: if you start doing reviews / audit work - any questions should go here or to the mailing list. We'll be more than happy to help support you in your efforts
<flohack> lazyPower: Great, so for starters, how do I copy the precise charm for memcached to a local repository?
<flohack> is there a git to clone?
<hazmat> flohack, bzr branch lp:charms/precise/memcached
<flohack> cheers mates! I'll take it from there and get back with questions!
<lazyPower> actually use charm-get from charm-tools
<lazyPower> its a wrapper, but keeps things consistent
<kiko> hey there
<kiko> I'm trying to start up an lxc instance and I'm getting this error
<kiko>     agent-state-info: '(error: container failed to start)'
<kiko> how can I debug what is going wrong?
<kiko> this is on 1.18.1.4
<kiko> is there a limit to the number of containers I can run?
<kiko> mm
<lazyPower> kiko: nope, have you put in a default-series directive in your environments.yaml?
<lazyPower> kiko: the only limit superimposed by lxc is dependent on your physical hardware, if you go spinning up crazy containers with crazy processes, it'll cause other unpredictable behavior due to being out of resources. But juju / lxc superimpose no limit to the quantity of machines you can spin up.
<kiko> lazyPower, I haven't put default-series in my environments
<kiko> and I already have a bunch of working containers
<kiko> it seems like the new way to run containers isn't working
<kiko> hmm
<kiko> okay
<kiko> so it seems like the container actually DOES run
<kiko> hmm
<kiko> lazyPower, so here's what I am seeing
<kiko> lazyPower, the container is running (i.e. lxc-console --name gets to it)
<kiko> lazyPower, juju status says "container failed to start")
<kiko> the rest looks all normal
<lazyPower> any notice in the logs about a tools mismatch?
<lazyPower> any possible IP Collisions?
<kiko> lazyPower, well, which log should I look at? oddly, there is no log in /var/log/juju-juju-local for that machine
<lazyPower> should be in $HOME/.juju/local/logs
<kiko> ah, there is now
<lazyPower> the tools mismatch log message scrolls in machine-0.log
<lazyPower> and can be corrected with sync-tools
<kiko> lazyPower, the word "mismatch" does not appear in machine-0.log
<kiko> lazyPower, is machine 0 special when using the local provider?
<kiko> I notice it's set to localhost
<lazyPower> It is. machine-0, your bootstrap node, is the parent machine warehousing the lxc containers
<lazyPower> however we are running to the end of my knowledge of common problems with LXC - if its not ip collision or tools/series.
<kiko> that's very interesting! is it documented anywhere?
<lazyPower> which aspect of the output? that the bootstrap node is localhost?
<kiko> hmmm
<kiko> I guess, yes, or that the bootstrap node's logs are interesting :)
<kiko> lazyPower, aha, machine-0's log has a lot of interesting stuff
<kiko> 2014-04-23 19:09:34 DEBUG juju.environs.simplestreams simplestreams.go:490 fetchData failed for "http://192.168.99.5:8040/tools/streams/v1/index.sjson": file "tools/streams/v1/index.sjson" not found
<kiko> 2014-04-23 19:09:37 WARNING juju.worker.instanceupdater updater.go:231 cannot get instance info for instance "": no instances found
<jose> is there any way to hardcode the type of machine juju deploys on EC2? it's very annoying finding out that even though you set the constraints it deploys a machine bigger than what you were expecting
<lazyPower> kiko: thats.. not good. it cant find the simplestreams data
<lazyPower> marcoceppi: simplestreams on juju-local is updated when you run sync-tools no?
<marcoceppi> lazyPower: kiko local provider doesn't use simplestreams
<marcoceppi> last I checked
<lazyPower> wat - i thought /tools/streams - was in fact simplestrams
<marcoceppi> that DEBUG is a red herring
<lazyPower> maybe my terminology is wrong
<lazyPower> bah
<lazyPower> thanks for the clarification
<marcoceppi> kiko: is 192.168.99.5 your machine?
<kiko> marcoceppi, yes
<kiko> marcoceppi, good to hear that simplestreams is a red herring
<marcoceppi> kiko: I might be wrong though, local has changed a lot.
<marcoceppi> What version is this?
<kiko> marcoceppi, 1.18.1.4
<marcoceppi> kiko: can you destroy then re-run with the --debug flag?
<kiko> marcoceppi, no, this is in production
<kiko> oh
<kiko> you mean destroy the machine?
<kiko> I have already
<kiko> many times
<marcoceppi> local provider in production?
<kiko> marcoceppi, sure, I hear that's the way to do it :)
<renier> 'Fix genghisapp charm directory name' https://github.com/juju/docs/pull/84
<qhartman> so I have a charm that failed to deploy, and destroying it doesn't seem to work.
<qhartman> How can I force that to happen (no --force it seems) and/or force the charm to be redeployed on the node to see if I've fixed the problem that caused it to fail?
<qhartman> If I force destroy the machine, then I can destroy the services that are in a bad state.
<jose> qhartman: you need to do 'juju resolved unitname/#' first
<jose> as juju is event-based, it needs to be taken out of the error state before continuing with the next action
<qhartman> jose, oooooh, that makes sense
<qhartman> cool. Is this sort of usage stuff documented anywhere? I've found lots of howto-style docs, but very little reference for juju.
<jose> well, we have docs at juju.ubuntu.com/docs
<jose> but I'm not sure if that specific point is documented, should be
<qhartman> ok
<qhartman> yeah, I've been poking around on there
<jose> https://juju.ubuntu.com/docs/charms-destroy.html#life:-dying
<jose> there it is :)
<qhartman> and this sort of middle-ground stuff isn't covered well, or I'm just not seeing it. Lots of bootstrappy stuff, and lots of dev oriented stuff though
<qhartman> awesome
<qhartman> I must just need to learn how to find stuff here
<lazyPower> qhartman: feedback on the list to your experience with the docs is gold as well :)
<qhartman> lazyPower, I'll add that to the list
<jose> if you have any questions you're welcome to just ask around here :)
<qhartman> lazyPower, I posted a couple items a few minutes ago
<qhartman> jose, yup, and gotten lots of help so far
<jose> qhartman: btw, nova-volume has not been promulgated to trusty yet
<qhartman> jose, so, how did you find that page? I don't see it in an index anywhere and a couple of intentionally naive but sensible searches didn't turn it up
<jose> juju.ubuntu.com/docs, on the sidebar, the 'Destroying Services' page, and read until the end of it
<qhartman> jose, yup, I knew I was breaking ground somewhat, was mostly hoping that my notes could help someone else along,
<qhartman> jose, aha, I see it now
<jose> I think the search looks for articles on the blog (if there's any)
<qhartman> yeah, it doesn't seem to search the docs at all
<zdr> What exactly is juju-mongodb for? Is it to enable SSL? What else? And why on Trusty only?
<lazyPower> zdr: juju-mongodb is the tweaked and tuned package for mongodb's inclusion into teh juju ecosystem.
<lazyPower> mongodb is the storage mechanism for your topology and other juju specific bits
<sarnold> marcoceppi: I can't find that ppa in my "subscriptions" list thingy -- should I have access or should I not? :)
<lazyPower> sarnold: shhh, we wont talk about that
<sarnold_> marcoceppi: sorry, my irc machine died after I saw a highlight but before I could switch to this channel to see what was said.. I assume it was you who replied to me, anyway :)
#juju 2014-04-24
<mbruzek> Hello Jose are you there?
<jose> mbruzek: I am always here :)
<mbruzek> wow
<jose> :P
<jose> how can I help?
<mbruzek> So as always you are doing a great job by submitting stuff.  I am reviewing one of your Merge Proposals.
<mbruzek> for the juju-gui and the default values.
<jose> cool :)
<jose> (btw, not sure if it's needed, but I have signed Canonical's CLA)
<mbruzek> I can not +1 this one because the juju-gui hook actually checks for one of these values being None.
<jose> oh
<mbruzek> jose signing that is a good idea, but not required.
<jose> good to know
<mbruzek> And I also wanted to say I watched your video with lazypower just now, and it was VERY WELL DONE by both you and Chuck.
<mbruzek> jose, seriously GREAT JOB on that video.
<jose> thank you!
<jose> I hope it can also serve as a future reference for new contributors
<lazyPower> jose deserves all the credit
<lazyPower> :)
<jose> nah, lazyPower was the one doing all the dirty work
<mbruzek> I will explain more in the response to the review.  I can approve this change if you leave the login-help without a default.
<jose> I just sat there and watched
<jose> mbruzek: actually
<jose> if that's the only thing, I can submit a fix just now
<lazyPower> i was completely happy educating the masses without telling them what juju was, it never even crossed my mind they wouldn't know what juju is....
<mbruzek> You both did an outstanding job on that video, it was great.
<mbruzek> Actually jose it is pretty late here and I should not push anything this late at night.  I will leave my review comment and if you fix it I will pick it up in the morning.
<jose> sounds good to me :)
<mbruzek> I wanted to thank you for the work in this area and tell you to keep up the good work.
<jose> I hope I can continue to be around to get more of those MPs in :)
<mbruzek> I am sure you will
<mbruzek> You are very close on this one, the code did not agree with you
<mbruzek> that happens to me all the time!
<mbruzek> For you just once in a while
<jose> but don't talk to me about icons :P
<lazyPower> LOL mbruzek. its like he 'knew' about inkscape being angry earlier.
<lazyPower> jose: you're more on topic than ever buddy. must be the wavelengths
<mbruzek> You know lazyPower I should have consulted jose with my problem with inkscape
<mbruzek> I didn't even think about that.
<mbruzek> Jose you are up next time I have a problem with inkscape.
<lazyPower> the kids got skills
<lazyPower> no doubt about it
<mbruzek> I figured it out by the way lazyPower, inkscape did not get the better of me this day!
 * jose is better with gimp
<lazyPower> so, we figured out it was the G, what was the magic transformation magic?
<lazyPower> g = square in klingon or something?
<lazyPower> dpb1: if you're around. You passed my intitial review. You'll get a full write up in the morning after i've reviewed with cory_fu, and finalize our notes.
<lazyPower> oh yeah jose, i'll push the assault cube and mailman stuff in the morning. i'm with mbruzek on not addressing the charm store this late at night.
<lazyPower> chances are i'll nuke the queue and reset the time space continuum.
<jose> well, that idea is great, guys.
<jose> I remember someone once broke the universe
<jose> once or twice
<mbruzek> lazyPower, For text object you need to run "object to path" which renders it to SVG.  The original text object was just a G with a font tag, and systems that don't have that font would not display it correctly
<lazyPower> lameeeee
<lazyPower> but it makes sense to someone i guess. When would you ever want a font object that renders as a square?
<mbruzek> Well I found it and jorge didn't like the G icon anyway so we went with the black one.
<sarnold> http://en.wikipedia.org/wiki/Ro_(kana)
<lazyPower> awww
<lazyPower> save that icon i'll charm up something with a G so we can use that slick icon
<lazyPower> or better yet, have jose do it
<lazyPower> sarnold: you're not helping my argument :|
<sarnold> lazyPower: sorry :)
<lazyPower> :P
<lazyPower> Are you going to be at the sprint in LV sarnold?
<sarnold> lazyPower: not that I know of.. when is it?
<lazyPower> next week. Take some swap days and wander down out of the mountains to say hi
<lazyPower> i'll buy the beer if ya do
<sarnold> woo beer :)
<sarnold> lazyPower: how about malta? are you going to be in malta?
<lazyPower> negative
<sarnold> awwww man :/
<lazyPower> wasn't invited.
<lazyPower> figure out a way to do some sec auditing on juju so you get invited to our sprints. I want to thump you in dominoes
<sarnold> I seriously miss UDS.
<lazyPower> not that i'm some great domino player but i'll play the card anyway
<sarnold> hahaha
<sarnold> the sprints I've done were alright, but they don't do much to undo the silo-effect. i figure I know a dozen or so employees tops despite being here 1.5 years..
<lazyPower> it takes some getting used to. I'm in my 30's and over half of my friends are from the internet - i figure its a right of passage getting to know someone in the physical space. Its a side effect of those BBS days of yore
<lazyPower> like, dial up to the BBS, play some door games with a bunch of geeks and meet up for beers once a year.
<sarnold> tradewars 2002 <3
<lazyPower> major mudd <3
<lazyPower> had the best scripted ninja no money could buy. 450 lines of comet code to power the autoroam
<lazyPower> 5 months of dev to get it right, and a ton of corpse runs while i figured out what went wrong while i was at school.
<lazyPower> sarnold: i still have a copy of the WORLDGROUP bbs software around here somewhere. It wouldn't take much to bring up a tradewars server if you wanted to play.
<sarnold> lazyPower: awwwww. that's tempting. :)
<sarnold> juju deploy tradewars2002!
<lazyPower> ehh... even though worldgroup is abandonware they still have a pretty nasty licensing model
<sarnold> aww :(
<lazyPower> I'd ahve to find a better hub to run it on if you wanted to wrap it with juju
<lazyPower> that or we need to find a better MUD with less angry licensing
<lazyPower> i think L.O.R.D. went public domain in 2000
<mbruzek> Later guys.
<lazyPower> later mbruzek o/
<lazyPower> see you in the am
<mbruzek> Thanks again Jose
<jose> I agree with sarnold, I also miss UDSs :(
<lazyPower> you know what would help alleviate that? if we did a mass broadcast of a meat space meetup somewhere on the globe, gave people time to plan it, and just did a meetup once a year. That way UDS stays VUDS and gets the benefits of it and the company gets a retreat/picnic
<lazyPower> assuming people want to go - non mandatory travel of course.
<jose> benefits of UDS is that I would be sponsored
<jose> kiddos cannot pay for airplane tickets
<sarnold> lazyPower: ooh. I'd give one of those a shot. even if it is just new joiners, folks not yet sick of airplanes ;) hehe
<lazyPower> jose: start a kickstarter
<lazyPower> 'send me to the canonical event for being an awesome community member for $1 from 200 people'
<jose> haha, airfare to the US is not $200, but rather $600 :P
<jose> $1 = thank you tweet, $5 = awesome email from me!, $10 = a not-so-awesome freenode cloak!, $200 = bottled air from the airplane I travel in!
<sarnold> hahaha
<lazyPower> oh man, the $200 donation package sounds awesome
<lazyPower> the funny thing is, if you did that and marketed it just right you'd probably get a free ticket.
<lazyPower> so, sarnold, i'm seriously looking into this. there's a few door games that we can bundle up
<lazyPower> i need to figure out what is involved in the bbs software seutp with the existing unix compat offerings...
<lazyPower> but if you want to pair on this and split up the work, i'm game
<lazyPower> we can bring a bit of 90's nostalgia to the juju charm store
<sarnold> lazyPower: heh, last time I played tw2002 I was utterly destroyed by a well-scripted player after about two weeks of simple trading and laying low and building a nice little corner of the universe...
<lazyPower> thats the benefit of running your own private server
<sarnold> lazyPower: it kinda took some of my enthusiasm out for re-playing those good old days :( hehe
<lazyPower> you get to be god and ban the scripters
<sarnold> hehe
<lazyPower> but ok, if its nto worth the investment, i'll let it go. It shouldn't take much to get this running tho
<lazyPower> a good weekend afternoon and we'd probably have most of the heavy lifting out of the way
<sarnold> yeah I'd probably have a giggle re-playing for an hour or something and that'd probably be the  end of it :)
<sarnold> alright, time to eod  :) g'night lazyPower :)
<lazyPower> o/
<dpb1> lazyPower: thanks!  I'll look forward to it
<lazyPower> dpb1: however the tests failed
<dpb1> which tests?
<lazyPower> 5 of the suite returned failure
<lazyPower> i'd have ot re run it that byobu session is long since detached
<dpb1> ahh
<dpb1> ok.  could be a missing dependency, will have to see it if you do run it again
<lazyPower> i can spin it up and re-run them, how long are you going to be around?
<lazyPower> the suite takes ~ 30 minutes to run from a to z. rough estimate - but thats about what i saw benching against hpcloud
<dpb1> lazyPower: ok, that is the integration one.  I'll be here at least an hour, but please, don't stay around for me.  we can do it tomorrow
<lazyPower> i'm hacking on other things after hours. no worries. its running now :)
<dpb1> lazyPower: and you can run SKIP_SLOW_TESTS=1 make integration-test
<dpb1> there is one test that takes all the time (it downloads some large files)
<lazyPower> yeah, i'm running the full suite, our mentality is if you have the tests, they better pass :)
<lazyPower> i got flogged for ack'ing a charm that didn't have passing tests that were included.
<lazyPower> so, lesson learned
<dpb1> k
<lazyPower> http://paste.ubuntu.com/7319822/
<lazyPower> dpb1: it didn't complete this time around, i must have run it with skip slow tests before.
<lazyPower> but i'm calling it and will resume this tomorrow morning.
<dpb1> lazyPower: can you paste in everything?
<dpb1> before you go. :)
<lazyPower> sure - http://paste.ubuntu.com/7319843/
<dpb1> lazyPower: thanks much... cya tomorrow
<lazyPower> np, the majority of the issues look related to a stray escape sequence, and an invalid password
<lazyPower> see you in the AM
<X-warrior> How could I remove my juju from debug mode? I mean, all my jujud unit has a  --debug parameter on the end of it.
<mhall119> jcastro: ping
<jcastro> yo
<mhall119> hey man, postgresql 9.3 on trusty, when will that be available via a charm?
<jcastro> we should add an option yes
<jcastro> mhall119, right now all the charms are precise except a handful, what we're doing is adding test to each one, then promoting them into trusty
<mhall119> jcastro: any ETA on that? I'm currently blocked testign on LXC
<jcastro> one sec, it appears the charm has a version option
<jcastro> let me see if it does what you want
<jcastro> Version of PostgreSQL that we want to install. Supported versions are "9.1", "9.2", "9.3". The default version for the deployed Ubuntu release is used when the version is not specified.
<jcastro> mhall119, so do:
<jcastro> juju set postgresql version="9.2"
<jcastro> not sure if you need the " or not
<mhall119> what's default for trusty?
<marcoceppi> mhall119: 9.3
<mhall119> so, how do I deploy the precise charm onto a trusty instance?
<marcoceppi> mhall119: you branch it first
<jcastro> marcoceppi, since postgres already has tests is there a reason we haven't promulgated it to trusty?
<mhall119> what's the location to branch from?
<marcoceppi> mhall119: mkdir trusty; cd trusty; charm get postgresql; juju deploy --repository ../ local:trusty/postgreql
<jcastro> "no time" is a totally valid answer here
<marcoceppi> jcastro: I haven't tested it yet, but I plan on it soon
<marcoceppi> jcastro: I know stub did some awesome work to make it trusty proof a few months ago
<jcastro> yeah
<jcastro> I have no doubt it's awesome
<mhall119> hey, so my laptop powered itself off yesterday (it does that sometimes, no idea why) and now I can't connect to my LXC environment
<mhall119> ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: dial tcp 10.0.3.1:17070: connection refused
<marcoceppi> mhall119: sudo initctl list | grep juju
<mhall119> juju-db-mhall-local stop/waiting
<mhall119> juju-agent-mhall-local start/running, process 996
<marcoceppi> mhall119: start the db process
<jcastro> mhall119, out of curiosity your app is so new it needs to deploy on trusty?
<mhall119> jcastro: it's summit, freshly updated to Django 1.6
<jcastro> ack
<jcastro> are you using the django charm on trusty too?
<mhall119> marcoceppi: it won't start
<mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/summit/current_work/summit$ sudo start juju-db-mhall-local
<mhall119> juju-db-mhall-local start/running, process 28000
<mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/summit/current_work/summit$ sudo initctl list | grep juju
<mhall119> juju-db-mhall-local stop/waiting
<mhall119> juju-agent-mhall-local start/running, process 996
<mhall119> jcastro: custom charm, for IS purposes
<marcoceppi> mhall119: pastebin /var/log/upstart/juju-db-mhall-local.log
<jcastro> marcoceppi, I'm going to bump the priority on postgres then, according to the spreadsheet we just need to check the tests, ensure it follows NEW policy, and add the charm features, that's about it.
<marcoceppi> jcastro: yeah, I'll take a peak tomorrow
<jcastro> mhall119, any other charm you need for trusty? Now is your chance
<jcastro> (assuming you get a working local provider. :))
<mhall119> marcoceppi: http://paste.ubuntu.com/7322529/
<mhall119> jcastro: gunicorn
<mhall119> those are the 3 I use, summit-website, postgresql and gunicorn
<mhall119> IS uses some HA proxy and pgbouncer ones, but that's their problem
<mhall119> I only need trusty-specific charms for postgresql because I cna't mix precise nad trusty deployments on LXC
<jcastro> haproxy is done
<jcastro> but I am not sure we have promulgated it yet
<jcastro> we have a sprint next week to sort ourselves
<mhall119> ok
<mhall119> marcoceppi: any suggestions on how to recover my LXC environment, or cleanly get rid of it so I can start over?
<mhall119> we need a juju-scrub-local command or something that forcibly removes anything left behind
<ppetraki> mhall119, file a bug
<mhall119> you mean complaining to jcastro isn't the same as filing a bug?
<ppetraki> mhall119, juju-scrub-local sounds like a great idea, and should be captured on a bug so we can task it out
<jcastro> http://askubuntu.com/questions/403618/how-do-i-clean-up-a-machine-after-using-the-local-provider
<jcastro> is this not up to date?
<lazyPower> jcastro: its as up to date as i'm aware of, we haven't done anything different.
<mhall119> ppetraki: lp.net/juju?
<lazyPower> mhall119: lp.net/juju-core
<ppetraki> yeah, pyjuju is in maintenance mode, and you can easily use goju from the ppa
<mhall119> ppetraki: https://bugs.launchpad.net/juju-core/+bug/1312201
<_mup_> Bug #1312201: Provide developers with a "nuke it from orbit" option for cleaning up LXC <juju-core:New> <https://launchpad.net/bugs/1312201>
<ppetraki> mhall119, thank you
<mhall119> np
<ppetraki> mhall119, in the meanwhile, you might want to consider taking that script and making a juju plugin out of it https://github.com/juju/plugins
<marcoceppi> there's a plugin for that
<ppetraki> \o/
<mhall119> damn I'm fast :)
<allomov> Hi, all.
<allomov> I have a problem with ssl after updating ubuntu from 12.04 to 14.04
<allomov> https://gist.github.com/allomov/11256266
<allomov> here are some details
<allomov> did anyone saw such issue ?
<cory_fu> allomov: There is an issue with websocket-client 0.13.0 and juju-deployer.  To get around that for now, downgrade websocket-client via, e.g.: sudo pip uninstall websocket-client && sudo pip install websocket-client==0.12.0
<allomov> wow. thank you so much, it appears that you've saved my day.
<marcoceppi> mhall119: still having issues?
<mhall119> marcoceppi: everything appears to have deployed ok, but HTTP connections are failing
<mhall119> not sure if it's a juju thing or a django/gunicorn thing
<mhall119> http://paste.ubuntu.com/7322988/
<mhall119> wasn't there a juju command to ssh into an instance?
<mhall119> or do I need to chroot to it when it's local
<mhall119> oh, duh, I'm missing my .wsgi file
<lazyPower> mhall119: re: your ssh command, juju ssh <service-name>/<unit> or juju ssh <unit>  will get you into the machine.
<lazyPower> if you want to run the hooks interactively, use debug-hooks service/unit  and use juju resolved --retry to re-runt he failed hook.   or alternatively you can just juju run --service <service> "hooks/hook"  to execute the hook and return STDOUT locally.
<jose> negronjl: did you get to review that seafile thing?
<negronjl> jose: I've been swamped ... let me do it now ... can you give me the MP so I don't have to :)
<jose> sure
<jose> https://code.launchpad.net/~jose/charms/precise/owncloud/port-change+repo+ssl-support
<jose> whoops
<jose> https://code.launchpad.net/~jose/charms/precise/owncloud/port-change+repo+ssl-support/+merge/215527 is it
<negronjl> jose: that's for owncloud
<jose> urgh, blargh
 * jose just got from university and brain isn't working
<jose> ok, here we go: https://code.launchpad.net/~jose/charms/precise/seafile/change-readme-icon-color-fixed-website-added-memcached-support/+merge/216804
<negronjl> jose, reviewing now
<jose> thank you
<negronjl> jose: merged
<jose> negronjl: awesome, thanks!
<negronjl> jose: thank you
<jose> it's waiting on the queue to be on the store :)
<qhartman> still working on getting openstack going. Figured out that I needed to add some relations that weren't in the doc I'm following.
<qhartman> Gotten to the point that I can run VMs, but they aren't getting networking for some reaso
<qhartman> Gotten to the point that I can run VMs, but they aren't getting networking for some reason
<qhartman> digging into that now.
<qhartman> Is there a doc anywhere that is known correct for all the relations that are needed in the Trusty charms?
<qhartman> I'm planning on currently going through each one in the charm store and double-=checking that way, but that's pretty laborious
<magicrobotmonkey> how do i make the bootstrap timeout longer? 10 minutes isn't enough for this hardware
<qhartman> I found that the other day... let me look again...
<qhartman> also, consider using the fastpath installer, it's muuuuch faster
<magicrobotmonkey> heh i am
<magicrobotmonkey> the bios is like 5 minutes
<magicrobotmonkey> oh nm i see it
<magicrobotmonkey> juju help bootstrap
<magicrobotmonkey> is what i was looking for
<qhartman> in environments.yaml
<qhartman> add bootstrap-timeout: 1800
<qhartman> (or whatever time you want
<magicrobotmonkey> thanks
<qhartman> Is there a quick way to restart component services through juju?
<qhartman> In my case, I updated the relation of nova-compute to rabbitmq-server, but it didn't look like the various nova-* services restarted to pick up the new config
<mbruzek> jose ping
<jose> mbruzek: pong
<mbruzek> So I spoke with the juju-gui team and it seems that you should open a similar merge request under the URL they replied with instead of the standard juju-gui charm.
<jose> ok, sounds good to me :)
<jose> I'll re-point the merge in a min
<mbruzek> OK let me know when you do and I will give it another look over.
<magicrobotmonkey> aww yea qhartman, things are happening now
<magicrobotmonkey> thanks
<qhartman> awesome
<qhartman> glad I could help
<magicrobotmonkey> umm but does this node need to be able to reach the internet?
<qhartman> probably
<qhartman> I setup my maas controller to do simple NAT bridging and that took care of it
<magicrobotmonkey> yea im gonna have to send it all through the region controller i think
<qhartman> yeah, that was simpler than getting the routing stuff automated in my multi-homed setup
<jose> mbruzek: is it necessary that I run `make lint` and `make unittest`? `make lint` is giving me an error about a virtualenv not found
<rick_h_> jose: is this on the gui charm patch?
<rick_h_> jose: so if you've got the charm code checked out you can make clean and then make lint
<rick_h_> it should setup a virtualenv with the tools needed to run lint/test/etc
<jose> rick_h_: yeah, this is on the gui charm
<mbruzek> jose I have found you have to be real clear with rick_h_ on which charm you are talking about
<mbruzek> JUJU-GUI
<rick_h_> :)
<rick_h_> sorry, I like get jump into the middle of conversations that sound like I might care
 * mbruzek is joking
<mbruzek> jose did make clean create a virtualenv for you ?  Or do you have to install extra packages?
<rick_h_> the makefile should take care of everything for you
<jose> same rror
<jose> and make clean didn't create a virtualenv
<jose> just deleted some files
<rick_h_> jose: can you pastebin the traceback?
<rick_h_> jose: right, clean will remove the files
<jose> sure
<rick_h_> and make lint should install them for you
<jose> http://paste.ubuntu.com/7324072/
<rick_h_> ah!
<rick_h_> make sysdeps
<rick_h_> sorry
<rick_h_> you need that to load system-wide deps to work on the charm
<rick_h_> you only have to do that once
<mbruzek> jose, These steps are good candidates to add un the HACKING.md
<mbruzek> s/un/in
<jose> I'll check that file in a bit too
 * jose has to do a classroom session atm
<rick_h_> jose: ok, let me know if you hit any more issues.
<rick_h_> jose: happy to help
<jose> thank you!
<magicrobotmonkey> ugh is there a way to make bootstrap not immediately shut down the node
<magicrobotmonkey> so i can investigate a bit
<jose> bootstrap shuts down the node?
<magicrobotmonkey> using maas
<jose> w0ot, looks like make sysdeps; make lint and make unittest ran successfully
<qhartman> magicrobotmonkey, not that I'm aware of. But I am a MAAS newbie
<jose> mbruzek: resubmitted MP
<rick_h_> jose: awesome
<rick_h_> jose: linky to the MP?
<jose> https://code.launchpad.net/~jose/charms/precise/juju-gui/add-blank-defaults/+merge/217120
<jose> rick_h_: ^
<kentb> are --upload-tools and --sync-tools valid bootstrap flags anymore?  I'm  behind a proxy and I keep getting "invalid URL "tools/streams/v1/index.json"" when trying to bootstrap
<rick_h_> jose: cool, I want to run the functional tests on it. I'll do that in a few. It takes a while to run against ec2 so will take a bit to make sure all is well and report back
<jose> no worries, I have time :)
<magicrobotmonkey> ERROR charm not found: cs:trusty/openstack
<jose> magicrobotmonkey: it's not been promulgated to trusty
<jose> and there's not even an openstack charm (like, named openstack) :)
<magicrobotmonkey> hah
<magicrobotmonkey> i was so excited i got it to bootstrap i had to try something
<jose> magicrobotmonkey: try nyancat, it's fun :P
<jose> just `juju deploy nyancat` should work
<magicrobotmonkey> man thats not on trusty either
<magicrobotmonkey> maybe i jumped the gun a bit
<kentb> nm figured it out
<jose> magicrobotmonkey: there are not many charms in trusty, but you can do cs:precise/nyancat
<magicrobotmonkey> ok
<tvansteenburgh> jose: did you see my comments on the seafile charm?
<jose> tvansteenburgh: yep! much appreciated, and they're now fixed :)
<jose> I think I should change the branch to reflect the actual trunk one
<tvansteenburgh> jose: ok cool, i'll give it another look
<jose> thank you!
<tvansteenburgh> didn't realize you'd pushed changes
<jose> btw, I also added memcached support
<tvansteenburgh> nice
<dpb1> cory_fu: so, two of those keys cannot have a default for now.  Can I ignore those warnings from charm proof?  I fixed 'services' to have a default.
<jose> as jcastro would say: jose <- lunch
<dpb1> cory_fu: soon, a default will be provided, but it's not quite ready yet (as you noted in another part of your review)
<cory_fu> Yeah, no default is fine if there isn't a sensible one
<dpb1> ok
<cory_fu> Though, are the options supposed to take file names or the actual key / URL values?
<cory_fu> I guess the values
<dpb1> the values
<dpb1> yes, right
<dpb1> cory_fu: soon, we will be able to fix it up, but for now it is what it is, they are required to install the charm. :(
<cory_fu> Yeah, no worries.  That seems reasonable
<dpb1> ok
<cory_fu> I figured they might not be reasonable to have default values, but figured I'd mention it, at least
<dpb1> thanks, duly noted.
<tvansteenburgh> jose: ping me when you're back from lunch
<dpb1> cory_fu, lazyPower: I pushed up r153 with feedback from your review, and updated the bug, could you take another look please?  :)
<lazyPower> dpb1: ack. I'll take a look before I EOB
<lazyPower> s/B/D
<dpb1> lazyPower: thx
<tvansteenburgh> jose: posted a review on your latest seafile changes
#juju 2014-04-25
<jose> tvansteenburgh: ping
<tvansteenburgh> jose: pong
<jose> tvansteenburgh: I'm back from 'lunch'. you caught me while taking a nap that lasted more than expected :P
<tvansteenburgh> jose: haha no prob. i was gonna chat about seafile stuff but i ended up just putting in a comment on the ticket
<jose> oh, oh
<jose> about the server_name
<jose> it's actually something to be treated like a hostname
<jose> so I'm not sure if 'localhost' would be a good guess
<jose> any name could actually fit
<tvansteenburgh> fair enough. in that case should probably put "server hostname" in the description
<tvansteenburgh> now that you've said "hostname" i get it
<tvansteenburgh> before i wasn't really sure what it was
<jose> the hostname will always be the internal IP, but this is more like 'my seafile server is called foo'
<tvansteenburgh> yeah , got it
<jose> but I can add a note saying 'it can be anything you like, let your creativity fly'
<tvansteenburgh> it's up to you, it's your charm :)
<tvansteenburgh> can leave as-is if you want
<jose> I'll go ahead and add some of those thingies in a min
<tvansteenburgh> cool
<jose> and, on the relation-departed hook, I'm going sed to match { as there are a couple lines which have a '{', so it deletes them all at once
<jose> ...or is there just one?
<tvansteenburgh> with the original code, the "CACHES = {" line didn't get deleted
<jose> uh
<jose> but I'll submit patches later today, that's for sure :)
<jose> thanks for going though it!
<tvansteenburgh> cool
<tvansteenburgh> my pleasure :) it's a nice charm
<tvansteenburgh> cool app too, i had never heard of seafile before
<jose> me neither :P
<joelmo> hi all, i followed https://juju.ubuntu.com/docs/getting-started.html and https://juju.ubuntu.com/docs/config-local.html to try and start a wordpress service but i get agent-state pending under wordpress and agent-state started on machine 0
<joelmo> https://gist.github.com/a26fd0a6222dcaa78b35
<lazyPower> joelmo: do you have a default-series: in your environments.yaml?
<joelmo> lazyPower: i didn't maybe i missed some step in the guide, will try now, how do i restart with the new env config?
<lazyPower> joelmo: its something we recently discovered is a side effect with the local provider
<lazyPower> you can restart by destroying the local env, and adding default-series: precise to ~/.juju/environments.yaml under the local provider section
<lazyPower> then rebootstrap and deploy. Also, your machine0 will always start without issue because its created on the host machine. The bootstrap node doesn't actually live in an lxc container.
<joelmo> lazyPower: ok thanks
<gnuoy> I'm experimenting with a new charm and adding a relation between 2 subordinates (attached to different superordinates). Juju allows me to add the relationship and then shows its existence in juju status bit I see no sign of any hooks being fired. I'm not sure whether I'm hitting a bug or if juju doesn't support this setup
<gnuoy> s/bit/but/
<gnuoy> ok, this looks like a bug because breaking the relation does fire hooks
<lazyPower> gnuoy: subordinates support relationships with other subordinates. Is the hook appropriately named?
<gnuoy> lazyPower, I'm in a debug hooks session on both subordinates and nothing happens when I add the relation and no output in debug-logs
<lazyPower> if its not firing the config-changed, or joined hooks - thats most def. a bug. I'd want to see a code example, output, debug log, and attach all that to a bug against juju-core.
<gnuoy> lazyPower, coming up
<lazyPower> dpb: sorry for not getting back to the landscape-server charm lastnight. Pulling it up for the follow up review now
<melmoth> what line to use exactly for "openstack-origin:" in order to install icehouse ? I try with "openstack-origin: cloud:precise-icehouse/updates" but that does not seem to be the right one
<melmoth> ahhh trusty-icehouse/updates seems better
<gnuoy> lazyPower, pebkac, I'd accidentally specified the scope of the relation between the two subordinates as 'container' (copy & pasta error), sorry for the noise
<lazyPower> gnuoy: glad you got it sorted :) I have those moments all the time
<gnuoy> those moments are coming think and fast for me today :)
<lazyPower> http://i.imgur.com/pny2W4g.jpg
<gnuoy> exactly
<dpb1> lazyPower, cory_fu: hey guys -- get a chance to peek at that landscape-server charm again?
<lazyPower> dpb1: finishing up the review now
<lazyPower> running the test suites :)
<dpb1> nice!
<lazyPower> sorry about the delay, i had intended to wrap it up lastnight but was unit testing some code until 10pm
<lazyPower> i was burnt and had no business pushing to the store that late
<dpb1> lazyPower: heh
<avoine> someone already saw this error at bootstraping: failed to initialize state: cannot create log collection: unauthorized mongo access: unauthorized
<avoine> I'm kind stuck on it
<Makyo> Hi from GopherCon.  I'm trying to get juju building on my new laptop and running into the following: utils/ssh/ssh_gocrypto.go:84: undefined: ssh.ClientConn
<avoine> so reboot solve the problem...
<marcoceppi> Makyo: you might want to check #juju-dev , but they're mostly at GopherCon too :)
<Makyo> marcoceppi, thanks :)
<wwitzel3> is there a list of charms somewhere that have been promoted to trusty?
<lazyPower> wwitzel3: http://manage.jujucharms.com/charms/trusty
<wwitzel3> lazyPower: cheers
<marcoceppi> bzr pull
<jcw4> marcoceppi: wrong window? ;)
 * marcoceppi sighs
<marcoceppi> yes
<jcw4> :)
<dpb1> Hi -- if I have a bundle that has a required config value for a charm to even install, what is the best approach?  Let the charm go to error, and let the user fill in the required value and do resolved --retry?
<lazyPower> dpb1: we typically refuse the setup, and return 0 so the charm doesnt 'error' - its the onus of the user to read the docs.
<dpb1> interesting.  ok
<dpb1> lazyPower: relations still work though, etc.  just nothing is functioning?
<dpb1> at some point, raising an error to user seems like the right approach.
<dpb1> (just thinking out loud)
<lazyPower> if it makes more sense in the context of your charm, proceed with raising an error - i can see why you would want that having reviewed the landscape-server charm - the relationships themselves would fail without the underlying service doing what its supposed to do.
<dpb1> lazyPower: ok, thanks
<axisys> looks like juju local still has a bug? juju status shows agent-state: down
<ahasenack> are you guys aware of mirror problems in us-east-1? I can't bootstrap
<ahasenack> W: Failed to fetch bzip2:/var/lib/apt/lists/partial/us-east-1.ec2.archive.ubuntu.com_ubuntu_dists_trusty-updates_universe_binary-amd64_Packages  Hash Sum mismatch
<ahasenack> E: Some index files failed to download. They have been ignored, or old ones used instead.
<ahasenack> ERROR bootstrap failed: rc: 1
<axisys> nm.. it started now
<axisys> agent-state: started
<mbruzek> Does anyone know how to refer to subordinate charm instances through juju?
<mbruzek> I am trying to run a command on a subordinate that looks deployed and related fine, but get $ juju ssh content-fetcher/0
<mbruzek> ERROR unit "content-fetcher/0" not found
<mbruzek> I realize I could ssh to the parent service, but I am trying to follow the readme and see if this works.
<cory_fu> I ran into that, as well, and am interested in knowing of a solution, mbruzek
<axisys> hmm.. looks like still having issue .. juju status hadoop-master still showing pending and lots of error in all-machines.log
<axisys> all-machines.log => http://paste.ubuntu.com/7331840/
<axisys> I am on Ubuntu 14.04 LTS
<mbruzek> hi axisys
<mbruzek> Do you have a default-series set in your environments.yaml?
<mbruzek> axisys It looks like you need to set "default-series: precise" in your ~/.juju/environments.yaml file
<Beret> what should the default charm license be?
<lazyPower> Beret: anything that falls under an Open Source License.
<lazyPower> Beret: http://choosealicense.com/
<Beret> no worries, I just wondered if there was a convention
<lazyPower> Just that its an open source license, we're pretty liberal when it comes to the authors choice of which model they choose.
<avoine> is there anything that can be done if one subordinate needs to wait for a other to finish before making a relation?
 * avoine needs to check openstack bundles
<avoine> like if A check if there is a B relation  and otherwise does nothing is there a chance that A will never be triggered when B is finish?
#juju 2014-04-26
<axisys> added default-series: precise below type:local.. still  not starting the services hadoop
<axisys> http://paste.ubuntu.com/7334598/
<vds> romanoff, https://juju.ubuntu.com/docs/getting-started.html#ubuntu
#juju 2015-04-20
<schkovich> comment
<blahdeblah> Hi all.  My amulet tests ran & passed for precise, but not trusty - any ideas why?  Is it just backlog, or do I need to do something else to get it recognised?  http://reports.vapour.ws/all-bundle-and-charm-results/quassel
<lazyPower> blahdeblah: looking now
<blahdeblah> lazyPower: thanks
<blahdeblah> lazyPower: I did push two different branches - one for precise & one for trusty
<lazyPower> thats the first thing i checked :)
<lazyPower> interesting. i see no evidence of it even attempting to run. I'll kick off a test of the trusty branch manually
<lazyPower> tvansteenburgh1: ^ if you get a moment, can you take a peek and see why the precise series ran but not trusty?
<lazyPower> blahdeblah: however - i see a full row of greens here. Congrats on the fruit of testing labor
<blahdeblah> lazyPower: I got there eventually. :-)
<blahdeblah> lazyPower: So the testing runs should kick off automatically when we do a new commit to a charm trunk?
<lazyPower> i dont know how much of the CI automation we have enabled/setup - that was being refactored the last i heard
<tvansteenburgh> lazyPower: tests aren't started automatically, someone has to start them
<lazyPower> I thought that's where we were when we left off w/ the automation.
<lazyPower> thanks for confirming tvansteenburgh
<lazyPower> blahdeblah: the trusty charm is still deploying the precise series
<lazyPower> http://bazaar.launchpad.net/~paulgear/charms/trusty/quassel-core/trunk/view/head:/tests/50-basic-deploy  - line 12 needs to be updated to read     cls.d = amulet.deployment(series='trusty')
<drbidwell> I have  a set of machines in MAAS with 4 nics.  How do I get juju to bring up all 4 nics when it deploys them?  My ceph deploy is failing because the right interfaces are not up.
<blahdeblah> lazyPower: thanks
#juju 2015-04-21
<jamespage> gnuoy, I need to fix nova-compute for kilo + dvr
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/nova-compute/fixup-dvr-metadata-proxy/+merge/256902
<gnuoy> jamespage, approved
<gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/neutron-api/fix-neutron-query/+merge/256889 if you have a moment.
<joec1> o/
<marcoceppi_> mbruzek lazyPower
<marcoceppi_> you can try adjusting the format of the bundle you're submitting
<mbruzek> So the charmstore editing a bundle seems like a "bad idea" to me.  We did a lot of testing the way it is and make sure everything works.
<mbruzek> https://github.com/juju/charmstore/issues/358
<mbruzek> This bug says they are inserting keys into the bundles.yaml
<rick_h_> mbruzek: definitely a bug and our fault.
<mbruzek> marcoceppi_:  What format would not get num_units inserted into the bundle?  We have suborinate charms, and num_units on subordinate charms do not mix
<rick_h_> mbruzek: but it was the path to get from the old format with multiple per file to the single bundle per file.
<rick_h_> mbruzek: not your fault, the orig file is fine
<rick_h_> mbruzek: nothing for you to do/change. it's all on us
<mbruzek> rick_h_: Our bundle broke  on a demo to customers
<urulama> mbruzek: if you use bundle.yaml, and remove num_units where not needed, it would be ok
<urulama> mbruzek: instead of bundles.yaml
<rick_h_> urulama: they're using the 'add to demo' from the jujucharms.com though and so it's broken for users ootb
<mbruzek> rick_h_: I am not trying to assign blame.  I just want to know what we can do to fix this problem.
<urulama> rick_h_: yes, we need to fix it. just thinking how to fix it by tomorrow
<rick_h_> mbruzek: nothing on your end atm. we're working on it. Just supporting you in that you're blocked on us and updating the format on your end won't help
<mbruzek> OK
<rick_h_> mbruzek: got a sec to chat?
<mbruzek> rick_h_: sure
<rick_h_> mbruzek: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 adjust authuser to your liking
<rick_h_> mbruzek: lazyPower https://bugs.launchpad.net/juju-gui/+bug/1446688 for the other end.
<mup> Bug #1446688: gui cannot import CS bundles via drag/drop or import button <juju-gui:Triaged by makyo> <https://launchpad.net/bugs/1446688>
<mbruzek> OK thanks
<rick_h_> mbruzek: lazyPower so can you take it on trust that if you upload that bundle we still want to see if that can work?
<lazyPower> sure i'll do that now
<rick_h_> mbruzek: lazyPower the issue in the gui is a missing bundle name provided by the store when doing the deploy through 'add to demo'
<rick_h_> lazyPower: ty
<lazyPower> rick_h_: revision 3 just pushed to bzr - ingest incoming
<rick_h_> lazyPower: rgr will watch ty
<rick_h_> urulama: ^
<urulama> rick_h_, lazyPower: kk, let's hope for the best
<urulama> lazyPower: is this it? https://api.jujucharms.com/charmstore/v4/~kubernetes/bundle/kubernetes-cluster-3/meta/extra-info
<urulama> lazyPower: https://api.jujucharms.com/charmstore/v4/~kubernetes/bundle/kubernetes-cluster-3/archive/bundle.yaml
<lazyPower> urulama: metadata ingest looks good
<lazyPower> revno3 has the proper commit message
<lazyPower> bundle.yaml looks proper
<urulama> lazyPower: add to demo did work for me
<urulama> (but didn't deploy it)
<lazyPower> ok, thats consistent with what I found when trying to D&D
<rick_h_> urulama: lazyPower looking
<rick_h_> urulama: another potential bug, should hte .orig file be gone if we don't do any transform? e.g. is the .orig now old but still there?
<urulama> rick_h_: it is. we don't take bundles.yaml if bundle.yaml is there
<rick_h_> lazyPower: urulama the add to demo from the cluster-3 worked for me
<urulama> rick_h_: worked here as well
<rick_h_> lazyPower: so that unblock you for the moment?
<urulama> waiting for lazyPower to confirm that this is a fix
<rick_h_> just be aware anything else breaks lol
<lazyPower> http://i.imgur.com/TdFRUlN.png - confirmed as a working work-around
<rick_h_> lazyPower: ok, we'll get the other fixes out asap, but will be a bit. thanks for finding our issues
<lazyPower> Anytime :)
<urulama> lazyPower: so, i'd suggest we test all other "demoed" bundles as well
<lazyPower> urulama: i dont have a confirmed list from Dan Poler yet, i'm still pending an answer
<rick_h_> mbruzek: ^ fyi in case you hit anything as well as we fix things up
<dalek57> I'd like to be able to specify a custom image from Glance (openstack) on a charm by charm basis. Is there support for this?
<drbidwell> I have a machine stuck in pending.  I can "juju ssh #" into the machine.  How "retry" the setup to move the machine from "pending" to "started"?
<marcoceppi_> lazyPower: where's your fossdem talk? I want to use some of it for my OSDC talk
<marcoceppi_> Going to go a bit more structured this time around
<lazyPower> https://www.dropbox.com/sh/5bbrmj80xip3tth/AABQQmzEGsvEYYXQQ_dPT6Cma?dl=0
<marcoceppi_> lazyPower: ta
<bdx> Has anyone had any luck in deploying ceph or ceph-osd or ceph-radosgw when specifying the source param? E.G. source: http://ceph.com/debian-hammer/ trusty main
<bdx> I am not having the best of luck;-(
<bdx> Any advice would be greatly appreciated! Thanks!
#juju 2015-04-22
<apuimedo_> hi all
<apuimedo_> lazyPower: stub: About the problem with cs:precise/cassandra where deploying to an lxc is problematic due to the lack of hostname resolution
<apuimedo_> the more I think about it, the more I think this is a problem of how juju deploys lxc
<apuimedo_> http://paste.ubuntu.com/10865222/
<apuimedo_> following http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution
<apuimedo_> the lxc deployment misses the identity between 127.0.1.1 and the hostname
<lazyPower> apuimedo_: i think this goes further than just juju however - sudo lxc-create -t ubuntu -n awesome -- only names the container awesome. The underlying container doesn't get the hostname specified on the CLI
<lazyPower> apuimedo_: so it appears to me that this is bugworthy against LXC with a follow up for juju - but i'm not sure thats intended behavior either.
<apuimedo_> it does get a hostname though
<apuimedo_> juju just does the lxc-create?
<lazyPower> hmm let me re-check... i am bleary eyed and sipping my first cup of coffee
<apuimedo_> ;-)
<lazyPower> yeah, it basically just clones a container template and does a few setup steps
<apuimedo_> better go with "earl grey, hot!"
<lazyPower> apuimedo_: ah i see what you're saying
<lazyPower> it sets /etc/hostname but doesn't update /etc/hosts with the loopback resolution
<apuimedo_> exactly
<lazyPower> yeah - again - i point @ lxc for not doing that yet. i feel its bugworthy
<apuimedo_> it's an inconsistency with what happens for normal images like you'd have in OSt/maas
<apuimedo_> lazyPower: do you have a bugtracker link handy?
<lazyPower> https://bugs.launchpad.net/ubuntu/+source/lxc/+filebug
<apuimedo_> thanks ;-)
<lazyPower> apuimedo_: did you land a branch MP against the legacy cassandra charm to update teh hostname?
<lazyPower> s/land/propose/
<apuimedo_> lazyPower: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1447160
<mup> Bug #1447160: lxc-create template does not include /etc/hosts hostname resolution <lxc (Ubuntu):New> <https://launchpad.net/bugs/1447160>
<apuimedo_> lazyPower: no, not yet. I was first checking the source of the problem
<lazyPower> Sounds reasonable. :) Thanks for the link, i subbed
<apuimedo_> do you think it'd be acceptable to just do echo "127.0.1.1 $(cat /etc/hostname)" >> /etc/hosts as a first step in the charm install if grepping the /etc/hosts for the hostname fails?
<lazyPower> Sure
<lazyPower> i'd want to test it, but that sounds reasonable
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/rabbitmq-server/vivid-fixes/+merge/257084
<jamespage> following charm-helpers for that one
<gnuoy> jamespage, +1
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/mongodb/vivid-fixes/+merge/257086
<gnuoy> jamespage, lots of conflicts with that one
<jamespage> gnuoy, opps - try again - https://code.launchpad.net/~james-page/charms/trusty/mongodb/vivid-fixes/+merge/257086
<gnuoy> jamespage, +1
<dosaboy> jamespage, gnuoy: 3-phase has yeilded better thus far
<gnuoy> excellent
<dosaboy> jamespage, gnuoy: we hit an issue with swift/ceph on one nonde but we think it is down to hw issue
<dosaboy> jamespage, gnuoy: sgdisk gets stuck in D-state
<jamespage> gnuoy, charm support for lxd - https://code.launchpad.net/~james-page/charms/trusty/nova-compute/lxd/+merge/257104
<mwak> hi
<marcoceppi_> o/
<mwak> any idea why I get the following error when deploying a node app
<mwak> http://pastebin.com/bL4CuRV5
<mwak> ? :)
<marcoceppi_> mwak: Juju seems to think you don't have an available machines
<marcoceppi_> any "clean" machines
<marcoceppi_> even though you clearly do
<mwak> hum
<mwak> weird :/
<marcoceppi_> mwak: it could also be a default-consrtaints issue
<marcoceppi_> mwak: can you run `juju get-constraints`?
<mwak> no constraints
<marcoceppi_> mwak: ah
<marcoceppi_> I see the issue
<marcoceppi_> mwak: you're deploying a precise charm, you only have trusty machines allocated
<marcoceppi_> juju is trying to add another machine to match this new constraint of series
<marcoceppi_> and fails
<jcastro> ah, so simple it's obvious
<mwak> oh, no node-app for trusty
<mwak> :(
<marcoceppi_> mwak: not atm :(
<marcoceppi_> you can probably fork it, push to persoanl branch in charm-store, then deploy from there
<marcoceppi_> it shoudl work int trusty, it just needs integration tests to move forward
<mwak> yup
<mwak> will do that
<stokachu> sinzui: The Juju AWS and MAAS providers now support starting LXC containers.
<stokachu> sinzui: does that mean lxc containers will pull from and managed MAAS dns/dhcp?
<stokachu> a*
<sinzui> stokachu, container networking is SNATing the container to the host machine. Though dimitern cab explain specifics
<stokachu> be interesting to know if those containers are reachable without having to go through juju ssh
<apuimedo_> lazyPower: https://code.launchpad.net/~celebdor/charms/precise/cassandra/hostname_resolve/+merge/257120
<dimitern> stokachu, it depends, so in 1.23.2 with the "address-allocation" feature flag on, we'll use maas api to allocate static ips for containers
<stokachu> dimitern: sweet
<dimitern> stokachu, if the feature flag is not on, juju-br0 will be used with DHCP for both kvm and lxc on maas
<stokachu> ah ok understood
<stokachu> that is pretty sweet
<dimitern> stokachu, we'll most likely change the address allocation with juju-br0 to use the maas devices api to tell maas as juju starts containers on a node (so maas can know which device belongs to which parent node and cleanup dhcp leases, etc.)
<dimitern> but that will happen when 1.8 is in trusty
<stokachu> dimitern: very cool
<dimitern> stokachu, I'm composing a reply to the mail sinzui sent with your questions
<sinzui> stokachu, the only change from the other 5 1.23.x releases was the feature flag.
<dimitern> sinzui, yeah, if you're not counting like 20-ish fixed issues :)
<lamont> services framework relation, one direction I see the provided data show up on the other side.  but not in the other direction.. anyone got a second to stare at it and call me silly?
#juju 2015-04-23
<aisrael> lamont: I might be able to help
<lamont> aisrael: I eventually figured it somewhat out
<aisrael> lamont: ok. It sounded like you might have been running into this issue: http://askubuntu.com/questions/602527/provide-data-doesnt-send-data-when-required-keys-not-satisfied-juju-charm-usin/602629#602629
<lamont> the big challenge is that I have a relation may or may not exist, so I cannot use required_keys for it.  If the other side does use required_keys, then when it finally does provide_data, juju decides that there is no need to run the hook, and we hate life
<lamont> it might be that very issue
<lamont> my workaround was to stop using required_keys on the side that actually requires the relation to work
<lamont> and yes, your explanation there puts it spot on
<aisrael> lamont: Excellent. Glad to hear you got it working!
<lamont> aisrael: working is a relative term.. .I'm on to the next issues
<gnuoy> jamespage, if you get a sec https://pastebin.canonical.com/130192/
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/nova-compute/lxd/+merge/257104
<jamespage> gnuoy, hey!
<mbruzek> arosales: ping  (I know it is early for you)
<arosales> mbruzek, omw
<jamespage> coreycb, ok so git branches - where are we?
<coreycb> jamespage, I'm trying to get around a few issues where python-six and python-netaddr are installed by apt and conflicting with pip dependencies
<coreycb> jamespage, I think the problem we're going to continue running into is a mixed bag of apt installed and pip installed packages, and where to draw the line
<coreycb> for example, six gets force installed by c-h
<jamespage> coreycb, ok - so we need a minimal fix for release today for the impacted charms
<coreycb> jamespage, I might have one
<jamespage> coreycb, and then we can review whether we use a venv or suchlike going forward
<coreycb> yeah
<jamespage> coreycb, the git-kilo ones just fixup git support right?
<jamespage> for kilo sorry
<coreycb> jamespage, let me double check them
<coreycb> jamespage, I need to refresh those
<jamespage> coreycb, ok lets prioritize this stuff
<jamespage> coreycb, nova-cc first
<jamespage> and then the kilo-git stuff so long as its not to late - we have to release today and I don't want to compromise that
<jamespage> we can stable update a minimal fix if need be
<coreycb> jamespage, ok, testing a change for nova-cc now
<mwak> o/
<moqq> can someone please confirm for me that calling `relation-set -r <some-id-relation>` for a peer relationship from within a config-changed hook should cause all peer units to get a -relation-changed event
<marcoceppi_> moqq: it should so long as you actually change a key for your relation settings
<moqq> yeah i just realized the realtion values are per-unit and not per-relation, explains the results iâm getting
<moqq> thanks
<VijayT> Hello
<lazyPower> Hello VijayT
<marcoceppi_> o/
<mattrae> what's the best way to start container started by juju if the container has been shut down?
<lazyPower> mattrae: which provider?
<lazyPower> is this local, or a cloud host? and is the container type kvm or lxc?
<mattrae> lazyPower: using the maas provider.. deployed the lxc container with --to lxc:1 for example. I think i have the command now though
<mattrae> lazyPower: looks like i can do lxc-start --daemon --name foo-bar --rcfile /var/lib/lxc/containers/foo-bar/lxc.conf
<lazyPower> mattrae: ok, i was going to suggest looking at sudo lxc-ls --fancy, and starting the container with sudo lxc-start -n <name-of-container>
<lazyPower> with -d so you dont lose your terminal
<lazyPower> but yeah, that works as well :)
<mattrae> oh ok, i actually want to start the container the same way that juju starts it
<lazyPower> the config should specify the container to auto-restart however.
<mattrae> the reason is only because i've changed the lxc config.. and to reload the config i need to stop and start the container afaik
<lazyPower> ah - yes.
<lazyPower> glad you figured it out though :)
<mattrae> yup thanks for your help :)
#juju 2015-04-24
<moqq> is there any timeline on the release of 1.23?
<jrwren> i thought it was out?
<jrwren> i was wrong.
<lazyPower> jrwren: its still in devel ppa, close to release however
<lazyPower> moqq: I cannot offer a hard ETA - but its rounding the final phase of Q/A and poking, i would imagine we'll see it land next week
<moqq> great, thank you
<jrwren> lazyPower: that is what confused me.
<lazyPower> jrwren: come at me and my actions bro https://github.com/chuckbutler/docker-charm/commit/e72fd0d5b21071806e661b8c0e548884e26d3f60 ;)
<jrwren> lazyPower: why me?
 * jrwren runs away
<lazyPower> because I like tormenting you when you're around? :D
<jrwren> hahaha. fair!
<jrwren> lazyPower: you should see some of the terrible things I've done lately :)
 * lazyPower eyes narrow
<jrwren> lazyPower: foregone logstash-forwarder for beaver, because its easier.
<lazyPower> oh yeah?!
<lazyPower> bro, we need to talk about logstash server.
<lazyPower> I've got a branch thats getting fairly mature, that needs third party eyes
<jrwren> lazyPower: we definitely need to talk, because I too have a branch. we need to come together.
<lazyPower> are you running my branch for trusty in the UIX prodstack?
<lazyPower> or did you fork it and cycle on your own stuff?
<jrwren> not yet
<jrwren> i forked your branch and hacked it up.
<lazyPower> ok, so my thought is this
<lazyPower> i just landed a big merge from IS that adds some nice goodies in there
<lazyPower> think you can port those to your branch, and we can do a review on tests+polish+actions
<jrwren> https://github.com/CanonicalLtd/beaver-charm and https://code.launchpad.net/~evarlast/charms/trusty/logstash/trunk
<lazyPower> adn then make a proposal for trusty?
<jrwren> I'll take a look.
<lazyPower> oh man
<lazyPower> you like, neutered half the relations
<jrwren> did i?
<jrwren> oh yeah.
<lazyPower>     major rework. remove ampq and redis, add raw tcp
<jrwren> we can put those back.
<jrwren> running redis server seems overkill.
<lazyPower> just add raw tcp, and block config sections with jinja
<lazyPower> well, are you running a 30 node cluster?
<jrwren> if gonna use redis, shouldn't i use the redis charm?
<lazyPower> 30 node cluster + redis queueing = kinda the reference arch for this stack.
<lazyPower> we shoudl be yeah
<jrwren> I found no evidence of any reference arch for this stack :)
<lazyPower> hate me all you want - i got it from here: http://www.logstashbook.com/
<jrwren> hey me too!
<lazyPower> <3
<jrwren> i got the paper copy
<jrwren> I'm really impressed with the typesetting.
<jrwren> Its really a pleasure to read.
<lazyPower> so anywho - if your charm operates more reliably than the franken-java-monster we have now
<lazyPower> lets converge on that - get IS to test it in staging and see how it goes
<jrwren> yeah, lets do that.
<lazyPower> or OIL actually, they would probably be interested in this as well
<jrwren> see also, the warning on page 193 :p
<lazyPower> I'm in malta starting Sunday - can you feesably look at this sometime in the next 2 weeks? I'll lend some later-workday-hours to pair
<lazyPower> after the malta sprint, and we'll go from there
<jrwren> that timing matches us reasonably well.
<lazyPower> i got poked by IS to get this thing in the CS sooner rather than later, and i'm doing one of these numbers @_@
<jrwren> we are JUST getting this into a std. dev env.
<jrwren> another week we may have it into our staging env
<lazyPower> ok sweet, so timing works then.
<lazyPower> Take a look at this MP, and see if this makes sense to you - as this was the big feature branch they wanted landed pre-store-inclusion. http://bazaar.launchpad.net/~lazypower/charms/trusty/logstash/trunk/revision/47
<jrwren> ha! ssl
<lazyPower> kind of important really :)
<jrwren> so... SSL was a reason I went beaver isntead of logstash-forwarder
<lazyPower> <3 them for contributing that
<jrwren> its entirely unimportant if you aren't accepting logs from outside.
<jrwren> all the comms from LS to ES are entirely unencrypted.
<jrwren> its faux security
<jrwren> and much added complexity
<jrwren> but cool that they did it as config.
<jrwren> before I gave up on it I was considering self signed generation and serving that to LSF on relation get
<lazyPower> there's charmhelpers to take care of SSL generation/consumption
<jrwren> nice.
<lazyPower> you know about this right?
<jrwren> i've not seen that part of helpers
<lazyPower> 1 sec, fishing link
<jrwren> so far this patch is +10
<lazyPower> http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/files/head:/charmhelpers/contrib/ssl/
<jrwren> very cool.
<lazyPower> http://bazaar.launchpad.net/~charmers/charms/trusty/nagios/trunk/revision/12
<lazyPower> line88 = consuming of that code, and generating self signed certs
<lazyPower> er, line88 of upgrade-charm hook
<lazyPower> so those may help you moving forward when you need SSL certs
<lazyPower> and you can use self-signed certs
<lazyPower> i nkow there are many cases where that ignites fire, and causes headaches. Namely when dealing with anything on the consuming end that expects a valid CA Signed SSL certificate
<jrwren> yeah, so that works for that use case.
<lazyPower> in term so flogstash - you could push to /usr/local/share/ssl/ca-certificates/ and run update-ca-certificates, and the self signed would no longer raise alarms.
<lazyPower> *push the ca cert
<lazyPower> and that could be done w/ base64 encoding over a relationship
<jrwren> logstash-forwarder has a ca config line
<lazyPower> so perfect
<jrwren> yes, exactly what I was considering
<lazyPower> \o/
<jrwren> but now I don't need it :p
<lazyPower> i find your lack of encryption disturbing ;)
<jrwren> *shrug*
<jrwren> i worked at a security company :p
<jrwren> it get... complecated.
<jrwren> for example, what do you do when you add more units to the logstash service?
<lazyPower> in terms of ssl?
<lazyPower> the way i see it, you have 2 options. hand over all the keys in a peer relationship and install them or 2) go nuts generating keys and do key management
<jrwren> you'll have to do 2
<jrwren> because with 1 your CN no longer matches the address to which you are connecting
<lazyPower> fair, i had not thought about CN based rejections. Stinking common name validation
<jrwren> so you have to use subject alternative names
<jrwren> which is not so easy to automate in openssl command lien
<jrwren> I would love to see it done :)
<jrwren> heck, at that point, someone could write up a very nice "run your own CA" charm :)
<jrwren> so all that said, I see great value in both solutions, hence our building of that beaver charm last week.
<lazyPower> fair enough - i can see/understand the need to GSD before you tackle the wall
<lazyPower> jrwren: i forgot about UOS coming week after the sprint. if we get slammed lets touch base at least and see where we're at in terms of time/exploration.
<lazyPower> and with that note, i'm goign to head out for the evening. Cheers o/
<jrwren> gnight lazyPower travel safely
<moqq> this is correct?:  JUJU_DEV_FEATURE_FLAG=actions juju bootstrap
<moqq> ahhhgg. juju destroy-environment appears to leave the vagrant box image in an unusable state. after i destroy the initial environment and try to bootstrap again, i only get â ERROR juju.cmd supercommand.go:430 cannot initiate replica set: cannot get replica set configuration: cannot get replset config: not authorized for query on local.system.replsetâ
 * thumper frowns
<thumper> wallyworld: you around?
<wallyworld> yeah
<thumper> so I'm trying to upgrade my ec2 env
<thumper> it is currently using 1.20.14
<thumper> my client is 1.22.1
<thumper> juju upgrade-juju says: "no upgrades available"
<thumper> any idea why?
<wallyworld> um
<wallyworld> do you have a tools-url setting in use?
 * thumper looks
<wallyworld> just saw this in the code :-(
<wallyworld> 			// No tools found and we shouldn't upload any, so if we are not asking for a
<wallyworld> 			// major upgrade, pretend there is no more recent version available.
<wallyworld> why oh why
<thumper> juju get-env tools-url says nothing
<thumper> ?
<wallyworld> might be tools-metadata-url
<thumper> 2015-04-24 03:16:00 DEBUG juju.cmd.juju upgradejuju.go:367 found more recent current version 1.20.14
<thumper> 2015-04-24 03:16:00 INFO juju.cmd cmd.go:113 no upgrades available
<wallyworld> so that comment was from the upgrade code
<thumper> that is from the log
<thumper> this is a very vanilla ec2 deploy
<thumper> I'm wondering why we are telling people there are no upgrades available when there obviously are
<wallyworld> me too
<wallyworld> ok, what about juju metadata validate-tools (i think)
<moqq> iâm glad i wasnât going crazy then
<moqq> i thought that was strange too
<thumper> wallyworld: what does the validate tools do?
<wallyworld> if prints the available tools and where it finds them
<wallyworld> or more accurately, the tools it would use
<thumper> http://paste.ubuntu.com/10876012/
<thumper> so... WTF?
<wallyworld> ok so that's good
<wallyworld> good in that your client can fin the expected tol
<wallyworld> tools
<wallyworld> bad in that it refuses to use them
<wallyworld> so we can narrow down where to look for the issue
<wallyworld> i'll read the code a bit to see if anything jumps out
<thumper> wallyworld: also, (since I'm not working today) can you file a bug about the help text for upgrade-juju?
<thumper> wallyworld: it still says minor numbers are dev versions
<wallyworld> sure
<thumper> wallyworld: I did 'juju upgrade-juju --version 1.22.1' and it worked
<wallyworld> hmmm, so the automatic new version selection fails
<wallyworld> the relevant comment
<wallyworld> 		// No explicitly specified version, so find the version to which we
<wallyworld> 		// need to upgrade. If the CLI and agent major versions match, we find
<wallyworld> 		// next available stable release to upgrade to by incrementing the
<wallyworld> 		// minor version, starting from the current agent version and doing
<wallyworld> 		// major.minor+1. If the CLI has a greater major version,
<wallyworld> 		// we just use the CLI version as is.
<bradm> anyone know how you get a charm added to trusty?  bip is currently only in precise, I followed what looked to be the instructions at https://jujucharms.com/docs/stable/authors-charm-store#recommended-charms and filed LP#1401774, but there is literally no movement.
<wallyworld> bradm: marcoceppi_ would be one person to ask, i have NFI
<bradm> I filed this bug about 4 months ago now..
<bradm> marcoceppi_: can you have a look at LP#1401774 when you're about and have time?  trying to get the bip charm into trusty.
<wallyworld> thumper: one guess i have quickly looking at the code is that we still seem to expect to only upgrade from x.y to x.y+1
<wallyworld> that's if we don't specify an explicit version
<wallyworld> so in your case, it was looking for 1.21
<thumper> hmm...
<wallyworld> not sure why it couldn't find that
<wallyworld> and anyway, that's wrong
 * thumper nods
 * thumper goes to make a coffee
<wallyworld> i'll file a bug
<moqq> hey i canât find in the docs anything detailing exactly what ports/routes are needed between the juju client and the rest of the cluster. is it ssh from the client machine to every machine in the cluster?
<moqq> and what the âtools storageâ port 8040 is exactly used for / by whom
<wallyworld> moqq: tools storage port is no longer used for new installs
<moqq> oh excellent
<wallyworld> the main port is 17070 used to connect the client to the state servers
<wallyworld> and ssh
<moqq> the 17070 is a mongodb port?
<wallyworld> the client can ssh to each node, but it can proxy via the state server i think
<moqq> ah ok
<wallyworld> no, mongo uses 37017
<wallyworld> but only the state server connects to that
<moqq> okay. and there is only one state server per cluster?
<moqq> per âenvironmentâ *
<wallyworld> by default, but there is high availability also so a cluster of state servers is supported
<moqq> ah ok
<wallyworld> 1, 3, 5, 7 etc
<wallyworld> odd numbers because it uses a mongo replicaset
<moqq> yep
<moqq> so, to issue commands to an environemnt (like deploy or actions), the machine running the juju client needs only to be able talk the master server(s) via tcp 37017
<moqq> correct?
<wallyworld> 17070
<moqq> erm*
<moqq> yes
<wallyworld> yes
<moqq> excellent, thank you
<wallyworld> sure, np
<wallyworld> i can't recall if ssh proxy is enabled by default
<wallyworld> if it is, you can also ssh to worker nodes via the state server also, so 17070 should be all you need the client to connect to
<moqq> yeah that makes sense. neat
<moqq> just curious, what protocol is it carrying over 17070?
<wallyworld> proxy-ssh is true by default for new environments
<wallyworld> websocket
<moqq> over https?
<wallyworld> https based
<moqq> awesome
<wallyworld> when an env is bootstrapped, certs are generated
<moqq> i saw those in there, that makes sense.
<moqq> thanks again for the info. getting this into production with a handful of custom charms over the coming week and a half so i will likely have a few more inquiries!
<wallyworld> moqq: sure, np. there's more people in #juju-dev so you will have most luck asking in there
<wallyworld> ask any questions and we'll try and help
<wallyworld> there's also the mailing list
<wallyworld> good luck with the roll out
<moqq> awesome, thank you
<lazyPower> bradm: Updates to trusty are predicated by test inclusion - if you can contribute some amulet tests to the bip charm it would expedite the process
<lazyPower> ah disregard, i made that statement while still reading backlog and not looking @ the bug
 * lazyPower stands in teh corner
<bradm> lazyPower: ayup.  as far as I can tell there's tests there.  I might need to update the branch from precise trunk since its been filed so long ago
<lazyPower> bradm: sorry about that - i dont see it in our RevQ, and id ont know why thats the case
<lazyPower> status new + linked branch should have pulled it in
<bradm> lazyPower: I'm planning to rewrite it in services framework, it should be pretty simple
<lazyPower> :thumbsup: I look forward to seeing that :)
<bradm> lazyPower: no worries, I couldn't see it in the review queue either, so I finally got time to go looking
<bradm> lazyPower: I have a couple of thruk charms to throw charmers way once I get tests added
<bradm> lazyPower: those are all in the services framework
<bradm> lazyPower: anyway, for the bip charm push up to trusty, if we can get it on someones radar to see whats going on, that'd be awesome.  its not a hugely high priority, bip is kind of my play charm that I push along when I get a chance
<jcapel> I thought I'd give juju a go on my freshly installed 15.04 server, but juju-quickstart fails. It seems to assume the system is using upstart (it fails on start juju-db)
<bloodearnest> hmm, can I file/reassign a bug to a specific charm? Seems I can only assign to "charms" project
<jamespage> marcoceppi_, hey - how do I see why the charm release yesterday has not ingested into the store?
<marcoceppi_> jamespage: great question, no idea anymore. If it passes proof it should be ingested. Are you not seeing it in the gui or not deployable?
<jamespage> marcoceppi_, https://jujucharms.com/cinder/
<jamespage> vs the branch on launchpad
<marcoceppi_> https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/cinder
<marcoceppi_> seems revision 18 is in the store
<marcoceppi_> this is a charmstore api thing, you'll need to ping rick_h_ & co to investigate
<marcoceppi_> jamespage: actually, they do seem to be the same
<marcoceppi_> so this might be a larger issue
 * marcoceppi_ investigates
<marcoceppi_> jamespage: it seems that what's in lp:~openstack-charmers/charms/trusty/cinder/trunk is in the charmstore proper
<marcoceppi_> the gui seems to have the same revision, but the revision history is off
<marcoceppi_> which makes sense, I think the api is mid-transision away from tracking dvcs info
<marcoceppi_> rick_h_ and the ui team would know more
<rick_h_> jamespage: marcoceppi_ there's a bug with the new charmstore not getting the up to date changelog and the guys on are it. The charm itself, the readme, etc is all good but it's missing the latest revisions in the changelog.
<marcoceppi_> rick_h_: that's what it seemed like, I figured we were just going to drop that in a juju publish world
<rick_h_> marcoceppi_: well our goal will be to try to keep it if we can tell but yea. Might end up being a link to the homepage/etc
<marcoceppi_> rick_h_: ack, thanks for the clarification
<Mmike> Hey, guys,. I run `juju run --service myservice "someSuperDuperStuff.sh`, and that fails with timeout for some units. But at the same time I'm able to do 'juju ssh myservice/{0,1,2,3...}' with no problem(s)
<Mmike> how is juju run implemented, and why whould it time out, how do I start debugging this?
<marcoceppi_> Mmike: juju run is run as a hook context, so if you have hooks running or is someSuperDuperStuff.sh never exits
<marcoceppi_> it'll timeout
<Mmike> marcoceppi_: aaaa, makes sense!
<Mmike> marcoceppi_: thnx! :)
<Mmike> i do have hooks still running
<marcoceppi_> Mmike: so the juju run is queued
<marcoceppi_> Mmike: you'd probalby be interested in actions, which is like run with some structure and async nature
<Mmike> marcoceppi_: for now I can really do 'juju ssh' in a for loop
<Mmike> marcoceppi_: is there a document(ation) describing how to use juju actions?
<marcoceppi_> Mmike: yes, there is: https://jujucharms.com/docs/stable/authors-charm-actions
<Mmike> oh
<Mmike> neat!
<Mmike> marcoceppi_++ thnx
<urulama> jamespage: is this the proper cinder now? https://jujucharms.com/cinder
<jhobbs> Hi - is there a way to specify a revision of the launchpad branch for a charm in deployer bundles?
<hatch> is there any way to expose a port on a unit from the juju CLI?
<jrwren> nope
<hatch> ok how about any way to expose a port besides the hook context
<hatch> doesn't look like I cna change it from the aws console
<jrwren> yeah, you can, edit the security group.
<lazyPower> hatch: juju run --service "open-port 80"
<lazyPower> Anon hook context == hook context. I use this when developing and i forget to set an open-port statement.
<hatch> lazyPower: very cool trick! Thanks!
<jrwren> been looking for that for a year(almost) is it documented?
<hatch> (not that I could find) heh
<hatch> well juju run is
<hatch> so this is just a really cool technique :)
<jrwren> the key there is that the unit tools path is in PATH when using --service. That is great!
<jrwren> bah, its right there in the juju run help. Now I feel stupid.
<hatch> haha I didn't even think to try juju run so... :)
<lazyPower> Tricks of the trade
<hatch> thanks again lazyPower
<lazyPower> cheers
#juju 2015-04-26
<jackweirdy> Is anyone using juju to prepare their development environment?
#juju 2016-04-25
<marcoceppi> magicaltrout: heh, YOU POLLUTING THE CHARM DEVELOPER PROGRAM WITH ABANDONDED INSTANCES?!
<magicaltrout> sorry marcoceppi ! I don't know what is left in the disconnected world, if I have stuff running, feel free to shut it down
<Garyx> Anyone have any idea of when juju 2.0 RC1 or next Beta will rear it's head?
<bdx> openstack-charmers: the issues I was experiencing with inability to modify the 30G default account quotas, and swift<->rgw api incompatibilities for rgw buckets has been remedied in Jewel :-)
<bdx> I'm so distraught that I've a hammer deploy :-( .... I've successfully preformed an upgrade from hammer to jewel on test stacks ..... I'm trying to get a stable upgrade/migration procedure that I could apply to my production hammer deploy, I think I'm pretty close..... I'm wondering if there are any gotcha's the storage team might be able to unveil concerning upgradin hammer to jewel ?
<marcoceppi> bdx: what's Jewel?
<gnuoy> marcoceppi, maybe refering to the Ceph LTS which is code named Jewel. not sure of the context
<bdx> the latest stable release of ceph packaged in xenial
<bdx> oooh nm. Its not in the xenial archives :-(
<bdx> only ceph==10.1.2 .... grrr
<bdx> openstack-charmers: is there a way we can bump ceph to jewel for xenial?
<bdx> openstack-charmers: ceph v10.2.0
<bdx> storage-peeps: http://docs.ceph.com/docs/master/release-notes/#v10.2.0-jewel
<ReSam> bdx: I think xenial includes a release candidate of jewel - and it will be upgraded later to the final release
<bdx> ReSam: thanks, I see that now. Final release of 16.04 charms?
<marcoceppi> bdx: almost all the openstack-charmers are in Austin at ODS, so responses might be delayed
<bdx> marcoceppi: totally, thx
<lazyPower> mbruzek - i know you're occupied atm, but here's where we left off at standup https://github.com/juju-solutions/layer-tls/pull/21
<lazyPower> lets see if we can poke a hole in this, but this looks like its doing what i want it to do
<magicaltrout> urgh bloody interfaces
<magicaltrout> can I prod something to find out what states my charm has set?
<lazyPower> magicaltrout charms.reactive get_states
<magicaltrout> ta
<magicaltrout> lazyPower: either I'm having a major brain fade or something is wonky
<magicaltrout> if I'm in juju debug-hooks how do I get access to charms.reactive?
<lazyPower> its included in layer-basic, so its on $PATH if you're in a hook context
<magicaltrout> thats what I thought
<magicaltrout> root@ip-172-31-22-199:~# charms.reactive get_states
<magicaltrout> bash: /usr/local/bin/charms.reactive: Permission denied
<magicaltrout> marcoceppi you like this random stuff
<magicaltrout> what am I doing wrong/broke
<lazyPower> wat
<marcoceppi> magicaltrout: obviously you have not acended past root to reach god level status which is the permission required
<magicaltrout> hehe
<marcoceppi> cory_fu: ^^
<marcoceppi> magicaltrout: can you strace the command and paste the output?
<magicaltrout> that one is easy
<magicaltrout> root@ip-172-31-22-199:~# strace charms.reactive get_states
<magicaltrout> strace: Can't stat 'charms.reactive': No such file or director
<magicaltrout> +y
<marcoceppi> magicaltrout: strace  /usr/local/bin/charms.reactive for thrills
<magicaltrout> ah that ones a treat
<magicaltrout> http://pastebin.com/EzRkWye5
<magicaltrout> same old stuff
<marcoceppi> magicaltrout: can you ls -lah that file?
<magicaltrout> -rw-r--r-- 1 root root 360 Apr 25 19:00 /usr/local/bin/charms.reactive
<marcoceppi> magicaltrout: well there's ya problem
<marcoceppi> chmod +x that file
<magicaltrout> yeah that works
<magicaltrout> weird
<marcoceppi> magicaltrout: super weird
<magicaltrout> yeah its like that on my other unit as well
<magicaltrout> Wily & Juju 2.0-beta4 according to my status
<magicaltrout> problem is no one cares about Wily... its like the forgotten love child.... ;'(
<magicaltrout> okay
<magicaltrout> i have an interface question cause I can't get this to work
<magicaltrout> and you lot seem to think this stuff is easy ;0
<magicaltrout> http://pastebin.com/HTfgbSbZ
<magicaltrout> dcosmaster.available is set by the master charm when its installed and running
<magicaltrout> if I debug the master charm i can see it set
<magicaltrout> but I don't seem to be picking it up on the requires end
<magicaltrout> any tips?
<magicaltrout> I can see the various hooks being triggered in the debug log
<cory_fu> magicaltrout: That file should be +x when it's installed from the wheelhouse by pip.  If it's not, then I can only guess that it's a problem with pip on wiley?
<magicaltrout> i like the way you answer that with a question mark cory_fu as if I have a any idea how pip works! ;)
<magicaltrout> I do have a question though
<magicaltrout> @hook('{requires:dcos}-relation-{joined,changed}')
<magicaltrout> i have that in my interface
<magicaltrout> how can i find out what it things requires:dcos is
<magicaltrout> because when i hard code it to dcosmaster my hook runs
<magicaltrout> and when its templated
<magicaltrout> it doesn't
<magicaltrout> i assumed it picked it up from metadata.yaml
<marcoceppi> magicaltrout: it gets that from the metdata.yaml
<marcoceppi> magicaltrout: what's the name of the interface?
<cory_fu> It does pick it up from metadata.yaml.  It should match any relation in metadata.yaml in the "requires:" section that has "interface: dcos"
<marcoceppi> dcos or dcosmaster?
<magicaltrout> "requires":
<magicaltrout>   "dcosmaster":
<magicaltrout>     "interface": "dcos"
<marcoceppi> magicaltrout: that will be triggered anytime dcosmater-relation-joined/changed is called
<magicaltrout> yeah well thats what i thought
<magicaltrout> but that only happens when i remove the templating
<magicaltrout> i realise you'll think i'm the crazy mad man at this point
<magicaltrout> but its actually true :P
<marcoceppi> magicaltrout: I believe you and defer to my associate, cory_fu ;)
<marcoceppi> magicaltrout: linky to the full requires.py file?
<magicaltrout> http://pastebin.com/nZWQ1brm its just a hacked up one from the docs
<magicaltrout> doesn't do much at the mo
<magicaltrout> ignore line 11 I deliberately broke it to check its execution :)
<marcoceppi> magicaltrout: is it because of the class name?
<magicaltrout> doubt it
<magicaltrout> i shall check
<magicaltrout> oh wtf
<magicaltrout> looks like you're correct marcoceppi
<magicaltrout> spent bloody ages looking at that wondering why filling in the templates worked fine
<magicaltrout> teaches me to copy and paste
<marcoceppi> magicaltrout: copy and paste - it's the reason we built layers ;)
<marcoceppi> magicaltrout: lesson learned, we need to have a charm create -t interface
 * marcoceppi opens bug
<magicaltrout> yeah that would be really good
<magicaltrout> oh well i can return to actually implmenting the busines end now :P
<marcoceppi> \o/ another blocker unblocked
<magicaltrout> yeah i'm well in a hole in terms of time and apachecon, the less blockers the better please :P
<marcoceppi> magicaltrout: well please feel free to aggressively ping me
<marcoceppi> magicaltrout: happy to make sure thta's a success for you
<marcoceppi> magicaltrout: and to basically defer all the hard stuff to cory_fu
<magicaltrout> hehe
<magicaltrout> I think the juju stuff is mostly in place. For the demo I plan to spin up Apache OODT for Data Management in DC/OS and use the Big Data bundles to spin up a hadoop platform and have some interaction between them all, probably similar to cory_fu's ssh failed attempts
<magicaltrout> suck them into the platform via Apache OODT for catalog and search stuff and Zeppelin for the analysis
<magicaltrout> which is a pseudo real world scenario we have, although we don't currently use DC/OS clearly as its rather new
<magicaltrout> and honestly, OODT, Mesos, Zookeeper, Hadoop, Zeppelin, how much more Apache tech could you have in a talk thats powered by Juju?
<magicaltrout> i don't think its possible
<magicaltrout> oh and Tomcat and Solr and Tika
<magicaltrout> blimey
<marcoceppi> magicaltrout: it's like the entire apache catalog ;)
<magicaltrout> yeah its not far off, but also is real life, so its not like i'm trying to cram it all into just to make a point
<magicaltrout> but it certainly helps ;)
<marcoceppi> :D
<magicaltrout> marcoceppi: whats the name of the stuff that houses downloads in 2.0 and is there any documentation for the feature I've forgotten? :)
<magicaltrout> hmm looks like classname might not be the problem
<magicaltrout> fresh install back to broken
<magicaltrout> fscking templates
<magicaltrout> cory_fu: http://pastebin.com/4LWd3s8q that runs and logs fine
<magicaltrout> http://pastebin.com/6WVCExFc
<magicaltrout> that sinks without trace
<magicaltrout> http://pastebin.com/x1yUwwCz
<magicaltrout> thats my metadata
<magicaltrout> suggestions please! :)
<magicaltrout> ack ack
<magicaltrout> bloody typo
<magicaltrout> always the users fault
<cory_fu> magicaltrout: Don't use -broken in reactive
<cory_fu> Also, your hook line should be @hook('{requires:dcos}-relation-{joined,changed}')
<cory_fu> Other than that, what's the problem?
<magicaltrout> yeah i saw it ;(
<cory_fu> I was in a meeting, and not really able to pay attention before.  :(
<magicaltrout> if you shouldn't use broken you should probably get evilnick to touch up the docs: https://jujucharms.com/docs/devel/developer-layers-interfaces
<cory_fu> Yeah, we should update that.  It will only actually cause problems if you use set_state in there, but it doesn't work like you'd expect so it's better to avoid it entirely
<magicaltrout> cool
<magicaltrout> as you're here and marco isn't whats the name for that charm storage stuff?
<magicaltrout> not "storage" but where you store artifacts
<cory_fu> Are you asking about resources?
<magicaltrout> my google-fu is failing me
<magicaltrout> that be the one
<magicaltrout> i knew it began with r
<cory_fu> :)
<cory_fu> magicaltrout: So I'm still confused what your issue is with the interface layer
<kjackal> cory_fu kwmonroe admcleod1: this PR on hue does a lot of cleaning and adds integration to ZK and Hive, integration with YARN & HDFS was already there (as far as I remember) https://github.com/juju-solutions/layer-hue/pull/6
<cory_fu> You definitely should not hard-code the name of the relation in the @hook line
<magicaltrout> i don't it was a typo and lack of understanding :)
<cory_fu> Ah, ok
<magicaltrout> not the hard coding was just because i couldn't see why it wasn't running
<magicaltrout> and to prove to myself i wasn't completely mad
<cory_fu> arosales: As kjackal pointed out above, we think that Hue is basically ready (pending the PR) and we can hopefully have it cleaned up and done by EOW
<kjackal> arosales: Just tested upgrade from spark 1.6.0 to 1.6.1 and it works
<magicaltrout> marcoceppi: with juju resources, on the first execution of a charm download an archive
<magicaltrout> then in the charm dump it into resources so in future it doesn't have to fetch it again
<arosales> cory_fu: kjackal  interesting and good to hear.
<arosales> kjackal: is that with spark only or with hadoop too?
<kjackal> this is for spark 1.6.1 to 1.6.0 and a fixed version of Hadoop 2.6.0
<arosales> kjackal: gotcha, and I think the hadoop admcleod1 is working on is 2.7.x so perhaps a little work there, but good to hear that is  close.
<arosales> kjackal: burning the mid night oil too I see ;-)
<kjackal> arosales: The binary was for Hadoop 2.6.0+ . I do not think there is a Spark binary for Hadoop 2.7.0 only
<kjackal> arosales: regarding Hue the misunderstanding (at least from my part) was that we do not need the entire functionality of Hue, we need integration with YARN. We can gradually integrate Hue with the rest of the Hadoop ecosystem
<marcoceppi> magicaltrout: that's not how resources work
<arosales> kjackal: for sure we can always build from there
<magicaltrout> marcoceppi: maybe, but it should be how resources work! :P
<magicaltrout> for example, DC/OS it has to download a 500mb file to bootstrap
<magicaltrout> if it was a resource, that would be pretty instant, not that its that slow over the net, but you get my drift
<magicaltrout> so I could define it as a resource and have people upload a bootstrap tarball to the Juju server resource pool
<magicaltrout> or, I could have some cool hook that grabs it on the first run, and dumps it into the resource pool so future runs could grab it from there instead of the web
<marcoceppi> magicaltrout: well...
<magicaltrout> well indeed!
<magicaltrout> boom
<magicaltrout> semi working DC/OS
<magicaltrout> what a hack!
<magicaltrout> ;)
<marcoceppi> magicaltrout: all great production deployments start as hacks :)
<magicaltrout> https://ibin.co/2f1dfqzROiqs.png
<magicaltrout> thanks marcoceppi nice charm developer program 12 node cluster ;)
<magicaltrout> (don't worry marco, I switched it off :P )
#juju 2016-04-26
<marcoceppi> magicaltrout: no worries, you can leave them running for a few weeks before I start to ask questions
<marcoceppi> esp since I can see what's running on them and anyting with dcos in it intrigues me
<ReSam> how can I use "juju upgrade-juju" to upgrade my machines from beta5 to beta6?
<gnuoy> jamespage, thedac, tinwood, beisner, wolsen I've move our layers and interfaces onto https://github.com/openstack-charmers and repointed our entries on http://interfaces.juju.solutions/
<gnuoy> s/move/moved/
<ReSam> I'm trying to install glance - but it fails at setting up the mysql db with: "Host 1.2.3.4  is not allowed to connect to this MySQL server". But the IP mentioned is exactly the IP of the machine...
<ReSam> seems to be this bug: https://bugs.launchpad.net/charms/+source/mysql/+bug/1305582
<mup> Bug #1305582: relation with mysql fail when mysql and glance are deployed on the same node <cts> <openstack> <mysql (Juju Charms Collection):Confirmed> <https://launchpad.net/bugs/1305582>
<xnox> jamespage, hypothetically, instead of two network cards, could two different vlans be used on a single network card for openstack deployment?
<xnox> aka foo.2001 & foo.2002, instead of two connections?
 * xnox ponders how good support for vlans is in juju/lxd/openstack world =)
<BlackDex> hello there
<BlackDex> i get the following
<BlackDex> 2016-04-26 14:24:36 ERROR juju.cmd supercommand.go:429 cannot assign unit "mysql/0" to machine 1: machine is not alive
<BlackDex> i installed the machines manually with ubuntu 14.04.4
<BlackDex> and after that added them with juju add-machine ssh:ubuntu@192.168.7.10
<BlackDex> why isn't this working?
<aisrael> Is there a workaround for bootstrapping xenial on aws? Bootstrap can't find any xenial images
<magicaltrout> aisrael: I asked on the ML, Mark said there will be images later this week hopefully
<SaltySolomon> hi
<SaltySolomon> Can I ask some support questions here, or is there a differnet channel?
<magicaltrout> SaltySolomon: you can try, this is the correct place
<SaltySolomon> We are currently trying to setup openstack with maas and juju, we got maas set up and working, but everything else is bugging out when we try to install juju
<magicaltrout> you might struggle with openstack questions, I believe most of them are in austin
<aisrael> magicaltrout: thanks!
<SaltySolomon> Bootstraping Juju takes ages
<marcoceppi> SaltySolomon: where's teh bugging start? does bootstrap complete?
<SaltySolomon> well, it says bootstraping juju, but it doesn't really finish, does it normally take a long time?
<marcoceppi> SaltySolomon: shouldn't be more than 10 mins
<marcoceppi> SaltySolomon: can you try to bootstrap again, with the --debug flag, and paste the output in paste.ubuntu.com and link here?
<marcoceppi> SaltySolomon: also, what version of juju (juju version)
<SaltySolomon> Okay, we got the version that is included with the liberty release on ubuntu server 15.01
<mbruzek> marcoceppi: Regarding the new charm push and charm publish commands.
<mbruzek> marcoceppi: Is there any special concerns when the charm was in the charm store from the old way and we want to push/publish using the new way?
<mbruzek> kwmonroe: ^
<lazyPower> mbruzek - just be aware that it disables the VCS ingestion route for that charm. Otherwise nope, it just continues on. You may need to tweak the ACLs on first upload... but thats true with any charm push
<mbruzek> lazyPower: I thought there was some caveat with publish. That we could not go back to the old way or something else... Like what if a charm is already in the store and the author pushes to the private namespace. Is there some kind of link problem there?
<rcj> aisrael, xenial AMIs should be working now
<lazyPower> mbruzek - thats what i was referring to that it disables VCS ingestion
<mbruzek> thanks rcj
<aisrael> rcj: Is that a recent fix?
<lazyPower> mbruzek - once you charm push, you wont be able to go back to pushing to launchpad. You will have to charm push future revisions
<mbruzek> lazyPower: ack
<aisrael> rcj: bootstrapping xenial working <3
<lazyPower> \o/
<Odd_Bloke> aisrael: \o/
<marcoceppi> SaltySolomon: could you run `juju version` that could be a number of different releases
<tinwood> gnuoy, ack. Are we moving to a pull request workflow for them?  e.g. fork, and PR?
<SaltySolomon> 1.25.5-wily-amd64
<gnuoy> tinwood, moving to openstack gerrit eventually
<SaltySolomon> marcoceppi, http://paste.ubuntu.com/16065407/ with version 1.25.5-wily-amd64
<marcoceppi> SaltySolomon: ah, this is the openstack installer, not too familiar with this, stokachu ^?
<stokachu> SaltySolomon: your maas api key is incorrect
<stokachu> SaltySolomon: you copy it from the maas ui under your user's account
<SaltySolomon> We tripplechecked it and it is the right one
<stokachu> SaltySolomon: did you create your own api key or let maas generate it
<SaltySolomon> create our own
<stokachu> ah that's why
<SaltySolomon> once we had the w
<stokachu> we check for ':' in the api key
<SaltySolomon> Well, it generated a new one for us
<SaltySolomon> It wasn't the default one
<SaltySolomon> So we let maas generate it for us
<stokachu> so the api key should be 'abcd:abcd:abde'
<SaltySolomon> Also once we had a typo in it
<SaltySolomon> Then it didn't find any machines, later we used the right key and it even deployed on machine with juju
<stokachu> SaltySolomon: ok so does your api key have that format i described? 'aaaa:bbbbb:ccccc'
<SaltySolomon> yes it does
<stokachu> ok you want to `sudo openstack-install -u` and then remove ~/.cloud-install
<stokachu> and start again entering that new api key
<SaltySolomon> okay, it finds the maas nodes
<tinwood> gnuoy, okay, but for now?
<SaltySolomon> Maas webinterface says it is deployed, the node output too,  but the installer, is well stalling
<SaltySolomon> stokachu ^
<stokachu> SaltySolomon: can you pastebin ~/.cloud-install/commands.log
<SaltySolomon> http://paste.ubuntu.com/16065965/
<SaltySolomon> Here you go stokachu
<stokachu> SaltySolomon: so it's probably still going through the cloud-init stuff with the system
<stokachu> has to do apt upgrade etc
<SaltySolomon> the client has no connection to the inet
<stokachu> do you have a proxy?
<SaltySolomon> okay, back it does have internet access, so it is probably the patching
<stokachu> ok
<stokachu> yea it could take a few minutes to do all that
<SaltySolomon> Node is currently just saying "Installation finished"
<SaltySolomon> Okay, wrong that was sme old stuff, we got the same error as before, will post you a pastebin in a sec
<SaltySolomon> http://paste.ubuntu.com/16066144/ here you go stokachu
<stokachu> SaltySolomon: looks like it's failing to upload the juju tools during bootstrap
<stokachu> SaltySolomon: you sure those deployed nodes can reach the internet?
<cory_fu> tvansteenburgh, kwmonroe: https://github.com/juju-solutions/bundle-apache-processing-mapreduce/pull/4
<tvansteenburgh> cory_fu: i'd like to know why it's passing tests before fixing it
<cory_fu> tvansteenburgh: Yeah, that's very strange.  I really don't understand it
<cory_fu> tvansteenburgh: But it's definitely passing: http://reports.vapour.ws/all-bundle-and-charm-results/charm-bundle-test-parent-6892/charm/aws/16
<cory_fu> tvansteenburgh: I'd like to point out that the message the stack trace is waiting for doesn't match the message in the current version of the test
<cory_fu> Not that it matters, since the current version of the test also doesn't match what the slave should be setting
<aisrael> I published a charm (to my personal namespace), but forgot to change bzr-owner before I published, so now it's showing up in the ~charmers namespace. I've changed bzr-owner now, re-promulgated, but not sure if there's anything else I need to do to fix it.
<aisrael> i.e., it's still showing up in the wrong place in the store
<SaltySolomon> stokachu, we tried again with packet forwarding activated, this time the error is: http://paste.ubuntu.com/16067371/
<stokachu> SaltySolomon: so youre still getting this error iled to connect to streams.canonical.com port 443: Connection timed out\ntools from https://streams.canonical.com/juju/tools/agent/1.25.5/juju-1.25.5-trusty-amd64.tgz d
<stokachu> something is still blocking you from accessing streams.canonical.com
<cory_fu> aisrael: bzr-owner only affects what Juju Cards show as the source, and is only a stop-gap until they fix Cards.  However, you have to set the bzr-owner for each revision that you push
<aisrael> cory_fu: Ok. Any idea why it'd show up in ~charmers vs. my namespace?
<cory_fu> Was it previously promulgated in ~charmers?  You may have to unpromulgate it from there
<cory_fu> What's the charm ID?
<aisrael> I don't think it was promulgated to ~charmers
<aisrael> it should be cs:~aisrael/trusty/plex-0
<aisrael> but my page in the cs points it to cs:trusty/plex-0
<aisrael> ok, I think I unpromulgated it.
<cory_fu> aisrael: Yeah, it's not promulgated now but https://jujucharms.com/plex/trusty/0 is still showing up and I don't know why
<cory_fu> https://jujucharms.com/plex/ rightly 404s
<cory_fu> https://jujucharms.com/u/aisrael/plex/trusty/0 looks right as well
<aisrael> but this works: https://jujucharms.com/plex/trusty/0
<cory_fu> I have no idea where the first is getting ~charmers.  Only thing I can possibly see is that, in the perms, write is set to charmers instead of you
<cory_fu> Yeah.  It shouldn't
<aisrael> and https://jujucharms.com/u/aisrael/ shows it's owned by charmers
<aisrael> Hmm. write perms..
<cory_fu> aisrael: Also note, user pages seem to be a bit out of whack with the new publishing process: https://github.com/CanonicalLtd/jujucharms.com/issues/249
<SaltySolomon> @stokachu, thanks a ton, it was exactly that problem, the nodes couldn't reach the internet
<stokachu> cool, glad to hear
<cory_fu> kwmonroe, kjackal, admcleod1 (if you're around): Does this look ok to you?  https://github.com/juju-solutions/layer-apache-hadoop-namenode/commit/e6ad8fd44f119fdc411c6104498276aa4d2ac1a8
<cory_fu> The "update on fencing" sort of worked, but only for the unit that was transitioning.
<cory_fu> I could maybe make it work for both but it would be a bit hairy.  But I'm not sure I like the every-minute-cron solution, either
<kjackal> lgtm
<kjackal> do we have any other option at this time?
<kjackal> Lets break it fast :)
<cory_fu> I could make the fencing solution more complex (it would require doing a SSH to the other NN to launch juju-run from there to update the status)
<cory_fu> Maybe we can do that in the future
<kjackal> +1 for pushing this out now and improve it as we go
<kwmonroe> yeah cory_fu, cron */1 kinda boo, but i think it's a good stab for now.  also i thought i was reading some hardcore productive code for a minute there.  then i realized that whole nn_status file is just for status.  good grief!  and nice job :)
<lazyPower> bdx - MFW i think to myself "Man, why didn't we make a common thing to copy out certificates to path..."
<lazyPower> bdx  then i recall doing a review... and find out you contributed this in tlslib :D
<lazyPower> high five sir
<lazyPower> s/common thing/function/
<ReSam> anyone here gonna help with the openstack keystone charm? or should I head over to some openstack channel?
<ReSam> keystone fails with "hook failed: config-changed" and in specific the function _ensure_initial_admin seems to fail... (it's tried 3 times until it gives up)
<ReSam> and: INFO worker.uniter.jujuc server.go:173 running hook tool "status-set" ["blocked" "Ports which should be open, but are not: 5000, 35357"]
<cholcombe> do we have a centos image we can deploy on ec2 with juju?
<cholcombe> i want to test some compatibility
<a123> I've been trying to run juju bootstrap --config default-series=xenial lxd-test lxd --debug from behind a work proxy which ultimately fails with the message: 2016-04-26 21:13:42 ERROR cmd supercommand.go:448 failed to bootstrap model: cannot start bootstrap instance: can't get info for image 'ubuntu-xenial': not found. This is running inside a fresh Ubuntu 16.06 VM. I have the same setup at home, and all works perfectly. Suggestions?
<a123> that's 16.04
<magicaltrout> aww a123
<magicaltrout> you need to grab an image i suspect
<magicaltrout> a123: i'm not sure about the syntax, i think its changed a bit but try something like
<magicaltrout> lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty
<magicaltrout> or
<magicaltrout> lxd-images import ubuntu xenial amd64 --sync --alias ubuntu-xenial
<a123> Ah. ok. I'll give that a try. I didn't realize bootstrap would check locally. I'm curious though, why are there 2 different methods of grabbing images? Why doesn't bootstrap use lxd-images...?
<magicaltrout> a123: dunno :)
<magicaltrout> LXD local does work though i have a bootstrapped setup here
<a123> is your bootstrap using the newly release 2.0?
<magicaltrout> i just installed a fresh xenial image and did apt-get
<magicaltrout> i've been running a self built LXD juju for a while and i did notice a few differences in the bootstrap
<magicaltrout> although it could just be me getting old
<a123> ok. sounds close enough to what I did. apt-get followed by setting up zfs as a backing store, then juju bootstrap.... As I mentioned, works great w/out being behind a proxy.
<magicaltrout> well
<a123> The image import syntax has changed a bit, so working on that now.
<magicaltrout> also check
<magicaltrout> lxc image list
<magicaltrout> it will also try and hook up to  streams.canonical.com for the tools
<magicaltrout> if that fails i'm pretty sure it will be sad as well
<magicaltrout> i'm not sure what error you'd get there
<cory_fu> admcleod1: https://github.com/juju-solutions/bundle-apache-processing-mapreduce/pull/5 look ok to you?
<cory_fu> admcleod1: Also, if you're ok w/ the HA as it stands now, I'd like to get it merged.  Maybe test it some more today and let me know if you hit anything, and if not I'll merge it tomorrow?
<cory_fu> I'm thinking we should  squash the merges, though, because the commit histories are quite loquacious.
<magicaltrout> check out the big word!
<cory_fu> :)
<cory_fu> Alright, well I'm EOD.  Have a good one!
<magicaltrout> boooo
<cory_fu> :)  Gotta go celebrate a friend's b-day
<magicaltrout> i'm too old for those
<magicaltrout> have fun!
#juju 2016-04-27
<axisys> on my 16.04 I tried to follow this https://jujucharms.com/get-started and failed miserably
<axisys> $ juju quickstart mediawiki-single
<axisys> juju: command not found
<axisys> That's the step 2
<axisys> I already went through step 1
<axisys> any suggestion how to get it working?
<admcleod1> cory_fu: looks good
<lazyPower> axisys i think thats a typo, it should read juju-quickstart mediawiki-single
<lazyPower> however the fact its saying juju isn't found isn't promising...
<lazyPower> axisys if you wander back and still need help i'll be around a couple hours longer. feel free to ping and i'll help get you sorted
<a123> I'm having trouble building juju(cb347bb). Following the instructions in the README.md results in: cannot find package "github.com/Azure/azure-sdk-for-go/Godeps/_workspace/src/github.com/Azure/go-autorest/autorest/mocks"
<lazyPower> a123 check in #juju-dev, the core hackers that are around should be able to lend a hand
<a123> thanks lazyPower
<sam_yan> To begin juju,should I use ubuntu-server or ubuntu-desktop?
<sam_yan> when I "juju quickstart mediawiki-single",juju gui is not in my browser
<magicaltrout> sam_yan: what version of juju are you running for a start?
<sam_yan> 1.25.5-wily
<sam_yan> need in ubuntu-server  ? I  use ubuntu-desktop
<magicaltrout> you read my DCOS tweet  you aiming to get to that point?
<magicaltrout> or just general hacking around with Juju?
<sam_yan> have not. I am a newer.I read the "install juju and deploy your services in minutes"
<magicaltrout> https://twitter.com/sam_yankun you're not that person who looks like an owl? :P{
<sam_yan> I am
<magicaltrout> so https://twitter.com/sam_yankun/status/724927897123852288 was you ;)
<magicaltrout> anyway! On your main computer you can run either run Desktop or Server
<magicaltrout> doesn't matter
<magicaltrout> I run my main juju controller in the data centre so I run ubuntu server but you can use desktop locally as well
<magicaltrout> it doesn't matter
<magicaltrout> also, if you're starting from scratch, grab a copy of Xenial if you can
<sam_yan> ok . https://jujucharms.com/get-started  I am learning this.
<magicaltrout> it has Juju 2.0 beta which you're better off getting started with
<magicaltrout> so my controller runs Ubuntu Server Xenial
<sam_yan> but  after "juju quickstart mediawiki-single",there is no response
<magicaltrout> okay well that should work
<magicaltrout> run juju status
<magicaltrout> does it say your stuff is up and running?
<magicaltrout> if you want a gui, run "juju deploy juju-gui"
<sam_yan> it says "service unknow"
<sam_yan> https://jujucharms.com/get-started    it says "running this command will open the juju gui in your browser"
<magicaltrout> juju status says service unknown?
<magicaltrout> that said, it will only open juju gui once it's bootstrapped a new environment, so you need to go through the stuff you see in the terminal in that page first
<sam_yan> i will try
<magicaltrout> sam_yan: basically, juju should ask you for AWS credentials or something, so it has somewhere to host your units
<magicaltrout> then when you fill them in, it should bootstrap a node in the cloud to run the controller, and if it or you deploy juju gui it will bootstrap another node to run juju gui
<sam_yan> I use vmware,it matters?
<magicaltrout> dunno
<magicaltrout> I'm not sure how that quickstart stuff works I've not used it. There is also juju local which will deploy stuff to your computer as opposed to cloud services
<magicaltrout> if you want to test lcoally
<sam_yan> where?
<magicaltrout> where what?
<sam_yan> juju local
<magicaltrout> https://jujucharms.com/docs/1.25/config-local
<sam_yan> it is for 12.04LTS,I use 15.10
<magicaltrout> the docs should be the same I believe
<magicaltrout> or same-enough
<sam_yan> ok  thank you
<sam_yan> <magicaltrout>:juju add-unit dcos-agent -n 3  it says "ERROR service "dcos-agent" not found"
<magicaltrout> sam_yan: dcos hasn't been deployed to the charm store
<magicaltrout> so it wont deploy
<sam_yan> how can I try?
<magicaltrout> you need to checkout my 3 github repositories and setup your environment to build charms
<magicaltrout> export JUJU_REPOSITORY=$HOME/charms
<magicaltrout> export LAYER_PATH=$JUJU_REPOSITORY/layers
<magicaltrout> export INTERFACE_PATH=$JUJU_REPOSITORY/interfaces
<magicaltrout> that should pretty much do you
<magicaltrout> then inside dcos-master and dcos-agent
<magicaltrout> run  charm build --series wily
<magicaltrout> juju deploy --repository=/home/youruser/charms local:wily/dcos-master
<magicaltrout> would then deploy the master for you
<magicaltrout> and
<magicaltrout> juju deploy --repository=/home/youruser/charms local:wily/dcos-agent
<magicaltrout> would deploy the agent
<sam_yan> ok .I think the first thing to do is to be familiar with the juju,and to do as you say. thank you magicaltrout   I will do as you tell me
<magicaltrout> no problem. Its not hard to build, but it helps to have a working environment first ;)
<sam_yan> year
<bbaqar> guys need some help. Lets say the latest availble charm revision is cs:trusty/charm-name-10 .. if i push a revision on top of it .. that revision should be accessible on cs:trusty/charm-name-11
<bbaqar> right?
<bbaqar> not happening for a charm of mine
<magicaltrout> bbaqar: you using the launchpad ingestion stuff?
<magicaltrout> ie: commit to LP, wait an hour, see if its updated?
<bbaqar> magicaltrout: that is exacly what i did .. but its been two days now ..
<magicaltrout> yeah its broken, and it looks pretty terminal
<magicaltrout> (speaking from a non canonical emplyee pov :) )
<magicaltrout> there were a couple of posts to the mailing list
<magicaltrout> its recommended you use the new charm publish stuff to get charms into the charm store
<magicaltrout> also its instant, you don't have to wait
<magicaltrout> https://insights.ubuntu.com/2016/04/16/charm-charm-tools-2-0/
<bbaqar> magicaltrout: okay i ll try that out .. but can i push to any space? like lp:~<team name>/charms/trusty/<charm-name>/trunk
<magicaltrout> it will login to the charmstore using your LP creds
<magicaltrout> so I think you end up doing the same thing
<magicaltrout> i'm not sure though, if you swing back in an hour or 3 marcoceppi will be able to offer much greater insight than me
<bbaqar> magicaltrout :thanks alot
<magicaltrout> no probs
<tvansteenburgh> can anyone tell me how to get a username/password from the rabbitmq-server charm so i can connect with an amqp:// url?
<sam_yan> I  use  "juju help local-provider       use on this computer"   and  get "public-address: 10.0.3.205".   But in firfox,it tells "The proxy server is refusing connections"      Why?
<ReSam> my percona-cluster on xenial fails at creating new databases: INFO shared-db-relation-changed _mysql_exceptions.OperationalError: (1045, "Access denied for user 'root'@'localhost' (using password: YES)")
<ReSam> any ideas?
<gahan> Hi. I had some issues with date on the server, time went forward, and since then I have logs of errors from 2032 saying "watcher has been stopped". I'm using OpenStack Autopilot and wondered about restarting watcher?
<gahan> I'm not getting any logs at the moment
<gahan> tail -f /var/log/juju/*.log feeds nothing back, used to be quite crazy
<beisner> bdx, howdy.  jewel 10.2 release dates and xenial release dates were out of alignment, but 10.2 is on its way to Yakkety, then Xenial as part of the FFe/SRU @ bug 1563714
<mup> Bug #1563714: [FFe][SRU] Ceph Jewel stable release <ceph (Ubuntu):In Progress by james-page> <https://launchpad.net/bugs/1563714>
<gahan> bootstrapped juju environment stopped responding, juju debug-log hangs
<Sharan> hi, i was trying to install juju2.0 , if i do "juju status" it is getting hung
<beisner> hi tvansteenburgh - aiui, rmq creates users @ amqp-relation-changed --> configure_amqp() --> create_user()  ie. https://github.com/openstack/charm-rabbitmq-server/blob/master/hooks/rabbitmq_server_relations.py#L152
<tvansteenburgh> beisner: thanks. it turns out the guest/guest user worked, i was just trying to connect to a vhost that didn't exist :/
<beisner> tvansteenburgh, yah but that won't work forever, as it's an undesirable security gap, locking down when this gets resurrected:  https://code.launchpad.net/~pjdc/charms/trusty/rabbitmq-server/no-more-guest-user/+merge/276831
<beisner> depending on the rmq version, the guest user either is or is not accessible from remote hosts, so it's kind of bad vs. bad
<tvansteenburgh> beisner: yah. for my use case right now it's ok
<beisner> tvansteenburgh, woot.  just wanted to make sure you didn't get used to that unintended feature
<axisys> so I end up installting juju-2.0 and now I have juju
<axisys> lazyPower: ^
<axisys> does it work with vmware vcenter or vmware vsphere?
<axisys> I like to test install a hadoop cluster and we have over 20 sites I can access through vcenter.. so testing with vagrant and it works .. wanted to test with juju
<jcastro> https://jujucharms.com/docs/devel/config-vmware
<jcastro> however that is for juju-1
<jcastro> hmmm, shouldn't vmware be there if I `juju update-clouds` and then `juju list-clouds`?
<lazyPower> mbruzek https://github.com/juju-solutions/layer-tls/pull/26
<axisys> jcastro: ah ok.. I see it now
<axisys> jcastro: ~$ juju-1 generate-config --show | grep -A1 vmware
<axisys>     vmware:
<axisys>       type: vsphere
<jcastro> yeah it's just in 2.0 it should set that up automatically, you shouldn't be mangling the config file by hand
<jcastro> I know it works in juju-1
<lazyPower> jcastro - i dont see vmware mentioned in the release notes for beta-5
<jcastro> nor me
<axisys> picky me.. would be nice if there were a bash completion of the juju arguments .. like git has
<jcastro> it does have that normally
<marcoceppi> axisys: there will be, for juju 2.0, when it's released iirc
<jcastro> I don't know why it's currently broken, I just noticed that today
<marcoceppi> bcsaller cory_fu I want to use a custom tactic in my layer. how can I?
<nottrobin> why would this charm https://jujucharms.com/u/charmers/block-storage-broker/trusty/2 be at lp:~charmers/trusty/block-storage-broker/trunk but not at lp:charms/trusty/block-storage-broker ?
<marcoceppi> nottrobin: because it's not promulgated
<axisys> hmm.. juju quickstart fails,  what am I doing wrong? http://dpaste.com/20N9MQN
<cory_fu> Ostensibly, you put the tactic in your layer, and add it to the "tactics" key in layer.yaml.  However, lazyPower ran into an issue with how `charm build` loads the tactics: https://github.com/juju/charm-tools/pull/191
<cory_fu> marcoceppi: ^
<marcoceppi> axisys: what does `juju version` say?
<axisys> I picked automatically create and bootstrap a local enviroment
<axisys> 2.0-beta4-xenial-amd64
<axisys> marcoceppi: ^
<marcoceppi> axisys: you don' tneed quickstart for 2.0
<magicaltrout> what in gods name is a tactic?!
 * magicaltrout cracks out the juju dictionary
<cory_fu> marcoceppi: Here's the example using the tactic in a layer: https://github.com/juju-solutions/layer-docker/pull/43/files  Note the docstring
<marcoceppi> axisys: just bootstrap an enivronment, then juju deploy mediawiki-single
<axisys> marcoceppi: I need a get started for 2.0 :-)
<axisys> marcoceppi: ok
<jcastro> axw: looks like you touched the vmware provider last in march, do you know why it wouldn't be showing as an option in add-clouds or list-clouds?
<marcoceppi> axisys: yes https://jujucharms.com/docs/devel/getting-started
<marcoceppi> axisys: 2.0 is still technically in development
<marcoceppi> magicaltrout: tactics are used in charm build to determine how to handle files/merging
<axisys> jcastro: I decided to come back.. dont have same environmen anymore..
 * jcastro nods
<marcoceppi> cory_fu: my django layer had a django.yaml, which I'm converting to layer.yaml, so I'd like to basically have a tactic that, if django.yaml is found it just yells at the user to migrate
<cory_fu> marcoceppi: Testing that PR on charm-tools would be much appreciated.  But the main thing you need to worry about without it is that your imports at the top of the file containing the tactic likely won't be visible when your tactic is actually invoked.  lazyPower could tell you if there are other issues, and I know he ended up removing the custom tactic in the end, so there might be
<lazyPower> cory_fu - only until it gets merged into charm-tools
<cory_fu> Hrm
<lazyPower> cory_fu - that patch that you linked worked. and i commented on teh commit itself as thats what i had to go on
 * lazyPower will comment on the bug
<marcoceppi> lazyPower cory_fu thanks for the feedback, I left the merge because I didn't see much feedback/way to test
<marcoceppi> also, no one checked of the checklist
<lazyPower> sorry
<lazyPower> preoccupied with a mountain of things to try to land by EOW
<marcoceppi> lazyPower: no worrie
<cory_fu> marcoceppi: Did you set that checklist up as a template for PRs or something?
<marcoceppi> cory_fu: yes
<cory_fu> Where do you set that up?  That's pretty awesome
<marcoceppi> https://github.com/juju/charm-tools/tree/master/.github
<cory_fu> Oh, nice
<marcoceppi> cory_fu: I wanted to experiment with the charm-tools repo before pushing it out elsewhere
<marcoceppi> esp since both charmstore-client and charm-tools are confusing
<LiftedKilt> is baking the gui into the bootstrap node still planned?
<LiftedKilt> or did that get abandoned
<ReSam> LiftedKilt: already done I guess.
<ReSam> "juju gui" works out-of-the-box with 2.0beta-something
<LiftedKilt> ReSam: oh snap cool
<LiftedKilt> I must have missed that
<LiftedKilt> creating models is still broken from the gui though haha
<marcoceppi> LiftedKilt: what version of juju?
<marcoceppi> LiftedKilt: are you using the baked in gui - because that totaly works
<LiftedKilt> beta6
<LiftedKilt> using baked in gui
<LiftedKilt> open drop down, type in name of model, click new -> it just closes the drop down but doesn't create anything. It has never worked for me though
<LiftedKilt> in firefox or chrome
<cmars> any of y'all written a charm with resources yet?
<cmars> looking for an example to learn from
<lazyPower> cmars - its not complete, but i've been looking at adding it to layer-tls so easyrsa is not beign pulled in via git
<cmars> lazyPower, what's a good way to locate the resource file after resource-get from within the charm?
<lazyPower> that i dont know :) i haven't gotten further than declaring it exists
<cmars> lazyPower, maybe os.path.join(hookenv.charm_dir(), '..', 'resources', resource-name) ?
<cmars> ok, i'll play with it
<lazyPower> that sounds like a charm-helper waiting to be written
<cmars> and share if i get it working
<cmars> yeah
<lazyPower> or a charms.module
<lazyPower> cmars - much <3 if you do. I'm eager to see how you solve it
<LiftedKilt> is there a way to just watch the output of [Units] from juju status?
<LiftedKilt> i've been doing:
<LiftedKilt> watch "juju status | sed -n '/\[Units\]/,/\[Machines\]/ p' | head -n -2"
<LiftedKilt> but wondering if there's a more elegant way
<suchvenu> Hi
<suchvenu> I am facing some issue while running amulet test, Can anyone please help me!
<suchvenu> 2016-04-27 17:59:45 DEBUG juju.worker.logger logger.go:45 reconfiguring logging from "<root>=DEBUG" to "<root>=WARNING;unit=DEBUG" 2016-04-27 17:59:46 INFO install /usr/bin/env: python3: No such file or directory 2016-04-27 17:59:46 ERROR juju.worker.uniter.operation runhook.go:107 hook "install" failed: exit status 127
<LiftedKilt> exit
<mgz> LiftedKilt: not as such, but I wonder what `juju status "*/*"` displays
<LiftedKilt> mgz: [Services]: command not found
<mgz> suchvenu: you don't have python3 installed but your install script uses it
<suchvenu> yes i have it
<SaltySolomon> Hi, quick question, how to debug juju charms?
<mgz> suchvenu: locally, but not on the machine that's being run? ssh in and poke around
<suchvenu> i have written in my 00-setup file
<suchvenu>  cat << EOF > local.yaml ibm-repo:     db2_curl_url: "$DB2_CURL_URL"     db2_curl_opts: "$DB2_CURL_OPTS"     db2_licese_accepted: "$DB2_LICENSE"     #db2_package_name: "$PACKAGE_NAME" EOF  #is sudo required here ? sudo add-apt-repository ppa:juju/stable -y sudo apt-get update sudo apt-get install amulet python3 -y
<mgz> SaltySolomon: https://jujucharms.com/docs/stable/authors-intro and so on
<mgz> suchvenu: I don't see how that helps
<SaltySolomon> mgz: I got one of the default packages from the charms store and keystone is not working
<mgz> SaltySolomon: you can pastebin the yaml status, and the unit log from keystone (get with juju ssh keystone/0) into a mailinglist post or bug on launchpad
<mgz> suchvenu: for your install hook to work, you need use a scripting language that's pre-installed on the default image
<mgz> suchvenu: old ubuntu series didn't have python3 by default
<mgz> suchvenu: so either your charm needs to say it's xenial only, or you need to make the install script bash that installs python 3 then invokes from there
<suchvenu> sorry was away
<suchvenu> ok... I see
<suchvenu> let me check
<suchvenu> mgz : So i need to specifically install python3 in my install hook, right ?
<mgz> suchvenu: depending on the series of you charm, yes. and obviously using any kind of python to do that install hook is therefore a problem (for multi-series charms)
<suchvenu> i am using trusty
<suchvenu> and i am writing as a layered charm
<mgz> then just change "#!/usr/bin/env python3" to "#!/usr/bin/env python" and be done
<mgz> or... whatever with layered charms, bug one of the maintainers
<suchvenu> Its getting deployed manually, some env issue with amulet
<suchvenu> i am trying to change python3 to python as you said
<mgz> might be something we need marcoceppi for then
<suchvenu> no, it didn;t help with that
<mgz> suchvenu: send a mail to the juju list, I think everyone's at ODS this week
<suchvenu> ok
<suchvenu> will do
<marcoceppi> mgz: what's up?
<mgz> marcoceppi: suchvenu was having issues writing amulet tests that looked like something was assuming python3 is installed on trusty
<tinwood> cory_fu, do you have time for a quick question?  It's about ignoring files in interfaces when they get copied as part of reactive charms.
<cory_fu> Sure
<tinwood> So, 'we' (as in OpenStack charmers) are trying to add tests to interfaces, but they get copied into the final charm and then blow up on install (due to missing python modules). ...
<tinwood> cory_fu, so I looked at the code and found an 'ignore' key, but it only seems to work for layers (or just the top level charm).
<tinwood> cory_fu, I stared at the code and saw that during the interface copy it uses the target_config of the layer that brings in the interface, but doesn't use any config from the interface.
<cory_fu> tinwood: Did you try adding the "ignore" key to interface.yaml?
<tinwood> cory_fu, so I was wondering how hard it would be to change it so that we could ignore files from the interface during the copy?
<tinwood> cory_fu, yep, it's ignored.  They only seem to work in layers.
<cory_fu> Hrm
<tinwood> It's due to the target_config in plan_interfaces() using the layer rather than the interfaces' yaml.  (I think).
<tinwood> cory_fu, (which is probably for a very good reason!) :)
<cory_fu> tinwood: I don't know.  It seems like it should honor ignores in the interface.yaml as well.  InterfaceCopy should still have access to those ignores, via self.interface.config.ignores, so I think we might just need to add that list to the target config's list at https://github.com/juju/charm-tools/blob/master/charmtools/build/tactics.py#L159
<cory_fu> bcsaller: Can you chime in whether there's a reason that only the charm layer's ignores are honored?
<cory_fu> Or if it's just an oversight
<tinwood> cory_fu, yes, I wasn't sure where the best place was to add it, nor whether there was an important reason to not do it; it seemed that the framework was there to make it work.
<cory_fu> tinwood: I think we should also have an additional set of default ignores for interface layers.  E.g., I don't think every interface layer should have to explicitly exclude tests
<tinwood> cory_fu, right. Yes, that makes sense.
<lazyPower> mbruzek if you have a sec, i could use eyes on this one - https://github.com/juju-solutions/charms.docker/pull/18/files
<bcsaller> cory_fu: most likely an oversight, I can't recall an intent
<tinwood> cory_fu, it would be great if 'tests' was added to DEFAULT_IGNORE list as that could create a template for how to add unit tests to an interface or layer.
<cory_fu> We don't always want to exclude tests from every layer, though, do we?
<tinwood> cory_fu, however, that might be going to far!
<cory_fu> Seems like it would make sense for interface layers, as they won't get picked up anyway.  But base layers could potentially add amulet tests to the final charm, or something
<tinwood> cory_fu, no you're probably right.  I can see the source charm for the build bundling tests for the final built version that can be exercised by the CI as a gate.  So yes, it would be foolish to ignore them by default.
<tinwood> cory_fu, bcsaller, how would you like to proceed?  Shall I raise a bug?  I can also (try to) to do a pull request if that helps?
<cory_fu> tinwood: Yeah, that would be good.  I'm optitmistic that it'll be a simple change at the line I linked above
<magicaltrout> thats what they all say....
<magicaltrout> ..... 6 days of hacking later
<tinwood> cory_fu, okay, I'll try it and let you know. :)
<cory_fu> lol, too true, magicaltrout
<tinwood> magicaltrout, indeed.  Down the rabbit hole one proceeds ...
<natefinch> marcoceppi: juju.failâs server DNS address could not be found.  :(
<marcoceppi> natefinch: oops, that'll be addressed in a hot min
<natefinch> marcoceppi: forget to pay your registrar again? ;)
<marcoceppi> natefinch: honestly, so many domains across so many registrars, a few have old credit cards
<natefinch> marcoceppi: I hear ya
<magicaltrout> its like a startup all over again!
<natefinch> marcoceppi: I'm lucky I only have domains on two registrars... I'd love to migrate off godaddy, but it's such a hassle.  That's how they get you, I guess.
<marcoceppi> natefinch: melbourne it, tucows, godaddy, google domains, iwantmyname, ghandi
<marcoceppi> natefinch: those are the ones I remember
<natefinch> marcoceppi: ouch
<natefinch> marcoceppi: million dollar idea - service that migrates your domains for you.  Actually... I'm surprised the bigger registrars don't code something up to make it easier.
<marcoceppi> natefinch: it's pretty straight forward, but it still requires human intervention
<marcoceppi> natefinch: and yo0u have th pay for another year on xfer
<marcoceppi> that'd be like me dolling out a few grand to consolidate
<magicaltrout> a few grand to consolidate sounds like a bargain
 * magicaltrout goes to setup such a service
<natefinch> if letsencrypt can figure out a way to make getting a friggin' cert automatic,  we should be able to figure out how to transfer a stupid domain
<marcoceppi> natefinch: juju.fail should be back unless you've got dns cache
<natefinch> marcoceppi: it seems I do
<marcoceppi> natefinch: if it's still not owrking, try a different browser
<magicaltrout> or reset your router :)
<tinwood> cory_fu, bcsaller: the good news is that your suggested change of 'self.config.ignores' -> 'self.interface.config.ignores' works to pick up the ignore config option in interfaces.yaml. I'll do a PR.
<cory_fu> tinwood: Make sure you also include the existing ignores.  It should be `self.config.ignores + self.interface.config.ignores`
<magicaltrout> woooo \o/
<cory_fu> Glad to hear it was easy, tho
<tinwood> cory_fu, they'll be dups then as both lists contain the defaults (I'm guessing).  Shall I list(set()) them to get a unique list?
<cory_fu> tinwood: self.config.ignores would contain the "ignores" key from the top (charm) layer's layer.yaml, while self.interfaces.config would contain the "ignores" key from interface.yaml
<tinwood> cory_fu, I printed them both and they both contain the DEFAULT_LIST: ...
<tinwood> The ignore list is: ['.bzr/', '.git/', '**/.ropeproject/', '*.pyc', '*~', '.tox/', 'build/']
<tinwood> The self ignores list is: ['.bzr/', '.git/', '**/.ropeproject/', '*.pyc', '*~', '.tox/', 'build/']
 * tinwood duh, wrong one:
<tinwood> charmtools.build.tactics: Copying Interface keystone: /home/ubuntu/charms/trusty/designate/build/builds/designate/hooks/relations/keystone
<tinwood> The ignore list is: ['.bzr/', '.git/', '**/.ropeproject/', '*.pyc', '*~', '.tox/', 'build/']
<tinwood> The self ignores list is: ['tests', '.bzr/', '.git/', '**/.ropeproject/', '*.pyc', '*~', '.tox/', 'build/']
<cory_fu> tinwood: It shouldn't matter if it has dupes
<tinwood> cory_fu, okay, I'll concat the two vars.  Thanks very much for your help!  Typically, how long will this take to land (assuming it's accepted)?
<cory_fu> marcoceppi: ^
<marcoceppi> cory_fu: IM CONFUSED
<marcoceppi> im also caps locked
<cmars> is there a way to skip installing g++ in the basic layer? a configuration option, perhaps?
<cory_fu> marcoceppi: If a PR is accepted on charm-tools, how long until it will be available (somehow, e.g., ppa)?  Or are we still too new to the release process?
<cmars> most of my charms don't need it and some ops folks are hesitant to deploy compilers into a production env
<marcoceppi> cory_fu: I'm working on getting an MRE, which means we can turn around a micro release (patch) in a copule of days
<cmars> as for me, i think it just slows down the install hook
<marcoceppi> cmars: it's typically installed for python-dev
<cmars> marcoceppi, can i not install python-dev?
<marcoceppi> cmars: maybe? but not atm
<cmars> ok
<marcoceppi> cory_fu: ^?
<tinwood> cory_fu, marcoceppi thanks for the info.  we'll work around the problem with a post build script until the patch (I've not yet submitted!) lands.
<tinwood> gnuoy, ^^^ - found issue, have solution,  but need to keep the delete workaround until it lands (... this is for tests appearing in the built charm).
<cory_fu> aisrael: I'm seeing some strange behavior when trying to use the watch-files options of rsyslog-forwarder-ha in a bundle.  If I don't tag the revision explicitly, I get an error saying the option is invalid, but if I explicitly give it -8, it works.  Any idea why?
<cory_fu> aisrael: Did you by chance use `charm publish` for rev 8?
<axw> jcastro: IIRC you have to set a feature flag for vsphere to show up
<jcastro> axw: yeah alexis had me file a bug on that, thanks
<axw> np
<aisrael> cory_fu: I don't think that's one I used charm publish for. The first one I used that on was auditd
<cory_fu> Very strange
#juju 2016-04-28
<stub> cory_fu: Are you working on actions for reactive? I'm going to want them sooner rather than later and might give it a go.
<Prabakaran> I am not able to install charm tools on Linux c277-pkvm-vm54 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:42:36 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux architechture. Could someone please advise me on this?
<Prabakaran> I am gettting this issue http://pastebin.ubuntu.com/16093003/
<Prabakaran> while installing charm tools
<nottrobin> Is the new resource stuff introduced here https://insights.ubuntu.com/2016/02/15/introducing-juju-resources/ documented more completely anywhere?
<marcoceppi> Prabakaran: it's a known issue
<marcoceppi> nottrobin: not at the moment, any questions?
<cory_fu> stub: I am not, but also want them so if you have the time to work on them, please do
<nottrobin> marcoceppi: am I correct in thinking I could use resource-set on the host and resource-get in the charm hook to pass, say, a URL of where to download code from?
<nottrobin> marcoceppi: to basically replace the functionality provide by content-fetcher: https://jujucharms.com/u/gnuoy/content-fetcher/precise/11#charm-config-archive_location
<marcoceppi> nottrobin: not quite, think of it more like. the charm describes a set of resources it needs. Then, when deployed from the charm store, where the charm would have been uploaded with a binary copy of some or all of the resources it's described, it'd be delivered to disk, by juju, those resources. Then, you - an operator - could push new versions of one or more of the resources to the deployed charm. It's not a content fetcher more so a content
<marcoceppi> delivery mechanism. `wget https://payload.tld/thing.tar.gz; juju attach app payload-thing=./thing.tar.gz`
<magicaltrout> see marcoceppi it needs more functionality! :P
<marcoceppi> nottrobin: an example of this is the charm-svg charm, which provides https://svg.juju.solutions - it needs two resources, the golang binary for converting a bundle to an svg and the bottle.py web app. So instead of having the charm just wildly grab these from the internet where you have problems like version drift between units, unreliable services, I just deploy the charm with the resources from my machine (or the charm store) after I've gotten/
<marcoceppi> verified them
<marcoceppi> magicaltrout: yes, it could be expanded a bit, where the charm could say "here's where you get it" but you still have problems with that model
<marcoceppi> magicaltrout: this just makes it a really straight forward tuple of charm-version and resourceN-version, it's locked, tested working together, always good set with a mechanism for you to update
<magicaltrout> this is true. You could have a mandatory checksum or something to go with it?
<nottrobin> marcoceppi: could you dump a few commands for how you'd then deploy the charm-svg charm with its resource into a pastebin?
<marcoceppi> magicaltrout: we're not out to solve every problem, just solve MVP and iterate on feedback ;) we'll never get everything everyone wants on the first stab
<nottrobin> marcoceppi: I'm trying to understand how we could use this
<marcoceppi> nottrobin: absolutely, since I have to redeploy in like 20 mins
 * marcoceppi grumbles about betas in production
<nottrobin> marcoceppi: at present, we have 2 charms we use, wsgi-app and content-fetcher, which have a setting to allow us to tell it where to get the code, from the internet
<magicaltrout> indeed, I'm just ribbing you. But it would be cool to be able to ship a charm and have the server grab the resrouces so it can deploy locally, with manual intervention
<nottrobin> marcoceppi: we put the code in a tarball which we upload to swift with a unique ID
<nottrobin> marcoceppi: then we do a "juju set archive_location={new_url}"
<nottrobin> marcoceppi: so I'd like to understand how that process could be replaced by resources
<marcoceppi> nottrobin: oh, absolutely
<tvansteenburgh> anyone have an example of a charm that works with upstart or systemd, depending on the os release it's deployed on?
<jcastro> postgres would be my first guess
<marcoceppi> tvansteenburgh: why not just install upstart and use upstart on all machines?
<marcoceppi> tvansteenburgh: systemd will wrap it, so it really doesn't matter
<marcoceppi> tvansteenburgh: just make sure you apt intsall upstart
<tvansteenburgh> marcoceppi: cool, didn't know it was that easy, will do, thanks
<mattyw> evilnick, ping?
<evilnick> mattyw pong
<mattyw> evilnick, hey there, I know your busy, but quick question: The docs at https://jujucharms.com/docs only list 1.25. Anyone that gets there from xenial is going to be quite confused, is there a plan to add a 2.0 tab?
<evilnick> matty, the 2.0 docs will go live, probably at some point before the 2.0 release
<evilnick> as there are still command changes etc going on, it would possibly be more confusing to have broken docs...
<evilnick> mattyw^
<mattyw> evilnick, ok ack
<mattyw> cherylj, ping?
<tvansteenburgh> stub: in the apt layer, is there a state that gets set when everything in `extra_packages` has been installed?
<cherylj> hey mattyw, what's up?
<mattyw> cherylj, hey hey, sent you an email :)
<stub> tvansteenburgh: @when_not('apt.queued_installs') is the best you can do at the moment
<tvansteenburgh> stub: ok thanks
<stub> (which is true when everything queued has been installed, not just extra_packages
<tvansteenburgh> stub: but could it also be true before anything is queued
<tvansteenburgh> stub: i guess the `hookenv.atstart(configure_sources)` means the apt stuff will always run *before* my charm code
<tvansteenburgh> stub: so, if not('apt.queued_installs'), i can assume everything has been installed, not that nothing has been queued yet
<stub> tvansteenburgh: Yes. Which can be annoying, as if you have handlers adding apt sources they will likely get invoked after an attempt is made to install packages declared in extra_packages, which is not ideal.
<tvansteenburgh> stub: ack, thanks for clarifying
<ReSam> I'm having problems deploying xenial/keystone-0 on juju2-beta5: "Ports which should be open, but are not: 5000, 35357"
<jamespage> marcoceppi, urulama: hey - does the juju gui install automatically on a controller node for 2.0 yet?
<urulama> jamespage: yes it does
<jamespage> urulama, hmm - an special port I have to use?
<jamespage> any rather?
<urulama> jamespage: https://blog.jujugui.org/2016/04/15/juju-2-0-beta-4-now-with-embedded-gui/
<urulama> jamespage: no, just type juju gui --show-credentials
<urulama> it'll connect to a model you're in atm
<jamespage> urulama, awesoe thankyou!
<tvansteenburgh> cory_fu: in light of the current behavior of config.changed.* states, do you have a suggestion for a way to work around the problem you illustrated here https://github.com/juju-solutions/layer-basic/pull/61
<tvansteenburgh> cory_fu: b/c that's pretty much how i want to organize my code, but i don't want install() called twice, obviously
<cory_fu> tvansteenburgh: You can see the approach I used in https://code.launchpad.net/~johnsca/layer-ibm-base/fix-multi-call/+merge/292845
<cory_fu> That should be future-proof if that PR gets accepted
<tvansteenburgh> cory_fu: cool, thanks!
<cory_fu> But with the current behavior, you could actually leave out the .new. state.  The extra state makes it more wordy, but at the same time, I think it makes it a bit more clear.  *shrug*
<tvansteenburgh> cory_fu: so it's the config.set. that's fixing the problem, right?
<cory_fu> No, that's replacing the "if" inside the handler.  It's the @when('config.changed.curl_url') and the removal of the "only do this once" state (ibm-base.curl.resource.fetched)
<tvansteenburgh> cory_fu: oic
<cory_fu> Basically, when the config changes (from being nothing, or to a new value), do the install
<tvansteenburgh> yeah, ok, i get it now
<cory_fu> It will do it at least once (because the config is new, or "changed" from "non-existant") and then won't do it again unless the config value changes
<tvansteenburgh> check for config.changed instead of maintaining your own "installed" state, in my case
<cory_fu> Yep
<tvansteenburgh> cool, thanks
<cory_fu> np
<jcastro> lazyPower: http://pastebin.ubuntu.com/16095681/
<jcastro> in the swarm charm it fails to install docker-engine
<lazyPower> swap to xenial?
<jcastro> oh, I would have thought the charm would have declared the series no?
<lazyPower> it does, it says its trusty compat
<lazyPower> oh i'm full of lies :)
<jcastro> it's their package, investigating
<jcastro> lazyPower: ok so do you want me to use xenial with this or do you plan on supporting trusty?
<lazyPower> Trusty was target for the spec. I can land xenial support in a couple days using our docker.io package vs upstreams
<lazyPower> the only reason docker-engine is being used in trusty is because docker 1.6 is quite old, has CVE's, and should go sit in the corner.
<jcastro> lazyPower: hey is it possible to use the apt layer to install docker? install_docker.sh is ;_;
<lazyPower> jcastro - file a bug
<jcastro> on the charm?
<jcastro> yeah so it looks like it's a circular thing, the service won't start because dpkg is unconfigured, and dpkg won't complete because the service won't start
<lazyPower> if you deployed on xenial, i'm not surprised :)
<jcastro> it's on trusty
<lazyPower> thats completely new
<lazyPower> what substrate?
<jcastro> lxd
<lazyPower> jorge
<lazyPower> unless you apply teh docker profile, use the docker.io package, and a few other small tweaks - docker/swarm will not run in lxd as it stands today (by default)
<jcastro> ah!
<jcastro> I ran right into bruzerville and didn't even notice!
<lazyPower> jcastro well - its like this. when KVM was removed as a provider you have 2 choices
<lazyPower> setup maas, or go to the cloud :)
<lazyPower> i defer to you, to pick your poison
<jcastro> sure, are you testing on aws or gcloud?
<jcastro> I'll use the one you're not using
<lazyPower> i've done my primary testing on aws, gcloud would be some welcome re-check of results
<jcastro> ack
<marcoceppi> jcastro: I am so close to autopkgtest for charm and charm-tools
<jcastro> \o/
<marcoceppi> jcastro: eco-wx?
<jcastro> omw
<marcoceppi> lazyPower cory_fu https://github.com/juju-solutions/layer-basic/pull/63
<cory_fu> marcoceppi: What is the reason for that?
<lazyPower> cory_fu - i found a pattern that causes it to choke
<lazyPower> i'm implicity caching a value in config()
<cory_fu> Example?
<lazyPower> cory_fu https://github.com/juju-solutions/layer-beats-base/blob/master/lib/elasticbeats.py#L17
<lazyPower> thing is, i had no idea i could cache in config
<cory_fu> Oh yeah, that was a feature tvansteenburgh added before we had unitdata.  I'd prefer you use unitdata, but I guess the whitelist is reasonable anyway
<lazyPower> cory_fu - i was improperly thinking config just returned a dict
<lazyPower> its a class, and has its own behaviors. so i kind of stumbled into this by being forceful with stuffing things in config to render a template :P
<cory_fu> lazyPower: Yeah, it's mostly a dict, but it does let you change the values, but I'm not sure that's a good pattern to encourage.  I'd prefer it to be immutable
<cory_fu> Otherwise, you'll see things coming out of hookenv.config() that don't match what you see from `juju get`
<lazyPower> cory_fu - yeah its not too ugly to make a separate context object and clone in the stuff you care about
<lazyPower> which i think i'll do
<cory_fu> Yeah
<cory_fu> But anyway, the PR has been merged
<marcoceppi> cory_fu: thanks
<marcoceppi> cory_fu: I'm going to align the deps with what's in xenial, because we can just backport xenial packages to trusty ppa
<cory_fu> +1
<marcoceppi> cory_fu: so a few things got bumped, will be in my test suite fixes
<marcoceppi> cory_fu: could I get a review of this but hold off on merge? https://github.com/juju/charm-tools/pull/195
<cory_fu> marcoceppi: Looks reasonable to me.
<marcoceppi> cory_fu: cool, I wasn't 100% sure tbh
<marcoceppi> waiting for autopkgtests to finish, but hopefully this address that import issue
<nottrobin> marcoceppi: did you get a chance to create that pastebin to illustrate resources?
<marcoceppi> nottrobin: sorry, not yet. fighting meetings most of my day so far
<nottrobin> marcoceppi: no rush. just ping me when/if you do get around to it
<Prabakaran> Hello Team, When ever i do juju add-machine command in juju framework .. it is creating xenial series machine instead of trusty series container...see the output of juju status http://pastebin.ubuntu.com/16108619/ which has trusty series for machine 0 and xenial series for machine 1.. please advise me to resolved this issue?
<Prabakaran> uname -a is Linux c277-pkvm-vm54 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:42:36 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux
<lazyPower> Prabakaran - if you're on juju 2.0 you can add a machine with --series=trusty
<lazyPower> otherwise i believe it constraints="series=trusty"
<Prabakaran> i am using 1.25.5-trusty-ppc64el
<LiftedKilt> deploying the openstack-lxd bundle, I get errors in my ceph cluster about too many PGs per OSD is there a way to tune that?
<lazyPower> cory_fu https://github.com/juju-solutions/layer-beats-base/pull/2
<cory_fu> lazyPower: Whoa.  Why are you doing manual hooks?
<lazyPower> i need that value set, and it was quicker to drop that as the hook file in bash?
 * cory_fu scowls at lazyPower.
<lazyPower> its been like that since i wrote it :P  guess it only sneaks past if its not in a MP?
<cory_fu> I never reviewed that layer
<cory_fu> We're supposed to have a fancy new RQ that lets us review layers.
 * cory_fu glances at tvansteenburgh.
<tvansteenburgh> cory_fu: i'm making the charm as we speak
<cory_fu> Yay!
<tvansteenburgh> cory_fu: although the first rev is just for charms
<cory_fu> lazyPower: There is a juju-info layer, but it needs  minor modification for your use-case: https://github.com/juju-solutions/interface-juju-info
<lazyPower> i...i made that interface...
<lazyPower> wait, so i can add behavior to that?
 * lazyPower sighs
<lazyPower> okay give me 30 minutes to unwind this and update the interface + beats-base + filebeat and re-run the tests
<cory_fu> lazyPower: It's not the end of the world if you want to punt on that to get it ready.  That hook is pretty trivial
<lazyPower> ok
<lazyPower> thats my preferred solution at this juncture
<lazyPower> if you bug it though, i swear i'll circle back and get it fixed
<cory_fu> But I'm going to open an issue to fix it later
<lazyPower> !
<lazyPower> perfect
<lazyPower> cory_fu https://github.com/juju-solutions/layer-filebeat/pull/4
<lazyPower> cory_fu - and if thats g2g https://bugs.launchpad.net/charms/+bug/1560166
<mup> Bug #1560166: New charm proposal: Filebeat <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1560166>
<cory_fu> lazyPower: I'm going to be a few minutes on those.  Getting pulled in a bunch of directions
<lazyPower> no rush. just getting the roadmap layed out so its easy to follow :)
<cory_fu> lazyPower: One comment on https://github.com/juju-solutions/layer-filebeat/pull/4
<lazyPower> cory_fu - awesome, almost ready to hand off topbeat and circle back to that rev comment
<lazyPower> cory_fu - replied on the comment
<lazyPower> but thats in teh wrong spot, gah
<lazyPower> fixed and re-pushed
<kwmonroe> cory_fu: is the reactive .py processed top-down?  i have "@when x; def slow()" followed by "@when y; def fast()".  x and y are totally independent and both set. if i move "@when y" before my "@when x", will it execute first?
<cory_fu> kwmonroe: There are no guarantees about what order handlers are executed in
<kwmonroe> cory_fu: is that because there is not guarnatee about the order hooks are fired?  if so, what if for a given hook both slow() and fast() should be executed.  is there nothing i can do to make fast() go first?
<magicaltrout> ask it nicely?
<cory_fu> lazyPower: You could use @when_any for "or"
<lazyPower> oh thats a good point
<kwmonroe> magicaltrout: i feel like we're going to have a nice time in vancouver.
 * lazyPower updates
<cory_fu> lazyPower: Although, with the issues with @when_file_changed, it's probably better that you're doing it that way
<lazyPower> yeah?
<lazyPower> well, i can leave it as is until when_file_changed gets some love
<cory_fu> lazyPower: Actually, I'd almost recommend not using @when_file_changed at all.  :(
<magicaltrout> looking forward to it kwmonroe :P
<lazyPower> thats a pretty big warning for something we're still shipping
<cory_fu> Using it by itself is probably fine, but it can get tripped up if states are removed
<lazyPower> hmm
<lazyPower> ok yeah its not doing any state modification in that method body
<cory_fu> I know.  I just haven't had time to address the issues with it
<lazyPower> is that teh only side effect it has? or does it get tripped up if another decorated method removes state?
<lazyPower> sorry i wasn't meaning to be critical either...
<cory_fu> lazyPower: No, I mean if any other handlers in the same execution queue remove states, it can cause the @when_file_changed handler to get dropped
<lazyPower> ah ok
<cory_fu> lazyPower: https://github.com/juju-solutions/charms.reactive/issues/44
<cory_fu> kwmonroe: There's no guarantee because all the handlers are put in a pool and pulled out at random when their conditions match.  If you want one handler to go before another, you should chain them together with a state (or have one call the other directly)
<lazyPower> cory_fu - so, full disclosure
<lazyPower> i have the same method(s) in topbeat
<lazyPower> should i refactor these then? if you're not happy with that decorator going in we can change it
<lazyPower> i'd like to know beforei kick off this test and wait through and have to re-test it. it delays ~ 15 minutes per run
<cory_fu> lazyPower: Is there any other handler besides render_filebeat_template that you expect to update that file?
<gnuoy> Is there a way to trigger an update of charm-tools in the ppa? I'm hoping to get my hands on a fix that landed yesterday
<lazyPower> cory_fu - nope. I can just put it in that body and eliminate the event handler
<cory_fu> Yeah, +1.  Inline the restart and avoid when_file_changed
<tvansteenburgh> gnuoy: i believe marcoceppi is the trigger
<cory_fu> You can manually call charms.reactive.helpers.any_file_changed(['file.yaml']) to prevent unnecessary restarts
<gnuoy> tvansteenburgh, ah, ok, thanks.
<cory_fu> lazyPower: ^
<marcoceppi> gnuoy: build from trunk
<marcoceppi> gnuoy: we're in the mist of getting an MRE for charm-tools, but I want to hold off having too much package drift until then
<bsod90> Hi guys! I'm a newbie to juju and I'm seeking for some general advices on how do I debug issues with it. In particular, I'm trying to deploy openstack base bundle on 4 maas machines and I'm stuck in a state like this: http://d.pr/i/142ox where some services came up, but some did not and nothing is happening anymore. What are my next steps to debug this? I looked into "juju status", but it's not very verbose.
<bsod90> What are the common places to start collecting more detailed information on what's going on? Thank you for any help.
<magicaltrout> bsod90: juju debug-log will help you
<marcoceppi> bsod90: can you put the output of juju status into a pastebin? (paste.ubuntu.com for example)
<magicaltrout> nice screenshot
<magicaltrout> looks like a mindmap
<bsod90> magicaltrout: thank you, it looks much more verbose. marcoceppi: one moment
<bsod90> marcoceppi: http://pastebin.com/7B9RMMK7
<lathiat> bsod90: juju status --format=tabular is also slightly easier to look at for a summary (but the same info mostly, more concise)
<marcoceppi> lathiat: that is format tabular
<marcoceppi> bsod90: you've got a few things going on here
<lathiat> oh, hes using juju2 :-)
<lathiat> ++ for the change
<marcoceppi> bsod90: how did you try to deploy openstack?
<bsod90> I can seet that machine 2 is still in "pending" state (whatever that means) and in debug-log I noticed a message saying "etting machine addresses: cannot set machine addresses of machine 2: state changing too quickly;" popping up sometimes. I'm trying to correlate this with potential network issues.
<bsod90> marcoceppi: just found the bundle on jujucharms
<bsod90> I've added it to 'admin' model
<bsod90> and then moved contents of one of 'new' nodes to 0 (to collocate it with juju itself)
<marcoceppi> bsod90: yeah, you need more than 4 machines for that
<bsod90> that's because I have only 4 machines available
<marcoceppi> bsod90: that bundle wants like 8 machines
<marcoceppi> bsod90: have you tried the openstack-installer?
<marcoceppi> bsod90: it's basically juju with smarter placement :)
<bsod90> hmm. in description it says " This bundle is designed to run on bare metal using Juju with MAAS (Metal-as-a-Service); you will need to have setup a MAAS deployment with a minimum of 4 physical servers prior to using this bundle."
<bsod90> but anyways, let me try openstack-installer then
<bsod90> thank you!
<marcoceppi> bsod90: http://www.ubuntu.com/download/cloud/install-openstack-with-autopilot
<bsod90> just to confirm: my end goal is to have nova-compute providing me with lxd containers on top of my physical nodes. With the ability to add/remove nodes in future, of course. Am I approaching it right when trying to setup maas and juju and what else it would need or it's better to setup just needed openstack components manually?
<lathiat> bsod90: maas and juju will do exactly that, you really need 4 actual nodes though .. colocating services on the juju node is not recommended
<lathiat> bsod90: openstack-base will work on 4 nodes + bootstrap server
<bsod90> lathiat: but juju controller node is not going to requrie a lot of resources, right? I can try finding some cheap piece of hardware around and just adding it to my cluster..
<lathiat> bsod90: in your current deployment there was a couple of errors that you would need to review the debug logs to understand what went wrong and try and figure out why.. mainly you had nova-compute/2 and openstack-dashboard/0 fail to install totally and mysql-shard-db relations faile dfor some reason
<lathiat> bsod90: yeah it doens't need a lot.. for testing at home I run this in a VM on some other server (not used for juju) to save a physical node
<lathiat> as well as maas
<lathiat> fine for testing
<marcoceppi> bsod90: you could create a KVM instance for the bootstrap node
<bsod90> hmm. that's feasible, I can easily allocate a VM here. but how do I tell juju to use the VM for controller and maas for the rest?
<marcoceppi> bsod90: we do that a lot when we have limited hardware
<lathiat> bsod90: you can manually enroll it in maas with libvirt driver
<marcoceppi> bsod90: you can actually put 90% of the openstack services in containers, either LXC or KVM
<lathiat> alongside your physical machines
<marcoceppi> bsod90: so use 3 nodes for nova-compute, and ceph, then everything else into containers
<lathiat> bsod90: puting aside the fact this breakage may be related to something like using machine 0.. we can review the debug-log to see what happened for some of these errors.  e.g. juju debug-log --include unit-glance-0 --replay -T
<lathiat> also worth looking at unit-nova-compute-2 and openstack-dashboard-0 as they failed install for some resaon
<bsod90> marcoceppi: I actually have 5 physical nodes. one already occupied by maas. I can manually setup LXD or KVM on it or even manually provision a VM on VMware (completely separate from my setup). I just need to know how can I use that together with maas
<bsod90> lathiat: one sec, let me collect the logs
<marcoceppi> bsod90: create the virtual machines, let me get you a template, then you more or less add them to maas with the libvirt backend
<marcoceppi> bsod90: https://maas.ubuntu.com/docs/nodes.html#virtual-machine-nodes
<bsod90> lathiat: glance: http://paste.ubuntu.com/16119929/ (quite big one) nova: http://paste.ubuntu.com/16119940/
<lathiat> mm so nova-compute is failing on unit-get private-address
<lathiat> mysql seems somehow the grant was not made
<bsod90> marcoceppi: would that require my VMs to be in the same management network (when MAAS is running DHCP) as the other 4 physical nodes?
<lathiat> bsod90: i might suggest prehaps t ogive trusty a try, instead of xenial.. the xenial stuff has just freshly landed in the last few days, which means (a) not so fleshed out yet and (b) i havent yet tried a full xenial deploy to see if I ran into such issues
<marcoceppi> bsod90: yes, but you could bridge into that network
<marcoceppi> bsod90: I'm looking for the script i use for this
<lathiat> marcoceppi: the virtual-maasers one?
<lazyPower> cory_fu another one for ya https://github.com/juju-solutions/layer-topbeat/pull/3
<lazyPower> cory_fu - if you like that approach i'll follow on filebeat with it
<bsod90> lathiat: I see. Yeah, I have already experienced some of the xenial freshness :) I'm a bit concerned about trusty kernel for LXD, whether our stuff will work on it or not. (basically, we need to use cgroups inside the container. I've tested that with LXD & xenial, it works. and I know that simillar thing, but in docker & trusty doesn't work). Anyways, let me probably first somehow provide it with all neede
<bsod90> nodes, so it has fresh 4 physicals just for openstack. Then I'll retry installation and will continue debugging from there.
<bdx> https://insights.ubuntu.com/2015/11/08/deploying-openstack-on-maas-1-9-with-juju/ -> click the "read original article" link at the bottom of the page
<bdx> sketch
<bdx> someone get a handle on ^ fast
<lathiat> bsod90: could be a good idea, actually these issues are quite possibly related.. the mysql grant possibly didn't work right fo rthe same reason that the private-address lookup is failing
<lathiat> im not 100% sure about how private-address is working.. maybe marcoceppi knows
<cory_fu> lazyPower: +1
<lazyPower> incoming Pr for filebeat then - let me rev the store and get you a bundle
<lazyPower> this should round out beats-core
<admcleod1> how do i, with an amulet test, wait for all units of a service to have a specific status message?
<cory_fu> admcleod1: You want https://pythonhosted.org/amulet/amulet.html#amulet.sentry.Talisman.wait_for_messages
<admcleod1> thanks cory_fu !
#juju 2016-04-29
<tvansteenburgh> stub: do you have an example of the config needed to deploy the postgresql charm using 9.4? my latest attempt was this http://paste.ubuntu.com/16121963/
<tvansteenburgh> stub: ala `juju deploy postgresql --config /tmp/pg.yaml`
<tvansteenburgh> stub: i had a typo in that. removed the leading "deb" from the install_sources. problem now is that when apt-get update tries to download the postgres index files, they 404
<tvansteenburgh> stub: not the charm's fault obviously, i'm just not sure how to fix.
<tvansteenburgh> stub: i don't know how apt-get update creates its urls. i gave it "http://apt.postgresql.org/pub/repos/apt/ trusty-pgdg main" and it's trying to fetch "http://apt.postgresql.org/pub/repos/apt/dists/trusty/trusty-pgdg/binary-amd64/Packages" and "http://apt.postgresql.org/pub/repos/apt/dists/trusty/main/binary-amd64/Packages", neither of which exist
<tvansteenburgh> stub: uh, nevermind. i just destroyed the model and redeployed everything and now it's working...
 * tvansteenburgh blinks
<stub> tvansteenburgh: If you use the most recent charm (or review it and stuff it in the charm store) you don't need the updated key, and can just set the pgdg boolean config option.
<stub> tvansteenburgh: launchpad.net/postgresql-charm
<tvansteenburgh> stub: ah, cool, didn't know there was a newer charm
<stub> tvansteenburgh: Yeah, complete rewrite in reactive, lots of bugs fixed.
<stub> tvansteenburgh: Its what we use for production deploys
<tvansteenburgh> sweet
<stub> https://code.launchpad.net/postgresql-charm has the branches - you want 'built'.
<tvansteenburgh> stub: is it in the store under your namespace or something?
<stub> tvansteenburgh: tribaal uploaded a copy to his namespace the other day. I can't log in myself (open bug on charmstore-client)
<tvansteenburgh> stub: ack, i'll take it for a spin
<veebers> Hi all, so trying to install juju from scratch as per https://github.com/juju/juju/blob/master/README.md (i.e. go get -d -v github.com/juju/juju/...) but fails on github.com/Azure/azure-sdk-for-go. A quick look at the build status for that project shows it's been failed for 17 days. Is this a known issue
<stub> Is there a blessed way of knowing what sort of a hook environment is in play? I think JUJU_HOOK_NAME now gets reliably set in hooks, but I'm not sure since what version. I also can't see anyway of determining if I'm running an action or in a juju-run context, apart from sniffing the process command line (which is error prone due to symlinks, but I could cope I think)
<stub> I guess I could rely on action-get to fail hard if I'm not in an action, which will cause log spam but should be reliable.
<admcleod-> id ilke to iterate through each unit in a service, in an amulet test, but not sure what the best way is
<admcleod-> (and action_do(unit))
<veebers> so instructions found here fixed my issue: https://github.com/juju/juju/blob/master/CONTRIBUTING.md#dependency-management (godeps etc.)
<stub> admcleod-: for unit_data in deployment.sentry['servicename']
<stub> unit_names = [i.info['unit_name'] for i in deployment.sentry['myservice']] if you just want the unit names for action_do(unit_name)
<admcleod-> ah ok cool, i was close
<admcleod-> but that saved me a bit of work i think :}
<Mo0O> hello
<Mo0O> do you know if it's possible to use juju to deploy with any given linux distro, like alpine linux for example
<Mo0O> ?
<Mo0O> or we can use it only with ubuntu and centos
<magicaltrout> hey Mo0O, currently I think thats it
<magicaltrout> the tools need to be compatible with the different linux flavours
<magicaltrout> so its not like its impossible it just depends on where the tooling has been developed
<Mo0O> magicaltrout: do you know which part of the source juju source code needs to be modified to support other distro?
<Mo0O> I can contribute
<magicaltrout> i don't but i'm sure marcoceppi can point you in the right direction when he arrives
<magicaltrout> you'll probably have to wait an hour for the east coasters to wake up
<Mo0O> no problem, I'm connected constantly
<Mo0O> ;)
<DavidRama> hello trying to get started with juju ans maas but can't bootstrap my environment here's my configenvironments:
<DavidRama>     # https://juju.ubuntu.com/docs/config-maas.html
<DavidRama>     maas:
<DavidRama>         type: maas
<DavidRama>         maas-server: 'http://172.17.6.253/MAAS/'
<DavidRama>         maas-oauth: 'XMepSnQvpPeNgDFEMH:D22wnKekvCg3mgWpAm:kRctQA9wXSW38VxRw7uqNhkNpsQxYpF8'
<DavidRama>         bootstrap-timeout: 1800
<DavidRama>         authorized-keys-path: /home/rama/.juju/ssh/rama.pub
<DavidRama> bootstraping leads to this
<DavidRama> rama@Maas:~$ juju-1.25 bootstrap
<DavidRama> WARNING ignoring environments.yaml: using bootstrap config in file "/home/rama/.juju/environments/maas.jenv"
<DavidRama> ERROR cannot determine if environment is already bootstrapped.: could not access file 'eec82963-60e7-480e-8ff3-888844ddab96-provider-state': Requested map, got <nil>.
<DavidRama> don't know where to find this provider-state file/erase it
<marcoceppi> DavidRama: delete the .jenv file it references, bootstrap again
<DavidRama> other provider state message:
<DavidRama> Bootstrap failed, destroying environment
<DavidRama> ERROR the environment could not be destroyed: destroying instances: Requested array, got <nil>.
<DavidRama> ERROR cannot determine if environment is already bootstrapped.: could not access file '68370e49-7eaa-4fdb-88b6-924856105d3a-provider-state': Requested map, got <nil>.
<shruthima> Hi kwmonroe, I have pushed the IBM-IM charm, but we are unable to see in review queue and even in charm store...  can u please let us know if anything we need to do...!!!
<magicaltrout> shruthima: the review queue spends more time broken than not, ask marcoceppi if its working or not ;)
<magicaltrout> also the launchpad ingestion is broken afaik, so if you're not using the new charm publish commands you won't see it land in jujucharms.com either
<shruthima> oh k thanks <magicaltrout>
<lazyPower> cory_fu - thanks for landing those charms. I've revv'd our namespace revisions and i'm wrapping up testing the bundle
<jcastro> lazyPower: ok firing up your cluster again, you still at rev 0?
<lazyPower> Yep trying to land beats-core atm
<lazyPower> all teh charms are revv'd, just need to land the bundle and get these prom'd and we're up and running w/ the new logging stack
<jcastro> oh ok so I should wait a bit then
<lazyPower> yeah give me a bit to have someone drive this to landing and i'll have another bundle for you
<jcastro> shruthima: have you seen the new publishing documentation to publish to the store directly?
<shruthima> yes i have seen will try to push in new way
<jcastro> we have tim working full time on the new review queue so we should have something working soon, sorry for the inconvenience
<tvansteenburgh> woo woo
<shruthima> np , thanks for the information jcastro
<shruthima> Hi Cory, With ibm-base layer we have one issue. In layer.yaml we have seen a comment  #Setting options for the basic layer(http://bazaar.launchpad.net/~ibmcharmers/layer-ibm-base/trunk/view/head:/layer.yaml)  due to these when layer options are called charm deployment is getting failed. so we have tested with removing comment and it is working fine. can you suggest on same ..???
<jcastro> lazyPower: status?
<lazyPower> jcastro on?
<jcastro> you were revving the bundle no?
<lazyPower> i'm deploying beats bundle tests
<lazyPower> trying to land the new logging stack. kwmonroe is reviewing the beats promulgation, mbruzek is reviewing my kibana mp
<lazyPower> I'm about 20 minutes out from having finished this bundletester run on the beats-core bundle... which is running tests on stuff in precise: series (?!)
<lazyPower> i'll have new swarm revs for you closer to EOD
<lazyPower> storage incoming shortly after lunch/standup
<jcastro> ack
<lazyPower> jcastro - i think we'll have a beats k8s bundle for you shortly
<jcastro> no worries
<lazyPower> "observeable kubernetes"
<jcastro> hey so ~charmers
<jcastro> nm, I'll ask on the list
<DavidRama> hi how can I fix this ?? ERROR MAAS 2 is not supported unless the 'maas2' feature flag is set
<tvansteenburgh> jamespage: do you have a charm that uses the experimental rabbitmq interface?
<jamespage> tvansteenburgh, yah
<jamespage> tvansteenburgh, one sec
<jamespage> tvansteenburgh, https://code.launchpad.net/~openstack-charmers/charms/+source/charm-aodh/+git/charm-aodh
<tvansteenburgh> jamespage: ta!
<jamespage> tvansteenburgh, specifically https://git.launchpad.net/~openstack-charmers/charms/+source/charm-aodh/tree/charm/reactive/aodh_handlers.py
<tvansteenburgh> jamespage: yah, perfect, thanks
<jamespage> tvansteenburgh, thedac, tinwood and gnuoy are working on unit tests across our interfaces as well
<tvansteenburgh> jamespage: you might consider linking to this example from a readme in the rabbitmq interface repo
<jamespage> tvansteenburgh, docs etc.. on the list...
<tvansteenburgh> roger
<marcoceppi> lazyPower: https://github.com/juju/charm-tools/pull/197
<TheMue> :q!
<TheMue> Ooops :)
<tvansteenburgh> cory_fu: @when('foo', 'bar') is the same as @when('foo')\n@when('bar') right?
<cory_fu> Yes
<lazyPower> jcastro  if you have a minute, this could use your wordsmithing https://github.com/juju-solutions/bundle-observable-swarm
<jcastro> lazyPower: on it.
<jcastro> lazyPower: from now on when you need a bundle README'ed, open an issue on it and assign it to me
<jcastro> and then I'll just do them all
<magicaltrout> aww everyone needs someone like jcastro working with them....
<jcastro> magicaltrout: I will also document your incredible soon-to-be-finished gitlab. :p
<magicaltrout> hehe
<magicaltrout> well
<magicaltrout> i'm waiting on what marcoceppi called a "much larger Pull Request"
<magicaltrout> that never appeared ;)
<marcoceppi> magicaltrout: it's still in flight, I've been talking to jcastro a lot about it
<magicaltrout> aye everyones been a bit busy, you guys with 2.0 and me with 2 jobs and ApacheCon. I should have some spare time post apachecon to finish a bunch of my charms off
<jcastro> I hope there are videos from apachecon
<magicaltrout> I don't
<magicaltrout> the main rooms get videoed, the others get recorded and slides and stuff posted
<magicaltrout> (audio)
<magicaltrout> or thats how it went the last 3 years, I doubt it will change
<kwmonroe> note tvansteenburgh, @when(foo, bar); def doinit(foo, bar)....  @when(foo)\n@when(bar); def doinit(bar, foo).
<tvansteenburgh> kwmonroe: yah
<jamespage> marcoceppi, hey - can you help dig us out of a gate break?
<jamespage> marcoceppi, paramiko just released a 2.0.0 which introduces a dep on cryptography, which in a trusty virtualenv explosed with setuptools version mismatches
<jamespage> marcoceppi, could you upper bound the paramiko dep in charm-tools to <2.0.0 ?
<jamespage> that would help hugely for now
<jcastro> lazyPower: out of curiosity why are you doing kibana on precise? Keeping the old version on purpose I take it?
<lazyPower> jcastro - if you're referring to the tests, that was inhereted.
<lazyPower> oooo wait i see it now
<lazyPower> and no that was a mistake
<jcastro> ok, heh
<jamespage> marcoceppi, ignore me apparently I'm beeing stoooppid today.,..
<jcastro> lazyPower: it's not obvious from the bundle format, but where do the filebeat and topbeat services live?
<jcastro> on each node?
<lazyPower> correct. they are subordinate units
<lazyPower> jcastro https://github.com/juju-solutions/bundle-observable-swarm/pull/1 ta for pointing that out
<jcastro> how can I determine where subordinates live in the bundle format?
<LiftedKilt> having trouble with the openstack-lxd bundle - can't save any images to glance
<lazyPower> by relating them over the "beats-host" relation
<LiftedKilt> any pointers on where to look? juju things everything is peachy
<lazyPower> jcastro other than that i'm not aware of any obvious hints
<LiftedKilt> ceph reports all the pgs being stuck inactive
<jcastro> lazyPower: ok, also, beats supercedes logstash right?
<lazyPower> Beats work with logstash
<lazyPower> logstash for the most part wont be required unless you need ot stream to multiple data-sorces, or do even more transformations on the data before ingest
<lazyPower> pardon typos
<jcastro> oh I see in their docs, it replaces logstash-forwarder
<lazyPower> correct. beats are the new shipping agent for all sorts of data
<lazyPower> the traditional ELK stack has been turned on its head
<bsod90> Hey everyone! I'm getting this error http://d.pr/i/jPVn when trying to open openstack-lxd bundle from ui (juju2). Other bundles seem to open fine. What would that mean?
<tvansteenburgh> stub: don't suppose you're around?
<jcastro> lazyPower: PR incoming
<lazyPower> jcastro ta
<jamespage> marcoceppi, tvansteenburgh, lazyPower: https://github.com/juju/charm-tools/pull/199
<jamespage> we need digging out of a hole pls :-)
<marcoceppi> jamespage: lgtm, where do you pull charm-tools from in ci?
<jamespage> marcoceppi, pypi
<jamespage> via tox/venv
<marcoceppi> jamespage: you can also fix this by just installing libssl-dev and libffi-dev in your testing env
<jamespage> marcoceppi, we need to review our dependency management to ensure we upper bound, but I did not want todo that during a gate break
<jamespage> marcoceppi, that's not actually the problem - once you install those, cryptography wants >=11.2 of setuptools
<jamespage> trusty virtualenv installs 2.2
<marcoceppi> jamespage: ah, that fixed it on xenial
<marcoceppi> jamespage: tbh, I'm not even sure why paramiko is in there
<marcoceppi> I think I added it becaues it was needed by launchpadlib
<marcoceppi> jamespage: this is going to be a bit awkward for a release, but I will get on this right away
<jamespage> marcoceppi, thankyou very much appreciated...
<marcoceppi> jamespage: I'm not sure how, but your branch has merge conflicts
<marcoceppi> jamespage: don't worry about it, I know it's getting late over there, I'll sort them out and cut the release tonight
<bsod90> How can I debug networking for container created by juju? I see from logs that internet if unreachable from 3/lxc/1 for some reason. I can ssh to machine 3, but how can I see how the things look like from inside lxc/1 ?
<tvansteenburgh> bsod: lxc exec <container name> --mode=interactive /bin/bash
<tvansteenburgh> bsod90: ^
<bsod90> tvansteenburgh: thank you!
<tvansteenburgh> so ssh to machine 3, run `lxc list` to get container name
<tvansteenburgh> np
<marcoceppi> tvansteenburgh: what the heck
<marcoceppi> tvansteenburgh: `lxc exec <container> bash` is all you need
<tvansteenburgh> i went above and beyond
<magicaltrout> hehe
<marcoceppi> bsod90: also, you probably have lxc1.0 if so, `sudo lxc-ls --fancy` and then ssh ubuntu@<ip-container>
<bsod90> it actually turned out to be "sudo lxc-attach juju-machine-3-lxc-1"
<bsod90> :)
 * tvansteenburgh shrinks into the corner
<LiftedKilt> in lxc1 you can lxc-attach --name container
<magicaltrout> direct amulet questions at tvansteenburgh he loves them ;)
<tvansteenburgh> ha
<tvansteenburgh> i got so many it drove me to write docs, of all things
<magicaltrout> hehe
<magicaltrout> it you could make it psychic that would be better
<bsod90> "subprocess.CalledProcessError: Command '['unit-get', '--format=json', 'private-address']' returned non-zero exit status 1
<magicaltrout> actually that would be cool, a bit like the Selenium test builders for FF and stuff
<bsod90> oops
<magicaltrout> create a test harness that just lets you replay juju commands though it with minor tweakage for assetions
<magicaltrout> +r
<tvansteenburgh> magicaltrout: cool idea, let me know when you have it ready!
<magicaltrout> lol
<magicaltrout> remind me in a few months when the rest of my life is in order and I'll consider it ;)
<tvansteenburgh> i hear ya
<bsod90> what would 'private address not found' error comming from unit-get mean?
<cory_fu> Is there any way to set list values for action results?
<barry> cherylj: hi :)
<cherylj> hi barry :)
<barry> cherylj: oh, i'm having so much trouble :)
<cherylj> I'm sorry to hear that :(
<barry> cherylj: if it helps make juju + charms better, it's okay!  if i'm just being dumb, maybe that's okay too :)
<cherylj> barry: did you try juju resolved?
<barry> i did, and it returned without any output
<cherylj> that's expected.  It will retry the failing hook on the unit
<cherylj> so you'll need to look at the status again
<barry> oh wow... juju status is very unhappy:
<cherylj> oh no
<barry> % juju status
<barry> WARNING discarding API open error: connecting with cached addresses: unknown model: "8d79af51-015a-4283-8d87-8ab0bf1f68a3" (not found)
<barry> ERROR connecting with bootstrap config: unknown model: "8d79af51-015a-4283-8d87-8ab0bf1f68a3" (not found)
<barry>  
<cherylj> barry: did you happen to remove a model and add a new one of the same name?
<cherylj> (see bug 1576359)
<mup> Bug #1576359: Cannot talk to a new model with a reused name <juju-release-support> <switch> <juju-core:Triaged> <https://launchpad.net/bugs/1576359>
<barry> cherylj: pretty sure i didn't try to add a new one.  in my flailing about i did try to destroy the model
<cherylj> oh you might still be in there as your current model
<cherylj> 'juju switch' will show you what model you're working in
<barry> ah yes, i'm still using local.mailman3-test:default
<barry> (admin is the only model shown by juju list-models)
<cherylj> ah, yeah that would do it
<cherylj> if it doesn't exist anymore
<barry> okay, gotcha
<cherylj> so did you destroy the model that was having the unit failures?
<barry> cherylj: i did
<cherylj> used the big hammer :)
<cherylj> heh heh
<barry> yeah, nothing else seemed to be working.  maybe i was impatient, but i did wait 5 minutes or so
<barry> cherylj: btw, am i helping by reporting bugs on the github projects, or should i use launchpad?
<cherylj> barry: I was just about to tell you that you should be using lp
<cherylj> :)
<cherylj> mind reader
<cherylj> the juju mailing list is also a good way to get help
<cherylj> if you're not sure how to do something
<barry> yeah, i should probably join the mailing list.  i just dread the inbox filling ;)
<cherylj> it's actually not so bad
<cherylj> and I'm all ALL the juju lists :)
<barry> :)
<barry> i wonder if it's on gmane...
<cherylj> https://lists.ubuntu.com/mailman/listinfo/juju
<barry> \o/
<cherylj> barry: you can ping me if you run into the issue again.  Hopefully we can figure it out :)
<barry> awesome, thanks!
<bsod90> does juju deal with dhcp somehow? I'm trying to understand how container interfaces are getting their IPs.. I thought they supposed to get IPs from whatever DHCP is running in bridged network, but I just observed the situation where one container got a gateway IP, which means it certainly did not get it from DHCP. At least not from one it supposed to get it from..
#juju 2016-04-30
<stub> tvansteenburgh: pong
<tvansteenburgh> stub: with the postgres-built charm, is it possible that i get all my relation info (including seeing my unit in allowed-units) before pg_hba.conf is updated and reloaded?
<tvansteenburgh> stub: b/c that's what i'm seeing. i get all my conn info, try to connect, and get a pg_hba rejection error
<tvansteenburgh> stub: eventually i'll be able to connect though
<tvansteenburgh> stub: i've got this fix to the interface pending (https://github.com/bcsaller/juju-relation-pgsql/pull/3/files), but i think i saw it happen even after patching that. will run some more tests and let you know
<tvansteenburgh> stub: of course now that i've mentioned it, the last two attempts i haven't been able to reproduce it. so maybe the interface was the culprit
<DavidRama> hi folks, trying to run juju with maas and got this message when trying to bootstrap: ERROR MAAS 2 is not supported unless the 'maas2' feature flag is set any any clue how to set this right ?
<Brochacho> Hello all, I'm a participant of GSoC this year and was wondering if setting up a local lxd setup via `juju bootstrap local lxd` requires I have an ssh key to log into the machines
<Brochacho> I'm on Xenial, juju 2.0
<DavidRama> Hi, trying to bootstrap juju with maas, it manages to aquire my node but fails after that with these erroe messages, any idea why this doesn't work ? If I delpoy by hand the host is works. Running 2.0 and xenial - thanks 2016-04-30 17:45:20 INFO juju.provider.common destroy.go:33 destroying instances
<DavidRama> 2016-04-30 17:45:20 ERROR juju.cmd.juju.commands bootstrap.go:686 error cleaning up: destroying instances: machine 0: blockdevice 5: blockdevice 2.0 schema check failed: model: expected string, got nothing
<DavidRama> 2016-04-30 17:45:20 ERROR cmd supercommand.go:448 failed to bootstrap model: cannot start bootstrap instance: cannot run instances: cannot run instance: blockdevice 5: blockdevice 2.0 schema check failed: model: expected string, got nothing
<Brochacho> Disregard my last question, had to use `juju ssh $unit_name`
<cherylj> DavidRama: in case you didn't get an answer yet:  export JUJU_DEV_FEATURE_FLAGS=maas2 then try to bootstrap
<cherylj> DavidRama: maas2 support is still under development, so it's behind a feature flag
<DavidRama> @cherlj thanks
<DavidRama> Got it working now
<DavidRama> Another question, how/where do I tell juju to initialise all the had drives of my machines ? and not only /dev/sda ? Thanks
<DavidRama> hard drive sorry
#juju 2016-05-01
<jrwren_> DavidRama: typically a charm would do that.
<DavidRama> jrwren_, like a post-installation script ? Are there some examples available somewhere for this ?
<veebers> I'm running juju from source, I see models/controllers are new (compared to ver 1.*). How does one show which environment they are current in? 'juju switch' complains about there being no specified model and apparently to get that setup you need to bootstrap
 * veebers reads the relevant docs and sees the answer
<jrwren_> juju list-models
#juju 2017-04-24
<kjackal> Good morning Juju World!
<magicaltrout> its average at best
<magicaltrout> it is monday after all
<admcleod> whos a little mr grumpypants
<blahdeblah> Hi all.  juju add-model has a --credential flag; is there a way to set this after the model has been added? or show which credentials are in use for a model?
<magicaltrout> too much wine, too little sleep ;)
<blahdeblah> magicaltrout: That'll do it every time
<magicaltrout> indeed
<magicaltrout> i never learn
<admcleod> blahdeblah: well, if you're in the model, you can 'juju add-credentials'
<admcleod> -s
<blahdeblah> admcleod: I was about to ask whether that did the same thing
<cnf> btw, is there a proxmox provider for juju?
<cory_fu> tvansteenburgh: For https://github.com/juju-solutions/interface-kube-control/pull/2 can you point me to the charm that uses that layer?  Is it kubes-master?
<tvansteenburgh> cory_fu: yeah, thanks for looking at that
<tvansteenburgh> cory_fu: https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py
<cory_fu> tvansteenburgh: Thanks
<cory_fu> tvansteenburgh: I assume the issue is that https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L308 is triggering when there are still workers (or whatever they're called)?
<tvansteenburgh> cory_fu: https://github.com/juju-solutions/interface-kube-control/issues/1
<tvansteenburgh> cory_fu: so, yes
<cory_fu> tvansteenburgh: That's very odd.  That's not a peer relation so I can't see any way it should be affected by scaling.
<cory_fu> tvansteenburgh: Deploying to see if I can replicate
<tvansteenburgh> cory_fu:  oh. i think the problem is on the worker side.
<tvansteenburgh> cory_fu: you remove a master, and then all the workers think they're not connected, when they are in fact still connected to the other master
<cory_fu> Hrm.  Looking at the requires now
<cory_fu> tvansteenburgh: Hrm.  Logic still seems fine.
<cory_fu> tvansteenburgh: When my kubes-core finishes coming up, I'll debug at it a bit
<tvansteenburgh> cory_fu: tyvm
<kwmonroe> cory_fu: is it frowned upon to use @hook('upgrade-charm')?  on upgrade, i want to re-trigger an install() method that typically prevents a re-trigger by setting an 'installed' state.  i'd like to remove this state on upgrade and can either do it with @hook, or set additional kv data that i can use in a data_changed handler. is one way better than the other?
<kwmonroe> .. keeping in mind that i don't currently have a data_changed handler, so it would be a new function either way.
<cory_fu> kwmonroe: There's not really an alternative at this point.  I'd like to remove the need for it, but I think upgrade-charm is probably the best case for @hook.
<cory_fu> kwmonroe: Though, if you're talking about upgrade-charm being triggered by a new resource, rather than new charm code, you could use data_changed (or I think there is a file_changed helper as well) instead if you wanted
<kwmonroe> cory_fu: both attach triggers upgrade-charm, which triggers config-changed, right?  if so, i think i'll use a when(config.changed) with appropriate data_changed conditions in it.
<kwmonroe> s/both//
<cory_fu> kwmonroe: Yeah, I think that's right and will work
<cory_fu> tvansteenburgh: Added a comment on https://github.com/juju-solutions/interface-kube-control/issues/1
<cory_fu> tvansteenburgh: TL;DR is that the issue is the GLOBAL scope
<tvansteenburgh> cory_fu: yeah, that makes sense :/
<bdx> kubernetes-peeps: how can I set EXTRA_DOCKER_OPTS on the kubelets .... can I just "snap set kubelet insecure-registry=10.0.0.0/8" ?
<lazyPower> bdx: i've been following along with 1685782 - :(  just added some bug heat there too
<lazyPower> bdx: that should be the case, yeah. Is that something you need exposed in the charms?
<bdx> lazyPower: using a mix of @SaMnCo's blog and my own findings, I have a working CDK + deis ... its amazing
<lazyPower> bdx: <3
<lazyPower> fan-freaking-tastic news
<lazyPower> keep notes on your pain points for issues and I'll be happy to get those on our next planning cycle
<bdx> lazyPower: yea, thanks for the heat there... I had to focus somewhere else, as all my other ops are blocked by that darn bug
<bdx> I'm beside myself as to how that made its way into a release
<bdx> but whatever
<lazyPower> bdx: I know you're going to find more dragons in our charms using spaces, just be aware that testing that particular scenario historically hasn't been heavily invested in, and we do indeed need to add that to our future roadmap
<SaMnCo> bdx: awesome! Let us blog about this. Today I met with riseML they do a sort of PaaS for Deep Learning
<bdx> lazyPower: ok
<lazyPower> we're going to need to add support for extra bindings and spaces and get some test suites written around that. Its an eventual certainty
<SaMnCo> Will probably need some of that XP for them as well
 * lazyPower silently sets modifier to 2x xp rates on the server
<lazyPower> magicaltrout: speaking of xp and server rates, i found an older container build for ark servers thats even better than what i sent over. Would love to collab with you on a chart if thats something you're interested in.
<bdx> SaMnCo, lazyPower: so ... my problem with the registry (one that I've hit before) can be found here https://github.com/deis/registry/issues/64
<bdx> SaMnCo, lazyPower: I've applied the patch (near the bottom) to the workflow ... now I just need to add some EXTRA_DOCKER_OPTS to my kubelets
<bdx> for the insecure local registry https://deis.com/docs/workflow/en/v2.2.0/installing-workflow/system-requirements/#docker-insecure-registry
<lazyPower> bdx: yeah, your snap config kubelet should work a treat for that, we dont do any validation so you can pass malformed config all day ;)
<bdx> so I need to set EXTRA_DOCKER_OPTS="--insecure-registry=10.0.0.0/8"
<bdx> ok
<bdx> sweet
<lazyPower> Cynerva: or ryebot  may correct me, but i'm 98% certain thats the case
<lazyPower> as they were teh primary authors of that feature of the snap(s)
 * ryebot catches up
<ryebot> hmm
<ryebot> That's an env var for kubelet?
<ryebot> pretty sure our config handling only works for cli args
<bdx> do the kubernetes charms allow for setting EXTRA_DOCKER_OPTS somewhere?
<ryebot> Hmm let me see
<bdx> ryebot: sudo docker -d --insecure-registry 10.0.0.26:5000
<bdx> it is a cli opt
<ryebot> Not that I can see, correct me if I'm wrong lazyPower or cynerva
<ryebot> ah I see it
<ryebot> looks like layer-docker has an extra-opts configuration setting
<ryebot> so if you do a `juju config kubernetes-worker`, you should see a `docker-opts` configuration you can alter
<bdx> ryebot: so, which should I favor then?
<ryebot> bdx: afaict using docker-opts is your only option
<bdx> ryebot: if you don't mind me asking, why can't/shouldn't this be done via `snap set`?
<ryebot> bdx: looks to me like it's a docker config, which is currently exposed via layer docker
<ryebot> bdx: so, I don't think there's currently a snap config that would work
<bdx> ryebot: doesn't the snap config accept all cli args?
<ryebot> bdx: it does for our k8s snaps, but we're not currently snapping docker itself, just the kubelet half of that relationship
<bdx> ryebot: I see. thx
<ryebot> bdx: no problem, feel free to ping me if you hit any roadblocks
<bdx> rybot: thanks
<lazyPower> bdx: well DOCKER_OPTS is a thing, but do you need to pass this along to kubelet as well?
<lazyPower> sorry i was afk otp
<lazyPower> ryebot: bdx: yeah setting the dockeropts should satisfy this looking at it. If you come up with issues with kubelet lmk and we can work through that nuance.
<ryebot> thanks lazyPower
<skay_> hm, on my juju2 deployed system my landscape-client is failing in the config-changed hook because it has missing info from juju, but I'm not familiar enough with the landscape client to know exactly what is causing it. anyone here familiar with it?
<skay_> it's expecting to get environment-uuid from a juju config file. I'm not sure where that lives
<skay_> happens around here https://bazaar.launchpad.net/~landscape/landscape-client/trunk/view/head:/landscape/broker/registration.py#L192 and it's reading a json file somewhere, as you can see here https://bazaar.launchpad.net/~landscape/landscape-client/trunk/view/head:/landscape/lib/juju.py
<erik_lonroth> Hello. I was trying to deploy to a "centos7" series on my local lxc controller and it didn't seem to work. As this would to me seem like a key functionality - is there anyone that can tell me what I need to do to make this work ?
<erik_lonroth__> This is how I try to deploy: juju deploy ~/git/juju/charms/hello-world --series=centos7
<erik_lonroth__> Juju outputs: juju deploy ~/git/juju/charms/hello-world --series=centos7
<erik_lonroth__> oops
<erik_lonroth__> Deploying charm "local:centos7/hello-world-2".
<erik_lonroth__> But after that.... juju status shows Machine as "down" and lxc shows no machine has been spawned.
<lazyPower> erik_lonroth__: it can take a few moments for the lxd provider to download the cloud image. How long has it been since you issued the deploy command?
#juju 2017-04-25
<dpawar> jamespage:what is the right time to talk to you ?
<dpawar> are you online now ?
<dpawar> pranav: https://developer.openstack.org/api-ref/compute/?expanded=list-all-major-versions-detail,list-servers-detail#list-servers
<kjackal> Good morning Juju world!
<jamespage> dpawar: +1.5 hours from now please
<cnf> so has anyone on the juju team looked at https://bugs.launchpad.net/juju/+bug/1681495 ?
<mup> Bug #1681495: add juju lxd proxy configuration <juju:New> <https://launchpad.net/bugs/1681495>
<urulama> SimonKLB: ping
<erik_lonroth> lazyPower: I'm going to try again now to deploy on centos7 and wait longer. How can I monitor the progress?
<lazyPower> erik_lonroth: there should be a wget going to fetch that cloud imag eif it doesn't exist.
<lazyPower> erik_lonroth: additionally `lxc image list` shoudl show something like juju/centos/7
<tychicus> just got kubernetes up and running and ran into this issue attempting a helm install https://github.com/kubernetes/helm/issues/1455
<lazyPower> tychicus: which bundle? kubernetes-core or canonical-kubernetes?
<tychicus> canonical-kubernetes
<lazyPower> tychicus: its the "error upgrade connection" not the DNS issue correct?
<tychicus> lazyPower: originally the DNS issue, that is fixed no getting the upgrade issue
<lazyPower> tychicus: that means the reverse proxy isn't respecting the http2 protocol.
<tychicus> 504 Gateway Time-out
<lazyPower> tychicus: which version of kube-apiloadbalancer do you have deployed?
<lazyPower> that should have been resolved with our 1.6.1 push week before last...
<tychicus> ok, just did the install within the last 24 hours
<tychicus> lazyPower: how do I find the kube-apiloadbalancer version?
<lazyPower> juju status kube-api-loadbalancer, there will be a charm revision in that output
<lazyPower> eg: kube-api-loadbalancer/7
<lazyPower> argh, i typod it
<lazyPower> kubeapi-load-balancer
<erik_lonroth> lazyPower: Nothing seems to have made it https://postimg.org/image/ynuq1ac41/
<tychicus> 1.10
<erik_lonroth> lazyPower: As you can see from the image, it seems centos7 is not in the list of images even now after waiting some time.
<lazyPower> erik_lonroth: http://pad.lv/1495978
<lazyPower> it looks like this isn't supported on the lxd provider at this time. Its also ben closed as of 2/22 with a "fix committed" status, that confuses me as i see nothing related to actually fixing the issue
<lazyPower> tychicus: 1 moment.
<tychicus> lazyPower: np, thanks
<lazyPower> rick_h: do you have any clarity here you can shed on http://pad.lv/1495978
<rick_h> lazyPower: looking
<erik_lonroth> lazyPower: Thats exactly my thought also. I read that bug earlier, thats also why I asked here. I was assuming I made some kind of error.
<rick_h> lazyPower: yea....so we were going to get that a bit ago. I'm not sure where it's at atm.
<lazyPower> it was closed recently as fix released
<rick_h> lazyPower: erik_lonroth so the deal was that you could do it with your own images in maas/lxd images/etc but having it work with Juju in the cloud meant "picking" an image that we don't provide/support as the basis for juju working or not.
<lazyPower> does this mean its coming or does this mean we dropped it all together? there's a lot of churn in that issue.
<lazyPower> ah ok
<rick_h> lazyPower: erik_lonroth so the issue was what process would be put in place to select what image id in each cloud was "THE CENTOS" that would be tested/supported/used.
<lazyPower> so the churn continues...
<rick_h> lazyPower: erik_lonroth and how we'd handle if that image was pulled, changed, etc.
<rick_h> lazyPower: erik_lonroth it was "90%" done at one point but I'm not sure if it ever got over that hump. This is a LXD case, does it work sans-lxd?
<rick_h> lazyPower: erik_lonroth we'd have to bug balloons to see if he has any insight beyond my history of it.
<rick_h> lazyPower: erik_lonroth I think azure and aws were the two targets first.
<erik_lonroth> I understand, but the argument proposed in the bug that supporting at least some kind of workflow for centos would be a winning feature of juju. At least, a good idea would be to provide some kind of indication that this needs either some manual "fix" to let me install centos, or how to get this feature to operate as I would hope. After all, centos is one "of the major" dists out there.
<erik_lonroth> ... as it is now, me as a noob on juju, is getting into a situation where I can't distinguish between this as a "method error" or a "bug"
<balloons> what is this?
<rick_h> balloons: do you have any insights on centos charms on lxd or public clouds?
<rick_h> balloons: I know there was work to select a centos image in azure/aws but not sure if that ever "got released"
<rick_h> erik_lonroth: understand and agree. We also love saying Juju is cross OS and we work on the client being multi-platform. Our issues with ootb centos is a :(
<erik_lonroth> I understand also. I'd love to help out here as I see the potential. Fixing issues lite this bridges also a healthy transition over OS:es and I see a number of "charms" that needs this functionality.
<erik_lonroth> One charm I'm looking for is the "freeIPA" which is a KEY element if you want to bring in enterprise level authentication systems with juju. At the moment, I don't know about a charm that deals with authentication in the charm store. (If you know about any, please let me know =)
<erik_lonroth> https://www.freeipa.org/page/Main_Page
<balloons> rick_h, we do test on centos on aws indeed
<rick_h> balloons: ah ok, it'd be nice to see if it's using some hard coded image id or if it's available to all.
<balloons> rick_h, the deploy is a simple charm, but you can do a basic bootstrap and deploy
<rick_h> balloons: k, erik_lonroth what charm are you using? I wonder if I can test it on aws
<rick_h> maybe hit and see where it might work vs doesn't and at least get farther on what works vs doesn't atm
<erik_lonroth> I'm using my own charm which is part of my "tutorial" writing to help my colleges to get started on juju development: https://github.com/erik78se/juju/wiki/The-hello-world-charm
<erik_lonroth> I've tested my charm on ubuntu already and now I wanted to "prove" juju as being linux-agnostic.
<erik_lonroth> ... well, at least "centos"/"ubuntu" agnostoc.
<rick_h> erik_lonroth: rgr
<erik_lonroth> This is what my next tutorial would likely be... showing that the hello-world example indeed can be commissioned on both ubuntu/centos.
<balloons> rick_h, seems I misspoke. I looked at the test and it still bootstraps with trusty
<rick_h> balloons: k, I'm ok with it bootstrapping just curios on the charm deploy
<rick_h> balloons: e.g. can we mix centos/ubuntu workloads and the like
<balloons> rick_h, that is the idea of the test it seems
<erik_lonroth> I don't know really at the moment where we are in this process...? Are we stuck with "not being able to support centos images", or is there a workaround, or what is the verdict here?
<zeestrat> rick_h: What's the plan on different LXD storage backends when deploying on MAAS? The default directory option that Juju uses is quite inflexible. We have separate /var partitions on our MAAS nodes which we need to watch out for as they get rather full when you're colocating LXD containers (something which quickly could take down all LXD containers).
<rick_h> zeestrat: yea there's a bug around the /var issue. I know there was a plan but not sure where it's at on the todo list atm
<zeestrat> If you're thinking about #1634390, then that is something else. This is about being able to select different storage backends such as LVM instead of just straight up directories for LXD to use as a storage backend.
<mup> Bug #1634390: jujud services not starting after reboot when /var is on separate partition  <uosci> <juju:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1634390>
<zeestrat> Just wondering if this was something on the roadmap. If not, I'll write up a bug with the details.
<tychicus> lazyPower: applied the settings listed here https://kubernetes.io/docs/getting-started-guides/ubuntu/troubleshooting/ now I get a slightly different error message Error: forwarding ports: error upgrading connection: error dialing backend: dial tcp 10.148.0.100:10250: getsockopt: connection timed out
<rick_h> erik_lonroth: ok, so on aws, once you agree to the terms of the centos7 image, I was able to deploy your charm on --series=centos7 and then the install hook errors with the "apt not found"
<rick_h> erik_lonroth: so yea, it works in theory, but not across the board atm
<tychicus> kubernetes is deployed on top of openstack
<rick_h> erik_lonroth: confirmed gce doesn't have an centos image set for use
<lazyPower> tychicus: sorry i'm getting pulled, i will circle back in a moment
<rick_h> good grief that centos image is slow
<tychicus> edited the security group to enable ingress on tcp 10250 0.0.0.0/0 to the specific kubernetes worker that helm was attempting to communicate with. this allowed helm to run
<lazyPower> tychicus: ah, juju run --application kubernetes-worker "open-port 10250" && juju expose kubernetes-worker
<lazyPower> tychicus: thats hwo you would accomplish that natively in juju terms.
<tychicus> thanks
<tychicus> and that will expose all workers
<tychicus> next question is related to persistent volume storage there is a great write up here https://kubernetes.io/docs/getting-started-guides/ubuntu/storage/ but I already have ceph deployed for openstack, so I think I would just use cinder to give persistent volumes to kubernetes
<tychicus> is that as simple as using the storage charm and doing juju deploy canonical-kubernetes âstorage data=50G
<lazyPower> tychicus: so the only storage backends we support today are nfs and rbd from ceph
<lazyPower> you can do som emanual ops to get things like ebs working pending our cloud native support however those are WIP and in a pre-alpha state at this time. (and you're deploying on openstack)
<lazyPower> tychicus: so wrt supporting cinder, a bug filed would go a long way towards helping us prioritize those storage providers natively without any manual intervention
<tychicus>  lazyPower: so can I connect to the existing ceph rdb?
<lazyPower> you certainly can
<lazyPower> tychicus: add the relation between your ceph-mon and kubernetes-worker charms, and there's an action for enlisting RBD's as PV's
<lazyPower> tychicus: one thing to note, that action doesn't validate and its entirely possible to over-provision your rbd's. eg: enlist a 90tb rbd as a pv, and k8s will gladly take it and do what it will with the rbd, even though theres no hope of fulfilling that requests initial storage capacity without adding physical disks and enlisting in the OSD's.
<lazyPower> thats one thing i've discovered that I haven't come up with a fix for just yet
<lazyPower> tychicus: additionally you can enlist the credentials and use the rbd auto-provisioner
<lazyPower> but thats not something we've enabled out of the box just yet. its on the todo list.
<lazyPower> tychicus: https://github.com/kubernetes/kubernetes/tree/master/examples/persistent-volume-provisioning - the CephRBD example illustrates how to setup the rbd auto provisioner.
<tychicus> lazyPower: just to make sure that I understand all of this correctly, since I am still very new to juju and I very well could have done some things wrong.  I used juju + maas to deploy openstack on physical hardware.  Then I used juju to deploy kubernetes on top of openstack.  I currently have 2 juju bootstrap nodes 1 node controls openstack, the other controls kubernetes
<lazyPower> tychicus: ah, nested...
<lazyPower> So that relationship i outlined was if it were on the same layer as the openstack deployment, since its nested you cannot reasonably relate k8s to ceph.
<lazyPower> good call. in this case, i would recommend enlistment of the ceph credentials, and using the rbd provisioner
<tychicus> I can use the existing Ceph Cluster deployed for openstack to provide persistent storage to the kubernetes cluster via https://github.com/kubernetes/kubernetes/tree/master/examples/persistent-volume-provisioning
<lazyPower> correct
<lazyPower> the RBD example there should get you moving. You'll need to create a secret with your ceph credentials and enlist the storage class
<tychicus> thanks, and thanks again for your assistance
<tychicus> as far as having 2 bootstrap nodes, is that correct, or shouldI only have a single bootstrap node with multiple models?
<lazyPower> you should have been able to re-use that initial bootstrap node for your openstack deployment
<tychicus> ok
<lazyPower> rick_h: fact check me here?
 * rick_h reads backward
<lazyPower> i'm going to owe mr _h a pizza by the end of today
<lazyPower> or a beer, notwithstanding.
<tychicus> do you know offhand what the syntax is for telling juju about an already existing bootstrap node?
<rick_h> tychicus: e.g. using a single controller for multiple providers?
<rick_h> tychicus: it doesn't support that at this time.
<lazyPower> gah
<lazyPower> i lied :( sorry
<lazyPower> really glad i pinged
<rick_h> tychicus: if they're on the same provider, you can just add-model with a region flag
<tychicus> ok and does controller == bootstrap node?
<lazyPower> you are correct
<lazyPower> a controller is the 2.0+ terminology for a bootstrap node.
<tychicus> ok, so it makes sense to have 1 controller for MaaS and another controller for openstack
<vasey> hey folks, i'm getting an error about a node not having an address family in common with my MAAS server that i'm trying to bootstrap a controller for (full error message here: https://pastebin.com/Pd8ktgPm) any ideas as to how to fix this?
 * rick_h is sorry to not say "yes!"
<lazyPower> vasey: looks like your network config in maas doesn't match whats happening in that rack.
<lazyPower> vasey: did you model the network fabrics in maas that match whats coming back from the DHCP server? i can only presume you'r eusing an external DHCP in this setup...
<tychicus> rick_h: thanks for the clarification
<tychicus> lazyPower: thanks for all the help
<lazyPower> tychicus: no problem, ping me with any questions about k8s :) happy to help.
<lazyPower> i clearly need to brush up on my non k8s bits... i'm a bit embarrased to have fibbed about the controller support :S  I'm living in a JAAS world, and its easy to blur the lines apparently.
<tychicus> so far I am very happy with what I have seen in juju thus far, excited to learn more
<lazyPower> Thats great to hear :)
<vasey> lazyPower: i'm using the MAAS built-in DHCP for this setup, and everything seems fine on that end; should i have given my juju a static IP
<lazyPower> well this is fun, i cant find a bug with that error text either
<lazyPower> this might be greenfield
<lazyPower> actually this seems related https://bugs.launchpad.net/maas/+bug/1683433
<mup> Bug #1683433: MAAS 2.2-rc1 refuses to deploy if all a node's interfaces are set to DHCP <regression> <MAAS:Fix Committed by blake-rouse> <https://launchpad.net/bugs/1683433>
<lazyPower> vasey: do the nodes successfully boot if you manually deploy one?
<erik_lonroth> rick_h: Thanx for testing it out and yeah, the "apt" thing error was very expected. But, the centos awkwardness for testing with lxd seems to me really something worth addressing. The typical development workflow would be to test on a local lxc and if that scenario fails, I think the concept also fails.... Can I help out here somehow ?
<vasey> lazyPower: i haven't tried a manual deployment, though they automatically PXE boot into the ephemeral ubuntu image just fine though
<rick_h> erik_lonroth: I think it's got to be streams work with lxd->image listing->juju trust that has to be setup for lxd
<lazyPower> vasey: that error message is actually surfacing from maas, i've grepped through the juju tree and dont find that error message.
<lazyPower> vasey: so it leads me to beleive there's an issue with the unit configuration in maas.
<lazyPower> that coupled with 1683433 linked above, i think its related to the networking configuration and its a bug in 2.2.0-rc1+
<erik_lonroth> rick_h: I'm sorry, but I don't quite follow you there. "streams" ?
<vasey> lazyPower: interesting! i'll look into that
<lazyPower> erik_lonroth: streams are a json listing of image type / series (like centos type, series is 7, or ubuntu type, series is xenial) and where to fetch those cloud images from.
<tychicus> how do you connect to an existing juju controller from a new juju client?
<bildz> hey guys, is anyone using the purity charm?
<vasey> lazyPower: turns out none of my nodes had an interface configured with an auto-assigned address, that did the trick
<rick_h> tychicus: try again? where's the client at?
<rick_h> bildz: not tried it out myself, what's up?
<lazyPower> vasey: awesome! glad we got you fixed up.
<lazyPower> bildz: would you be referring to https://jujucharms.com/u/brent-clements/cinder-purity/ ?
<magicaltrout> hello people
<magicaltrout> can you still get the dashboard list of your own charms in the charmstore?
<magicaltrout> oh i see what its doing there
<rick_h> magicaltrout: ?
<magicaltrout> this is what gets on my tits about the store search
<magicaltrout> rick_h: what do i need to change to get my gitlab charm to show up?
<magicaltrout> just call it something else?
<magicaltrout> i don't even know how you know it exists
<rick_h> magicaltrout: heh, I saw your email and I knew to check your user account.
<magicaltrout> meh
<rick_h> magicaltrout: the best thing is to get it promulgated I guess.
<magicaltrout> that takes effort! :P
<magicaltrout> i have a backlog of charms to get promulgated, this is why i have new people starting, to get through my self inflicted backlog ;)
<rick_h> magicaltrout: yea, looks like the one there now has just been limped along by lazyPower and others.
<rick_h> magicaltrout: shouldn't be too bad to get it swapped out. I'm sure they'd like to have someone else doing awesome stuff in that namespace
<magicaltrout> i don't get why the search just ignores anything with the same name
<magicaltrout> why not just segregate the results somehow
<rick_h> magicaltrout: used to do that and it confused folks getting several versions of ceph and the like
<magicaltrout> hmmmmmmmmmmmmmmmmmmm
<magicaltrout> fair enough
<magicaltrout> can't you just tell them not to be confused? ;)
<magicaltrout> or "check this box to return stuff we really have no idea if it works or not" ;)
<rick_h> magicaltrout: yea, so the new agreement was to add an option to "find all other options" or the like
<rick_h> magicaltrout: but not been completed yet
<magicaltrout> ah
<magicaltrout> cool
 * rick_h sees a handful of gitlab deploys and checks who's charm they are running
<rick_h> hmm, yea 8 of the current one out there I can tell
<rick_h> magicaltrout: so yea we'd have to work out a migration path as part of swapping the promulgated version :(
<rick_h> magicaltrout: or push yours as trusty as the current one is only precise
<rick_h> which would be <3
<magicaltrout> my will be xenial and trusty when i get the former checked
<rick_h> magicaltrout: cool
<magicaltrout> https://jujucharms.com/u/spiculecharms/gitlab okay rick_h
<magicaltrout> thats the one, although I need to push an updated readme and a few tweaks in the morning
<magicaltrout> i'll write some tests and get it into the review queue when I get an hour or 3 later in the week
<rick_h> magicaltrout: it's not public
<magicaltrout> meh
<rick_h> magicaltrout: rgr
<magicaltrout> my guesses failed me
<magicaltrout> public now rick_h
<rick_h> magicaltrout: ty I see it
<rick_h> magicaltrout: ooh, support http endpoint! /me rushes to use it with the ssl-termination charm
<magicaltrout> its set to the latest version, but if people want to run a specific version they can, i've tested 8.0 through to 9.1 or wherever we are now
<magicaltrout> i have some code to decouple the database and other bits but i've not tested them thoroughly yet
<magicaltrout> it will land one day
#juju 2017-04-26
<anrah> any guess when 2.2 Beta 3 will be out?
<anastasiamac> anrah: is there something specific u r after in 2.2-b3?
<anrah> anastasiamac: Yes: https://bugs.launchpad.net/juju/+bug/1654144
<mup> Bug #1654144: AllocatePublicIP fails on some Openstacks <bootstrap> <oil> <openstack-provider> <juju:Fix Committed by hmlanigan> <juju 2.1:Won't Fix> <https://launchpad.net/bugs/1654144>
<anrah> There is couple fixes in 2.2 I would like to test on our environment but 2.2 does not work with FloatingIp's on our OpenStack
<anastasiamac> anrah: there is a hope that 2.2-b3 may be available this week. I cannot give u more concrete dates at this stage but it's very close :)
<anrah> Great, thanks :)
<Guest52313> juju connection timed out error
<sai_> I have configured juju with local and openstack. I followed the instructions here: Bootstrapping JuJu on top of an OpenStack private cloud for configuring juju on a private openstack deployment.  Juju spawns a new VM in openstack and it is visible in the horizon dashboard but the problem occurs when juju tries to ssh into the newly spawned VM for installing juju agent. This is what I get in the terminal:
<sai_> use-floating-ip specifies whether a floating IP address is     # required to give the nodes a public IP address. Some     # installations assign public IP addresses by default without     # requiring a floating IP address.     #     use-floating-ip: true      # use-default-secgroup specifies whether new machine instances     # should have the "default" Openstack security group assigned.     #     use-default-secgroup: true      # network 
<anrah> sai_: can you use some paste-service to paste that output?
<anrah> ist there an error somewhere on the output and how you are running the bootstrap command?
<sai_> 2017-04-19 09:46:26 INFO juju.environs.instances image.go:91 find instance - using image with id: eca6b790-18e5-42c8-b239-1f33f0400187 2017-04-19 09:46:26 DEBUG juju.cloudconfig.instancecfg instancecfg.go:525 Setting numa ctl preference to false 2017-04-19 09:46:27 DEBUG juju.service discovery.go:65 discovered init system "systemd" from series "xenial" 2017-04-19 09:46:27 DEBUG juju.provider.openstack provider.go:1034 openstack user data;
<sai_> 2017-04-19 09:46:27 DEBUG juju.provider.openstack provider.go:1034 openstack user data; 1031 bytes 2017-04-19 09:46:27 DEBUG juju.provider.openstack provider.go:1049 allocating public IP address for openstack node 2017-04-19 09:46:37 DEBUG juju.provider.openstack provider.go:913 found unassigned public ip: 172.16.50.108 2017-04-19 09:46:37 INFO juju.provider.openstack provider.go:1054 allocated public IP 172.16.50.108 2017-04-19 09:46:44 
<sai_> 2017-04-19 09:47:15 DEBUG juju.provider.openstack provider.go:459 instance c19d0ff7-8f43-41f9-a268-9600df72168a has floating IP address: 172.16.50.108 2017-04-19 09:47:16 DEBUG juju.provider.common bootstrap.go:257 connection attempt for 172.16.50.108 failed: ssh: connect to host 172.16.50.108 port 22: Connection refused 2017-04-19 09:47:21 DEBUG juju.provider.common bootstrap.go:257 connection attempt for 172.16.50.108 failed: ssh: conne
<anrah> sai_: can you paste the whole output for example to: http://paste.ubuntu.com/
<sai_> http://paste.ubuntu.com/24458888/
<kjackal> Good morning Juju world!
<kklimonda> tych0: hey, have you ever looked into https://bugs.launchpad.net/juju/+bug/1632189 ? I've started hitting this today randomly, and I'm not sure how to debug it.
<mup> Bug #1632189: juju can not use upstart to run service in juju machine <ppc64el> <upstart> <juju:Triaged> <https://launchpad.net/bugs/1632189>
<anrah> does anyone have a example of a charm that communicates with Juju API?
<magicaltrout> i think the auto scaling charm thing does
<magicaltrout> https://jujucharms.com/charmscaler
<kklimonda> how do juju install lxc & co? It's not installing my version of lxcfs, even though it's candidate for installation
<kklimonda> bummer, something is calling --target-release trusty-backports
<kjackal> cory_fu: is there a way to have a decorator of my own in a reactive charm?
<cnf> m00
<lazyPower> magicaltrout: are you charming up gitlab i see?
<rick_h> magicaltrout: hah, you did the work I was poking at with your bundle. :)
<magicaltrout> lazyPower: its been available for 12 months, but nicely hidden by the charmstore search
<lazyPower> magicaltrout: i for one, apologize for our non-linear graph search.
<rick_h> lazyPower: yes, we've been talking about it last night and want to see about an upgrade path from the current promulgated one at some point
<lazyPower> magicaltrout: only teh git repo or were you including CI and Registry as part of that?
<magicaltrout> lazyPower: i'm lazy it ships what they put in the omnibus repo
<lazyPower> magicaltrout: so everything, but not integrated yet. gotchya
<magicaltrout> i've used it for ages for internal git repo, i've not expanded yet
<magicaltrout> although I have a branch here with an external db hook that i want to get into the charm soonish
<lazyPower> magicaltrout: lmk if you want help w/ the ci subsystem. the registry is still hairy to setup
<lazyPower> it involves a lot of self-signed key or proper authority-based-tls-key schenanigans that i'm not ready to support for everyone yet.
<magicaltrout> they use the gitlab registry on one of the darpa projects, I never even knew that was a thing
<magicaltrout> I need to delve properly
<lazyPower> yeah man
<lazyPower> its actually quite good
<lazyPower> i'm using the sameersbn images a-la dorker (pun intended) and its been a rock solid performer for me
<lazyPower> much easier than using a registry without an auth doman and no gui
<lazyPower> s/doman/domain/
<magicaltrout> yeah on our genomics project we use the docker v2 reg
<magicaltrout> its fine as long as you like using curl to prod it ;)
<lazyPower> on a scale of one to trolled, how trolled does it make you feel? :)
<lazyPower> magicaltrout: oh and the final integration is actually mattermost
<lazyPower> so you get a full startup pack if you're using the omnibus.
<magicaltrout> yeah
<magicaltrout> so what do we want lazyPower, gitlab sorting out some certificates and then having k8s trust them?
<magicaltrout> you chaps must already have some code kicking around for k8s cert generation?
<magicaltrout> the back button in the charm store is an interesting sight to behold these days
<hatch> magicaltrout is it not working for you?
<magicaltrout> well it sorta works hatch
<magicaltrout> but it also sorta doesn't
<hatch> it definitely should work :) can you explain what you're seeing?
<magicaltrout> erm
<magicaltrout> i'll see if a screenshot can explain
<hatch> sure thanks!
<rick_h> magicaltrout: I'm not able to login. Your readme references "password of your choice"
<rick_h> magicaltrout: but it's not the old default from the first charm and I'm not seeing a config/etc?
<magicaltrout> rick_h: you should define a random password and it just ask you to set it
<magicaltrout> was my understanding
<rick_h> magicaltrout: when you say "define" what do you mean?
<magicaltrout> just stab some random characters
<rick_h> magicaltrout: oh damn, I'm blind. I thought it was a login form but it's a change password form
<rick_h> I see the link for "login" now. My bad.
<magicaltrout> yeah its sneaky isn't it!
<magicaltrout> I did the same yesterday
<rick_h> magicaltrout: this is what I get for using the older one yesterday
<rick_h> magicaltrout: ty :)
<magicaltrout> hey hatch https://ibin.co/3KPFGS2PHiAo.png
<magicaltrout> you see the untitled-model back links?
<magicaltrout> but I've not been in a model
<magicaltrout> and going back from this page takes me no where it doesn't even change
<hatch> ahh, hmm
<hatch> have you been sitting on this page a while?
<magicaltrout> probably
<hatch> ok np, just trying to think about what is causing those entries
<magicaltrout> like i said some times its absolutely fine
<hatch> thanks, I'll create an issue so we can try and track this down
<magicaltrout> sometimes i land like that and you have to go somewhere else to get moving again
<lazyPower> magicaltrout: we sure do, its teh easyrsa charm :)
<lazyPower> magicaltrout: you could in theory support that relation, and reuse the ca + trust chain there.
<magicaltrout> sounds like that might be a sane way to do it lazyPower
<lazyPower> magicaltrout: so long as gitlab and k8s are deployed in the same model or you use xmodel relations to define that relationship, it should be as simple as placing the certs in teh correct configs and "magic"
<lazyPower> magicaltrout: whats nice is that so long as any replacement (say vault) reuse that relationship we can make that CA a pluggable component.
<lazyPower> i keep saying this but haven't had time to really dig into using another Cert Authority, let alone charm it up.
<lazyPower> magicaltrout: also whats your expected integration with with k8s? run the ci-worker in k8s? there's a multi-manager bin that allows your ci jobs to scale and create their own ephemeral pods...
<lazyPower> magicaltrout: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/executors/kubernetes.md
<magicaltrout> yeah that would be very useful lazyPower I do similar with Jenkins on DC/OS
<lazyPower> i agree
<magicaltrout> as a cash strapped startup, having CI servers sucking up resource and doing nothing makes me sad ;)
<lazyPower> there's an obvious intersection here, i'm just not certain how this integration should actually work. I feel like its going to require another interface to get all the data but i dont want interface proliferation either.
<lazyPower> what we *might* do... is add the kube-admin relationship to fetch credentials and create a workload manifest in the gitlab charm and have an action deploy it.
<lazyPower> that seems clean and keeps the onus of having the ci-multi-runner update from the gitlab charm side.
<lazyPower> i'll noodle on this s'more and get back to you magicaltrout. Feel free to poke between now/then about this though.
<magicaltrout> will do
<bdx> http://paste.ubuntu.com/24460316/
<bdx> is ^ a bug?
<petevg> cory_uf: small PR for you: https://github.com/juju/python-libjuju/pull/113
<lazyPower> bdx: i dont think instance type is a post-deploy constraint juju understands
<lazyPower> and afaik instance-type was actually a deprecated constraint, but i may be wrong there...
<bdx> lazyPower: post deploy ?
<lazyPower> right so there's sets of constraints
<lazyPower> wait i'm about ot talk about both sides of my mouth, i see what you did here
<lazyPower> add-machine and deploy
<lazyPower> but i think that still holds true... yeah, i beleive add machine and deploy are 2 different sets of constraints. One understands that instance type the other doesn't.
<bdx> oh really
<lazyPower> yeah, and if i'm wrong, i'll go ahead and put my pants on my head
<lazyPower> because i'm only 80% certain thats the case
<lazyPower> thats a pretty large margin for error
 * magicaltrout waits expectantly
<bdx> a `juju deploy`ed application automatically consumes any available machine instead of getting affinity to its own resources?
<bdx> ok
<bdx> good to know
<bdx> thx
<bdx> I thought that was only a thing when using `--to`
<lazyPower> actually bdx...
<lazyPower> let me flip this on its head
<bdx> :)
<lazyPower> you provisioned a super large machine
<lazyPower> it has no workload on it, and juju knows about it
<lazyPower> then you requested a deployment to a much smaller machine, juju said "Yo dog, i see you like to deploy things, and i have this large machiine that totally fits that t2.micro in it"
<lazyPower> so mebbe it just said "Welp, nothing to do here" and crammed it on that machine because it effectively did what you asked. Now if you provisioned a t2.micro first, and attempted to put a m4.xlarge on it, i can see that being where its def a bug
<lazyPower> but technically, juju used the resources that were available to it, before requesting more.
<bdx> I see
<lazyPower> bdx: try flipping that around and see if the behavior changes
<lazyPower> anecdotal validation, but i'm pretty sure it'll behave how you would expect then
<magicaltrout> i'd tend to agree with bdx though, if i'd asked for a t2.micro deployment and a large machine was available
<magicaltrout> i'd not want my workload on it
<magicaltrout> not that i have that use case
<bdx> in my case, I want one host to deploy my containers on, and one haproxy box to proxy to it
<bdx> the fact that juju makes assumptions about what I want to do with my workload makes my stomach churn
<magicaltrout> thats just last nights beer
<bdx> for u
<bdx> I don't drink beer bro - get it right
<bdx> jeeeeze
<magicaltrout> lol
<bdx> :-)
<bdx> lazyPower: I think I see what you are saying .... the constraints for 'add-machine' and 'deploy' commands aren't the same constraints, so the 'instance-type' isn't evaluated as to whether its the same or not
<lazyPower> bdx: i think its closer related to my last assumption...
<lazyPower> that had you inverted those constraints, it would behaving as you expect.
<bdx> lazyPower: ahhh ... so what we are dancing around is that juju doesn't take into consideration the actual instance type
<bdx> just the resources associated with the instance type
<bdx> so like a t2.xlarge and a m4.xlarge would be equivelent in the eyes of juju because the both have the same cpu, mem
<bdx> magicaltrout: for future reference - whiskey with a single ice cube, or a malbec with room to breathe :)
<rick_h> reminder juju show in 3hrs
<rick_h> magicaltrout: will show off your bundle and such if you're interested in joining
<magicaltrout> i will swing by rick_h
<zeestrat> rick_h: question for the juju show (or here). What will be the upgrade strategy for 2.1 -> 2.2? Supported for controllers with models running and all?
<rick_h> zeestrat: completely
<rick_h> zeestrat: model migrations is the safest production ready method to upgrade
<rick_h> zeestrat: https://jujucharms.com/docs/2.1/models-migrate
<petevg> cory_fu: got another PR for you (matrix-side JaaS support): https://github.com/juju-solutions/matrix/pull/127
<petevg> (it depends on that other PR, so it's a WIP for now.)
<cory_fu> petevg: https://github.com/juju/python-libjuju/pull/113 can't be right.  The redirect info code was put in there specifically *for* jaas.  Also, the current libjuju master works fine for me on jaas.
<cory_fu> tvansteenburgh: Can you confirm that first bit?   ^
<petevg> cory_fu: can you run the add_model example against JaaS. It fails for me ...
<cory_fu> petevg: Hrm.  Yeah, it does fail for me.  Let me re-test with conjure-up, which is where I saw it working, and confirm that it's using latest master for libjuju
<tvansteenburgh> cory_fu: in a meeting, can't look right now
<cory_fu> petevg: Hrm.  In conjure-up, I'm getting the server-version KeyError
<petevg> cory_fu: hmmm ... if you do "juju list-controllers", what version do you get for your jaas controller?
<cory_fu> petevg: 2.1.2
<petevg> cory_fu: that's the same as mine. That's weird.
<cory_fu> petevg: Of course when I add a logging statement to see what the info dict contains, it has the server-version key
<petevg> Heh.
<zeestrat> rick_h: Cool. Great to hear. So what do you do when model migrations doesn't work? #1680392
<mup> Bug #1680392: Model migration fails on large model <juju:Fix Committed by thumper> <https://launchpad.net/bugs/1680392>
<rick_h> zeestrat: so you can do in place upgrades like some folks still do from pre-migrations
<rick_h> zeestrat: however, it's riskier
<rick_h> migrations are meant to be put together such that they fail in a clean way, reversible, etc.
<cory_fu> petevg: Another thing to note: conjure-up is using the CLI to do the add-model and is then establishing a model connection without ever establishing a controller connection.  It's the controller connection that is failing in examples/add_model.py with the redirect issue
<cory_fu> petevg: I'm also having the problem with not being able to remove the models from jaas
<zeestrat> Yeah. We'd love to do migrations, but that doesn't seem to work with a model for for example Openstack in 2.1.2
<petevg> cory_fu: if you're not establishing a controller connection, I understand why you wouldn't be seeing the error :-)
<petevg> cory_fu: as for removing models ... if I add and remove the model with the websocket api (e.g., matrix does it by itself), everything works.
<petevg> If I try to add a model via the cli, I can't remove it via the cli.
<petevg> And I can't use the cli to remove models added by the websocket api (this happens when matrix fails without figuring out that it has added a model).
<petevg> cory_fu: I am running into an annoying problem: I occasionally get timeouts in matrix's add_model call, despite making the timeout a lot more generous. When I check the model got added, but we apparently never heard about it.
<petevg> Also, I can't clean it up :-(
<cory_fu> petevg: Only on JAAS?  Also, have you replicated it with debug logging turned on to see if the message ever came in on the websocket and we missed it somehow?
<petevg> cory_fu: yes. Only on JaaS.
<petevg> cory_fu: I've got matrix debugging turned on, but I haven't gone in and hacked in debug logging for the controller. Can I do that in JaaS?
<petevg> Oh. You just mean turn on debugging in python-libjuju. I can do that.
<cory_fu> petevg: It's a bit late for him, but maybe urulama can help us out with these JAAS issues?
<cory_fu> urulama: If you're still around
<petevg> cory_fu: yeah. Squawking for help makes senes.
<petevg> *sense
<petevg> cory_fu: it looks like redirect_info is never meant to work for controllers, per the docstring in the source:
<urulama> cory_fu: otp for a while :-/
<petevg> RedirectInfo returns redirected host information for the model. In Juju it always returns an error because the Juju controller does not multiplex controllers.
<cory_fu> petevg: The JAAS controller is slightly different from a normal Juju controller, specifically in that it *does* multiplex controllers.
<petevg> Hmmm ... don't know why we get the not implemented error, then. I have a feeling that it might have something to do with the timeouts (e.g., I end up talking to a controller that doesn't want to talk to me any more.)
<cory_fu> petevg: It may be that the reason examples/add_model.py is failing is because we need to give the controller connection the info that it needs to redirect us to the proper actual controller
<mhilton> petevg, cory_fu: can I help with something?
<cory_fu> mhilton: I hope so!  :)
<petevg> mhilton: hopefully you can :-) We're trying to debug two issues when talking to a JaaS controller via the websocket api.
<zeestrat> rick_h: I guess there is no 2.1.3 planned that could fix model migrations for us on 2.1.2 without the big jump to 2.2?
<mhilton> cory_fu, petevg: if you're seeing a not implemented error from JAAS there's a good chance the JAAS controller just doesn't implement the call yet.
<rick_h> zeestrat: not sure. I'd not be surprised and maybe it can be fixed on the 2.2 end. Migrations is interesting as sometimes the new model can handle issues.
<petevg> mhilton: The call is theoretically a JaaS specific one, though: Admin.RedirectInfo
<cory_fu> mhilton: My understanding, though, is that the redirect logic is exactly for JAAS and it would be the only thing that *does* implement it
<cory_fu> mhilton: This is the example we're using that is giving us the issue with the RedirectInfo: https://github.com/juju/python-libjuju/blob/master/examples/add_model.py
<petevg> mhilton: the json request is {"type": "Admin", "request": "RedirectInfo", "version": 3}
<cory_fu> mhilton: I feel like this worked in the past, when JAAS was at version 2.0.2, but I am not 100% sure
<petevg> I can confirm that it worked in 2.0.2. mhilton: are we possibly just using the wrong version? (The facade isn't in the list of facades that schemagen puts together, so the version is just hard coded currently.)
<mhilton> petevg, cory_fu: OK RedirectInfo is only implemented on a Model connection (that changed recently, but before it was a bug)
<cory_fu> Ok, so it did change, but it was working by accident before
<petevg> mhilton: That makes sense. That means that my workaround is okay (though could be better -- I just swallow the error, rather than trying to skip asking for redirect_info on a Controller connection.)
<petevg> mhilton: the second issue is that I add a model, and timeout, possibly because we never get a websocket response. I probably need to get better debugging info on that one, though.
<mhilton> cory_fu, petevg: so to be clear if you are connecting to the model you should use a new connection that connects to the model's UUID.
<petevg> It's good to know that it probably doesn't have anything to do with the RedirectInfo facade.
<cory_fu> petevg: It's probably reasonable to just always try and swallow the error if the result is "not implemented" because a regular controller might do the same even for model connections
<petevg> mhilton: yes. We are getting a new connection for the model.
<cory_fu> mhilton: Yeah, we do create a new connection with the UUID
<mhilton> the login will fail with an error saying it's been redirected, and then you can log in to the redirected location, if you put that in the login part of the code it should make everything make more sense
<petevg> mhilton: ... the timouts aren't consistent, like I'd expect they would be if we were doing something obviously wrong.
<mhilton> cory_fu, petevg: what's the second part of the problem?
<petevg> mhilton: It's the timeouts. I ask the websocket api to create a model, and it does, but we're apparently not hearing about it.
<zeestrat> rick_h: yeah, the problem here seems to be due to an issue with the mongodb on the original controller we'd like to migrate from so I hope there will be some kind of fix or workaround.
<petevg> mhilton: I guess the call to create the model is to the controller, so maybe something is going wrong with the handoff, and we're swallowing the error somehow.
<mhilton> petevg, so you just get a closed connection with no error response or anything? is it on any particular cloud or region?
<petevg> mhilton: the timeout is actually coming from Python, several layers up; it's just as likely to be an uncaught error as it is to be a network timeout.
<petevg> mhilton: I've been testing on aws/us-east-1. Haven't gotten around to testing on other clouds.
<petevg> Ooh. This is before we actually start monitoring the websocket connection to make sure that it is alive. It could just be closing.
<mhilton> petevg: OK as far as I know that one is working fine.
<petevg> mhilton: I'll add some more debugging to this beast and ping back here if I have questions based on the results. Thank you for all the help thus far :-)
<cory_fu> petevg: Am I correct in thinking that the reason you're hitting a timeout is because the we never see the model show up in the controller connection's watcher?  Or is it because we're not seeing a response for the API request itself?
<mhilton> petevg: Oh the JAAS controller can be a little aggressive about shutting down connections if it doesn't get a Ping (or some other call) every minute or so.
<petevg> cory_fu: ambiguous. We're hitting a timeout because we call "await Controller.add_model" with an x second timeout, and that call doesn't come back to us in x seconds.
<petevg> mhilton: we're pinging it every 10 seconds, so that part should be okay :-)
<mhilton> petevg: OK that sounds fine then. feel free to ping back later.
<petevg> Will do. Thank you again.
<cory_fu> mhilton: One other issue that I'm seeing is that I'm occasionally, but not consistently, getting a login response that doesn't appear to contain a server-version key.  I haven't been able to reproduce it since increasing the logging to see what else is present in the response, but can you think of any way the login response could come back without an error but also without a server-version?
<mhilton> cory_fu: interesting. give me a couple of secs and I'll have a look
<cory_fu> petevg: So that could either be that model_facade.CreateModel isn't returning in a timely fashion (i.e., the websocket response doesn't come in), or because the subsequent ssh key logic is hanging, or because the attempt to connect to the model after the fact is hanging.   I guess you're working on increasing logging around that
<cory_fu> ha, I reproduced it
<mhilton> cory_fu: are these controller connections, or model connections?
<cory_fu> mhilton: They're model connections, but I was able to reproduce it and it's an issue with how we're handling discharge-required-error responses
<cory_fu> petevg: The build_facades call in login (https://github.com/juju/python-libjuju/blob/master/juju/client/connection.py#L467) needs to either account for or come after the discharge-required-error response check (https://github.com/juju/python-libjuju/blob/master/juju/client/connection.py#L343)
<cory_fu> petevg: I'll open an issue
<petevg> cory_fu: interesting. Accounting for it is the right thing, I think, because we need those facades for the pinger.
<tych0> kklimonda: i haven't looked at it
<cory_fu> petevg: Well, we could just move both the build_facades and create_task(pinger) to after this check: https://github.com/juju/python-libjuju/blob/master/juju/client/connection.py#L343
<cory_fu> Instead of doing it in login
<cory_fu> Though I guess we also need to do it on the no-redirect-info case above
<petevg> cory_fu: yep. I like the accounting better than the making sure it gets called in multiple places :-)
<petevg> ... though I guess then the pinger might try to set itself up even though we want to just discharge an error and move on.
<petevg> Hmmm ....
<cory_fu> petevg: Created https://github.com/juju/python-libjuju/issues/114
<cory_fu> petevg: It would.  And then we'd end up with multiple tasks
<cory_fu> petevg: I can resolve that today
<cory_fu> brb
<petevg> cory_fu: awesome. Thx.
<cory_fu> mhilton: Can you speak at all to the issue that we're seeing with JAAS where we get models added that can't be removed?
<mhilton> cory_fu, yes that one is a known JAAS bug, the model is removed, but JAAS doesn't find out.
<cory_fu> mhilton: Is there any way to get those models cleaned up?
<mhilton> cory_fu, there is a fix in the pipeline.
<cory_fu> Ok
<mhilton> cory_fu, there aren't any machines running on the models or anything that needs cleaning up if that's what you mean.
<cory_fu> mhilton: Right, I can see that.  So it's just an issue of clutter in juju list-models
<mhilton> cory_fu: although if you're just getting upset by a long list of dying models then it would be possible to manually clean them up if it's a big problem. There's a chance I can get the fix into produciton tomorrow though. which might end up being easier.
<cory_fu> mhilton: It's not a big deal, I can wait on the fix
<rick_h> 30min juju show warning wheeeeee
<rick_h> juju show links: https://hangouts.google.com/hangouts/_/spafozizrrgsvkyfq733kzxsmme to join the hangout
<rick_h> https://www.youtube.com/watch?v=h2X9gIxXPH8 to watch it stream
<rick_h> hatch: jrwren lazyPower cory_fu petevg magicaltrout and anyone else interested ^
<rick_h> magicaltrout: are you still able to join?
<lazyPower> oo snap, i missed the intro. /me pulls up the watch url
<lazyPower> if you want me there i'll hop in
 * lazyPower applauds and fanfares rick_h
<lazyPower> great show this week rick_h
<lazyPower> sorry i missed the CTA
<rick_h> lazyPower: <3
<magicaltrout> sorry rick_h got home to find the kids still awake and causing chaos
<magicaltrout> how dare they not be in bed!
<rick_h> magicaltrout: hah, of course :)
<rick_h> magicaltrout: all good, just didn't want to start without you if you wanted to join
<rick_h> magicaltrout: <3 and ty for the updates!
<magicaltrout> no probs
<magicaltrout> keep prodding me and i'll make sure the new stuff gets done at some point in the not too distant future ;)
<magicaltrout> OOTB docker repo for CDK sounds pretty cool
<rick_h> magicaltrout: mmmm, yummy
<lazyPower> magicaltrout: there's been some work by a former contributor for a stand-alone registry
<lazyPower> plus we have a registry action in the k8s charms...
<lazyPower> but i'm all for the gitlab registry. its by far the most robust free solution you can get today on the free market.
<rick_h> yea, gitlab is very cool. I'd heard about it but didn't realize it did as much as it does.
<rick_h> I'd love to see this build system in place doing CI/CD
<tychicus1> I've been using gitlab since version 6.x, been very happy with the features they have added.  getting ready to consolidate the responsibilities of redmine and jenkins into our gitlab server
<rick_h> tychicus1: very cool
<bdx> rick_h: the mailman project is a great example https://gitlab.com/mailman/mailman/pipelines
<bdx> for CI
<tychicus1> I'll be doing this, as soon as I get persistent storage up and running on k8s http://blog.lwolf.org/post/fully-automated-gitlab-installation-on-kubernetes-including-runner-and-registry/
<cory_fu> petevg, stokachu: https://github.com/juju/python-libjuju/pull/116
<petevg> cory_fu: +1 after the tests pass.
<cory_fu> petevg: I'm running into a strangely consistent issue running the integration tests locally.  The tests/integration/test_unit.py::test_run_action deployment of the git charm on trusty always ends up with my juju machine stuck in pending, and when I manually check the cloud-init-output.log on the lxd instance, I just see "Job failed to start" from the jujud-machine-0 service
<cory_fu> petevg: The weird thing is that all of the other tests are fine, and it's always that one test
<cory_fu> petevg: Have you seen anything like that?
<petevg> cory_fu: I haven't. Huh.
<cory_fu> I can't see it being related to libjuju in any way, and I suspect it has something to do with my lxd / zfs setup, but I can't even get any more debugging info because no logs are created for that service
<cory_fu> And the first thing the service does is touch the log file, and it doesn't even do that
<petevg> cory_fu: weird. I think that the only difference for me is that I'm not running zfs.
<magicaltrout> everyone should run zfs
<magicaltrout> its the lay
<magicaltrout> law
<cory_fu> petevg: Hrm.  The travis build for that PR is now up to almost 35 minutes, where all the previous runs took about 20.  Maybe the failures I'm seeing are due to my changes somehow after all.  I really can't see how libjuju would cause such a weird provisioning error, though
<petevg> Huh.
<cory_fu> petevg: Of course, it could be an issue with the latest beta.  Aren't we still using that in our tests?
<petevg> We are.
<petevg> cory_fu: I'm on beta2 locally. Has there been a new one released?
<petevg> Nope. That looks like the latest.
<cory_fu> petevg: 2.2-beta3.1
<petevg> Weird. Don't know why apt doesn't see the new one.
<cory_fu> petevg: Travis passed on that PR.  It just took a while for some reason
<petevg> cory_fu: I'm still good with merging, then.
<petevg> The time on a lot of these is kind of hard to pin down.
<cory_fu> petevg: I'm going to close out https://github.com/juju/python-libjuju/pull/113 as well
<petevg> cory_fu: I beat you to it :-p
<cory_fu> petevg: :)
<cory_fu> petevg: Also, shouldn't 90, 98, and 99 be closed?
<cory_fu> https://github.com/juju/python-libjuju/issues/90
<cory_fu> https://github.com/juju/python-libjuju/issues/98
<cory_fu> https://github.com/juju/python-libjuju/issues/99
<petevg> cory_fu: yep. Closing them now.
<cory_fu> Thanks
<petevg> np
<petevg> cory_fu: I'm going to call it a night. Tomorrow, I'll rebuild matrix's wheelhouse, and switch that WIP to being a real PR.
<cory_fu> petevg: Cool, have a good night
<petevg> You, too :-)
#juju 2017-04-27
<kjackal> Good morning Juju world!
<afellow> Hello everyone!
<afellow> I have question about juju and maas  2
<afellow> is Juju already compatible with maas 2?
<afellow> I am asking because I have problem bootstrapping maas2 cloud
<afellow> I get the following error during the process
<afellow> ERROR cmd supercommand.go:458 new environ: Get http://localhost:5240/MAAS/api/1.0/version/: dial tcp 127.0.0.1:5240: getsockopt: connection refused
<afellow> It want to use 1.0 API version instead of 2.0
<afellow> I need to add that I use juju 1.2.1 and maas 2.1.3
<afellow> Did anyone had similar problem and solved it?
<magicaltrout> morning folks
<magicaltrout> trying to bootstrap some test nonsense
<magicaltrout> juju-wait fails when I try and run the sample bundletester -t cs:bundle/wiki-simple
<magicaltrout> on the matrix readme
<magicaltrout>   File "/usr/local/lib/python2.7/dist-packages/juju_wait/__init__.py", line 102, in juju_exe
<magicaltrout>     if not shutil.which(juju):
<magicaltrout> AttributeError: 'module' object has no attribute 'which'
<magicaltrout> anyone got any sane ideas?
<SimonKLB> magicaltrout: old python version=
<SimonKLB> https://docs.python.org/3/library/shutil.html#shutil.which
<SimonKLB> "New in version 3.3."
<magicaltrout> yeah SimonKLB
<magicaltrout> but as I have python 3 installed
<magicaltrout> how do I tell juju-wait to use it ?:)
<magicaltrout> or more to the point, whats the ubuntu way of making python3 the default, 2.7 still seems to be /usr/bin/python
<magicaltrout> which is whats in the shebang
<SimonKLB> hmm, looks like the latest version has python3 https://git.launchpad.net/juju-wait/tree/juju_wait/__init__.py
<SimonKLB> perhaps the wait plugin needs an update
<magicaltrout> oh yeah so it does
<SimonKLB> magicaltrout: since it's installed under python2.7 the shebang might not be considered when it's executed
<SimonKLB> not sure how the plugins are being run, but if they are not executed standalone then that might be the problem
<magicaltrout> thanks SimonKLB I fixed that by just changing the shebang in the plugin
<magicaltrout> bundletester is completely hosed on my xenial install though
<magicaltrout> bugg@tom-laptop2:~/Projects/charms/layer-gitlab/tests$ juju api-endpoints -e aws1:admin/default
<magicaltrout> ERROR unrecognized command: juju api-endpoints
<magicaltrout> no idea what its trying to do there but it doesn't like it
<magicaltrout> some juju2.0 thing I guess
<SimonKLB> magicaltrout: you dont run 2.0?
<magicaltrout> i do run 2.0
<magicaltrout> thats why i'm confused
<magicaltrout> i just pip2 installed bundletester
<magicaltrout> like all the docs say
<SimonKLB> have you tried the charmbox docker container?
<magicaltrout> but it doesn't like my juju install, which was apt and now snapd to check
<SimonKLB> it comes pre-packaged with all the test-stuff
<magicaltrout> I've not
<magicaltrout> i'll give it a spin
<SimonKLB> yea do it! i'm using it all the time when building/testing charms, it's very handy
<magicaltrout> much improved it seems SimonKLB
<magicaltrout> thanks for the hint
<SimonKLB> great np :)
<magicaltrout> https://jujucharms.com/q/gitlab so here's another gripe about the charmstore
<magicaltrout> I get (kinda) why you'd not want to return gitlab recommended and gitlab non recommended
<magicaltrout> but if you have gitlab and gitlab-server
<magicaltrout> surely you need to do a wildcard search there by default? people are full on searching blind
<magicaltrout> watch last nights video rick_h. Good show, thanks for the demo! :)
<rick_h> magicaltrout: awesome
<magicaltrout> alright
<magicaltrout> next testing error cause clearly i'm doing something fully moronic
<magicaltrout> why is bundletester trying to test my tests.yaml?
<petevg> cory_fu: I think that I've figured out where those timeouts were coming from when running matrix against JaaS. I replaced the asyncio.wait_for calls with simple awaits, and got a traceback: http://paste.ubuntu.com/24466731/
<petevg> cory_fu: it looks like this is happening when we first try to open the socket connection, before we can get at redirect_info, if there's any present.
<petevg> cory_fu: I think that a retry might be the most sensible thing to do -- what do you think?
<cory_fu> Interesting.  So you think the wait_for for the timeout was somehow masking the connection error?
<petevg> cory_fu: yes. I think that we were creating a future, but not checking the exception status on it.
<petevg> cory_fu: regardless, I think that we've made python-libjuju much more enthusiastic about raising errors, so I think the reasons for wrapping add_model in a wait_for may have gone away.
<cory_fu> petevg: We don't have access to any future that wait_for creates.  There doesn't seem to be any way to check for an exception with wait_for
<petevg> cory_fu: ugh. All the more reason not to use it, I think ...
<cory_fu> petevg: The wait_for was there to prevent the connection from hanging indefinitely
<cory_fu> It seems to be the only way to enforce a timeout
<cory_fu> I guess we could roll our own wait_for using create_task and asyncio.sleep
<petevg> cory_fu: I think that we may not need it at all -- we've got higher level timeouts wrapped around matrix in the CI tools, and it looks like the native timeouts work pretty well.
<lazyPower> magicaltrout: bugs on charmbox welcome <3 thats my ugly baby :)
<cory_fu> petevg: Hrm.  I was thinking for other code that uses libjuju
<magicaltrout> charmbox is fine lazyPower many thanks
<petevg> cory_fu: this code was in matrix, anyway :-)
<magicaltrout> comapred to trying to run tests on my own machine
<cory_fu> petevg: Oh, well fine then
<cory_fu> :)
<petevg> cory_fu: python-libjujuj provides that monitor class to get around the cases where you aren't going to hear abotu a timeout.
<lazyPower> magicaltrout: indeed, and it insulates you from dependency bloat running tests, thats why we created it.
<lazyPower> doing revq on your laptop shouldn't leave you with 800+ dependencies installed.
<magicaltrout> hehe
<magicaltrout> so there seems to be a missing document
<magicaltrout> cause i couldn't find this a few months ago and gave up then
<magicaltrout> how do you get stuff into the review queue these days?
<magicaltrout> actually via the app itself or some other method?
<magicaltrout> oh yeah, request a review, conundrum solved
<magicaltrout> Start your review by saying "Thanks", no matter what the outcome of the review is going to be.
<magicaltrout> If you recognise somebody you've worked with on IRC, thank them.
<magicaltrout> lol
<magicaltrout> I understand why thats written down, but it does make me chuckle
<admcleod> magicaltrout: you should totally google 'conundrum etymology'
 * magicaltrout did and is thoroughly confused
<magicaltrout> time for biscuits
<rick_h> magicaltrout: :)
<admcleod> magicaltrout: mostly it as because of the pendantic thing that i was amused
<magicaltrout> need to test config setting in amulet
<magicaltrout> can I look at a file on the unit to check settings?
<magicaltrout> ah sentry file_contents it seems
<kjackal> petevg: is there a bundletester flag to disable matrix tests?
<petevg> kjackal: there isn't. You can not have matrix installed, though, and it will skip it.
<kjackal> petevg: I want them but in case I want to exclude them how do i do that?
<magicaltrout> --dontrunthecrazyshit
<kjackal> crazy petevg! Right magicaltrout?
<petevg> kjackal: best thing to do right now is to temporarily rename the matrix executable. You should file a ticket against bundletester, though, because it's not that hard to add a flag :-)
<kjackal> petevg: you said I can do a "pip unsinstall matrix" right?
<petevg> kjackal: it depends on what you did to install it in the first place.
<petevg> kjackal: I haven't pushed the pypi package, though, so it's unlikely that pip will work.
<petevg> kjackal: if you're in cwr-ci, matrix is just part of the image; probably renaming the executable is the way to go.
<petevg> Locally, I usually just have it installed in a venv, so it's easy to turn on and off :-)
<petevg> cory_fu, kwmonroe: simple but brutal solution for "matrix is too green", which was caused by us not cleaning up a health check after we hit an internal timeout. I'm just yanking the timeout, because we handle that at a higher level in cwr-ci, anyway: https://github.com/juju-solutions/matrix/pull/129
<kwmonroe> petevg: bundletester didn't use the -z, so i think what you've done is reasonable.  are there any other callers that i should check (for -z) off the top of your head?
<petevg> kwmonroe: I don't think that anybody was using "-z". It had a default timeout internally.
<petevg> kwmronoe: ... and that timeout was basically just there for cwr-ci ... which now has its own timeout wrapped around matrix, anyway, complete with model cleanup.
<petevg> kwmonroe, cory_fu: The other piece of the puzzle is that I got rid of a major source of hangs by adding that Monitor class to the python-libjuju connection. Matrix should basically never just sit there anymore. (At least, never sit there once it has managed to put its test suite together, which is the part that the timeout covered, anyway.)
<kwmonroe> awesome petevg!
#juju 2017-04-28
<bdx> I'm wondering how python3 can be used as the default python for trusty based *legacy* charms ...
<bdx> it seems it would have to be installed prior to the running of hooks.py
<bdx> so, if you can't use the 'install' hook to install python3 (because python3 needed for hooks.py to run)
<bdx> then how is it done?
<bdx> there must be a way
<bdx> I'm thinking execd preinstall?
<hloeung> install hook wrapper where the install hook is a shell script that installs python3
<hloeung> and then calls hooks.py's install hook
<wgrant> Right, install doesn't have to be a symlink.
<hloeung> bdx: ^
<wgrant> All the others usually are, but install can be a script which checks the environment and then calls hooks.py
<bdx> hloeung: thats great! thank you!
<bdx> hloeung, wgrant: this is probably why I see 'install.real' files laying around then I'm thinking
<bdx> ahh like this https://github.com/openstack/charm-glance/blob/master/hooks/install
<hloeung> bdx: yeah, just like that
<kjackal> Good morning Juju world!
<erik_lonroth3_> Hello! I'm writing  tutorial in how to create a new "layer" in juju. Is the proper start for that by using charm-create <name-of-layer> or how would you recommend that a beginner starts developing layers?
<erik_lonroth3_> The tutorial will build on the last one I wrote and are now updating also to accomodate for a series of tutorials.
<tvansteenburgh> erik_lonroth: yeah, `charm create` is correct
<erik_lonroth3_> OK. Thanx. Its not clear from the documentation that a layer is the same thing in essence as a charm.
<erik_lonroth3_> I also would need some help to understand when to place configuration options in the "layers.yaml" vs. config.yaml
<magicaltrout>  config.yaml is for user editable configuration options mostly erik_lonroth3_
<magicaltrout> like "i want to make this port configurable"
<erik_lonroth3_> So, the layer.yaml is for ?
<erik_lonroth3_> ... when do I place configuration in there?
<magicaltrout> dunno
<tvansteenburgh> it's mainly for configuring the layers below yours, if you need to
<magicaltrout> layer.yaml is for the stacking of other layers your charm depends on
<magicaltrout> mostly
<erik_lonroth3_> According to the documentation in the base-layer, it seems like those configuration options in the layer.yaml is intended for being over-ridden by layers above.
<erik_lonroth3_> So, if I create a charm on top of base-layer, I can use those options from within my own charm. Is that right?
<tvansteenburgh> you can set those options at build time, in your layer.yaml
<tvansteenburgh> they're not meant to be use at run time like config options from config.yaml
<erik_lonroth3_> Ah.
<erik_lonroth3_> So, its build-time configuration.
<tvansteenburgh> yep
<tvansteenburgh> erik_lonroth3_: concrete example from the 'apt' layer: https://git.launchpad.net/layer-apt/tree/README.md#n158
<tvansteenburgh> (line 158)
<tvansteenburgh> in the example yaml on line 169, options are being set for layer basic and layer apt
<erik_lonroth3_> tvansteenburgh: Thats a great example!
<erik_lonroth3_> Is it nessecary at all to write 'hooks' (start,stop,install,etc.) if you do charms the 'reactive' way instead ?
<jrwren> erik_lonroth3_: no, I think `charm build` creates them for you.
<erik_lonroth3_> jrwren: I dont follow exactly. What I don't get, is if I need to create files in the "hooks/" dirctory aswell as create the code in the "reactive/" directory.
<tvansteenburgh> erik_lonroth3_: you don't need to create anything in hooks/
<tvansteenburgh> `charm build` will do that for you
<erik_lonroth3_> Thats weird since the build-process complain if I don't create them...
<tvansteenburgh> erik_lonroth3_: pastebin a directory listing of your charm, and the error you're seeing
<tvansteenburgh> erik_lonroth3_: did you create an empty hooks/ dir?
<tvansteenburgh> erik_lonroth3_: if so, delete it and rebuild
<erik_lonroth3_> Hmm, I think your kind of right. https://pastebin.com/uaSvn9c1
<erik_lonroth3_> However, if I follow the 'recommendations' in the "Information" - I end up in a bad situation.
<tvansteenburgh> erik_lonroth3_: are you running `charm proof` before `charm build`?
<erik_lonroth3_> yeah
<tvansteenburgh> ok yeah, that won't work
<tvansteenburgh> right now you have a layer. you have to `charm build` to turn it into a valid charm
<tvansteenburgh> erik_lonroth3_: would you be willing to submit a PR to fix the docs that tripped you up?
<tvansteenburgh> because that would be great
<erik_lonroth3_> I can do that.
<erik_lonroth3_> Do I also have to do "charm-build" for layers?
<erik_lonroth3_> ... as well as for charms and interfaces ?
<tvansteenburgh> erik_lonroth3_: you only do `charm build` if you are making a charm
<tvansteenburgh> layers are the building blocks of charms
<tvansteenburgh> `charm build` combines them together to make a functional charm
<erik_lonroth3_> not if I'm making a layer?  This is confusing
<erik_lonroth3_> I understand what you are saying, but I fund the documentation quite difficult to follow and digest... Thanx for answering my questions...
<erik_lonroth3_> ... So, if I understand you right. Layers are not charms?
<tvansteenburgh> erik_lonroth3_: for example, the apt layer is a layer, but it is not built into a charm - it's meant to be used by other charms
<tvansteenburgh> erik_lonroth3_: layers are not charms
<erik_lonroth3_> I got that. But how about when I build and intend to distribute my "charm" that builds on a "layer". Wouldn't I have to distribute that "layer" also ?
<tvansteenburgh> layers are like the source code. when you build them (with `charm build`), you get a charm
<erik_lonroth3_> Ah, good description.
<tvansteenburgh> you don't have to distribute the layer. the built charm is what juju deploys.
<erik_lonroth3_> I'm going to "rip" that explanation in my tutorials
<tvansteenburgh> but, most people do make their layers available on github or something
<tvansteenburgh> and if your layer is meant to be reused, you can register it here http://interfaces.juju.solutions/
<erik_lonroth3_> Yeah, I guess its kind of key to have those layers accessible if you intend to build on them.
<erik_lonroth3_> But at what point do I then create a "charm" as opposed to "layer" if there is nothing that in the process of creating them is different?
<tvansteenburgh> erik_lonroth3_: the charm is the "compiled" output of one or more layers
<tvansteenburgh> you can `charm build` as often as you want
<erik_lonroth3_> So I decide for my self if a layer should become a charm or not ?
<tvansteenburgh> for every change you make to your layer source, you could charm build and push the built charm to the charm store
<tvansteenburgh> yes
<erik_lonroth3_> OK, that also explains more to me.
<tvansteenburgh> are you building something that you're unsure should be a charm or not?
<erik_lonroth3_> No not really. I'm creating tutorials to help my collegues to get started with this also. I've written a "hello-world" tutorial that produces a very simple charm. I started today working on doing a "layer" tutorial. That has come to a point where I realize that the reactive framework is a "must" and that I need to re-write the tutorial now =D
<erik_lonroth3_> https://github.com/erik78se/hello-world/wiki
<bildz> good morning
<bildz> is anyone monitoring their juju openstack with elk
<bildz> ?
<admcleod> bildz: not yet, thinking about it - why do you ask?
<salmankhan> erik_lonroth3_: (y)
<kwmonroe> hey marcoceppi - bdx needs a charm-kibana in https://github.com/charms.  will you make that happen (with elastic-ops as an admin)?
<bdx> kwmonroe: thx
<bdx> marcoceppi: thx
<kwmonroe> bdx: just to make sure, you want to commit an old-style charm there, right?  the convention is layer-foo for layered source and charm-foo for the older style (like the elasticsearch charm)
<bdx> ooh
<bdx> I did not know
<bdx> that makes sense
<kwmonroe> yeah so bdx, do you want charm-kibana or layer-kibana?
<bdx> both
<kwmonroe> ha!  for why?
<bdx> https://github.com/jamesbeedy/juju-charm-kibana
<kwmonroe> ok - that's a good looking candidate for layer-kibana.  what would you be committing to charm-kibana (remember we don't need to commit the built charm artifact anymore)
<bdx> yeah ... I need to fix all my repo names now
<bdx> lol
<bdx> yeah, so in that case only a layer-kibana I guess
<kwmonroe> meh - whatever works for you is cool.  just noting the convention for ./charms and ./juju-solutions github orgs.
<bdx> totally
<kwmonroe> ok - so marcoceppi, s/charm-kibana/layer-kibana in the charms org please.
<erik_lonroth> I'm trying to remove a charm stuck in en error state... I'm trying 'juju remove-application hello-world-reactive' but it wont go away. I'm probably doing something wrong... Can you tell me how you guys debug and remove charms stuck in error state?
<hml> erik_lonroth: have you tried removing the unit?
<hml> erik_lonroth: sometimes itâs hard to catch the hooks in a good state to do something with the removal request
<erik_lonroth> not yet... would "the unit" also destroy my host vm ? I don't want to destroy the vm
<hml> iâm not sure what your host vm refers to
<hml> the controller? the juju machine the unit is installed on?
<erik_lonroth> Yeah, the "machine" = "host vm"
<erik_lonroth> I tried "juju remove-unit" now also... no luck
<hml> yes, remove-unit also destroys the juju machine that the unit is installed on.  a juju machine can be a lot of different things
<tvansteenburgh> erik_lonroth: use `juju debug-log` to debug
<erik_lonroth> Ah, ok
<tvansteenburgh> you want to find out what's broken before destroying it
<tvansteenburgh> then you can fix your charm, rebuild it locally, and then use the `juju upgrade-charm` command to upload your new (fixed) charm over the top of the broken one
<tvansteenburgh> see `juju debug-log -h` for helpful options, especially --replay and -i <unit>
<erik_lonroth> thanx!!!
<hml> there is also a juju debug-hooks command if the error is in a hook
<tvansteenburgh> also, with `juju upgrade-charm` you'll want to use the --path arg to upgrade to the freshly built charm on your local filesytem
<erik_lonroth> I did: "erik@snowflake:~/git/juju/charms$ juju upgrade-charm hello-world-reactive --path ~/charms/trusty/hello-world-reactive" but its still there.
<erik_lonroth> the debug-log contains some hint perhaps: "juju.worker.uniter awaiting error resolution for "install" hook"
<erik_lonroth> Now it seems its just adding to the model... Added charm "local:xenial/hello-world-reactive-4" to the model.
<erik_lonroth> "juju resolved --no-retry hello-world-reactive/0" seemed to remove it.
<marcoceppi> bdx: kwmonroe done
<kwmonroe> thx marcoceppi
<bildz> admcleod: setting it up now
#juju 2017-04-29
<erik_lonroth> tvansteenburgh: Thanx for your help yesterday. After som time, I managed to get through on this and managed to get a "hello-world-reactive" charm to work, which doesn't do much, but helps me get going on charm development.
<erik_lonroth> I however struggle with finding a "best practice" for reactive programming. Understanding the "state" machine, what is executedunder what conditions etc. is quite hard to get a good feeling about the "workflow". How do you guys plan your larger charms and layers when you develop?
<bdx> kwmonroe, marcoceppi: one more thing ... could you add me to the layer-kibana repo also?
<bdx> thx
#juju 2018-04-23
<jam> thumper: wallyworld: so the reason the old code landed (without gomock in dependencies) is because it *didn't* have "pipefail", whatever patch that tried to introduce "pipefail" caused it to fail correctly, but doesn't seem committed to juju-qa-jenkins master branch.
<jam> however, whatever added "set -o pipefail" just had a typo of "set +o pipefail" to turn it off again.
<thumper> ah
<thumper> ok
<jam> but code has landed, and hopefully I updated and fixed the landing job.
<thumper> thanks
<veebers> jam, is this re: the juju merge job? I added pipefail handling today due to gofmt errors not failing the job.
<jam> veebers: k. you didn't commit it to upstream/master AFAICT. , and you had a typo in it.
<veebers> jam: 8sigh* I see, I broke it
<jam> veebers: well, it broke correctly, because we were missing a godeps as well
<jam> but I think I fixed both those issues
<veebers> jam, sorry about that. Hah, lucked out. Ugh, did I not push either :-\
<jam> veebers: I kept trying to grep for "set +o pipefile" and couldn't find it anywhere, but did find it on grumpig in /tmp/jenkins*.sh
<veebers> jam: ugh. Sorry I got distracted, the push command sits there with no return to make it so :-\
<thumper> veebers: so, with the 2.3.6 agents, I got IS to move the agent files
<thumper> so the simplestream data probably still points to it, but they aren't there
<jam> thumper: so its going to make my testing of how to get out of 2.3.6 a bit hard, but maybe I can make it fail
<veebers> jam, is the removal of "set +e" correct? that will mean that the job will exit if make check fails (and thus won't get a test report written)
<jam> veebers: I just replaced "set +e " with "set -o pipefail" and then "set +o pipefail". The bug was that you spelled the latter "pipefile" instead of "pipefail"
<thumper> jam: you could always just build a 2.3.6 locally
<thumper> and use --build-agent
<jam> thumper: with the caveat of whether build-agent will work with an agent that it thinks exists in streams, but yes, something liket hat
<thumper> it does...
<thumper> 99% sure
<veebers> jam: ack, we still need "set +e" otherwise the script will exit immediately, the pipefail is so any non-zero exit codes 'bubble' up the pipe chain (so if 'make check' fails it's not masked by 'tee')
<jam> veebers: interestingly enough, http://ci.jujucharms.com/job/github-merge-juju/382/console says that "set +o pipfile" doesn't actually cause the script to exit immediately
<jam> veebers: so it may be that we need to change the script from what I did. you're welcome to override my commit with yours and just fix the typo.
<jam> veebers: (you can see the error at the end of the console output, but it still marks the commit a success)
<veebers> jam, ack. I'll comfirm the use of +e and pipefail. Sorry again for the pain, if I had pushed (or ideally not hamfisted that) it would have been all good
<jam> veebers: mostly it was just confusing to see something and not be able to figure out where that was being set.
<jam> so the final "push" to github would have helped
<jam> veebers: makes me wonder if there should be more of a "publish it to jenkins via github" sort of thing.
<jam> veebers: I'm certainly just as guilty about do I commit and push first, or publish first, or did I forget to commit & push when I publish, etc.
<veebers> jam: yeah, I think having a landing job for the jenkins job builder config that deploys on merge/landing would be great
<veebers> aye, you want to make sure your changes actually work. Could be tiresome to push and wait see if a check job succeeds. Although you can do the test locally easily enough
<veebers> jam: seems "set +e" is the 'default'. I've added it back in so it's explicit and we won't get tripped up if the script surrounding it changes.
 * veebers has updated the job && pushed the changes.
<wgrant> How do I enable the audit log in 2.3?
<wgrant> I have an audit.log but it is empty.
<jam> wgrant: there seems to be "juju controller-config auditing-enabled" and "audit-log-capture-args" "audit-log-max-backups" "audit-log-exclude-methods=ReadOnlyMethods"
<jam> wgrant: but probably "auditing-enabled=true"
<jam> wallyworld: it looks ilke 'juju-force-upgrade' doesn't work because it has an assertion for "assert there is no current upgrade in progress"
<jam> upgradeInfo, current, "d-"
<jam> wallyworld: ok. I've worked out the upgrade and recovery steps and posted them to the bug.
<wallyworld> jam: great, looking
<wallyworld> jam: so we want to remove the prepared and applying txns? why prepared as well?
<jam> wallyworld: all the prepared ones are *going* to be broken, they are just not applying yet because they ahave to apply the applying txn first
<jam> wallyworld: everytime the upradesteps worker starts it creates a *new* txn that is going to do the same thing
<wallyworld> and e are sure there aren't any prepared ones we should be keeping?
<jam> it just doesn't notice until it goes to apply it that there are broken ones waiting.
<jam> wallyworld: so if it is stuck in prepared, it couldn't be applied
<wallyworld> ok
<jam> wallyworld: if we just did an upgrade, theoretically all real changes are either before the upgrade step broke everything, or after, things before the upgrade step should be fully applied
<jam> wallyworld: things after, couldn't have touched anything, because they never made it out of prepared.
<wallyworld> i was thinking other non related tasks may have tried to update settings, but seems unlikely
<jam> wallyworld: so yes, it is possible someone did "juju upgrade-juju" and then something like "juju config a=b" and we'll lose that latter one
<wallyworld> yeah. changes of that though seem slim
<jam> wallyworld: we could have them audit the actual list of changes that would be applied, by including more of the txn details in the find()
<jam> wallyworld: but I don't think anyone other than us really has the stomach for that
<jam> and it sucks even for us, because real model settings docs have like 30 items in them
<wallyworld> i was thinking we could make the find more selective, yeah. but i think what we have might be ok
<jam> wallyworld: https://github.com/juju/juju/pull/8642 is merging 2.3 into develop, along with https://github.com/juju/juju/pull/8642/commits/6df4788963993eca81afc5bb1b165248604d1542
<jam> which just changes the settingsMap.GetBSON to always escape when writing
<jam> wallyworld: for more restricting remove. we might be able to do something with o.c.???.container-image-stream ${exists: 1}
<jam> wallyworld: I'd have to think quite a bit to figure out the exact syntax that would match
<jam> *if* you stop the controller at *exactly* the right time it might also be possible to get a txn that is in Preparing (1) state. but it never gets blocked there, so is unlikely to exist
<stub> tinwood: Can I get added to the relevant team for https://github.com/juju/charm-helpers ?
<tinwood> stub, sure; I'll see if I can do it, or prod the person who can.
<tinwood> stub, it's jamespage, marcoceppi or dpb1 that can add you to the charm-helpers team.
<jamespage> stub: yeah I can do that
<jamespage> stub: what's your github handle?
<utking> Hey guys! We're having some troubles with openstack base
<stub> jamespage: stub42, which you can confirm from my older commits of Canonical team membership
<stub> c/of/or
<utking> it works perfect when deployed, but when we add nova-compute and ceph to the last node (4 nodes) neutron-gateway goes to blocked
<stub> (heh, #3 committer)
<utking> services not running that should be, neutron-dhcp-agent, neutron-metadata-agent, neutron-L3-agent
<utking> also another ntp is added to the fourth node that fails with hook-failed
<utking> unit-nova-compute-0: 10:21:55 DEBUG unit.nova-compute/0.update-status ERROR no relation id specified
<utking> any ideas?
<utking> can't gateway run on the same node as nova-compute?
<utking> openstack-base is bugged at least
<jamespage> utking: -> #openstack-charmers good place to get help on the openstack charms and bundles
<jamespage> stub: invited
<jamespage> utking: can you clarify what you mean by "when we add nova-compute and ceph to the last node"
<utking> Ah, yes!
<utking> We deploy openstack-base to 4 nodes
<utking> gateway on one, and 3 nova compute + ceph
<utking> then we use add-unit nova-compute
<utking> to the latest node
<utking> but then neutron gateway goes to blocked
<jamespage> utking: yes - the bundle is split intentionally that way - you can't place nova-compute and ceph on the neutron-gateway unit
<jamespage> the charms won't co-exist on the same machine (nova-compute and neutron-gateway specifically)
<utking> ah ok, how can we achieve this, if you won't mind me asking :)
<utking> guess we could try by doing it with add unit commands instead then
<TheAbsentOne> can an interface name contain a dash (-)? And are there any limitations like length to it, or is anything possible?
<utking> Is there any way we can configure the charms ourself so they can co-exist together?
<zeestrat> TheAbsentOne: Are you thinking about maas/juju or in general? Here's launchpad bug with some background info mostly on the length limitation: https://bugs.launchpad.net/juju/+bug/1672327
<mup> Bug #1672327: Too long names for bridges <cdo-qa-blocker> <maas-provider> <openstack> <uosci> <juju:Fix Released by wpk> <MAAS:Fix Released by mpontillo> <https://launchpad.net/bugs/1672327>
<TheAbsentOne> zeestrat: It's about the juju layer interfaces, as soon as I asked the question I realised mysql-shared has a hyphen and I felt stupid xD
<TheAbsentOne> thanks though!
<zeestrat> TheAbsentOne: Ah, my bad, I just assumed you were talking about network interfaces :) I imagine there's some cap on the length, but there are a few wordy ones already: https://github.com/juju/layer-index
<TheAbsentOne> yes exactly I took a look at the index too
<TheAbsentOne> now the question remains do I choose generic-db or generic-database as it seems there is no real convention about using abbreviations or not
<utking> Is there any way we can get this to work at all? it's for our bachelor thesis, and we really need to get a 4 node with compute openstack up and running
<utking> https://pastebin.com/XS0sm4uG
<utking> This is our script :)
<stub> TheAbsentOne: I'm pretty certain they are the same standard juju identifiers found everywhere, but I haven't looked at the code to see what the rules are. I do know _ and - are fine, and characters juju uses as delimeters are not (so no : or /). I personally assume no punctuation apart from _ and -, case insensitive, and sane lengths since humans need to read them.
<TheAbsentOne> Seems about right stub thanks for that insight! neutron-plugin-api-subordinate is also a layername so I guess I wont run into issues about the length either, perfect! ;)
<jamespage> utking: sorry  - in lots of channel - prefix my nick to get my attention
<jamespage> utking: tl;dr no not without quite alot of coding work in the charms
<jamespage> cory_fu: morning - quick q- I have a non-reactive charm interacting with my reactive implementation - I'm see string data items being double quoted '"str"' - is that intentional and how do I deal with that outside of reactive
<jamespage> tinwood: might you have an idea ^^
<tinwood> hmm
<tinwood> jamespage, that's new.  Is that endpoint related?
<jamespage> tinwood: I'm using a endpoint based interface on my provides end
<tinwood> jamespage, I'll have a quick check ...
<jamespage> tinwood: example data - http://paste.ubuntu.com/p/cJvht5dwjM/
<tinwood> jamespage, it's being jsonified in to_publish()
<tinwood> what does your endpoing look like
<jamespage> it does to_publish
<jamespage> oops
<tinwood> there's a to_publish_raw too
<jamespage> what should I be doing?
<tinwood> jamespage, https://github.com/juju-solutions/charms.reactive/blob/master/charms/reactive/endpoints.py#L412
<tinwood> it's for not using JSON -- i.e. for pre- endpoint charms.
<jamespage> tinwood: or I could do the right thing on the other end of the relation
<jamespage> even thought its a non-reactive charm right?
<tinwood> jamespage, oh yes; you'd just need to do a json.loads('"string stuff"') and it would strip off the string and check it.
<tinwood> That would work too.
<cory_fu> jamespage, tinwood: For reference, this is documented at https://charmsreactive.readthedocs.io/en/latest/charms.reactive.relations.html#charms.reactive.endpoints.RelatedUnit.received but it could definitely be better surfaced.
<tinwood> thanks cory_fu
<cory_fu> We should probably add a section on converting existing interfaces to Endpoint
<jamespage> cory_fu: ta - another quick question
<jamespage> cory_fu: we have an action that unlocks a new set of capabilities in a charm - can I get the action code to re-trigger the main hook state loop thing once its done?
<cory_fu> Oh, and the publish side of those docs is at https://charmsreactive.readthedocs.io/en/latest/charms.reactive.relations.html#charms.reactive.endpoints.Relation.to_publish
<cory_fu> jamespage: Yes.  Just call charms.reactive.main()
<jamespage> awesome ta
<cory_fu> jamespage: np
<cory_fu> jamespage: Are you aware of using charm-env as your shebang line for actions?
<jamespage> cory_fu: er no
<jamespage> cory_fu: docref?
<jamespage> cory_fu: I've been a bit way from the charm coalface for a few months...
<cory_fu> jamespage: There was an announcement a couple of weeks ago on the mailing list about changing the deault in layer:basic for use_venv to True, so unless you're explicitly setting that back to False, then your charm will use a venv that needs to be activated for your action.
<jamespage> oh ok
<jamespage> we're not
<jamespage> I wonder how its working?
<cory_fu> jamespage: To make that easy, there's a wrapper at /usr/local/sbin/charm-env that can be used in place of /usr/bin/env in your shebang
<cory_fu> jamespage: Unfortunately, I don't think charm-env is documented yet.  I will try to get that done today.
<jamespage> cory_fu: ta
<cory_fu> jamespage: It's also useful when debugging charms, so you can do, e.g, juju run --unit charm/0 -- charm-env charms.reactive get_flags
<TheAbsentOne> cory_fu: what is your timezone +/- I would love to have a private chat once my whole design is done to hear your thoughts. It will help me make choices as I'm a bit unsure what the best-practice approach is as of today
<cory_fu> jamespage: I'm not sure how it would be working either, unless you have another charm on that unit (subordinate, perhaps) that happens to be setting it to False or was built before the default change
<jamespage> well we use 'env' just not 'charm-env'
<cory_fu> TheAbsentOne: Absolutely.  I'm east coast US, UTC-4
<TheAbsentOne> cory_fu: noted, thanks in advance big sir! ^^
<cory_fu> TheAbsentOne: No problem.  Do be aware that I'll be travelling next week for a planning sprint, so will be in a different timezone (UTC+2) and not generally available except maybe in the evenings.
<TheAbsentOne> cory_fu: Ohn you are coming to Europe? I'm from Belgium :P Thanks for telling though!
<cory_fu> TheAbsentOne: Belgium is great.  I've been there once and loved it.  I'll be in Berlin this time, though.
<TheAbsentOne> Probably at config management camp to present juju a few years back. Love the talks ;) Have a great time in Berlin, man!
<TheAbsentOne> and btw cory_fu the beer in Belgium is better x)
<cory_fu> =D
#juju 2018-04-24
<thumper> wallyworld: was thinking about the default num_units, there is anothe edge case with subordinate charms, not sure the bundlechanges library knows about them...
<thumper> just another thing to think about
<thumper> wallyworld: also, we should push chatter from #juju-dev here
<jam> morning all
<jam> thumper: I set the topic and I left that node myself, not sure if you want me to idle with a "all pings must be made on #juju" message ? :)
<thumper> jam: would that work?
<veebers> Hi jam, thanks for getting the release rolling, just about to finish it off now :-)
<jam> veebers: thanks for working on it
<jam> thumper: I don't think you can set a reply that only works in one room
<jam> veebers: I have to say, the checklist is nice when it all works, but when there are any issues, it does take a lot of work to know how to recover.
<veebers> jam: ack, it seems we still have some ways to go to improve the process. I guess there is still a large amount of assumed context there.
 * veebers annouces juju 2.3.7, moves on to SRU process for xenial
<jam> veebers: nice.
 * veebers regrets eating almost a whole box of girlguide biscuits
<jam> veebers: just to add context. we messed up because a few of the builders failed to install go, so we didn't have binaries for all archs/platforms
<jam> but the next steps didn't check that everything was available, so they got half broken.
<jam> the "copy from the build_* location to the agent-archive location" copied 2 binaries, but the others had failed to build
<jam> but that meant you couldn't rerun the copy, because there *were* intermediates present.
<veebers> jam: d'oh I saw those comments. That needs to be improved. You're right to say that normally someone in "the know" grabs the commit sha to relase
<veebers> oh no :-\ that's a pain
<jam> veebers: if it wasn't for the fact that I've been tweaking the CI bot, i woudln't have known where to look, etc.
<jam> veebers: anyway, just trying to find the balance between "expand knowledge in the team" and "specialization makes it go much faster for people who understand"
<veebers> jam: wow, ok yeah there is def room for improvement there. Looks like we'll have another release debrief so we can squeeze out the issues
<veebers> indeed
<veebers> as much as I want to say "it's a much better process than before" that doesn't make it a good process :-) Always room for improvement
<wallyworld> thumper: we should push chatter here yes. let's just close juju-dev
<thumper> wallyworld: it is hard to close an IRC channel
<wallyworld> yeah, that is true i suspect
<wallyworld> on freenode at least
<thumper> wallyworld: https://github.com/juju/juju/pull/8649
<wallyworld> looking
<wallyworld> thumper: you proposing against 2.3 in case we do another release?
<thumper> wallyworld: yeah
<thumper> will also bring into 2.3
<thumper> ugh
<wallyworld> righto
<thumper> 2.4
<thumper> remember we were planning 2.3 as an LTS
<wallyworld> thumper: with the new facade method, i had a recollection that the python client library would be unhappy if its version of the api caller for a given version didn't match the methods on the juju apiserver facade
<wallyworld> so adding a new facade method to apiserver might make python lib fail some tests? not sure
<thumper> ugh...
<wallyworld> we may need to rev the version
<thumper> should check with cory
 * thumper nods
<wallyworld> yeah
<thumper> or I could just rev the facade
<thumper> leave that comment and I'll rev it
<wallyworld> that would be safest
<wallyworld> ok
<wallyworld> thumper: reviewed
<thumper> ta
<jam> manadart: ping for your thoughts about bug #1765342
<mup> Bug #1765342: 2.4 enable-ha complains about no address w/ unstarted machines <enable-ha> <juju:Triaged> <https://launchpad.net/bugs/1765342>
<jam> maybe we should treat a machine with *no* addresses at all as just ignored?
<manadart> jam: Will look in a mo'.
<manadart> jam: Commented there. I think it is OK to ignore no addresses in the particular guard.
<rmescandon> Question: is there a way of adding a resource to the model testing a charm with amulet?
<rmescandon> I can execute by hand a juju deploy with --resource, but then, i have any unit available using sentry
<rmescandon> i have no unit, i mean
<jam> manadart: any chance to look at https://github.com/juju/juju/pull/8653
<manadart> jam: Approved.
<jam> manadart: https://github.com/juju/juju/pull/8654 fixes the "juju enable-ha; juju enable-ha" complaining when the machines haven't started yet
<pmatulis_> jam, does the new HA stuff affect recovery when the majority of cluster members are broken? a user must restore from backups?
<jam> pmatulis_: if you've killed nodes, then you should be able to "juju enable-ha" to get back into a safe state. If you went into HA=3 and lost 2 nodes then you have the normal "it can't proceed without user intervention"
<jam> pmatulis_: but if 1 machine just dies, then doing "juju remove-machine DEAD; juju enable-ha" should get you back up and with 3 nodes again.
<pmatulis_> jam, ok, re your last point, does the order of those commands matter (i.e. does enable-ha ensure *working* members or just the total number of members?)?
<pmatulis_> jam, also, does a dead controller affect the 'HA' column of `list-controllers` (i.e. if one of three dies will it show 2/3?)? i'm wondering how a user can be alerted of a dead controller (degraded cluster)
<jam> pmatulis_: in 2.4 it ensures the *total* number of members. so the user must use "remove-machine" for enable-ha to treat it as really gone and not just sleeping.
<jam> pmatulis_: juju status -m controller ; will show one as "down"
<admcleod_> im wondering if theres anyone around who can help with the openstack provider, more specifically "juju metadata generate-image"
<admcleod_> not sure if its a bug or im not doing it right
<elox> Hello! How do I login to JAAS without a browser ? trying to do "juju deploy cs:~someuser/some-charm-1" and gets a request for a Couldn't find a suitable web browser! Set the BROWSER environment variable to your desired browser.
<rick_h_> elox: do you have the charm command?
<elox> sure sec
<elox> juju deploy cs:~erik-lonroth/mydbtest-1
<rick_h_> elox: so you can login to jaas with "juju login jaas" and you can log into the charmstore with charm login
<rick_h_> elox: I think juju login has a full CLI input, and charm login has a url to copy to browser in another machine/etc
<elox> I know I can login by using a browser, but if I don't have a browser available ?
<rick_h_> elox: none available at all? I mean I run it remote and copy the url to my local laptop browser window.
<elox> ... if I'm, lets say, in a datacenter with a console only =D
<rick_h_> elox: type it out on your cell phone? :)
<elox> rofl
<rick_h_> elox: but I think juju login jaas isndans browser
<rick_h_> Give that a go
<elox> isndans?
<rick_h_> Is sans browser
<cmars> juju login jaas -B
<elox> Not sure what you mean
<cmars> elox: rick_h_^^
<elox> AAAhhhhh
<rick_h_> I thought -B was the default now
<elox> Hm, I still get the question when trying to deploy to my localhost
<elox> lxd
<rick_h_> Ah on, deploying to localhost. So it's going to use your charm login
<elox> ok ?
<elox> Oh, adding the -B worked
<elox> again
<elox>  juju deploy -B cs:~erik-lonroth/mydbtest-1 Located charm "cs:~erik-lonroth/mydbtest-1". Deploying charm "cs:~erik-lonroth/mydbtest-1".
<elox> big thanx
<rick_h_> ok, I didn't realize deploy had a -B and it should use your existing login
 * rick_h_ learns something new
<elox> I'm trying to learn this before tomorrow when I need to get some staff to do the same as me here. Its a bit of a hurdle.
<elox> But with some great help from @bdx and yourself, I will make it through
<elox> what is your best way to redeploy a charm without having to redo deployment of a full machine etc?
<magicaltrout> upgrade-charm?
<magicaltrout> hack the code on the box and let the hooks rerun?
<elox> well, I have a new version and I remember some tips and trix from me asking the same question a few months ago
<elox> .... at that time, I think I was to new to all this to cope with the informaion
<magicaltrout> well if you have an updated version in the store
<magicaltrout> you can upgrade the charm
<magicaltrout> depends what you're trying to test I guess
<elox> Yeah... I'll manage =) juju remove-application ........
<rick_h_> elox: magicaltrout and if you're local you can upgrade-charm --switch and such
<rick_h_> basically upgrade charm but using the options to either use a new local path (after charm build) or a new version in the store with just upgrade-charm from where it came from
<pmatulis_> jam, can you confirm that controller HA is active/active (load balancing)? also, a hot standby is technically a valid HA strategy. is there anything you can think of that i could elaborate re 'hot standby'?
<magicaltrout> rick_h_: the mysql charm points to marcoceppi 's github repo
<magicaltrout> but that repo doesn't seem to be the charm home
<magicaltrout> any idea where it lives?
<rick_h_> magicaltrout: oh hmm, I thought that was true.
<magicaltrout> well I'm trying to find its zesty support tag in metadata.yaml
<magicaltrout> and i can't see it in that repo
<magicaltrout> cause its hosed in zesty which is currently the default
<magicaltrout> either that or marcoceppi hasn't pushed his latest
<magicaltrout> i'd get rid of that zesty tag for now
<rick_h_> yea, https://api.jujucharms.com/charmstore/v5/mysql/archive/metadata.yaml
<magicaltrout> yeah the install hook fails
<magicaltrout> 100% of the time
<rick_h_> that's what's there and that's for the cs:~mysql-charmers/mysql
<magicaltrout> lack of python or something
<rick_h_> and that's the home page setup for that url, so I've got nothing else to go off of there
<magicaltrout> well i've stuck an issue in his github but its hard to fix cause i don't know which source he's built off of
<magicaltrout> don't demo mysql though rick_h_ ;)
<rick_h_> magicaltrout: heh gotcha. I might see marcoceppi next week at the sprint I'll check with him
<magicaltrout> going anywhere nice?
<rick_h_> magicaltrout: berlin sprint to plot out 18.10
<rick_h_> magicaltrout: should be fun but wish it was somewhere I could bring my bike and ride :P
<magicaltrout> hmm never been to Berlin somehow
<magicaltrout> I hope its nice and wet for you ;)
<rick_h_> booooo
<rick_h_> looks like it'll be about like at home
<rick_h_> if the forecast holds up
<magicaltrout> cmars: you around?
<cmars> magicaltrout: i am, how goes?
<magicaltrout> not bad just trying to get some sanity in my life which with 2 interns learning juju is tricky i'll admit! ;)
#juju 2018-04-25
<jam> manadart: just making some coffee will be a couple min late
<manadart> jam: Ack.
<jam> manadart: any chance you could look at https://github.com/juju/juju/pull/8654
<jam> it handles the Addresses() being empty
<manadart> jam: Yep.
<manadart> jam: LGTM'd
<jam> stickupkid: I confirmed your change on 8655, do you want to $$merge$$ your first PR?
<stickupkid> sure :D
<jam> stickupkid: I like your GH profile picture
<jam> stickupkid: can you set up a pic for Trello as well? It can be the same pic, just nice to have something than SR
<stickupkid> jam: yeah of course
<jam> hml: you also still just have your "HL" in trello.
<jam> manadart: there was always "if it compiles, ship it", now we also have "if it bootstraps, ship it" :)
<manadart> jam: Words to live by :)
<manadart> Some thing to go on the next Juju shirt/sticker/flair.
<rick_h_> bdx: cory_fu_ kwmonroe hml magicaltrout zeestrat and folks juju show in an hour. Party time!
<rick_h_> getting the hangout setup
<rick_h_> if you want to watch the stream hit up https://www.youtube.com/watch?v=cxAsJpmwDFE
<rick_h_> https://hangouts.google.com/hangouts/_/qmpic4iiazfmffm7to5kw7ohq4e if you want to chat on the call
<rick_h_> zeestrat: bdx coreycb kwmonroe hml and anyone else interested ^
<balloons> rick_h_, bionic release hype! Folks should use 2.3.7 or 2.4-beta1 client to be ready for it :-)
<rick_h_> thanks zeestrat, appreciate you joining in!
<rick_h_> third time you join you have to show something cool, no pressure :P
<rick_h_> first two are free lol
<zeestrat> rick_h_: That's how they get you!
<zeestrat> rick_h_: Yeah, I had a small blog post about some juju upgrade woes a couple of weeks ago, but I need to up my game to match stub's posts. Just got a large shipment of supermicro boxes that we're going to expand our juju deployed ceph cluster with. Been hitting (and fixing) the ceph-osd charm a bit to make that smooth so might write up something there.
<rick_h_> zeestrat: love it, and saw your upgrade post. Thanks for that. Was solid.
<rick_h_> well, sucked you hit the bugs there, but good stuff that folks helped out and you pushed through and got things rocking
<zeestrat> rick_h_: Yupp, things got sorted in the end and it seems the guys will be focusing more on testing which is great. Not to mention having dedicated staging setups has saved our butts more than once.
<rick_h_> Yea, good practices are good practices for sure.
<zeestrat> rick_h_: Can't promise a live upgrade of our prod cluster, but let me see if I can cobble together something fun.
<thumper> morning team
<balloons> thumper, good morning
<veebers> Morning o/
<TheAbsentOne> As it is almost midnight for me I will be offline soon but are there expert charm writers online right now by any chance?
<magicaltrout> whats broken TheAbsentOne ?
<TheAbsentOne> nothing is (yet) but I want huge insights and opinions :D
<magicaltrout> ha
<TheAbsentOne> is it okay to post dropbox url (pdf) here magicaltrout ?
<magicaltrout> sure
<TheAbsentOne> https://www.dropbox.com/s/adiyp4qqkx4wg3i/Charm%20prototypingv0.pdf?dl=0
<magicaltrout> ah this badboy
<TheAbsentOne> I created a document to illustrate what I want to create and I want some tips and help from the real experts ^^
<TheAbsentOne> hehe sorry man!
<TheAbsentOne> I added the link to a github repo where everybody can leave a response as well (if I would be offline). I'll ask it tomorrow again though no worries. You guys will be mad at me soon enough x)
<magicaltrout> i do like this idea TheAbsentOne. So in simple terms its an SQL dump for a bunch of different databases, and depending on which you connect to it will install the correct database and provide connection details?
<TheAbsentOne> magicaltrout: so yeah you can actually see it even bigger and add nosql technologies to the stack as well
<magicaltrout> yeah i used sql as the common example
<magicaltrout> but json dump or whatever
<TheAbsentOne> yeah exactly and the generic-database charm handles all complex material if the requirements are not clear. And if let's say the using charm knows it's stuff it will just act as a proxy
<magicaltrout> i have a few questions off the top of my head
<TheAbsentOne> sure shoot!
<magicaltrout> a) why not ship the schema with the application, and import the database at relation connection time to the app? rather than the proxy charm
<magicaltrout> b) if developer a updates the webapp but the schema differs from v1 to v2 and someone then deploys the 2 charms it'll die horribly, how is that mitigated?
<TheAbsentOne> a) We really want a charm that represents a database (and not a service). The major use would be to have the ability to have multiple charms to "easily" connect to the same database.
<TheAbsentOne> And I kinda think that also answers the b question. If a developer updates the webapp, the database itself is not changed whatsoever
<magicaltrout> ah yeah the multiple charm thing, i did read that!
<magicaltrout> in answer to your questions, i think you're right in keeping the mid layer simple that way it can be leveraged by more projects
<magicaltrout> and
<TheAbsentOne> My whole conceptual idea of my research comes down to modeling things in juju that are not services and in my specific case it's about databases. But the same use case could be mapped to load balancers, message brokers, topics, caches
<magicaltrout> you can't delete relations to my knowledge, but you could block up th eothers so if they end up being used you could publish a status message saying "We're serving on database x, your database y connection will have no effect"
<magicaltrout> or something of that nature
<TheAbsentOne> Right, that would be a good solution. The only thing that kinda feels awkward right now is that I assume relations are made between the providing technology charms (the charms from the charm store) and my generic-database. So this means that for every non-used database technology a useless database will be created because that is default behaviour right now, right?
<TheAbsentOne> A second step (if I get this generic-database charm to work) would be to use libjuju to dynamically deploy the services on the fly, resolving this issue. But I'm a bit scared to use libjuju right now (as I'm a still a complete beginner/noob)
<magicaltrout> pretty much
<TheAbsentOne> That isn't the end of the world though in this proof of concept ^^
<TheAbsentOne> So do you thing the structure of the charm is somewhat okay? Do you think it's feasible magicaltrout?
<magicaltrout> i think its perfectly viable TheAbsentOne i like the idea. For example I'm working on a bunch of data viz and SQL tooling
<magicaltrout> so in using that, I'd get connectivity to your app in Apache Drill or something with zeroconf
<magicaltrout> at which point I can then expose the schema to the data viz tools who know about it automatically
<TheAbsentOne> That's really cool to hear. I have no experience with drill or zeroconf so I'm not completely following but it would be cool if it could help others too!
<magicaltrout> well i deal in the data analysis sector
<magicaltrout> so if I can tap into your "webshop" without knowing anything about it to provide more reports etc
<TheAbsentOne> Great I will start on setting up a repo asap and hopefully I get somewhere
<magicaltrout> thats a good thing
<TheAbsentOne> yes exactly!
<TheAbsentOne> that's exactly the goal actually
<magicaltrout> well then
<magicaltrout> make it so!
<TheAbsentOne> hehe I will do my best. But first some sleep. Talk to you later and thanks for looking into it!
<magicaltrout> no probs
<magicaltrout> have a good night
<veebers> could I get a quick review for this please? https://github.com/juju/juju/pull/8658 adds a file that should have been added in my original PR.
<veebers> currently looking at updating the merge/check jobs to catch stuff like this.
<thumper> veebers: why is this check-merge failing? https://github.com/juju/juju/pull/8651
<thumper> I can't work it out
 * veebers looks
<veebers> thumper: odd, probably related to a change I made this morning so the checkout failed on error (instead of ignoring it). I'll get it sorted now
<thumper> veebers: thanks, I was just confused
<veebers> thumper: fixed now, the script was doing "git config core.sparseCheckout" instead of "git config core.sparseCheckout true" so was exiting non-zero (with no error message)
<thumper> ah
<thumper> what is the sparse checkout option?
<veebers> thumper: here it's intended to reduce the amount of work when pulling, checking out and merging a PR. Although the fact that it's never actually been properly set makes me question it's worth. Perhaps I should remove it. Although I'll see how the fixed run goes
<veebers> kelvinliu: Do you have your lint fixes in a separate PR? If not I might do a quick fix now as I'm adding checks to the merge/check job :-)
<thumper> veebers: it passed the check this time
<veebers> thumper: ack, the issue was an error in the checkout script, I added -eux to catch merge errors early etc. seems it was glossing over that issue earlier
<kelvinliu> veebers, not yet. yeah, you can do. appreciate for that. ^^
<veebers> kelvinliu: ack, sounds good.
<thumper> wallyworld: got 5 minutes?
<wallyworld> thumper: after standup, sure, give me 15
<thumper> wallyworld: I'm trying to recall how we gracefully degrade in commands when facades don't define the methods we want
<anastasiamac> thumper: we call the previous call version of any... for example - https://github.com/juju/juju/blob/develop/cmd/juju/application/config.go#L272
<anastasiamac> thumper: or just err out if no equivalent existed - https://github.com/juju/juju/blob/develop/cmd/juju/application/addunit.go#L201
<thumper> that has the client explicitly checking api version
<thumper> which I guess I could do
<thumper> rather than making the api call itself
<thumper> probably better that way
<thumper> there was an error returned from the facades if the method wasn't there but I can't seem to find a reference
<anastasiamac> ha, dunno of any specialised errors coming from there except for NotFound and NotImplemented..
<wallyworld> thumper: free now, just finished standup
<wallyworld> we do use BestVersion()
<wallyworld> to check up front
<thumper> wallyworld: yeah, that's what I'm doing now
<wallyworld> rather than making the call
<thumper> wallyworld: so we don't need to chat
<wallyworld> ok
<anastasiamac> thumper: wallyworld: well, if u r after a totally complete answer... we do actually check bestapi version at api layer too but mostly if we change args to call between facade versions, for e.g. https://github.com/juju/juju/blob/develop/api/applicationoffers/client.go#L293
<anastasiamac> i do not recall that we actually do that for any calls per se
#juju 2018-04-26
 * vino here
<thumper> jam: mostly lost ya
<jam> thumper: yeah, was just coming around to ping you. will be right back
<veebers> ugh, can someone better versed in find/xargs tell me what I'm doing wrong? I just want the file name sans .py etc: "find . -name "assess_*.py" -print0 |  xargs -0I{} -n1 echo $(basename {} .py)"
<anastasiamac> can I plz get a review of   https://github.com/juju/juju/pull/8659?
<jam> manadart: I've started looking at 8656, any chance you could look at 8660 ?
<jam> anastasiamac: looking. though "similar PR" to what? can you link the PR it is similar to?
<anastasiamac> jam: where r u seeing similar?
<anastasiamac> jam: i don't understand what  r asking, i think...
<jam> anastasiamac: in your PR description you say: "Similar PR to ensure"
<jam> but I don't know what it is similar to
<jam> anastasiamac: anyway, code reviewed mostly LGTM
<anastasiamac> jam: my PR description says "simple"
<anastasiamac> r u sure u r reading the same PR? :D
<jam> anastasiamac: maybe I need glasses. :)
<jam> but I swear I read it multiple times
<anastasiamac> jam: must b one of these days \o/ thnx for looking :D
<manadart> jam: Yep.
<jam> manadart: just finishing up lunch, sorry I'm late
<rts-sander> hey I'm getting on update-series: "ERROR updating the application series is not supported by this API server"
<rts-sander> even though juju --version gives "2.3.7-xenial-amd64"
<rts-sander> which should be a feature of 2.3: https://jujucharms.com/docs/2.3/howto-updateseries
<rts-sander> so what am I doing wrong?
<rts-sander> guess I'm going to have to go with juju remove-application, and add it again with the correct series which is regrettable
<anastasiamac> rts-sander: juju --version gives u a client version
<anastasiamac> rts-sander: to get juju controller version, u'd need to run 'juju status'
<anastasiamac> that'll give u an "API server" version
<rts-sander> anastasiamac, ah now I'm getting 2.2.6
<rts-sander> there ya go
<manadart> jam: Approved 8660 with one comment.
<jam> manadart: thanks. removing hasPriority and changing the pretty function to print it out.
<manadart> jam: What is point of the "juju/" prefixed alias?
<jam> manadart: so that we are authoritative about what image we're pointing at. And also so people can change it and know that they aren't changing what "ubuntu/xenial" is, just that we are deciding what to use for juju
<jam> that said, the official name is actually ubuntu/xenial/amd64 IIRC
<jam> balloons: for standup stuff. I've been reviewing manadart's patch for LXD. I'll probably still finish that up tonight. And then I've managed to get "juju remove-machine" working when you only have 2 machines left.
<jam> and we did the Architecture review.
<jam> and a bit of oracle review
<jam> manadart: ^^ gabriel has pushed up the changes we asked for, so likely its ready to $$merge$$ the next one.
<manadart> jam: I will look.
<manadart> jam: BTW, The image *is* cached when you use CreateContainerFromImage, but without intervention it does not have the juju alias.
<manadart> So it gets picked up thereafter, but to get the local target,  you still need to use the remote server with the alias.
<manadart> I am working a change now to copy the image and add the alias (rather like before).
<rick_h_> kwmonroe: ping if you get a sec
<rick_h_> anyone know on my k8s cluster doing the proxy and going to the /ui gets me a list of api endpoints vs the dashboard.
<rick_h_> it was working, but not messed with it in a while. Did an upgrade on it today and so not sure what I might have borked
<erik_lonroth> Hello, anyone aware of whats happening with lxd cloudimages for bionic ?
<erik_lonroth> http://paste.ubuntu.com/p/XBZ8GHCgJB/
<erik_lonroth> I've tried to bootstrap a local lxd juju controller and fail every time
<pmatulis_> erik_lonroth, why is it trying to look for Bionic? and why are you calling the controller lxd-xenial if you are expecting Bionic?
<erik_lonroth> I'm sorry about the syntax. I've tried other commands and on our xenial node which was working perfectly yesterday
<erik_lonroth> "juju bootstrap localhost" -> gives the same errors
<erik_lonroth> Could this be somehow related to the mechanism (whatever it is) that points to like "current" or something else suddenly starting to point towards something that is neweer than before bionic release date ?
<pmatulis_> erik_lonroth, what version of Juju are you running on the client?
<erik_lonroth> I'm not at my workplace anymore so I can't check.
<erik_lonroth> But I know Its from ubuntu 16.04.4
<pmatulis_> erik_lonroth, do you use snaps or apt?
<erik_lonroth> standard "apt install juju"
<erik_lonroth> I'm happy to file a bug report tomorrow, but I think you should be aware.
<pmatulis_> ok, that will get you 2.3.7 if you installed within the last 48 hours
<pmatulis_> which is the latest stable
<kwmonroe> rick_h_: what does your dashboard url look like?  also, what does "kubectl get po -n kube-system" say about the dashboard (if anything)?
<TheAbsentOne> what is currently the right way to put information on a relation with the reactive framework? I don't find a relation-set function or anything in the api. Do I need hookenv.config and config['key'] = value or is there a better approach?
<pmatulis_> erik_lonroth, fwiw, i just created a xenial LXD controller on my xenial client (running 2.3.7). all with 'juju bootstrap --no-gui localhost lxd'
<magicaltrout> https://github.com/johnsca/juju-relation-mysql i borrow cory_fu_ 's mysql relation as my pattern for most stuff
<magicaltrout> mostly cause he documents things much better than i do :)
<pmatulis_> erik_lonroth, but --no-gui prolly doesn't matter
<magicaltrout> actually on that note, cory_fu_ can you tell me what the new endpoints pattern is all about?
<TheAbsentOne> yeah I find myself always looking back at that repo too magicaltrout hmm, I'll guess I'll just try it out later today
<kwmonroe> magicaltrout: Endpoints are the evolution of the previous RelationBase
<TheAbsentOne> I see, so relationbase is depricated as well kwmonroe ?
<kwmonroe> magicaltrout: so if you previously had an interface provide/require subclass of RelationBase, you would switch that to Endpoint
<kwmonroe> TheAbsentOne: endpoints are back compat with relationbase (at least for now -- not sure about the roadmap there)
<kwmonroe> magicaltrout: endpoints are nice when writing reactive handlers for a couple reasons.. you don't have to worry about param ordering for the handler, eg, @when foo, bar; def handle(bar, foo).  you just always get the endpoint with endpoint_from_flag('foo').
<TheAbsentOne> I see, another quick question. I'm still a bit confused on how the connection_string() function in the juju-relation-mysql works as it is described in the requires file and not the provides file
<TheAbsentOne> These are two different classes o.O
<kwmonroe> better endpoint docs than i could describe are here: https://charmsreactive.readthedocs.io/en/latest/charms.reactive.relations.html#charms.reactive.endpoints.Endpoint
<kwmonroe> TheAbsentOne: you'll have 2 sides of juju-relation-mysql.  the provider is the mysql charm itself (which doesn't exist in a reactive form today, so don't go looking for it).  if it did exist, that charm would handle a client joining the relation by creating a new database and calling  provide_database (https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L51).
<kwmonroe> TheAbsentOne: the *consumer* of juju-relation-mysql would use the requires.py bits and would be something like wordpress, which needs to know what db mysql has created for it.
<kwmonroe> TheAbsentOne: so in the consuming charm, you would have something like "@when mysql.available; def configure_db(); db = endpoint_from_flag('mysql.available'); conn_string = db.connection_string()
<TheAbsentOne> Owkey I see so I completely had it the other way around, thanks a lot for that clarification kwmonroe !
<kwmonroe> np
<TheAbsentOne> so if you use reactive framework you will never create a provides.py? kwmonroe
<kwmonroe> not quite TheAbsentOne -- if you are creating an interface layer (https://jujucharms.com/docs/devel/developer-layers-interfaces) you will always create the provides.py and requires.py.  if you are creating a reactive charm that uses an interface, the provider (mysql) will call the interface provides.py methods to effectively do "relation-set" and the consumer (wordpress) will call the interface requires.py methods to "
<kwmonroe> relation-get" the stuff sent by the provider.
<TheAbsentOne> kwmonroe allright, I will chew a bit on that and come back to you thanks man
<kwmonroe> TheAbsentOne: sounds good.  the takeaway is that provides.py and requires.py are 2 sides of an interface that can be used by charms whether they're reactive or not.  the Endpoint class simply makes it easier to work with (ahem, react to) the data that's getting passed around.
<bdx> kwmonroe: I was able to get a strawman working with hadoop <-> cephfs
<kwmonroe> noice!
<bdx> kwmonroe: my guys are dead set on using for the hadoop that will run in our openstack
<bdx> I don't think its the worst idea
<bdx> either way, I'm going to be working on charming the bits over the next few
<kwmonroe> "I don't think its the worst idea" <-- well there's a glowing recommendation if i ever heard one
<bdx> :)
<rick_h_> kwmonroe: howdy, so kube-system says kubernetes-dashboard-5bd6f767c7-5d7rc            1/1       Running            0          3h
<rick_h_> kwmonroe: url is just the 127.0.0.1:8001/ui
<rick_h_> and gets me https://www.irccloud.com/pastebin/RGCPnRZ2/
<kwmonroe> rick_h_: try replacing /ui with /api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
<kwmonroe> the latter is way easier to remember
<rick_h_> kwmonroe: hmm, ok that worked
<kwmonroe> my work here is done
<kwmonroe> send bitcoins
 * rick_h_ now ponders wtf
<kwmonroe> rick_h_: see https://github.com/kubernetes/dashboard, NOTE:
<kwmonroe> The shortcut http://localhost:8001/ui is deprecated. Use the full proxy URL shown above.
<rick_h_> well, that makes me sad for the world
<kwmonroe> rick_h_: how did you know to go to /ui?  i thought 'kubectl cluster-info' would show you the new url nowadays
<rick_h_> kwmonroe: because the readme says so?
<kwmonroe> when you're paid by the character, you don't want /ui
<rick_h_> To reach the Kubernetes dashboard, visit
<rick_h_> http://localhost:8001/ui
<kwmonroe> ahhh rick_h_, fair enough.. if our readmes are borked, that's on us.  would you please file an issue at https://github.com/juju-solutions/bundle-canonical-kubernetes/issues
<kwmonroe> you can keep your bitcoins... for now.
<rick_h_> kwmonroe: I liked the readme version better
<kwmonroe> lol
<kwmonroe> if only readmes made it so
<rick_h_> and when I did try the cluster-info I felt like that failed for some reason. /me goes to look wtf
<rick_h_> ah, that's right, that doesn't use the proxy url so you get "message: "services "https:kubernetes-dashboard:" is forbidden: User "system:anonymous" cannot get services/proxy in the namespace "kube-system"","
<rick_h_> so you have to mix the two, use the localhost domain, but the rest of the url so you can get to it
<kwmonroe> yeah, duh.
<cory_fu_> magicaltrout, kwmonroe, TheAbsentOne: Sorry, I was on my chromebook which doesn't give me notifications for pings and I missed that whole convo.  Sounds like kwmonroe explained things well, though I haven't finished getting caught up.
<kwmonroe> cory_fu_: please correct as needed.  i tried to summon your voice in my head with everything i typed, but still good to get it straight from the horse.
<cory_fu_> magicaltrout, kwmonroe, TheAbsentOne: One thing I did want to clarify that kwmonroe said is that you can use endpoint_from_flag with RelationBase style relations as well.  Honestly, charm authors shouldn't care how interface layers are implemented, so they will always be compatible.  But yeah, you can now just have no-arg handlers and always use endpoint_from_flag (or relation_from_flag if you like that better, but it's deprecated and the
<cory_fu_> terminology of the former is more precise)
<cory_fu_> The main benefit of Endpoints vs RelationBase is that you don't have to worry about scopes or conversations or any of that mess.  You always just iterate over self.relations[*].units and access unit.received (or received_raw for older interfaces), or you can use self.all_joined_units.received if you don't care which unit the data comes from.
<cory_fu_> Or iterate over self.all_joined_units, etc.  There are several convenience views to hopefully make whatever use-case as natural as possible
<kwmonroe> oh yeah cory_fu_!  i told magicaltrout that there were a couple reaons why endpoints were better, but only mentioned how nice it is to have no-arg handlers.  the other was for sure the paving over of scope/convos.  in fact, i'll always believe you pioneered this pattern so i would stop asking you if my interface was global or unit.
<cory_fu_> If you're familiar with the RelationBase pattern, using self.all_joined_units.recieved is analogous to scope=GLOBAL, using self.relations[*].joined_units.received is analogous to scope=SERVICE, and iterating over self.all_joined_units or iterating over self.relations[*].joined_units is like scope=UNIT.  Something like that
<cory_fu_> Switching to Endpoints from RelationBase should hopefully be pretty painless, and mostly just involve getting rid of the confusing bits in favor of using those more explicit collections
<TheAbsentOne> cory_fu_: thanks for bringing it up. It's still a maze for me but I hope I will get there. I talked yesterday with magicaltrout about my project btw: if you are interested and you have the time to look at it, I would love some recommendations on how to approach it all: https://www.dropbox.com/s/adiyp4qqkx4wg3i/Charm%20prototypingv0.pdf?dl=0
<cory_fu_> kwmonroe: Oh!  Another big thing is you no longer need @hook at all, which also makes them work with upgrades from non-reactive charms to reactive, where RelationBase failed miserably
<TheAbsentOne> You know what I kinda miss in the whole reactive pattern + writing charms. A "state of the art" example that or roadmap. I hope to document my project in such a way, hopefully it can be used as some sort of tutorial or something
<kwmonroe> TheAbsentOne: if you do that, rick_h_ will feature you on the juju show and probably send you bitcoins.
<TheAbsentOne> Haha xD no need for that as long as I end up with a working thing I would be the happiest guy on earth
<TheAbsentOne> kwmonroe cory_fu_ the juju show is every 2 weeks right? You guys know by heart if there was a show about libjuju?
<kwmonroe> TheAbsentOne: yup, every 2 weeks.  i don't recall libjuju being featured off hand, but maybe rick_h_ or cory_fu_ would remember.
<cory_fu_> kwmonroe, TheAbsentOne: I know we've talked about it in the past, but I don't recall in what depth, nor exactly when it was.
<TheAbsentOne> That's ok!
<cory_fu_> TheAbsentOne: Looking over your PDF, making a generic database interface protocol is a really good idea but I think if you can create the interface, ideally you would want to update the individual database charms to support it directly rather than requiring a proxy charm to relay the relation data.
<cory_fu_> Also, there's something to be said for the inherent typing that the different interface protocols provide... Not every application will realistically work with just any DB, especially for ones as different as MongoDB is from relational DBs
<TheAbsentOne> cory_fu_ thanks for looking into it! Hmm I kinda don't want to edit existing charms + I really want to have the option to have multiple charms to connect to 1 and the same database.
<cory_fu_> Sure, I can see that.  Updating the existing charms can be intimidating, and there's nothing wrong with having a proxy charm as a first step, but I just wanted to say that getting the charms updated would be the ideal end-goal, to me.
<TheAbsentOne> cory_fu_ correct but my "proxy charm" should find out from data on the relation what specific service should be used
<TheAbsentOne> ah I see gotcha
<cory_fu_> TheAbsentOne: One of the benefits of modelling software in Juju is that it's easy* to look at the model diagram and see what applications have relationships and thus dependencies on which other applications.  The abstraction layer of the proxy charm seems appealing, but you end up not knowing what applications are actually using mysql, postresql, mongo, etc. which can make it harder to reason about load, usage patterns, security, etc.
<cory_fu_> *: for some definitions of "easy"  ;)
<TheAbsentOne> cory_fu_: my goal of the "generic-database" charm is based on 3 things: 1 that he can determine what service needs to be used by the consumer charm, 2 that he acts as a proxy to relay information from existing charms to consumer charm and 3 if a new consumer comes in and wants to use it all he needs to do is add a relation and all information is already there
<TheAbsentOne> That is a really good remark there, and I realised I was trying things with juju that it wasn't really designed for when theorycrafting
<TheAbsentOne> Then again the focus I have is to create a charm that "stupid users without operational knowledge" can use without being bothered by different technologies, their setup and their connectionstrings
<cory_fu_> TheAbsentOne: But don't let me naysay your idea. :)  What you're proposing is certainly possible and I know there are cases where it would make operational management easier.  You should just also keep in mind what your trade-offs are.  :)
<TheAbsentOne> I will keep you posted cory_fu_ and probably ask for in depth technical questions as I'm really a noob when it comes to writing python code for the charms and interfaces x) I appreciate your thoughts!
<cory_fu_> TheAbsentOne: kwmonroe and I started going down a similar thought route with the big data charms at one point, starting to come up with ideas about service discovery and a central hub for big data components.
<cory_fu_> TheAbsentOne: Happy to help, any time
<cory_fu_> TheAbsentOne: Regarding your questions toward the end, it's definitely a good idea to keep interface layers as simple as possible.  Really, the interface layer should just be there to provide a structured API over top of the data that goes over the wire and give you room to change that data if needed without breaking the API
<TheAbsentOne> I see, that's pretty close in terms of approach/goal. I hope to get a working proof of concept real soon (although it will seem really inefficient without libjuju as all supported database services need to be up and running)
<TheAbsentOne> that's good to hear, I guess that's the first step to properly work on the interface layer ;) I'll let you review it real soon cory_fu_
<TheAbsentOne> and all others here ofcourse
<cory_fu_> TheAbsentOne: As for removing relations from within charms, it's definitely not possible without essentially providing the charm with credentials for Juju and using something like libjuju to drive it.  You're essentially describing an operator charm (an autoscaler would be another example), which is possible but again requires giving your charm access to the Juju controller that it doesn't get out of the box
<cory_fu_> TheAbsentOne: The beta version of Juju now has a concept of granting "trust" to give a charm access to cloud credentials to talk directly to the cloud API.  The logical next step would be something similar to allow the charm to talk to the Juju API.  The Juju GUI would be a good candidate for that, along with things like autoscalers and your charm
<TheAbsentOne> Yep that's what I thought and found when browsing the docs and stuff, so I hope to look at libjuju but that's on another whole new level
<TheAbsentOne> that would be really interesting
<TheAbsentOne> cory_fu_: Is libjuju hard to use and is such an operator charm hard to write on top of an existing charm?
<TheAbsentOne> so in other words if I have a charm that does my stuff pretty good could I use libjuju and add that functionality?
<arosales> Happy 18.04 release day :-)
<cory_fu_> TheAbsentOne: Well, I'm probably a bad one to ask, as I work on libjuju quite a bit, so it doesn't seem too hard to me.  ;)  But it does use the async pattern, which can be confusing if you're not familiar with it.
<cory_fu_> arosales!  o/
<TheAbsentOne> Welp good to know I will just ping you a lot if I reach that point x) thanks again cory_fu_
<arosales> waves to cory_fu_
<TheAbsentOne> big day arosales ! ^^
<cory_fu_> TheAbsentOne: In general, though, I don't think libjuju is terribly hard to use.  The examples/ directory has some good examples, such as this one: https://github.com/juju/python-libjuju/blob/master/examples/credential.py
<arosales> TheAbsentOne: indeed, LTS! :-)
<cory_fu_> TheAbsentOne: And the docs have examples for adding and removing relations: https://pythonlibjuju.readthedocs.io/en/latest/narrative/application.html#adding-and-removing-relations
<TheAbsentOne> cory_fu_: great, I will bookmark these and I pray I will use them in the near future x)
<kwmonroe> TheAbsentOne: i find it better to open tabs for required links without bookmarking them.  that forces you to read them before you browser crashes (assuming you don't have a tab resumer -- best to disable that in this case)
<kwmonroe> ;)
<magicaltrout> i've had D and Julia tabs open in my firefox browser since i was in DC in january
<magicaltrout> it keeps crashing
<magicaltrout> and they keep coming back
<kwmonroe> ahoy arosales!  i assume you're bionic as ever.
<TheAbsentOne> haha I'll keep that one in mind kwmonroe xD
<kwmonroe> yeah magicaltrout, these new fangled browser innovations are fueling my procrastination
<kwmonroe> "tab suspended since Nov 2016"... i'm sure i'll get there soon.
<arosales> There are tooo many jokes, mostly not in a good taste, for Bionic Beaver
<arosales> Great Suspender!
<kwmonroe> i learned it from watching you arosales.  never before had i seen 700 tabs open until i watched you present.  i thought "no way that browser stays up", then i learned of your suspenders.
<kwmonroe> been not reading things ever since
<arosales> Glad I had such a positive effect on your procrastination
<magicaltrout> don't get him procrastinating more...
<arosales> magicaltrout: all you need to do is fuel him with cheap beer
<arosales> magicaltrout: that _does_ have diminishing returns though
<magicaltrout> i know... gone are the days when you used to take us to nice joints arosales ... all i've got left is kev and cheap beer ;)
<arosales> lol, always good to see folks put kwmonroe and cheap beer in the same sentence
<magicaltrout> and thats tricky cause cory_fu_ still refuses to drink beer...
<arosales> magicaltrout: we will have to make our own conference featuring unicorn tears for beer
<magicaltrout> sounds like an excellent plan
<arosales> oh cory_fu_ you have to fuel with top shelf bourbon
<magicaltrout> i know
<magicaltrout> one day it'll bankrupt me
<cory_fu_> lol
<magicaltrout> i told him i'll supply him hats to offset the lack of affordable bourbon
<arosales> only fedoras
<magicaltrout> yeah
<magicaltrout> posh git
<veebers> Morning all o/
<thumper> morning
<magicaltrout> can we have a straw poll herer
<magicaltrout> -r
<magicaltrout> here's more wrong me or marco
<magicaltrout> can't type
<magicaltrout> who's more wrong
<magicaltrout> https://github.com/marcoceppi/charm-mysql/issues/25#issuecomment-384791236
<magicaltrout> https://jujucharms.com/mysql/58
<magicaltrout> oh he seems to suggest the fix is in candidate not the zesty support
<magicaltrout> makes a bit more sense
<TheAbsentOne> Welp i'm off to bed, talk to you all in a few hours!
<wallyworld> vino: standup?
#juju 2018-04-27
<wallyworld> kelvinliu: got a minute to talk?
<babbageclunk> names
<babbageclunk> doh
<wallyworld> veebers: got a minute?
<kelvinliu> wallyworld, sorry, just saw ur message. yeah, i am free now
<veebers> wallyworld: I'm just about to pop out for a childcare meeting :0\
<wallyworld> kelvinliu: ok
<wallyworld> veebers: no worries, just ping when you're back
<veebers> wallyworld: can we chat after?
<veebers> mean, will so
<veebers> do
<wallyworld> vino: how goes it? let me know when you might be free for a chat?
<vino> It working.
<vino> i was able to replace the cmd.Context in differant way.
<vino> test it..
<vino> and push the commit
<vino> that can be first reviewed
<wallyworld> yay, great
<wallyworld> let me know hen ready for review
<vino> sure.
<wallyworld> babbageclunk: quick chat?
<babbageclunk> wallyworld: sure sure
<babbageclunk> in 1:1?
<wallyworld> yup
<vino> wallyworld:
<wallyworld> vino: hey, just talking to chtis, give me
<wallyworld> 55
<wallyworld> 5
<vino> sure sure.
<vino> anastasiamac: hi Can u please take a look at PR#8644
<vino> provide ur feeback please
<anastasiamac> vino: m a bit swamp atm but will try later on today. otherwise, monday :D
<vino> sure.
<wallyworld> vino: free now
<wallyworld> habgout?
<vino> ok.
<vino> not really.
<vino> i want u to take a look.
<vino> unit tests are still pending.
<vino> if u r ok with the way i retrurn
<vino> if its CLEAN
<wallyworld> vino: ok, will review now
<wallyworld> vino: i've left come comments. good to see those contexts gone. let me know if anything is unclear
<vino> sure..
<vino> i cleaned up the updateseries_test.go
<vino> and unti test result:
<vino> OOPS: 10 passed, 6 FAILED
<vino> --- FAIL: TestPackage (0.21s)
<vino> FAIL
<vino> so 4 are the ones which has sysd issue
<vino> and 2 are STDOUT format err.
<vino> and verified the juju-updateseries functionality as well.
<wallyworld> unit tests will take a little tweaking to get right for sure
<vino> yes.
<vino> Just gone thru ur comments
<vino> its all clear for me.
<vino> i will address them.
<vino> Yes. Unit test.... :)
<vino> I want u to decide upon that.
<vino> shd i be moving them all to service folder as agentconf_test.go ?
<vino> wallyworld: the above message is for u :)
<wallyworld> yeah, there should be some tests for the helper code in that file. but potentially also some updateseries tests still as well
<wallyworld> let's get everything working and then we can mess with where the tests live
<vino> ok sure.
<wallyworld> easier to refactor with a clean system
<vino> first i will address ur review comments and keep it clean.
<vino> wallyworld:Agree
<wallyworld> that way you know any failures are due to the refactoring and not broken code
<vino> wallyworld:agree
<vino> wallyworld: have a min
<anastasiamac> vino: do u still need that PR reviewed? m in a logical break and can spare a min
<anastasiamac> :D
<vino> yes. i did address the review comments.
<vino> But i need to discuss upon the way unit tests are going to be placed
<anastasiamac> "yes" u need a review or is wallyworld reviewing it?
<vino> we still have 4 issues failing.
<vino> review is done.
<anastasiamac> right. so can u resolve the failing tests before next review or do u need a hand?
<vino> the resolution of those 4 issues.. requires the unit tests to be relocated.
<anastasiamac> m about to go to school picku... do u want to pair on monday to iron these wrinkles? i cannot guaranteed 4am wakeup but certtainly can do a reasonable 9.15am
<vino> :)
<anastasiamac> really? why? nm - let's discuss on monday :)
<vino> sure. i need you help and inputs.
<vino> yes see u on Monday
<anastasiamac> enjoy crispy cold weekend :)
<vino> U too.. Have Fun!
 * anastasiamac is tired of scorching heat in autumn..
<cloaked1> Could someone enlighten me on how to trigger creation of a client-certificate using the easyrsa charm? I'm super new to juju, but so far, it doesn't seem doable to run something like: `juju create_client_certificate` or some such. We're trying to create RBAC based namespaces for users authenticated with certs.
<McL0v1n> Anyone having issues with the prefer ipv6 function?
<McL0v1n> I have a proper ipv6 address (global and permanent) on an interface but the charms are not recognizing the ipv6 addresses on the interface
#juju 2018-04-28
<magicaltrout> cloaked1: at this time of night on a friday, you're much better sticking that on the mailing list
<cloaked1> Thanks magicaltrout. :)
<magicaltrout> I thought wheelhouse.txt installed pip dependencies
<magicaltrout> am I wrong?
<junaidali> Hi everyone, is it possible to recover the juju client files stored in ~/.local/share/juju if we have lost it? and if we have access to the juju controller
#juju 2018-04-29
<veebers> Morning team
<veebers> babbageclunk: would you have a free moment today? wallyworld tasked me with adding --agent-stream to upgrade-juju, want to make sure I'm going down the right path (will need a facade vers bump I believe)
<babbageclunk> veebers: sure
<babbageclunk> veebers: want to hangout about it?
<veebers> babbageclunk: sure! I'll just grab a drink of water, use the standup HO?
<babbageclunk> veebers: yup yup
#juju 2020-04-20
<hpidcock> wallyworld ^
<wallyworld> hpidcock: looking
<wallyworld> sorry, was distracted
<wallyworld> done
<hpidcock> wallyworld: danke
<wallyworld> bitte schoen
<hpidcock> wallyworld: missed this one https://github.com/juju/lumberjack/pull/3
<wallyworld> done
<hpidcock> wallyworld: can you create a v2 branch from master on https://github.com/juju/mgo and push it please. I don't have write access
<wallyworld> ok
<hpidcock> thankyou
<wallyworld> hpidcock: done
<hpidcock> awesome
<hpidcock> thanks
<thumper> wallyworld: are you looking at the release blocker or shall i?
<wallyworld> thumper: babbageclunk is. and i don't agree it's a release blocks. 1. not regressions, 2. TBA not juju
<thumper> wallyworld: I may take a look at logs and sync with babbageclunk then
<babbageclunk> yup yup
<wallyworld> sgtm, ty
<babbageclunk> I can see where everything starts going wrong but nothing that indicates why - just seems like the disk stops
<babbageclunk> would be good if crashdump captured engine reports and goroutines
 * thumper crosses fingers
<thumper> babbageclunk: can we jump in a HO to discuss this bug?
<babbageclunk> yup yup
<timClicks> how do charm (frameworks) access the new juju persistent storage available between hook executions?
<wallyworld> timClicks: no idea, john would know
<thumper> timClicks: StoredState object
<thumper> wallyworld: can you join me and babbageclunk?
<wallyworld> sure
<wallyworld> where?
<thumper> https://meet.google.com/rzk-sipb-yna
<babbageclunk> thumper: while writing stuff up I got very confused about the "fortress worker shutting down" errors - why are we seeing those in the log?
<thumper> that is because the controller is no longer responsible for the model
<thumper> the fortress worker just happened to be a worker stopped that caused all the others to stop too
<thumper> that is what my thinking is
<thumper> because the model workers don't stop all the workers
<thumper> this is a different issue
<thumper> most are based around migration
<thumper> and the migration is based around if responsible
<babbageclunk> thumper: but the lease can only expire if the clock updater can put time updates through, right?
<thumper> I don't know
<babbageclunk> Oh no, the isResponsible worker would crash if it got a timeout trying to extend the lease, so I can see that happening.
<thumper> babbageclunk: http://paste.ubuntu.com/p/F73c29DVcB/ and https://paste.ubuntu.com/p/rVycBmX8PF/
<babbageclunk> oh nice!
<thumper> although the report showing "agent: true" is weird
<thumper> it should be the other unit name
<thumper> however, basics working
<stickupkid> manadart, are we going to add spaces cmds to pylibjuju?
<manadart> stickupkid: I think, yes.
<manadart> stickupkid: https://github.com/juju/juju/pull/11466
<stickupkid> manadart, k, will check now... it seems strange that setting a SetCharmURL isn't a requirement of logic further down. i.e. it does seem flakey logic for it to be like this
<stickupkid> I need to back port my github action fix to 2.7
<manadart> stickupkid: It's because in-situ, the steps happen independently. It is the local uniter that sets the charm URL at deploy time.
<stickupkid> manadart, https://github.com/juju/juju/pull/11468
<manadart> stickupkid: Approved. When it lands, I will add to https://github.com/juju/juju/pull/11467.
<stickupkid> manadart, ah, nice cheers
<manadart> stickupkid: Quick HO?
<stickupkid> not got any video, but sure
<stickupkid> hml, I fixed the tmp directory last month actually -> https://github.com/juju/juju/commit/2912ff39fab9ecd9a0de211cede78a93d35153c4
<manadart> stickupkid or hml: https://github.com/juju/juju/pull/11470
<stickupkid> manadart, I think github have tightened their restrictions on what can run inside a container now
<manadart> stickupkid: *Sigh*
<stickupkid> manadart, I've fixed the snapcraft github action and it's also reporting the same issue https://github.com/juju/juju/pull/11469
<stickupkid> manadart, hml CR at somepoint -> https://github.com/juju/juju/pull/11412
<stickupkid> this one takes time :(
<hml> stickupkid: hrmmâ¦ wonder why i hit it last week then.  will have to investigate on my end
<babbageclunk> thumper: you were talking about going through mongo bugs for #1873482 - anything useful? Should I keep doing that?
<mup> Bug #1873482: [2.7.6] Controller reporting model dropped when no action taken on model <cdo-release-blocker> <juju:New> <https://launchpad.net/bugs/1873482>
<thumper> I didn't find anything, but there were heaps
<babbageclunk> or is it enough to say that we don't think this is new, it probably shouldn't be a blocker?
<thumper> babbageclunk: can you join the release call?
<babbageclunk> sure
<tlm> wallyworld, kelvinliu do we make a service account or rbac permissions for a controller to talk to kubernetes ?
<kelvinliu> tlm: yes, the controller's credential is a RBAC SA
<tlm> where does that SA get created because I am not seeing it
<kelvinliu> during bootstrapping time
<tlm> hmmm funny feeling the code isn't working
<tlm> got a rough idea where I should look ?
<thumper> babbageclunk: bug 1873482, is it in progress or won't fix?
<kelvinliu> why isn't working, the rbac staff are in kube-system namespace
<mup> Bug #1873482: [2.7.6] Controller reporting model dropped when no action taken on model <cdo-release-blocker> <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1873482>
<babbageclunk> thumper: I'm not sure - it doesn't seem like it should be wontfix?
<kelvinliu> tlm: caas/kubernetes/clientconfig/
<tlm> ta
<kelvinliu> nws
#juju 2020-04-21
<kelvinliu> tlm: have u figured out what the root cause is?
<tlm> nah still tracing code at the moment
<tlm> just looks like the broker is loading the default creds from the container and not the kube-system ones
<kelvinliu> the weird,  when u bootstrap then juju add-k8s model1 microk8s, the controller model and model1 should be using the same credential
<tlm> should but my debug points to no
<tlm> the bug will be in our creds loading
<kelvinliu> tlm:  I just had a double check, I log the credential(token) in newK8sBroker, it's the correct token in microk8s(cloud).microk8s(credential)
<kelvinliu> and it's the token in mkubectl get secret/juju-credential-microk8s-token-hpdjs -n kube-system -o yaml
<kelvinliu> I think the credential should be correct. there might be some other issue
<tlm> two ticks will grab you my tests
<tlm> what field are you logging ?
<kelvinliu> logger.Criticalf("newK8sBroker newCfg -> %s", pretty.Sprint(newCfg))
<kelvinliu> 	logger.Criticalf("newK8sBroker k8sRestConfig -> %s", pretty.Sprint(k8sRestConfig))
<tlm> also bootstrap the controller under a different name then the default
<kelvinliu> i tested bootstrap to a different controller name. no problem as well
<tlm> will take a look
<tlm> yeah I agree after decoding the JWT
<tlm> hmmm back to the drawing board
<timClicks_> can the application-version-set hook tool be executed outside of the update-status hook? (our docs seem to indicate that it does)
<thumper> timClicks: perhaps through juju-run, but not by itself
<timClicks> oh I meant can it be run in another hook, eg config-changed
<timClicks> in the same way that the add-metric hook tool is restricted to the collect-metrics hook
<wallyworld> hpidcock: here's a PR for the bug you raised, still need to do a followup for model migration https://github.com/juju/juju/pull/11473
<timClicks> in goal-state... does the relation-get hook tool work if the relation to another unit is in the "broken" state?
<hpidcock> wallyworld: cool, will look
<tlm> hpidcock: SetConfig is the secret killer
<tlm> wallyworld: got 5 min for HO ?
<wallyworld> ok
<wallyworld> hpidcock: ty for review, that migratin todo is because there needs to be a juju/description update first https://github.com/juju/description/pull/76
<hpidcock> wallyworld: Oh it was just not obvious as there was no comment
<wallyworld> fair enough,we often jsut do a quick todo since the followup PR is landing imminently
<wallyworld> and todos like that in the migration_import code are fairly common
<wallyworld> hpidcock: if you were free to do a small +1, it would unblock me to propose the last juju PR to remove those todos https://github.com/juju/description/pull/76
<hpidcock> ok
<hpidcock> wallyworld: LGTM
<wallyworld> ty
<achilleasa> quick poll: I want to modify a provisioner API method which returns a map to *additionally* include an extra KV pair. As this is an agent API call and pylibjuju may potentially call it, do I really really need to bump the version? Note that there are *no* actual schema changes so bumping (and having V{latest-1} remove the key from the response) seems like overkill to me
<achilleasa> any thoughts? stickupkid_ ^
<achilleasa> (call is "ContainerManagerConfig" and the new key is the channel for the lxd snap which comes from a model cfg)
<stickupkid_> achilleasa, let me check, but if it's a map, then that seems fine to me
<stickupkid_> achilleasa, if you add or remove in the map[string]string then no need to bump
<achilleasa> stickupkid_: thought so but wanted to confirm... pheww
<stickupkid_> achilleasa, we should just make the api a map[string]string :troll:
 * achilleasa runs away
<manadart> stickupkid_, achilleasa: Able to review a real small one? https://github.com/juju/juju/pull/11477
<manadart> stickupkid_: Ta.
<achilleasa> tiny PR https://github.com/juju/packaging/pull/9
<achilleasa> manadart: can you take a look at ^?
<manadart> achilleasa: Tick.
<achilleasa> manadart: tyvm
<achilleasa> manadart stickupkid or hml: any ideas why this gets stuck? Am I doing something wrong? (that's on develop/HEAD) https://pastebin.canonical.com/p/P864ZXPTYm/
<hml> achilleasa: if you ssh to 0/lxd/0, has juju been setup?
<achilleasa> hml: let me check
<achilleasa> hml: btw, if I run ' juju add-unit ubuntu-lite --to lxd' it starts a bionic one that does work
<achilleasa> hml: I cannot ssh to 0/lxd/0 (no available addresses)
<hml> achilleasa:  can you get to it from machine 0?
<achilleasa> hml: yes. no juju and cloud-init has completed without an error
<hml> achilleasa:  weirdâ¦ hrmâ¦ iâm trying samilar with only add-machine
<hml> achilleasa:  i get the same with only add-machine:  machine-2 https://pastebin.canonical.com/p/rH4Y88H5Kh/
<achilleasa> hml: can you try with 2.7.6?
<achilleasa> wonder if this is a 2.8 issue
<hml> achilleasa: sure
<hml> achilleasa: hit with 2.7.6
<hml> anyone seeing this bootstrapping lxd develop focal?  âsudo: setrlimit(RLIMIT_CORE): Operation not permittedâ
<hml> as part of the machine config piece
<stickupkid> hml, yeah, it's fine, it's focal issue
<stickupkid> hml, I made a bug out of it, it got closed
<hml> stickupkid: awesome!
<stickupkid> hml, https://github.com/juju/juju/pull/11482/files
<stickupkid> achilleasa, got an issue with windows build
<stickupkid> ##[error]worker/provisioner/container_initialisation.go:260:37: too many arguments in call to "github.com/juju/juju/container/lxd".NewContainerInitialiser
<hml> achilleasa:  thumper renamed the config values etc:  https://github.com/juju/juju/pull/11475
<hml> achilleasa:  once i used the correct config valuesâ¦ HA with OpenStack qaâd good
<achilleasa> rick_h: manadart: stickupkid hml looks like my patch works fine on aws; so it's probably the nested lxds that exhibit the problem...
<manadart> achilleasa: I bet it is specific to snap-installed LXD too. Apparmour/Cgroups or some such.
<achilleasa> stickupkid: can you run the qa steps on aws or maas to confirm?
<achilleasa> manadart: I tried with latest/stable on focal (aws) which should give you 4.0
<stickupkid> achilleasa, sure, give me a sec
<stickupkid> achilleasa, I would but github is down
<achilleasa> anyone doing the homebrew bit of the 2.7.6 release?
<achilleasa> ^^^ doing the homebrew bits
<hml> quick review pls?  https://github.com/juju/juju/pull/11484
<rick_h> hml:  +1
<hml> rick_h: ty
<wallyworld> babbageclunk: hey,  could you comment on https://bugs.launchpad.net/juju/+bug/1874031?
<mup> Bug #1874031: [vsphere 6.5] root-disk-source is failing to select from available datastores <juju:New> <https://launchpad.net/bugs/1874031>
<babbageclunk> wallyworld: yup, looking
<wallyworld> babbageclunk: ty. also a very small PR https://github.com/juju/juju/pull/11478
<babbageclunk> love a small pr
<babbageclunk> wallyworld: approved
<wallyworld> \o/
<hpidcock> babbageclunk: did you forget to update https://github.com/juju/utils/pull/309 in Gopkg.toml?
<hpidcock> I'm guessing this is safe for 2.8?
<babbageclunk> I added that for juju-restore. It didn't occur to me to update the dep in the juju repo.
<babbageclunk> hpidcock: yup, definitely safe
<babbageclunk> But I really should have, sorry!
<babbageclunk> At the moment the only use of UntarFiles in juju extracts to an existing directory tree, so all of the directories are already there.
#juju 2020-04-22
<wallyworld> babbageclunk: 1 line PR? (plus small test) https://github.com/juju/juju/pull/11485
<babbageclunk> wallyworld: yup yup
<babbageclunk> wallyworld: lgtm!
<wallyworld> tyvm
<babbageclunk> do we have a convenient way of combining multiple errors into one?
<rick_h> superglue!
<wallyworld> hmm, not sure
<hpidcock> babbageclunk: not from memory
<rick_h> or gorilla tape
<hpidcock> babbageclunk: the problem is the Cause is ambiguous
<babbageclunk> go to bed rick_h, you're drunk!
<hpidcock> so I think using Annotatef is your best bet
<rick_h> babbageclunk:  am I? crap when did that happen
<hpidcock> chose one error, then have the other in the annotation
<babbageclunk> we've all been there!
<babbageclunk> hpidcock: yeah, but it's not just 2 (although I guess I could combine them pariwise)
<babbageclunk> pairwise
<hpidcock> I think multiple errors is a symptoms of bad design anyway :P
<babbageclunk> I mean, I'm running a script on multiple machines and collecting the errors
<hpidcock> babbageclunk: then they are results, not the error
<babbageclunk> sure... but I want to fail if any of them failed
<babbageclunk> and report the failure as an error
<hpidcock> yeah well then you should combine them
<hpidcock> into one new error
<hpidcock> implement your own error type if introspection is needed
<hpidcock> he didn't like what I had to say
<babbageclunk> sorry computer crashed
<hpidcock> "yeah well then you should combine them
<hpidcock> into one new error"
<hpidcock> "implement your own error type if introspection is needed"
<babbageclunk> my computer didn't really crash
<hpidcock> rage quit?
<babbageclunk> irc needs a /flounce
<babbageclunk> I guess string concatenation it is! Ah well
<babbageclunk> thanks hpidcock
<hpidcock> babbageclunk: string concat makes sense unless you need to allow the caller to introspect each error
<hpidcock> then it should be results
<hpidcock> my 2c
<babbageclunk> yeah definitely, but in this case I just want to report it to the user.
<hpidcock> to the CLI or just into a log?
<babbageclunk> cli
<hpidcock> well if the user specified multiple entities, then the errors are results are they not?
<hpidcock> the error would be "I failed to talk to juju api or something else"
<hpidcock> the results are each of the individual operations
<hpidcock> I'll shutup now leave it to you hah
<babbageclunk> This is in juju-restore, so there's no api involved. But the user doesn't specify the controller machines individually, they just say "restore this backup" and we say whether it worked or not.
<wallyworld> tlm: hey, any issues with my comments on the PR?
<tlm> haven't looked wallyworld pulling my hair out over something else
<hpidcock> tlm seems to find the fun weird stuff
<wallyworld> no worries, reach out if you need help
<wallyworld> to do with the model operator stuff?
<tlm> think I have got it thanks to hpidcock just throwing the tool box at it now
<tlm> angry music helps
 * tlm fixed his problem, drinks babbageclunk rum
<babbageclunk> ok some bash help please? why doesn't this give any output? `ssh ubuntu@10.77.116.85 -- sudo bash -c "echo hey"`
<babbageclunk> in exchange for my rum tlm
<wallyworld> "hey" "hey" "hey" "hey"
<tlm> um
<wallyworld> works for me  :-D
<babbageclunk> heeeeeeeeyaaaaaaaa
<tlm> i am not good at the ssh foo,
<babbageclunk> works without the bash bit
<babbageclunk> Actually my problem is more that I'm not seeing stderr from the command if I run `sudo bash somescript` over ssh
<wallyworld> hpidcock is a bash wizard
<hpidcock> uhoh
<babbageclunk> I mean I'm reluctant to bug him because he's busy and also his advice is annoying
<babbageclunk> ;)
<tlm> lmao
<tlm> i know a guy I can ask babbageclunk
<tlm> not hpidcock
<babbageclunk> but for reals I would appreciate it this time hpidcock not like before
<hpidcock> just need to whack '' around your ssh command
 * babbageclunk tries that
<hpidcock> ssh ubuntu@10.77.116.85 'sudo bash -c "echo hey"'
<babbageclunk> yay, hpidcock is a genius!
<babbageclunk> totally works
<babbageclunk> thanks
<babbageclunk> I take back the mean thing I said just before
<hpidcock> hah
<babbageclunk> ahhhhh - it's because without the quotes the bash command is just taking the command to be "echo", and then the next arg is $0 for the command
<tlm> wallyworld: pushed up some changes, just taking the dogs for a run so they stop bugging me
<wallyworld> ok :-)
<wallyworld> tlm: reviewed, see if i make sense or you think i am on crack....
<achilleasa> stickupkid: found a small problem in my lxd PR (channel not propagated correctly when you install the snap instead of refreshing it). Will amend the last commit to address this
<stickupkid> achilleasa, I've just popped out of a meeting, so I've got time to do the full PR test now
<achilleasa> stickupkid: give me a few min to double-check something.
<achilleasa> stickupkid: pushed the missing bit. btw, I just tried to use my PR to do nested-lxd on eoan host with lxd 3.0/stable (I see 3.0.3 installed in my bionic box) but still doesn't work
<achilleasa> debug logs for bionic and eoan look more or less the same. There isn't actually any output after the "no profile changes required" message and the agent starting. I also compared the profiles in the host boxes to make sure they match
<achilleasa> any idea where I should be looking next for the agent copy bits?
<achilleasa> also manadart ^
<stickupkid> achilleasa, i'm in daily
<achilleasa> (sidenote: downgrading to something like 3.0.3 prevents lxd from starting due to schema incompat)
<achilleasa> stickupkid: is this what I am supposed to be seeing? https://pastebin.canonical.com/p/HjQKkXG84m/
<achilleasa> stickupkid: I still get apparmor's "are you running confined" logs in the nested container
<achilleasa> stickupkid: one step closer: https://pastebin.canonical.com/p/pX8H7fntsM/
<achilleasa> this is after the unconfined patch
<achilleasa> hope we don't have to remove apparmor via cloudinit...
<achilleasa> there is a possibly related bug here: https://bugs.launchpad.net/snapcraft/+bug/1822372
<mup> Bug #1822372: Snapcraft cleanbuild on Arch Linux with LXD - AppArmor permission error <apparmor> <cleanbuild> <lxd> <permissions> <snapcraft> <snapd> <Snapcraft:New> <https://launchpad.net/bugs/1822372>
<hml> stickupkid: https://pastebin.canonical.com/p/C6rwgyxgg4/. from juju edge snap on serverstack. - wonder if its related to my port security enabled bit?  dunno
<stickupkid> hml, but it should block the destroying of the controller, maybe I should just say there will be an orphaned set of os interfaces
<hml> stickupkid: the controller was destroyed
<hml> stickupkid: checking the interfaces
<stickupkid> hml, that's how it should work
<hml> stickupkid: yup, i have an orphaner interface.  thought we fixed this?
<stickupkid> hml, you can't fix it if the server stack doesn't support it
<stickupkid> achilleasa, ping
<stickupkid> hml, get me?
<hml> stickupkid: yeah yeah.
<stickupkid> hml, better error message maybe?
<hml> stickupkid: yes.  especially if we want to let users know to remove them
<hml> weâve done that a few times.
<stickupkid> yes, I'll add a card
<hml> stickupkid: looks like we get a NotFound which is helpful
<stickupkid> nice nice
<achilleasa> stickupkid: pong
<stickupkid> achilleasa, was in daily
<achilleasa> stickupkid: got it working with nesting: https://pastebin.canonical.com/p/PV2MdNDgCn/
<achilleasa> (+unconfined)
<stickupkid> achilleasa, in daily
<achilleasa> stickupkid: thanks for the review. I will need to !!build!! until it gets green (having issues with windows box for the last few attempts)
#juju 2020-04-23
<wallyworld> babbageclunk: so, when you proposed your recent juju/utils PR, did you see unrelated failures in merge check tests due to focal now being picked up as a series https://github.com/juju/utils/pull/311
<babbageclunk> wallyworld: hmm, trying to remember...
<babbageclunk> doesn't sound familiar
<wallyworld> i guess i need to make a drive by change then
<babbageclunk> no, I definitely didn't
<wallyworld> maybe distro has been updated on machine
<babbageclunk> that was nearly 2 months ago though so I can see a default having changed in the meantime
<wallyworld> acxtually, maybe focal is released now
<wallyworld> was going to be today or thereabouts
<babbageclunk> it *is* 20.04
<babbageclunk> yeah that would do that
<hpidcock> wallyworld: can you review this commit https://github.com/juju/juju/pull/11465/commits/2995c2168bdb04d8708dcac06acdbfb9b90ac3a9
<wallyworld> hpidcock: otp, sec
<wallyworld> hpidcock: yeah, that uniter test is bloody awful. goes back to the very early juju go port from python and never been fixed
<wallyworld> hpidcock: looks like a new conflict to solve in gopkg.lock
<hpidcock> yeah, also still fighting some silly tests
<wallyworld> joy
<hpidcock> I can almost taste go mod
<wallyworld> mmmmmmm
<tlm> I want it now hpidcock
<hpidcock> Waiting for ci jobs
<tlm> I am cool with untested code
<hpidcock> Oh its already tested. But Jenkins likes to get upset
<kelvinliu> wallyworld: https://github.com/juju/juju/pull/11490 got this PR to let webhook name keep no change, +1 plz  ty
<wallyworld> sure
<kelvinliu> wallyworld: going to grab some food, come back later
<wallyworld> np
<thumper> wallyworld: https://github.com/juju/juju/pull/11491 is the logger branch
<thumper> wallyworld: it is very mechanical
<wallyworld> sure
<thumper> I'm just snap installing microk8s to bootstrap and deploy to ensure all bits are actually hooked up
<thumper> this is my first time bootstrapping into k8s, anything I need to know?
<wallyworld> hope not
<thumper> and what can I deploy as an "ubuntu-lite" type k8s charm
<wallyworld> i use ~juju/mariadb-k8s
<wallyworld> well, my local copy
<wallyworld> you will need to seed microk8s
<wallyworld> with your locally build juju image
<thumper> how?
<wallyworld> make microk8s-operator-update
<wallyworld> in the discourse post :-)
<wallyworld> then just juju bootstrap microk8s tim
<thumper> ack
<thumper> will try
<thumper> still in the middle of bootstrapping lxd for that part of the test
<wallyworld> i hope to hear good news :-)
<thumper> oh...
<thumper> as noted in the description
<thumper> I've actually properly fixed an intermittent test failure in the featuretests package
<wallyworld> yeah, saw that, good
<thumper> wallyworld: ah, poo, found another place I've missed since the develop merge
<thumper> worker/uniter/actions has a place I need to thread a logger
<wallyworld> np, i'll keep reviewing
<thumper> I'll update and push
<wallyworld> thumper: in caasoperator worker, why logger := loggo.GetLogger("juju.worker.uniter.charm") ? and not from config?
<thumper> wallyworld: because we don't want the "worker.caasoperator" module
<wallyworld> oh right ok
<wallyworld> maybe pass in  as a second logger on the config struct?
<wallyworld> as it's used twice
<wallyworld> well, actuallt no
<wallyworld> slightly different variations
<wallyworld> so maybe not
<thumper> wallyworld: some of this will get cleaned up when we have the caas operator using a nested dep engine
<wallyworld> thumper: yeah, true that. lgtm with a suggestion
 * thumper is still testing...
 * wallyworld needs to go to vet
<thumper> wallyworld: seems I don't have docker installed
<thumper> where do we normally get that from
<thumper> ?
<thumper> wallyworld, hpidcock: ^^
<wallyworld> i snap install docker
<hpidcock> thumper: snap is ok
<thumper> cheers
<wallyworld> there might be a perms issue with /var/lib/docker something
<thumper> why?
<wallyworld> or /var/run/docker. can't recall
<wallyworld> because docker
<wallyworld> or because snap
<hpidcock> I think you just need to add your user to the docker group
<wallyworld> not sure
<wallyworld> ah yeah, that rungs a bell
<wallyworld> been a while
 * thumper hasn't done any of that, just snap installed docker
<wallyworld> may be ok to use it to build images
<wallyworld> but running stuff might complain. but microk8s uses containerd now anyway
<hpidcock> snap might have fixed the issue
<thumper> it isn't / hasn't
<wallyworld> hpidcock: good luck with go mod finalisation, i'll see if there's a devel update after vet :-)
<thumper> does anyone remember how to add to groups without logging in or out?
<hpidcock> newgrp docker will fork the shell with the new group
<hpidcock> but
<hpidcock> you first need to add yourself to the group
<wallyworld> that
<wallyworld> same as we do for lxd
<hpidcock> usermod -a -G docker thumper
<wallyworld> right, off to vet
<tlm> start a new session with su thumper
<tlm> should re load all the groups in that terminal
<tlm> su - thumper
<thumper> hmm... seems like the docker snap doesn't create the docker group
<thumper> or at least doesn't put me in it
 * thumper sighs
<thumper> seems like the docker daemon isn't running even
<tlm> i always install docker from their deb repo
<tlm> but thats just me
<thumper> snap service docker does show one running
 * thumper sighs
<thumper> why is this so hard?
<kelvinliu> wallyworld: I changed the annoation to "juju.io/disable-name-prefix"
<thumper> hpidcock: any ideas why snap docker wouldn't do its thing?
<kelvinliu> i installed docker using apt as well
<hpidcock> `ls -la /var/run/docker.sock`
<hpidcock> is it using the docker group?
<hpidcock> also check `snap services`
<hpidcock> maybe there is a docker service there
<hpidcock> I haven't used the snap in a while
<thumper> that's running as root
<thumper> /var/run/docker.sock
<hpidcock> should be owned by root but the group should be docker
<thumper> it's root root
<hpidcock> eww
 * thumper edits it
 * thumper tries again
<thumper> got further, but it still doesn't work
<thumper> hpidcock: https://pastebin.ubuntu.com/p/cDnpRHhJ77/
<tlm> thumper: are you part of the microk8s group ?
<thumper> ??
<thumper> maybe not
<thumper> nope
<tlm> see if that works
 * thumper adds himself to the microk8s group and tries again
<thumper> yep, that now worked
<tlm> \o/
 * thumper tries to deploy again
<thumper> charmstore was still down before
<thumper> looks like it still is
<thumper> may come back down later
 * thumper is past EOD
<thumper> later peeps
<kelvinliu> anyone free to take a look this tiny PR plz https://github.com/juju/juju/pull/11492
<hpidcock> wallyworld: "All checks have passed"
<wallyworld> hpidcock: so merge that mother plucker
<hpidcock> I need popcorn
<hpidcock> UberEats popcorn delivery to the whole team
<babbageclunk> anyone around in here?
<stickupkid> manadart, https://github.com/juju/juju/pull/11483
<stickupkid> babbageclunk, hello
<manadart> stickupkid: Tick.
<stickupkid> manadart, Ta
<stickupkid> manadart, tests are fun
<manadart> stickupkid: My MicroStack QA worked for https://github.com/juju/juju/pull/11435.
<stickupkid> manadart, was actually just looking at that PR
<manadart> stickupkid: Quick HO?
<stickupkid> manadart: if interface info aka network config doesn't have an origin (older api), then it should be a OriginProvider right?
<manadart> stickupkid: Hmm, that may get us into trouble.
<stickupkid> manadart, quick ho about it?
<cmsanders> Audio is not working for everyone on youtube you might need to repeate the questions
<cmsanders> whoever is talking now can't be heard
#juju 2020-04-24
<babbageclunk> wallyworld: quick review? Once that's landed I'll tag another juju-restore release. https://github.com/juju/juju-restore/pull/16
<wallyworld> sure, just otp will try and do concurrently
<wallyworld> babbageclunk: lgtm, ty
<babbageclunk> wallyworld: nice one
<babbageclunk> hey, anyone have any idea why merge commits in juju-restore are full of \rs? (I guess it's a setup problem with the bot?)
<babbageclunk> https://github.com/juju/juju-restore/commit/e3f234891e55368ac906959c775cf25563f6b754
<babbageclunk> I thought it might be because of the pull request template but it doesn't seem to have them
<hpidcock> "pr_descr=$(echo ${ghprbPullLongDescription} | sed $'s/\\r\\n/ \\\\\\n/g')"
<hpidcock> babbageclunk: https://api.github.com/repos/juju/juju-restore/pulls/14
<hpidcock> should have worked
<babbageclunk> :/
<babbageclunk> thanks hpidcock - I'll check against the juju one
<babbageclunk> love that quoting
<babbageclunk> hpidcock: what does that $' syntax mean? It's totally ungooglable
<babbageclunk> oh no, it's googlable as "bash dollar quote"
<babbageclunk> weirdly, the line from the juju/juju bot uses $"
<babbageclunk> pr_descr=$(echo ${ghprbPullLongDescription} | sed $"s/\\\r//g")
<babbageclunk> from what I can find $" doesn't actually do anything, assuming the locale's C
<babbageclunk> man, that is some super-weird shell-quoting madness.
<hpidcock> shell fun
<manadart> stickupkid: Any special reason to go from `//go:generate mockgen...` to `//go:generate go run github.com/golang/mock/mockgen...`?
<hpidcock> manadart: it will use the go.mod versioned mockgen
<manadart> hpidcock: Yeah, figured that since.
<hpidcock> nice
<hpidcock> tools.go in the root dir pins it as a dependency
<achilleasa> Did we rename other pre-existing go:generate bits?
<hpidcock> achilleasa: just mockgen at the moment
<stickupkid_> hml, manadart petevg, I was working on this yesterday and is required for testing focal for 2.8, can somebody shepherd it through? - https://github.com/juju/juju/pull/11497
<hml> stickupkid_: sure.
<stickupkid_> ta
<hml> stickupkid_: whatâs left?  review and qa?
<stickupkid_> test
<stickupkid_> haha
<hml> stickupkid_: rgr
<hml> :-)
<stickupkid_> was meant to do that today, but never got around to it
<petevg> thx, hml!
<hml> stickupkid_: no worries
<stickupkid_> hml, thanks, later \o
<flxfoo> hi all,
<flxfoo> What does it costs to boorstrap a new controller (with custom image ID, simplestream) and migrate the a current model to new controller, especially in turns of availability (we are talking about a dozen of containers) thanks
<rick_h> flxfoo:  so when you migrate the model the actual units running don't go anywhere. It's just the db that tracks state that's moving.
<rick_h> flxfoo:  so the cost would be a new controller node (t3 medium ish sized?)
<flxfoo> rick_h: thanks, so no service downtime
<rick_h> flxfoo:  no, just the downtime during transition in controller/changing the model
<flxfoo> rick_h: sorry, can you elaborate that?
<rick_h> flxfoo:  so while the model is migrating, there's safety checks going on to make sure all the units running can reach the new controller, that the db is copied over correctly, etc.
<rick_h> flxfoo:  so while that's taking place you can't juju deploy new things into that mode, or make config changes in that model, etc
<flxfoo> rick_h: ok ok thanks for the details.... :)
<rick_h> np
#juju 2020-04-25
<flxfoo> Hi again
<flxfoo> How often you guys create a new controller and move model from one to another? If it is something recurrent for what purpose? upgrade? solving issues? thanks
