#juju 2011-11-21
<george_e> Where in the filesystem of a unit does Juju store the hook scripts?
<hazmat> g'morning
<noodles775> hazmat, m_3 : Hi! I'm currently using the latest postresql charm (r17), and it still used localhost: http://paste.ubuntu.com/745058/
<noodles775> hazmat, m_3: But I've just realised that r17 of that charm didn't update the revision... retrying now after manually updating the rev (as I'm still using the same environment)
<hazmat> noodles775, good catch
<noodles775> And that was it indeed, it's getting the IP now. Thanks!
<noodles775> So the only remaining issue for me seems to be that the postgresql charm uses the relationname as the db name (which psql doesn't like if it contains hyphens): http://paste.ubuntu.com/745066/
<hazmat> noodles775, worth a bug against the charm, it should escape them
<noodles775> hazmat: Will do now... thanks.
<noodles775> hazmat: is this where bugs are now reported for charms? Or is there somewhere newer: https://bugs.launchpad.net/charm
<hazmat> noodles775, each charm has its own bug tracker.. for postgresql its .. https://bugs.launchpad.net/charm/oneiric/+source/postgresql
<noodles775> Great, thanks.
<hazmat> noodles775,  the charm browser at charms.kapilt.com is useful for finding the relevant links
<fwereade> hazmat, does test_full_run in the base agent test ring any bells for you?
<hazmat> fwereade, its a test that actually launches the agent afaicr
<hazmat> fwereade, is it breaking?
<fwereade> hazmat, yeah, and while it's surely something I'm doing it seems I'llhave to start poking into twisted itself to figure it out
<hazmat> fwereade, cause might be a missing env var/cli option
<fwereade> hazmat, hm, yes, plausible
<hazmat> fwereade, i'd try printing os.environ to a file from an early entry point (cli parse setup)
<fwereade> hazmat, well in fact it's not technically *breaking*, but it is exiting the whole test run
<hazmat> huh
 * hazmat looks up the test
<hazmat> fwereade, i don't see anything obvious, even a mismatched mock statement there shouldn't exit the tests, i'd pdb into run().. it doesn't look like it actually forks a process here just simulates the startup.
<fwereade> hazmat, sounds good
<fwereade> hazmat, (sorry vague, moved on to something else for a bit, will be back on that in a bit)
<hazmat> fwereade, no worries
<noodles775> hazmat: hi again. I created https://bugs.launchpad.net/charm/+source/postgresql/+bug/893088 , but atm am just trying to find a work-around...
<noodles775> I've re-name my charm to apache_django_wsgi (both the directory and in the metadata), but get:
<noodles775> Bad charm URL: http://paste.ubuntu.com/745120/
<noodles775> Let me know if you've seen that before... /me keeps plugging away.
<marcoceppi> The postgres charm should probably do a string replace on - with _
<noodles775> marcoceppi: yep, or something similar that enforces db/user names psql is happy with (there could be other invalid chars?). But atm, I just want to get my own charm working :)
<hazmat> its this file that needs a mod http://charms.kapilt.com/charms/oneiric/postgresql/hooks/common.sh
<marcoceppi> Yeah, sanitation would probably need to take place in all the db charms
<hazmat> noodles775, most of the other invalids are done just by restrictions on the charm/service name
<hazmat> which juju handles
<noodles775> hazmat: yep, which is how I'm trying to work-around the issue atm (my charm name), but am getting Bad charm URL... digging now.
 * noodles775 removed both '-'s and '_'s... now it's accepting it.
<hazmat> noodles775, committed a fix upstream
<hazmat> postgres charm escapes dashes now
<noodles775> hazmat: sweet, thanks - I'll rename my charm again so it's readable :)
<SpamapS> marcoceppi: regarding the passing of config on deploy, I think you *should* be able to say --set 'x=y z=foo' .. but you can't right now. Maybe open a bug?
<marcoceppi> SpamapS: Cool, I'll do that and see if I can create a patch for it
<jcastro> marcoceppi: have you seen george? Last I checked he was mostly there but stuck on a juju problem
<SpamapS> hazmat: is there any reason we aren't using the DescribeRegions AWS API call instead of a static list of regions?
<hazmat> SpamapS, txaws doesn't support, and schema def is static thing atm, we could fix both, but its been low priority
<SpamapS> hazmat: ok I'll open a low priority bug against both. Just making sure its possible/makes sense.
<hazmat> SpamapS, i'm not sure it does make sense
<SpamapS> hazmat: I tried using txaws-discover --action DescribeRegions and it fails because of key problems. Is txaws using an outdated API or something?
<jimbaker> not certain why we don't just use boto + deferToThread
<SpamapS> jimbaker: +++++
<hazmat> jimbaker, indeed, or libcloud
<SpamapS> ;)
<hazmat> SpamapS, the schema is defined to validate environments.yaml, but we need to consult the environments.yaml to make the describe regions call...
<jimbaker> cool, this is widely used. see for example some of the openstack tests. etc
<SpamapS> hazmat: so make sure it is formatted right, and trust that the user isn't an idiot. :)
<hazmat> easy enough to do a second pass at the cost of a roundtrip
<SpamapS> if they put in us-beast-1 its ok.. right? ;)
<SpamapS> they'll get a failure on bootstrap
<marcoceppi> jcastro: I was talking to him last night for a bit
<marcoceppi> but then he went to bed
<hazmat> SpamapS, fair enough, we can yank that part of the schema
<SpamapS> I'm getting more and more worried about these juju set* commands ... without a way to export the env.. we're making it really hard to reproduce environments.
<SpamapS> hazmat: we can just make it verify that its a valid hostname (starts with a letter, [0-9-]+) right?
<hazmat> SpamapS,  marcoceppi, you can pass a config file at deploy time
<hazmat> SpamapS, sounds good
<SpamapS> hazmat: convenience feature though, would be nice to be able to have one command that does the deploy and set's without having to write a config file out.
<SpamapS> hazmat: I can see that being an important part of an autoscaler actually
<hazmat> jimbaker, i'm pretty convinced of the utility of doing a provider like that, we really need to stop concerning ourselves with twisted bindings to the world
<hazmat> and just interact with the world
<SpamapS> "when my database gets 10,000 shards, deploy a new one with this shard hash value"
<SpamapS> hazmat: you would make the rackspace guys *VERY* happy :)
<hazmat> SpamapS, i think an autoscaler can figure out how to write a file ;-)
<m_3> noodles775: just catching up with the conversation... is that stack happy with '-'s and '_'s in the charm names now?
<SpamapS> hazmat: mtaylor has been asking me "why not libcloud" for a while now. :)
<hazmat> SpamapS, the answer was for a while that it didn't have support what we needed, but i had a look again last month, and it does seem to support the basics of everything we'd want
<hazmat> the sshscriptdeploy stuff in particular to trigger initialization of the instance
<noodles775> m_3: I haven't yet tried as I'd re-named my charm, but will do so tomorrow. Looking at the change, I expect it to work :)
<m_3> noodles775: cool.. I'll spin it up with various names today
<marcoceppi> SpamapS hazmat I agree, being able to say juju deploy --config="game=tf2" steam is a lot more convenient than having to create a config file :)
 * marcoceppi is lazy
<jimbaker> hazmat, agreed on that. we saw that w/ lxc support by the local provider for example, also a pragmatic usage
 * marcoceppi s/--config/--set/
<SpamapS> hazmat: sweeeeet (re libcloud)
 * hazmat grabs some food
<_mup_> Bug #893176 was filed: do not limit ec2 region to static list of regions <juju:New> < https://launchpad.net/bugs/893176 >
<_mup_> Bug #893184 was filed: Deploy should allow for a "config set" flag <juju:New> < https://launchpad.net/bugs/893184 >
<jcastro> SpamapS: soon I will be confident enough to file bugs like that instead of asking you if ideas are dumb before hand. :)
<SpamapS> jcastro: indeed, thanks for the nudge. :-D
<SpamapS> jcastro: I was thinking the same thing but didn't actually validate my assumptions until you asked. :)
<SpamapS> jcastro: so please, feel free to continue asking "dumb" questions.
 * m_3 hopes SpamapS never tires of answering our dumb questions :)
 * SpamapS hopes google never tires of making him look smarter than he is
<jimbaker> hazmat, looking at libcloud's support for providers, yes that would be very nice: http://libcloud.apache.org/supported_providers.html - no way would we want to do each of these
<jimbaker> i do assume that http://libcloud.apache.org/driver-features.html#deploy means the same thing as cloud-init ?
<SpamapS> gogrid and linode.. nice
<jimbaker> maybe the best thing to do is to support libcloud as a new provider
<hazmat> jimbaker, basically... we'd either format cloud-init as a script, or transfer and invoke cloud init remotely
<SpamapS> hazmat: seems like it would be worthwhile to work in an extension to libcloud to support cloud-init directly.
<SpamapS> hazmat: or at least, metadata/userdata directly.
<jimbaker> SpamapS, that makes a lot of sense
<SpamapS> the world would probably thank us for that.
<hazmat> SpamapS, all we really need to support it is remote ssh
<SpamapS> (and it would also have the nice effect of making Ubuntu a preferred platform for libcloud users)
<hazmat> true
<SpamapS> hazmat: heh.. an ssh usurper provider has been on my list of things to hack out for a while.. just feed it a list of boxes and it will ssh in and run the agent. ;)
<jimbaker> SpamapS, sure, you handle the provisioning with say capistrano, seems feasible
<jimbaker> anyway, i think it would be nice if we got a bug in for a libcloud provider. i would like to work on it myself. the only thing i see missing here  in libcloud is firewall support, but it's a good reason to machine-based firewalls instead
<_mup_> Bug #893204 was filed: Support libcloud provider <juju:New> < https://launchpad.net/bugs/893204 >
<jimbaker> SpamapS, i filed this so we can track and see if this makes sense. seems like the consensus here is that it does
<SpamapS> jimbaker: yes, I'm going to mark it as Confirmed and Wishlist. Once we've got a handle on it, we may need to break it up into a blueprint.
<SpamapS> jimbaker: seems like a good thing to start on as soon as the 12.04 stabilization/prod work is done.
<SpamapS> speaking of that, how is the "subordinate services" work coming?
<jimbaker> is bcsaller out this week? (the best person to ask here)
<hazmat> jimbaker, not per the team calendar
<hazmat> but the person who maintains the calendar is out.. so who knows.
<hazmat> he'll be on shortly, just did a meeting with him re co-lcoation
<hazmat> jimbaker, ping?
<SpamapS> hazmat: I thought of some charms that need to be available as both subordinate and regular services.. so I'm wondering if that will throw a wrench into the spec
<SpamapS> hazmat: like NFS server.. you want to be able to expose the data dir of a service via NFS.
<SpamapS> bcsaller: ^^
<bcsaller> SpamapS: You can define normal relationships from subordinate service outside of the container
<bcsaller> SpamapS: its only the relationship with the principal service that is special
<bcsaller> SpamapS: and so in that sense it is both a subordinate service (to the prinicpal) and a normal charm to anyone else
<hazmat> SpamapS, i tend to think of most of the coordinate services as a head / tail er.. server / client.. where we deploy the clients in co-located fashion, and relate them to the server, this holds for logging, distributed fs, monitoring, etc.
<hazmat> hmm
<hazmat> so in that case expose the data-dir of a service via nfs.. is deploy an nfs-client, that has a relation to the primary that setups the data-dir as an nfs mount.
<hazmat> so its not per se exporting data per se as a separate volume nfs style, just using an existing mounted volume for the storage
<SpamapS> So another scenario is ceph.. the ceph charm operates as both the client and server for ceph
<SpamapS> it would be useful to make the ceph client a subordinate of a service that wants to store data in ceph
<bcsaller> SpamapS: that sounds correct, I don't see an issue though?
<SpamapS> Ok at one point I got the impression that we couldn't subordinate normal charms.
<bcsaller> SpamapS: the client would be a subordinate charm with a normal relationship to the master
<bcsaller> and a subordinate relation to its principal service
<SpamapS> ceph is a normal charm, and works as a client or server
<SpamapS> so I could add a subordinate relation to ceph so it can talk to the.. I don't know the term.. other service in the container?
 * SpamapS re-reads the spec
<marcoceppi> How can I test juju from the repo?
<marcoceppi> from the bzr repo?
<bcsaller> SpamapS: yes, a subordinate relation is what you'd need there. I think that is all you'd need to define but I'll keep playing with the use-case
<bcsaller> SpamapS: we had a top level subordinate:true in the metadata, I've taken that out and it only depends on changing the interface now
<jimbaker> hazmat, hi
<hazmat> marcoceppi, bzr branch lp:juju && cd ./bin/juju -h
<hazmat> marcoceppi, the ppa is rebuilt daily, if you have a package install of juju, it might be good to remove it to avoid any version confusion
<marcoceppi> hazmat: thanks, I'm just trying to test this patch I've made
<SpamapS> bcsaller: ahh cool! ok
<jimbaker> hazmat, thanks for the approval on ssh passthrough. i will write up the new juju scp command shortly, as well as my thoughts on bug 814974
<_mup_> Bug #814974: config options need a "file" type <juju:In Progress by jimbaker> < https://launchpad.net/bugs/814974 >
<jimbaker> biab, time for lunch
<hazmat> jimbaker, great, i wanted to touch base on what's next, but i'll finish up reviews on your branches first
<jimbaker> hazmat, i think i'll take a look at the ssh key stuff
<hazmat> jimbaker, cool
<jimbaker> that's an important prod issue
<jimbaker> hazmat, cool
<_mup_> Bug #893281 was filed: Subordinate services require topology support <juju:New for bcsaller> < https://launchpad.net/bugs/893281 >
<_mup_> juju/session-expiration r409 committed by kapil.thangavelu@canonical.com
<_mup_> add session expiration documentation
<_mup_> juju/session-expiration r410 committed by kapil.thangavelu@canonical.com
<_mup_> merge trunk
<hazmat> sidnei, did your ssd get resurrected?
<sidnei> hazmat, haven't had much time to play with it unfortunately. seems like it's a known issue with sandforce-based drives, and a firmware upgrade might solve it.
<sidnei> http://lmgtfy.com/?q=sandforce+cold+start+bug
<hazmat> sidnei, ic.. good luck with that.. i'm hopeful sandforce controllers will be getting better ootb now that they have much larger testing resources since they got acquired.. just got a new ssd myself (samsung) like 10m ago, tbd
<hazmat> sidnei, hm.. that's interesting.. i was putting together a nas with my old ocz sandforce drive (won't fit in new laptop).. and noticed it wasn't being picked up the bios, what was odd though is the ubuntu partioner could see the drive.. this might be relevant.. although i'm not convinced its not a mb bios issue
<sidnei> yeah, if the partitioner triggers a pci rescan or something, it might get the drive to initialize properly
<jcastro> this is why I am intel only. :)
<marcoceppi> I think I'm going to stick to making charms, and leave juju in the capable hands of those who know
<_mup_> Bug #893332 was filed: Watches are needed for changes to subordinate services <juju:In Progress by bcsaller> < https://launchpad.net/bugs/893332 >
<jcastro> marcoceppi: the charms are the best part anyway, for the rest we can just whine
<jcastro> hey guys, what's best practice for SMTP?
<jcastro> there's no mail charm
<jcastro> and I assume on EC2 they just don't allow port 25 or any of that do they? Don't they have like an email API or something instead?
<jcastro> but if you use the amazon simple email service then the charm becomes aws specific ...
<marcoceppi> You can mail out of port 25, bulk stuff you need to fill out a request
<m_3> hazmat: is charm.log going away in favor of a combined unit-agent log in /var/log/juju?
<m_3> (charm.log is there in EC2, but missing in LXC)
<_mup_> Bug #893379 was filed: inconsistent logging between different providers <juju:New> < https://launchpad.net/bugs/893379 >
#juju 2011-11-22
<hazmat> m_3, in lxc its in /var/log/juju/
<hazmat> we need to unify that, i pushed it there because really it should be there for both..
<hazmat> bad examples becomes precedents  :-(
<george_e> https://bugs.launchpad.net/charm/+bug/891749
<_mup_> Bug #891749: [charm-needed] ThinkUp <new-charm> <juju Charms Collection:New> < https://launchpad.net/bugs/891749 >
<george_e> It appears we have no SMTP charm?
<SpamapS> george_e: nothing yet no
<SpamapS> george_e: should be a fun one to write.. :)
<george_e> Would it be hard?
<SpamapS> george_e: yes.. I don't think there are any smtp servers that don't have 100's of options
<george_e> (...and would Postfix be a good choice?)
<SpamapS> yeah since is the default in Ubuntu
<george_e> Hmmm... well, it would definitely be a challenge.
<SpamapS> Luckily debconf helps you in that case
<george_e> Yeah.
<noodles775> hazmat, m_3 : I just renamed my charm (adding the hyphens back) and retried... it seems the fix is only switching the first hyphen:
<noodles775> 2011-11-22 08:14:18,542 unit:postgresql/7: hook.output ERROR: ERROR:  syntax error at or near "-"
<noodles775> LINE 1: grant all privileges on database apache_django-wsgi to apach...
<noodles775> fwiw, there are a bunch of other errors being reported by the hook, but I've not checked if they're just fall-out: http://paste.ubuntu.com/745665/
 * hazmat yawns
<hazmat> noodles775, huh.. it looks like the bash replace only hit the first string occurence
<noodles775> Yep.
<noodles775> I've removed the hyphens from the charm name, so there's no rush... enjoy your normal morning :-)
<_mup_> Bug #893480 was filed: subordinate services need status support <juju:New> < https://launchpad.net/bugs/893480 >
<fwereade> crikey, hazmat, I presume you're still up rather than already up?
<hazmat> fwereade, aborted sleep attempt
<fwereade> heh, bad luck :(
<noodles775> hazmat: you give up to easily if you're jumping back on irc :P
<hazmat> noodles775, just rallying for another attempt ;-)
<fwereade> hazmat, quick opinion: UpstartService has .install, .start, .destroy
<hazmat> fwereade, +is_running, else sounds reasonable
<hazmat> i can't think of a scenario atm where we'd stop and not destroy
<fwereade> hazmat, appropriate to do everything via deferToThread(subprocess.[whatever_]call), even when there are more convenient ways to do it in python, so that I can always stick a sudo in there (so we get interactive password for local lxc-futzing)
<fwereade> ?
<fwereade> hazmat, there's an is_running too, but that one has no issues :)
<hazmat> fwereade, indeed we need defertothread to maintain the illusion of concurrency in twisted.. the local provider plays this game. and the sudo grab works through the defer to thread
<rog> fwereade, hazmat: mornin'
<fwereade> hazmat, I thought it was the subprocess functions?
<fwereade> heya rog
<rog> not often i see any chat at this hour...
<fwereade> hazmat, well, both, I guess
<hazmat> ie it does subprocess functions in a defer to thread.. see local/agent.py
<hazmat> rog g'morning
<fwereade> hazmat, indeed, that's what I'm suggesting, that we always use that approach
<hazmat> fwereade, sounds good
<fwereade> hazmat, it just gives me a little twinge to shell out to do an os.remove, needed confirmation that it's not totally insane :p
<fwereade> cheers
<hazmat> fwereade, not insane given the need for sudo in some cases
<fwereade> hazmat, good-o
<hazmat> understandable twinge.. but of what ? ;-)
<therve> hazmat, any reason not to use twisted process support?
<hazmat> therve, because its not needed since the signal problems with subprocess where fixed?
<hazmat> afaicr the only delta is some additional closing out of parent fds in the fork
<hazmat> which afacir the subprocess module does as well
<hazmat> therve, short answer.. less twisted, more python
<therve> ok. deferToThread makes me cry a little, that's all :)
<hazmat> therve, longer answer we started with spawnprocess for most of our subprocess usage, but it turns one line calls into whole pages of code.
<therve> hum, weird
<hazmat> we could abstract our process protocol for this to make it easier, but else we where doing a separate one per interaction
<hazmat> therve, re crying is it just the use of a separate thread that concerns, or the whole approach of a  pipe writer back into the reactor?
<therve> hazmat, yeah using a thread, also if stock process support was easier, you wouldn't even think about it.
<therve> getProcessOutputAndValue generally works OK, but I don't know the particular problems here.
<hazmat> therve, oh.. i don't think i knew about that one
 * hazmat wonders if it works with a sudo console grab
<therve> I guess you need a tty for sudo
<hazmat> ah.. its in utils
<therve> so maybe not :)
<fwereade> therve, it's the tty, I had had it just using getProcessOutput and I was happy :)
<m_3> hazmat: btw, ${VAR/-/_} swaps first instance, ${VAR//-/_} swaps _all_ instances
<m_3> noodles775: that change is pushed
<noodles775> Thanks m_3
<m_3> noodles775: are the other hook errors (http://paste.ubuntu.com/745665/) there even when you used a name w/o '-'s?
<noodles775> m_3: yes, they are - although the database connection works. Let me paste the current log.
<m_3> hmmmm
<noodles775> m_3: here's the current log (without the '-' errors): http://paste.ubuntu.com/745749/ , but as above, it seems to be working fine.
<m_3> I'm guessing those're just psql warnings on stderr... lemme see if I can reproduce
<m_3> noodles775: btw, are you good with the pg-v9 builtin replication scheme?  or were you using one of the other pre-9 options?
 * noodles775 hasn't specified any options. I'm just deploying then relating postgresql:db to my app server.
<m_3> ok, there's no repl in the current charm.  I was going to add in the builtin repl now that we're on 9... just checking what would be most useful for you atm
<noodles775> m_3: ah, atm I'm just doing a proof-of-concept charm. But thanks for the thought!
<fwereade> anyone who's around... is there any continuing benefit to using pidfiles, if we're using upstart to manage everything anyway?
<rog> fwereade: not a question i can easily answer, i'm afraid
<fwereade> rog, not to worry, I needn't touch them really; they won't do any harm :)
<Daviey> hazmat: Did you notice https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-juju-roadmap isn't yet drafted?
<hazmat> Daviey, we're still learning the ropes of blueprints as regards the dev process.. we've got a few other blueprints for the individual items in that set, the only actionable thing related to the roadmap is to just publish the roadmap
<Daviey> hazmat: oh groovy.. have you seen the How To?
<Daviey> (the syntax is parsed by http://status.ubuntu.com to track progress through the cycle)
<hazmat> Daviey, i haven't.. i've seen the status tracker, but not so much a how to on the blueprint process as regards the distro usage
<hazmat> ah.. there's a link there of course
<hazmat> Daviey, thanks
<Daviey> https://wiki.ubuntu.com/WorkItemsHowto
<Daviey> superb
<hazmat> fwereade, no benefit to pid files with upstart
<hazmat> Daviey, wrt to pre install on machines, if we do it client side, its pretty straightforward however the user will need to match numbers against the available machines.. which seems a little suspect vs just plugging in and selecting the juju  orchestra when setting up the machine.. i'm game for it either way
<Daviey> hazmat: I wonder if 'both' makes sense?
<hazmat> Daviey, possibly.. standby to juju means powered on, and ready to deploy units to, ie latency on the order of seconds instead of minutes, which would deliver the most benefit, the pre install is bit more helpful without the standby allocation but its useful in either case to cut the allocation time.
<hazmat> i could see a scenario where trying to allocate 10 machines in response to load suddenly hammers the network with the image transfer
<hazmat> which pre-install would avoid
<hazmat> doh
<jcastro> we've got some things marked new-charm that need looking into
<jcastro> https://bugs.launchpad.net/charm/+bug/886362
<_mup_> Bug #886362: New charm proposal: txstatsd <new-charm> <juju Charms Collection:New> < https://launchpad.net/bugs/886362 >
<jcastro> https://bugs.launchpad.net/charm/+bug/886362
<_mup_> Bug #886362: New charm proposal: txstatsd <new-charm> <juju Charms Collection:New> < https://launchpad.net/bugs/886362 >
<jcastro> https://bugs.launchpad.net/charm/+bug/886365
<_mup_> Bug #886365: New charm proposal: graphite <new-charm> <juju Charms Collection:New> < https://launchpad.net/bugs/886365 >
<jcastro> and https://bugs.launchpad.net/charm/+bug/891749
<_mup_> Bug #891749: [charm-needed] ThinkUp <new-charm> <juju Charms Collection:New> < https://launchpad.net/bugs/891749 >
<rog> apparently william has a power cut
<hazmat> rog, ah.. good to know, thanks
<mpl> rog: speaking of that, has your internet connectivity problem been solved?
<rog> mpl: i just got a message from my phone provider saying "your problem has been fixed". we will see - the phone line has been up and down all day.
<mpl> it was fortunate you already knew how use your mobile phone as an alternative. it might have been painfull to figure it all out without connectivity.
<mpl> *how to use
<rog> mpl: yeah, mobile hotspot functionality on android is a godsend
<hazmat> jimbaker, ping
<hazmat> marcoceppi, nice blog post
<marcoceppi> hazmat: thanks!
 * rog always finds it hard to maintain momentum when suddenly... all tests pass.
<rog> do i take out the log messages for tidiness or add more tests and do that later?
<jimbaker> hazmat, hi
 * hazmat wonders why the charm browser isn't showing noodles775 noodle's django charm
<hazmat> noodles775, your missing a file in that charm
<noodles775> hazmat: Originally I just committed what I had and pushed where i could, so I may not have the correct layout.
<hazmat> noodles775, there's no metadata.yaml
<hazmat> at least not pushed, which means juju and the charm browser don't detect it as a charm
<hazmat> noodles775, ah
 * hazmat checks the repo
<noodles775> Yeah, it's there: http://bazaar.launchpad.net/~michael.nelson/charm/oneiric/apache-django-wsgi/trunk/view/head:/oneiric/apache-django-wsgi/metadata.yaml
 * noodles775 checks the charm instructions now.
<hazmat> noodles775, you've got two extraneous sub-directories there.
<noodles775> That would do it.
<hazmat> noodles775, neither oneiric or apache-django-wsgi should be in the actual branch, their implied by the repo name and location
<noodles775> k, I'll remove them and re-push.
<hazmat> noodles775, awesome, thanks
<jrgifford> question:
<jrgifford> is it safe to assume that the juju instance (regardless of if it's ec2) is the only thing running, and you won't have multiple things on the same server?
<jrgifford> (example: having three redmine/phpbb instances on the same juju "guest")
<bcsaller> jrgifford: the default is one unit per machine, you'd have to do something explicit to get other behavior and the hooks to do that are quite limited right now. In the future there will be more control over that.
<bcsaller> jrgifford: we talk about that feature in terms of 'placement'
<jrgifford> so, right now, i only need to think in terms of "there is *one* thing that can run on that guest/unit."
<jrgifford> correct bcsaller?
<bcsaller> jrgifford: yes, though in the future even when that changes it will only be as a result of having lxc everywhere to provide some isolation between units
<jrgifford> bcsaller: ok, thanks.
<jrgifford> that makes this super simple.
<hazmat> even with lxc everywhere, it will appear as though a charm owns the entire machine, except for the case of subordinate/co-located charms which are a little different in usage target
<jrgifford> ok. guess i don't need to go this super convoluted route i was thinking about going...
<jrgifford> (it involved compiling a bunch of stuff to make sure it was flexible)
<hazmat> jimbaker, bcsaller invites out
 * hazmat looks for a stop watch program
<noodles775> hazmat: The branch has been updated, but maybe the directory polls/caches? I don't yet see it, but will check back after dinner.
<m_3> jrgifford: the unit agent makes sure the hooks for a charm are executed serially too, so there's even less to worry about
<bcsaller> hazmat: still there?
<hazmat> bcsaller, indeed, new invite out to you
<m_3> jrgifford: idempotency is the only real issue you gotta worry about
<jrgifford> m_3: gotcha.
<jcastro> https://juju.ubuntu.com/CharmSchool/2December11
<jcastro> I still need 2 volunteer instructors for next Friday's Charm school
<jrgifford> jcastro: tentatively, i'm in.
<jrgifford> need to finish this charm first though.
<jrgifford> since otherwise, i won't have anything to teach on. :)
<jcastro> I was going to go with an experienced charmer for the first one to teach
<jrgifford> ok, that makes more sense.
<jcastro> basically I want this one to prep you guys up with what you need.
<jcastro> kind of solidify a core base
<jcastro> then grow from there
<jcastro> SpamapS: m_3: still need 2 volunteer instructors for the first charm school next friday *cough* *cough*
<jcastro> I'll run the thing, just need people to answer questions
<m_3> jcastro: I'll be there... just thought you wanted newer charm authors to lead off
<jcastro> for this first one let's just concentrate on getting everyone in the right place at the right time
<jcastro> we'll do introductions
<jcastro> talk about the new charms people are working on
<jcastro> and then like, they can just Q+A you for a bit
<jcastro> by next friday these guys should be pretty comfortable, that will just leave us with nagging hard questions.
<jcastro> jrgifford: and then I'll put you on the hook to run the next one?
<m_3> jcastro: sounds greate
<m_3> s/e//
<jcastro> ok, m_3 alright so it'll be me and you next friday, and anyone else on juju core who happens to be around in IRC and talks will get automatically roped in. :)
<m_3> jcastro: is that in #ubuntu-classroom or #juju?
<m_3> jcastro: nevermind, you said #juju in email
<jcastro> I think we should do it here
<jcastro> it will bring people into the channel
<m_3> yup
<jcastro> and hopefully encourage them to idle
<rog> i've been sporadically trying to resubmit a merge proposal (to change its target) but keep on getting timeouts from launchpad. is it something i'm doing, or is it launchpad flakiness currently?
<james_w> rog, I have a vague recollection that there is a timeout bug for that case on occaision
<james_w> if there's nothing of interest in the one you are trying to resubmit then you could delete and re-propose
<rog> james_w: there are a few comments that i don't want to lose
<james_w> rog, I was thinking of a timeout on registering
<james_w> rog, do you have an oops id from your timeouts?
<rog> james_w: yeah:  OOPS-c942fd1ba80db6e59400b027d15aa31c)
<james_w> rog, though are you trying to resubmit against a branch that isn't the "development focus"?
<rog> james_w: what does that mean?
<james_w> a development focus branch is anything that has a "short name"
<james_w> like lp:juju lp:juju/something
<james_w> if you are trying to propose against lp:~someone/juju/something-else then it may be the bug I was thinking of
<rog> james_w: the branch target was not originally against the development focus
<rog> james_w: that's why i'm resubmitting
<james_w> then it may be https://bugs.launchpad.net/launchpad/+bug/793830
<_mup_> Bug #793830: Branch:+register-merge time out due to substring matching many tables <critical-analysis> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/793830 >
<rog> my mouse pointer is jiggling - anyone else get that?
<rog> oh well, i'll delete and create again
<rog> do deleted merge requests remain around so i can point a URL at one (so the old comments aren't lost)
<rog> ?
<james_w> I don't think so
<rog> oh well.
<james_w> if you wait a couple more minutes we should be able to see the OOPS and that may give a clue as to a workaround
<rog> james_w: where do OOPSs end up?
<james_w> https://lp-oops.canonical.com/?oopsid=c942fd1ba80db6e59400b027d15aa31c
<rog> one mo, need to suspend to stop my mouse wiggling
<rog> james_w: how long does it usually take?
<rog> (that oops was probably an hour ago)
<james_w> oh, ok
<james_w> seems it has disappeared then
<james_w> I think it's up to 10 minutes usually
<rog> james_w: thanks for your help. i've got to leave now. will try again tomorrow.
<james_w> ok
<rog> see y'all tomorrow
<rog> ttfn
<hazmat> mcclurmc, greetings.. how goes the xen provider?
<hazmat> er. xcp
<mcclurmc> hi hazmat
<mcclurmc> it goes
<mcclurmc> it's currently my spare-spare time project, unfortunately
<mcclurmc> i created a spec though, and i think i made you the approver
<mcclurmc> is this okay?
<hazmat> mcclurmc, sounds good, if you have any questions.. this is the place to ask..
<mcclurmc> i've got a few questions, but they're not fully formed
<mcclurmc> i'm going to try to find some time tonight to work on the filestorage implementation, so i might be back here
<hazmat> mcclurmc, sounds good
<jrgifford> jcastro: sounds good.
<fwereade> hazmat, is there any point at all in specifying pidfiles for upstart services?
<hazmat> fwereade, none
<hazmat> fwereade, welcome back.. i think you disconnected on the answer earlier
<fwereade> hazmat, good-o, we can delete some code :)
<hazmat> fwereade, lots ;-)
<fwereade> hazmat, probably did, sorry about that
<hazmat> fwereade, no worries, rog mentioned you had power issues
<fwereade> hazmat, yeah, it happens every now and then
<jcastro> so SpamapS
<hazmat> so jcastro ;-)
 * hazmat wants for some more packaging automation
<hazmat> we haz the power
<jcastro> what do you mean?
<jcastro> actually I was just going to mail the list about charm snippets, we haz the power
<jcastro> hazmat: what's on your mind?
<hazmat> jcastro, just ruminating over the power of a simple site that you upload a tarball or a url + tarball of deb and it packages it for you
<jcastro> I believe james_w is working on exactly that sort of thing
<hazmat> i wantz it
<james_w> we are
<hazmat> james_w, awesome
<hazmat> james_w, url ? ;-)
<james_w> http://developer.ubuntu.com/2011/11/automatic-packaging-progress/
 * m_3 loves it when a plan comes together
<hazmat> hmm. pkgme is for simple CMMI (configure/make/make install) style single source single pkg systems, aka the 95%.. which is indeed awesome
<hazmat> i have  single source multi-package tarball with existing deb dir
<hazmat> anyone interested ? ;-) http://labs.omniti.com/labs/reconnoiter
<hazmat> its already packaged.. i was just thinking it would be nice if it could auto ppa for me.. http://labs.omniti.com/labs/reconnoiter/browser/pkg/debian
<hazmat> er.. not upstream but the packaging work is done
<james_w> it's pretty easy to automate packaging something with a deb dir :-)
<hazmat> james_w, true that
<james_w> does that packaged code live in a VCS somewhere public?
<hazmat> james_w, indeed its a public svn
<james_w> ah, sorry, looked at the link now
<james_w> then you want recipes
<hazmat> er.. git
<hazmat> git clone git://github.com/omniti-labs/reconnoiter.git
<james_w> import reconnoiter to LP bzr
<james_w> and import than git repo too
<james_w> then combine them with a recipe and set it to build every day
<james_w> then you'll have a fresh PPA package every day (if there is new code to package)
<hazmat> ic.. so basically follow on https://help.launchpad.net/Packaging/SourceBuilds/Recipes
<james_w> yeah, with a bit of https://help.launchpad.net/Code/Imports thrown in to get the code in to Launchpad
<james_w> recipes are easier than the length of that page would suggest
<hazmat> james_w, if that src pkg namespace (ie. upstream) is already owned on lp, i guess i need to email the current owner to give access?
<james_w> shouldn't do
<james_w> https://code.launchpad.net/~thombot/reconnoiter/trunk is an import of the main code so that takes care of that part
<hazmat> hmm.. already a src import
<hazmat> so just need a recipe that skips nest for mv
<james_w> nest-part will do that
<hazmat> james_w, well its got a failed build i assume because of the nest part
<hazmat> ie. there's already a recipe
<james_w> oh
<james_w> didn't see the recipe
<hazmat> https://code.launchpad.net/~dsci-admins/+recipe/reconnoiter-daily
<james_w> ah
<james_w> interesting
<james_w> trying to nest from itself
<jcastro> I love "accidentally" finding recipes
<hazmat> james_w, yeah.. just reading through this bug report against the same sort of usage of nest-part https://bugs.launchpad.net/bzr-builder/+bug/771568
<_mup_> Bug #771568: nest-part unable to nest files <udd> <bzr-builder:Confirmed> <Launchpad itself:Triaged> < https://launchpad.net/bugs/771568 >
<hazmat> seems like it should just do a mv
<hazmat> jcastro, re charm snippets, what about a gist/pastebin setup?
<jcastro> what, contribute your snippet, then we just have a list of URLs?
<hazmat> jcastro, with description, search, comments, tags, ratings
<jcastro> ok so how would that work
<jcastro> let's say I have a snippet.
<jcastro> I put it in pastebin
<jcastro> then ... ?
<marcoceppi> I'm in favor of gist's because you can fork gists
<hazmat> you'd add a description of what your snippet does publish it to the a snippet repo, other folks could discover it via search, comment on it, and rate it
<marcoceppi> How do your other examples work? I don't think I've ever used them
<hazmat> marcoceppi, ?
<hazmat> marcoceppi, you mean the example formulas?
<m_3> might need to be a little more involved though... templating, local config storage, etc... was thinking language-specific charmutils deployed on each unit.  but I really like the simplicity of gists/pastes
<hazmat> the examples dir is a repo
<marcoceppi> hazmat jcastro put up a few packages as examples, one for bash and one for python
<hazmat> m_3, in that context, well the question is the purpose to share knowledge or multi-file arbitrary language code
<marcoceppi> Oh, nevermind, I see what those are now
<hazmat> gist/pastes with comments/ratings can share knowledge and discovery via search
<hazmat> libraries share code
<m_3> hazmat: I'd be leaning more towards sharing code... it's really boilerplate as far as knowledge goes
<m_3> we should include examples in the list
<m_3> love the gist/pastebin approach though... I'm not clear on the lines between the different uses
<jcastro> yeah so the thing is
<m_3> definitely a problem... charmers start copying scripts from one charm to the next
<jcastro> "I need to get foo and do bar to it", here you go dude, here's the pastebin. If it's basically like another store but for snippets .... too complicated?
<marcoceppi> What about if snippets get updated?
<marcoceppi> or would these just be "use at your own risk brooooo"
<jcastro> can you update gists?
<jcastro> so the url doesn't change?
<marcoceppi> jcastro: Not really, it creates a fork to it, IIRC
<marcoceppi> jk, you can
<marcoceppi> https://gist.github.com/1387034
<marcoceppi> Even tracks revision history
<m_3> hazmat: BTW, reconnoiter is building in my ppa if you just want a one-off package to charm with (https://launchpad.net/~mark-mims/+archive/ppa/+packages)... I'll let you know when it finishes
<hazmat> m_3, score! ;-)
<m_3> jcastro: and forks https://gist.github.com/1336585
<jcastro> ok so this seems pretty lightweight to me
<m_3> hazmat: dunno if it'll build, but we'll see
<m_3> jcastro: quite lightweight, but that can be a good thing... perhaps this is two different requirements
<hazmat> m_3, i'm hopeful
<jcastro> m_3: lightweight wins here I think, they're just snippets
<marcoceppi> +1
<james_w> if it does build then https://code.launchpad.net/~james-w/+recipe/reconnoiter-daily will do it daily
<hazmat> the problem with gists is discovery
<james_w> bzr saves the day
<hazmat> james_w, awesome
<jcastro> hazmat: so, if we're going for some lightweight ones, why not just a wiki page with the common ones?
<jcastro> also, sabfl just responded on the list, so it will definately not be me recommending using something from github. :p
<m_3> james_w: thanks, I'll try that out... I haven't played with recipes yet... just sort of plugged reconnoiter(sp?) into the debuild process that I've been scared to leave cause it works!
<hazmat> jcastro, good question
<m_3> jcastro: wiki => manual process == evil ( or really, just out of date)
<marcoceppi> Wiki pages kind of suck at managing code snippets?
<jcastro> not for the snippets themselves
<jcastro> I mean as a link to snippets, but mark has a point about the manualness
<jcastro> oh dude, I got it.
<m_3> charm-store extension
<m_3> :)
<jcastro> http://pad.ubuntu.com/marco-charm
<jcastro> and then the index becomes: http://pad.ubuntu.com/ep/search?query=charm-snippet
<marcoceppi> not a bad idea
<hazmat> except there is no pad search
<marcoceppi> Seems to maintain formatting OK
<jcastro> marcoceppi: right expect you'd make another one, one for each snippet
<hazmat> going back to a wiki page... assuming good formatting tools and embedded discussion (disqus).. is it problematic?
<jcastro> and tag it with #charm-snippet
<hazmat> i guess i shouldn't assume the current wiki site for juju
<marcoceppi> jcastro: yeah, I was just testing the formatting
<m_3> wiki'd work
<jcastro> ok so wiki is fine
<jcastro> other than no one who doesn't work for canonical can't write to it yet.
<m_3> we'll need cli and vim plugins a la pastebinit
<m_3> s/need/want/
<jcastro> man, bummer about the search on etherpad
<jcastro> that is almost what we want.
<m_3> hazmat: reconnoiter isn't scheduled to build for another 7hrs (amd64) and 11hrs (i386)... I'm guessing they're still playing with perl or something on the buildds
<hazmat> m_3, no worries, i've been down the buildd road b4 by hand, its a waiting game
#juju 2011-11-23
<SpamapS> m_3: yeah buildd's are pretty busy leading up to alpha1 on Dec 1
<SpamapS> m_3: I'm about to make them even more busy as soon as mysql 5.5 finishes building...
<SpamapS> found another non-deterministic test that will likely have to be disabled. :-P
<marcoceppi> So, I started a small collection of bash functions for this charm-helper idea. Any requests?
<SpamapS> marcoceppi: one that always returns an IP from a hostname or IP that is passed to it
<tazz> hmm so i came across juju right now, dosnt puppet+mcollective solve the same problem ?
<noodles775> tazz: I'm just a user of juju - so best to wait for one of the juju team to answer, but my impression is that mcollective helps you manage servers and clusters of servers, where as juju is about managing services and their relationships.
<noodles775> (meant to say, I've only read docs of mcollective - it's not my area)
<tazz> right...
<noodles775> tazz: there are probably better demo's of juju around, but I created a demo yesterday from an experiment which highlights the service-orientation:
<noodles775> http://micknelson.wordpress.com/2011/11/22/a-generic-juju-charm-for-django-apps/
<hazmat> james_w, success! re reconnoiter pkgs
<hazmat> james_w, hm... actually i'm a little confused, the src pkg gens 3 bin pkgs but i only see one pkg in the ppa
<hazmat> hmm.. actually that doesn't look like it actually built correctly, false success
<hazmat> fwereade_, could you have a look at this trivial.. https://code.launchpad.net/~hazmat/juju/preserve-unit-for-external-gc/+merge/82413
<fwereade_> hazmat, sure
<hazmat> fwereade_, thanks
<fwereade_> hazmat, I'm a bit wary of this given that there isn't actually any GC
<marcoceppi> SpamapS: What about hostnames with more than one ip?
<hazmat> fwereade_, we already have a need for gc
<hazmat> fwereade_, its been assumed, ie if there's a state conflict at any point we have a need for gc, because there is a leftover state
<hazmat> fwereade_, we use the topology to sync/commit changes for multi node ops
<fwereade_> hazmat, ok, so the motivation is that we're already leaving stale crap in ZK, and we need a general solution for that, but this fixes an unrelated problem and doens't make the GC problem significantly worse?
<hazmat> fwereade_, exactly
<fwereade_> hazmat, ok, I'm happy
<hazmat> fwereade_, say for example we go to create a service state, and we get a topology conflict, we end up leaving a stale service state
<fwereade_> hazmat, yep, I've noticed an instance or two of that sort of thing
<hazmat> i know there's a bug already for it..
<fwereade_> hazmat, cool
 * hazmat wishes lp would search comments
<rog> hazmat: that's interesting. could you explain how that happens?
<rog> (leaving a stale service state, that is)
<hazmat> rog, sure
<hazmat> rog, so say two clients go to create a service named 'mysql' concurrently, they'll first create a service state, which is done against with a sequence node in the /services container, and both succeed, then both go to modify the topology, only one will succeed, the other will get a statechanged error
<hazmat> but that will leave a stale/unused service state
<rog> hazmat: can't the one that failed remove its own (stale) service state?
<hazmat> rog, or take debug-log which currently uses zk as a storage mechanism.. those records are effectively dead after debug-log is terminated
<hazmat> rog, its a simplification of a general problem, yes in some cases the ops could clean up after state
<hazmat> rog, the general form though is a multi-node operation, that is 'committed' after topology state modification, the op may span apis and service states
<rog> isn't debug-log a slightly different problem?
<hazmat> rog, both generate zk nodes that need gc
<hazmat> although the latter is indeed different since an ideal solution is to not use zk
<rog> and it seems to me that the debug-log garbage isn't generated as a result of conflict either?
<hazmat> rog, effectively we would need either rollback operations per mod, multi-node transactions, or gc
<hazmat> the former is a rather large code burden, the second is viable though also at some cost of rearchitecting,  the gc solution here is quite simple and the garbage cost neglible
<rog> is the multi-node operation always initiated by a single client?
<hazmat> rog, there's care taken such that the same multi-node op can be concurrent with predicatable results
<hazmat> ie. either complete success or state changed error
<hazmat> with errors not effecting the consideration of live changes
<rog> hazmat: i think i'm trying to ask if nodes created by more than one client can be invalidated by a single topology commit.
<rog> by "the former" you mean getting the client to remove its own garbage after commit failure?
<hazmat> rog i'm not sure i understand the question, a single commit either adds or removes nodes, either can invalidate other concurrent operations
<hazmat> although only the add conflict scenario would leave state to be gc'd
<hazmat> and the b) multi-node transaction capabilities are only exposed as of zk 3.4
<rog> i was just wondering if the "remove your own garbage" option was generally viable
<rog> of course, you'd need a GC anyway in case the connection failed halfway through, leaving the garbage around.
<hazmat> rog, indeed i did mean the post clean up of every state mod api having a parallel cleanup api is rather a large code burden
<hazmat> rog, indeed
<rog> hazmat: how common is conflict anyway?
<rog> hazmat: i'd guess it is currently vanishingly rare, but perhaps people will start doing more concurrent topology mods in the future
<hazmat> rog, at the moment extremely rare, its more that the system was designed for concurrency, in practice we don't really have it outside of someone using the cli programmatically
<hazmat> there are lots of tests around concurrent changes in the code base
<rog> hazmat: so GC is more of an academic argument for the time being
<hazmat> rog, absolutely
<rog> hazmat: and i'd guess the node sizes are pretty small, so the amount of garbage even in bad cases will be fairly smal
<rog> l
<hazmat> rog, its actually a non problem for the most part.. for large installs, the biggest issue is going to be node size limitations around topology
<hazmat> which we can alleviate for 10k nodes + via compression
<rog> hazmat: i was about to suggest that
<hazmat> rog, its potentially an issue for large and long lived installations over time, all zk nodes are effectively held in ram
<hazmat> but the per garbage overhead is on the order a few hundred bytes
<hazmat> the gc algorithm and impl is also pretty trivial
<rog> maybe just a way to manually initiate GC would be sufficient
<hazmat> yeah.. or just another agent or fold into an existing privileged one (provisioning i suppose)
<rog> another very simple agent seems fine. sleep for a day, have a look, GC as necessary, repeat
<rog> but i guess provisioning is already doing a kind of GC by examining running nodes and squaring that with desired topology
<rog> hazmat: anyway, thanks, that's been useful
<hazmat> rog, indeed it is, though that's a different sort of gc.. resource gc, vs state
<hazmat> rog, did you ever review go-new-revisions.. https://code.launchpad.net/~niemeyer/juju/go-new-revisions/+merge/78728
<hazmat> ah.. i guess so
<rog> i'm not sure gustavo saw my response
<hazmat> rog, hmm.. yeah. not sure.. i just pushed into the approved queue, he'll look at it prior to merge
<hazmat> rog,  wrt to https://code.launchpad.net/~rogpeppe/juju/go-juju-initial-ec2/+merge/82669  it doesn't appear that the changes that address william's comments have been pushed
<rog> hmm, i thought i had
<hazmat> rog, nevermind.. i see the issue now.. its an entirely new review
<hazmat> not linked to the old review
<rog> hazmat: yeah, and i actually have to create another one too, as it has the wrong target
<rog> and i can't do resubmit because of an lp bug
<rog> sigh
<hazmat> rog, yeah.. i was just noticing that
<hazmat> its odd
<hazmat> i don't even see the resubmit link
<hazmat> rog, did that get submitted with lbox propose -cr ?
<rog> hazmat: yes. i'm not sure the heuristics for determining branch target are quite there yet
<rog> hazmat: actually, i think i'd merged go-error-fixes into my trunk and then pushed.
<rog> hazmat: so probably the trunk remembered the wrong target
<rog> hmm
<rog> problem is you can't specify an explicit lp: target - you have to specify the disk location of a branch, but then the lp: target is implicit
<hazmat> fwereade_, one more review request, could you have a look at either of jim's branches in the queue, i'll ask bcsaller to look at the other
<hazmat> so close to an empty queue ;-)
<fwereade_> hazmat, sure
<rog> i still haven't worked out how to deal with the proliferation of bzr branches in a sane way
<fwereade_> hazmat, expose-refactor?
<hazmat> fwereade_, which ever you prefer
<hazmat> fwereade_, expose refactor is pretty straightforward its mostly a code transplant
<hazmat> rog, you mean you prefer the hg/git many branches in one dir?
<hazmat> rog, there are bzr plugins to emulate that (bzr-colo)
<fwereade_> hazmat, well then, I'll take a look at the other one, sounds a bit more interesting :)
<rog> hazmat: i don't know. i never worked with many branches before, in one dir or not.
<hazmat> rog, but else that's pretty bot standard vcs using feature branches
<hazmat> s/bot/bog
<rog> i think i get confused by the fact that there are (at least) three independently varying things about a branch: the uncommitted changes; the target; and the currently committed version.
<rog> BTW james_w said the timeout bug may be this one: https://bugs.launchpad.net/launchpad/+bug/793830
<_mup_> Bug #793830: Branch:+register-merge time out due to substring matching many tables <critical-analysis> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/793830 >
 * hazmat finishes xapian indexing all the juju bugs
<hazmat> rog, i've only see lp issues for merges a  handful of times, but they are annoying.. in this case i don't even see the link so i can't trigger the resubmit, except via url surgery
<rog> hazmat: maybe only the author of a proposal can resubmit it
<rog> i don't really see why you can't just edit the target
<hazmat> rog, no i can resubmit other proposals normally
<rog> i get this link: https://code.launchpad.net/~rogpeppe/juju/go-juju-initial-ec2/+merge/82669/+resubmit
<rog> yeah, i still get the same time out
<rog> yay! i made a new proposal and it kept the comments around anyway.
<SpamapS> marcoceppi: for multiple IPs, randomly choose one
<marcoceppi> SpamapS: cool
<marcoceppi> I'll push these up in a bit for feedback, I don't want to get too deep
<SpamapS> marcoceppi: technically your resolver should be randomizing multiple-IP's .. so you could probably just return the first one.
<SpamapS> marcoceppi: are these bash functions that you have already used in multiple charms?
<marcoceppi> SpamapS: Two were, the IP one I just made
<marcoceppi> I retooled them though, to be more generic
<SpamapS> marcoceppi: I can make use of the IP one in the ceph charm
<marcoceppi> cppl
<marcoceppi> cool* I'll start weeding through charms in the store to see what other functions I can abstract
<marcoceppi> then I'll just write the equivalent functions in Python
<SpamapS> ehh
<marcoceppi> ruby, php, etc
<SpamapS> wait wait wait
<marcoceppi> waiting
<SpamapS> Lets not reinvent configuration management. :)
<marcoceppi> oh?
<SpamapS> The idea is to take stuff that we can clearly see has been copy/pasted between charms, and put it into charm-helper
<marcoceppi> ah
<SpamapS> Not to build a new config management solution. :)
<SpamapS> I mean
<SpamapS> go ahead if you really want to!
<SpamapS> But it could get really big, really fast, and I'd like to make sure it stays focused on things that "many" charms can use, not just a few. :)
<marcoceppi> aye
<marcoceppi> I tend to jump ahead rather quickly :)
<SpamapS> really?
<SpamapS> hadn't noticed
<SpamapS> +1!
<SpamapS> (I tend to overuse the !)
<jcastro> marcoceppi: hey does the think up charm work for you?
<jcastro> I get that relationship error I put in the bug
<marcoceppi> jcastro: It worked for me, there's a warning with charm proof but that warning is going away in the next build
<marcoceppi> Let me find the bug...
<jcastro> I wonder if I just hit "lxc weirdness"
<jcastro> marcoceppi: do you have time to give the charm a review today? I figure with both you and mmims checking it we should be good
<marcoceppi> yeah, it deployed fine - but I didn't get a chance to look into the code yesterday
<jcastro> nice nice!
<jcastro> I think they had problems with their ec2 launcher.
<jcastro> I can't find it on their site anymore.
<marcoceppi> jcastro: room for Juju to rule!
<jcastro> this will be nice for them. :)
<SpamapS> We should add charm bugs to the bot
<marcoceppi> jcastro: https://bugs.launchpad.net/charm-tools/+bug/893363
<_mup_> Bug #893363: charm proof should not warn on a relation without hooks <Juju Charm Tools:Triaged> < https://launchpad.net/bugs/893363 >
<jcastro> @marcoceppi  when you investigate adding AU questions to the bots in IRC, see if we can get for example juju tagged questions mentioned by the bot in here.
<jcastro> that would be jawesome.
<jcastro> <--- off to lunch
<jcastro> SpamapS: if mims pops in before I get back can you poke him to review the thinkup charm?
<jcastro> I'm dying to get with upstream on this one
<SpamapS> jcastro: mmkay
<m_3> hey... here... just in a meeting on another channel
<m_3> yesterday george was going to go off and add in postfix... I'll check status of the charm in a bit
<_mup_> Bug #894060 was filed: cannot restart unit agent (no unit workflow restart transition) <juju:In Progress by fwereade> < https://launchpad.net/bugs/894060 >
<marcoceppi> jcastro et al: where is the bot's code?
<SpamapS> m_3: I was thinking about that.. if the local charm just needs to send mail.. ssmtp would be one option
<m_3> SpamapS: I think it's gotta receive too... account validation
<m_3> not sure though... didn't get that far with george
<m_3> if it's just send it's a _much_ simpler dep
<SpamapS> oh that can be much more difficult
<SpamapS> domains.. mx's.. meh meh meh
<m_3> SpamapS: phracking nightmare
<m_3> staying off of blacklists is the hardest part
<SpamapS> on ec2 most IPs get blacklisted pretty fast from what I understand.
<SpamapS> which is why they have the email api
<mainerror> jcastro: That would be amazing! I have the juju and charms tag set as mail subscription.
<fwereade_> hazmat, jimbaker, bcsaller: standup?
<hazmat> fwereade_, indeed
<hazmat> jimbaker, bcsaller, fwereade_ invites out
<mainerror> The juju documentation could use a common errors section, possibly linked to Ask Ubuntu questions with an answer to given problem or error.
<jimbaker> just saw the notice re standup, sounds good
<m_3> hazmat: build was missing libprotobuf-c... I'm adding an explicit dep to the control file and trying again.
<hazmat> fwereade_, bcsaller woot! new record 5m32s
<fwereade_> go us!
<marcoceppi> So, this is what I've got so far for charm-helper lp:~marcoceppi/charm/oneiric/charm-helper/trunk
<marcoceppi> I couldn't think of a better place to push it to
<hazmat> m_3, if it succeeds would you mind moving it into a dedicated ppa
<hazmat> m_3, i'm always nervous grabbing stuff from ppas with unrelated packages
<marcoceppi> er: https://code.launchpad.net/~marcoceppi/charm/oneiric/charm-helper/trunk
<jimbaker> hazmat, looks like i saw the closing end of the standup. better sync next time
<m_3> hazmat: sure thang
<hazmat> i ended up using an html 5 timer.. couldnt find a decent app in the repos.. for a count down timer.. http://helvetimer.com/
<hazmat> jimbaker, yeah.. trying to keep them short and sweet and on the dot.. wasn't much to miss
<jimbaker> hazmat, sounds like a good plan. i'm definitely up for on the dot, for the next one on monday
<jimbaker> i'm making good progress on the ssh key mgmt is my standup report
<hazmat> jimbaker, cool
 * jcastro returns from chow
<jcastro> hey m_3
<jcastro> he updated the charm
<jcastro> and is doing the first thing you mentioned, wrt. debconfig postfix
<rog> in bzr, is there a way i can change a bogus message on an old commit? (i presume not, but you never know...)
<hazmat> rog, no
<m_3> jcastro: cool, I'll do a review
<hazmat> rog, bzr has immutable history view, bzr rebase is the extent of playing with it that i'm aware of
<rog> hazmat: darn. a few days ago i ran commit in the wrong directory... i knew i'd run it *somewhere* (because i had to commit again) but i've only just discovered where...
<hazmat> er. bzr rewrite plugin
<hazmat> rog, IFF you haven't pushed it yet, you can uncommit
<hazmat> but you have to wind down the stack
<rog> hazmat: i've three commits sitting on top of it...
<hazmat> rog you could try.. bzr uncommit, bzr shelve --all -n "top"... if its really important.. alternatively you can commit the inverse diff on that dir
<rog> i guess i theoretically i could encode each delta as a patch, then wind it forwards using the patches.
<hazmat> rog, ie bzr diff -r -2..-3 | patch -p0
<marcoceppi> m_3: The charm doesn't check thinkup.zip against any hash, since it's a git repository - would it be better to just have it get cloned instead?
<m_3> marcoceppi: no difference from a security-standpoint I think
<jcastro> hazmat: hey does cs:charmname work yet?
<jcastro> when deploying?
<marcoceppi> m_3 couldn't you do a host fingerprint validation since git would clone via SSH?
<marcoceppi> The fingerprint is far less likely to change compared to the hash of a tarbal
<m_3> marcoceppi: yes, if you're going over ssh... maybe something similar when cloning over ssl
<m_3> haven't looked at what the git client does with an ssl url... i.e., does it at least verify the cert's ok?
<marcoceppi> I don't know, let me check
<SpamapS> marcoceppi: files fetched over ssh with a static key counts as cryptographically verified.
<SpamapS> m_3: most cmdline tools seem to ignore PKI and just accept any old cert
<marcoceppi> SpamapS: Cool, too bad Github doesn't have anonymous SSH Read access
<m_3> SpamapS: ok
 * m_3 looking at what the actual charm is doing now
<SpamapS> marcoceppi: the alternative is to embed the zip file in the charm, and verify it by hand.
<SpamapS> Oo
<SpamapS> you know.. charm get/charm getall should really verify the charms
<SpamapS> I mean, we already talk to launchpad w/ https..
<SpamapS> and/or ssh
<SpamapS> so I guess its not that critical
<m_3> marcoceppi: do you have a snippet of hash-verification of a payload?
<marcoceppi> Yeah
<marcoceppi> m_3: It's wrapped into "get_file" http://bazaar.launchpad.net/~marcoceppi/charm/oneiric/charm-helper/trunk/view/head:/net.sh
<m_3> gracias!
<hazmat> jcastro, no the charmstore is not operational yet
<jcastro> hazmat: is there a tracking bug for that I can follow along with?
<hazmat> jcastro, https://blueprints.launchpad.net/juju/+spec/formula-store
<jcastro> ta
<mainerror> Alright. Quick question. In my weird logic, when both of my services, in this case mediawiki and mysql have the status running and have a working relation then I should be able to reach the mediawiki instance using it's public IP address. Right?
<jcastro> juju expose wordpress
<jcastro> sorry, I mean mediawiki
<jcastro> you need to explicitly expose the service to the outside world
<mainerror> oh god
<mainerror> How did I miss that? lol
<mainerror> Thanks. :D
<jcastro> hey, what did it return after you inputted that?
<mainerror> 2011-11-23 18:59:16,982 INFO Service 'mediawiki' was exposed.
<mainerror> 2011-11-23 18:59:16,985 INFO 'expose' command finished successfully
<mainerror> mhm
<mainerror> I should probably mention that I'm running it off a local provider.
<mainerror> What is funny is that the public address I get is not on the same subnet.
<marcoceppi> mainerror: It's probably for the virtual network interface created on your local machine
<jcastro> yeah
<mainerror> Oh.
<SpamapS> mainerror: yeah it should be 192.168.122.xx ..
<mainerror> Indeed.
<jcastro> "Service 'mediawiki' was exposed on 192.168.122.xxx" would be way more useful, I hate having to go back in my status and find the right IP
 * jcastro goes to file a bug
 * mainerror will confirm the bug!
<SpamapS> +1 from me too, should be easy
<mainerror> So basically I have no way to access my mediawiki instance?
<_mup_> Bug #894094 was filed: "juju expose" should tell me exactly where a service is exposed. <juju:New> < https://launchpad.net/bugs/894094 >
<marcoceppi> m_3: SpamapS it appears git uses curl and does validate SSL certificates
<m_3> mainerror, you should be able to open 192.168.122.xx (whatever status tells you) in a browser and see mediawiki
<marcoceppi> However, couldn't someone still perform a man-in-the-middle attack even through SSL?
<mainerror> Should I go ahead and confirm that bug?
<mainerror> Never mind. :)
<mainerror> Mhm, I can't access my mediawiki instance.
<m_3> mainerror: 'juju -elocal status' should show an address associated with the mediawiki unit... (also if it's started or not)
<jimbaker>  zookeeper 3.4.0 was just released
<jcastro> m_3: ok, so I can get to thinkup, everything worked once I did the :db thing
<mainerror> m_3: The address I get is 192.168.122.80, my subnet is 192.168.0.x.
<jcastro> m_3: and according to the machine log it sent the mail, just waiting for it now, then I'll bang on the service a bit.
<mainerror> Status is up, started and exposed.
<mainerror> I mean state, relation state and exposed state respectively.
<m_3> mainerror: nice, ok... when you open 192.168.122.80 in a browser?
<mainerror> It times out after some time.
<m_3> if that's no good, then 'ping -c4 192.168.122.80'
<mainerror> 100% packet loss.
<m_3> what does 'juju ssh mediawiki/0' give you?
<mainerror> The machine juju runs on is a VirtualBox instance of Ubuntu 11.10 Server with a bridged interface.
<m_3> ah, thanks...
<m_3> are you running the cli from the virtualbox instance?
<mainerror> Yes.
<mainerror> Well I'm connected to the VB instance via SSH.
<m_3> understood
<jimbaker> jcastro, re bug 894094, i'm not certain if that's meaningful or not without the status. services are exposed, not individual machines, so potentially this could mean a large list. also it's possible that any corresponding ports have not yet been opened by the charm
<m_3> so I haven't seen juju local run on a bridged physical interface... it's always been a virtual bridge
<_mup_> Bug #894094: "juju expose" should tell me exactly where a service is exposed. <juju:Confirmed> < https://launchpad.net/bugs/894094 >
<hazmat> mainerror, the wordpress instance is only accessible to the local machine
<jcastro> marcoceppi: aha, that's why I got the thinkup error, the hook isn't idempotent, but it looks like m_3 caught that in the review
<hazmat> mainerror, you'd have to route the bridge on the local machine to make it accessible to other machines on the net
<mainerror> mhmm, I'll try lynx on that IP from the VB instance.
<hazmat> mainerror, its mainly intended as a development tool for well local development
<m_3> mainerror: from your VirtualBox instance (hereafter deemed "host")... you should see a libvirt std network setup... virbr, dnsmasq, etc
<mainerror> So basically I should run juju on my machine directly or on a normal desktop install on the VM.
<m_3> ah, right... you can also forward a port... something like 'ssh -L8888:192.168.122.80:80 VirtualBoxAddress' from your base machine
<mainerror> hmm, that sounds like a good plan.
<m_3> but should be able to tell pretty quickly from the cli... 'curl 192.168.122.80' or something similar
<mainerror> Whoops! Alright. I've just tried lynx on that IP.
<mainerror> Got a 500 Server error from mediawiki.
<mainerror> But it is deployed. :)
<m_3> nice!
<mainerror> Alright. Here is what I'll do next. I'll just install juju directly on my machine and work from there. :D
<mainerror> Less complexity.
<m_3> mainerror: yeah, that's probably the best plan
<m_3> it doesn't bite
<mainerror> Indeed.
<m_3> I typically work in VMs as much as possible myself, but lxc runs fine as long as you're setup is happy with libvirt networking
<m_3> s/you're/your/ :)
 * m_3 food
<mainerror> I don't have any kind of special setup so in theory there should be no problem.
<mainerror> Thanks for your help! :)
<marcoceppi> jcastro: Cool, good to know
<hazmat> hmm.. would be nice to get a vpn charm to make that scenario a little easier
<jcastro> somoeone on my blog had an awesome charm idea
<jcastro> an ubuntu mirror charm
<jcastro> "run this on an m1.large, then pay your bill."
<SpamapS> Hmm..
<SpamapS> does that person know that Ubuntu maintains full mirrors in EC2 already?
<SpamapS> in every availability zone
<jcastro> well, for internal reasons
<jcastro> though, I suppose with orchestra you wouldn't really need that
<SpamapS> It would actually be really cool for orchestra
<SpamapS> most places want a local mirror that they can control
<jcastro> right
<jcastro> and
<jcastro> ubumirror is packaged
<jcastro> it really just needs to be installed and run
 * jcastro pencils himself in for this one since it's simple
<SpamapS> juju set local-mirror releases="lucid precise"
<jcastro> I will finish my Alice IRC today
<SpamapS> Alice the IRC bot?
<jcastro> web hosted irc
<jcastro> I saw people asking for a ZNC service for work
<jcastro> I am like, forget that, I want a web client
<SpamapS> Oh.. there used to be an IRC bot that was slightly smarter than a tic-tac called Alice
<mainerror> There is also that creepy server (AI control) of the Umbrella Corporation hive that was called Alice. That creepy little girl.
<mainerror> We definitely don't need a Charm for her!
<jcastro> https://www.usealice.org/
<marcoceppi> jcastro: So it's irccloud but I host it?
<mainerror> irccloud is awesome!
<marcoceppi> Where is the charm-tools package?
<m_3> marcoceppi: https://code.launchpad.net/charm-tools
<jcastro> marcoceppi: yeah, I like it better than irccloud actually
<marcoceppi> m_3: Thanks!
<SpamapS> marcoceppi: do you like that idea, to put the helpers in charm-tools?
<SpamapS> marcoceppi: I figure it makes sense .. they're quite related
<marcoceppi> I'm fine with that. Does charm-tools get pulled into the environment at all on deploy?
<marcoceppi> SpamapS: What I mean is, will we still have to copy/paste these functions out or is there a way we can have them float in the env?
<SpamapS> no, but we'll make these separate packages from charm-tools
<SpamapS> They'll jus thave to be part of the install hook.
<SpamapS> apt-get install charm-helper-sh
<marcoceppi> ah, right gotchya
<marcoceppi> Yeah, good idea about the namepsaceing too
<SpamapS> marcoceppi: I'd suggest branching charm-tools, and submitting a merge proposal. I'll review ASAP
<marcoceppi> SpamapS: Yeah, that's what I'm doing now
<jcastro> m_3: hypothetically, what kind of charm would use db-admin?
<marcoceppi> phpmyadmin maybe?
<mainerror> phpPgAdmin for PostgreSQL
<jcastro> ah ok, now that's obvious to me
<SpamapS> jcastro: I believe cloudfoundry also needs root
<SpamapS> jcastro: since it has to create multi-tenant databases.. it pretty much pwns the box
 * jcastro nods
<jcastro> SpamapS: I don't like that I have to care when executing
<jcastro> I'd rather have db be the default
<jcastro> and for the services that need that stuff then explicitly mention that
<jcastro> but I don't feel strongly enough about it to complain
<jcastro> other than to you I mean. :)
<SpamapS> jcastro: one could argue that db-admin is a different interface
<jcastro> I more mean default to one interface
<SpamapS> jcastro: since db gives you just one database...
<jcastro> "most charms will use db so be lazy here"
<m_3> jcastro: I think it's just a problem because mysql is so common in our examples
<jcastro> yeah
<jcastro> it's just I cringe every time our deploy command adds length
<m_3> but yeah, maybe worth splitting into a separate relation
<marcoceppi> SpamapS: In regards to add-relationship, shouldn't juju see that the charm has no db-admin interface requirement and only show the ambiguity message when it's ambiguious?
 * mainerror nods
<m_3> sorry, I mean split into a separate interfaces
<jcastro> SpamapS: so basically my complaint is that makes "juju deploy cs:mysql" longer than it needs to be ...
<SpamapS> marcoceppi: they're both interface: mysql
<marcoceppi> Err, the db-admin relationship
<SpamapS> I think its actually a bug in the mysql charm
<SpamapS> we should fix it
<SpamapS> make it interface: mysql-root
<marcoceppi> Ah, I see. Good alternative
<SpamapS> I don't see any downside to that
<SpamapS> things either need root, or they don't
<m_3> +1
 * SpamapS feels like the Charm Ceaser today.. "MAKE IT SO!, and bring me WINE!!"
 * SpamapS wanders off to find food
 * marcoceppi wanders off to find wine
<jcastro> SpamapS: ok I'll file that badboy
<marcoceppi> So, what's the safest License for this charm-helper? MIT?
<mainerror> WTFPL. :D
<mainerror> It does really exist, no joke. .P
<marcoceppi> I googled just to be sure
<jcastro> hazmat: hey before I file a bug humor me for a second
 * hazmat laughs @ jcastro
<jcastro> hazmat: so at UDS I saw juan's .juju dir, he had a bunch of environment.yamls
 * hazmat nods
<jcastro> and would symlink what he wants to use
<jcastro> how about a convenience switch function
<jcastro> like:
<hazmat> jcastro, -e
<jcastro> son of a ....
<mainerror> :D
<jcastro> hazmat: how long has that been there?
<jcastro> you know what, don't tell me
<mainerror> hehe
<marcoceppi> jcastro: I thought you showed me that? Maybe it was m_3. I've got two environments in my file, EC2 and local
<hazmat> jcastro, that allows picking from multiple envs in a single file, you can set a default: ${env-name} label in the file to set a default one (sans -e usage).. the multiple file thing is useful for demos to avoid showing your passwords on screen.
<jcastro> aaaaaah.
<SpamapS> marcoceppi: GPLv3 is what charm-tools is under.. simpler if you just keep it all charm-tools. *using* something is not *linking* to it.
<marcoceppi> SpamapS: Thanks, easy enough
<SpamapS> hmm
<SpamapS> the python bit may actually be linking if we do it
<SpamapS> so LGPL might be more appropriate for that
<SpamapS> but, we'll cross that bridge when we come to it.
<marcoceppi> fair enough
<marcoceppi> I really wish I could figure this Ondina name thing out
<marcoceppi> on LaunchPad, any idea where I could start to diagnose this?
<jcastro> what, your display name?
<marcoceppi> Yeah, I made sure whoami and launchpad login both go to marcoceppi account, but it keeps showing Ondina as the name
<james_w> marcoceppi, it's because the ondina team has marco@ondina.co set as the contact address
<james_w> and that's the address that you are committing the revisions in bzr as I expect
<marcoceppi> james_w: So? My commits come from marco@ceppi.net
<james_w> i.e. what bzr whoami says
<james_w> oh, hmm
<marcoceppi> Marco Ceppi <marco@ceppi.net>
<james_w> sounds like a Launchpad bug then
<jcastro> m_3: SpamapS: http://dl.dropbox.com/u/5720/Screenshot%20at%202011-11-23%2017%3A21%3A00.png
<jcastro> we should try to do an office hours in a hangout
<marcoceppi> james_w: Probably, I'm checking it out in the launchpad room
<m_3> I like the iphone icon on there
<hazmat> jcastro, what's the benefit of the hangout in this context/
<m_3> jcastro: maybe let's see how irc goes first?
<jcastro> m_3: yeah I was keeping an eye on it
<jcastro> hazmat: more personal, high bandwidth for explaining concepts, etc.
<mainerror> Oh that is Reto. :)
<marcoceppi> SpamapS Seems odd, I probably shouldn't put a copyright on the net.sh charm helper, right?
<SpamapS> marcoceppi: it should have a license/copyright header in the file
<marcoceppi> this is what I have now
<SpamapS> marcoceppi: push to a branch?
<marcoceppi> http://paste.ubuntu.com/747686/
<marcoceppi> I don't want to stain the commit with a bad header :)
<marcoceppi> Still really green when it comes to how licenses and copyrights work
<SpamapS> marcoceppi: that header looks a little off, where did you get it?
<marcoceppi> The internet: http://stackoverflow.com/q/153489/196832
<SpamapS> http://www.gnu.org/licenses/gpl-howto.html
<SpamapS> marcoceppi: heh, you just forgot the spacing. ;)
<marcoceppi> Spacing is important?
<SpamapS> For my eyes it is.. because otherwise I read every word and go "wtf? this SOUNDS ok" ..
<SpamapS> :)
<marcoceppi> So http://paste.ubuntu.com/747700/ ?
#juju 2011-11-24
<SpamapS> marcoceppi: put your email address (the more precise, the better), but yes, otherwise good.
<m_3> aren't we ok with a copyright for the whole charm-tools project applying to the whole thing?
<SpamapS> m_3: IMO no. Put a header on every file. Especially files full of code that people will be tempted to copy/paste into their charms. ;)
<m_3> gotcha, yeah if they're gonna be real snippets
<SpamapS> m_3: the more explicit one is about their licensing, the less they have to deal with it later on.
<m_3> cool
<SpamapS> ambiguity is the enemy of license due dilligence. ;)
<marcoceppi> SpamapS: Thanks! pushed up
<SpamapS> marcoceppi: looks good. :)
<marcoceppi> awesome
<SpamapS> marcoceppi: so, if you wanted to get your feet wet on packaging.. lp:~charmers/charm-tools/packaging
<marcoceppi> SpamapS: <3 wet feet
<SpamapS> marcoceppi: the idea would be to add a charm-helpers-sh to debian/control ...
<SpamapS> (ignore everything outside of debian/ in that branch)
<marcoceppi> I'll take a look and branch
<SpamapS> marcoceppi: and then a charm-tools-sh.install file which puts the files in /usr/lib/charm-helpers/sh
<SpamapS> actually
<SpamapS> they should be in /usr/share/charm-helpers/sh
<SpamapS> /usr/lib should only have binaries
<marcoceppi> how do I get the file into the environment?
<SpamapS> like, in your charm?
<SpamapS> . /usr/share/charm-helpers/sh/net.sh
<marcoceppi> Sure, for instance.
<marcoceppi> Would I need to source it
<marcoceppi> ah, k
<SpamapS> simplest way
<_mup_> Bug #894362 was filed: orchestra launch failure can "lose" machines <juju:In Progress by fwereade> < https://launchpad.net/bugs/894362 >
<rog> fwereade_: if you want a distraction for a bit: https://codereview.appspot.com/5433056/
<fwereade_> cheers rog
<rog> fwereade_: unfortunately the diffs include the diffs from the previous merge request which only changed the error type
<fwereade_> rog: don't worry about it :)
<rog> fwereade_: it's an interesting thing though that i hadn't previously - merge requests are submitted against a moving target...
<rog> s/ously/ously appreciated/
<fwereade_> rog: yeah, I find that the regular merge-test-pushes become a bit tedious when I have more than two or 3 branches pending
<rog> fwereade_: i can see why some people choose a more linear model
<fwereade_> rog, I feel like I've adapted quite well, and am content
<fwereade_> rog, it's only really something I notice when i have multiple branches out
<rog> fwereade_: cool. i'm aiming for that state of mind :-)
<fwereade_> rog, otherwise when I'm working it's just a regular work-merge-work-merge-work-merge thing and it fades into the mental background
<rog> fwereade_: that's easier when reviews are timely, i guess
<fwereade_> rog, well, maybe wok-merge-work-merge-work-merge-dammit,conflict-fiddle-fiddle
<fwereade_> rog, definitely
<rog> anyone know of a way to change a repo's default push location without actually using push?
<therve> rog, you can set something for your branch in the locations.conf?
<rog> therve: do you mean branch.conf?
<rog> therve: if that's the definitive source for the info, that's a good idea, thanks.
<therve> I meant ~/.bazaar/locations.conf, but branch.conf sounds good too :)
<rog> therve: hmm, except it's stored there in full URL form rather than short lp:... form. i wonder if it'll work anyway.
<hazmat> rog, its worthwhile looking up the docs for location.conf, it has lots of options.. appendpath is the most useful, you can set for the parent directory and your subdirs (branches) all pickup the appropriate push path
<rog> hazmat: i'll have a look, but it's only for a branch temporarily created by a script, so maybe not appropriate in this case.
<hazmat> rog, its worth looking/setting up regardless of an individual branch
 * hazmat wanders off to enjoy the holiday
<rog> hazmat: useful, yes, but in this case branch.conf is what i needed.
<rog> fwereade_: next review in stack: https://codereview.appspot.com/5431067/
<fwereade_> rog, cheers again
<rog> oh bugger, it's got two prerequisites
<fwereade_> rog, sorry, I've been finding it a bit tricky to engage with reviewing today
<rog> fwereade_: that's fine, it's just a FYI
<fwereade_> rog, ha, I find it very irritating that multiple prereqs aren't handled by lp
<rog> fwereade_: i couldn't push without a nod from gustavo anyway
<rog> fwereade_: aren't they?
<fwereade_> rog not that I'm aware of
<fwereade_> rog, if C depends on B depends on A, fine
<fwereade_> if C depends on both A and B I don't think that can be expressed
<rog> ah, so i see. oh well, i won't have to start yet again then
<rog> yeah, this review relies on two parallel changes to two different repositories
<rog> s/review/merge request/
<rog> i'll just put it in the comments
<fwereade_> rog, I found making sure the branch with the bigger diff-from-trunk was the one marked as the prereq was helpful to people
<rog> hmm, let me see
<rog> the diffs come to 980 vs 1257 lines respectively. i've chosen the wrong one, but it's probably not too bad.
<rog> is there some definitive documentation on cloudinit somewhere? this only seems to give some examples: https://help.ubuntu.com/community/CloudInit
<george_e> jcastro: Please, oh please be here...
<george_e> I ran into some problems polishing up my ThinkUp charm.
<SpamapS> george_e: anything I can help with?
<SpamapS> rog: the package puts some good stuff in /usr/share/doc/cloud-init.. I think
<rog> SpamapS: i'd looked at that. nothing like definitive docs there.
<george_e> SpamapS: Possibly - I am writing a charm for ThinkUp and I have a question about config. data.
<rog> i ended up going through the source codee
<SpamapS> george_e: fire away.. :)
<george_e> If in config.yaml I do not specify a default value for a particular option, what is the value of that option when I look it up with 'config-get'?
<SpamapS> rog: I think the best docs are just the example cloud config yaml
<SpamapS> george_e: I believe its ""
<SpamapS> george_e: as in, empty
<george_e> Okay, thanks.
<george_e> I was just wondering about that.
<SpamapS> george_e: best to always specify a default though. :)
<SpamapS> I think we talked about making some values required, which would mean you couldn't deploy the charm, and there was a lot of resistance to that idea.
<george_e> Well, not in this case: it's for a username and password and email address :)
<george_e> All the other options have defaults though.
<rog> SpamapS: i just went through cloudinit/CloudConfig/cc_*.py and looked for occurrences of "cfg"
<rog> SpamapS: which gave a pretty good idea of what fields there are and what types are expected
<rog> (which is what i wanted to know, as i was making a Go package for generating cloud-init config)
<rog> off to bed.
<SpamapS> george_e: in the past I've used the empty string in the yaml file as the explicit default, and acted accordingly. :)
<george_e> So just "default:" will suffice?
<SpamapS> george_e: I did  default: ""
<george_e> With quotes? Does that work?
<SpamapS> yes it is type: string
<george_e> Okay, thanks.
<george_e> SpamapS: Does config-get return the same data in each hook?
<george_e> For example, can I access the DB config data in the config-changed hook?
<SpamapS> george_e: relation-get is only available in *-relation-* hooks
<SpamapS> george_e: config-get is always available
<george_e> Oh right.
<george_e> Okay, thanks.
#juju 2011-11-25
<george_e> SpamapS: Can I put another script in the hooks folder that isn't actually a hook script?
<george_e> I want to reuse some code between hooks.
<james_w> george_e, you can
<james_w> your hooks are executed with the PWD being the root of your branch
<james_w> so you can load the code with
<james_w> . ./hooks/shared
<james_w> (assuming you are using shell)
<george_e> james_w: Okay, thanks.
<fwereade> hazmat: ONLY if this is an easy question you already know the answer to without hunting through the source (I can do that myself if necessary...):
<fwereade> hazmat: what nodes are created by the unit agent?
<hazmat> fwereade, its presence node its relation settings and presence nodes
<fwereade> hazmat, cheers
<fwereade> hazmat, I'll double-check which of those could have barfed a NodeExists at me, but haven't managed to repro it, so not to worry :)
<hazmat> fwereade, i've got a branch which pushes the path into the exception of txzk.. i haven't felt a 100% comfortable with it.. but its useful for debugging these sorts of things
<hazmat> fwereade, its https://code.launchpad.net/~hazmat/txzookeeper/errors-with-path/+merge/77254
<fwereade> hazmat, thanks, that's awesome; I'll grab it if I screw things up in the same way again :)
<jcastro> m_3: thinkup charm needs another round o' review
<hazmat> m_3, thanks again for setting up the reconnoiter ppa
<fwereade> hazmat, I appear to be unable to recreate the unit agent presence node when the unit was previously "kill -9"ed (NodeExistsException, despite the fact that it was created ephemeral)
<fwereade> hazmat, please confirm that I am smoking crack
<hazmat> fwereade, the session is still alive
<hazmat> fwereade, the agent need to store their session id, and reconnect with that only creating a new session if the previous is expired
<fwereade> hazmat, awesome, the universe still works, I'm just ignorant
 * fwereade sighs with relief
<hazmat> fwereade, we all gotta start somewhere.. for example if you put a sleep(10) in there it would just work ;-)
<hazmat> fwereade, so i'd setup the base agent to store the client_id after connect to file on disk, and utilize that path if it exists when connecting for the session id
<hazmat> if it doesn't work (sessionexpired) just reconnect sans the id
<fwereade> hazmat, cool, on the plus side the unit agent does appear to work if it's killed normally :)
<hazmat> fwereade, nice
<hazmat> fwereade, yeah.. i was going through the workflow api.. you had it right.. transition_state is optimistic, fire_transition was pessimisitc
<fwereade> hazmat, cool, that bit is changing a little in the current work anyway
<hazmat> fwereade, what's current? which branch is this?
<hazmat> fwereade, ie. are these changes to what's in the queue?
<fwereade> hazmat, it's work on top of it, I probably should have written a bug for it
<hazmat> fwereade, no worries, lbox makes us lazy ;-)
<fwereade> hazmat, it's the distinction between "uses upstart" and "actually works properly in certain circumstances"
<hazmat> fwereade, cool, i'm going to delay the session expiration work to build on the upstart stuff your doing, else we have to introduce additional primitives regarding stop/restart doing hook execution, vs stopping activity
<fwereade> hazmat, yeah, figuring out just what should happen if we suddenly die mid-hook is beyond my understanding at the moment
<hazmat> just doing a suicide on expiration seems like it would be easier than introducing additional paths for stop 'only activity'
<fwereade> hazmat, that sounds good though
<hazmat> fwereade, that's fine, when we save the queue state to disk, it should re-execute the hook
<hazmat> fwereade, we're going for the at least once guarantee
<fwereade> hazmat, cool
<hazmat> instead of the at most once
<hazmat> the latter has the potent to miss an exec
 * hazmat grabs some coffee
<marcoceppi> Hey guys, any idea on this: http://askubuntu.com/questions/82632/juju-bootstrap-problem
<hazmat> marcoceppi, in process on answering it now
<hazmat> marcoceppi, hmm.. actually that's not what i thought it was
<marcoceppi> Anything I can ask him to get more info>
<hazmat> marcoceppi, not sure, i posted something, it looks like he might have another dns server on that machine
<hazmat> perhaps a local caching proxy
<marcoceppi> ah, thanks hazmat
<hazmat> marcoceppi, i thought i'd setup a subscription to juju questions, but i don't every seem to get notified about new questions
<marcoceppi> hazmat How did you subscribe?
<hazmat> marcoceppi, via the web on the tag
<marcoceppi> Ah, that only highlights questions in the main feed, IIRC
<marcoceppi> hum, maybe not.
<hazmat> marcoceppi, i don't get it.. it doesn't notify me of all new questions w/ the tag.. that question is in the rss feed
<hazmat> marcoceppi, hmm.. seems like there are multiple interfaces for subscription management..
<hazmat> trying out the stackexchange one from my profile now
<marcoceppi> hazmat Check out your profile's email preferences, make sure the checkbox to receive emails is selected. http://askubuntu.com/users/preferences/28532
<marcoceppi> It doesn't appear you do. Kind of seems like a bug.
<marcoceppi> You can also change the frequency of emails. It defaults to a daily digest, IIRC
<hazmat> marcoceppi, that seems to me the trick thanks
<hazmat> s/me/be
<marcoceppi> np
<amithkk> Nice cozy juju room :) Hi guys
<hazmat> amithkk, greetings
<amithkk> hi hazmat
<hazmat> bcsaller, jimbaker you guys in today?
 * SpamapS tosses amithkk a beverage
<SpamapS> welcome!
<hazmat> fwereade, up for a standup?
<hazmat> bcsaller, jimbaker, fwereade invites out.. low attendance expected ;-)
<amithkk> hi
<fwereade> hazmat, ah yeah
 * amithkk drinks beverage
 * SpamapS cries out "NO WAIT!"
<mainerror> What is a standup?
<hazmat> mainerror, its a very short meeting
<mainerror> I see.
<hazmat> mainerror, we just do a quick roundtable on dev tasks
<hazmat> less than 5m
<hazmat> mainerror, http://en.wikipedia.org/wiki/Stand-up_meeting
<m_3> looks like the latest charm-tools package has a broken link...  I'll try it on another machine to verify
<hazmat> m_3, is that reconnoiter ppa a daily build recipe attached to the imported branch?
<hazmat> m_3, looking at the imported branch recipes.. i just see https://code.launchpad.net/reconnoiter/+recipes
<m_3> SpamapS: but if he knew that you knew that he knew which vial was poisoned...
<m_3> no, I didn't use the recipe, just built the daily from the other day
<m_3> hazmat: ^
<m_3> hazmat: figured if it worked, then we could use the recipe to do a daily build.  I had to update debian/control to add deps to get it to build, so we'll have to add that to the recipe
<fwereade> happy weekends all :)
<hazmat> fwereade, cheers, have a good one
<m_3> fwereade: you too
<hazmat> m_3, cool we should probably send a control diff upstream as well, it was just the protobuf dep?
<m_3> yup
<hazmat> m_3, cool
 * hazmat lunches
<jcastro> hazmat: bout how much longer after a charm is accepted does it take to show up in your charm browser thing?
<hazmat> jcastro, 15m after its pushed to lp
<hazmat> jcastro, it won't appear if the charm has structural errors
<hazmat> jcastro, which one where you thinking of?
<jcastro> thinkup
<hazmat> jcastro, thinkup is there already
<jcastro> ROCK.
<hazmat> jcastro, its in a ppa, so you need to find via search
<hazmat> unless its in the official distrib
<hazmat> http://charms.kapilt.com/~george-edison55/oneiric/thinkup
<jcastro> right so in the bug report mmims +1'ed it, I guess the next step is to 'promote' it or whatever we do?
<jcastro> but then he found a bug in the charm tool or something
<hazmat> jcastro, yup
<hazmat> jcastro, per the spec its actually posisble for a ppa charm to be the official one, but the charm browser and practice seems to be moving it to ~charmers ownership
<jcastro> oh ok, so basically we move it
<jcastro> and then tell him to just propose fixes from then on?
<marcoceppi> it needs to be promogulated, right?
<rog> can we rely on the fact that we've always got cloud-init? or can that be provider-dependent?
<marcoceppi> promulgated*
<rog> hazmat: ^
<hazmat> rog, we use cloud-init everywhere but local provider
<hazmat> rog, bcsaller and i  debated using it there, but opted to pass on it to keep local fast
<jcastro> we suck for naming it "promulgate" by the way, when "charm bless" or "charm sugar" would have been awesomer.
<hazmat> jcastro, or just give him r/w access to it
<hazmat> marcoceppi, i think m_3 and SpamapS know the procedure.. i'd have to look it up
<rog> hazmat: darn. ok, thanks.
<marcoceppi> hazmat: I've done it once before if they're pre-occupied
<hazmat> rog, why? whats up?
<m_3> yeah, I can promulgate... just chasing down what's wrong with charm-tools
<hazmat> rog, its generally a pretty reasonable assumption
<hazmat> m_3, need another set of eyes?
<rog> hazmat: just wondering what code can be factored out of providers
<m_3> also didn't know if acceptance meant it should be promulgated to lp:charm or stay in a ppa
<rog> hazmat: in Go the decision has to be a bit more clear-cut than in python.
<hazmat> rog, well the cloud init stuff is factored out of the provider implementations, individual provider implementations will by default get a common impl of the provider that uses cloud-init
<jcastro> m_3: what's the difference from the deployment point of view of where the charm is?
<m_3> hazmat: I'm still trying to figure out how the packaging process works for charm-tools... the latest version just isn't installing enough stuff
<jcastro> m_3: either way I need to charm get right?
<rog> hazmat: yeah, i saw that, but hadn't seen that local didn't use the common implementation
<hazmat> jcastro, yeah.. charms are always fetched locally, even with a store
<m_3> jcastro: yeah, it'll just be a different url
<hazmat> er. deployed from local
<jcastro> ok so from the end user perspective, they don't need to do anything different?
<hazmat> the store just automates the fetch to local and deploy to env
<jcastro> in other words, is this our problem or a user-visible problem?
<hazmat> rog, it does use the base class, it just overrides that behavior
<hazmat> by implementing its own start machine method
<m_3> jcastro: so that's the difference... right now 'charm get thinkup' says it doesn't exist in the official charm store
<hazmat> rog, the local provider is a bit of abberation in several respects, besides the lack of cloud-init, there is no provisioning agent
<m_3> so I'll promulgate it
<hazmat> rog, in the local provider case there is only one machine the host
<hazmat> so cloud init never runs, we treat the containers as containers instead of machines
<hazmat> the notion being that if where a new machine, we would indeed run cloud-init
<rog> hazmat: yeah, it's an exception that seems like to be making things a bit harder, cos it makes everything less regular
<hazmat> rog, it is actually pretty regular the delta is that its an environment with exactly one machine
<rog> hazmat: it's things like no provisioning agent, etc
<hazmat> rog, and that we have multiple units with isolation on it.. the original impl that SpamapS did had modeled containers as machines
<hazmat> rog, there is only one machine in the env, so what does the provisioning agent do?
<rog> hazmat: was that too slow?
<hazmat> rog, no just that niemeyer didn't like the model that way
<rog> hazmat: i'd model containers as machines...
<rog> hazmat: fair enough
<hazmat> rog, there was a long discussion on list about this
<hazmat> rog, the problems with networking still haven't been addressed unfortunately
<rog> hazmat: depends how you think of the local provider, i guess - as a test for the system, or as a thing to do useful work with
<hazmat> wrt to pushing lxc everywhere
<hazmat> rog, the goal of getting lxc everywhere is better served by the current impl (machines deploying units in containers), but lacking an appros solution for the networking, its a bit moot
<rog> for LXC everywhere, i guess it'd make sense to treat containers as machines and have a provider on every real machine
<hazmat> rog, not really
<hazmat> rog, providers model real billable resources, container ares not
<hazmat> s/ares/are
<rog> oops
<rog> i didn't mean provider, i meant provisioning agent
<rog> totally different thing
<hazmat> rog, same thing, providers are actualized by a provisioning agent
<hazmat> there is no provider api for creating a container, the provider is abstraction to external resource interaction
<rog> interesting.
<hazmat> for the provisioning of compute resources, lxc are are just logical subdivisions of those resources imposed by juju for units
<rog> if there *was* a provider api for creating a container, might that make things easier?
<rog> because then creating a container would be very similar to allocating a new machine
<rog> once you've got multiple levels of provider, spanning across multiple billable providers might become easier. but i'm speaking off the top of my head here, obviously :-)
<rog> hazmat: what are the problems with the networking, BTW?
<hazmat> rog, i don't think a container provider api helps at all, its a different level of the conceptual stack
<hazmat> rog, your trying to posit the provider agent living on every machine.. why thats what the machine agent is there for
<hazmat> rog, the networking problem is what i outlined on the mailing list, namely that because we're using dynamic port allocation for units, which itself is a less than 0.1% problem, instead of static port allocation in metadata, we  lose the ability at deploy time to determine conflict/optimal placement of units when machines have multiple units
<marcoceppi> What is the "peers" metadata config section for?
<rog> i guess in the end, it doesn't matter what agent does provisioning, just as long as it follows the right zk state
<hazmat> meaning that we can never have more than one unit on a machine without a soft network overlay
<hazmat> marcoceppi, its for a special type of relation used to talk within a service among its service units.. like cassandra, or riak, mongodb replica set..
<hazmat> the units of those services need to be aware of the other members of the service and to talk to them, for things like setting up token rings for sharding or replication, or leader election
<hazmat> rog, indeed
<marcoceppi> hazmat: Cool, thanks
<rog> hazmat: i wondered about peer relations as well. how exactly do they differ from provides/requires relations?
<hazmat> rog, provides/requires are to model client/server relations across services, peers model intra service relations
<hazmat> inter vs intra service relations.. for the one liner ;-)
<rog> hazmat: so a peer relation is always established?
<hazmat> rog, it is, but that's a convenience of the deploy cli impl, the rel impl is the same at the declaration and actualization layer as a client/server.. the main impl difference is in the watch mechanism feeding into hook execution
<rog> hazmat: is hook execution any different for peer relations?
<hazmat> rog, no
<hazmat> rog, the structural layout of the relation is  slightly different leading to slightly different related unit watching, instead of watching the units of the opposite end's service, it watches the units of the same service.. that feeds into a hook scheduler, which queues hook exec, the actual hook impl/semantics are the same
<rog> hazmat: thanks
<hazmat> i think i wrote most of that in a mad crazy code cycle this time last year
<rog> hazmat: it's all in the machine agent, presumably
<hazmat> rog, not at all
<hazmat> rog, the machine agent has no responsibilities outside of deploying units
<hazmat> and removing them if unassigned from the machine
<rog> hazmat: ah, i thought the machine agent executed hooks
<hazmat> rog, the unit agent does all unit management
<hazmat> rog, most of this is abstracted into a unit workflow/lifecycle that the unit agent just starts
<rog> hazmat: so it does, i've just seen
<rog> hazmat: hmm, so... is there one machine agent per machine?
<hazmat> rog, yes
<rog> hazmat: but currently a machine maps exactly one to one with a unit, right? so what does the machine agent actually do?
 * rog should just go and read the damn code!
<rog> ok, yes, it doesn't do much
<hazmat> rog, none of the agents do very much, they activate semantic logic protocols in their process, but the agent code is always pretty minimal
<hazmat> rog, the provisioning agent has been an exception to that, but not for long (expose-refactor pushes the firewall stuff out)
<hazmat> rog, at the risk of repeat myself... machine agents only manage unit deployments
<hazmat> their not one to one with a local provider
<hazmat> their only one to one elsewhere due to the network issues as above, either a soft overlay network or static ports would resolve that
<rog> i'd vote for static ports, otherwise you get addressing issues.
<hazmat> yeah.. me too
<hazmat> encapsulating units into lxc everywhere also solves the issue of the charm scribbling on a machine's root fs which makes machine reuse problematic
<rog> gotta go
<rog> thanks for the discussion
<hazmat> rog, cheers have a good weekend
<rog> and you
<jcastro> james_w: fyi, your graphite and txstatsd charms got an initial review
<james_w> yeah, thanks
<james_w> important fixes needed, I just need to find the time now
<jcastro> m_3: AWWW YEAH
<jcastro> thinkup is working
<jcastro> http://pad.ubuntu.com/thinkup
<jcastro> are the commands I used.
<m_3> jcastro: phpmyadmin is reported as blocked BTW
<m_3> awesome!!
<m_3> ^ re: thinkup
<jcastro> http://cloud.ubuntu.com/2011/11/deploying-thinkup-to-the-cloud-with-juju/
<m_3> jcastro: gotta do a charm get mysql too
<m_3> (in the article you reference above)
<jcastro> whoops!
<SpamapS> charm-tools should be fixed shortly btw
<m_3> SpamapS: thanks!
<marcoceppi> SpamapS I hope it wasn't anything I did
<SpamapS> no
<SpamapS> definitely me
<SpamapS> rushing things before throwing the turkey in the oven yesterday ;)
<SpamapS> can you guys try updating charm-tools on 11.10?
<SpamapS> m_3: ^^
<SpamapS> marcoceppi: ^^
<marcoceppi> Has it been packaged?
<SpamapS> it just updated
 * marcoceppi wishes he can edit messages in IRC
<SpamapS> the PPA claims it is published
<marcoceppi> Looks like it: 0.2+bzr85-4~oneiric1
<m_3> SpamapS: will check now
<m_3> SpamapS: look fine
<SpamapS> m_3: cool. thanks for the heads up
<m_3> thanks for not making me learn about recipes tonight :)
<marcoceppi> What are the restrictions of names for charms? Just alphas?
<hazmat> marcoceppi, alpha num not leading alpha, and '-'
<hazmat> er. leading alpha
<marcoceppi> thanks
#juju 2011-11-26
<mrskanko> Hi guys
<mrskanko> some one can help me
<mrskanko> with juju?
<mrskanko> i can't boostrap it!
<mrskanko> no body can help me?
<mrskanko> i'll try tomorrow
<mrskanko> nite
#juju 2011-11-27
<mrskanko> hi
<mrskanko> i need a help with juju
<mainerror> Hello mrskanko.
<mainerror> What is the problem?
<mrskanko> i'm using Juju on openstack
<mrskanko> i have configured the environment
<mrskanko> but when i bootstrapping it
<mrskanko> and i do juju status
<mrskanko> i received a SSH ERROR
<mrskanko> and i can't connect to the machine
<mrskanko> but if i run in terminal ssh - i ubuntu@boostraped_machine
<mrskanko> it run correctly
<mrskanko> have you understood?
<mainerror> Oh right, didn't see that yet. Sorry
<mainerror> Phew. I have no idea, sorry. I'm sure someone will get back to you as soon as he reads this tough.
<mrskanko> don't worry
<mrskanko> thank you
<mrskanko> What juju.control package contains?
<rog> hey
<rog> anyone around, by any chance?
<rog> i can't quite work out how in the bootstrap process the zookeeper daemon actually gets run.
<rog> i can see how the zookeeperd package gets installed, and how the initial zk hierarchy is created, but can't find the actual exec of zookeeperd
<rog> it's something in juju/providers/common/cloudinit.py that i'm missing, i'm sure
<rog> why i'm doing this on a sunday night, i'm not quite sure :-)
<TheMue> rog: hehe, not a good time to get support
<TheMue> rog: i'll start to dig deeper next week. right now first reedings in the wiki
<rog> TheMue: first reedings?
<rog> TheMue: have you started yet?
<TheMue> rog: eh, reading
<TheMue> rog: no, i'll start on thursday
<rog> TheMue: cool! looking forward to working with you.
<TheMue> rog: yep, me too. and listening to your music. *smile*
<TheMue> rog: i think we'll meet in budapest
<rog> TheMue: wonderful.
<hazmat> rog, ping
<hazmat> rog, the zk instance is started as a consequence of installing the pkg
<hazmat> that's fairly common for daemon packages
<rog> hazmat: thanks, that's useful
<rog> hazmat: i thought the packages were just the equivalent of apt-get packages
<rog> which don't run anything... i think. right?
<rog> if the packages passed to cloud-init aren't apt-get packages, what are they?
<hazmat> rog, they are apt-get packages
<hazmat> rog, daemon packages will install upstart files that can start the relevant software
<hazmat> rog, ie if you apt-get install nginx or apache, it will actually start the daemon
<hazmat> a daemon package is just a semantic distinction i'm making on what software is being installed
<rog> hazmat: i never realised that apt-get stuff could actually run the programs you're installing
<rog> wow
<TheMue> doesn't they just install the scripts in /etc/init.d and set the links in rc0.d to rcS.d?
<TheMue> so everything is starting fine with the next boot and additionally the first time directly by apt?
<hazmat> TheMue, indeed that's one way.. the newer way is to use upstart
<hazmat> which does an inotify listen on the files in its dir and executes new ones
<hazmat> it also monitors the the rcX.d dirs
<hazmat> TheMue, http://upstart.ubuntu.com/
<hazmat> SpamapS, looks like that sites need a new news item re the new releases
<hazmat> SpamapS, actualy the downloads there don't correspond at all to the ones in the distro
<hazmat> 1.3 vs 0.6.x
<TheMue> hazmat: ah, will take a look at it
<hazmat> TheMue, welcome aboard ;-)
<TheMue> hazmat: thx, i really appreciate it
<SpamapS> hazmat: upstream upstart is not like ubuntu upstart
<SpamapS> hazmat: though I believe the delta is quite small as of 1.3
#juju 2013-11-18
<Luca__> jamespage: Hi there, I am trying to set up openstack using bundles and/or reducing # of required jobs. I know you are working on openstack's charms, could you provide any update on your progresses?
<AskUbuntu> Can Juju cannot services that are in different environments? | http://askubuntu.com/q/378679
<AskUbuntu> Swift - No ring is created when deployed using juju. attached is output of 'swift-init start main' on swift-proxy node | http://askubuntu.com/q/378774
<InformatiQ> hey guys I'm new to juju and a bit confused about the difference between deploy and add-unit
<InformatiQ> could some one kindly explain
<noodles775> jamespage or adam_g : If you've time, I've got a patch for what seems to be a bug in the swift-proxy charm when using essex, attached to bug 1251551
<_mup_> Bug #1251551: Essex + Keystone deploy broken <swift-proxy (Juju Charms Collection):New> <https://launchpad.net/bugs/1251551>
<jamespage> hey noodles775
<noodles775> Hi james :)
 * jamespage looks
<noodles775> InformatiQ: `juju deploy` is for deploying a new service (and by default, it'll create a single unit for that service). add-unit can then be used to add extra units to that existing service. This blogpost shows a simple example: http://smartbridge.com/blog/use-juju-to-deploy-and-scale-wordpress-in-the-cloud/
<InformatiQ> noodles775: thanks for the answer, so a deploy is creating the configuration and the required instances to run those, then add-unit just does the same but it would not as for configs and just clone the already deployed service
<InformatiQ> noodles775: is that correct
<InformatiQ> noodles775: also in that blog post, adding a worpress unit does not mean it will actually load balance or anything, i will then need to add a load balancer service to handle the actual scaling
<jamespage> noodles775, nice work on the template unit testing - I like that
 * jamespage had been pondering how todo that best
<noodles775> InformatiQ: So yes, deploy tells juju about the service and sets up some configuration that is re-used by subsequent units. And yes, the blogpost doesn't include a load balancer. As an example of how simple that is, see "How to deploy the charm" on the haproxy charm at: https://jujucharms.com/fullscreen/search/precise/haproxy-21/#bws-readme
<jamespage> luca__, hey - you had a question on openstack bundles?
<noodles775> jamespage: Great - yes, I was unsure how to test the changes - I was happy to find that the choice loader just worked in those tests :)
<jamespage> noodles775, I made a few tweaks to how the tests get executed; we have a pattern that we have used across the other openstack charms
<jamespage> but it broadly looks OK
<noodles775> Excellent, thanks.
<luca__> jamespage: Hi James, I did but I can't remember what the question was. I'll dig through my notes to see if I can find it :)
<jamespage> noodles775, the proposal has changes to the README and to swift-test as well - any particular reason?
<noodles775> jamespage: yeah, mentioned in the MP description, but happy to revert if you don't want them.
<noodles775> jamespage: hrm, I see my changes to the readme, but not to swift-test?
 * jamespage ponders that one
<jamespage> oh - sorry - that was me being an ass
<jamespage> (to much autopep8)
<noodles775> hah :)
<InformatiQ> noodles775: thanks for your help, that helped me a lot
<InformatiQ> I am quite impressed of juju's ease of use and low barrier to entry
<InformatiQ> not liking the bash install hooks though
<benji> InformatiQ: fortunately, you can write hooks in any language you want
<jamespage> if anyone has a bit of review time:
<jamespage> https://code.launchpad.net/~openstack-charmers/charms/precise/ceph/alternatives-config/+merge/195148
<jamespage> https://code.launchpad.net/~openstack-charmers/charms/precise/ceph-osd/alternatives-config/+merge/195149
<jamespage> (they have been in use in testing for quite some time and where used for the keynote at the OpenStack summit a few weeks back)
<noodles775> InformatiQ: np :) And yes, as benji said, you can use any language you want. There's also support for using configuration tools like ansible/saltstack if you're into that.
<noodles775> jamespage: oh, that reminds me, can I swap you for a review of https://code.launchpad.net/~michael.nelson/charm-helpers/ansible-tags/+merge/194324
<InformatiQ> noodles775: yeah i was googlng for ansible support but seemed to be still not merged
<noodles775> InformatiQ: yeah, there's some basic support in current charm-helpers (ie. an apply_playbook() helper), but I'm hoping to get the above branch landed soon which will make the ansible suppport much nicer.
<noodles775> jamespage: done.
<jamespage> noodles775, looking at your ansible one now
<noodles775> Great, thanks.
 * noodles775 -> lunch
<jamespage> noodles775, thanks for the review (and yes alot of the delta is re-sync of charm-helpers)
<jamespage> noodles775, reviewed and +1'ed
<noodles775> Great, thanks jamespage
<jamespage> np
<jamespage> love it when I propose branches and find my stuff is already merged
<jamespage> \o/
<jamespage> free work!
<jamespage> dosaboy, please see my comments on mysql and rabbitmq charms re argonaut backwards compat
<jamespage> that fix is already in cinder and glance
<dosaboy> jamespage: yep, actually the question was raised over whether we should allow non-openstack charms that use ceph to specify a source for the ceph packages
<jamespage> ooo - good one
<dosaboy> since right now if deployed on precise they are forced to use Argonaut
<jamespage> dosaboy, that might not be much of an issue - the mysql and rabbitmq charms both use the kernel module
<jamespage> so its only the cli tools that might be incompat
<dosaboy> yeah and that is the problem ;)
<jamespage> dosaboy, with havana backend?
<dosaboy> i mean i agree we should provide back-compat support
<dosaboy> but if users want to use > A they also have that option
<dosaboy> for the cli tools that is
<dosaboy> and
<dosaboy> if their cluster is > A the tools may have issues
<jamespage> its awkward
<jamespage> dosaboy, if we go down that route the cloud-archive must be installed at a lower priority than main archive
<jamespage> then you can cherry pick the ceph tools by themselved
<jamespage> then you can cherry pick the ceph tools by themselves
<dosaboy> jamespage: agreed
<dosaboy> or could version ping just the packages we ned but that is a little messay
<dosaboy> messy even
<InformatiQ> in the case where i deploy 2 wordpress + 1 mysql + haproxy then I want to have a central logging server then I would need to deploy rsyslog to each of those services with the --to param and a rsyslog service to collect them all?
<noodles775> InformatiQ: So the rsyslog-forwarder charm is a "subordinate" charm, so you just deploy it as normal and then relate it to the services where you want it in use (juju knows not to create any separate instances for that charm, due to it being a subordinate charm).
<noodles775> InformatiQ: Then you can deploy the rsyslog charm and relate it to the rsyslog-forwarder. (I've not used these, just going from the summary/readme at https://jujucharms.com/fullscreen/search/precise/rsyslog-1/
<jamespage> noodles775, your swift-proxy change worked OK for havana so I went ahead and merge it - thanks!
<jamespage> it was a bit crufty  from pre-redux stuff
<noodles775> Great, thanks jamespage. Yeah, looked like a huge cleanup!
<AskUbuntu> Will Juju support start/stop of existing units? | http://askubuntu.com/q/378920
<noodles775> jamespage: Hi, my MP is still approved but not landed - does it need to be merged manually? https://code.launchpad.net/~michael.nelson/charm-helpers/ansible-tags/+merge/194324
<jamespage> noodles775, yes - sorry
<jamespage> no auto-landing just yet....
<mattyw> I seem to be able to bootstrap multiple environments for a single provider - and they are kept seperate but destroy-environment kills everything - is this a known problem?
<jamespage> mattyw is that with maas?
<mattyw> jamespage, aws
<jamespage> mattyw, juju version?
<mattyw> jamespage, ah - the destroy is an old version: 1.13
<jamespage> mattyw: and do you have unique control-buckets and secrets for each environment?
<jamespage> (just checking the obvious stuff first)
<mattyw> jamespage, bucket and secret are different
<jamespage> mattyw, I would suspect a bug - but I could not confirm that
<jamespage> fwereade_, jam: ^^ ring any bells?
<mattyw> jamespage, I'll try updating the old version and see if it happens again
<fwereade_> mattyw, what provider?
<fwereade_> mattyw, ec2 will have problems if the environments have the same name
<fwereade_> mattyw, and I *think* openstack has the same issue
<fwereade_> mattyw, maas is meant to be working if you have up-to-date juju and maas, and you have unique values of... er<checks>
<fwereade_> mattyw, maas-agent-name -- but that should not be set automatically, so you're safe unless they're old environments or you're doing something really weird
<fwereade_> mattyw, sorry, maas-agent-name *should* be set automatically
 * fwereade_ will bbl
<InformatiQ> using juju with local provider, afer a reboot of the VM i get "ERROR Unable to connect to environment "local"
<InformatiQ> I was thinking that a jujud should be running but cabn't find the service
<marcoceppi_> InformatiQ: what does `initctl list | grep juju` show on your machine?
<InformatiQ> marcoceppi_: uju-db-rhanna-local stop/waiting
<InformatiQ> juju-agent-rhanna-local start/running, process 907
<marcoceppi_> InformatiQ: `sudo start juju-db-hanna-local`
<marcoceppi_> InformatiQ: wait a few seconds, then try juju status
<InformatiQ> recover error: abrupt end to file .juju/local/db/journal/j._1, yet it isn't the last journal file
<InformatiQ> ok so apparantly juju-db cannot recover so that's why it can't start
<InformatiQ> hmmm
<InformatiQ> ok got it, remove journal j.__? files and restart service this should work in case of corruÃ¥t journal but no db chnages
<InformatiQ> first issue with juju == first real learning experience
<InformatiQ> good day so far
<jcastro> hey arosales or marcoceppi
<jcastro> which one of you recorded the last charmer meeting?
<marcoceppi> jcastro: I think it was arosales
<jcastro> I need a link to the video please!
<InformatiQ> hey guys any pointers to how to do python or ansible charms
<avoine> would it be correct to use admin-secret as my charm default admin password like juju-gui does?
<InformatiQ> or if you know one charm from the store written ansible/puppet/python would be cool
<avoine> InformatiQ: I've done charm in python
<marcoceppi> InformatiQ: http://micknelson.wordpress.com/2013/11/08/juju-ansible-simpler-charms/
<avoine> python-django, gunicorn, but postgresql and etherpad-lite would be better examples
<arosales> jcastro, I indeed did
<arosales> jcastro, sure let me grab it
<InformatiQ> marcoceppi: that blog post is mentioning that the ansble stuff was not yet commited
<marcoceppi> InformatiQ: it's been merged, that post was from august
<arosales> jcastro, https://www.youtube.com/watch?v=QlI2Qz2nucc
<InformatiQ> marcoceppi: wasn't sure how fast juju gets things in ;)
<InformatiQ> arosales:
<marcoceppi> InformatiQ: that is part of charm-helpers, a seperate project that's designed to help streamling writing charms
<InformatiQ> avoine: so a big hooks.py and everything else points to it
<marcoceppi> InformatiQ: that's one method
<avoine> InformatiQ: yeah, this way it more convenient
<dannf> helping someone behind a firewall in another channel - does juju use the various *_proxy variables? does it need more than http/https out to work?
<dannf> (when talking to the charmstore)
<thumper> dannf: not as much as I believe we should
<thumper> I'm not sure it has been thoroughly thrashed out and exhaustively tested
<dannf> thumper:  ack
<thumper> so, my normal stance is, if it isn't tested, it is broken
#juju 2013-11-19
<cjohnston> Does anyone have any experience with using salt in a charm?
<sidnei> cjohnston: ping noodles775 in the morning
<sidnei> cjohnston: though he (and me and hazmat) favours ansible
<cjohnston> sidnei: ya. was hoping for someone tonight..
<sidnei> let me see if i can find you an example
<hazmat> cjohnston, there's support for it in charmhelpers
<cjohnston> hazmat: right.. I'm having a specific issue, but I know that not many people have experience with it
<hazmat> cjohnston, traceback?
<hazmat> cjohnston, i'm happy to take a look, but no guarantees. i haven't used the combo, though i'm familiar with both.
<cjohnston> hazmat: http://paste.ubuntu.com/6440481/  I believe the issue is with my attempt at getting relation info.
<cjohnston> I'm trying to get the postgres host, grains.get('postgres:host'),  is what I'm using
<hazmat> cjohnston, hmm.. it looks something wrong in the template expression
<hazmat> cjohnston, do you have a minimal file that reproduces ?
<hazmat> cjohnston, one that you can share that reproduces?
<cjohnston> its supposed to be producing django DATABASES = {}
<cjohnston> one sec
<cjohnston> hazmat: http://paste.ubuntu.com/6440506/
<hazmat> cjohnston, the sls file for it?
<cjohnston> I think I may have just figured something out... hrm.. lemme see what it does, if not I'll paste
<hazmat> cjohnston, any luck?
<cjohnston> well, the traceback is gone, but I have 'None' instead of real data
<hazmat> cjohnston, are you using the charm-helpers salt support? ie. http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/saltstack/__init__.py
<cjohnston> yes
<cjohnston> hazmat: http://paste.ubuntu.com/6440556/
<hazmat> cjohnston, so the relation data isn't there yet, which hook is that being run in?
<cjohnston> db-relation-joined and db-relation-changed... if I do relation-get it returns the correct data
<cjohnston> hazmat: is ('postgres:host') correct? should postgres be something else maybe?
<hazmat> cjohnston, the grains with the data  are in /etc/salt/grains ..
<hazmat> cjohnston, it looks like you need a prefix from http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/templating/contexts.py#L34
<InformatiQ> i'm working on a trac charm using ansible
<noodles775> InformatiQ: Excellent! Just ping with any questions... I guess you saw that the extra ansible support landed yesterday in charm-helpers.
<InformatiQ> does anyone have any pointer how the juju_state_to_yaml outputr looks like
<InformatiQ> noodles775: i was waiting for it to start writing my code ;)
<InformatiQ> I have been using ansible for a while now and I can see a lot of potential for combining it with juju
<InformatiQ> although i still struggle a bit with juju concepts
<noodles775> Yep - I think the combination has lots of potential to simplify charms too (and make them much more flexible out-of-the-box).
<noodles775> InformatiQ: so do you want a paste of an example yaml file that's outputted by the function (I can do that, just wondering why you need it, normally you wouldn't need the file itself, as it's just used to provide context for your templates). Ah, probably the key names...
<noodles775> cjohnston: Did you find the data you were looking for? FWIW, I'd recommend checking the actual grains written to the file in /etc/salt/grains as hazmat suggested (or alternatively using a pdb when running your hook in the debug-hook window) to confirm the actual keys, but they should be "reln_type:reln_key" (where reln_type is just os.environ.get('JUJU_RELATION_ID'))
<noodles775> cjohnston: er, os.environ.get('JUJU_RELATION'), sorry (ie. output of charmhelpers.core.hookenv.relation_type())
<InformatiQ> noodles775: yes I need that file to know what are the  vars that are available
<InformatiQ> noodles775: i would appreciate if you could paste one for me or just tell me how to generate it
<noodles775> InformatiQ: Cool, so in the long run it'd be best to look at the one generated automatically by your charm, as it is just a json dump of the charm configuration (which is very dependent on the charm you're using). But as an example, if I was working with a charm which had these options in the config.yaml:
<noodles775> https://jujucharms.com/fullscreen/search/precise/swift-proxy-30/?text=swift-proxy#bws-configuration
<noodles775> then the file contents are just a dump of the charms config, eg: http://paste.ubuntu.com/6441675/
<noodles775> The juju_state_to_yaml helper also adds 'charm_dir', 'local_unit', as well as relationship data (which is only present once those relationships are added).
<noodles775> (for all the details, see http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/templating/contexts.py ), but otherwise, let me know when you've got a simple install hook which just installs ansible, and I'll show you how you can inspect the real file yourself.
<InformatiQ> noodles775: are you the author of the blog micknelson.wordpress.com
<noodles775> InformatiQ: yep, you can blame me for any errors there :)
<InformatiQ> noodles775: just that i left a comment and it is still waiting moderation ;)
<InformatiQ> noodles775: so I followed your example and have that hooks.py and install/start/stop/etc and links to it
<noodles775> InformatiQ: It should be there, I approved it 15mins ago or so.
<InformatiQ> now I am working on an ansible playbook
<noodles775> InformatiQ: Great. Just start with something really simple (ie. something that has a single task tagged with 'install'), then we can start the deploy/debug-hook cycle so you can see how to debug and test as you go.
<noodles775> s/something that/a playbook that/
<InformatiQ> noodles775: ok should have the needed stuff there
<InformatiQ> noodles775: so what is the path to testing the hook without really deploying?
<noodles775> InformatiQ: So I tend to write unit-tests to test things like "calling the install hook installs ansible", but there's not a lot more you could unit-test (perhaps with ansible, we could add some helpers that ensure your playbook is formatted correctly etc.). When developing your charm though, you really want to be deploying to test it. Do you have an environment bootstrapped?
<InformatiQ> noodles775: yes I have a local env
<noodles775> Great. So you can try deploying your charm (if you can push your branch somewhere, I can follow along/help a bit more).
<noodles775> InformatiQ: hah - thanks for the flowers :-) (the tweet)
<InformatiQ> noodles775: pushed current code to https://github.com/InformatiQ/charm-trac
<InformatiQ> noodles775: i got 2013-11-19 09:01:01 ERROR juju.worker.uniter uniter.go:350 hook failed: fork/exec /var/lib/juju/agents/unit-trac-0/charm/hooks/install: exec format error
<noodles775> InformatiQ: Perfect, let's find out why...
 * noodles775 grabs the charm
<noodles775> InformatiQ: Ok, I'm guessing the error is that we've not yet imported charmhelpers (nor is it yet available in the charm - it's not included automatically). But let's actually confirm that the right way. In a separate terminal, run `juju debug-hooks trac/0`
<InformatiQ> noodles775: ok that dropped me in a shell on the new machine
<noodles775> Then in your original terminal, do `juju resolved --retry trac/0`
<noodles775> When you switch back to the debug-hooks window, it should now be ready to run the install hook.
<InformatiQ> yes
<noodles775> Run `hooks/install` to see the error.
<InformatiQ> noodles775: syntax error at line 4
<InformatiQ> hmm
<noodles775> Yep, let's back out a bit (it was just worth seeing how to use debug-hooks). Basically, hooks/install is currently running your hooks/hooks.py as a bash script.
<noodles775> So edit the file (right there on the unit, so we can iterate quickly)
<InformatiQ> aha
<InformatiQ> yeah got that and now add the hash bang for python?
<noodles775> Yep, then you'll see the error related to charmhelpers being missing.
 * noodles775 looks up the latest and greatest way to include those in your charm.
<InformatiQ> yup charmhelpers not defined
<noodles775> jamespage: hi! I'm just looking for the best way to pull charmhelpers into a charm (to help InformatiQ). I notice in your swift-proxy charm you've got a charm-helpers.yaml defining the import, and in the Makefile the sync target calls charm-helper-sync... where does charm-helper-sync come from?
 * noodles775 normally does it with a much uglier Makefile target.
<InformatiQ> this is looking a bit complicated for me
 * InformatiQ is a code monkey not a developer
<noodles775> InformatiQ: hah. New things are always tricky at first. We can do it a simpler way. Just do `bzr branch lp:charm-helpers /tmp/charm-helpers && cp -R /tmp/charm-helpers/charmhelpers hooks`
<noodles775> InformatiQ: that'll put the current charmhelpers python library in your hooks directory so we can use it.
<noodles775> InformatiQ: oh, and if it's not clear, this is on your development machine, you can exit out of the debug-hooks.
<InformatiQ> noodles775: ok so now I need to redeploy?
<noodles775> InformatiQ: You can just upgrade the charm too `juju upgrade-charm trac --repository....`
 * noodles775 is just testing the updated hooks.py before pasting it.
<noodles775> InformatiQ: so this is what your hooks.py should look like - I'll update the blogpost with the imports and the main section, note you also had site.yaml rather than sites.yaml too: http://paste.ubuntu.com/6441930/
<noodles775> InformatiQ: also, in your playbooks/sites.yaml, you've got "lates" instead of "latest".
<InformatiQ> noodles775: cool things are moving ahead
<InformatiQ> cool
<noodles775> Yep. I'm still just looking at an issue I'm seeing (not an issue of yours, but with the ansible support that I've added). So don't worry if it gets stuck. (It's worthwhile to me because I'm keen to iron out issues in the ansible support :-) ).
<InformatiQ> where should the playbook dir reside? in the hooks ?
<noodles775> It's fine where you've got it.
<InformatiQ> i am getting file not found
<noodles775> Did you fix the "playbooks/site.yaml" to "playbook/sites.yaml"?
<noodles775> (in hooks/hooks.py, that is)
<InformatiQ> yes i have
<InformatiQ> http://paste.ubuntu.com/6441986/ that is the traceback
<noodles775> InformatiQ: hrm - that's not related to your playbook. Checking the line that's failing from your tracebook says that it's trying to run `juju-log` and not finding it. But I don't know why that would be (ie. why a juju unit wouldn't have juju-log available).
<InformatiQ> juju-loh is not even available on my juju host
<InformatiQ> is it deprecated now?
<InformatiQ> i am using the ppa version of juju
<InformatiQ> ppa:juju/stable
<InformatiQ> on saucy
<noodles775> No, it's still very much a part of juju. I'm using the same ppa (on saucy), and this is the output I see on the trac unit: http://paste.ubuntu.com/6442038/
<noodles775> InformatiQ: I'm not sure how you ended up with a juju unit without juju-log, but it might be worth redeploying...
<InformatiQ> noodles775: just sshed into one of the successfully deployed machine and juju-log cmd is not available too
<noodles775> Ahh - hangon.
<InformatiQ> although actually the install hook for that service had juju-log in there
<noodles775> InformatiQ: Cool, confirmed: it's not an installed command available whenever you log in. But it is available when you're running a hook. So first, make sure you're in a `juju debug-hooks trac/0` session (even if it's not currently within a hook)
<InformatiQ> noodles775: juju-log is supposed to be here /var/lib/juju/tools/1.16.3.1-precise-amd64/juju-log
<InformatiQ> and that is probably not in the path
<InformatiQ> noodles775: i guess you either extend PATH in the charmhelpers/core/hookenv.py or explicutly use the full path for juju-log
<InformatiQ> because I am in juju debug-hooks for that service
<noodles775> InformatiQ: you won't need to. It'll be available when you're actually running a hook. Great (that you're in the debug-hooks session), we just need to trigger a hook first. Try:
<noodles775> InformatiQ: back in your other terminal, run `juju set trac tracadmin_user=foo` (it'll just cause the config-changed hook to be triggered)
<noodles775> InformatiQ: when you switch back to your debug-hooks terminal, you should see it's updated and juju-log will be on the path.
<InformatiQ> well that didn't help either but I set it manually
<InformatiQ> and now a new failure related to config-get i guess because it doesnot have the needed configs
<InformatiQ> i guess i now cleanup, fix sources push to git and retry
<noodles775> InformatiQ: Yeah - I'm still investigating something with the ansible support, but I'll create a pull-request demoing the stubbed charm once it's working. Thanks for your patience :)
<InformatiQ> noodles775: ok, i guess that was a good drill i have updated the charm on github
<InformatiQ> let me know when it is ready to proceed
<InformatiQ> i need to get back to my dayjob now
<noodles775> Great, will do. Enjoy :-)
<davecheney> http://us-east.manta.joyent.com/dfc/public/QaipSnfmeK.0.svg
<davecheney> ^ sorry, it has the wrong mime type
<davecheney> i'll have to fix my client
<davecheney> ignore, wrong chan
<jamespage> noodles775, its in charm-helpers
<jamespage> (yeah - I know thats a bit sucky)
<jamespage> noodles775, http://paste.ubuntu.com/6442249/
<noodles775> Thanks jamespage
 * noodles775 wonders if a simple Makefile might provide a good bootstrap to pull that one file from the branch, sync charmhelpers, and create a stubbed (but working) basic charm.
<noodles775> InformatiQ: The issue I thought I was looking out was a typo on my part (I had sites.yaml, rather than sites.yml). Here's an example of your charm being deployed: http://paste.ubuntu.com/6442336/
<noodles775> InformatiQ: What you had in your branch was fine as is, all I needed to do was remove the unused hooks: https://github.com/InformatiQ/charm-trac/pull/1
 * noodles775 -> lunch
<AskUbuntu> jujud hangs when connecting to the mongo,maybe tls handshake error | http://askubuntu.com/q/379325
<jamespage> noodles775, ooo - now that is an idea
<InformatiQ> noodles775: great thanks
<InformatiQ> now I need to figure out what to do about those db relations
 * InformatiQ wonders what subordinates are
<InformatiQ> to the docs
<InformatiQ> noodles775: one more thing related to the state_to_yaml what you pasted earlier had the config vars, but what about relation vars?
<noodles775> InformatiQ: they'll also be in the file once you add a relation hook and it's called (the helper updates the vars file based on the current config and current relation just before running the playbook with the tag)
<cjohnston> noodles775: I finally figured it out ;-)
<noodles775> cjohnston: great :-) Let me know if it's something that could have been avoided by better docstrings in the charmhelper modules.
<cjohnston> noodles775: it was figuring out grains.get('db:database')  (the 'db' part), I didn't find anything that said what it should have been
<noodles775> cjohnston: Right - I'll update the docstring to make that explicit.
<gnuoy> if a unit dies unexpectedly does that trigger cluster relation departed on the other units in the same server ? I thought it would but I don't seem to be seeing that
<hazmat> gnuoy, it used to with pyjuju.. in juju-core the signaling is explicit after the admin does juju remove-unit.
<gnuoy> hazmat, ah ok, thanks
<InformatiQ> I have a " agent-state-info: 'hook failed: "install"'"
<InformatiQ> how do i get it fixed after i have fixed my hook
<InformatiQ> i did try juju resolved
<InformatiQ> but didn't get that fixed
<InformatiQ> ok aparantly me being in debug hooks prevented it from continuing
<InformatiQ> all good now
<SuperMatt> I'm having trouble using this: https://juju.ubuntu.com/docs/howto-node.html with my own node app. I don't particularly care for the mongodb integration, so how could I tweak the charm for what I need?
<marcoceppi> hey SuperMatt, so you can fork the charm, using charm-tools (available from ppa:juju/stable), just run juju charm get node-app, edit the metadata.yaml file to include additional interfaces you wish to communicate with, then write the hooks for those relations
<SuperMatt> thanks :)
<SuperMatt> I think I discovered why the charm hasn't really been working for me
<marcoceppi> SuperMatt: We do have people working on the node-app charm to make it more robust, but that's a way for you to patch in the mean time
<SuperMatt> there's a lot of stuff in the config.yaml that the tut doesn't really mention
<marcoceppi> SuperMatt: Must have changed since the tut was written
<marcoceppi> SuperMatt: I'll also include https://juju.ubuntu.com/docs/charms-deploying.html#local in case you didn't already know how to deploy a charm from a local repo
<SuperMatt> marcoceppi: if you don't mind, I'm going to just have a bash at tweaking this thing, and I'll let you know what I discover :)
<marcoceppi> SuperMatt: sure! if your changes can benefit the larger community, feel free to submit a merge req back in to the store
<SuperMatt> well, I don't know about that ;)
<SuperMatt> I imagine it's a good idea to have the charm allow you to pick if you want to have mongodb, rather than it being required
<marcoceppi> SuperMatt: you can submit for a review anywasys :_
<SuperMatt> sure
<SuperMatt> thanks
<SuperMatt> I'm kinda just learning about juju right now
<SuperMatt> so it's all a bit up in the air for me
<SuperMatt> if I manage to do something cool I'll merge back
<SuperMatt> thanks for the help though, I didn't realise you could simple pull out a charm and modify it
<SuperMatt> q
<SuperMatt> ops
<SuperMatt> I actually typed :q there
<SuperMatt> >.<
<SuperMatt> marcoceppi: I've just spotted exactly what I needed to change to make the installer work for me. Thanks a lot
<marcoceppi> SuperMatt: NP! Glad I could help
<SuperMatt> all right, here goes nothing
<noodles775> jamespage: trivial one-liner if you've a few secs: https://code.launchpad.net/~michael.nelson/charm-helpers/remove-saltstack-import-from-ansible-support/+merge/195817
<jaywink> hi .. anyone with knowledge whether on azure "force-image-name" config can be used to use an image captured into personal gallery? I cannot really find image names..
<jaywink> and I'm interested in freezing an image to use for deployments anyhow
<InformatiQ> noodles775: according to your patch https://code.launchpad.net/~michael.nelson/charm-helpers/ansible-tags/+merge/194324 line 201 + ("{relation_type}{namespace_separator}{key}".format(
<InformatiQ> noodles775: the relation vars are prefixed with relation_type
<InformatiQ> how do i get the relationtype?
<InformatiQ> so i can formulate the var name
<InformatiQ> noodles775: or how can i print the vars.yml so I can inspect it
<SuperMatt> marcoceppi: my juju experiments are going very well now. Thank you for your help
<InformatiQ> noodles775: ok found out what type it is from env var
<marcoceppi> SuperMatt: awesome, let us know if you have any other questions :)
<SuperMatt> sure thing
<SuperMatt> I think I'm going to stay in here
<InformatiQ> but ansible complains about variable not defined
<SuperMatt> I think learning juju, lxc, cgroups and maybe a little openstack are going to make me indispensible in the future
<jamespage> noodles775, merged
<jamespage> (implicit approval)
<InformatiQ> SuperMatt: indeed
<InformatiQ> noodles775: it seems ansible does not like vars with '-' as in the case with private-address so simply also key.replace('-','_') as you did for the relation_type
<InformatiQ> noodles775: check my git repo hooks/charmhelpers/contrib/templating/contexts.py to see the small chnage needed
<InformatiQ> hey guys, some advice needed
<InformatiQ> working on a trac charm
<InformatiQ> should i make mysql an optional db ?
<InformatiQ> i was thinking to make sqlite default backend and make mysql optional
<jcastro> InformatiQ, yes, that sounds great
<jcastro> that's what the etherpadlite charm does
<jcastro> that way if someone wants to run "small" on one instance they can do so
<jcastro> and then expand out to mysql later
<InformatiQ> jcastro: good to see someone up
<InformatiQ> jcastro: the proble is that trac is not quite kind when it comes to migrating dbs
<jcastro> I would leave a note in your README though, reminding people that if they add the mysql relation that their data will not magically be migrated to the new DB
<jcastro> yeah so I would just mention that in the README
<InformatiQ> jcastro: good isea
<jcastro> maybe link to db migration docs if trac has them or something
<InformatiQ> jcastro: so hooks would be
<InformatiQ> install to get all installed
<InformatiQ> config-changed to init the env and db using sqlite
<InformatiQ> if relation added
<InformatiQ> then keep the sqlite db and reconfigure to point to mysql and then people need to do the work to get it migrated
<InformatiQ> jcastro: what do you think? (my first charm))
<jcastro> yeah, sec, I am looking at http://bazaar.launchpad.net/~charmers/charms/precise/etherpad-lite/trunk/view/head:/hooks/hooks.py
<jcastro> I think that would be in relation changed?
<jcastro> marcoceppi,  is that right?
<InformatiQ> jcastro: yeah that would be db-relation-changed
<jcastro> oh interesting, I didn't know trac did postgresql too
<marcoceppi> InformatiQ: jcastro: sure, that's one way to approach it
<jcastro> (just searching for other charms that support multiple DBs)
<marcoceppi> jcastro: typically, you'd make sure the data migrated between sets
<InformatiQ> hei guys, so I start a new project and start creatingthe infra with juju say a wordpress + mysql
<InformatiQ> then i need to add plugins and a new theme to wordpress and whatever
<InformatiQ> soe of these changes are on filesystem
<InformatiQ> now when do add-unit wordpress that won't take my chnages
<marcoceppi> InformatiQ: check the readme, there is a way to make that happen
<marcoceppi> InformatiQ: you either need to place your plugins and themes in a repository OR use an NFS charm to share the files across a mount
<InformatiQ> marcoceppi: well that is a general case notspeciic to wordpress
<marcoceppi> InformatiQ: it's what teh wordpress charm does
<InformatiQ> mainly about the lifetime and repeatability of a juju infra
<InformatiQ> i am sysadmin
<marcoceppi> InformatiQ: what's your question?
<marcoceppi> i'm not quite grasping what you're trying to ask
<InformatiQ> i use ansible to deploy services, and whenver i want to change my infra i update the ansible scripts and redeploy
<sarnold> InformatiQ: perhaps you're looking for juju subordinate charms to deploy different wordpress plugins?
<InformatiQ> I am trying to understand how does juju handle changes to infra?
<jcastro> so you could fork the wordpress charm, make the changes you want, and deploy
<jcastro> however, juju has a concept of subordinate charms
<thumper> o/
<jcastro> which "bolt on" to existing charms
<InformatiQ> jcastro: yeah i am trying to understand that now
<jcastro> so you could have "wordpress" and say "all-my-custom stuff charm"
<jcastro> however with this particular charm marco made it so you could do plugins and custom things on disk without having to do that
<jcastro> you basically deploy the NFS charm as a subordinate of wordpress
<jcastro> and then when you add unit of wordpress it'll also pull in nfs and have the right things on disk for the new unit
<InformatiQ> so a subordinate sticks to the service and get redeployed whenver a unit is added
<jcastro> yeah
<InformatiQ> hmm
<jcastro> the relationship is made between the services, not the machines
<InformatiQ> jcastro: yup got that
<jcastro> so any new unit you add will be like the others
<jcastro> https://jujucharms.com/fullscreen/search/precise/wordpress-20/?text=wordpress#bws-readme
<jcastro> the "single mode and the scale out" section explains the NFS bit with the wordpress charm btw
<jcastro> (sorry we're in the middle of a team call right now, trying to respond as fast as I can)
<InformatiQ> jcastro: oh no worries i got enough to read already
<jcastro> if we're not responsive over the next 2 days it's because we're doing a developer conference, but feel free to post on the mailing list!
<InformatiQ> jcastro: one last question
<jcastro> shoot!
<InformatiQ> in the case i want to add a monitoring agent to all my machines, then that is not a subordinate
<InformatiQ> and add-unit will not help get that agent to all machines right?
<jcastro> ok so let's say you have newrelic
<jcastro> we made that a subordinate so that anything you relate to newrelic will automatically get the agent deployed
<jcastro> but correct, if you don't have a relationship with the agent and the service on the machine then juju won't help in that case
<jcastro> but we want to get as many monitoring agents in the charm store as possible so that you can just relate them to whatever you want to monitor
<jcastro> the same thing would apply to say, backup agents too
<InformatiQ> jcastro: so the monitoring agent gets to be a subordinate of a service hmmm
<InformatiQ> makes sense
<jcastro> what agent do you use btw?
<InformatiQ> sensu
<jcastro> oh, we have that!
<InformatiQ> i saw there is an agent already there
<InformatiQ> but i am trying to get beyond just using things
 * jcastro nods
<InformatiQ> I am also thinking in terms of multiple services per machine
<InformatiQ> so that means what when each service has an agent attached to it
<jcastro> arosales, gary_poster would like us to move bundle workflows so he can attend it, I was thinking swapping it out with automated charm testing.
<jcastro> this is for thursday
<gary_poster> thank you for considering jcastro
<jcastro> gary_poster, for the rest of the stuff you asked about we only have 2 "tracks" and we have to share with the rest of cloud/server, so that unfortunately is the case
<gary_poster> jcastro, ack, figured it might be something like that
<arosales> jcastro, +1
<jcastro> marcoceppi, ok automated charm testing is an hour earlier than before on thursday
<marcoceppi>  jcastroack
<arosales> marcoceppi, rick_h_ had a question on charm testing urls
<arosales> specifically https://jenkins.qa.ubuntu.com/job/precise-openstack-charm-mysql  is 404'ing
<arosales> marcoceppi, afik those URLs ~should~ still be valid, but wanted to confirm with you.
<arosales> marcoceppi, I think we are not seeing testing results at jujucharms.com as some testing aren't running
<arosales> ie https://jujucharms.com/fullscreen/search/precise/mysql-29/?text=mysql
<arosales> no test results
<arosales> https://jujucharms.com/fullscreen/search/precise/jenkins-8/?text=jenkins
<arosales> has test results
<unbreak-it> Would this be a good place to get help on deploying juju on aws?
<marcoceppi> unbreak-it: it would
<unbreak-it> I can run `juju bootstrap` just fine, and an instance shows up in my EC2 management console. But when I run `juju status -v` it locks up after `INFO juju.state open.go:68 opening state; mongo addresses: ["ec2-54-226-186-205.compute-1.amazonaws.com:37017"]; entity ""`
<unbreak-it> Any ideas what the issue could be?
<arosales> unbreak-it, can you pastebin.ubuntu.com the output of "juju --debug status"
<arosales> unbreak-it, also what juju version are you running?
<arosales> juju --version
#juju 2013-11-20
<noodles775> InformatiQ: Glad you found the vars. FWIW, I included an example of cat'ing the vars yaml file in the paste at line 53: http://paste.ubuntu.com/6442336/
<noodles775> InformatiQ: and thanks for the pointer about the key names in ansible, I'll update that in charm helpers too.
<freeflying> can we change config flag with juju set dynamically?
<freeflying> like set quantum's ext network pool
<noodles775> freeflying: running `juju set servicename mysetting=foo` will trigger the config-changed hook on all units of servicename in addition to providing the new value for the mysetting config optin (which must be part of the config.yaml).
<freeflying> noodles775, sounds cool, thx
<InformatiQ> good morning/day/whateveryoutimeis
<InformatiQ> is there any page which lists who is using juju?
<InformatiQ> I usually don't see juju much in the devops circles (which is where juju should be really)
<InformatiQ> so I was hoping to get a feeling of the adoption of juju
<InformatiQ> also if anyone here does juju consulting I would interested to have a quick chat
<noodles775> Hi InformatiQ. I'm not aware of a page listing adoption, jcastro is the person to talk to I'd think (when he's awake).
<InformatiQ> Hi noodles775
<InformatiQ> noodles775: so in ansible if i need to open a port i just run the command in shell from ansible
<InformatiQ> right?
<noodles775> InformatiQ: Normally if it's to expose the service, you'd use `juju expose servicename`... is that what you're after? eg, https://juju.ubuntu.com/docs/charms-exposing.html
<InformatiQ> noodles775: i thought you had to put open anyway
<noodles775> InformatiQ: yes, sorry. I'm not sure of the best way to do that with ansible - perhaps a command is the best way.
 * noodles775 checks
<noodles775> Yeah, there's a charm-helper for it (charmhelpers.core.hookenv.open_port), but it's just trivially calling open-port.
<noodles775> jamespage: Thanks for landing the one-liner yesterday. I've got another branch here which deals with an issue InformatiQ pointed out yesterday - but I'm assuming I shouldn't be pinging you for each branch. Are there a bunch of people subscribed or reviewing?
<noodles775> Anyway, fwiw: https://code.launchpad.net/~michael.nelson/charm-helpers/no-hyphens-in-ansible-yaml-keys/+merge/195931
<jamespage> noodles775, I'll do it for future review credit :-)
<noodles775> jamespage: Done :-) (although, can we go by line-count? :P)
<jamespage> noodles775, reviewed and merged - thanks
<noodles775> Great, thank-you!
<InformatiQ> noodles775 jamespage : so everytime i make a charm using ansible i copy the charmhelpers tree in my hooks?
<jamespage> InformatiQ, for now yes
<jamespage> there are plans to release charm-helpers (at least the stable, core ones) for 14.04
<jamespage> + PPA's for backports (I expect)
<InformatiQ> 14.04 that's a long wait
<InformatiQ> i need to get familiar with launchpad
<noodles775> InformatiQ: Based on our experience yesterday, I'm putting together a charm-bootstrap-ansible branch on github that'll make it easier (it uses a script to just pull in or update the parts of charmhelpers you need)
<InformatiQ> noodles775: oh great thanks noodles
<InformatiQ> i am more familiar with github
<stub> I'm trying to work out the best place to initialize some storage shared between units in my service (a Swift container)
<stub>  I'm trying to work out the best place to initialize some storage shared between units in my service (a Swift container)
<stub> The problem I see is that if I do it in my install or config-changed hook, then every unit will attempt to intialize it.
<stub> If I do it in my peer relation-joined hook, then it is only initialized if there are more than one unit.
<noodles775> stub: it shouldn't matter I think? (that is, the PUT request for container creation is idempotent - http://docs.openstack.org/api/openstack-object-storage/1.0/content/create-container.html )
<noodles775> stub: you just get a 202 instead of a 201
<stub> I guess that isn't the real problem
<noodles775> Ah - or you want to do more than just create the container...
<noodles775> Yeah.
<stub> If there is a single unit, the unit needs to use the container. If there are multiple units, only the master unit needs to use the container.
<stub> If I 'deploy --units=3', then until the peer relation hooks are run I'll have 3 units that don't know about each other and will all attempt to use the shared storage.
<noodles775> Hrm, that seems to make sense though (that until they know about each other, they assume they use the shared storage themselves).
<stub> yeah. Also, if I add a new unit I don't want it to crap all over the shared area when it thinks it is alone.
<stub> I think I need some sort of locking, but I don't think I can do that with Swift?
<stub> create_container_if_not_exists_else_fail
<noodles775> You should be able to do that with multiple requests? (ie. a HEAD for metadata, which will 404 if it doesn't exist)
<stub> Maybe append a UUID to the container name...
<noodles775> Ah - right, but that'll just race.
<InformatiQ> stub why not the first container writes a lock file to the container (assuming the container is a filesystem of some sort)
<stub> That master-election thing someone mentioned on the mailing list would be useful here (that doesn't eist)
<stub> InformatiQ: Swift is an object store, and some of its features make locking problematic I think
<gnuoy> jamespage, fwiw I've resubmitted the multiple floating pools  branch. I see the mp to nova-compute is still outstanding, do you have any philosophical objection to that one or is it just in the queue ?
<noodles775> (lake of consistency, for example, http://julien.danjou.info/blog/2012/openstack-swift-consistency-analysis )
<jamespage> gnuoy, in the queue but uds this week
<gnuoy> ok, understood
<jamespage> gnuoy, was that the one that does the mtu setting stuff?
<jamespage> I was pondering that approach
<gnuoy> jamespage, thats the one
<gnuoy> jamespage, what's your reservation about the approach ?
<jamespage> gnuoy, well as much as possible I'm adverse to twiddling network knobs and configuration in the charm
<jamespage> I think that should be done during provisioning and written into /etc/network/interfaces
<gnuoy> jamespage, really ? Surely a customers experience would be far better if they deploy openstack via stock maas and twiddle the mtu setting afterwards. If you do object strongly I can add it to my MaaS hacking instead
<jamespage> gnuoy, that's kinda why I'm still pondering it
<gnuoy> jamespage, I can see your pov, there is an element of compensating for a missing MaaS feature
<jamespage> gnuoy, yes indeed
 * jamespage thinks a bit more
<ashipika> hello juju!
<ashipika> having a bit of a problem with juju and MaaS.. and i was hoping somebody here would be kind eough to shed some light on a juju newbie
<ashipika> three computers.. one installed with ubuntu server CD with maas (create new...), configured (managed eth0, dhcp, etc).. the other two computers comissioned as nodes (raring, wake on lan..).. juju init, changed the .yaml file.. juju bootstrap went fine:
<ashipika>  WARNING picked arbitrary tools &{"1.16.0.1-precise-amd64" "http://192.168.1.99/MAAS/api/1.0/files/?key=11d9953c-51d5-11e3-a0a8-001e8c1c89bd&op=get_by_key" "9be79a60ec6084880521069f7555c011825ed9294a65cbac575333afe6bf1484" %!q(int64=4638204)}
<ashipika> ...
<ashipika> juju status.. freezes..
<ashipika> 2013-11-20 11:29:51 INFO juju.state open.go:68 opening state; mongo addresses: ["kwhp7.local:37017"]; entity ""
<ashipika> any ideas?
<jamespage> ashipika, I would suspect that the bootstrap node is still being installed; but you would need to see which node is allocated in the maas ui and go check to be sure
<jamespage> its possible something bad happened...
<ashipika> jamespage: thanks for your reply. yes. something strange is going on with my maas..  seems to be installing, but the node just shutsdown when it is "done"
<jamespage> ashipika, maas nodes have to be registered and commissioned prior to use; the commissioning step does what you just described above
<jamespage> and that's triggered when you accept the nodes in MAAS
<ashipika> yes.. but the status on the web says: Allocated to <username>
<ashipika> i already went through the commisioning step and accepting and whatnot
<jamespage> ashipika, probably worth asking in #maas - more knowledge in that channel as this sounds maas-ish
<ashipika> thanks!
<ashipika> :D
<InformatiQ> #juju on twitter returns lots of cats a weired people
<jamespage> marcoceppi, jcastro: when did lp:charms/ceph -> lp:charms/precise/ceph
<jamespage> ?
<jamespage> jamespage@armstrong:~/src/charms/precise$ charm get ceph
<jamespage> Error: ceph not found in charm store.
<jamespage> ouch!
<jamespage> marcoceppi, ^^
<marcoceppi> jamespage: what.
<jamespage> marcoceppi, that was my reaction as well
<jamespage> marcoceppi, https://code.launchpad.net/~charmers/
<marcoceppi> what the hell
<jamespage> marcoceppi, I suspect " Registered by Curtis Hovey 17 hours ago " is the cause
<jamespage> sinzui, ^^
<jamespage> https://launchpad.net/charms/trusty
<sinzui> jamespage, marcoceppi egad. I don't think registering trusty is the exact cause because I registered bundles several months ago
<sinzui> jamespage: I just changed trusty to experimental to de-empahise it
<jamespage> mthaddon, ^^ can you shed light on this issue?
<sinzui> jamespage, mthaddon: With projects, you explicitly set the series that is the focus of development.
<jamespage> sinzui, charms is a distributed tho
<jamespage> so I expect it behaves differently
<sinzui> jamespage, I did register trusty yesterday as I did bundles a few months ago. I did not edit precise
<sinzui> precise is set as supported, and once in that state, I can only become "current stable release" and "obsolete"
<sinzui> trusty is experimental
 * mthaddon catches up
<sinzui> mthaddon, jamespage: I was mistaken. /charms/trusty was NOT experimental. It claimed to be active development like precise. I just changed it to be Experimental after flipping between staging.lp and lp
<mthaddon> ah, yeah, it's now working for me, so I'm glad something was changed
<mthaddon> jamespage: I would definitely recommend lp:charms/precise/ceph though
<sinzui> I'm not. I did  make the change and I really didn't expect this. And I really don't know if I have fixed anything
<mthaddon> I think if it was set to active development it's entirely expected
<sinzui> jamespage, have I fixed it? I ran "bzr branch lp:charms/ceph ceph" and got a branch
<jamespage> I think so yes
<sinzui> okay I see this command did change the listing
<sinzui> charm search ganglia
<sinzui> damn. ppetraki was the first to spot the problem and I didn't understand the issue when we talked about it
<ppetraki> oh that
<noodles775> jamespage: another short charmhelpers branch for an error which the tests only highlight when run in isolation :/ https://code.launchpad.net/~michael.nelson/charm-helpers/missing-import-for-ansible-helpers/+merge/195967
<AskUbuntu> Problems using containers created using juju | http://askubuntu.com/q/379902
<marcoceppi> sinzui: could you jump in to uds-servercloud-1 ?
 * sinzui does, first killing cpu intensive procs
<marcoceppi> sinzui: https://plus.google.com/hangouts/_/72cpjufj5oc8omdro2acjh1vco?authuser=0&hl=en
<SuperMatt> all right, now I need to get my head around how relations work in juju!
<SuperMatt> my mind boggles
<SuperMatt> so in the metadata, you can set the requires stuff. I'm not sure why for instance you might need to specify "database:\n interface: mysql." Why the database part, when we already know that mysql is a db
<SuperMatt> does the interface specify the port?
<SuperMatt> or is it something different entirely?
<SuperMatt> hmmmm
<SuperMatt> I think I'm beginning to undestand relations, but at what point does one end of the relationship set their variables, such as ip address, etc?
<SuperMatt> or am I doing things wrong?
<marcoceppi> SuperMatt: so you can set relation data at anytime
<marcoceppi> but it won't be sent until the hook finishes executing
<SuperMatt> basically, I have a reverse proxy, and I want to get the ip address from one of the web servers. how and where would I set the ip address? In the start section?
<marcoceppi> SuperMatt: so your charm is providing the http interface, or is it consuming the interface
<marcoceppi> err, "requires"
<SuperMatt> well I have two charms, one for the web server, one for the reverse proxy
<SuperMatt> and I just want to update the reverse proxy with the ip addresses of the web servers
<marcoceppi> SuperMatt: right, so what you should have is the web server providing the http interface, and the reverse proxy requring the http interface
<SuperMatt> yes
<marcoceppi> SuperMatt: so the http interface relation on the app needs to
<marcoceppi> relation-set hostname=unit-get private-address port=<PORT>
<marcoceppi> SuperMatt: and the proxy http interface relation needs to
<marcoceppi> relation-get hostname
<marcoceppi> relation-get port
<marcoceppi> inside of the hook, so that it can read those values
<SuperMatt> ok
<SuperMatt> so which hook? the relation-changed hook?
<marcoceppi> SuperMatt: it'd be easier to explain if you provided a paste of each of the metadata.yaml files
<marcoceppi> SuperMatt: then I could provide exact hooknames that it would happen in
<SuperMatt> http://paste.ubuntu-helpouts.org/9
<SuperMatt> http://paste.ubuntu-helpouts.org/10
<SuperMatt> the second is a modified version of the node-app we talked about yesterday
<marcoceppi> SuperMatt: okay, so on the nginx-hash site, you're going to have a hook called reverseproxy-relation-changed
<SuperMatt> got it
<SuperMatt> I assume that's where I do my magic to update nginx
<marcoceppi> SuperMatt: each relation has four events/hooks tied to them relation-joined, relation-changed, relation-departed, and relation-broken
<SuperMatt> sure
<marcoceppi> SuperMatt: yes, you'll also want to add a realtion-departed/broken hook logic to remove those values from nginx config as the relation no longer exists
<SuperMatt> makes sense
<marcoceppi> SuperMatt: we have an nginx-reverseproxy charm, if you want to use as a reference
<SuperMatt> I might check it out
<SuperMatt> I had to make my own anyway, because I had to compile in an extra plugin
<marcoceppi> SuperMatt: nevermind, we don't have a reverseproxy charm
<SuperMatt> hahaha
<marcoceppi> could have sworn we did
<SuperMatt> well I have a general idea of how to update the conf file
 * marcoceppi may have confused with squid
<SuperMatt> the only thing I need is the list of IPs from the node-apps
<marcoceppi> SuperMatt: you can do that with relation-list actually
<SuperMatt> oh?
<marcoceppi> SuperMatt: so if you wanted to rebuild the file everytime
<marcoceppi> you could have the reverseproxy-relation-changed run relation-list to get a list of all the units
<marcoceppi> SuperMatt: then loop through those units and do a relation-get to that unit
 * marcoceppi finds example
<SuperMatt> lemme show you what I have
<SuperMatt> http://paste.ubuntu-helpouts.org/11
<SuperMatt> that's not by any means complete
<marcoceppi> SuperMatt: that's pretty much the idea
<SuperMatt> sure
<SuperMatt> but ip isn't set anywhere
<marcoceppi> I need to look up the relation-get syntax for specifying a unit
<marcoceppi> SuperMatt: you want to use hostname
<marcoceppi> http interface exposes `hostname` rather than ip
<SuperMatt> right
<SuperMatt> is hostname something that's set automatically by the unit?
<gary_poster> marcoceppi, jcastro can someone give me the hangout for the gui vUDS now please
<marcoceppi> SuperMatt: no, it's something that the relation requries authors to set
<gary_poster> happening now I mean
<jcastro> gary_poster, I just made the same mistake, check the time
<jcastro> it's lunch
<marcoceppi> SuperMatt: the assumption is all service will provide you with a port and a hostname
<jcastro> it just doesn't have a "lunch" session there
<gary_poster> jcastro, oh! ok thanks
<SuperMatt> marcoceppi: ok, I'm beginning to understand
<SuperMatt> so when does the service set that?
<SuperMatt> relation-changed?
<marcoceppi> SuperMatt: relation-changed is the best time to do this
<marcoceppi> http://paste.ubuntu.com/6449144/
<SuperMatt> ok
<SuperMatt> I think I get you
<marcoceppi> SuperMatt: since you're re-creating the file each time, you could symlink relation-departed and relation-broken to this file and then it'll update whenever a unit goes away
<marcoceppi> and that's your logic for updating when units get removed
<vds> I'm trying to ssh a unit in local environment and I get http://paste.ubuntu.com/6449146/ any suggestions?
<SuperMatt> but the thing I don't understand is, if both ends are running relation-changed at the same time, how does the reverse proxy know when the node has prepared all variables?
<marcoceppi> vds: don't use sudo
<marcoceppi> vds: only use sudo when you're bootstrapping and destroying a local environment
<marcoceppi> SuperMatt: they arent' running at the same time
<SuperMatt> oh
<SuperMatt> ok
<SuperMatt> I just assumed they were
<marcoceppi> SuperMatt: -changed will be run anytime there is a new data on the relation wire
<vds> marcoceppi, I'll try thanks
<SuperMatt> ok
<SuperMatt> I'll just give it a bash now
<SuperMatt> I think I have everything I need
<marcoceppi> SuperMatt: so what happens is, you add-relation and the -joined then -changed event will fire for each unit attached. Then if any of those two hooks added data -changed will be fired for the other side, -changed continues to fire on each side until there is no more new data being sent
<SuperMatt> I see
<SuperMatt> well fingers crossed, here goes nothing
<vds> marcoceppi, if I try to juju deploy without sudo I get http://paste.ubuntu.com/6449178/
<SuperMatt> marcoceppi: your help has been indispensible throughout my trails and tribulations. For that, I thank you.
<marcoceppi> vds: something is wrong then
<marcoceppi> vds: destroy-environment, then make sure you .juju folder is recursively owned by you
<marcoceppi> then bootstrap/deploy again
<vds> marcoceppi, same result
<marcoceppi> vds: what version of juju?
<marcoceppi> vds: this is really a bug, you shouldn't be using sudo for commands other than bootstrap and destroy-env
<vds> marcoceppi, 1.13.2-raring-amd64
<marcoceppi> vds: try upgrading to the latest, 1.16.3 and trying again
<vds> let's see what happens...
<InformatiQ> jcastro: I was told you're the man to talk to about juju
<InformatiQ> :)
<jcastro> InformatiQ, shoot!
<jcastro> I am ready!
<thumper> BANG!
 * thumper ducks
<InformatiQ> jcastro: well i was wondering about the adoption of juju, like who is using it, what environments, own charms vs cs
<jcastro> we're still in the early stages
<jcastro> we really didn't hit a production quality release until ~6 months ago
<jcastro> and for some people needing HA is still an issue which we'll address in 14.04
<jcastro> but we use it in production and we have customers who do
<jcastro> Juju hasn't been included in an LTS yet so the adoption is still early-stages
<InformatiQ> who is your target customers profiles?
<jcastro> So right now the obvious one is anyone deploying and orchestrating on openstack
<jcastro> However I am not a product-ish guy, so right now I'm focused on developers and sysadmins
<InformatiQ> well amazon fits in quite well too
<jcastro> I don't have like a list of personas or anything we target offhand
<jcastro> oh yeah, amazon, hp cloud, and azure are all first class citizens
<InformatiQ> well i am just trying to understand where juju is going
<jcastro> it's just openstack has a bunch of deployment painpoints that we address nicely
<jcastro> oh so did you see the 2.0 roadmap video from today's UDS?
<InformatiQ> so developers write juju code and sysadmin run the juju infra?
<InformatiQ> haven't seen the video yet
<jcastro> well the idea is to bridge dev and ops
<jcastro> for example being able to deploy something when developing it in a way that is similar to how you would run it in production
<InformatiQ> ah you meant you care about them as your target users, ok
<InformatiQ> got that point
<jcastro> https://www.youtube.com/watch?v=ZjzImjEinB8&feature=c4-overview&list=UUyT3AcQaRx_yl1yYLa5ikXQ
<jcastro> is the video
<jcastro> oh for sure.
<InformatiQ> well yeah that is my day job, do ops and get devs involved
<jcastro> right, so the idea with dev charms in particular
<jcastro> like rails, or the django charm
<jcastro> is that a developer will straight away be deploying to instances
<jcastro> and he iterates in a way that can be deployed by ops
<jcastro> I made a joke once, "You ever deploy something from a developer where he hardcoded in `localhost`? That's what we're trying to fix."
<jcastro> so the local provider the guy is developing on uses the same cloud images you would use on say Amazon
<jcastro> and he can rev at his pace on his laptop, and then when he's ready redeploy it to AWS
<jcastro> or over to your internal hardware
<jcastro> we want to make it easy for people to shift workloads around in different clouds
<InformatiQ> yup, and make dev envs as colse as possible to prod
<InformatiQ> which might make a case for mking a juju local provider run on virtualbox for those devs using macs
<InformatiQ> but anyway
<InformatiQ> coming from a sysadmin and ansible background
<InformatiQ> the playbook is a living thing, it changes as your conf changes so next time you dpeloy it it is uptodate and configured)
<InformatiQ> while that doesn't seem like the workflow in juju
<InformatiQ> i know you can always fork and edit the charm
<InformatiQ> just was wondering what is the official view on that?
<zradmin> is anyone else using it with MAAS and having the issue where juju locks up because the maas api is throwing back "not authorized" errors?
<arosales> InformatiQ, I think a charm is flexible to accomodate a dynamic playboook.  It may be analogous to a git hub project branch that a charm pulls from (at any deploy that git branch could be updated, if not pinned).
<arosales> zradmin, not sure how you were setting up but did you leave any of the fields blank when issuing "createsuperuser"
<arosales> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1243917
<_mup_> Bug #1243917: 'maas createsuperuser' errors out if no email address is entered. <MAAS:Fix Committed by jtv> <maas (Ubuntu):New> <https://launchpad.net/bugs/1243917>
<thumper> jcastro: you around?
<zradmin> arosales: yeah, i have an email address in the superuser but nothing under Full Name, my bug seems to be related to this entry: https://bugs.launchpad.net/maas/+bug/1218997
<_mup_> Bug #1218997: maas throws unauthorized sometimes for no reason <intermittent-failure> <maas> <juju-core:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1218997>
<arosales> zradmin, can you confirm your clocks are within 5 minutes of each other?
<zradmin> arosales: yes, between maas & juju they are both on the same time, just different timezones
<sarnold> does date -u on both return the same time?
<zradmin> sarnold: I just ran it on node 0 and maas and they are both returning the same time
<sarnold> zradmin: cool, thanks
<zradmin> sarnold: no problem
<arosales> zradmin, so it may not but be bug 1218997 your are hitting that roughly looked to be a clock sync issue
<_mup_> Bug #1218997: maas throws unauthorized sometimes for no reason <intermittent-failure> <maas> <juju-core:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1218997>
<arosales> hmm . ..
<arosales> zradmin, which version of juju and maas are you running?
<zradmin> arosales: juju 1.16.3, MAAS 1.5.4
<arosales> zradmin, yup that looks recent
<davecheney> zradmin: what does the maas log say
<davecheney> in maas/juju
<arosales> davecheney, hello
<davecheney> maas returns very terse errors to the client
<davecheney> for security reasons
<davecheney> but is usualy much more vocal in its own log
 * davecheney waves to arosales 
<zradmin> davecheney: it's filled with these errors http://pastebin.ubuntu.com/6450947/
<davecheney> brilliant
<davecheney> can you generate a new user and try to authenticate with that user ?
<zradmin> oauth or just logon to the webpage
#juju 2013-11-21
<zradmin> just created a test user and was able to authenticate to maas through the webpage
<davecheney> zradmin: via juju
<zradmin> ah ok so create another api user and stand up a second juju environment?
<arosales> zradmin, that is how I read davecheney suggestion
<zradmin> yeah, I'm setting it up currently
<arosales> zradmin, cool
 * arosales grabs some dinner
<AskUbuntu> Creating a charm | http://askubuntu.com/q/380207
<ankrj> Hello everyone!
<ankrj> What kind of an environment do I need t osetup in order to start writing charms?
<jaywink> ankrj, you will find everything you need here: https://juju.ubuntu.com/docs/authors-charm-writing.html
<makara> hi. Juju sounds like a good idea, but I'm skeptical
<makara> suppose I want to deploy a Wordpress instance
<makara> what type of instance would I get? I just want a microinstance - the smallest, least powerful option
<makara> but I've been having trouble with Wordpress because it keeps the siteurl in it's DB, and then when I associate the instance with a static IP, the DNS changes, and Wordpress breaks
<makara> since juju is the to cloud what apt is to a system, changing an IP address would be like messing with the directories APT installs to
<makara> what are your experiences?
<makara> how can I deploy an EC2 t1.micro instance instead of an m1.small instance?
<makara> terminal hangs after: juju deploy --to 0 wordpress
<makara> ctrl+c
<makara> juju status
<makara> hangs
<mthaddon> makara: you can specify whatever instance size you want - that's independent of the charms you're deploying (e.g. wordpress or mysql)
<mthaddon> makara: see https://juju.ubuntu.com/docs/charms-constraints.html
<makara> mthaddon, ok thanks, but I have another problem now
<makara> juju is hanging
<makara> so I go "juju status" and it doesn't give me anything
<mthaddon> it may be that the instance is too small to run juju and wordpress - but I'm not sure of the best way to troubleshoot unless you already know the IP and can login to the instance to diagnose
<makara> mthaddon, juju is running on my own machine
<makara> i'm deploying an m1.small instance
<makara> it deploys it, but then juju hangs
<mthaddon> well, you're using the juju client from your own machine, but juju itself is running on the m1.small instance
<mthaddon> so I'd try to login to that instance directly and troubleshoot - I assume this is EC2 and you can use other tools to figure out the IP of the instance, etc.
<makara> mthaddon, ok, well if I have to do that then first impressions aren't going very far
<makara> its why I would want to use Juju in the first place
<mthaddon> fair enough - I'm not a juju developer, just a user like yourself, so others may have better troubleshooting advice
<marcoceppi> makara: what version of juju are you using (juju version) ?
<makara> marcoceppi, 1.16.3-raring-amd64
<marcoceppi> makara: awesome, you've got the latest. You shouldn't expereince problems deploying to amazon, sorry you're having a poor first time experience
<marcoceppi> makara: so what happens when you run `juju status --debug --show-log` ? Could you paste that to http://pastebin.ubuntu.com
<marcoceppi> makara: it may help us debug what's going on
<makara> marcoceppi, there's a bit too much revealed in this log for my liking
<marcoceppi> makara: you can mask IP addresses or PM me if you want it outside of the channel
<makara> marcoceppi, its private key data, security keys, etc
<makara> marcoceppi, i've taken that out: http://pastebin.ubuntu.com/6453412/
<ashipika> hello juju world..
<ashipika> manual provisioning.. bootstrapped one host, added another.. both ubunu 12.04.. tried deploying tomcat7.. but it is stuck in pending state
<ashipika> and for the second machine i added it says instance-state:missing
<ashipika> any ideas?
<marcoceppi> makara: is i-d3b6399c actually running on your account right now?
<marcoceppi> ashipika: can you ssh in to that machine? the instance-state:missing?
<marcoceppi> ashipika: also, manual provisioning is still very much under development
<ashipika> i can ssh manually, yes.. but not via juju
<ashipika> Permission denied (publickey,password).
<marcoceppi> ashipika: that's fine, manually ssh for now
<ashipika> but how come the state is missing?
<marcoceppi> ashipika: that's what I'm trying to help you figure out
<marcoceppi> ashipika: again, manual provisioning is not a stable juju feature yet
<ashipika> i understand that.. how can i help decypher this problem?
<marcoceppi> ashipika: again, ssh in to the server and I can help you troubleshoot the problem :)
<ashipika> i'm in :)
<marcoceppi> ashipika: run `initctl list | grep juju` what do you get?
<ashipika> jujud-machine-4 start/running process 2869
<marcoceppi> ashipika: can you install pastebinit then run `cat /var/log/juju/machine*.log | pastebinit`
<ashipika> http://paste.ubuntu.com/6453560/
<marcoceppi> ashipika: that's the problem
<marcoceppi> ashipika: where is the bootstrap node?
<ashipika> on another machine.
<marcoceppi> ashipika: is that other machine your local machine?
<ashipika> no
<ashipika> the bootstrap machine is at 192.168.1.108, while this machine is 192.168.1.110
<marcoceppi> ashipika: the address it's getting for the bootstrap node is ubuntu.; this leads me to believe that the bootstrap node doesn't have proper hostname setup for it
<marcoceppi>  dialing "wss://ubuntu.:37017/"
<ashipika> oh! it's trying to contact mongodb at ubuntu.?
<marcoceppi> ashipika: well, it's trying to contact the bootstrap API at ubuntu.
<ashipika> ok
<marcoceppi> which connects to mongo, so essentially yes
<ashipika> so i need to fix hostname at the bootstrap host?
<marcoceppi> ashipika: it's got a bad address resolution. make sure the bootstrap machine has proper hostname that's mappable in the system
<marcoceppi> yeah
<ashipika> why not ip? why hostname?
<marcoceppi> ashipika: what did you set as the bootstrap node for the manual provisioner?
<marcoceppi> again, improvements to this feature are being made
<marcoceppi> this isn't the final product for manual provisioning
<ashipika>  maas-server: 'http://192.168.1.1/MAAS/'
<ashipika> in the .yaml file
<ashipika> sorry.. wrong file..
<ashipika> but i set the ip for the boostrap-host: 192.168.1.108
<marcoceppi> interesting
<marcoceppi> ashipika: can you `cat /var/log/cloud-init/*.log | pastebinit`
<ashipika> on the bootstrap server?
<marcoceppi> ashipika: on the machine-4
<ashipika> no cloud-init folder in the log folder..
<marcoceppi> how about a cloud-init.log in /var/log?
<ashipika> nope
<marcoceppi> hum, cloud-init had to run somewhere on that machine
<ashipika> i can't see any logs
<marcoceppi> ashipika: apt-get install tree, `tree /var/log | pastebinit`
<ashipika> http://paste.ubuntu.com/6453610/
<makara> marcoceppi, no, I terminated it
<marcoceppi> makara: okay, well run juju destroy-environment to clean up, then try bootstrapping again. This time use --debug and --show-log flags. If after a few moments you can't run juju status and get output, sanitize the log and paste it for me
<marcoceppi> ashipika: interesting. No cloud-init log anywhere. Regardless, update the host of your bootstrap node, stop the juju-machine-4 upstart, delete /etc/init/juju-*, then try adding it again
<ashipika> ok.. thank you very much
<makara> marcoceppi, I'll post it tomorrow 6 UCT
<marcoceppi> makara: I'm EST (UTC-5) so I won't get it for a few hours, but I'll look for it when I awake
<makara> k
<X-warrior> is anybody using elasticsearch/logstash with juju? I'm trying the elasticsearch charm but it is failling
<marcoceppi> X-warrior: I know it's been deployed a few times, where is it failing?
<X-warrior> on deploy, the hook start is failling ' HOOK WARNING: ElasticSearch may have failed to start.'
<marcoceppi> thats not very helpful
<X-warrior> I guess it is not juju faults, it is something related to ElasticSearch, let me dig into it
<X-warrior> brb
<x-warrior> What does this means? "ERROR no CA certificate in environment configuration" ?
<x-warrior> I'm able to connect to one environment, but when I try to connect to otherone, I receive this error
<marcoceppi> x-warrior: did you bootstrap from that machine or another machine?
<x-warrior> marcoceppi, another machine
<marcoceppi> x-warrior: yeah, that's why
<marcoceppi> x-warrior: you need to copy the certs from that machine to this one
<x-warrior> you mean .ssh certs?
<x-warrior> because I'm able to ssh directly to the machine
<x-warrior> without using juju
<x-warrior> marcoceppi, have to go now, talk about this with u tomorrow, have a good one
<x-warrior> ty
<InformatiQ> i was searching for a directory server in the charm store, didn't find anything i know. anyone has an idea if there is one?
<InformatiQ> i would tend to see that as an important part
#juju 2013-11-22
<InformatiQ> good morning
<noodles775> Morning InformatiQ :)
<AskUbuntu> Installing and start using juju in ubuntu | http://askubuntu.com/q/380695
<InformatiQ> this juju thing is threatning my job
<noodles775> InformatiQ: heh - I was beginning to wonder when you sleep. I take it you're not yet able to use juju in your sysadmin roles?
<InformatiQ> noodles775: i got excited about juju and was spending a few evening hours on it :)
<InformatiQ> no i can't get it into my dayjob
<InformatiQ> we are quite strict about what we use, change is not something that is liked around here
<InformatiQ> and I still need to grasp it better
<noodles775> Yep.
<InformatiQ> noodles775: i get that you actuall do juju as dayjob
<noodles775> InformatiQ: actually not... I do get to spend some time (probably around 15% of my time at the moment) working on the occasional charm, but that's about it. I'm just excited about juju+ansible :)
<noodles775> Although, I do use juju in other work (like currently deploying openstack-swift+keystone using juju so I can work on some development stuff)
<jamespage> marcoceppi, hey - I'm really struggling with the amulet package in the stable PPA
<jamespage> its trying to run as python3 - is that right?
<AskUbuntu> juju status machines 1 2 3 instance-id: pending forever | http://askubuntu.com/q/380716
<AskUbuntu> OpenStack Havana with Juju/MAAS : no Quantum API server listening for requests | http://askubuntu.com/q/380718
<marcoceppi> jamespage: yes, that's correct
<jamespage> marcoceppi, the deps on the package are incorrect then
<marcoceppi> jamespage: everyone scared me, saying trusty would come with py3 as default, so I figured I'd make amulet Python3
<marcoceppi> I love messing up things
<jamespage> I hit a syntax issue as well
<jamespage> this was on saucy
<marcoceppi> syntax error?
<marcoceppi> jamespage: what syntax errors?
<jamespage> marcoceppi, http://paste.ubuntu.com/6458233/
<jamespage> marcoceppi, that might be me being dumb - hold the line
<jamespage> yeah - the python3 thing was confusing me
<jamespage> working OK now
<marcoceppi> jamespage: cool, I'll have to figure out what I did wrong in packaging to get it to go to the proper python3 namespaces
<marcoceppi> I'll fix that in the next release of amulet, should be coming out 2nd of dec
<marcoceppi> jamespage: any suggestions? I followed what was on the appdev website: http://developer.ubuntu.com/packaging/html/python-packaging.html#debian-rules
<marcoceppi> jamespage: actually, I'll dig more myself and comeback if I can't figure it out
<jamespage> marcoceppi, where is your packaging branch?
<marcoceppi> jamespage: not uploaded, that would probalby help
<marcoceppi> jamespage: lp:~marcoceppi/amulet/pkg I need to learn to use recipes, but that's the packaging I'm using
<jamespage> marcoceppi, I don't think you should have moved to python3 - bzrlib does not support it yet
<marcoceppi> jamespage: soo, I've made a mess
<marcoceppi> jamespage: I'll pull back to py2 then
<jamespage> marcoceppi, +1
<marcoceppi> jamespage: thanks!
<marcoceppi> makes packaging easier. I'll just do the future stuff for print, etc as to not undo all the work. I don't think I'm doing anything too terribly py3 specific
<SuperMatt> marcoceppi: fyi, I've got my juju charm working, and now the relations are working perfectly! I'm sure I could have got this working yesterday, but I wasn't in the office :)
<marcoceppi> SuperMatt: awesome! glad to see you've made progress
<marcoceppi> How's it been so far?
<marcoceppi> the whole charm thing
<SuperMatt> I quite like it
<SuperMatt> it's one of those things I could get in to
<marcoceppi> SuperMatt: awesome!
<InformatiQ> what's up guys
<InformatiQ> this place is too quiet in general
<sarnold> InformatiQ: the last week has been crazy for everyone, what with vUDS going on .. next week includes US federal holiday, so it may also be quieter than normal..
<InformatiQ> so is everyone here US based?
<sarnold> funny, I've never thought to ask :)
<InformatiQ> heh
<marcoceppi> InformatiQ: the Juju and Ecosystem team are spread out around the world
<marcoceppi> we have members in the US, South America, Austrailia, and Europe
#juju 2013-11-23
<AskUbuntu> Charms and juju. Why there are no charms under saucy? | http://askubuntu.com/q/381120
<AskUbuntu> How to access to juju-gui | http://askubuntu.com/q/381182
<gadlinux> Hi there
<gadlinux> I'm reading about mysql deployment on saucy
<gadlinux> and I'm very surprised to see that mysql is not supported to be deployed on saucy
<gadlinux> I'm getting a weird error, same than in log
<gadlinux> any help here?
#juju 2013-11-24
<cjohnston> When trying to setup juju to work locally I get: WARNING unknown config field "$JUJU_HOME"   $JUJU_HOME is commented out in ~/.juju/environments.yaml  - any ideas?
<hatch> cjohnston have you tried removing that line entirely?
<cjohnston> no, assumed it would understand the comment
<hatch> well typically it does as long as it's a valid comment in yaml
<hatch> I can't really tell without seeing the file
<cjohnston> hatch: removed it, still happening
<cjohnston> one sec, let me clean it
<hatch> https://juju.ubuntu.com/docs/config-local.html
<hatch> cjohnston make a backup of your current environments.yaml and then `juju generate-config --show`
<hatch> as per those docs
<cjohnston> hatch: http://paste.ubuntu.com/6469924/  the relevant parts
<hatch> hmm yeah that all looks good to me, I am guessing that there is something else in the file
<hatch> I'd try to generate a raw config file to see if that works
<cjohnston> http://paste.ubuntu.com/6469939/
<cjohnston> hatch: ^
<hatch> hmm I am totally out of ideas
<hatch> cjohnston I suppose the only other thing I can offer would be to bootstrap with -v
<hatch> it -may- give you more information
<cjohnston> hatch: hrm.. I guess it somehow already had a bad bootstrap.. destroy-env and I am kinda back up and running
<cjohnston> now a complaint about CA cert
<hatch> ahh darn, well at least it's closer :)
<cjohnston> :-)
<cjohnston> thanks hatch
<hatch> cjohnston np - curious, was it the -v which told you you had a problem or did you just try to destroy first?
<cjohnston> -v
<hatch> ahh great :)
#juju 2014-11-17
<josepht> is any hook triggered when a service is exposed?
<jose> josepht: nope, the only thing that happens is that the ports are opened for the external world to connect to
<josepht> jose: thanks
<mrjazzcat> Is there a way to turn off the juju engine for a while, to leave the environment in a certain state?
<lazyPower> mrjazzcat: when you say turn off the juju engine - i'm assuming you mean halt the state-server so no agents receive any further events for the duration of teh state-server outage?
<mrjazzcat> lazyPower:  That's it exactly
<lazyPower> that would be my recommendation then - just halt the state-server machine for the duration of the desired "locked config"
<lazyPower> er
<lazyPower> "locked state"
<mrjazzcat> lazyPower:  Is there a method to halt it?  kill <pid>  ??  Better?
<lazyPower> mrjazzcat: well i was referring to actually halting the VM
<mrjazzcat> lazyPower:  Ah, OK.  Thank you!
<lazyPower> it does have an upstart job - let me see what i can fish up
<lazyPower> mrjazzcat: if you want to just halt the services, look like juju-db and jujud-machine-0 are the jobs to stop
<lazyPower> so, service jujud-machine-0 stop should be sufficient. as thats the state-server api process
<mrjazzcat> lazyPower:  awesome.  I'll try that.  Thanks again
<appelgriebsch> hello, I tried to use JuJu on a dedicated Ubuntu Server 14.04 LTS installation in our office network (http proxy enabled) with the local (LXC) adapter
<appelgriebsch> everything bootstraps fine and juju status shows the agent running on local machine
<appelgriebsch> but doing a juju deploy juju-gui failed when trying to access the web repo
<appelgriebsch> have set the environment variables for the proxy (juju set-env http-proxy=...) but did not solve the issue
<appelgriebsch> does someone has an hint how to proceed?
<appelgriebsch> btw: doing a curl with the URL (something like https://charm...) works fine on the server
<lazyPower> appelgriebsch: From the parent that worked - have you tried in the lxc-container the local provider allocated?
<appelgriebsch> lazyPower: sorry, I don't understand your proposal. Everything was executed on one machine. Accessing the web repo via juju doesnt work. Doing a curl request (manually) from the same machine to the URL listed in the juju error message works fine
<lazyPower> appelgriebsch: ah sorry for the confusion. The local provider spins up light weight containers to emulate a cloud to deploy services - if the networking on your host is fine doesn't necessarily mean your containers aren't inheriting the same config. What iw as asking is if you have tried to ssh into that machine:  juju ssh juju-gui/0 , and then try executing the command
<lazyPower> since you mentioned a proxy is being set - i imagine the error here is the proxy isn't being inhereted by your juju env - and your communication isn't being routed properly through that proxy
<lazyPower> i've got limited experience witht his and will tap someone else to see if they can help you - 1 moment while i put out a request for help
<lazyPower> natefinch: when you juju-set http-proxy on the local provider, are all your lxc-containers expected to inheret that config as well? or have I missed something in the docs.
<jose> beisner: hey, mind a quick PM?
<beisner> o/ jose
<jose> o/
<natefinch> lazyPower: it's an environment-level property, so it really should be respected by everything
<lazyPower> natefinch: ack. a user joined up experiencing the issue and has susequently left - but I thought that was the case.
<lazyPower> ty for clarification
<natefinch> lazyPower: though what I hear is "blah blah local provider"
<natefinch> lazyPower: and the answer is almost always "that's not what local provider is for"
<natefinch> unfortunately, I think way too many people misunderstand how juju works, and try to use local provider instead of just deploying to a machine and adding LXC containers to it.
<lazyPower> natefinch: understood and agreed
<lazyPower> natefinch: When I wrap up this weeks video overview of the rudder/lxc stuff - would you mind giving it a proof watch before i publish - i bet you've got some insight into this topic I may miss.
<natefinch> lazyPower: sure, though lxc is not my forte... but I can give it a once-over
<lazyPower> the more eyes the better quality the output will be is my thought :) Thanks for the pledge natefinch
<lazyPower> this one has taken me longer than I care to admit circling back to
#juju 2014-11-18
<rick_h_> juju gui release love http://jujugui.wordpress.com/2014/11/18/juju-gui-1-3-0-released-now-with-added-services-view-2/ and https://plus.google.com/116120911388966791792/posts/7TAs5UiubKj and https://plus.google.com/116120911388966791792/posts/cbnGW5iw2Hy
<stub> Are there any magic filenames that are ignored when juju packages a charm for deployment? I want to have a Python virtualenv in my charm directory containing pip installed package dependencies, which all goes well until deployment fails due to it containing symlinks outside of the charm.
<rick_h_> stub: we build them in the charm
<rick_h_> stub: you might be interested in our 'make deploy' target stuff http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/Makefile#L68
<rick_h_> stub: we use that so from our dev checkout we can rerun that and redeploy the charm and have it build/etc.
<stub> rick_h_: That seems to be what I'm doing, except when things get as far as amulet invoking juju-deployer invoking juju, it explodes because the charm contains the .venv containing symlinks outside of the charm directory.
<stub> rick_h_: Do you repackage your charm without the .venv and deploy that instead?
<rick_h_> stub: I'm double checking what the deploy target does. I believe so.
<rick_h_> stub: because when we do a real release the charm builds the venv from a local download cache of the python deps
<rick_h_> stub: so that way it mirrors a real deploy
<stub> My .venv is being used to install dependencies the amulet tests need, so I don't need it pushed as part of the charm.
<rick_h_> stub: yea, we split that into test-requirements and actual requirements
<rick_h_> stub: so we've got the  server-requirements.pip vs test-requirements.pip
<lazyPower> cargill_: cheers on your mail to the list, thanks for the follow up
<stub> I'm getting very confused.
<stub> On one hand, my amulet tests fail to deploy if they contain symlinks outside of the charm. These are not under revision control.
<stub> If I remove the symlink issue, I have a different problem where only the version of my charm that has been committed is being tested, with uncommitted changes ignored.
<stub> is this explainable, or do I just need to try again tomorrow with a freshly caffeinated brain?
<jcastro> marcoceppi, ping
<lazyPower> stub: do you have 2 copies ofthe charm in your juju_repository?
<rick_h_> stub: ok, so there's something there in that. I know we hit an issue because amulet bzr'ifies your stuff? We hit issues with our git charm because of amulet trying to do bzr things but we wre using bzr-git and there was no .bzr. So I wonder if amulet is messing with you
<stub> lazyPower: I no longer have $JUJU_REPOSITORY set (separate bug - amulet packaging up the charm I'm development and stuffing it in there without permission)
<stub> rick_h_: I suspect it is actually juju-deployer hiding in there, but yeah, sounds familiar
<lazyPower> stub: just making sure you weren't hitting this: https://bugs.launchpad.net/juju-core/+bug/1260170
<mup> Bug #1260170: local charms are not deploy by filename <charms> <deploy> <juju-core:Fix Released> <https://launchpad.net/bugs/1260170>
<lazyPower> tvansteenburgh: How much bzr magic are we still doing in amulet?
 * tvansteenburgh reads scrollback
<lazyPower> starts at 9:11:59
<lazyPower> o, no it goes further back, my b
<tvansteenburgh> stub: yes this is a limitation of amulet, b/c it's a limitation of deployer
<stub> ta
<stub> I can probably stuff my charm through tar into a tempdir and have amulet test that instead
<tvansteenburgh> i noticed recently that we pass -L to deployer from amulet; removing that may solve the "doesn't deploy uncommitted changes" prob
<stub> I'll look at that tomorrow, maybe a patch to amulet is possible.
 * stub wanders off in search of late dinner.
<mbruzek> Hey lazyPower someone opened a bug for a new charm, but it is not yet ready for review.  What is the correct state for the bug to keep it from going in the review queue?
<mbruzek> I was thinking "In Progress" but there is also "Incomplete"
<lazyPower> IIRC we just need to set the bug to "in progress" or "incomplete" and leave a follow up
<lazyPower> the status + comment combo will do its due dilligence to put it in teh proper bin in the queue
<lazyPower> when the bug author makes an update, it will see activity and move it back into the active state in the queue
<lazyPower> rick_h_: quick update - worked on the first load, reloading the page brought the breakage to ff
<lazyPower> gah wrong channel - sorry :(
<rick_h_> lazyPower: it's ok, I'll find you whereever you hide
<lazyPower> abandon thread!
<hazmat> stub, tvansteenburgh, deployer uses the standard bzr api... it should work with plugins .. but its only going to do it if you specify vcs for the charm
<hazmat> tvansteenburgh, oh.. uncommitted changes, yeah -L should do it
<hazmat> stub, tvansteenburgh, the alternative is don't use branch: to pull the charm.. not sure if amulet is doing something around that
<tvansteenburgh> hazmat: in a deployer file is it possible to specify a local charm w/o using branch: ?
<hazmat> tvansteenburgh, definitely .. just set JUJU_REPOSITORY   and use charm: charm_name
<tvansteenburgh> hazmat: ok cool, i may be able to make amulet handle this better then
<mgz> gnuoy: bug 1392602
<mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
<jcastro> hey lazyPower
<lazyPower> yo yo jcastro
<jcastro> any videos from last week worth posting on insights? are they reusable or were they specific?
<lazyPower> jcastro: everything from day 1 was instructional
<lazyPower> specifically the first 5 minutes charming, and charm testing
<jcastro> ok so I can reuse those?
<lazyPower> yep
<lazyPower> charm helpers didn't do as deep of a dive as I would think useful - we covered a lot of what is in there, and how to get into it + some of the future of charm helpers
<lazyPower> maybe give that one a watch and make a yey/ney vote - but i'm leaning towards ney
<lazyPower> jcastro: also the open feedback session was stellar
<jcastro> might want to post a link to it to the list?
<jcastro> I'm looking for the reusable ones for the website.
<mgz> gnuoy: you can find the lxc-specific log for start issues in for eg /var/lib/juju/containers/ubuntu-local-machine-1/container.log
<gnuoy> mgz, http://paste.ubuntu.com/9075776/
<mgz> gnuoy: first ERROR line in that paste seems the relevent part, not sure why you're getting that
<mgz> gnuoy: check your lxc mount settings?
<skay> is anyone around who works on the python-django charm?
<jose> rcj: ping
<jose> skay: hey, what's up? probably can give you a hand
<skay> jose: there are some changes I'd like to propose, but it looks like there is a big merge request about to land. does Patrick hang out here? I was wondering when it might land
<skay> jose: I'd like to have an option to pip install from local files
<jose> avoine: ^
<skay> jose: so basically, for example, pass --no-index --find-links=wheelhouse -r requirements/ci.txt
<jose> he hasn't been around for about 4h, so probably not here
<jose> if the MP is open, then it should be landing soon (if no errors are found)
<skay> and while I was looking at that, I see that you can import some things from pip, and maybe could call it directly. on the otherhand, it's not a public api so that could be a bad idea
<skay> jose: there's a failing test for hte merge request, and I don't know where he is on fixing that. no new comments
<jose> skay: lemme check, one sec!
<skay> I could clone his branch and do what I need and then hop the merge request lands soon, then propose changes
<skay> but I'd rather not
<jose> skay: that will probably create a merge conflict, since the lander is usually someone different and revisions and stuff
<jose> skay: could you PM me your email address? I'm going to send an email to Patrick and CC you in, asking for the status. sounds good to you?
<skay> sure
<jose> cool :)
<avoine> skay: hi
<skay> avoine: hi
<skay> avoine: I'm interested in having python-django be able to install dependencies from local files. is this something that you'd like in python-django?
<avoine> skay: you could probably use the pip_extra_args config variable
 * avoine is reading the backlog
<skay> avoine: oh thanks, I missed that! that may be all I need!
 * skay is looking through source code
<avoine> skay: hmm, It won't with the charm currently in the store I think
<avoine> won't work
<skay> okay, looking through pure-python branch now (that one?)
<avoine> yeah this is the target for charm store
<skay> avoine: I'll go ahead with using that one for now and maybe post to the juju mailing list if I need help (or chat here)
<jose> marcoceppi: is there any way to force-update the review queue? it's taking me through several items that have already been promoted
<avoine> skay: the pip_extra_args was added in an other version of the charm but the code was never backported to the pure-python branch
<avoine> but that would not be too hard to do
<skay> avoine: oh. I see the config file with the option is in the pure-python branch. (I just checked)
<skay> I haven't checked the source code yet to verify that it uses it though
<skay> I guess if it is not backported, I could make my own branch and use that for now?
<avoine> skay: yes you could do that
<skay> avoine: which branch is using the extra args feature?
<avoine> skay: this one: http://bazaar.launchpad.net/~patrick-hetu/charms/precise/python-django/ansible/files
<jose> whit: ping
<whit> hey jose
<jose> whit: have a min?
<whit> jose, kinda in the middle of something
<jose> whit: was just wondering where you had found the typos on https://bugs.launchpad.net/charms/+bug/1374085/comments/5, since I cannot find them
<whit> jose, ah, whatever. what's up?
<mup> Bug #1374085: New Shoutcast Charm <Juju Charms Collection:In Progress by lazypower> <https://launchpad.net/bugs/1374085>
<jose> :P
<jose> found the '(p)assword' one, but cannot find the admin one
<whit> jose, in the readme?
<lazyPower> oh my, i put assword as a config options. Clever
<jose> :P
<whit> iirc, I noticed it because it broke cutting and pasting
<jose> hehe
<jose> erm, let's check...
<jose> found it
<whit> cool
<jose> thanks :)
<whit> nw
<skay> avoine: from a cursory glance, it seems only people who are using ansible in conjunction with juju will be able to use the pip_extra_args feature
<skay> avoine: please let me know if I've misread things
<avoine> skay: no your right
<skay> avoine: maybe I could fork teh pure-python branch and then make a change so that I can use that with the hook.py code. would that be something helpful to contribute later? or perhaps someone is doing that already
 * skay wants to use a charm store charm, ultimately
<avoine> skay: I'll merge your changes for sure
<jose> lazyPower, mbruzek, marcoceppi: authorization to promulgate shoutcast (https://bugs.launchpad.net/charms/+bug/1374085), haven't found any errors
<avoine> skay: as soon as the branch is merge in the store we could add feature to it
<mup> Bug #1374085: New Shoutcast Charm <Juju Charms Collection:In Progress by lazypower> <https://launchpad.net/bugs/1374085>
<lazyPower> I'll defer to mbruzek as i'm the author
<jose> ack
<lazyPower> jose: did you fix up those typos for me?
<lazyPower> i dont think we want end users looking for ***word
<jose> lazyPower: I did, don't worry. people won't have to set that config option :P
<lazyPower> solid
<rcj> jose, I'm at a sprint this week but I can't get to work on the nrpe charm test failure next week if not sooner.
<jose> rcj: sounds good, thanks :)
<rcj> jose, that was the question, right?  not sure now reading the backlog if I confused this with conversation you were having about the  python-django charm.
<mgz> gnuoy: try deleting /var/lib/lxc/juju-trusty-template or similar, Ian suggests
<gnuoy> ack, will do
<gnuoy> mgz, wallyworld_ fixed !
<gnuoy> thank you
<wallyworld_> gnuoy: that's good news, and highlights something we should deal with
<gnuoy> tip top
<wallyworld_> thanks for finding the issue
<jrwren> 150% faster mongodb deploys: https://code.launchpad.net/~evarlast/charms/trusty/mongodb/trunk/+merge/242136  eco folks ;]
<rcj> jose, Just re-read my earlier comment and realized that I mis-typed.  I can't get to work on the nrpe charm until next week most likely.
<lazyPower> jrwren: merged
<jrwren> lazyPower: ! thanks!
#juju 2014-11-19
* lonroth changed the topic of #juju to: /join #android-dev
* lonroth changed the topic of #juju to: lonroth
* lonroth changed the topic of #juju to: Juju
<lonroth> sorry about that =D
<skay> hi juju. I have managed to get my laptop in to a crazy and exciting state
<skay> I got in to a state where juju calling lxc-create had this problem http://paste.ubuntu.com/9096762/
<skay> agent-state-info: 'error executing "lxc-create": Container already exists'
<skay> and did call juju destroy-environment a gazillion times, lxc-ls did not list anything for the machines, so then resorted to trying to clean things up by hand
<skay> by going around to /var/lib/juju/containers and deleting the image directories
<skay> etc
<skay> now I get an exciting error when I try to bootstrap http://paste.ubuntu.com/9096721/
<skay> now I just need to grind until I kill the big boss
<mbruzek1> hello skay
<mbruzek1> Are you using sudo with the lxc-ls  command?
<skay> mbruzek1: yes
<skay> mbruzek1: it's int he pastebin. I called: sudo lxc-ls --fancy --nesting
<mbruzek1> looking
<skay> mbruzek1: got two pastebins.
<skay> mbruzek1: I think I've managed to royally screw things up after trying to do manual cleanup
<mbruzek1> skay: it looks like it, still reading.
<skay> mbruzek1: I'll probably need to figure out how to clean up everything. drastically.
<mbruzek1> Definitely looks like an lxc related problem.  I have not seen where lxc-destroy fails.
<mbruzek1> OK lets do this.
<mbruzek1> juju destroy-environment -y local --force
<mbruzek1> delete the images in /var/lib/juju/container/*
<skay> mbruzek1: I did try --force, I will try again
<mbruzek1> skay: I am sure you did, I just want to get juju to stop talking to those images
<skay> along with deleting the images in /var/lib/juju/container/*
<mbruzek1> Looks like you have problems destroying the images.
<skay> mbruzek1: thanks, it does make sense to try all the steps because I must have missed something
<mbruzek1> sudo lxc-ls --fancy
<mbruzek1> do you see any containers running?
<mbruzek1> skay also delete things in /var/lib/lxc/juju*
<mbruzek1> if there is anything there
<skay> mbruzek1: no, but it shows some as STOPPED. which I wouldn't expect. sanity check. http://paste.ubuntu.com/9097472/
<mbruzek1> ok is there anything in /var/lib/lxc/juju*?
<skay> mbruzek1: yes, and I deleted it. lxc-ls no longer shows anything. that is hopeful
<mbruzek1> I think we are getting somewhere.
<mbruzek1> Let me check if there are any other clean up bits I do
<mbruzek1> Ok delete everything in /var/lib/juju/locks/*
<skay> mbruzek1: done. and there were things in there
 * mbruzek1 nods
<mbruzek1> OK if you sudo lxc-ls shows nothing more I think you should try another bootstrap.
<mbruzek1> skay: juju bootstrap -v -e local --debug
<skay> mbruzek1: thanks! sudo lxc-ls shows nothing, so here goes
<skay> mbruzek1: debug starts tmux right? (I've not tried it yet.)
<skay> mbruzek1: and I'm tmux already. maybe I should get out
<mbruzek1> no it just prints out an obnxious amount of data
<roadmr> obnoxiousness ftw
<skay> not seeing any ERRORs... yet
<skay> OH NOES
<mbruzek1> ?
<skay> let me pastebin it.
<skay> last line shows hte error, http://paste.ubuntu.com/9097595/
<skay> mbruzek1: there is this blog post, http://blog.naydenov.net/2014/03/remove-juju-local-environment-cleanly/ and I didn't kill the mongod or jujud processes, so let me check that (earlier today I did look for a running juju process, but I didn't know to check for mongod)
<skay> though, ps aux | grep mongo doesn't find anything
<mbruzek1> skay: Yeah I was looking at that kind of script I have on my own system, it is home made so nothing official let me pastebin something for you
<skay> mbruzek1: thanks!
<mbruzek1> http://pastebin.ubuntu.com/9097629/
<mbruzek1> It started with Jorge's ask ubuntu post but I have added and removed from it
<mbruzek1> skay: It looks like you had juju running before.  Did you change anything recently?
<skay> I can't figure out if I did before I started having hte problems. last night I was pretty frustrated and figured why not upgrade to utopic.
<skay> so I did. similar things are happening today, so I don't know how much that would have changed things, except now my 0 is utopic
<mbruzek1> OK.  So there are no juju or mongo processes running now right?
<mbruzek1> Did you try the clean script?
<skay> correct. I'm currently looking through the script to see what it does, and was listing the directories to see if they have anything in them before running the script because Im curious whether I had cleaned up everything
<skay> and then I'll run the script for good measure
<mbruzek1> skay: We tried the major parts of this script I would be surprised if it fixes your problem.  So you recently updated to utopic.  Do you have default-series:  set in ~/.juju/environments.yaml?
<skay> mbruzek1: yes, to precise
<mbruzek1> skay: run the script and let me know if you see anything clean up better.
<skay> ok
<skay> mbruzek1: it failed, http://paste.ubuntu.com/9097960/
<skay> I notice that the script only deletes cloud-{precise,trusty}, and I see download and trusty in that dir. would it affect this?
<skay> and, any reason not to delete /var/cache/lxc/cloud-*
<mbruzek1> skay: Yes this script is pretty old and "unofficial" so updates for utopic
<avoine> skay: do you have any mongodb in your /var/log/syslog?
<avoine> *mongodb errors
<mbruzek1> would be needed in your case
<avoine> I found that cleaning running lxc vm and /var/lib/juju/ is enought for me most of the time
<skay> avoine: http://paste.ubuntu.com/9098077/
<avoine> skay: do you have a local IP address in the 10.x.x.x range?
<skay> avoine: ifconfig shows lxcbr0 with one
<avoine> that's ok
<skay> avoine: if lxc-ls doesn't show any containers, should lxcbr0 still show up?
<avoine> I was suspecting a bug I had last week but I seams to be something else
<avoine> skay: yes
<avoine> skay: Have you tried to boot up an lxc node manually?
<avoine> with something like: lxc-create -t ubuntu -n ubuntutest
<skay> avoine: I can't remember if I've tried that today, I'll do so now. btw, juju --version gives me 1.20.11-utopic-amd64 in case there is any known issue with that
<avoine> I'm at the same version
<mbruzek1> I was searching for your problem skay and I found this bug https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1346815
<mup> Bug #1346815: lxc-clone causes duplicate MAC address and IP address <amd64> <apparmor> <apport-bug> <utopic> <lxc (Ubuntu):Fix Released> <lxc (Ubuntu Trusty):Triaged> <https://launchpad.net/bugs/1346815>
<avoine> this in your log looks suspicious: start: Job is already running: juju-agent-sheila-local
<avoine> do you have any juju-* process running?
<mbruzek1> avoine: That is the errror message that I searched on
<mbruzek1> to find the bug listed above
<skay> avoine: I thought not, but will check again
<skay> avoine: from my earlier pastebin, I showed ps aux | grep juju and it didn't show any processes other than the grep
<skay> avoine: still nothing showing from that. is there a better way to check?
<skay> avoine: lxc-create still running, btw
<avoine> the "Job is already running" error must be "normal" then
<avoine> I don't use lxc-clone or lxc-clone-aufs so mbruzek1's bug could be it
<avoine> maybe you could try to put them both to false
<mbruzek1> skay: The bug I listed had some pretty easy re-create steps
<avoine> in your environments.yaml
<mbruzek1> skay when you get a chance can we try steps 1-4?
<skay> avoine: lxc-create just finished, sudo lxc-attach -n ubuntutest gives me: lxc-attach: attach.c: lxc_attach: 635 failed to get the init pid
<skay> mbruzek1: I'll try to recreate the bug now
<mbruzek1> skay: I just ran the steps on my machine and I got the "correct" output (different macs)
<skay> also, oops, forgot to lxc-start before attempting to attach to ubuntutest, that works as expected once I did that
<avoine> ok
<skay> mbruzek1: I followed steps 1 through 4, and sudo lxc-ls -f shows bar and foo have different ip addresses.
<avoine> skay: what is you mongodb version? dpkg -l | grep mongo
<avoine> skay: and could you paste what's in /var/log/juju-*-local/all-machines.log
<skay> avoine: ii  juju-mongodb                                         2.4.10-0ubuntu1                                   amd64        MongoDB object/document-oriented database for Juju
<mbruzek1> skay: then I suspect the bug is not our problem
<skay> mbruzek1: which version of mongo do you have?
<mbruzek1> 2.4.9-0ubuntu3
<mbruzek1> I am on trusty
<skay> avoine: nothing in /var/log/juju-*-local/
<mbruzek1> skay: if you got different mac addresses then the bug I found is not the problem
<skay> mbruzek1: true.
<skay> avoine: which mongo version do you have?
<avoine> same as yours
<skay> avoine: are you on trusty or utopic?
<avoine> skay: utopic
<mbruzek1> skay: What is your version of lxc?   (Mine is 1.0.6-0ubuntu0.1)  dpkg -l | grep lxc
<avoine> I have 1.1.0~alpha2-0ubuntu3
<skay> avoine: I've got 1.1.0~alpha2+master~20141106-1929-0ubuntu1~utopic
<skay> avoine: I'm using the ubuntu-lxc daily ppa
<skay> avoine: perhaps I should not?
<mbruzek1> skay is there a reason you are on the daily one?
<skay> mbruzek1: not really
<mbruzek1> skay: Comment #6 of the bug I listed states : This bug was fixed in the package lxc - 1.1.0~alpha2-0ubuntu2
<skay> mbruzek1: I checked and the IPs were different... so probably that bug is fixed in daily as well?
<mbruzek1> It looks like avoine has a later version, I don't know what yours is.  The date looks later
<mbruzek1> yes but since we are having an LXC problem and you are on the daily build I would suspect some other lxc regression is causing this problem.
<avoine> skay: that could be it, try removing it with ppa-purge
<skay> mbruzek1: I'll remove the ppa and stop using daily
<mbruzek1> skay: if there is no particular reason for the daily ppa could you go back to the package lxc?
<skay> mbruzek1: I'll try so
<skay> avoine: which package installs ppa-purge? I do not have that command
<avoine> ppa-purge I think
<skay> haha, go figure
<avoine> it still troubles me that you don't have anything in /var/log/juju-*
<mbruzek1> avoine: If the bootstrap node is not coming up that might be why we have no logs
<skay> avoine: I cleaned up everything, and then after that ran bootstrap, which failed. so what mbruzek1just said is likely the reason
 * skay just joined a meeting, so not as chatty
<skay> appreciate all the help. I just did a ppa-purge, and will try everything over again once the meeting is over
<avoine> mbruzek1: that would make sens
<avoine> maybe checkout in /var/log/upstart/juju-* instead
<dosaboy> jamespage_: https://code.launchpad.net/~hopem/charms/trusty/nova-compute/rbd-imagebackend-support
<dosaboy> jamespage_: as mentioned, not ready for review yet, but hopefully almost
<dosaboy> jamespage_: needs ceph-broker to land first
<darknet_> someone can help me? I've reported a problem deployed all services for Openstack and make all relations between nodes but if I try to open horizon, I see just a white page!!This lab has realized using a Virtual MaaS Server and with 2 Node. I followed this guide http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/
<darknet_> is there anyone can help me
<darknet_> ops sorry I wrote a bad sentence!!
<darknet_> I want to say that I deployed all service and make all relations between node, but when I try to open the dashboard I see just a white page. I've also to try to ping from host the VM using FQDN and it works.
<darknet_> anyone can help me?
<avoine> darknet_: this is either a problem in horizon templates or apache2 is returning you an masked error
<avoine> darknet_: check the apache2 logs for any error
<darknet_> I've also try to connect on node where juju has deployed horizon and restart apache but nothing
<gQuigs> how do I customize the default deployment name?  instead of "juju-canonistack-machine-#"?
<darknet_> this is a log of apache http://paste.ubuntu.com/8615952/
<gQuigs> (I'm running into DNS conflicts as others have used the same name..)
<darknet_> I've followed this guide http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/
<darknet_> avoine_: I've followed this guide http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/
<marcoceppi> darknet_: did you go to horizon-ip/horizon ?
<darknet_> hi marco I've posted on your guide the same problem
<darknet_> I'm sorry but I've to go now I'll connect back about 10 min.
<marcoceppi> jose: charm review queue queue should be updating again
<lazyPower> Great Success!
<gQuigs> answered>  change your environment name.. oops
<jcastro> hey lazyPower
<jcastro> and aisrael
<lazyPower> Whats up jcastro
<jcastro> I noticed the vanilla vagrant boxes are 14.04, not 14.04.1
<jcastro> any idea what's up with that?
<lazyPower> I think the cpc build scripts haven't been updated with the latest base image
<lazyPower> good catch - haven't been in vagrant land in over a month now
<lazyPower> utlemming: ping
<jcastro> lazyPower, hey so, where do we file vagrant box bugs that are not juju related?
<jcastro> is my real question
<jcastro> (I'll also ensure the juju ones are on the list)
<utlemming> jcastro: what do you mean by they are not 14.04.1
<utlemming> jcastro: this is a labeling thing?
<jcastro> well initially it was 14.04
<jcastro> and I upgraded it
<jcastro> to 14.04.1
<utlemming> jcastro: ack, file a bug and we'll get on it
<jcastro> utlemming, we're unclear as to where
<lazyPower> i'm sifting through old email threads looking for that link
<lazyPower> i know we settled on one, but i forget which project
<jcastro> I will also file a bug to add a bug link to the descriptions on vagrantcloud.com
<jcastro> that should make it easier
<lazyPower> adeuring: Abel, were we only tracking bugs based on the vagrant supporting files like the redirector / provisioning bits in the vagrantfile?
<utlemming> jcastro: you can file a public bug against ubuntu and assing it Odd_Bloke
<lazyPower> utlemming: is that the path forward we want with public bugs against the vagrantboxes (i'm thinking vagrantcloud.com listing)? I'm still not finding the bugtracker we have for the box themselves - as its several components to track, and we only settled on the redirector and other sub-components.
<rick_h_> juju do we have any sort of 'recover your juju env' from this azure outage notes going on?
<rick_h_> for instance, we had our CI environment in Juju, it seems to have come back but with new hostnames and juju is quite unhappy. I wonder if there's a standard "what to watch for, tips for recovering" we're putting together and getting out to the public on this?
<darknet_> marcoceppi_: I'm so sorry for before, but I had to go out from office!!!
<lazyPower> rick_h_: yes! i covered this last week
<rick_h_> lazyPower: linky!
<lazyPower> rick_h_: http://blog.dasroot.net/reconnecting-juju-connectivity/
<rick_h_> lazyPower: might I suggest a giant twitter storm referencing the azure downtime and this then if we're sure it's the right way to go?
<rick_h_> and we'll check it out for our env
<darknet_> marcoceppi_: as url I've used http://IP_address/horizon
<lazyPower> rick_h_: sounds good - ping me with what you discover and I'll lock and load some social media candy
<rick_h_> lazyPower: maybe even a juju mailing list email post
<rick_h_> lazyPower: I assume there's got to be > 1 juju on azure user doing :( today
<lazyPower> yeah, global azure outage is going to be a fun run for a lot of users
<rick_h_> lazyPower: yea, proactive canonical response ftw. bac is going to test it out on our env and see how it goes and then we can see about getting a great message out to users
<rick_h_> ty for the link, nice timing :)
<lazyPower> its almost like i knew
<rick_h_> hah!
 * lazyPower waves his arms like a mystic
<skay> avoine: thanks for all the help, bootstrap works again, and things are looking okay. mbruzek1 isn't around to thank. oh well!
<skay> avoine: I did end up rebooting since it didn't work right after ppa-purge and I figured, what the hell, why not reboot
<lazyPower> skay: really happy to hear we got you sorted.
<lazyPower> and i'lli pass along your well wishes to mbruzek when he returns
<avoine> skay: great news!
<skay> lazyPower: I am very grateful. I was almost ready to resort to completely blowing away my laptop and starting over
<lazyPower> ooo, tricky
<lazyPower> glad you didn't have to resort to such extreme measures
<skay> lazyPower: maybe I should see if I can reproduce the problem ina  friendly way in case I uncovered something in a daily build
<skay> but I don't have time for it right now
<skay> and also I feel a bit antsy at the idea since I'd rather do that on a different computer
<lazyPower> skay: i cant say that i blame you there :)
<lazyPower> possibly a vagrant run/build would be in order to test taht so its isolated
<bac> lazyPower: hey, thanks for the doc about reconnecting juju
<lazyPower> bac: np, did that fix ya up?
<bac> lazyPower: our problem seems little more complicated.  they machine that is supposed to be our state server was not brought back up
<bac> s/they/the/
<lazyPower> ah, yeah - if your state server isn't back online - you're hozed
<bac> azure has it marked as created but it isn't running
<lazyPower> until the state-server re-appears.
<bac> lazyPower: yeah, it isn't going to just appear and i don't know how to bring it back
<lazyPower> hmmm..  do you have a snapshot you can re-deploy?
<bac> lazyPower: no, no snapshot
<lazyPower> and/or was your state-server ha-enabled?
<bac> nope
<lazyPower> oh man :(
<lazyPower> i have bad news
<bac> i think we'll be recreating it.
<lazyPower> you're going to need that database on the api server for things to normalize - otherwise you're registering units the state server knows nothing about.
<bac> lazyPower: yeah, we'll just have to redeploy.
<lazyPower> rick_h_: sorry to hear about the trouble - however social media candy has been deployed. Can I get some syndication lovin on that?
<rick_h_> lazyPower: sure thing, will look for it
<skay> pip question... I have a local directory with wheels in it, let's call it /path/to/dependencies. and I've hacked python-django to accept extra pip args in hook.py (versus ansible, which I'm not using at the moment). do I need to mount a shared founder where dependiencies should live? or will the charm "magically" be able to use my local folder?
<skay> my pip_extra_args is "--no-index --find-links=/path/to/dependencies"
<skay> and the python-django hack is http://bazaar.launchpad.net/~codersquid/+junk/pure-python-with-tgz/revision/70
<skay> I'm not going to make a MR based off that, it's just a hack
<avoine> skay: do you plan to shared your wheels package cache with other instances?
<skay> avoine: no
<skay> avoine: I was about to say, currently pip is not finding the files
<skay> I'm trying to dig up the log, I had it in a window a moment ago
<skay> avoine: I get: ValueError: unknown url type: /path/to/dependencies
<skay> pip can handle the path when I run it locally
<avoine> skay: what is your complet pip command?
<skay> avoine: will the juju log echo that? let me scroll back
<skay> avoine: the juju log does not echo that, I will add something to echo the command. I know what I think is the complete command, but in reality I should print it out to see what juju thinks it is
<avoine> skay: it might be that the version of pip in the vm is too old
<avoine> skay: try to add:
<avoine> pip_additional_packages: "pip"
<avoine> in your juju config file
<skay> avoine: okay
 * skay is rerunning everything
<darknet_> someone can help me? I've reported a problem deployed the modules to have Openstack on my infrastructure. I've made all relations between nodes but if I try to open horizon, I see just a white page!!This lab has been realized using a Virtual MaaS Server and with 2 VM Node. I followed this guide http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/
<darknet_> anyone can help me?
<sarnold> darknet_: how long have you 'waited' for everything to start?
<sarnold> darknet_: sometimes a lot of work is hidden behind the 'juju relate ...' calls; I know a recent video I saw for deploying openstack took ~15 minutes or something..
<darknet_> sarnold_: on juju-gui all module and relations are green.
<darknet_> sarnold_: anyway I wait but nothing, the link http://hostname/horizon presents a white page!!!
<lazyPower> darknet_: green relations dont necessarily mean the relationships have completed running
<lazyPower> do you see any output from the units under relation when you run juju debug-log?
<darknet_> lazypower_: but if I run the command "juju status -e maas" I see that everything is started!!!
<lazyPower> darknet_: that just means the charm has reached the started hook - as juju is event driven, and relationships can be called after teh started hook it can be a bit misleading
<lazyPower> darknet_: did you see any output from the units under relation when you ran juju debug-log?
<lazyPower> darknet_: also sorry for teh confusion there - we've had some discussions about this on teh mailing list recently - about charms and hooks providing more accurate reporting
<darknet_> I didn't try to run that.
<darknet_> I promise y that tomorrow I'll post y log
<darknet_> i can do that now
<lazyPower> darknet_: juju debug-log should give you an immediate feedback of whats currently happening in the system. if you have the time, a quick check will yield if we need to start debugging or if this is a time to bepatient while juju finishes its housekeeping.
<darknet_> will y be here tomorrow?
<lazyPower> darknet_: i will be here from ~ 9am EDT to 5pm EDT m-f most weeks.
<lazyPower> er, EST - sorry, timeshift happened and i keep forgetting to update my timestamp.
<gnuoy> Hi, would somebody mind preventing my charmers membership from expiring please ?
<darknet_> ok let's make that and tomorrow I'll contact you
<lazyPower> sounds good darknet_
<darknet_> in case I'll send y a private text
<lazyPower> marcoceppi: gnuoy is running out of time, can you renew him for me please?
<gnuoy> thanks lazyPower
<lazyPower> my pleasure
 * lazyPower hat tips
<darknet_> lazyPower_: just one technical question!
<lazyPower> darknet_: i'm all ears
<darknet_> why in MaaS I've to report the ssh keys of the Host machine, of Region Controller and of a maas user created on RC?
<darknet_> lazyPower_: and also Juju
<darknet_> lazyPower:_ I told y that because everytime I want to run all infrastructure (virtual) I've to use the same network connection otherwise the from MaaS the VM not run
<lazyPower> darknet_: i'm not understanding what you're asking me - let me try to ask what i think you're asking.
<lazyPower> You're questioning why you have to register your ssh keys in the region controller of MAAS?
<darknet_> yes! and why to run the VM node allocated on MaaS I've to use the same connection?
<lazyPower> darknet_: So long as you have a user on the MAAS region controller - and have the api credentials obtained from the RC - juju will automatically register ssh keys that it uses with any nodes spun up. This key exchange happens transparently.
<lazyPower> darknet_: when you ask why are the VM's using the same connection - are you referring to the same network device? This is highly dependent on how you have your MAAS cluster setup, and if this is physical MAAS vs VirtualMAAS
<lazyPower> im' assuming its vmaas - as you're only using 2 machines per marco's post right?
<darknet_> perfect, but if the host where I've installed MaaS change the IP address I can't launch the node via MaaS
<lazyPower> darknet_: if your machine has 2 network devices, that is the recommended path to use - 1 for public traffic access, and the second as the private network (or management network)
<lazyPower> your public network bridge should be bridged into your VM Cluster, the private network can very well be a virtual network created inside of your KVM configuration
<darknet_> ah here is my problem!!!!
<darknet_> my RC has to have 2 interface
<lazyPower> Networking and VMAAS is a very tricky thing - the reasoning being MAAS recommends you run the MAAS DHCP server and DNS - this is the necessity for a private network that exists only within the vlan of that cluster.
<lazyPower> your public network wont have the same requirement, and you're safe to use whatever DHCP/DNS settings are incoming from your bridged network on that particular interface
<lazyPower> it will be a bridged mode networking connection, and helping you get that set up is a bit beyond my scope of knowledge - iv'e done it a few times but its highly dependent on how your network is setup. The best I can offer from where I'm sitting is encouragement and answers to very specific questions.
<darknet_> I explain y my lab....i've on host ubuntu 14.04lts with kvm and virt-manager then with it I've created a VM (MaaS) with just one interface.
<lazyPower> darknet_: the first step to doing any of this is creaeting a bridged interface - do you know how to do that?
<darknet_> I've created a new virtual network (1
<darknet_> 1.1.0.0/24
<darknet_> with virt-manager and I've used that as network for MaaS,
<darknet_> lazyPower_: and for 2 VM,
<lazyPower> darknet_: i just got pulled into a meeting - so far sounds good.
<lazyPower> replies will be latent
<darknet_> lazyPower:_thanks a lot for your supporting see you tomorrow with log!!!
<lazyPower> best of luck darknet_, cheers
* jose changed the topic of #juju to: Welcome to Juju! || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://review.juju.solutions || Unanswered Questions: http://goo.gl/dNj8CP || News and stuff: http://reddit.com/r/juju
<lazyPower> jose: Congrats on your first solo promulgation man. May the juju powers be with you.
<jose> thanks! :)
#juju 2014-11-20
<noodles785> I was wanting to experiment adding egress rules to all units in an environment. I can't do that via constraints or similar juju functionality right? (I'm assuming I'll need to update the default secgroup for the env, which will only work when deploying to openstack/aws, not local)
<rick_h_> noodles775: you could add a subordinate, I've thought of doing that
<rick_h_> noodles775: having a egress filter subordinate that get attched in dev/qa to create firewall rules manually
<noodles775> rick_h_: yeah - I was hoping to do it outside the units themselves (ie. secgroups), but wanted to check whether it's something juju manages (I'm assuming not). Thanks!
<rick_h_> noodles775: I don't think so atm
<skay> I think the charm helper docs for charm create are out of sync with the package, but could use a sanity check. here's what results from following the docs, http://paste.ubuntu.com/9125147/
<skay> expected behavior should be http://pythonhosted.org/charmhelpers/getting-started.html#creating-a-new-charm right?
<tvansteenburgh> skay: too many "create" in your commands
<lazyPower> skay: are you looking at using the services framework as well
<lazyPower> the python-basic template is more likely what you're looking for.
<skay> lazyPower: when I tried to use the -t to specify a template, I got a usage error
<tvansteenburgh> skay you have "charm create create"
<skay> tvansteenburgh: woohoo, I like it when it's a typo instead of a complete crazy misunderstanding
<tvansteenburgh>  :)
<skay> lazyPower: python-basic is indeed what I was looking for (it also looks like the docs should indicate python-basic for hte template rather than python?)
<skay> thanks all
<lazyPower> skay: It's a bit confusing I agree - python being an alias for the services framework.
<skay> lazyPower: for feedback: when I use the python template the dir tree does not resemble the dir tree on the docs.
 * tvansteenburgh makes a note to update docs
<tvansteenburgh> thanks for pointing that out skay
<skay> tvansteenburgh: I wasn't sure if I should open an issue in case I had misunderstood something. thanks for helping.
<tvansteenburgh> sure thing
<skay> avoine: adding support for pip_extra_args in order to use --no-index --find-links=/some/path, isn't as straight forward as I thought due to pip not being able to find /some/path.
<skay> avoine: I am not sure exactly what to do, and maybe I need to write a subordinate charm to populate /some/path on the python-django unit?
<skay> because I don't think that functionality belongs in python-django
<skay> I think adding support for pip_extra_args belongs, and python-django would just pass that to pip
<skay> and it would be the responsibility of something else to ensure the path is reachable
<avoine> skay: Have you tried to upgrade pip?
<skay> avoine: I did try, that did not resolve the problem. (and also would be a problem if one applies pip_extra_args to all calls, if it is the case that the existing pip doesn't support the extra args, but while I investigated I introduced a temp kluge to ignore it when installing pip)
<avoine> skay: just to be sure I understand, your installing a tar archive with your django project + your dependencies and then your pointing pip ... --find-links to your dependencies dir, right?
<avoine> also pip don't need to be upgrade on trusty since "Added support for bare paths (including relative paths) as argument to âfind-links" was added in version 1.3 and trusty is 1.5.4
<skay> avoine: not exactly. I tarred up my django project and had dependencies in the local file system. oh derp, I should just tar them up too?
<skay> avoine: I'm using precise at the moment (I thought the gunicorn charm was precise, but if I'm mistaken I can use trusty)
<avoine> gunicorn is in trusty too
<avoine> skay: how do you add your dependencies, with scp?
<avoine> âfind-links needs a dir where dependencies are already downloaded
<skay> avoine: no, I ignorantly thought that juju would be able to provide access to them in the local file system
<avoine> oh like vagrant does
<avoine> ?
<skay> yeah
<avoine> no indeed it's not
<avoine> I would put them in the tar
<skay> yes, it is clear to me now
<skay> this is simpler.
<skay> thanks for walking me through that
<avoine> but I think that's a feature they want to add
<avoine> that would be usefull
<avoine> lazyPower: mounting local directory inside a local deployement (with nfs for example) is still a feature you wanted to add to juju?
<lazyPower> avoine: we found a work around as documented in the NFS charm
<avoine> cool
<avoine> skay:  ^
<skay> o/
<lazyPower> it requires some manual intervention - so adding something without the manual intervention would be nice - but i can see it as being lower priority
<lazyPower> skay: https://jujucharms.com/nfs/trusty/0 - take a look at "On the LXC host" in the readme
 * skay takes a look
<avoine> I guess that would be a good use case for a juju plugin
<jw4> lazyPower, avoine this sounds like what Juju Actions is intended for
<lazyPower> jw4: i dont think actions will be able to modify the HOST on behalf of the user.
<lazyPower> those particular edits take place on the LXC host so the containers can receive the nfs kernel modules - otherwise apparmor blocks them
<jw4> lazyPower: I see - and actions run in the context of the units
<lazyPower> correct
<lazyPower> actions are intended to be helpers that dont necessarily belong in the hooks - like database backups, adding users to an app, etc.
<jw4> lazyPower: oh well.  I got excited for a minute there
<avoine> I forgot, is there a way I can get the data of a relation outside a hook or with a juju command?
<avoine> juju-run on the vm did the trick
<mwenning> hi juju team, can anyone help with a juju hang problem?
<lazyPower> mwenning: hey o/ whats going on with juju?
<mwenning> lazyPower, hi, I'm running juju bootstrap --debug -e maas and it hangs for 10 min and then fails with a timeout
<lazyPower> mwenning: are the units still spinning up? iirc you're working in a pure hardware environment
<mwenning> I'm pretty sure I didn't set the proxy right, but it won't take the right value anymore.
<mwenning> juju destroy-environment --debug --force maas also hangs
<mwenning> stby I'll get a pastebin
<jose> mwenning: is it still giving the 502?
<mwenning> yes.
<jose> huh
<mwenning> after I set the proxy correctly it worked for awhile, now it's hung again
<mwenning> s/hung/hanging
<mwenning> https://pastebin.canonical.com/120815/
<mwenning> lazyPower, jose, it hangs at line 9 for probably 10 min, then dumps the rest of that stuff.
<jose> mwenning: lazyPower will give you a hand with this - cannot access canonical services and I wouldn't risk pasting any private details on a public site
<mwenning> jose, ok thx
<lazyPower> mwenning: can your workstation reach the node its attempting to bootstrap when you just activate it in the MAAS gui?
<mwenning> lazyPower, yes, maas works fine, I can start/stop all my nodes
<jcastro> is `instance-type` ignored in environments.yaml?
<lazyPower> mwenning: and workstation connectivity to the nodes works as well?
<jcastro> I put m3.mediums but it's asking for m1.smalls
<lazyPower> jcastro: thats a depreciated constraint
<lazyPower> you should add proper constraints
<mwenning> lazyPower, yes, I can ssh into all the nodes from my maas server
<jcastro> I thought we were putting it back in?
<jcastro> or at least defaulting to m3's?
<lazyPower> mwenning: hmm... this is troubling
<lazyPower> mwenning: which juju revision are you on? 1.20.x i assume?
<mwenning> juju-core 1.20.11
<lazyPower> ok, latest stable
<lazyPower> hmm this sounds like a reachability issue though
<mwenning> what's wierd is that it doesn't seem to take anything from environments.yaml or environments/maas.jenv
<jose> what do you mean?
<mwenning> I tried changing bootstrap-timeout to 120  and it didn't take it.
<mwenning> I've got http-proxy and https-proxy set in the environments.yaml, that should point to the correct proxy but it doesn't seem to pay attention
<mwenning> Is there somewhere else that juju is reading that info?
<lazyPower> mwenning: im' asking for a core dev to come take a look with us - 1 moment
<lazyPower> i'm not using any proxies and have limited interaction with using a proxy in juju
<mwenning> hmm, what the heck?  It's trying to access 192.168.1.1/MAAS .
<mwenning> That's not my MAAS server, it's at 192.168.0.2
<lazyPower> mwenning: stale maas jenv?
<mwenning> where is that?
<mwenning> where is maas.jenv?
<lazyPower> ~/.juju/environments/maas.jenv
<jose> tvansteenburgh: ping, mind a quick pm?
<tvansteenburgh> jose: sure
<mwenning> actually maas.jenv is gone.
<lazyPower> mwenning: ok so if its not reading a stale jenv file - something else is awry
<lazyPower> can you verify the server config in environments.yaml is the correct ip address?
<mwenning> I lazyPower , yes.  stby I'll paste the whole thing
<mwenning> https://pastebin.canonical.com/120819/
<lazyPower> mwenning: do you have another PROXy export set?
<lazyPower> echo $JUJU_PROXY i think
<mwenning> lazyPower, $JUJU_PROXY shows nothing
 * lazyPower snaps
<lazyPower> that was the last thought i had on what it could be
<lazyPower> i unfortunately dont know why you're seeing that behavior :(
<mwenning> lazyPower, ok.  I've got to drive downtown to a meeting, I'll look at this later
<jcastro> hey bcsallerm can you add your +1 to this bug?
<jcastro> https://bugs.launchpad.net/juju-core/+bug/1373516
<mup> Bug #1373516: Switch default instance type from m1.small to t2.small/m3.medium for EC2 provider <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1373516>
<jcastro> hey natefinch, can we get this on someone's radar? ^^^^
<jcastro> This will only get worse and worse
<mwenning> lazyPower, if you can think of anywhere that juju might be cacheing that information please let me know, that's all I can figure
<lazyPower> mwenning: my only other suggestion is to do a full env dump and sift through whats in there
<lazyPower> juju reads from env => .jenv => environments.yaml - in that order.
<mwenning> lazyPower, do you know if it reads http_proxy in the env?
<lazyPower> i believe so
<mwenning> ok, I think that's new, but I've set it there too.
<natefinch> jcastro: I think we addressed that... lemme double check, thought I saw that in the 1.21 release notes
<natefinch> jcastro: hmm. maybe not
<natefinch> jcastro: it's definitely on our radar.  I'll see if I can get someone to put a little time into fixing it.  I think the main problem we had was that there wasn't really a no-brainer replacement.  both t2.small and m3.medium had slight problems (I believe t2.small is a burstable instance, and m3.medium is slightly more expensive)
<jcastro> yeah
<jcastro> it was just reiterated to us that m1's are going away much faster than we thought
<natefinch> jcastro: personally, I'd just go with m3.medium.... it's not our fault amazon doesn't have cheap prices :)
<natefinch> (for reasonable machines)
<natefinch> jcastro: I'll bring it up right now.  I agree it needs to get fixed ASAP.  Of course, the problem is that it won't be fixed in older jujus
<jcastro> I'd rather have people pay more than having it not work because m1's are being culled
<natefinch> yep
<natefinch> jcastro: we also should handle that error better by requesting from a different AZ in the region and/or trying a different instance type
<natefinch> jcastro: who said the m1's are going away faster?  Just want to give proper attribution.
<jcastro> ben and robert
<jcastro> aka the CPC team
<jcastro> robert filed the initial bug
<natefinch> jcastro: just sent a mail to juju-dev.  Assuming no one objects, I'll try to make sure someone gets on it ASAP.
<jcastro> -<3 thanks
#juju 2014-11-21
<stub> I have banged out Python3 support for charm-helpers, https://code.launchpad.net/~stub/charm-helpers/py3/+merge/242460
<stub> I've love a review ASAP since branches like this will grow conflicts with every landing
<erkules> ahoi, what platforms are supported by juju?
<tvansteenburgh> stub: thanks for the py3 charmhelpers branch! gonna review that now
<stub> tvansteenburgh: ta.
<darknet_> lazypower_: hi how are you?
<darknet_> lazypower_: I've re-install everything using the guide published of Marco Ceppi (http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/). But the result is the always the same when I try to open the horizon I see just a white page!!!
<darknet_> someone can help me, please?
<darknet_> and from host machine a can ping that using either IP address or FQDN.
<bloodearnest> hm, how does one use t2.micro instance-type on amazon?
<bloodearnest> ah. https://bugs.launchpad.net/juju-core/+bug/1336473
<mup> Bug #1336473: Support new t2 instance types on AWS <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1336473>
<bloodearnest> bummer
<darknet_> anyone can help me???
<marcoceppi> darknet_: I'm about to follow my directions again to see if I can reproduce the issue
<darknet_> marcoceppi_: hi Marco, thanks a lot for your reply. I also send y a private message about that issue.
<darknet_>  marcoceppi_: I've re-install everything and I've the same issue...a white page
<lazyPower> greetings darknet_
<lazyPower> have you confirmed no further relationships are running in your environment? ran juju debug-log and saw no chatter amongst units reporting they are still doing anything?
<lazyPower> can i get a quick pair of eyes on https://code.launchpad.net/~bigdata-dev/charms/trusty/hdp-hadoop/trunk/+merge/242414 ?  I need to get this landed for CTS today
<dpb1> lazyPower: looking
<lazyPower> thanks dpb1
<marcoceppi> lazyPower: why are you removing usr/bin/env?
<dpb1> lazyPower: what kind of testing have you done?
<lazyPower> i didnt catch that marcoceppi - but a quick push will fix that
<lazyPower> dpb1: deployed on canonistack, and hpcloud leveraging the tests in the charm suite - HDFS DFSADMIN report yields a good cluster, and terragen/sort smoke tests
<marcoceppi> lazyPower: why do you have amir's branch in the bundle? wouldn't you want amulet to use the CWD charm?
<lazyPower> marcoceppi: that was inhereted from amirs branch - when i ran the tests i pointed it at ~bigdata-dev
<marcoceppi> lazyPower: just drop all that in general
<lazyPower> when i push this from bigdata-dev i'll update to use the cs resource - however in bundles whats the proper format for calling CWD?
<marcoceppi> and put charm: hdp-hadoop
<lazyPower> marcoceppi: when i ran that it deployed cs:trusty/hdp-hadoop
<marcoceppi> amulet will see that the charm its testing is that and use the directory the test is launched from
<marcoceppi> how did you test?
<lazyPower> with JUJU_REPOSITORY set, it didnt deploy that, it picked the CS resource over local
<lazyPower> bundletester and executing the script directly
<lazyPower> eg: tests/10_deploy
<marcoceppi> idontbelieveyou.gif one second
<marcoceppi> so, I don't know if bundletester sets JUJU_TEST_CHARM
<marcoceppi> but if you set that to hdp-hadoop
<marcoceppi> it will work
<lazyPower> ok, so you want me to nuke the branch bits and export that env var and re-test?
<marcoceppi> wait
<marcoceppi> tvansteenburgh ^?
<tvansteenburgh> ?
 * tvansteenburgh reads scrollback
<tvansteenburgh> if the the charm name matches the local dirname amulet will deploy the local charm
<lazyPower> thats not consistent with what i saw lastnight but i'm running another test on it now
<lazyPower> i know thats the case when the service is declared in the test itself - but the bundle was consistently picking cs:trusty/hdp-hadoop
<tvansteenburgh> is the bundle file being loaded by amulet
<tvansteenburgh> ?
<tvansteenburgh> or just picked up implicitly by bundletester
<lazyPower> its being loaded by amulet
<lazyPower> self.d.load(yaml.safe_load(bun))
<tvansteenburgh> ok
<lazyPower> i see there's an open file descriptor in the test :S might as well fix that while i'm in here
<darknet_> marcoceppi_: re-open the URL without /horizon I don't see neither the apache's page
<lazyPower> darknet_: are you getting a no response or an empty reponse?
<marcoceppi> tvansteenburgh: is it because the service naem doesn't match the charm name?
<marcoceppi> as in the service is being aliased in the bundle file
<darknet_> marcoceppi_: I tried to ping the node from host (my PC) using both IP add. and FQDN and it works correctly..
<tvansteenburgh> marcoceppi: i haven't seen the bundle file
<tvansteenburgh> is anything actually broken? i was waiting to hear the results of lazyPower's test run
<lazyPower> tvansteenburgh: spinning up vagrant to run again - took me a minute to clean up and re-import the box.  I'm in the middle of another test on canonistack so my env is a bit occupied
<tvansteenburgh> d.load() just calls d.add() for every service in the bundle, so it determine the charm-under-test in the same way
<tvansteenburgh> *should*
<lazyPower> i'll know as soon as the vm is booted - i'll ping ya with the results tvansteenburgh
<tvansteenburgh> roger
<dpb1> lazyPower: I'm progressively submitting diff comments
<lazyPower> awesome. feedback much appreciated
<dpb1> lazyPower: ok, I'm done, marked needs fixing
<dpb1> caught one bug, most of the others are just really egregious style errors
<lazyPower> dpb1: solid - i'll get these banged out and pushed within the hour. Cheers for the review
<dpb1> np
<lazyPower> marcoceppi tvansteenburgh whit: standup
<themonk> jose, hi
<themonk> jose, can we PM now?
<themonk> lazyPower, hi
<lazyPower> Hello themonk
<themonk> lazyPower, sorry for late replay
<lazyPower> no worries themonk
<lazyPower> tvansteenburgh: appears nothings broken
<tvansteenburgh> \o/
<lazyPower> tvansteenburgh: i did however export the env var implicitly
<lazyPower> that may or may not have been the magic sauce
<tvansteenburgh> well yeah that'll work too
<tvansteenburgh> although should work w/o it
<lazyPower> yeah i had a variable in there i didnt think to isolate
<lazyPower> next time around. but i'd say its safe to assume it was PEBKAC
<themonk> lazyPower, i have a script.py which is not idempotent, i am passing properties values to config-change using juju set, and because setup.py is not reconfigurable i am setting a lock so that it(setup.py) can not run second time, and mention it in readme, my question is will it be a blocker in charm review?
<lazyPower> themonk: its quite dependent on the context of the immutable configuration - in some scenarios it is neccessary to prevent dataloss for example.
<lazyPower> Can you give some context as to why  the setting is immutable?
<themonk> lazyPower, the context is it creates certs and insert it in jks and creates DS data which is immutable and many other things which i dont know all :)
<themonk> lazyPower, may be it not complex to make it mutable, but right now its immutable.
<lazyPower> themonk: that seems like a candidate for consideration - its going to be up to the reviewer that looks at the code
<lazyPower> if there is a sane and viable way to make it mutable - we would perfer that be the case
<lazyPower> themonk: i suggest you push it to a namespace branch and get a proper code review - otherwise its a bit too subjective to make a proper response.
<themonk> lazyPower, hmm, agreed :) doing it, thanks
<lazyPower> anytime themonk - good luck on the review
<themonk> lazyPower, :)
<jcastro> You can now configure 'apt-mirror' in environments.yaml to specify the
<jcastro> mirror used by all the machines provisioned in the environment.
<jcastro>     apt-mirror: http://my.archive.ubuntu.com
<jcastro> \o/
<jcastro> my fave feature so far
<lazyPower> dpb1: fixes are up - running tests now
<jcastro> jose, lazyPower, marcoceppi: let's fire it up in like 5 more minutes?
<jose> sounds good to me
<lazyPower> Sounds like a plan
<jcastro> jose, ok let's do this!
<jose> yep, it's starting
<jcastro> jose, post the youtube link too for people who just want to listen
<jose> got it
<rick_h_> jcastro: jose marcoceppi mbruzek1 lazyPower working on an initial readme for hte bugs for jujucharms.com, please feel free to suggest updates. https://github.com/CanonicalLtd/jujucharms.com
<jose> rick_h_: thanks! will take a look once we're done with the Charm School
<rick_h_> jose: all good ty much
<jcastro> wwitzel3, around?
<jrwren> awe man, I'm missing charm school?
<jcastro> yeah
<jcastro> jose, youtube link pls
<jose> ubuntuonair.com
<jose> sec checking analytics
<jose> or youtube.com/watch?v=NjERFuBs2S8
<cory_fu> https://github.com/juju/plugins/
<wwitzel3> jcastro: yepo
<jcastro> https://plus.google.com/hangouts/_/g4roaheffd55jqc2tofvieb42ya?hl=en
<jcastro> want to join our charm school to explain your new retry hotness?
<cory_fu> https://github.com/nojhan/liquidprompt
<sarnold> cory_fu: wow
<lazyPower> sarnold: you following along at home on the charm school?
<sarnold> lazyPower: no :/
<lazyPower> sarnold: cory_fu wrote a pretty intense juju plugin
<lazyPower> juju dhx
<cory_fu> Oh, I thought you were impressed by my dhx plugin.  :)
<cory_fu> wwitzel3: Please check out the middle / end of the Charm School video we just finished.  I'd like to get your feedback on my dhx plugin
<sarnold> oh :) well, maybe I would be, let me go looking for it :)
<sarnold> yup, looks pretty cool :)
<cory_fu> wwitzel3: https://www.youtube.com/watch?v=NjERFuBs2S8#t=1059
<wwitzel3> cory_fu: thank you
<wwitzel3> jcastro: sorry, I didn't respond earlier, I'm neck deep in trying to get something reviewed and landed before I go on vacation for 2-weeks
<cory_fu> wwitzel3: Oh, then the plugin review isn't urgent enough to block your vacation.  :)  Just was curious on your feedback vis what of those features might make sense in core down the road.
<darknet_> Someone can help me? I've reported a problem with Openstack that was deployed by Juju.. All relations between charms are ok (green) but if I try to open horizon, I receive an error page like that " This webpage is not available".  I tried also to ping the vm node from my host using either its IP address or FQDN and it works!!. I followed this guide http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/. B.R.
<darknet_> darknet
<jrwren> I have an open bug on this, and I'm looking for ideas for work arounds. https://bugs.launchpad.net/juju-core/+bug/1392786
<mup> Bug #1392786: charm has no way to report error state <charms> <feature> <hooks> <juju-core:Triaged> <https://launchpad.net/bugs/1392786>
<jrwren> what to do when a charm has an error, if I'm actively avoiding error states?
<jrwren> e.g. right now my charm takes a source PPA as config option. If you type that wrong then the isntall hook errors. I can catch the exception and let the hook complete without error. Question is, should I?
<darknet_> anyone can help me?
<cory_fu> darknet_: Is the openstack-dashboard service exposed?  (Does it say "exposed: true" in `juju status openstack-dashboard`?)
<darknet_> cory_fu_: yes all services are exposed
<cory_fu> darknet_: And port 80 is open (listed under ports)?
<darknet_> cory_fu_: let me check
<cory_fu> jrwren: There is a discussion underway for a feature to allow charms to report information, including more detailed statuses and messages, back to the user.  The semantics haven't been finalized yet, though, so it will be a while before it's available.  I'm definitely hoping it comes sooner rather than later.
<cory_fu> jrwren: For the time being, how you handle it very much comes down to your specific needs.  I would lean toward failing into error state if the user enters an invalid value, since there isn't really a way to inform them that their selection is being ignored
<cory_fu> But, depending on your specific scenario, it may be acceptable to fall back to a default value
<darknet_> cory_fu_: i don't know what happened but not i see the openstack's dashboard....i don't have any idea why
<cory_fu> E.g., something like an invalid PPA should probably be an error, because otherwise they'd be running the incorrect version / code without realizing it, but something like setting the domain to be used when generating URLs could be defaulted to a valid domain if you detect something completely wrong
<jrwren> cory_fu: thanks. I'm going to go ahead and fail.
<cory_fu> darknet_: It's possible the machine failed to provision.  Try looking through the full output of `juju status` to see if there are any errors that you missed
<cory_fu> jrwren: Yeah, it's definitely not ideal, but we don't have a better option (yet!)
<tvansteenburgh> lol, jrwren qotw
<cory_fu> lol
<jrwren> tvansteenburgh: tis my life motto.
<sarnold> awesome :)
<darknet_> cory_fu: this is a paste of juju status http://paste.ubuntu.com/9157090/
<darknet_>  cory_fu_: I don't see any error!!!
<marcoceppi> darknet_: is apache2 running on openstack-dashboard?
<darknet_> yes
<cory_fu> darknet_: And listening properly on 80 & 443 (netstate -tnl)?  If so, I guess check the Apache logs, unless marcoceppi has a better suggestion
 * cory_fu tags out, because he just reached the end of his depth.
<darknet_> cory_fu_: after to run the command "juju set keystone admin-password="test01" and try the login openstack gave me "Something went wrong! An unexpected error has occurred. Try refreshing the page. If that doesn't help, contact your local administrator."
<cory_fu> darknet_: Sorry, I stepped away.  Honestly, I haven't done anything with that openstack deployment.  You'd really need marcoceppi to help you, I'm afraid
<darknet_> cory_fu:_ anyway thanks a lot for your support i'll try to ask that to marco
<cory_fu> Good luck.
<darknet_> cory_fu_: this is strange I've reboot all node and now I can open horizon, same error "This webpage is not available"....why?why?
#juju 2015-11-16
<aisrael> I think I've got something funky going on with my dns on wily w/juju 1.25. It'll work, then stop (can't resolve internal dns), then start working again. At the same time, I'm having deployed machines able to resolve names but not connect (i.e., apt-get update)
<aisrael> Ok, that last part gets fixed by restarting lxc-net (a side-effect of my iptables script to port forward to containers.
<blahdeblah> aisrael: I experience that all the time completely without respect to juju
<blahdeblah> NetworkManager seems to be very stop-start when it comes to rational DNS resolution.
<aisrael> blahdeblah: So I've noticed. The quickest way to get it back is to ssh in and restart nm. I'm combing logs now to try to find what's getting run that confuses it
<blahdeblah> It has been like that since at least trusty; I got into the habit of adding /etc/hosts entries for anything important.  I probably should rather start debugging it a little and submit bugs against NM.
<DarkNet> oh, so sad. this is not about jujujoints :(
<blahdeblah> lazypower: I've read your DNS charm documentation today for the 2nd time, and I'm still trying to work out whether it's what I should be using for my particular application.  If you're around late in your day sometime, would you mind me picking your brain about it for a few minutes?
<gnuoy> jamespage, Could I get a second opinion on https://code.launchpad.net/~ionutbalutoiu/charms/trusty/neutron-gateway/next/+merge/276833 ? I'm inclined to merge it and add a comment to config.yaml saying "if you need to use this config option please consider filing a bug against the charm to explicitly expose the config option you are setting"
<gnuoy> or words to that effect that actually make sense
<jamespage> gnuoy, agreed - and some unit tests would also be nice
<jose> arosales: hey, good news! we got accepted into Google Code-In - we're on the search for tasks right now :)
<arosales> jose: woot!
<arosales> jose: good to hear
<arosales> jose we can certainly help with tasks :-)
<jose> \o/
<arosales> jose: would you like me to just send them to you or do you have have a google doc, git-hub page, or something I can reference?
<jose> arosales: google doc is fine. marcoceppi offered to be a mentor I believe, so maybe you can work with him, or if you want you can be a mentor too
<arosales> jose: I would be interested. I am not sure how the whole process works, but I would like to learn more and work with you to make it sucessfull.
<arosales> jose: would you perfet github repo or google doc?
<jose> arosales: google doc works for me - I'm working on mobile a lot and it's easier to access :)
<arosales> jose: oh, I was talking more long term too, not just for today
<jose> arosales: yeah, university schedule keeps me here 7am-8pm :D
<jose> and semester finishes second week of december
<arosales> I bet  :-)
<jose> so, mentors are basically the ones who publish tasks and review that they have been done
<jose> and if students have any questions about an specific task they can ask the mentor they published
<jose> yes, it's easy as it sounds
<arosales> jose: I made https://docs.google.com/document/d/1ZFAJiuml59dF_1qJmCmrTqRoJxQRJddcL3baxnkmoh8/edit just for the initial plannin
<arosales> open to anyone if anyone elses has any ides
#juju 2015-11-17
<ionutbalutoiu> Can someone take a look by any chance at this Merge Request: https://code.launchpad.net/~ionutbalutoiu/charms/trusty/neutron-gateway/next/+merge/276833 ?
<jamespage> gnuoy, can I get an ack on https://code.launchpad.net/~james-page/charms/trusty/nova-compute/lp1516640/+merge/277586 ples
<jamespage> ah you're not around today
<jamespage> ionutbalutoiu, hey - your MP looks OK - but I'd like to see some unit tests for the change please
<ionutbalutoiu> jamespage, very well, I'll update it a little bit later.
<jamespage> coreycb, hey - can I get a +1 on https://code.launchpad.net/~james-page/charms/trusty/nova-compute/lp1516640/+merge/277586 when you start - lxd support is currently busted
<marcoceppi> cory_fu: will charm build compile actions.yaml like it does metadata and config?
<cory_fu> marcoceppi: I don't think it will currently, but I was going to add that soon
<asanjar1> marcoceppi: hi there, do u know what would be the cause of this problem http://paste.ubuntu.com/13313806/.. juju-quckstart goes halfway through deployment and then it hangs there
<asanjar1> lazypower: looks like marcoceppi is ignoring me as usual :) would you look at the http://paste.ubuntu.com/13313806/. do you know what could cause that
<lazypower> o/ asanjar1
<marcoceppi> asanjar1: it's been 4 mins, and I'm otp :)
<lazypower> 1 sec and i'll TAL - mid review of some doc updates
<asanjar1> no excuse marcoceppi
<lazypower> asanjar1 is this juju 1.24?
<lazypower> asanjar1 i saw this briefly in 1.24 - but this went away when 1.25 landed for me.
<asanjar1> 1.26-alpha1-vivid-ppc64el
<lazypower> ok, this is most def. bug worthy
<kwmonroe> asanjar1: are you sure the deployment is hung?  what does "juju status --format=tabular" show?
<asanjar1> kwmonroe: http://paste.ubuntu.com/13313890/
<asanjar1> kwmonroe: it is saying that for a while
<asanjar1> kwmonroe: juju-gui then dies
<asanjar1> and stays there
<jcastro> https://www.youtube.com/watch?v=lowRfWcxky0
<jcastro> ^^^ reactive charm things
<jcastro> lazypower: man the overlay on the youtube videos looks awesome
<lazypower> Yeah it does :) That juju icon really shines
<jcastro> <3 donner made it for me
<Odd_Bloke> marcoceppi: arosales: This is actually an experimental art project we're working on.
<Odd_Bloke> We're exploring the New York soundscape.
<Odd_Bloke> It's a real voyage of discovery.
<arosales> Odd_Bloke: sorry I missed the backscoll
<arosales> Odd_Bloke: but if your exploring sounds you should definately hit up lazypower
<Odd_Bloke> :p
<Odd_Bloke> lazypower: Done any work with multiple Hangouts clients in the same room? :p
<jamespage> coreycb, hey - can I get a +1 on the stable fix for https://code.launchpad.net/~james-page/charms/trusty/nova-compute/lp1516640-stable/+merge/277739 as well?
<coreycb> jamespage, done
<jamespage> coreycb, thanks muchly
<lazypower> Odd_Bloke : i'm not sur ei follow
<lazypower> Odd_Bloke is this different feed per hangout client? or is this muxing audio from many clients into a single stream?
<Odd_Bloke> lazypower: We just had massive feedback going on; and I was trying to claim it was a music project. :p
<lazypower> Ah! That's actually a problem when you're doing it all in the same room :)
<lazypower> so room was referring to physical location. *nod*
<lazypower> easy fix is to just plug in headphones on every unit so its not rebroadcasting in an audible range of the mic
<lazypower> cory_fu - quick question - I see the http interface was re-tooled on the requires side to be more explicit about services under communication. Do we have any known layers implementing this? All i've found to date are providers, which is the simple side of the relation.
<lazypower> I think, its implementing as such that it just returns a dict containing the services / units + ports if i'm reading this properly
<jrwren> anyone using juju-test with lxd-provider? does it work? It isn't working for me, but I don't know if it is my weird env or not. I get juju-test.conductor WARNING : Could not bootstrap lxd, got Bootstrap returned with an exit > 0
<cory_fu> lazypower: No, I don't think anything is implementing the requires side using the interface layer, yet.
<lazypower> Ah! I did however find the example in the readme
<lazypower> THank you for writing a proper readme cory_fu <3
<cory_fu> :)
<lazypower> I'll have to take a page out of your book and do more of this
<cory_fu> Actually, I think I made those changes in response to some use-case, but I can't recall now why or who might have been trying to use it
<lazypower> cory_fu : your words, all in one place, and i think its methodically organized - https://github.com/chuckbutler/docs/blob/2f006a4edefb9715a10fb86ff13770ce77de8a8b/src/en/developers-layers-interfaces.md
<lazypower> and if you refresh you'll see the missing requires side as well
<lazypower> https://github.com/chuckbutler/docs/blob/developer-layers/src/en/developers-layers-interfaces.md  <- because i clearly have no idea how github uses commit hashes and why that will keep me from seeing changes.... >.>
<cory_fu> On the provides side bit, the comment "Anonymous method passed into methods decorated with @when(reelation.available)" is not really accurate
<cory_fu> Also, could probably use some more commenting in or description around the "writing" sections.  But thanks for pulling all this together.  Definitely needed.  :)
<lazypower> ah
<lazypower> yeah
<lazypower> whats that called?
<lazypower> as its an implicit thing that jsut happens
<lazypower> like i have the "wrong terminology but right behavior" syndrome going on in my head
<cory_fu> Um, well, the instance of the class is passed into the (@when-decorated) handler, which is expected to call that method on the instance
<lazypower> ok, i'll re-word it as such
<cory_fu> I'm not sure how to phrase that, exactly.  What I just said still seems pretty cumbersome, but at least it's not inaccurate.  :)
<lazypower> ta for the clarification
<lazypower> yeah :D
<lazypower> i'll start decorating all my "chuckisms" with :guyfawkes: so you know its completely reasonable ;)
<icey> I just deployed 3 instances on AWS with: --constraints="root-disk=25G instance-type=m4.xlarge"
<icey> juju status shows them as error
<icey> how can I find out what that error is?
<icey> nevermind: no instance types in us-east-1 matching constraints "instance-type=m4.xlarge root-disk=25600M"
#juju 2015-11-18
<gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/cisco-vpp/amulet/+merge/277787 if you get a moment
<jamespage> gnuoy, merged
<gnuoy> ta
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/odl-controller/doc-updates/+merge/277797
<gnuoy> jamespage, don't you need to reference the config.yaml at line 44 of the diff?
<jamespage> gnuoy, yes pushed
<gnuoy> ta
<gnuoy> jamespage, approved
<jamespage> gnuoy, I'm working on refreshes to the bundles for liberty and the 15.10 charm release this morning - we should add that to the release checklist
<gnuoy> ack, good catch
<gnuoy> jamespage, done
<jamespage> gnuoy, mind if I do a trivial on all of our charms for "maintainer: OpenStack Charmers <openstack-charmers@lists.ubuntu.com>"
<jamespage> ?
<gnuoy> jamespage, please do, thanks
<jamespage> gnuoy, done
<jamespage> gnuoy, I tied some pretty crappy summary and description bits at the same time
<jamespage> tided rather
<gnuoy> sounds good, thanks
<jamespage> gnuoy, can you sanity check:
<jamespage> https://code.launchpad.net/~james-page/charms/bundles/openstack-base/bundle/+merge/277798
<jamespage> and
<jamespage> https://code.launchpad.net/~james-page/charms/bundles/openstack-telemetry/bundle/+merge/277799
<jamespage> I've just deployed telemetry in dellstack and run through the README ok
<jamespage> telemetry == base + ceilometer
<gnuoy> 'num_units: 0' looks odd but since you've deployed with it is looks like it does no harm for subordinates
<jamespage> gnuoy, thats a gui-ism
<gnuoy> jamespage, why are the mcast ports explicitly stated for a couple of services?
<jamespage> gnuoy, again I have not idea why the gui elected to add those...
<gnuoy> haha
<jamespage> they could be dropped
<jamespage> gnuoy, charmstore does some verification of bundles
<jamespage> https://jujucharms.com/u/james-page/openstack-base
<jamespage> and https://jujucharms.com/u/james-page/openstack-telemetry
<jamespage> that validates the format and the charm revs...
<gnuoy> the bundles look ok to me
<jamespage> gnuoy, ok
<jamespage> thanks
<kwmonroe> hey folks - what's the difference between "destroy-environment local" and "destroy-environment local --force"?  help tells me that force destroys "directly through the env provider", but i don't know what that means for local.
<asanjar1> kwmonroe: hi
<kwmonroe> hey asanjar1
<asanjar1> kwmonroe: thanks for v9 version. Maria's team could use you onsite for few hours to resolve the remaining issues.. do you have time? I have already asked arosales
<kwmonroe> asanjar1: is the caffetteria food any good?
<kwmonroe> (and yeah, i can be there around 1:45 this afternoon)
<asanjar1> kwmonroe: I wounder if there is something unique with their environment
<asanjar1> kwmonroe: no man, it SUCKS
<asanjar1> kwmonroe: I am losing weight
<asanjar1> okay let me ping here
<jcastro> anyone have a tldr on the current state of the jenkins charm?
<jcastro> it hasn't been touched for over a year so it's either really awesome or horrible. :)
<jcastro> huh wait a minute, it is updated, the jujucharms changelog is broken?!
<lazypower> jcastro - correct. its been receiving some attention. The changelog in the store has been silently sometimes-functional due to the v3->v4 transition
<jrwren> does juju support ipv6? I can't seem to juju ssh to a machine with ipv6 public-address the proxy-ssh netcat fails. http://pastebin.ubuntu.com/13334236/
<jrwren> *doh* nevenmind. i was misinterpreting the message.  works fine
<lazypower> jrwren woo! \o/
<jcastro> lazypower: ack, filed a bug
<jrwren> any write amulet tests which execute on an ipv6 environment? :)
<beisner> o/ jcastro, jenkins charm has action in the review queue to, to bring feature parity of the python rewrite back up to le ole bash precise jenkins charm.
<beisner> too, even.
<jcastro> beisner: do you guys maintain it? you guys being the openstackers
<beisner> jcastro, no.  but we consume an old diverged fork, and would like to switch to consuming a converged, updated, works-for-everyone version, ie. the python rewrite + back-filled features.
<beisner> jcastro, so, by virtue, contributing to the thing, testing the thing, making proposals of the thing, could be pretty close to "maintaining"  ;-)
<jrwren> bash charms <3
<beisner> :)
<adam_g> hey, ive got a charm questino wrt coordination between two services. i have service A that will eventually get a relation to B. when it does, B will do some stuff on A's API.  before it can, service A needs a complete relation to service 1 and 2 (say, DB and message queue)
<adam_g> is there a good way to interrogate that on B's side, short of adding some data in the relation settings exported by A that B can use as a test?
<adam_g> its been a while since ive juju'd, but i remember dealing with this often. wondering if a good practice has come up since
<adam_g> jamespage, maybe you know
<mgz> adam_g: I think the normal way is that B doesn't set it's api details on the B-A relation till it has B-1 and B-2 relations up and whatever real interfaces for those up and ready
<mgz> so, A will not get the relation config stuff it needs to start the api poking till B is really ready to act on it
<mgz> juju now has nice reporting in status where a charm can say it is "blocked" for these sorts of situations
<adam_g> mgz, well, thats complicated by the fact that the API endpoint isn't advertised via relation, its published into a catalog (read: keystone)
<adam_g> mgz, ya, im looking at the status stuff now in the openstack charms. will have to go find the docs on that
<marcoceppi> adam_g: there really isn't a way to interogate b's relations, Juju doesn't set up that kind of dependency train, otherwise A becomes co-dependant to Bs architecture. Relation data is the best way to handle this
<mgz> adam_g: https://jujucharms.com/docs/1.24/reference-status is some of it, there are some new tools for setting that from hooks
<adam_g> marcoceppi, yeah, was hoping to get around it without having to extend existing stuff
<mgz> adam_g: if you can't set the api details directly, you can just have a api-ready: bool type thing on the relation config
<adam_g> mgz, thats what i was thinking, thanks
#juju 2015-11-19
<lamont> lets say I have juju 1.24.7-0ubuntu1~14.04.1, and I want to juju deploy local:xenial/foo... is there some obvious reason that the service winds up in this state:
<lamont>     service-status:
<lamont>       current: unknown
<lamont>       message: Waiting for agent initialization to finish
<lamont>       since: 19 Nov 2015 03:45:05Z
<mgz> lamont: what status is the machine in?
<lamont> nova?  doesn't exist at all
<lamont> interestingly, local:wily/foo gets me machine-2
<mgz> weeelll... that would be why the agent isn;t up
<lamont>     service-status:
<lamont>       current: maintenance
<lamont>       message: installing charm software
<lamont>       since: 19 Nov 2015 03:47:45Z
<lamont> that's with local:wily/foo
<lamont> mgz: is there some easy way to cause juju to spill what command it's using for "nova boot"?
<mgz> lxc-ls --fancy gives you a view under the hood, as does $JUJU_HOME/$ENV/*
<mgz> er, meph
<lamont> no lxcs involved... this is openstack
<mgz> I was imagining containers where none exist
<lamont> can I have multiple series (trusty,wily,xenial) in one juju environment?
<mgz> for the true story, you need the nova logs
<lamont> as in nova host api logs on the api host?
<mgz> but machine-0.log will tell you what the provisioner tried to do
<lamont> ah!
<mgz> it may be something as simple as nova not having a xenial image
<lamont> nova image-list| grep xenial
<lamont> | 00e59d4a-b4a5-4b27-8cf9-3fe2bcd0fb79 | ubuntu-xenial-daily-amd64-server-20151105-disk1.img  | ACTIVE |        |
<lamont> ^^ that's why I thought I could do this
<mgz> okay, but how does juju know about that image?
<lamont> 2015-11-19 03:45:07 ERROR juju.provisioner provisioner_task.go:630 cannot find tools for machine "1": no matching tools available
<mgz> did you also update local simplestreams
<lamont> bingo!
<lamont> apparently not
<mgz> ...and also it couldn't find xenial tools
 * lamont goes to poke his admins
<mgz> okay, we haven't published xenial tools yet, because there are no xenial cloud-images yet, and our build chain expects that
<lamont> oh!
<lamont> well then
<mgz> in practice, the tools would be identical to wily's
<lamont> mgz: any eta?  (meanwhile, I'll do the wily + upgrade-in-place-while-crying
<lamont> guessing step 1 is poke the cloud-images people?
<mgz> yeah, they're trying to change the method they're making images, which is the hang up
<lamont> ack
<jamespage> adam_g, hey - you should hook up with gnuoy, coreycb and thedac as they are about to write three new openstack charms - all based on the new reactive framework which is our standard now
<ionutbalutoiu> hi, jamespage. Update MP with the unit tests as you advised. Can you take a look whenever you can ? (https://code.launchpad.net/~ionutbalutoiu/charms/trusty/neutron-gateway/next/+merge/276833)
<jamespage> ionutbalutoiu, on my list for today
<ionutbalutoiu> jamespage, just as a note, amulet tests didn't run yet for this update (only lint_test and unit_test), but it's been two days. I think we have to wait for this as well. Just wanted to give you a ping. Is it common such a delay for amulet tests ?
<jamespage> ionutbalutoiu, long queue in the lab right now as we keep enabling new tests for each charm
<jamespage> its possible something is blocked up - I'll check
<jamespage> ionutbalutoiu, if not I'll run them myself...
<ionutbalutoiu> good, thank-you.
<jamespage> ionutbalutoiu, tbh I'd be happy to land without those reporting in as they passed before, and you've made 0 code change that would impact that since then
<jamespage> but lets see
<lazypower> o/ mornin jamespage
<jamespage> hey lazypower
<lazypower> jamespage did you see the somewhat silent post yesterday about charming w/ layers interview feat. Adam Stokes?
<jamespage> lazypower, I did - started to watch but then got children
<jamespage> so had to stop
<jamespage> will resume later today
<lazypower> :D just wanted ot make sure it crossed your radar as i know your team is about to go head first in reactive/layer territory
<lazypower> to anyone lurking that didn't catch the update - https://www.youtube.com/watch?v=lowRfWcxky0
<jamespage> gnuoy, coreycb, thedac, ddellav, rockstar, beisner ^^
<gnuoy> ta
<tvansteenburgh> anyone know how to get the ID of the currently executing juju action from inside the action itself?
<tvansteenburgh> i've seen other code using JUJU_ACTION_ID, but it's not set, and I don't see any mention of that env var in the docs
<tvansteenburgh> ah, it's JUJU_ACTION_UUID
<stub> Register the decorated function to run when not all desired_states are active.
<stub> Which does not mean when all desired_states are not active.
<stub> tvansteenburgh: I look in charmhelpers.core.hookenv() for those :)
<stub> So we get an AND operation with @when and an OR with @when_not. But I think I might stick with a single state per decorator for now until I get the hang of this ;)
<jcastro> rick_h_: we're 7 subscriptions short of the 100 we need to get the custom URL for the youtube channel, can you ask for one more push across the board?
<rick_h_> jcastro: sure thing
<rick_h_> jcastro: sent, included cloud@ as well this time so hopefully moves fast for you.
<jcastro> <3
<rick_h_> jcastro: <3 jane's reply
<rick_h_> jcastro: and done! woot
<natefinch> rick_h_: sort of sad that a 600 person company has trouble getting 100 subscriptions to their own youtube channel ;)
<rick_h_> natefinch: naw, it got through pretty well. Folks just need reminders :)
<adam_g> gnuoy, coreycb thedac  are there any examples out there of openstack charms using the reactive framework?
<gnuoy> adam_g, there is one I think
 * gnuoy is looking for the link
<gnuoy> adam_g, https://code.launchpad.net/~openstack-charmers/charms/trusty/openvswitch-odl/next
<adam_g> gnuoy, thanks.
<gnuoy> adam_g, the directory layout is a little outdated though
<gnuoy> reactive should be a top level dir I think
<adam_g> also--i seem to remember at least one place in the openstack charms where a charm would go and create neutron networks and subnets in neutron using neutronclient as part of a hook. does that still exist?
<adam_g> i need to do something similar but can't remember where that was done
<gnuoy> adam_g, are you thinking of http://bazaar.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk/view/head:/bin/quantum-ext-net
<gnuoy> adam_g, oh, as aprt of a hook
<adam_g> gnuoy, oh ya, that was it
<gnuoy> adam_g, also http://bazaar.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk/view/head:/bin/quantum-tenant-net
<adam_g> gnuoy, okay, so those dont actuallyg et called as part of a hook
<gnuoy> adam_g, nope, I can't think of a hook that does that
<adam_g> as part of my services deployment, i need to go and create a network in neutron on behalf of the service tenant
<coreycb> adam_g, btw we're in the midst of creating a base openstack layer and inteface layers for rmq, mysql, keystone, etc
<adam_g> coreycb, cool. im kinda operating on a tight schedule so im not sure ill be able to adapt that just yet. :\ unless all that stuff is about done and ready to use now.
<gnuoy> adam_g, that's going to be a pain I would think
<gnuoy> I mean creating the network
<adam_g> gnuoy, yeah, i was trying to find a good way to make that fit yesterday
<adam_g> gnuoy, best i could come with is have neutron-api expose a setting in its relatoin that lets other services know that neutron at least has: keystone, db, rabbit relations
<adam_g> then have the other end do what it needs once thats true
<gnuoy> adam_g, fwiw we already have a concept of the charm being ready (all mandatory relations and config satisfied)
<gnuoy> it;s spat out in the workload status
<adam_g> gnuoy, right but isnt that just user facing? i cant block relatin A's hooks on the status of B+C+D ?
<bdx_> charmers, core, dev: Hey whats up everyone? I am finally getting my feet wet and jumping into charming with reactive.... I'm trying to react to the changing of specific configs on config-changed hook, is there a best practice for checking for config change for specific configs? heres what I'm working with...https://github.com/jamesbeedy/puppet-agent/blob/master/reactive/puppet_agent.py
<gnuoy> adam_g, yes, you're right. I just meant the charm already has a concept of what it needs to be ready
<adam_g> gnuoy, yeah, AIUI that unfortunately doesnt help here
<adam_g> i think all i need from neutron-api is a flag i can pass to other services that says 'the api is functional and you can create things'
<adam_g> should be fine if that were  happen before the rest of neutron is wired (neutron-gateway and cooresponding compute agents)
<gnuoy> adam_g, yep, it seems reasonable. I'd like to see what jamespage thinks too as he was pondering a similiar issue recently
<adam_g> cool
<adam_g> i might get something functional later this afternoon and push it somewhere
<tvansteenburgh> bdx_: you can do `if config.changed(key)`
<bdx_> tvansteenburgh: ha...I knew it was something simple....thanks!
<bdx_> 2-vcpu_4-gb-ram_20-gb-hd
#juju 2015-11-20
<bdx_> 2-vcpu_4-gb-ram_20-gb-hdq
<mattyw> evilnickveitch, ping?
<jrwren> charmers: do you have history of charm tests? I suspect that mongodb tests/50_relate_ceilometer_test.py was once passing but that ceilometer charm changes and now it wouldn't pass. If I could pin a version the test would pass.
<lazypower> jrwren - the history of test runs that we have are on reports.vapour.ws
<jrwren> lazypower: thanks.
<lazypower> np
<jrwren> lazypower: do they go back in time any farther?
<lazypower> not that i'm aware of jrwren :(
<marcoceppi> jrwren: reports.vapour.ws should go back quite a ways
<jrwren> marcoceppi: less than 20days
<marcoceppi> jrwren: that's quite a ways
<jrwren> no last successful mongodb run from any branch
<jrwren> i need years :)
<jrwren> or rather, I need a last successful.
<jrwren> i suppose I can estimate and bisect ceilometer versions
<jrwren> or rather, its environment specific
<lazypower> jrwren is it?
<jrwren> lazypower: yes. might be OK in local, its not ok in my env. tests run in many environments, right? I saw the matrix of azure, aws, local, etc on reports.vapour.ws
<lazypower> :\
<bdx_> q
<jcastro> http://insights.ubuntu.com/2015/11/20/juju-charmer-summit-designing-for-success/?utm_source=twitterfeed&utm_medium=twitter
<jcastro> check out marco guys ^^^
<bdx> hey whats going on everyone? I'm looking at creating an icon for my puppet-agent charm https://code.launchpad.net/~jamesbeedy/charms/trusty/puppet-agent/trunk ...what I'm wondering, is, can I use the puppet logo in my charm icon? ...I'm guessing not, thought I would ask though. Thanks.
<bdx> I guess I could just create an outline of the beaker
<bdx> to represent puppet
<asanjar1> kwmonroe: just for your info, these days STANDALONE means hdfs cluster lol lol lol
<marcoceppi> bdx: I don't see why not ;)
#juju 2015-11-21
<scubabri> howdee
<scubabri> anyone here got time for a juju/openstack question?
#juju 2015-11-22
<jrwren> yes, and best hours are M-F 8am-10pm GMT
#juju 2016-11-21
<kjackal> Good morning Juju world!
<gennadiy> hi everybody,  does somebody have exp with riftio and juju?
<Spaulding> Hi guys!
<Spaulding> I have a strange issue, after reboot I can't see my juju status :(
<Spaulding> 10:50:43 INFO  juju.api apiclient.go:535 dialing "wss://10.190.134.11:17070/model/23ab79f9-57dc-41cc-8ecf-d367885d750e/api"
<Spaulding> this is what i see from the debug, so probably one of the controllers changed IP?
<vmorris> when I perform a deploy, is it the machine from which I am running the 'juju deploy' command that downloads the charms, or is it the controller machine?
<tvansteenburgh> vmorris: the controller
<vmorris> tvansteenburgh: ty
<lazyPower> Spaulding: hey have you found an answer/root-cause/work-around to your troubles with juju status?
<Spaulding> lazyPower: it's test env... so basically i removed the old env
<Spaulding> and bootstrap new one
<lazyPower> ok. so long as its resolved :)
<Spaulding> yeah ;)
<Spaulding> but still it was strange
<Spaulding> looks like jujud was not able to start...
<lazyPower> Spaulding: - capturing those logs and reproduction steps in a bug would go a long way to help resolving it.
<lazyPower> next time lmk and i'll be happy to step you through what to do in that scenario
<Spaulding> sure!
<Spaulding> i think the problem was that i rebooted the machine after apt upgrade
<Spaulding> and probably i should run something like juju upgrade
<Spaulding> juju upgrade-juju
<beisner> howdy marcoceppi - do you know the eta for a libcharmstore 0.0.5 cut @ pypi?
<marcoceppi> beisner: 5 mins
<beisner> too fast, slow her down man
<hackedbellini> lazyPower: hey, are you there?
<lazyPower> hackedbellini: yep hey there
<beisner> thanks, marcoceppi
<arosales> marcoceppi: good morning
<arosales> marcoceppi: do you think we should remove k8-core from cwr?  I made https://github.com/juju-solutions/build-cloud/pull/81
<arosales> given canonical-kubernetes is the main bundle and these charms and solution context is addressed there.
<marcoceppi> arosales: why remove it?
<arosales> marcoceppi: well seems that testing is handled in canonical-k8
<marcoceppi> it's a different toplogy, with different scale and different (less) components
<arosales> unless there is different test scenerios in that bundle
<marcoceppi> it's a different scenario under test
<arosales> thats fair, could you comment on the pull and I'll reject?
<arosales> marcoceppi: also I think you guys were working on getting that bundle also updated with the latest correct?
<arosales> looks like it still may be failing on the flake tests
<arosales> ref = http://data.vapour.ws/cwr-tests/results/bundle_kubernetes_core/fd135530b9e94084992706899d0040ac/report.html
<marcoceppi> arosales: the bundle needs to be revv'd and it will be in due time as part of the release cycle
<arosales> marcoceppi: gotcha, I was thinking it was just missed as part of the release last week when canonical-k8 was updated
<marcoceppi> well, canonical-k8s release was rushed due to preassure. so it was done out of band
 * arosales can be patient until the next release those as we see the correct link in the canonical-k8 bundles
<arosales> marcoceppi: cool -- thanks for the update
<bildz> Good morning.  Brand new install and trying to get conjure-up working again (sigh).  This time I see that autopilot is an option.  Tried that route and it failed because juju was not bootstrapped
<bildz> i bootstrap juju to localhost with "maas" and it deploys, but not conjure-up fails
<bildz> one day this will work!
<bildz> but right now i want to take a hammer to all these charms
<marcoceppi> bildz: what are you trying to conjure-up?
<bildz> im trying to start fresh with an environment
<bildz> openstack
<bildz> where does juju get configurations options to bootstrap?
<bildz> is it in the postgres database for maas?
<marcoceppi> you, the operator, supplies them
<bildz> Performing bootstrap: ant maas/http://10.9.9.11/MAAS
<bildz> that's the wrong ip
<bildz> and i have no idea where it's getting that
<bildz> error:  flag provided but not defined: --upload-tools
<marcoceppi> stokachu: ^^
<Guest89712> I need help with a Juju, conjure-up, Openstack deployment issue
<Guest89712> After deployment I have an openstack0 and a conjureup0 interface with the same IP address
<lazyPower> marcoceppi: arosales: https://github.com/juju-solutions/bundle-kubernetes-core/pull/39
<marcoceppi> stokachu: ^^
<arosales> lazyPower: thanks
<lazyPower> arosales: np, sorry it slipped through. There was some undue pressure last week to make an early release and that got left behind
<lazyPower> RIP
<arosales> lazyPower: no worries.i was mainly just confirming my understanding. Thanks for the work on it
<hackedbellini> lazyPower: sorry for the delay. I was in a meeting until now and am going to go to another one. I'll probably be back to redmine tomorrow. In the mean time, just to give you the actual state:
<hackedbellini> both the containers are having "executable file not found in $PATH" issue. I tried to run docker-compose by hand and this is what I got:
<hackedbellini> https://www.irccloud.com/pastebin/Xiq9xl0h/
<lazyPower> hackedbellini: one of two things has happened. The containers themselves are broken and no longer work how they did when that compose file was written, or the compose file is overriding some stuff and causing the failure
<lazyPower> not sure which, we'll need ot dive into it deeper to figure out whats up
<hackedbellini> lazyPower: hrm I see. That is strange... the composer file looks like this right now:
<hackedbellini> https://www.irccloud.com/pastebin/1St1nbOd/
<tvansteenburgh> how do you install juju 2 on trusty?
<hackedbellini> the issue happened even trying other versions (e.g. postgres:9.5) and even using the one from https://github.com/sameersbn/docker-redmine
<lazyPower> hackedbellini: it might even be better if we start from scratch and build a RedMine container ourselves. The idea being: We control the inputs/outputs so we know how long something will work, and can make those decisions for the containers as it evolves, but the charm code would largely say the same.
<lazyPower> tvansteenburgh: i believe you add the juju/stable and juju/devel ppas, and install the juju-2.0 package
<lazyPower> but i haven't tried this so ymmv
<tvansteenburgh> using juju/stable, installing juju gets you juju1, and juju-2.0 doesn't exist
<lazyPower> tvansteenburgh: this bug from last month looks like it did at one point and time exist https://bugs.launchpad.net/juju-release-tools/+bug/1633593
<mup> Bug #1633593: [juju-2.0] trusty package doesn't install juju-2.0 commands via update-alternatives <sts> <juju-release-tools:Fix Released by nskaggs> <https://launchpad.net/bugs/1633593>
<arosales> Guest89712: hello
<hackedbellini> lazyPower: hrm I see. It is a nice idea indeed
<hackedbellini> I have to go now to the other meeting, tomorrow I'll ping you again to continue from when we stopped :)
<arosales> stokachu: are spells versioned? If so is there a quick way to see what spell one is using?
<lazyPower> hackedbellini: sounds good. Glad we're making progress but sorry its taking so long
<arosales> Guest89712: what is the conjure version you are using, ie out out of `conjure-up --version`
<Guest89712> Checking
<Guest89712> conjure-up --version conjure-up 2.0.2
<arosales> Guest89712: thanks and what does `dpkg -l | grep conjure-up` return?
<Guest89712> arosales # dpkg -l | grep conjure-up   ii  conjure-up                         2.0.2-0~201610141215~ubuntu16.04.1 all          Package runtime for conjure-up spells
<arosales> Guest89712: thanks, it looks like the latest is 2.0.2-0~201611211448~ubuntu16.04.1, as a data point
<arosales> I would need to check with stokachu if there were any openstack fixes between 201610141215 and 201611211448
 * arosales looking at spell info atm Guest89712
<arosales> for openstack specifically
<arosales> Guest89712: could you pastebin the outout of 'journalctl |grep conjure-up'
<Guest89712> arosales  Can you read:  http://pastebin.com/FQpbBenk
<arosales> Guest89712: thanks
<arosales> stokachu: I am reading through http://conjure-up.io/docs/en/users/ but I am not finding a place tell which version of a spell I am running on or if I need to refresh my spell registry?  I am guessing conjure-up runs the latest spell from the registry on each summon, correct? Or are spells version'ed per conjure-up binary version?
<arosales> stokachu: working with Guest89712 on openstack0 and a conjureup0 interface with the same IP address
<stokachu> arosales: yea the latest spells are used from the registry
<stokachu> arosales: no way to set a version to be used
<arosales> stokachu: independent of conjure-up binary version the latest spell is used from the registry @ https://github.com/conjure-up/spells correct?
<stokachu> arosales: yea thats correct
<stokachu> arosales: what channel are you in for that guest89712 person
<arosales> stokachu: ok thanks, and did you have any openstack fixes on nova-lxd between conjure-up versions  201610141215 and 201611211448 ?
<stokachu> arosales: lemme check
<arosales> stokachu: thanks
<stokachu> arosales: https://github.com/conjure-up/conjure-up/commit/50f4899 that was the only major thing
<stokachu> we added the custom bridge to our packaging
<stokachu> and the spell makes use of conjureup0 bridge device for openstack-novalxd
<lutostag> anyone else seen...
<lutostag> lutostag@cia:~$ juju models
<lutostag> ERROR cannot list models: upgrade in progress (upgrade in progress)
<stokachu> arosales: oh something is wrong with the latest lxd charm
<stokachu> lemme look into it
<arosales> stokachu: thanks Guest89712 was seeing an issue where openstack0 and a conjureup0 interface with the same IP address
<marcoceppi> lutostag: sthat's a new one for me
<stokachu> arosales: maybe he installed an older conjure-up and then upgraded
<stokachu> arosales: there should only be conjureup0
<stokachu> arosales: openstack0 was from like conjure-up 0.1.2
<arosales> stokachu: Guest89712 has 201610141215 currently installed http://pastebin.com/FQpbBenk
<stokachu> arosales: yea he upgraded from an older version it looks like
<stokachu> arosales: what channel is this in?
<arosales> stokachu: sorry I didn't parse the last comment
<stokachu> arosales: so the package in the archive conjure-up 0.1.2 was setting up openstack0 as a bridge
<stokachu> arosales: in the next release of conjure-up (2.x) we renamed that to conjureup0 as the bridge
<stokachu> so it looks like the old bridge is still on their system
<stokachu> they need to remove openstack0 bridge
<arosales> stokachu: ah, thanks for that insight
<stokachu> np
<stokachu> arosales: i also fixed the lxd charm issue too
<stokachu> arosales: so if they want to redeploy it should all be good
<arosales> Guest89712: ^ fyi remove the openstack0 bridge, and if you are going to redeploy you may want to run "sudo apt update && sudo apt install conjure-up"
<arosales> stokachu: good stuff, but Guest89712 needs to manually remove openstack0 bridge first, correct?
<stokachu> arosales: yea they'll need to do that manually
<stokachu> im going to file a bug to make sure the packaging does it
<arosales> stokachu: ack --thanks
<arosales> stokachu: also is there a good place I can look for change logs to conjure, or should I just look at the .deb package?
<stokachu> arosales: the changelog is usually just high level stuff, best place is to check git log
<stokachu> oh
<stokachu> arosales: https://github.com/conjure-up/conjure-up/releases
<stokachu> i also try to keep a good list here
<arosales> stokachu: ah perfect. I should have look there first
<arosales> thanks for the help stokachu. Guest89712 ^ that should fix you, and thanks for the feedback
<stokachu> np, lemme know if you need anything else
<arosales> stokachu: thanks
<skay_> I want to write a mojo spec that deploys a charm that needs to be deployed with a resource. would I pass some keyword args to the deploy command in my manifest?
<skay_> on the command line, juju deploy <charmname> --resource <name>=<path>
<skay_> is there a way for me to tell if a resource has been updated, e.g. if I attach a new version of a resource
<marcoceppi> skay_: `juju resources`?
<skay_> marcoceppi: I'm not certain if that does what I want, let me try
<tvansteenburgh> skay_: mthaddon is the best one to talk to about mojo stuff
<skay_> tvansteenburgh: I think mojo may not be able to handle resources, but I'm not certain. I opened an issue
<skay_> tvansteenburgh: I think what I'll do to work around it is have a script that runs juju attach
<skay_> the docs say that will kick off an upgrade-hook
<skay_> I can use resource_get in my charm to see if a resource exists (resource_get is available in charmhelpers in hookenv)
<skay_> I'd sort of like to know if there was actuall a new resources and just skip that part if there wasn't
<lazyPower> skay_: you'll need to do fingerprinting
<lazyPower> skay_: there's no other way to know if the resource has changed. as the method blindly returns a path to the resource its fetched and magic happens. In order to know in charm code you'll need to shasum the payload or something to determine if its changed from last run, and use that against a value stored in unitdata or some other means of caching.
<skay_> lazyPower: ack
<lazyPower> skay_: we were talking about adjusting the charm helper to just do that for you, and instead of returning the path, returning a tuple with path and fingerprint. But there's already a good size of code out there consuming the resource helper.
#juju 2016-11-22
<hallyn> what pkg do i need to fix "_juju_complete_2_0: command not found" ?
<stub> lazyPower, skay_ : charms.reactive supplies an any_file_changed helper that works great here. It would also be quite possible to create a resource layer that sets states based on freshness of resources, similar to leadership.* or config.* states
<viswesn> Me using juju 2.0.1-xenial-amd64 version and I am trying to run agent-metadata-url of juju bootstrab commad to set the value but I am getting output to specify the Clouds - http://paste.ubuntu.com/23515660/
<viswesn> I think I am wrong somewhere;
<kjackal> Goodmorning Juju World!
<ionutbalutoiu> Hello guys! How much storage does one user on charm store have ?
<ionutbalutoiu> I'm thinking about storage available for Juju resources.
<rick_h> ionutbalutoiu: a bit :) what are you thinking?
<ionutbalutoiu> We are writing Juju charms for Windows and have some installers (all have aprox 200MB in size) which I was thinking to upload as Juju resources. I was curious about the available storage.
<ionutbalutoiu> 200MB installers for one charm only*
<rick_h> 200MB would be ok
<rick_h> ionutbalutoiu:
<rock> Hi. I developed a charm which will pass the config data to the relation instead of touching nova.conf directly. Then config data will be catched by subordinatecontext . It will generate config from template in nova.conf. After that juju restart the nova-compute service.
<rock> First time when we deploy our charm with one application name and added the relation to nova-compute , then juju modifying nova.conf and then restarting the nova-compute service three times.
<rock> II has to restart only once. but it is restarting three times.
<rock> After restarting nova-compute service only it is taking config values. But I was checked  1) service restart time and 2)nova.conf modification time  it was showing like service is restarted before modifying.
<rock> Why juju is restarting nova-compute service three times?
<Guest50242> I am still having problems with openstack0 and a conjureup0 interfaces with the same IP address during and OpenStack Mitika deployment with Juju and conjure-up
<Guest50242> I had uninstalled openstack and my juju controller and models and reinstalled them.
<shruthima> hi all, Can anyone please suggest how to create terms iam getting the following error http://paste.ubuntu.com/23516679/
<Guest50242> I also ran  sudo apt update && sudo apt install conjure-up before re-installing
<shruthima> hi all, Can anyone please suggest how to create terms iam getting the following error http://paste.ubuntu.com/23516679/
<shruthima> hi all, Can anyone please suggest how to create terms with charm push-term ,iam getting the following error http://paste.ubuntu.com/23516679/
<rick_h> mattyw: ^ did that get built into charm? I don't see it in the latest snap?
<mattyw> shruthima, rick_h what version of charmtools are you using? as far as I know it's only supported in the charmtools snap
<rick_h> mattyw: so just got v2.2 rev 9 of charm
<shruthima> mattyw: charm-tools 2.1.2
<mattyw> rick_h, shruthima I will double check, but last I was aware it was definitely in the latest version of charmtools in the snap - but looks like I'll have to look into it
<shruthima> mattyw: ok . can we use this link for creating terms for now https://docs.google.com/forms/d/1sOfp0a6KLY9kqnpPeGwHv_YQJv7LEbXH1CAV-xBaMjU/viewform?edit_requested=true
<mattyw> shruthima, yes you can - fill the form out and I'll get it setup - and I'll find out why it isn't in charm tools
<mattyw> shruthima, sorry for the trouble
<shruthima> mattyw: no worries , thankyou . i have just filled the form how much time does it take to create the term
<mattyw> shruthima, I'll do it now
<shruthima> mattyw: thank you so much  :)
<mattyw> shruthima, that's been done for you - it's ibm-wlp/1
<shruthima> mattyw: thanks a lot !!
<mattyw> shruthima, no problem, sorry charmtools wasn't working for you - I'm chasing that now
<shruthima> oh k
<skay_> stub: thanks for the comment! I have a snap that I'm attaching as a resource because it's a private one. I know I can publish private snaps in the store, but I'm not sure how I'd provide authentication for a robot-type of account (generate an auth.json to get deployed as a secret? I haven't experimented with that) but attaching a resource is simpler.
<stub> skay_: I think you would need to embed your own credentials , or at least creds of an account with access to update your snap (security issue)
<stub> skay_: If you are dealing with snaps, have a look at the snap layer. Although it doesn't handle that use case (because I don't know how to handle it), it could be useful.
<stub> skay_: (actually, it does support that use case. It allows you to attach snaps as a resource, so exactly what you are trying to do out of the box)
<skay_> stub: I'm using your snap layer. It's useful. Since I don't want to hit the store, I'm checking for hte existence of the resource first
<skay_> stub: it's a nice layer
<stub> skay_: That is what the layer does. It uses the local resource if available, if not falls back to the store. We could add an option to turn off the fallback behaviour if it helps.
<skay_> stub: turning off the fallback behavior would help. I'm doing it by hand for now. I have an install command that is checking when_not 'snap.installed.mysnap' and then it attempts to get the resource. if the resource isn't found, it returns and sets a maintenance status about waiting for the resource. otherwise it calls snap.install
<stub> yup. You get nicer status messages that way, I see.
<skay_> my install hook checks for the 'snap.installed.mysnap' state too
<skay_> is there a way to get values from the metadata.yaml? right now I have the resource name hardcoded :(
<skay_> I couldn't find that in the docs, so I don't know if it's available
<stub> Yes, there is a charmhelpers.core.hookenv method that loads the yaml and hands you a dictionary
<skay_> oh nice. I missed that
<skay_> doh
<petevg> cory_fu: uh-oh. I get an error running matrix off of master, post your task rename: http://paste.ubuntu.com/23517167/
<petevg> digging into it now ...
<petevg> cory_fu: weird. I think that it is because test_2.matrix still references pre-rename stuff. I thought that I saw that refactored in the PR ...
<cory_fu> petevg: Looks like one of the yaml files still has "action" in it
<petevg> cory_fu: yep. That was it. Did you not refactor test_2.matrix? Did something go wonky w/ the merge?
<petevg> Regardless, going to push a fix shortly ...
<cory_fu> petevg: I completely missed that file, sorry.
<hackedbellini> lazyPower: so, just to inform you... The people here have decided to use taiga.io instead of readmine. Because of that I don't need to install redmine on juju anymore.
<petevg> No worries. I totally thought that I had seen the file in your PR.
<petevg> cory_fu: quick PR for you: https://github.com/juju-solutions/matrix/pull/22 (fixes those test files)
<lazyPower> hackedbellini: ah ok. I'm still interested in fixing that at some point. Would you mind terribly linking me to your WIP?
<cory_fu> petevg: The first one could be shortened to "matrix.tasks.glitch"
<cory_fu> But if you prefer the long form, it'll work, too, and I'll go ahead and merge it
<petevg> cory_fu: I shortened it.
<cory_fu> Merged
<petevg> Thank you :-)
<hackedbellini> lazyPower: my WIP as in the changes I've made to the charm to make it work?
<hackedbellini> lazyPower: what I di was: I changed docker-compose.yml to this:
<hackedbellini> https://www.irccloud.com/pastebin/5l4ANfy3/
<hackedbellini> I fixed a the typo on the config where it was "posgres" to "postgres"
<hackedbellini> and I deployed in a xenial machine instead of a trusty, by adding the machine first, applying the 'docker' lxc profile and them deploying to it
<hackedbellini> ah, I also had to build the charm again from the layer using your instructions
<petevg> bcsaller, cory_fu: I rebased and updated that implicit leadership PR here: https://github.com/juju-solutions/matrix/pull/11/files  I think that I've addressed all the comments (unfortunately, selectors still need to be async, as digging leadership out of FullStatus requires a trip across the websocket; it's a quick trip, at least.)
<skay_> would it be bad to call systemctl status everytime the status hook is called?
<marcoceppi> skay_: probably not
<cory_fu> petevg: What about using model.loop.run_until_complete() to make it synchronous?
<cory_fu> Could even do that in libjuju and make it look like a property, perhpas
<petevg> cory_fu: That feels incorrect to me -- if we're making an asynchronous call, we might as well just use the asyncio constructs in their simplest way.
<petevg> The only cost is that we don't get to type check the return. We immediately run that return through type checking for the next selector, however, so we still get immediate feedback on whether we did things correctly.
<cory_fu> petevg: Yeah, that's fair.  I was just thinking that it was only async due to a bug in juju and we intend to make it a property in the future, so that we could maybe fake it for now until the bug is fixed?
<cory_fu> Either way.  It was just a random thought
<petevg> cory_fu: Cool. I have a feeling that this isn't the last thing that we'll need to reach out to the websocket for; making the selectors async makes them more flexible, without any really terrible downsides.
<cory_fu> Good point
<lazyPower> hackedbellini: ack, thanks for the rundown.
<skay_> I posted to suggest @any_resource_changed
<skay_> it would be handy. meanwhile, is the way to check this using resource_get, if it returns a path, then call any_file_changed
<skay_> I couldn't make a callable that returns a list of resource_get since that would not be a list of paths, it could be a list of False
<skay_> or did I misunderstand?
<deanman> Hi, trying to deploy to a private openstack environement and during bootstrapping procedure i can see that it's trying to reach 192.168.x.x address which is basically the subnet inside OS and not reachable outside. Am i doing something wrong?
<mattyw> rick_h, ping?
<rick_h> mattyw: pong, otp what's up
<mattyw> rick_h, just following on from earlier, it looks like charm v2.2 (from the snap) does have the push-term command
<mattyw> rick_h, so I don't think there's anything to fix there
<rick_h> mattyw: k, my question was going to be on the status of what we need for 1.25
<mattyw> rick_h, oooh, that's another question altogether, ping when you're not otp and we can chat
<rick_h> mattyw: k
<hackedbellini> lazyPower: thank you for your time! :)
<lazyPower> anytime
<justicefries> is there a command to move a model between users?
<cory_fu> tvansteenburgh: Can you take a quick look at https://github.com/juju/python-libjuju/pull/18
<cory_fu> tvansteenburgh: I'm wondering if we should do something similar for the other plan components, like units, machines, etc?
<bdx> hey whats up guys
<bdx> I'm getting this -> http://paste.ubuntu.com/23518738/
<bdx> anytime I try to access my controller
<bdx> I seem to be able to login  ... but anything past `juju login` returns ^
<bdx> rick_h: sos
<bdx> rick_h: what do I do when I get this -> http://paste.ubuntu.com/23518738/
<bdx> do I just forget about everything  that ever lived on that controller and start over
<rick_h> bdx: looking
<bdx> not sure why juju is trying to use the 10.20.3.0 network
<bdx> 10.20.3.0/24 is the private ip
<rick_h> bdx: I think that's juju the controller (api server) trying to contact the mongodb service
<bdx> private address space
<bdx> ahh
<rick_h> bdx: worth a check to see if mongodb is up and happy
<rick_h> bdx: that port is the mongodb port
<bdx> ok
<bdx> rick_h: what is the perferred method of restarting mongo?
<rick_h> bdx: sudo service juju-db restart I think?
<bdx> ahh, thanks
<rick_h> bdx: /me goes to dbl check the service name of the juju mongodb
<bdx> rick_h: looks like that did the trick
<bdx> ok, I've got `juju status` returning successfully
<rick_h> bdx: k, so that's the error, so the question now is why did mongodb bite the farm and is there something going on there
<rick_h> bdx: so have to check the mongodb logs, syslog/etc for hints
<bdx> rick_h: ok, I'll get a bug in about this later today
<bdx> thanks for the quick rescue
<rick_h> bdx: k, sorry for the trouble but glad you got back/running/debuggable
<rick_h> np, any time
<bdx> no worries, thank you
<marcoceppi> rick_h bdx follow up, lets not make that error message so cryptic
<bdx> totally
<rick_h> marcoceppi: +1, will file that one now
<bdx> marcoceppi: rick_h: I've been having issues with juju closing ports on me
<bdx> marcoceppi: rick_h: its most likely intended, but its becoming an issue
<rick_h> bdx: closing ports on you in what way? e.g. open-ports get closed later after expose is run?
<cory_fu> tvansteenburgh: In libjuju, do you think that wait_for_new should, instead of watching explicitly for "add", watch for any event that indicates the entity is in the model and return it then?  Or is it important to make sure it only ever matches the "add"?
<bdx> marcoceppi: rick_h: for example, keystone only exposes port 5000, but I need to open up 35357, so I do that manually in the provider security group rules
<tvansteenburgh> cory_fu: i think there is an important use case for the latter, when you are creating something but don't know what the entity id will be
<cory_fu> tvansteenburgh: I ran up against that on run_action.  It never saw an "add" event, and instead just saw a "change" which did add it to the model.  I worked around it by using _wait('action', action_id, None)
<cory_fu> tvansteenburgh: True
<bdx> marcoceppi, rick_h: after an amount of time, juju will revert any changes I've make to the security group
<tvansteenburgh> cory_fu: yeah, that's why _wait was added
<cory_fu> tvansteenburgh: But wait_for_new requires an entity_id, tho
<bdx> such that only the ports specified by the charm can remain open
<tvansteenburgh> cory_fu: but it can be None
<rick_h> bdx: ah, yes it's a security thing
<rick_h> bdx: it's making sure things are kept up to the model defined
<cory_fu> tvansteenburgh: Hrm.  That's not clear from either the signature nor docstring.
<tvansteenburgh> cory_fu: that's fair
<cory_fu> tvansteenburgh: Perhaps it should be entity_id=None and if it's not None, we can watch for either "add" or "create"?
<cory_fu> Or I could just keep using _wait() and stop complaining
<cory_fu> :)
<bdx> rick_h: so I should maintain custom charms for every charm I want a port open on that isn't specified by the charm?
<cory_fu> tvansteenburgh: But I'm changing that section anyway, so...
<rick_h> bdx: hmmm, maybe something like a port-opening subordinate atm?
<rick_h> bdx: that declares it can open a range and then opening parts of that range when required? maybe via config?
<rick_h> bdx: I don't recall how fine grained the ranged open-ports stuff works out
<bdx> rick_h: totally ..... fck
<rick_h> bdx: ? /me can't process that line
<vmorris> bdx, rick_h: https://jujucharms.com/u/caio1982/open-port
<tvansteenburgh> cory_fu: do what you think makes the most sense, i'll comment in the pr if i have a different opinion
<bdx> vmorris: nice! thx!
<cory_fu> :)
<rick_h> vmorris: niiice, gotta love it when you dream it and it's there waiting for you
<vmorris> heh
<vmorris> i was curious to know myself
 * rick_h is always happy when something that doesn't work ootb has at least a chance to work via some method. Flexibility ftw
<bdx> rick_h, marcoceppi: nothing is going my way today ... -> https://s21.postimg.org/srmeqmkhj/Screen_Shot_2016_11_22_at_1_04_28_PM.png
<bdx> was preparing for a manual provider production deploy this week
<bdx> shot down, simply on the fact that RS doesn't support xenial yet
<bdx> ooooh, I an bootstrap juju 2.0 on trusty huh?
<bdx> *can
<rick_h> bdx: :/ ouch
<rick_h> bdx: the issue is going to be making sure you have a lxd/lxc 2.0+ on trusty and to be honest it's not tested or beat on as well as xenial/lxd
<rick_h> bdx: so you can go for it, but I'd also make sure to do some pre-lim testing and validating you can put together what you want with the containers on those hosts
<bdx> rick_h: totally ... so not into doing any of ^ though .... I already know the anwser ... bunch of work towards technical debt
<rick_h> bdx: /me checks version of lxd in trusty backports
<bdx> rick_h: I don't need lxd in this
<rick_h> bdx: ah ok
<bdx> this was suppost to be my first prod juju deploy too, it will have a lot of eyes on it
<bdx> suppose to *
<bdx> thinking I should petition to wait it out maybe ..
<cory_fu> tvansteenburgh: PR updated
<tvansteenburgh> cory_fu: k
<cory_fu> petevg, bcsaller: https://github.com/juju-solutions/matrix/pull/21 updated
<petevg> cory_fu, bcsaller: just a quick heads up: I made a new build of python-libjuju, and pushed it to the wheelhouse in matrix master. Pull to get something that includes both cory_fu and my fixes from today.
<cory_fu> petevg: Did you update libjuju on matrix master?  Is it anything other than libjuju master?
<cory_fu> Oh, ha
<cory_fu> petevg: That screws up my PR
<cory_fu> Probably should have just waited for that PR to land
<petevg> cory_fu: I had a build checked into the PR that I just merged, so it would have been screwed up anyway. Sorry.
<cory_fu> petevg: No worries.  I can rebase
<petevg> Cool.
<kwmonroe> hey cory_fu petevg.. does this failure look familiar on NN install? http://paste.ubuntu.com/23519035/  subsequent hook retry works, but it seems to be an agent comm failure, so i'm not sure how/where the charm could handle that if the model didn't allow for hook retry.
<petevg> kwmonroe: that error is not immediately familiar. If its succeeding on retry, I might have just missed it, though.
<cory_fu> kwmonroe: Wow, yeah.  I have not seen that, nor do I have any idea how to guard against it
<kwmonroe> ok.. beisner almost had me convinced to turn off hook retries.  what a silly thing to suggest ;)
<kwmonroe> eventual success ftw
<cory_fu> bcsaller: Your comments were noted and addressed in https://github.com/juju-solutions/matrix/pull/21
<cory_fu> petevg: I rebased away the conflict on the above PR
<cory_fu> petevg: It still shows libjuju as changed, though, because I did fresh wheelhouse just to make sure it had the PR that tvansteenburgh merged a few minutes ago
<petevg> @cory_fu: Cool. Merged.
#juju 2016-11-23
<beisner> kwmonroe, haha - clearly, layer basic attempted a config-get too early.  ;-)
<kwmonroe> i don't think so beisner.. i didn't show the whole log (which i have conveniently lost by now), but the charm had already gone through "installing charm software", after which i think should be fair game to config-get to your heart's content.  i think the issue was more with "error: connection is shut down", as in maybe config-get isn't safe to run if a unit's jujud can't contact the controller.
<beisner> kwmonroe, mostly joking.  but yeah, the charm can't be expected to solve tooling/agent errors.  i'd raise a core bug.
<kwmonroe> beisner: i appreciate your jovialityness.  i also like your no-retry stance and hope to live in your world someday.  it's just so much easier to push those silly errors under the covers until even a retry isn't enough.  it makes debugging future-kevin's problem, and i don't care about that guy.
<beisner> kwmonroe, ha!  happy to provide levity.  well to be clear and differentiate:  i think failed hook retry is a good thing in user/production land.  it removes needless face-slaps from transient infra/interweb type issues.  it's in dev/test/gates where i think it is actually counterproductive.
<kjackal> Good morning Juju world!
<Ankammarao> Hi All
<Ankammarao> Hi All
<Mmike> Hi, lads. Any news on when 1.25.8 is going to hit the archives?
<marcoceppi> Mmike: should be in the next hour, at most, are you pulling from the stable ppa or the Ubuntu archive?
<Mmike> marcoceppi, depending on the customer :) I'm asking for trusty so both are applicable
<marcoceppi> Mmike: it's available here https://launchpad.net/~juju/+archive/ubuntu/1.25
<Mmike> oh
<Mmike> haven't checked the ppa today
<Mmike> thn marcoceppi
<Mmike> thnx
<Ankammarao> Hi
<cory_fu> petevg: Added a reply to https://github.com/juju-solutions/matrix/issues/24 to clarify that I didn't mean that we should break pre-deployment.  I agree that that's a useful dev feature.
<petevg> cory_fu: thx for the clarification. I'm +1 on the issue now.
<Ankammarao> Hi All
<Ankammarao> can any on tell me to create terms
<Ankammarao> i am not aware of creating terms
<rick_h> mattyw: you able to help Ankammarao?
<cory_fu> kjackal: Am I correct in remembering that you can build Bigtop charms with a layer option "bigtop_version: master" or similar to get a charm that deploys the cutting edge of Bigtop?
<kjackal> this is somewhat accurate. But we decided we will not be supporting this option/path
<kjackal> So if i were to guess i would say it will not work
<kjackal> However, I saw someone asking for this in the bigtop list
<kjackal> cory_fu: ^
<cory_fu> kjackal: Yeah, that was Amir.  I think it's safe to let him know that it's available as an unsupported dev option
<kjackal> sounds resonable
<cory_fu> kjackal: Am I right in remembering the value being "master"?
<kjackal> I do not remember right now, let m echek
<kjackal> yes it is master
<narindergupta> hi all i started seeing the error during deployment ssl.SSLError: [Errno 1] _ssl.c:510: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version
<narindergupta> https://build.opnfv.org/ci/view/joid/job/joid-deploy-baremetal-daily-master/1171/console
<bdx> charmstore is down
<bdx> to some extent
<bdx> https://s11.postimg.org/d2frsznwz/Screen_Shot_2016_11_23_at_9_12_24_AM.png
<urulama> web part is down atn, service is up and juju deploy still works
<urulama> proxy issues
<bdx> urulama: ok, thanks
<cory_fu> petevg: Hrm.  I didn't run in to any issues with a fresh run of rules.1.yaml on that branch of matrix with a fresh model.  :/  I guess matrix and unit logs will be necessary.
<petevg> cory_fu: I just did a re-run, and didn't run into an issue, either. Except for realizing that I was on the wrong branch, which definitely isn't an issue w/ your code :-)
<cory_fu> heh
<petevg> I'm now running on the actual right branch. The end result should be a blank model, correct?
<petevg> Yay! That's what happened.
<petevg> cory_fu: was going to give bcsaller a chance to comment before merging, but the branch looks good to me, and the tests run great, too.
<urulama> bdx: should be back up
<petevg> cory_fu: just left a comment on your PR. There is a test that needs updating (didn't see it until after I blew up .tox and rebuilt)
<bdx> urulama: nice, thx
<mattyw> rick_h, sorry - I can now, but it seems like Ankammarao has gone?
<mattyw> rick_h, for future reference, we do have docs for terms: https://jujucharms.com/docs/2.0/developer-terms
<rick_h> mattyw: sorry, was otp and trying to punt
<cory_fu> petevg: blarg
<cory_fu> :)
<mattyw> rick_h, no problem at all, I was afk and forgot to set my nick, I'll keep an eye out tomorrow
<cory_fu> petevg: Updated
<cory_fu> Thanks for the catch
<petevg> cory_fu: after running glitch, I also notice that we can get into a state where we can't reset. I think that this is more of an underlying juju issue than an issue with your code, though. Will save off logs so that we can file a bug.
<cory_fu> petevg: I think I might have seen that.  Is it due to agents being in a "failed" state?  I added some additional checks to the health task to spot that
<petevg> cory_fu: yes.
<petevg> cory_fu: I see an error in the logs, but I suspect that it's a lie, and that the actual problem is that the juju agent is borked: http://paste.ubuntu.com/23523296/
<cory_fu> petevg: So, that should now set the "health.status.unhealthy" state, but I'm not sure how to properly handle that.
<viswesn> I am getting error "Failed to copy file" during bs_manager.booted_context() and then task goes for destroying the controller; - http://paste.ubuntu.com/23523247/
<viswesn> how to overcome this issue
<petevg> cory_fu: I can get it unstuck by running "juju destroy-machine --force <int>", where <int> is the machine name.
<cory_fu> petevg: This touches on bcsaller's comment on the PR and we eventually might want to move to managing entire models.
<petevg> cory_fu: in any case, I merged your PR. We can open a separate ticket to figure out what we want to do when the usual way of resetting the juju model doesn't work.
<bdx> https://s22.postimg.org/oc82s31g1/Screen_Shot_2016_11_23_at_10_59_09_AM.png
<bdx> SOS ^
<bdx> ahh, finally logged in
<bdx> looks like my controller is super loaded
<bdx> https://s21.postimg.org/9mg4bhwef/Screen_Shot_2016_11_23_at_11_00_08_AM.png
<bdx> jesus
<bdx> marcoceppi, rick_h: I'm thinking I'm going to need a massive controller here
<bdx> rick_h: per the rackspace xenial support thing ... I was able to negotiate a deal to give me xenial for stateless services, even though its not supported yet :-)
<marcoceppi> bdx: what version of Juju?
<bdx> marcoceppi: 2.0.1-xenial-amd64
<marcoceppi> bdx: do you have a lot of models/applications deployed?
<bdx> marcoceppi: http://paste.ubuntu.com/23523955/
<bdx> I may of had +5-10 more machines deployer earlier
<marcoceppi> bdx: so a decent amount. This might be a bug in the controller, but you can do one of two things. The first is you can just deploy controllers on larger instance sizes. The second is to enable-ha on the controller which will also help load balance reqeusts
<bdx> marcoceppi: ahh, controller ha faciltates load balancing too? sweet!
<bdx> ahh, only of requests though
<marcoceppi> bdx: I'm like 90% sure it does, basically all the agents get the address of all the controllers, and will over time spread those calls around
<bdx> ok
<rick_h> marcoceppi: bdx yes, reads, but not writes
<marcoceppi> rick_h: \o/ thanks for the confirmation
<rick_h> bdx: will be interesting to see is 2.0.2 helps at all
<rick_h> bdx: there's a lot of discussion and work going in to watching that as folks push things with multi-models/etc.
 * marcoceppi eod's for some R&R, cheers o/
<rick_h> enjoy and have a good holiday marcoceppi
<bdx> marcoceppi: thanks as always for your insight, happy holidays!
<bdx> rick_h: what work is going into 2.0.2 that you are thinking will help lighten the load?
<rick_h> bdx: so 2.0.2 is cut but in vetting atm because there might be a regression on maas with it
<rick_h> bdx: but it does some work to help with cpu load.
<rick_h> bdx: our internal folks are chomping to get at it
<bdx> nice, good to know
<rick_h> bdx: but there's some other work going on around identifying storms of activity and working on how to prevent the controller from getting swamped
<rick_h> bdx: and for the cycle as a whole, there's a big goal to reduce the cpu load, especially at idle, because there's more event handling going on than you'd think
<bdx> rick_h: how is that being approached?
<rick_h> bdx: so the idle work is that we've got long running controllers with different sized models and identifying what events is keeping the CPU going
<rick_h> bdx: and so there's some work to move to pub/sub vs poll/etc
<bdx> ahh nice
<rick_h> bdx: so that things are only handled when required vs old fashioned whole sale
<rick_h> bdx: so there's some very low hanging fruit
<smgoller> hey, so I'm trying to use juju 2 (currently 2.1 beta 1 I think, whatever's latest as of yesterday) with maas 2, and when i bootstrap, it keeps trying to talk to version 1 of MAAS' API, which has been deprecated. Any ideas on how to fix this?
<smgoller> yeah, 2.1 beta 1 and maas is 2.1.1+bzr5544
<thumper> smgoller: do you have the endpoint set correctly?
<thumper> smgoller: because that should just work
<thumper> I think we even have CI tests to ensure it does
#juju 2016-11-24
<smgoller> thumper the endpoint is set to similar to the example: http://my.mass.server/MAAS
<thumper> hmm...
<thumper> can I get you to put a slash on the end?
<thumper> it shouldn't matter, but might
<smgoller> this is the error:
<smgoller> hold on let me pastebin it
<smgoller> thumper http://paste.ubuntu.com/23524903/
<smgoller> gut feeling is the slash won't matter, but i can try it if you like
<thumper> nuh
<thumper> that's fine
<thumper> no idea why that is happening to be honest
<thumper> it shouldn't
<thumper> can you hit the 2.0 api endoint without juju in the way?
<smgoller> yes
<smgoller> thumper let me reverify that, actually
<thumper> from the controller machine?
<smgoller> juju and mass box are the same
<smgoller> maas box that is
<smgoller> thumper  hitting http://maas.goller.lan/MAAS/api/2.0/version/ works fine from both maas/juju machine and another machine on the network
<smgoller> oh
<smgoller> hm.
<thumper> ?
<smgoller> n/m for some reason I was thinking the controller being boostrapped couldn't talk to the maas box, but it's being bootstrapped from the maas box :)
<smgoller> and it's definitely ssh'ing into it
<smgoller> so it successfully launches the host via maas, right now it's installing the machine agent
<rick_h> smgoller: does the 1.0 api version exist on 2.0?
<rick_h> smgoller: e.g. can you take that url and hit it successfully as does the 1.0 api version say it's maas 2.0?
<smgoller> not any more apparently. If you hit 1.0 it says it's been removed.
<rick_h> smgoller: what's the version response from that call above?
<rick_h> e.g. what does maas say its version is?
<smgoller> 2.1.1+bzr5544-0ubuntu1
<rick_h> ok, so this is a dev version of maas? they just got 2.1.1 out today right?
<smgoller> er
<smgoller> it's maas-stable repo
<rick_h> ok, the +bzr/etc made me suspect it as a dev version but ok
<rick_h> I know that froboware was having issues with 2.1.1 and juju trunk, but it was in getting vmaas machines working vs bootstrap/api version I thought I understood it to be
 * rick_h wonders if they yanked something and we've not noticed it yet. I just sent a request to QA to update our maas to 2.1.1 today based on the new release
<rick_h> smgoller: I'll have to spin up a vm and try the latest maas and see what I can see
<rick_h> thumper: if you get a sec I wanted to chat please
<thumper> hmm...
<thumper> rick_h: hey
<smgoller> rick_h: awesome. thanks!
<rick_h> thumper: can I steal 15min ?
<thumper> rick_h: sure
<rick_h> smgoller: heh don't thank me yet, going to take a sec
<rick_h> thumper: do you have a bluejeans or something you use?
<smgoller> rick_h: you're looking into it, that's all that counts.
<rick_h> thumper, so I can't find any examples of us parsing this complicated version string on the gomaasapi code: https://goo.gl/uKxsbE
<rick_h> thumper: my guess is that the version checker is failing to parse, returning an error, and that's turning into an error that it's not a 2.0 supported version and it falls back to 1.0
 * thumper looks
<rick_h> thumper: but I don't follow that parser code well enough for the problem to jump at me and the controller_test.go code doesn't have anything testing it's parsing I'd expect to see.
<thumper> it just unmarshalls the json
<rick_h> thumper: any chance there's a fast way to test that method against the version string 2.1.1+bzr5544-0ubuntu1 ?
<thumper> paste me the version string
<rick_h> thumper: https://goo.gl/RQn9Im is what I think is failing
<rick_h> thumper see line above, the 2.1.1+bzr...
<rick_h> "version": "2.1.2+bzr5555-0ubuntu1" is my json output
<thumper> that isn't valid json
<rick_h> thumper: no, you want the full json?
<thumper> yes
<rick_h> thumper: http://104.199.217.13/MAAS/api/2.0/version/
 * thumper pokes the code
<thumper> no... that should be fine
<rick_h> hmm, ok then. No idea. I can verify that you're right. It tries 2.0 first, and the error smgoller is seeing is when it fails to find a valid version and that version is put together by parsing that output.
<thumper> smgoller: can you try bootstrap with --debug?
<thumper> smgoller: that will at least get the line that is failing the 2.0 check to be logged
<rick_h> smgoller: +1 be curious if that debug line about "read version failed:" comes out in there
<thumper> rick_h: that isn't what is done
<thumper> rick_h: the 2.0 endpoint is hit, and the only thing that is looked at in that response is the capabilities array
<rick_h> thumper: ? /me is reading it wrong? readVersionFailed is checking it parsed the json response?
<thumper> parse just hits the url and parses the json
<thumper> version is the path
<thumper> not the field name
<rick_h> thumper: understand, sorry. I just mean the output of version. in that readAPIVersion
<thumper> it would say 2.0
<rick_h> so bootstrap against this maas with 2.0.0 works (well it complains about lack of machines but gets that far)
 * rick_h upgrades to devel ppa
<rick_h> smgoller: where did you get your juju from?
 * rick_h smacks head for not upgrading juju 2 vs just juju
<rick_h> smgoller: ok, I can't replicate with the 2.1 beta1 either. I have to say to check your url and your credentials in .local/share/juju/credentials.yaml  and clouds.yaml
<rick_h> I don't think it's an auth problem, I get 01:46:03 ERROR cmd supercommand.go:458 Authorization Error: Invalid API key.
<rick_h> if I change my oauth token...
 * rick_h waits for bootstrap to timeout with a bad url for the maas endpoint...
<rick_h> boom, here we go I bet: 01:49:22 DEBUG maas controller.go:80 read version failed: &errors.Err{message:"", cause:(*url.Error)(0xc82044a000), previous:(*errors.Err)(0xc82040c0a0), file:"github.com/juju/gomaasapi/controller.go", line:794}
 * rick_h now waits for v1.0 to time out
<rick_h> boom! {Get http://104.199.217.130/MAAS/api/1.0/version/: dial tcp 104.199.217.130:80: getsockopt: connection timed out}])
<rick_h> ok, so that's what it is. failure to reach the maas server at all
<rick_h> thumper: smgoller ^
<rick_h> the bug I'll file from here is that we need to output to the user when we fail to connect/find v2.0 so that's much more obvious in the output to the user
<rick_h> because you can't tell "cannot communicate with maas" vs "wtf are you looking at the 1.0 api url?"
<thumper> huh
<thumper> interesting
<rick_h> https://pastebin.canonical.com/171681/ for full output
<rick_h> smgoller: filed https://bugs.launchpad.net/juju/+bug/1644395 on your behalf
<mup> Bug #1644395: failure to connect to maas endpoint looks the same as wrong maas version <observability> <usability> <juju:Triaged> <https://launchpad.net/bugs/1644395>
 * rick_h stops working now...
<viswesn> Do juju bootstrap output can be send to log file? rather than stdout or stderr?
<viswesn> I am writing juju-ci-tool and I want the output of juju bootstrap redirected to a file
<hallyn> juju won't shut up: Nov 24 05:39:09 sergeh2 mongod.37017[16252]: Thu Nov 24 05:39:09.595 [conn26] command juju.$cmd command: { getLastError: 1, j: true } ntoreturn:1 keyUpdates:0  reslen:83 111ms
<viswesn> redirecting stdout and stderr fails on juju-ci-tools; - http://paste.ubuntu.com/23525597/
<viswesn> how to overcome this issue
<Ankammarao> Hi All
<Ankammarao> i am new to terms
<Ankammarao> can any tell me how to create terms or push terms
<lazyPower> Ankammarao: https://jujucharms.com/docs/2.0/developer-terms
<Ankammarao> thanks lazyPower, but charm push-term  is not working for my machine
<Ankammarao> giving error like ERROR unrecognized command: charm push-term
<lazyPower> Ankammarao: do you have the charm package installed?
<Ankammarao> yes installed
<lazyPower> Ankammarao: did you install via the snap?
<Ankammarao> yes
<viswesn> I am getting always juju version - 2.1-beta2-xenial-amd64 rather than stable version; I also ran - sudo add-apt-repository ppa:juju/stable
<Ankammarao> snap has installed at /snap/bin/charm
<viswesn> how to get stable rc3 version of juju
<lazyPower> Ankammarao: would you mind filing a bug here? https://github.com/juju/charmstore-client/issues
<Ankammarao> ok sure
<viswesn> how to upgrade to juju2.0 rc3 version from my current juju version 2.1-beta2-xenial-amd64
<kjackal> Good morning Juju world!
<Ankammarao> Hi mattyw
<Ankammarao> can you help me to create terms
<feral_> yo, do you guys know of any scalable web crawler or screen-scraper charm bundles?
<zeestrat> viswesn: Do you perhaps have the juju/devel ppa for juju installed alongside juju/stable? You should be able to list them with: "ls -la /etc/apt/sources.list.d/"
<zeestrat> viswesn: Is there a reason that you want the juju2.0 rc3 release? Just asking because it is an older release now. See https://launchpad.net/juju/+series
<viswesn> zeestrat, so how can I upgrade to new version
<viswesn> right now I am using - 2.1-beta2-xenial-amd64
<viswesn> looking in to the launchpad.net/juju/+series I think the version which I am using it good to go ; Please correct me, if I am wrong
<zeestrat> viswesn: The latest release in the juju/stable ppa is 2.0.1 so if you want to get on stable you'll have to make sure you only have the juju/stable ppa installed, do apt update, then downgrade or remove and reinstall juju
<viswesn> Thanks zeestrat
<viswesn> Zeestrat, Is I am missing something ? - http://paste.ubuntu.com/23526316/
<viswesn> I am still seeing the same version after updating juju/stable
<zeestrat> viswesn: Could you paste the output from "ls -la /etc/apt/sources.list.d/" and "dpkg -l | grep juju"
<viswesn> zeestrat, http://paste.ubuntu.com/23526325/
<viswesn> Zeestrat: http://paste.ubuntu.com/23526325/
<feral_> can the charm command line tool list all bundles in the charm store?
<zeestrat> viswesn: Thanks. Seems you have the juju/daily ppa in there. Try this: http://paste.ubuntu.com/23526346/
<viswesn> Finally it is working :)
<viswesn> Thanks a lot Zeestrat
<zeestrat> No worries. Good luck!
<mattyw> Ankammarao, hey there -sorry, we keep missing each other
<mattyw> Ankammarao, you were asking about terms?
<mattyw> Ankammarao, there's a good guide to terms here: https://jujucharms.com/docs/2.0/developer-terms. If you have any more questions I'll be around all day
<Ankammarao> matty i have tried with charm push-term command
<Ankammarao> but its giving error to me
<Ankammarao> ERROR unrecognized command: charm push-terms
<mattyw> Ankammarao, what version of charm tools do you have?
<mattyw> Ankammarao, only charm tools 2.2 from the snap has push terms
<Ankammarao> charm-tools 2.1.9
<mattyw> Ankammarao, you'll need to get 2.2 from the snap store
<Ankammarao> can you tell me how to upgrade the charm tools
<mattyw> Ankammarao, snap install charm should do it?
<Ankammarao> yeah i tried it and it has installed
<mattyw> you'll need to make sure you run charm from the snap path
<mattyw>  /snap/bin/charm I believe
<Ankammarao> yes i tried
<Ankammarao> charm is not a directory
<mattyw> charm should be the binary
<mattyw> Ankammarao, did you do snap install charm?
<Ankammarao> yes i did
<mattyw> Ankammarao, so /snap/bin/charm push-term -h should work?
<Ankammarao> its working
<Ankammarao> giving some output
<mattyw> evilnickveitch, ping?
<evilnickveitch> mattyw, hey
<mattyw> evilnickveitch, so I need to improve the docs here: https://jujucharms.com/docs/2.0/developer-terms
<mattyw> evilnickveitch, and I'd like them to be live asap - which branch of juju/docs should I submit the pr to?
<evilnickveitch> mattyw, Hi, okay. The PR should be against master - we'll backport to relevant versions
<evilnickveitch> thanks
<mattyw> evilnickveitch, ok great, I'll give you a friendly ping when it's done, cheers
<Ankammarao> mattyw, so i can use /snap/bin/charm push-term terms.txt my-group/my-terms command to create terms?
<mattyw> Ankammarao, you can indeed
<Ankammarao> matty, what terms.txt contains
<mattyw> evilnickveitch, https://github.com/juju/docs/pull/1543
<mattyw> Ankammarao, terms.txt should contain the plain text of the terms you are publishing
<mattyw> Ankammarao, are you looking to publish a charm that requires some terms and conditions to be signed?
<Ankammarao> i have already pushed the charm to the charm store, but i got review comments terms missing or terms not created for the charm
<Ankammarao> so i want to create or push terms to the charm
<mattyw> Ankammarao, are you expecting to need to create terms for the charm?
<mattyw> Ankammarao, as the charm author that's you're decision, if you don't require terms and conditions to be signed you don't need to include them
<Ankammarao> mattyw, when i tried to deploy the charm from the charm store it was asking for agree the terms
<Ankammarao> mattyw so can we remove the terms if we do not require
<mattyw> Ankammarao, which charm is this? to agree to terms you just need to run juju agree...
<mattyw> Ankammarao, and yes - if you don't require uses to sign any terms you can just not specify any in the charm's metadata.yaml
<Ankammarao> mattyw ,ibm-platform-ac
<mattyw> Ankammarao, and then users won't get prompted to agree to terms when they deploy the charm
<mattyw> Ankammarao, this charm? https://jujucharms.com/u/ibmcharmers/ibm-platform-ac/trusty/4
<Ankammarao> mattyw,yes this only
<mattyw> Ankammarao, so if you have any terms and conditions that users of this charm should sign they should be uploaded using charm push-term filename.text owner/termname
<mattyw> Ankammarao, I believe there are a number of ibm terms already uploaded, but the ones needed by this charm is obviouslly an ibm decision
<mattyw> Ankammarao, but any terms that need to be signed should be put in plain text format and put into a file which is passed as an argument to charm push-term
<mattyw> Ankammarao, and then when the user deploys the charm and does juju agree they will be presented with the contents of this file
<Ankammarao> mattyw, i am getting this error "error: could not read contents of "ibm-platform-ac.txt": open ibm-platform-ac.txt: permission denied" while pushing terms
<Ankammarao> mattyw, i just pasted the content into the file .txt
<mattyw> Ankammarao, that error would be a local problem (local to your machine) it means the command is unable to read from that file
<Ankammarao> mattyw, thanks for help and i'll try to resolve the issue with .txt and i'll push the terms
<mattyw> Ankammarao, no problem, sorry the docs weren't clearer, I've submitted a fix for that, if you have any more issues just let me know
<Ankammarao> mattyw, ok np
<capsali> hi guys
<capsali> we have a small problem with juju2 and i hope i can get some help with it
<capsali> we have juju2 deployed in ha with 3 state machines, MAAS as backend
<capsali> there are 6 total models
<capsali> the largest modle has 70 machines
<capsali> and the smallest one has 4 machines
<capsali> the problem is that it takes a long time for any command givent ot juju
<capsali> on the larger model if i issue a juju status command it hangs around 40-60 second untill it displays the results
<capsali> on the 4 machines model it is quicker, but still around 10 seconds
<capsali> for 'juju models' the same problem, round 1min to display results
<capsali> i have been tailing juju logs with no luck
<capsali> there isn;t any relevant error in the logs that could trace to this problem
<capsali> the only thing that is weird to me is that from the 3 state machines, two of them have mongodb consume around 5% of cpu and jujud around 55%
<capsali> the first state machine mongodb stays at around 80% sometimes reaching 160-200% cpu
<capsali> any ideas on what could be the root cause for this slowness?
<zeestrat> Hey capsali I don't have an answer but I saw bdx having some similar load issues yesterday: https://irclogs.ubuntu.com/2016/11/23/%23juju.txt
<zeestrat> Also, it's pretty quiet here today from juju folks due to it being a US holiday.
<pmatulis> capsali, yeah, best open a bug
<capsali> thanks guys
<capsali> i would open a bug but i don't have any relevant logs to show
<capsali> that's why i didn't open a but yet
<capsali> and happy holiday
<capsali> thanksgiving right?
<viswesn> I am using logger module to write log messages to file in juju-cli-tool but I am getting logs that were specific to juju-cli-tool in the log file where as the log output from juju is shown on stdout but not in the file; how to redirect that to the log file?
<magicaltrout>  isn't it nice when all of the USA is offline! ;)
<mattyw> evilnickveitch, you still about?
<evilnickveitch> mattyw, yup, I'm just working on backporting that fix
<mattyw> evilnickveitch, you work fast - I was just about to ask what I should be doing :)
<evilnickveitch> mattyw, should be live in stable docs in about 10 mins
<mattyw> evilnickveitch, many thanks
<evilnickveitch> np
<evilnickveitch> thanks for helping
<bdx> rick_h: happy thanksgiving
<bdx> rick_h: hitting this pretty regularly -> http://paste.ubuntu.com/23528908/
<bdx> rick_h: don't know if you made a bug for it the other day or not
<bdx> can't even access my controller -> http://paste.ubuntu.com/23528918/
<bdx> https://bugs.launchpad.net/juju/+bug/1644634
<mup> Bug #1644634: cannot access controller <juju:New> <https://launchpad.net/bugs/1644634>
#juju 2016-11-25
<kjackal> Good morning Juju world!
* botwanker changed the topic of #juju to: Your mother is available, for sex?
<botwanker> jam,  jcastro,  marcoceppi,  mgz:
<botwanker> Your mother is available, for sex?
<botwanker> admcleod_,  ahasenack,  aisrael,  ajmitch,  alexlist,  aluria,  Ankammarao,  anrah,  anthonyf,  arosales,  axino,  axw,  babbageclunk,  Baqar,  bcsaller,  bdx,  beisner,  bildz,  bitchecker,  BjornT,  blackboxsw,  BlackDex,  bladernr`,  blahdeblah,  bloodearnest,  blr,  bodie_,  bogdanteleaga,  bradm,  bryan_att,  cargill,  cargonza,  caribou,  cdeyoung,  chris38,  ChrisHolcombe,  chrome0,  cmars,  coreycb,  cory_fu,  cppforlife_,  CyberJacob,  Cynerva,  
<botwanker> frobware,  geekgonecrazy,  gnuoy,  gsamfira,  hackedbellini,  hatch,  hazmat,  hecliunyx,  higgins,  hloeung,  iatrou,  icey,  ionutbalutoiu,  iptable,  jacekn,  jamespage,  jasondotstar,  jcsackett,  jhegge,  jhobbs,  john51,  jose,  josvaz,  jrwren,  junaidali,  kadams54,  karlthane,  khyr0n,  kina_,  kirkland,  kjackal,  kragniz,  kwmonroe,  lamont,  larrymi,  lathiat,  lazyPower,  lezbar,  lifeless,  LiftedKilt,  lukasa,  lutostag,  macgreagoir,  magi
<botwanker> neiljerram,  niemeyer,  nihas,  nottrobin,  ociuhandu,  Odd_Bloke,  pcdummy,  perrito666,  petevg,  pjdc,  plars,  pmatulis,  psivaa,  rbasak,  rcj,  redir,  rektide_,  rharper,  rick_h,  rockstar,  Roconda_,  rogpeppe1,  rvba,  ryebot,  ryotagami,  saibarspeis,  SaltySolomon,  SaMnCo,  sarnold,  scuttle|afk,  SimonKLB:
* aluria changed the topic of #juju to: Welcome to Juju! || Docs: http://jujucharms.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://review.juju.solutions || Unanswered Questions:  http://goo.gl/dNj8CP || Youtube: https://www.youtube.com/c/jujucharms || Juju 2.0 release notes: https://jujucharms.com/docs/stable/reference-release-notes
<blahdeblah> thanks aluria - I was just trying to find the old one :-)
<aluria> cheers
<blahdeblah> Why they let 12-year-olds make bots, I'll never know...
<aluria> :)
<magicaltrout> bring back the chap who keeps talking about Allah at least he's not just listing nicks
<Ankammarao> Hi mattyw,
<mattyw> Ankammarao, good morning
<Ankammarao> mattyw,Good morning
<Ankammarao> i have tried with your given commands for pushing terms but it was giving error
<Ankammarao> mattyw, error: cannot get discharge from "https://api.jujucharms.com/identity/v1/discharger": third party refused discharge: cannot discharge: user is not a member of required groups
<Ankammarao> mattyw, any idea about this error
<mattyw> Ankammarao, what was the name of the term you were trying to push?
<mattyw> Ankammarao, it's likely that you aren't a member of the group you're pushing the term to
<Ankammarao> mattyw,ibm-platform-ac term
<Ankammarao> matty,which group it is refering to
<mattyw> Ankammarao,  that name needs to be a group in launchpad - for example https://launchpad.net/~ibmcharmers
<mattyw> Ankammarao, so ibm-platform-ac would need to be a launchpad group
<mattyw> Ankammarao, or you could upload terms to ibcharmers/ibm-platform-ac
<Ankammarao> mattyw, yes i am trying that way only /snap/bin/charm push-term ibm-platform-ac.txt ibmcharmers/ibm-platform-ac
<mattyw> Ankammarao, are you a member of the ibcharmers group on launchpad?
<mattyw> Ankammarao, I think that error is because you aren't
<Ankammarao> mattyw, i'm not added to the group
<mattyw> Ankammarao, you'll need to contact one of the admins for https://launchpad.net/~ibmcharmers
<mattyw> Ankammarao, and they should be able to get you added to that group
<Ankammarao> mattyw,ok i'll request to them to add my name
<mattyw> Ankammarao, I'll talk to some folk about improving that error message :)
<Ankammarao> mattyw,thank you
<Mmike> marcoceppi, 1.25.8 is still not in the archives - sorry to bother you like this, but customers.... :/
<Mmike> (that is juju1.25.8)
<deanman> Hello, after managing integrating juju with a private OS Mitaka i've noticed that the security groups cannot be automatically harvested when destroying applications/models. Has anyone else exprienced that?
<jose> Mmike: Mmay be a good idea to ping over at #juju-dev, they should be able to help about that :)
<Mmike> jose, thnx, will do :)
<junaidali> Guys! I'm facing an issue where setting a config value isn't working. It appears that Juju has old config value cached somewhere and returning to charm
<junaidali> I'm using the latest juju 2.0.1
<admcleod_> junaidali: so if you type 'juju config application_name' what do you see, the new value or the old one?
<junaidali> admcleod_: yes, it shows the new value
<junaidali> The config be an IP in my charm and will raise a value error if an invalid IP is entered. I mistakenly set invalid IP while deploying.
<junaidali> I put a print statement in the code, which shows the config has old invalid IP causing a value error.
<admcleod_> junaidali: if 'juju config app' shows the new value, then i guess the way you are retriving the config value before printing may be the issue?
<ChrisHolcombe> bdx, is your vault charm published?
<ChrisHolcombe> i think i hit a reactive bug
<ChrisHolcombe> my fn is firing but the state is not setting for some reason
#juju 2016-11-26
<vibol> Hello, Why do Juju doc recommend to install Juju vai ppa. Can i install both juju and maas without ppa ?
<pmatulis> vibol, b/c the better juju is in the PPA
<pmatulis> which will soon be in the regular archives
<vibol> Is ppa perform good after a major upgrade example from lts to next lts ?
<pmatulis> vibol, what ubuntu version are you currently running?
<vibol> I'm running 14.04
<pmatulis> and when do you intend on upgrading to 16.04?
<vibol> I'm on a  testing purpose..
<vibol> And... i'm notice that. Upgrading a whole infrastrure is not a good idea
<pmatulis> vibol, then i would recommend using 16.04
<vibol> i trying to understand one by one about upgrading a major version with a work software juju, maas, landscape also openstack
<vibol> i'm just to come here for some recommendation
<pmatulis> recommendation is to use 16.04 from the start and avoid upgrading
<vibol> so what happen when the current version has reach EOL ?
<vibol> destroy the whole environment ?
<pmatulis> upgrade it, but why not start with the latest LTS to avoid an upgrade as long as possible?
<bdx> stokachu: ping
<twitch> Question watching an older video on juju, https://www.youtube.com/watch?v=9h5hgfnZcBQ  in the current state when a deploy is run against a local lxc provider is it deployed as a container or an instance?
<zeestrat> twitch: If by current state, you mean today, then the default local provider in Juju 2.0 is lxd (which is like lxc 2.0 just with some nicer wrapping) so deploying with that would get you lxd containers
<twitch> And on amazon prime?
<twitch> aws sorry
<zeestrat> On AWS you would spin up instances. Note, if you want, you can actually you can deploy lxd containers on those AWS instances as well.
<zeestrat> See https://jujucharms.com/docs/stable/clouds for some more info on the different clouds supported by Juju.
<twitch> awesome ty
<zeestrat> No worries. I recommend checking out https://jujucharms.com/docs/stable/getting-started which starts you out with the local lxd provider/cloud.
<zeestrat> The cool things is when you get the feel for how to deploy locally with juju, you can basically just switch to the AWS cloud in juju, bootstrap a new controller there, and deploy the exact same thing in the cloud.
<twitch> will the container tech always be focused on lxd containers or is work being done on other container software like docker?
<zeestrat> I'm not affiliated with juju so take it with a grain of salt, but I think the main focus for local providers/clouds is on lxd containers at the moment. However one of the flagship juju charms is for deploying Kubernetes (https://jujucharms.com/canonical-kubernetes/) and I know there are people who are using docker containers in juju charms.
<zeestrat> I suggest checking back in here next week and/or ask the mailing list (https://lists.ubuntu.com/mailman/listinfo/juju) if you have some more questions regarding docker and juju.
<zeestrat> I'm off so good luck!
#juju 2016-11-27
<stokachu> bdx: saw your ruby layer bug, ill look into it
#juju 2017-11-20
<uzair> How to remove charm installed completely including its container ?
<[Kid]> is there a way to use hostnames with juju and MAAS to deploy certain machine numbers to certain nodes by hostname?
<[Kid]> to hostname maas
<rick_h> [Kid]: no, you'd have to leverage tags probably.
<[Kid]> ahh okay
<[Kid]> i figured that might be the case
<[Kid]> i guess it wasn't really meant to get that specific
<[Kid]> how about defining specific subnets for pods in k8?
<[Kid]> right now i think it might just be arbitrary subnets
<bdx> [Kid]: yeah `juju deploy ubuntu --to <my-maas-machine-fqdn>`
<rick_h> bdx: oh can you target the fqdn
<[Kid]> bdx, but can you do that in the yaml?
<[Kid]> i knew about the single one offs
<[Kid]> i was thinking under the machine section in the yaml
<bdx> ahh my bad
<bdx> not sure in that case
<[Kid]> damn
<[Kid]> there isn't a ton of docs around the syntax and parameters for the yaml
<bdx> [Kid]: far better idea would be to tag the machines in maas and just use the tags constraints though
<bdx> even if you give the machine a tag that is its hostname
<[Kid]> ahh that is smart.
<[Kid]> thanks
<R_P_S> so the juju install of a kubernetes cluster creates an additional charm called kubeapi-load-balancer which is required to access the api of kubernetes.  but what about apps hosted inside kubernetes?
<R_P_S> do I need another load balancer (charm) to get through to the apps hosted inside kubernetes?  I went through a demo, but it used GCE for it's underlying k8s, and the last part was creating a service of type "loadbalancer"
<R_P_S> but this is perpetually pending and not providing an endpoint
<R_P_S> it should also be noted that all instances except the kubeapi-load-balancer are in AWS private subnets, but it's not even exposing anything on the private subnet ranges
<[Kid]> R_P_S, i am doing something similar. my understanding is you have to create pods on your cluster and then you expose those.
<[Kid]> you have to create a YAML that describes the service you want to expose, i.e. port mainly
<R_P_S> yeah, here's the yaml file from the demo that's supposed to create this endpoint
<R_P_S> https://raw.githubusercontent.com/omerio/kubernetes-graphviz/master/frontend-service.yaml
<R_P_S> but kubectl get service shows: frontend-service       LoadBalancer   10.152.183.159   <pending>     80:32379/TCP   9m
#juju 2017-11-21
<R_P_S> but I'm guessing it's not supposed to go through the kubeapi-load-balancer... which means I need something else that has a public IP (AWS ELB, proxy instance in public subnet, some other juju charm?)
<R_P_S> holy crap, EOD... I'll need to pick this up in the morning and I'll check logs when I get in :\
<[Kid]> yeah, i know what you mean
<bdx> R_P_S, [Kid]: using conjure-up, there is the 'deis' post install option I think
<bdx> that deis install should also bring with it a load-balancer for your apllication level ingress
<bdx> might be an easy option for you
<bdx> I know doing ingress correctly can be a battle
<bdx> and there are different way of doing it depending on what framework/workflow/architecture your targeting
<bdx> to tell you the truth I'm not sure how the deis deploy works outside of the aws provider
<admcleod_> if i have a charm which doesnt support say, artful, how can i force that deployment in a bundle?
<tingwei> Hi there! My juju is running on lxd, it hanged after fill up the lxd space. The lxd space was expanded which is zfs. But juju is still not responding. Is there any way to get it back?
<tingwei> *The lxd space was expanded using zfs at backend.
<tingwei> It works after rebooting the container.
<R_P_S>  bdx: I'm unsure how to invoke conjure-up now that all my infrastructure is already online.  it wants to create a new controller.  If I try specifying my controller + model, it complains that my "controller name" is not a spell
<bdx> ahh, yeah, so
<R_P_S> deis does not appear to be a spell either
<R_P_S> oh hey, while you're here... is deis and helm the same thing?
<bdx> R_P_S: deis is an "addon"
<bdx> no
<bdx> R_P_S: I took about 2 weeks and became very familiar with all of the tooling surrounding k8s
<bdx> when I was first diving in
<bdx> I highly suggest you do the same
<bdx> it will enable you to be proactive in your k8s dev instead of always wondering wtf
<bdx> you need to go down a few rabbit holes my friend
<R_P_S> as indicated earlier, I do not have that time... my manager has already asked me why it's taking so long :(
<bdx> oh man
<bdx> yeah
<bdx> well if your only interface to this thing is to get it standing, and not to understand it
<bdx> then you shouldn't need to concern your self with the tooling
<R_P_S> well, I have a kubernetes cluster online, but I did a demo app and it tried to create a load balancer which got stuck in pending forever
<bdx> I see
<bdx> follow the instructions here https://jujucharms.com/canonical-kubernetes/
<bdx> and deploy the microbot example
<bdx> then cut the cord
<bdx> thats your best bet
<bdx> unless you plan on learning some thing
<bdx> s
<R_P_S> the diagram at the top of the page is essentially what I have now
<bdx> and you boss will need to understand that its going to take you 1 month of k8s academia to start being able to understand how it works and deploy apps and what not
<bdx> exactly
<bdx> so just follow the instructions there
<bdx> had you not seen those yet?
<R_P_S> no, I'
<R_P_S> I've never seen anything related to squid config
<R_P_S> oh, the squid is for egress... don't think that's an issue at this time
<R_P_S> I can't get any ingress except for the kubeapi-load-balancer
<bdx> try ^ example
<bdx> if it doesn't work
<bdx> create a bug
<bdx> there is a link to "submit a bug" on ^ page
<bdx> ^ is more productive/proactive way of getting to the bottom of what ever you are having trouble with
<R_P_S> so I don't understand why I'm asked to select deis or helm in conjure-up.  I tried googling the difference, and the first link was
<R_P_S> https://deis.com/blog/2015/why-kubernetes-needs-helm/
<bdx> R_P_S: helm is used to install deis
<bdx> `helm repo add deis https://charts.deis.com/workflow`
<R_P_S> is helm is required for deis, why can I install deis without helm?
<bdx> `helm install deis/workflow --namespace deis`
<bdx> the conjure-up deis addon takes care of that for you
<bdx> so you can just get a platform bootstrapped with the deis workflow, and you can start deploying apps with a single command
<bdx> and you can just know how to use deis
<bdx> you don't need to understand how anything works underneath
<R_P_S> that is not clear at all in the conjure-up screen that asks between deis or helm :\
<stokachu> if you pick deis everything is setup for you including helm
<stokachu> if you pick helm then you just get helm
<bdx> well if you understand what deis is it would make sense
<R_P_S> that feels like chicken and egg lol
<stokachu> how so
<R_P_S> "here's an explanation of 2 tools in conjure-up, but if you don't understand the tools, this explanation will make no sense"
<R_P_S> so either you already know what they do and need no explanation, or you don't know what they do and the explanations might as well be written in another language
<bdx> well if I told you openstack would serve you better then a public cloud, it wouldn't make sense unless you understood what openstack was
<bdx> or a car over a bike
<bdx> you would have to know what a bike is
<bdx> to understand
<bdx> and a car
<bdx> correct me if I'm wrong here, but its not conjure-up, or juju's responsibility to provide education on 3rd party software
<bdx> conjure-up/juju, provide the thing
<bdx> its up to you to know how to use it
<R_P_S> this conversation is devolving :(  I do hope you understand I'm trying my best here
<stokachu> R_P_S: what more would you want in the screen listing the addons?
<stokachu> urls to their websites?
<R_P_S> this line here actually explains a ton: <stokachu> if you pick deis everything is setup for you including helm
<stokachu> not really as you stated you don't know what deis or helm actually is
<R_P_S> I am presented with 2 options.  Except you stated that option 1 includes option 2.  That alone makes decisions much easier going forward
<stokachu> hmm ok
<R_P_S> actually, I'm presented with 3 options... I can go with neither
<R_P_S> and when selecting deis or helm, it doesn't become clear why the options are limtied to aws afterwards, since googling "deis on azure" yields ocs from deis own website
<stokachu> avaialble clouds are enabled according to the spell, we just actually fixed it to show all clouds but give you a reason as to why some are enabled and not others
<stokachu> https://github.com/conjure-up/conjure-up/issues/1222
<R_P_S> that's a nice feature
<Navin> Hi guys
<Navin> I am fairly new to juju
<Navin> Hoping for some help from you guys
<Navin> I have been trying to bootstrap juju to openstack, that is hosted in one of the VM's I have spun up on a bare-metal
<Navin> But, this is following error I have been receiving:
<Navin> 11:36:59 ERROR juju.cmd.juju.commands bootstrap.go:496 failed to bootstrap model: cannot start bootstrap instance: cannot run instance: No valid host was found.
<Navin> Any inputs on this would be highly appreciated, thanks
<Navin> or if there's any other info required for troubleshooting, I would be more than happy to provide with the same..thanks so mcuh
<rick_h> Navin: try with --debug on the command and see if there's more details. It should show you what kind of instance it's looking for
<Navin> Thank rick for your reponse
<Navin> I did use the --debug command
<Navin> 11:36:41 DEBUG goose <autogenerated>:22 discovered API versions: [{Version:{major:2 minor:0} Links:[{Href:http://192.168.122.166:9696/v2.0/ Rel:self}] Status:CURRENT}] 11:36:41 DEBUG juju.provider.openstack provider.go:1022 using network id "5227f5c1-3857-4295-be56-2b1acb3af717" 11:36:46 INFO  juju.provider.openstack provider.go:1146 trying to build instance in availability zone "nova" 11:36:59 INFO  juju.provider.openstack provider.go:11
<Navin> 11:36:59 INFO  juju.provider.openstack provider.go:1126 Instance "bce33e58-51dd-4eef-aaf8-4a67298ce90e" in ERROR state with fault "No valid host was found. "
<Navin> I can see it's pointing to a specific instance "bce33e58-51dd-4eef-aaf8-4a67298ce90e" in ERROR state but I am not sure how to fix this
<Navin> Any advise on this Nick?
<R_P_S> the deis addon failed to install as part of conjure-up/canonical-kubernetes.  It looks like it created all the infrastructure (juju status shows everything operational)
<R_P_S> so there's a charm for kubeapi-load-balancer, which is meant to be a public facing instance for the masters (auto config etc)
<R_P_S> is there a juju charm for load-balancing the workers?  From what I can tell, I can either expose the workers by putting them in a public subnet, which is less than ideal, or by having a load balancer charm that is in a public subnet on it's own with a relationship to the workers
<bdx> cory_fu: http://paste.ubuntu.com/26014595/
<R_P_S> when searching nginx, I only came across one option - "nginx dh" which states it requires a whole pile of other charms including psql, "devicehive", zookeeper and kafka...
<bdx> is there something else that needs to change, other then using endpoint_from_name('endpoint-name')
<bdx> R_P_S: deploy vanilla k8s using conjure up with no private subnets
<bdx> and the load balancing ingress and deis work
<bdx> you *should* end up with an elb endpoint that will proxy to your workers
<cory_fu> bdx: No, that looks like my mistake.  Iâll take a quick look
<bdx> cory_fu: thank_u
<R_P_S> bdx: I tried a vanilla install of k8s with deis and it bailed at the deis addon part... Exception: Failure in step /home/R_P_S/.cache/conjure-up/canonical-kubernetes/addons/deis/steps/step-01_install-workflow
<R_P_S> so I've got full infrastructure running without deis
<bdx> I see
<bdx> R_P_S: to get that fixed, so it will work for you, please file a bug with conjure-up
<cory_fu> bdx: Oh, sorry.  There was one thing that has to change.  The flag pattern is now âendpoint.{endpoint_name}.fooâ to be consistent
<bdx> ahh, in my interface layers, gotcha
<bdx> thanks
<bdx> cory_fu: looking through the Endpoints class, I don't see self.relations or self.endpoints, do those come from RelationFactory ?
<bdx> cory_fu: might you be kind enough to point me in the direction of where that code lives?
<bdx> cory_fu: or possibly there is only self.endpoints now, because we are ditching the relation metaphor ?
<bdx> Endpoint* class^
<cory_fu> bdx: The terminology is that âendpointsâ are the named connection point which form either end of a relation, with the ârelationâ being the active connection.  So, the name is associated with the endpoint, and the Endpoint instance has a list of established relations
<bdx> aaha
<bdx> thanks for that
<cory_fu> bdx: The relations property is defined here: https://github.com/juju-solutions/charms.reactive/blob/feature/new-relations/charms/reactive/endpoints.py#L127
<bdx> excellent, thank you
<bdx> so self.relations is still a thing
<bdx> ok
<bdx> sweet, tracking
<cory_fu> I know itâs a terminology change, but Iâm hopeful that it is more precise and avoids some confusion, even though it is more to grok at first.
<cory_fu> I thought we had a write-up of the terminology somewhere, but Iâm having trouble finding it
<bdx> it totally does
<bdx> cory_fu: did context go away too?
<cory_fu> bdx: It did.  I thought I mentioned that to you the other day?
<cory_fu> Unfortunately, it doesnât work with old-style interfaces, so we canât really support it.
<bdx> http://paste.ubuntu.com/26014988/
<bdx> cory_fu: how do I access the api provided by the interface layer?
<bdx> I must have missed that part my bad
<cory_fu> bdx: Instead of âendpoint = context.endpoints.nameâ, you would use âendpoint = endpoint_from_name(ânameâ)"
<cory_fu> Then it should otherwise be the same
<bdx> so http://paste.ubuntu.com/26015030/
<bdx> would not work
<bdx> because I need to index into "endpoint = endpoint_from_name(ânameâ)" to pull out to relation data ?
<cory_fu> bdx: Sorry, Iâm actually on the road and lost connection
<R_P_S> cory_fu bsx left #juju
<cory_fu> Oh, shoot
<R_P_S> so I've got a default conjure-up k8s cluster running with helm, I went to install nginx-ingress with helm, and it's trying to create a load balancer indefinitely pending
#juju 2017-11-22
<R_P_S> hey, so I've got a cluster that I created a few days ago with juju, and now all juju commands are simply hanging.  I thought maybe I got auto logged out?  (using admin user).  But every juju command I've tried just hangs
<R_P_S> juju had created a k8s cluster, and kubectl appears to be working, but juju is completely non-responsive
<jamesbenson> how do you issue the post-processing steps?
<jamesbenson> for k8s conjure-up
<R_P_S> that is so weird... so juju was hanging for any commands including status for hours there... but it's suddenly come back.
<R_P_S> I'm not sure I like the juju command being randomly unavailable for hours on end.  Any idea how I would troubleshoot this?  the juju client literally just hung for hours with any command until I noticed it started working again
<rick_h> juju show in just over 15!!!!!!
<rick_h> https://www.youtube.com/watch?v=Kq1sgJs9miU for those that want to watch the stream
<rick_h> https://hangouts.google.com/hangouts/_/xgsuvuvuyrcpnk3hkqgz4u7opee for those that want to hop in and chat
<R_P_S> I'm trying to setup one of my coworkers on my conjure-up juju cluster.  ME: juju add-user <username>, juju grant superuser  HIM: juju register <stuff>, juju switch <controller>, juju add-ssh-key "$(cat ~/.local/share/juju/ssh/juju_id_rsa.pub)", juju ssh kubernetes-master/0   ERROR permissions denied (unauthorized access)
<bdx> R_P_S: `juju grant <username> admin|read|write <model-name>`
<bdx> `juju grant superuser` grants controller acls
<R_P_S> superuser doesn't have model access?
<bdx> R_P_S: superuser is a role
<R_P_S> if he's superuser, could he technically grant himself model acess?
<bdx> nah
<bdx> you would think
<bdx> superuser is just controller level
<bdx> admin|read|write are model level
<R_P_S> so if you create a new model, the admin user has to go in and grant admin access to the new model to each user already in the system?
<bdx> yeah
<bdx> because the users aren't added to the model
<bdx> they just exist at the controller level
<bdx> so you must explicitly grant them the access level you want them to have as the model owner or as a model admin
<R_P_S> ah, I just listed model users
<R_P_S> I was watching the auth.log, and my coworker wasn't even hitting it... so something definitely felt off.  In other news, I got to watch all the attack attempts because ssh was given 0.0.0.0/0 ingress ACLs >.>
<R_P_S> So I'm running through a quick demo with my coworker on what should be a vanilla conjure-up cluster
<R_P_S> https://kubernetes.io/docs/tasks/access-application-cluster/load-balance-access-application-cluster/
<R_P_S> and we get to step 4 - exposing the service... and the external-ip gets stuck at <pending>
<R_P_S> the tutorial talks about a "minikube" getting stuck at pending, but doesn't provide any reasoning as to why this happens
<R_P_S> so despite being "exposed" there's no actual external access since it's only available via IPs that are tied to the flannel networking layer
<bdx> R_P_S: is that subnet its deployed to configured to auto assign public ips?
<bdx> and also using the igw and correct routing table(s)?
<R_P_S> well, it's in ec2-classic... the vanilla install doesn't even stick it into a VPC
<bdx> so its deployed in a vpc, or in default ec2-classic?
<R_P_S> ec2-classic
<R_P_S> which is always assign public IP by default
<R_P_S> each of these instances do have public IPs, and juju status shows each instance with their actual public IP
<R_P_S> and as for ec2-classic... the concept of igw and routing tables are completely hidden.
<elmaciej> Hi! Just want to ask - do you have guys any bundle for openstack without ceph or I have to make it manually from charms
<R_P_S> What are the S3 buckets used for when you select helm in a conjure-up?  I just realized that the IAM credentials I provided was never given S3 access... but it never at any point stated there was a failure since the conjure-up succeeded.
<R_P_S> so of course the buckets don't exist... do I need to rebuild the entire cluster?  or can I just modify the IAM policy now and the system will pickup and get into the state it's expected?
<stokachu> R_P_S: https://docs.ubuntu.com/conjure-up/2.4.0/en/cni/k8s-and-aws
<R_P_S> stokachu: that page pretty much mirrors the link I was following: https://kubernetes.io/docs/tasks/access-application-cluster/load-balance-access-application-cluster/ except that it actually talks about what happens in AWS
<stokachu> Heh ok
<R_P_S> but no ELB was ever created.  My policies are "effect allow, action elasticloadbalancing:*, resource *" and "effect allow, action ec2:*, resource *"
<R_P_S> that's cool that it's supposed to make an ELB... but it's strange that no ELB was ever created :(
<stokachu> Well the docs state where to look for the error logs
<stokachu> So that's probably where I would start
<R_P_S> hrmm... I don't have any permissions for EBS... but I see the hint for checking logs on kubernetes master at the bottom of your page
<R_P_S> EBS should be contained within EC2:* though... I'll have to check that... but that shouldn't be blocking anything now anyways since I'm not doing anything with volumes yet
<R_P_S> yup create volume and attach volume are covered by ec2:*
<R_P_S> weird, not found anything in the logs... but in ~/.cache/conjure-up/canonical-kubernetes/steps/04_enable-cni/ec2, there's a pair of files call policy-master and policy-worker that specify a pile of access including ec2, elasticloadbalancing, route53, s3 etc
<R_P_S> hum... it looks like conjure-up needs to make aws roles?  It sure doens't have any permissions to do that...
#juju 2017-11-23
<BarDweller> I got round to putting my kube-in-a-box project on github, brings up Kubernetes with RBAC/Istio/Docker-Registry and port forwarding on a bridged network interface all inside a Vagrant VM =) Would not have been possible without the help from here =)
<BarDweller> https://github.com/BarDweller/Kube-in-a-box
<R_P_S> with conjure-up canonical-kubernetes how do I specify a VPC?
<R_P_S> https://docs.ubuntu.com/conjure-up/2.4.0/en/usage
<R_P_S> I tried doing the headless on that page to specify my own controller which I manually created in the VPC, but it would just error out with the strangest of errors
<R_P_S> 2017-11-23 19:36:44,469 [ERROR] conjure-up/canonical-kubernetes - juju.py:894 - Traceback (most recent call last):
<R_P_S> 2017-11-23 19:36:44,469 [ERROR] conjure-up/canonical-kubernetes - juju.py:894 - Traceback (most recent call last):
<R_P_S>   File "/snap/conjure-up/842/bin/juju-wait", line 7, in <module>
<R_P_S>     from juju_wait import wait_cmd
<R_P_S> ModuleNotFoundError: No module named 'juju_wait'
<bdx> R_P_S: https://github.com/conjure-up/conjure-up/issues could you create a bug here about that pls
<R_P_S> hum... for reference, I didn't end up writing the last bug.  Upgrading with snap --edge resolved the previous one... but this time I'm using edge for both juju and conjure-up
<R_P_S> a regular non-headless conjure-up is in progres... although strange it seems to have hung.  All the instances are listed as active with a green checkmark, but the conjure-up installer has stalled at creating a relation?
<bdx> R_P_S: cool ... yea, I would like to follow the progress on that ^^ though too
<bdx> the bug
<R_P_S> is there a way to just specify a VPC with conjure up though?  I thought I recalled something from days ago, but it's scrolled off chat history
<R_P_S> and the only reference I could find was that headless option, which doesn't look like what I recalled mentioned the other day.  But that might have been with respect to creating a controller in a VPC as opposed to an entire spell
<bdx> you can set a default vpc to use
<bdx> at the controller level I think
<bdx> not so sure though
<R_P_S> well, conjure-up makes controller and env, so I don't have any chance to change anything on the controller before the environment is spun up
<bdx> ahhh, I think conjure-up will let you choose an existing controller though
<stokachu> Please file a bug to get that added
<R_P_S> yeah, that's when I encountered that juju_wait error... the options for selecting a controller required also doing a headless install for some reason
<R_P_S> damn, this vanilla "conjure-up canonical-kubernetes" has definitely hung... but I need to kill it to repro the headless errors
<bdx> https://github.com/conjure-up/conjure-up/issues/1241
<R_P_S> that's cool... now I've not used github for submitting bugs, should I be adding a +1 comment to that FR?
<bdx> R_P_S: yes, you can click the "Watch" button to be notified of activity and progress on the issues
<bdx> and yes, add your 2 cents to things you care about
<bdx> to a reasonable degree ;)
<R_P_S> ok, I'm going through a complete repro of that juju_wait issue right now... rebuilding a new instance now
<R_P_S> never used sosreport before... it just said "no valid plugins were enabled" after giving out the version (3.4)
<R_P_S> is that expected?
<R_P_S> https://github.com/conjure-up/conjure-up/issues/1242
<R_P_S> the wording on this page is a bit confusing. in the section customizing deployment phases
<R_P_S> https://docs.ubuntu.com/conjure-up/2.4.0/en/usage
<R_P_S> it initially talks about "controller or model" but then when it actually refers to the parameters, it calls them "datacenter" and "deployment".  is datacenter=controller and model=deployment?  This was the base assumption I made when I tried to run with an existing controller
<stokachu> Yes
<stokachu> It's sudo sosreport
<R_P_S> but those docs seem to indicate that issue 1241 technically has a solution already (even if just headless), if I could just get past the bug I wrote up.  Where I can create my own controller, possibly even model (with basic VPC configs for services)
<R_P_S> that doesn't quite deal with spaces though, cause I'd still need some way to associate spaces with the apps defined inside the spell
<R_P_S> oh ffs lol sudo sosreport
<R_P_S> I've already downed the machine... is sosreport critical?  Or should I repro again?
<stokachu> Nah you got the logs attached
<R_P_S> I just reproduced that bug I wrote up with a vanilla $ conjure-up canonical-kubernetes  (options: deis selected, aws credentials are full admin in IAM, set masters to 3)
<bdx> R_P_S: from the looks of it, you found a legit bug
<R_P_S> "found" :P
<bdx> R_P_S: you should be excited that you helped make the software better for future use and for others by creating an issue and getting it fixed
<bdx> that can be your holiday gift
<bdx> :)
<R_P_S> hehe... I'm glad to help... I just have no reason to take credit for stumbling across such a basic use case
<bdx> its what you do about it that matters
<R_P_S> to be fair, if it wasn't for the support I've received on this channel for juju, I would have abandoned it long ago and tried another option since there are so many out there
<bdx> really? If you dont mind me asking, why so?
<bdx> and ... becareful what you say
<bdx> there is nothing like juju out there
<blahdeblah> bdx: "Please tell me honestly, but don't be totally honest"?
<bdx> haha
<bdx> nah
<R_P_S> from what I can tell, I've yet to actually get a fully operational cluster online.  working with my coworker yesterday, I took what I thought was a fully working cluster and found out it hadn't properly integrated with aws to create ELBs
<R_P_S> it's become so black box that when something goes wrong, you aren't even sure what has gone wrong exactly
<R_P_S> I've had multiple clusters complete setup without error, and yet when it comes time to do something inside kubernetes, something just didn't work
<bdx> ahh, so yeah, I would say that you may have jumped in the deep end a bit fast
<R_P_S> there's a very large gap between "quickstart" and "what I actually need"
<bdx> totally
<bdx> well deploying clouds and cloud software is no simple task
<R_P_S> and the fact that I have to technically abandon conjure-up itself to eventually make what I need (aka create my own controller, model, config model, create bundle and juju deploy)
<R_P_S> and then still not know if I'm missing something that conjure-up silently put in that I don't even know about
<bdx> right right
<bdx> totally
<bdx> R_P_S: I feel you on all of that
<R_P_S> right now, I'm fairly certain there are "steps" that need to be done post juju deploy bundle.yaml.  But I don't know exactly how their called.  I'm fairly certain one of those steps is AWS CNI.  I have a hunch that was the missing piece for why all the demos always got stuck at "create load balancer with indefinite pending"
<R_P_S> to be honest, I went with juju because it was made by ubuntu, which meant hopefully there was more than a couple guys working out of their basement.
<bdx> R_P_S: thats a good reason, but there are many others that mihght make you appreciate it more if you were wise to them
<bdx> but thats just the name of the game
<R_P_S> I see kubernetes.io -> install guide -> choose one of these 75 tools.  The fact alone that there's 75 tools tells me that not one of them really stands out enough to deprecate the others.
<bdx> this is super cutting edge stuff, and sometime you just gotta make it work
<bdx> which comes down to creating a bug and getting something fixed
<bdx> I know it seems like masssive roadblock when someone is giving you a timeline
<bdx> but to be fair, what you've been asked to do, with what little prerequisite knowledge you have is entirely unreasonable in the first place
<bdx> which leads us to juju
<R_P_S> well, this can start getting philosophical on the concept of MVP, Agile and and cutting edge.  Cutting edge always means "replaced before it ever reaches maturity", a self fulfilling prophecy
<bdx> that exists for ^ purpose kinda
<blahdeblah> haha - 75 tools; nice
<R_P_S> which is the reason so far that I haven't abadoned juju... cause the grass is just as... brown? over there as it is over here.  although maybe the grass over there was just seeded like over here
<R_P_S> blahdeblah: 75 is a bit of an exxageration.  but the table at the bottom of this "very-early" page is massive: https://kubernetes.io/docs/setup/pick-right-solution/
<R_P_S> and that doesn't even cover all the random solutions you'll find on github where some guy wrote it solo
<R_P_S> the truth is, is that kubernetes is extremely powerful, and I don't honestly trust any of these solutions to really "get it right"
<bdx> Its all about the operator
<bdx> the solution is just a tool
<R_P_S> please tell that to my manager
<bdx> email?
<R_P_S> prior to me joining this company, they didn't have any devops, and dev just pushed whatever they could get out.  is it up?  good, push it to prod.  oh, it fell over?  weird.
<bdx> I'll kindly write him a nice letter telling him how ignorant he is
<R_P_S> that will go over real well
<bdx> jp :p
<bdx> but really
<bdx> its my biggest pet-peeve when people of that nature make it into positions of power in the technology sector
<bdx> it hurts everyone
<R_P_S> well, overall he's a decent guy.  He's actually fairly good at treating people like humans
<bdx> they usually are
<R_P_S> but when it comes to the marketing, he just doesn't know, and has always had people around him who haven't questioned things hard enough
<bdx> yeah
<R_P_S> marketing: multicloud!  what it means.  most setups can be done in the cloud you're currently using.  what they think: fuck yeah, we can have a cluster that spans azure, aws, inhouse baremetal and godaddy
<bdx> if I was in your  situation, I would start scheduling weekly educational meetings on infrastructure lifecycle
<bdx> the only way is to educate them
<R_P_S> I've been doing that for most of the year now.  I've had full on training sessions about barebones infrastructure best practices, flows and pitfalls
<R_P_S> they still have no idea what good actually looks like though
<R_P_S> but at the end of the day, they've created a new feature, and it needs prod infrastructure yesterday cause sales is doing a demo 2 days ago to customers who have already paid for it
<R_P_S> even my direct manager understands that there needs to be an entire culture shift from top to bottom to give us time to work out some of these underlying issues
<bdx> yeah, your dead on there
<bdx> Im out for t-day
<R_P_S> roger, thanks
<bdx> Im sure your conjure-up issue will be solved fairly quick, looks like an easy fix
<bdx> then you can get your way
<R_P_S> as in, I should be able to refresh --edge soon?
<bdx> well, the bug you created will get status updated as the fix is released
<R_P_S> of course, I'll watch that
<bdx> I wouldnt expect anything before monday, but im sure sometime next week it will get sorted
<stokachu> Yes we move pretty fast .. but you know it's Thanksgiving and all
<R_P_S> heh, I sent a video to a cubemate today.  an espn announcer saying.  No Games in the NHL cause it's thanksgiving, or as we call it in canada, thursday
<R_P_S> it's from years ago, but still good for a chuckle
#juju 2017-11-24
<akshay__> Hi what are the consequences of directly doing juju remove-application <app-name>, instead of removing all the relations first and then removing application?
<evilnickveitch> akshay__, which version of Juju are you using?
<akshay__> evilnickveitch: it is 1.6
<evilnickveitch> akshay__, for 2.0+, there is no effective difference, the other side of the relation fires a relation-departed hook
<evilnickveitch> but for earlier versions I don't think that happens, so the related application will switch to an error state
<evilnickveitch> so, much better to remove the relations first, because you are going to have to clean up afterwards
<evilnickveitch> ^otherwise
<freyes> hi, is there a command to list permissions granted to a user?
<jose-phillips> hi
<jose-phillips> someone know how to upgrade openstack from newton to ocata?
<jose-phillips> on a conjure-up juju installation?
#juju 2019-11-18
<nammn_de> morning rick_h . Ping me if you are on and free for ho
<manadart> stickupkid: https://github.com/juju/juju/pull/10917
<nammn_de> 2 line fix https://github.com/juju/juju/pull/10918/files
<nammn_de> stickupkid_ changed the comment
<nammn_de> should be aligned different and should make more sense now
<stickupkid_> nammn_de, done
<nammn_de> stickupkid_: taaa
<rick_h> nammn_de:  ping
<rick_h> manadart:  ping, did you get a chance to poke at the spaces bug that came in overnight?
<manadart> rick_h: I am looking at it now.
<rick_h> manadart:  ok ty
<nammn_de> rick_h: ping back, are you free?
<rick_h> nammn_de:  now I am :)
<rick_h> nammn_de:  going to hop in daily early if you want
<nammn_de> kk following
<manadart> nammn_de: https://github.com/juju/juju/pull/10921
<nammn_de> rick_h you still wanted to give a +1 on this one https://github.com/juju/juju/pull/10907
<rick_h> nammn_de:  done ty
<nammn_de> rick_h: ta
<timClicks> can anyone point to the best explanation of relations, interfaces and endpoints that they've seen?
<pmatulis> timClicks, https://jaas.ai/docs/concepts-and-terms ?
<timClicks> it's not clear enoug
<timClicks> it's not clear enough
<skay> I have a charm with a package in its wheelhouse that is not found when the install hook is running. The package is setuptools-scm. I don't know why this is happening.
<pmatulis> timClicks, ok, but that's the best explanation i've seen ;)
<skay> and oh, it may be that mojo deployed an old version of the charm but I may be wrong
#juju 2019-11-19
<hpidcock> few test fixes for someone https://github.com/juju/juju/pull/10916 https://github.com/juju/juju/pull/10922 https://github.com/juju/juju/pull/10923
<babbageclunk> hpidcock: approved the two quick ones!
<babbageclunk> still looking at the pregen certs one
<hpidcock> babbageclunk: danke
<babbageclunk> hpidcock: also approved the certs one
<hpidcock> thankyou!
<sahid> is someone can confirm me that juju is not using any code related to nova-network for the openstack provider?
<sahid> i checked the code and i think we are OK, but just wanted double check with you since nova-network will be completly rmeoved for the next release of nova
<timClicks> sahid: thank you for checking
<timClicks> sahid: if you are able, could you please ask on the discourse forum?
<timClicks> sahid: that way team members who are currently offline will have a chance to check
<sahid> timClicks: sure I will do that
<stickupkid> manadart, you got time for a CR https://github.com/juju/juju/pull/10881
<manadart> stickupkid: Yep.
<manadart> stickupkid: Done.
<stickupkid> manadart, need to fix the tests fyi
<manadart> Need a tick on a forward-merge: https://github.com/juju/juju/pull/10925
<stickupkid> manadart, tick
<manadart> stickupkid: Ta.
<rick_h> morning party folks
<icey>  /join #maas
<skay> I think juju deploy is installing a different version of the charm than the one in the local build directory. The version file and codetree-collect-info.yaml in the local charms dir have a different hash.
<skay> what could be causing that?
<rick_h> skay: reactive charm that needs to be deployed from the build dir?
<rick_h> or some missing path expectation?
<skay> rick_h: reactive charm that needs to be deployed from the build dir
<skay> the normal workflow uses mojo. the path to the charms dir is setup by mojo and the charms are collected there via a collect file in my spec.
<skay> while trying to figure this out I've also done it by factoring mojo out of the equation
<rick_h> nammn_de:  so those are the old canonistack region urls
<rick_h> nammn_de:  I've forwarded you the email on the new region, I'd suggest we update to use that
<rick_h> nammn_de:  let me know if that'll work or not
<nammn_de> cool, can do that
<nammn_de> rick_h: should they work, if I try them locally over vpn?
<rick_h> nammn_de:  but yea, I think we just had test data that's on old cloud endpoints and we have to update for the changes
<rick_h> nammn_de:  yep, over vpn should be good
<nammn_de> rick_h: because of the yaml  jenkins/I couldnt reach any of those endpoints afaict
<rick_h> nammn_de:  yea, I think they're shut down
<rick_h> nammn_de:  or moved
<rick_h> nammn_de:  so have to update to the current ones
<nammn_de> rick_h: cool will update
<rick_h> achilleasa:  if we can, anywhere we have some sort of interval we should be doing backoff if it might cause any sort of issue
<rick_h> achilleasa:  just one of those lessons where debugging something bouncing and without the backoff it makes it hard to recover
<nammn_de> rick_h: and for manual-xenial-amd64, finfolk-vmaas and vsphere?  They don't seem to work either
<rick_h> nammn_de:  sounds like achilleasa sent you notes on vsphere, is that IP still correct?
<rick_h> nammn_de:  and for the vmaas I'm not sure about. Have to check our infra, probably listed in cloud-city details somewhere.
<nammn_de> rick_h: yeah should be, I can use those as long as jenkins has intenrally the creds for them
<rick_h> nammn_de: in the end this is just to test you can add multiple clouds right?
<nammn_de> rick_h: yeah, I can just steal some from clouds.yaml or just remove some
<rick_h> nammn_de:  so I like the canonistack as it has a couple of regions as well, but honestly we just need to verify a few clouds. Find a few that work and run with it.
<rick_h> nammn_de:  exactly, I don't think we have to over do it
<rick_h> nammn_de:  this was just easy for the original test. let's keep it easy as long as the test validation is still legit
<rick_h> skay:  how did you take mojo out of the question?
<nammn_de> Just wanted to make sure that we align here and that. Yeah Didnt plan to add additional complexity. Will do
<skay> rick_h:  I'll do this all again momentarily to make sure I remember it right. I didn't take as good of notes as I should have yesterday. but, from memory...
<skay> rick_h: locally to run things without mojo I have env variables set up for my charm repo. I build the charm from my clone. I have a bundle file that specifies the charm in the build directory and run `juju deploy` on that bundle
<skay> re mojo, I took different steps yesterday to make sure it wasn't somehow pulling from an old checkout. in the /path/to/mojo/workspace I removed spec/, build/, charms/.
<skay> rick_h: do you have more troubleshooting tips to try?
<achilleasa> rick_h: in that particular PR implementing a backoff inside the watcher will not be easy and I think might cause more problems than it actually solves (I have proposed a way to do it if we really really want to in the PR comments)
<rick_h> achilleasa:  ok, it's something I'd really like jam's signoff on in that case
<rick_h> achilleasa:  thanks for the notes
<rick_h> skay:  version of Juju?
<skay> rick_h: 2.6.10-trusty-amd64
<achilleasa> rick_h: yeap, not in a hurry to merge that one (still have to fix the agent test I was talking about)
<rick_h> achilleasa:  +1
<rick_h> skay:  hmmm, we started with the effort to have the charm build process add a version file to note git/vcs info in a version file in the charm
<rick_h> skay:  might check if that's there and match the sha up
<rick_h> skay:  but not sure, lots of moving parts in this situation
<skay> rick_h: yeah, see above. they don't match.
<skay> rick_h: nor do hashes in the codetree yaml file
<pmatulis> can actions be run from within a charm's config file that is used during deploy?
<rick_h> pmatulis:  no, charms don't have creds to call actions themselves
<rick_h> pmatulis:  they're operator triggered
<pmatulis> rick_h, thank you sir
<rick_h> pmatulis:  if the charm wants to share some code they can manage that internally and wire it up into the install hook and such
<rick_h> pmatulis:  but that's just code at that point vs actions/not actions
<stickupkid> hml, CR https://github.com/juju/juju/pull/10926
<hml> stickupkid: any rush on this?
<stickupkid> hml, so this fixes the controller test in 2.7
<stickupkid> hml, no rush
<stickupkid> hml, helps if i base it on the correct branch :|
<hml> stickupkid: trade ya:  https://github.com/juju/juju/pull/10927. gave up on unit test, integration test proves fix
<stickupkid> hml, deal
<stickupkid> hml, should target 2.7 right though?
<hml> stickupkid: yes.  oops
<hml> stickupkid: fixed
<stickupkid> hml, done
<timClicks> is it possible to use juju scp as the root user? I'm encountering a permissions (?) issue
<timClicks> ERROR exit status 1 (Please login as the user "NONE" rather than the user "root".)
<rick_h> timClicks:  no, the ssh key is only on the ubuntu user
<rick_h> timClicks:  you'd have to scp it there and then juju run to mv it
<timClicks> rick_h: okay, good to know
<rick_h> timClicks:  what are you copying? worth it just to juju scp it to /tmp and then root has access?
<timClicks> i'm writing a relations tutorial and want to scp before/after versions of config files that have changed
<timClicks> i'll just do the work via juju run, rather than locally client-side
<rick_h> timClicks:  ah yea, might just juju run --wait -- cat ....
<timClicks> fwiw we've just had a request for ipv6 support in the #cdk slack channel
<timClicks> part 1 of a new tutorial series on relations is up https://discourse.jujucharms.com/t/what-is-a-juju-relation-and-what-purpose-do-they-serve/2347
#juju 2019-11-20
<rick_h> timClicks:  yea, ipv6 comes from time to time but never becomes critical enough to get it scheduled unfortunately
<wallyworld> kelvinliu: don't forget to remove these comments fromt the toml file! eg # source = "github.com/ycliuhw/charmrepo"
<kelvinliu> wallyworld: sure, I will  need to update the depfile after charm.v6 PR landed.
<kelvinliu> wallyworld: so ru happy for me to land it now?
<wallyworld> i can take one quick look again
<wallyworld> needa break from these online modules
<kelvinliu> k thx
<kelvinliu> the charm-tool repo needs to be merged manually
<wallyworld> kelvinliu: juju/charm and juju/juju look fine
<wallyworld> what's the charm-tool repo?
<wallyworld> url?
<kelvinliu> wallyworld: https://github.com/juju/charm-tools/pull/555
<wallyworld> kelvinliu: ty, merge done
<kelvinliu> thx
<wallyworld> kelvinliu: once your stuff lands, here's a charm-helpers one https://github.com/juju/charm-helpers/pull/394
<wallyworld> no hurry and not critical for rc5
<wallyworld> *as
<kelvinliu> ok
<wallyworld> looks like i got  a travis issue to fix
<wallyworld> after coffee
<wallyworld> kelvinliu: i updated the tests to patch the cmd_exists function. if you're happy, can you Approve?
<kelvinliu> wallyworld: done, thx!
<hpidcock> wallyworld: https://github.com/juju/juju/pull/10928
<hpidcock> you're running eoan right?
<wallyworld> hpidcock: o am
<wallyworld> *I
<wallyworld> hpidcock: seems we use 0.1.2.3 in a few places
<hpidcock> Yeah this seems to be the only test I found affected
<hpidcock> but maybe there are more Â¯\_(ã)_/Â¯ I'll run tests again locally
<wallyworld> would benice to change them all to be consistent
<wallyworld> jujud agent tests now pass
<hpidcock> ok yep, I'll make the change and run all the tests
<wallyworld> with the change
<hpidcock> :D
<hpidcock> ehh wallyworld there are way too many references to 0.1.2.* addresses and not everything can be changed to 127.0.0.2+n addresses, since they are used in spaces stuff. It's probably safer to just move things one by one.
<wallyworld> ok
<wallyworld> are there any others that can be done easily?
<wallyworld> ie to fix a test failure
<hpidcock> no other tests fail
<gnuoy> stickupkid, fwiw I tried to reproduce issue 366 on a cut down deploy but failed. So, I've added more details on reproducing it to the issue report.
<stickupkid> gnuoy, I've got a potential fix
<gnuoy> stickupkid, oh, that  was quick. I shall keep everything crossed! I have a test environment I can try things out with if thats any help.
<stickupkid> gnuoy, https://github.com/juju/python-libjuju/pull/367 - I'm going to double check against your repro steps this afternoon
<rick_h> morning folks
<gnuoy> stickupkid, thanks, I can test it too. I don't really understand why the remote application is missing or are you suggesting that the missing remote application is a transitive state ? fwiw the deploy I used to reproduce the issue it still exhibiting it.
<stickupkid> gnuoy, i can replicate with your setup
<stickupkid> gnuoy, i'll keep looking
<gnuoy> kk, thanks stickupkid
<stickupkid> gnuoy, what version of pylibjuju are you using?
<gnuoy> stickupkid, I pip installed it without any bounds.
<gnuoy> $ pip freeze | grep juju
<gnuoy> juju==2.6.3
<stickupkid> gnuoy, can you try my PR, I think it should work
<gnuoy> stickupkid, that seems to fix my issue, thanks.
<stickupkid> gnuoy, amazing, ty
<gnuoy> stickupkid, do you think the travis failures against your PR are unrelated to the change >
<gnuoy> ?
<stickupkid> gnuoy, travis is unreliable for pylibjuju, jenkins gives the best review analysis
<gnuoy> kk
#juju 2019-11-21
<gnuoy> stickupkid, do you think it's likely that your pr will land this week ?
<stickupkid> gnuoy, probably next week
<gnuoy> ack, ok, thanks
<stickupkid> gnuoy, I'm away tomorrow, hence why it probably won't be
<int_0x21> Hi im giving juju openstack a fresh go, i wonder is there a est practise on how to configure the network on the nodes in maas ? bond/bridge vlan settings and so on ?
<rick_h> int_0x21:  they've got pretty good docs around that. pmatulis might know the best url to point you to regarding "suggested setup" but if you've got specific questions maybe hit up #openstack-charms or #openstack?
<int_0x21> rick_h, ah thank you :)
<int_0x21> Will check in the charm one
<nammn_de> stickupkid: are  juju/description a kind of serialization format of the state package?
<stickupkid> nammn_de, yes and no, it's not a 1-1 mapping, it should be an abstraction of the state package.
<nammn_de> So actually our state package should kind of implement /build on them in an ideal case ?
<stickupkid> what do you mean /build?
<nammn_de> stickupkid: depending on the pov a kind of "implement"
<hml> stickupkid:  2 min doesnât work either for the controller test.  maybe we need a different approach?
<stickupkid> hml, it would seem so
<stickupkid> hml, well doesn't this suggest that it may never get set, is there something juju isn't correctly doing / modelling
<hml> stickupkid: if that is the case, why does the test succeed locally?
<stickupkid> hml, i bet the machine isn't running!
<stickupkid> hml, i.e. we don't wait for the machine 0 to be running in this test, perhaps we should
<hml> stickupkid: could be
<gnuoy> stickupkid, I think I understand what is going. A minor tweak to your original patch makes sense to me: https://paste.ubuntu.com/p/NkrkvxpX9s/
<stickupkid> gnuoy, I believe the right thing to do is, is to consume all the deltas.
<stickupkid> gnuoy, i've started working on this
<gnuoy> stickupkid, hmm, ok, I assumed that the model cannot no information about a remote model. If that is correct then libjuju cannot get information about an application in a different model.
<gnuoy> s/cannot no/cannot know/
<gnuoy> fwiw I think the issue only occurs on the side making the offers
<stickupkid> rick_h, this is ready for a CR https://github.com/juju/python-libjuju/pull/367
<stickupkid> rick_h, turns out this was the cause https://github.com/juju/python-libjuju/pull/367/files#diff-934c79f928f581e5f1d8903f275de68fR900-R905
<stickupkid> logging the error as "debug" was about as helpful as a chocolate fire guard
<rick_h> stickupkid:  looking
<rick_h> stickupkid:  lol on your fire guard
<stickupkid> rick_h, i'd like your feedback if we should actually raise the log to an error
<rick_h> stickupkid:  k, processing
 * rick_h gets brain out of corporate training mode
<rick_h> stickupkid:  still have time to chat?
<stickupkid> rick_h, issue I have with that, is that we could end up with a LOT of bugs
 * rick_h doesn't want to hold you
<stickupkid> yeah quickly
<timClicks> are there any docs available for how to listen to the events streamed by the allwatcher?
<timClicks> i'm interested to know how the juju gui works
<rick_h> https://github.com/juju/js-libjuju/blob/master/examples/watch-all-models.js
<rick_h> \https://github.com/juju/js-libjuju/blob/master/examples/watch.js
<timClicks> rick_h: cool, ty
#juju 2019-11-22
<wallyworld> hpidcock: here's that huge PR for rc6 https://github.com/juju/juju/pull/10937
<hpidcock> on it
<hpidcock> uh
<hpidcock> this is too big
<wallyworld> ty
<hpidcock> np
<parlos> Good Morning Juju!
<rick_h> morning Juju party people
<parlos__> Good Afternoon rick_h
<achilleasa> manadart: what do you make of this? https://github.com/juju/juju/blob/develop/provider/maas/maas2_environ_whitebox_test.go#L926-L939
<achilleasa> rick_h: ^^^ is this example realistic?
<parlos__> If a 'bug' is discovered in a charm, where should that be reported?
<rick_h> achilleasa:  thinking, trying to make sense of it. it is that the device has multiple nics, and the children are possibly bridged addresses or something?
<rick_h> parlos__:  charm show cs:xxxx bugs-url is the best start
<rick_h> parlos__:  or look for the bugs url link on the jaas.ai/xxxxx page
<manadart> achilleasa: I am up against the limits of my networking knowledge, but I can't see how this can happen. Particularly as the VLAN is on the interface = same for all links...
<parlos__> rick_h thanks.
<achilleasa> rick_h: manadart I have no idea; strong my maas-fu is not :D
<achilleasa> according to the implementation the last address wins there
<manadart> achilleasa: You can have multiple subnets on a VLAN, but everything I am reading discourages it.
<parlos__> Have a nice day!
<manadart> achilleasa: And Netplan appears not to support virtual interfaces: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1743200
<mup> Bug #1743200: No support for interface labels <netplan:New> <nplan (Ubuntu):Triaged> <https://launchpad.net/bugs/1743200>
<achilleasa> manadart: can you take a look at https://github.com/juju/juju/pull/10942?
<manadart> achilleasa: Yep.
<nammn_de> manadart: can you take a quick/first look into that to see whether I am going in the right direction? https://github.com/juju/juju/pull/10943/files Next step would be to add those to the import step as well
<manadart> nammn_de: Looking.
<nammn_de> while at it, I would put the export step into another PR after this one got through
<nammn_de> the corresponding description PR https://github.com/juju/description/pull/66
<nammn_de> manadart: thanks! I incorporated your review. description and juju/juju should be ready to be reviewed for real
