#juju 2012-05-07
<SpamapS> anybody up late charming? :)
<ejat> :)
<ejat> SpamapS: any plan ?
<marcoceppi> SpamapS: You know it
<marcoceppi> SpamapS: since you're up
<marcoceppi> I've got questions
<marcoceppi> relation-set, it works from any hook now right?
<ejat> marcoceppi: u at ya room ?
<marcoceppi> ejat: no, I'm downstairs
<ejat> with ?
<ejat> at lobby ?
<SpamapS> marcoceppi: yes
<SpamapS> marcoceppi: you just have to give it a relation id with -r
<SpamapS> marcoceppi: this allows full orchestration now :)
<SpamapS> service A changes something, B sees change, reacts by informing C
<SpamapS> marcoceppi: working on anything juicy?
<_mup_> Bug #995823 was filed: Machines occasionally fail to start the machine agent correctly because of an unhandled ConnectionTimeoutException <juju:New> < https://launchpad.net/bugs/995823 >
 * SpamapS rings the bell
<SpamapS> new charm promulgated, mumble-server!
<SpamapS> well done Kees Cook. :)
<Leseb> hi everyone!
<benji> hi Leseb
<Leseb> benji: I'm running MAAS + Juju and I have some questions, do u have time to help me a little? pleas
<Leseb> +e
<benji> Leseb: I will give it a shot, but I don't know anything about MAAS yet.
<Leseb> ok, first I just want to be sure about the meaning of "juju bootstrap"
<Leseb> It mean setting up a new environment right?
<Leseb> does it also mean launching instance?
<benji> Leseb: when running in EC2 "juju bootstrap" will start one instance which is used for administrative purposes
<benji> then deploying charms will launch more instances
<benji> (there are plans to make the control instance shared with other instances so as to reduce the instance count, but that's not ready yet)
<Leseb> ok, what do you mean by "for administrative purpose"? the node doesn't run service?
<benji> Leseb: exactly
<Leseb> ok, thank you that really helpful :)
<Leseb> *was
<benji> my pleasure
<Leseb> benji: so this same command also copy the public ssh keys?
<Leseb> in the new created instance?
<benji> Leseb: I /think/ temporary ssh keys are generated for instances, you can use the "juju ssh" command to ssh into an instance.
<benji> once in you could add your real ssh keys if you so desired
<marcoceppi> SpamapS: with -r for relation-set, can i just give it the interface or relation, instead of a unit? like `relation-set -r db foo=bar`
<SpamapS> marcoceppi: no, you need a relation id (as given as $JUJU_RELATION_ID in the joined/changed/departed/broken hooks). Thats basically the bucket of information that you want to update. -r db wouldn't have enough context because there might be more than one db relationship
<SpamapS> in fact I think relation-id is the wrong term
<SpamapS> relations are the things you define, relationships are the things you establish
<marcoceppi> SpamapS: so relationship-id is a better descriptor?
<SpamapS> marcoceppi: yeah
<SpamapS> but thats something we'll have to work out long-term
<SpamapS> relation-ids is already part of the vernacular
<marcoceppi> sure, np
<marcoceppi> SpamapS: I just threw this up too, not sure if it's a good idea for charm-helper-sh
<marcoceppi> https://code.launchpad.net/~marcoceppi/charm-tools/unit-parsing/+merge/104929
<SpamapS> marcoceppi: +1 , thats nice actually.
<SpamapS> marcoceppi: I had some good success moving juju-jitsu to autotools so we can address the path issues btw.
<marcoceppi> SpamapS: just wanted to make sure the movement from peer.sh and copyright were okay
<marcoceppi> excellent!
<SpamapS> marcoceppi: we'll move to autotools and then we can have @scriptdir@ in code and just let 'make install' work that stuff out.
<marcoceppi> awesome, I felt dirty hard coding paths ;)
<SpamapS> marcoceppi: that does make it hard to test.. the hardcoded path..
<SpamapS> marcoceppi: perhaps do . "${CHARMTOOLS_PATH:-/usr/share/charm-tools}/scripts" ?
<SpamapS> marcoceppi: just so we can override it
<marcoceppi> I was starting to do this weird bash hack to figure out working directory, and decided it would be just best to push the hard code for now
<marcoceppi> yeah, I'll go ahead and update that
<marcoceppi> SpamapS: . "${CHARM_HELPER_SH_PATH:-/usr/share/charm-helper/sh}/unit.sh"
<SpamapS> marcoceppi: yeah that should work. Please make sure there is at least a test that it parses.
<SpamapS> marcoceppi: as long as we're touching it.. moar tests!
<marcoceppi> test that parses it?
<marcoceppi> You mean create a unit test?
<marcoceppi> I can do that prior to the merge
<SpamapS> Yeah look at the other tests
<marcoceppi> seems easy enough
<marcoceppi> I'll add that now and push it up
<SpamapS> like seriously as long as it does '. ...'
<SpamapS> so we don't ship a package that has unparsable shell code :p
<marcoceppi> SpamapS: I noticed that unit tests use $HELPERS_HOME, would that be a better env variable than $CHARM_HELPER_SH_PATH ?
<marcoceppi> inside peer.sh
<SpamapS> marcoceppi: yeah that makes sense
<marcoceppi> awesome, just about done
<SpamapS> marcoceppi: peer.sh is not always the best thing to copy though :)
<SpamapS> marcoceppi: its a bit ambitious :)
<marcoceppi> aye it is, I just want to parse unit names/numbers quickly
<SpamapS> exactly, that stuff belongs in its own tight lib
<marcoceppi> hence unit.sh :)
<marcoceppi> SpamapS: something odd is happening with the unit test, it's only running the first test and not carrying on
<marcoceppi> dis regard
<SpamapS> done
<marcoceppi> Unit tests are good indeed
<SpamapS> always nice to know it works :)
<marcoceppi> Okay, unit test is up, passing, and pushed if you want to take a final look
 * SpamapS pulls and plays
<SpamapS> FYI, there is a juju related session starting at UDS in Room 201
<SpamapS> http://summit.ubuntu.com/uds-q/meeting/20509/servercloud-q-juju-resource-map/
<SpamapS> http://icecast.ubuntu.com:8000/room-201.ogg
<ahasenack> I have two environments in my .juju/environments.yaml file, how do I tell juju which one to use without changing "default" in that file all the time?
<ahasenack> hm, -e
<SpamapS> ahasenack: also $JUJU_ENV
<SpamapS> ahasenack: another useful one, $JUJU_REPOSITORY
<marcoceppi> SpamapS: is there a way to lower the verbosity of the juju command?
<marcoceppi> IE mute the WARNINGS
<marcoceppi> wall of warning during a deploy demo is always awkward to explain
<marcoceppi> "PAY NO ATTENTION TO THE MAN BEHIND THIS CURTAIN"
<SpamapS> juju -l ERROR
<SpamapS> marcoceppi: what are the warnings? Bad charms in your repo?
<SpamapS> I think we should drop that to INFO actually
<SpamapS> having a half-written charm in a repo is a normal, but notable event
<SpamapS> not a warning IMO
<marcoceppi> SpamapS: http://paste.ubuntu.com/974479/
<SpamapS> marcoceppi: add 'ssl-hostname-verification: true' to your environment.
<SpamapS> marcoceppi: that *is* a legitimate warning. :)
<marcoceppi> I know, i know :)
<SpamapS> marcoceppi: we made it a warning, instead of a fail, so you'd have time to make sure all your SSL endpoints verify :)
<SpamapS> The 'honolulu' release will make it true by default
<koolhead17> SpamapS, sir when can we see you at UDS :)
<SpamapS> koolhead17: I arrive in the morning
<koolhead17> cool. :)
<SpamapS> marcoceppi is about to present charms at UDS http://video.ubuntu.com/live
<Tribaal> Hi all
<SpamapS> why does everybody want to deploy multiple things to one box.. one box in the cloud == fail
<james_w> SpamapS, it's more reliable than multiple boxes :-)
<SpamapS> james_w: if by more reliable you mean "fails more reliably", then yes. :)
<james_w> lower system failure rate
<lifeless> SpamapS: multiple systems multiple their failure rates
<lifeless> SpamapS: not everything is single node failure resilient
<lifeless> SpamapS: secondly, many things need to exist on the same box to cooperate sanely (e.g. take advantage of local IO, or process local logs) - and making them all tightly bound to another charm doesn't make sense in folks heads.
<lifeless> SpamapS: a good question to ask is why folk don't *want* to do it the way the Juju design thinks is best
<SpamapS> lifeless: thats exactly what I'm asking. Why are people rejecting the model that juju is selling. I think its the same reason people default to single threaded code... multiple threads, multiple servers, is hard.
<james_w> IME it's cost that drives it initially. For a trivial app paying for three machines is far more than is needed to handle the request load
<lifeless> SpamapS: thinking of 'threads are for developers that don't understand state machines' ?
<lifeless> SpamapS: FWIW I don't think its because there are a wide range of things where coexisting is much easier to reason about (and pay for)
<lifeless> SpamapS: where reasoning about includes dealing with network failure modes, avoiding NFS or similar tools
<SpamapS> lifeless: could it just be force of habit?
<lifeless> SpamapS: I don't think so
<lifeless> SpamapS: I've had what, 2 years of Juju exposure, and its still my second most desired feature
<lifeless> SpamapS: (the #1 being security)
<SpamapS> lifeless: can you explain a deployment that you want to do where m1.small is too big?
<SpamapS> or is that the real problem, I think its resource based, but its deeper than that?
<lifeless> SpamapS: size isn't the issue for me - james_w brought up size.
<lifeless> I acked that paying for things does appear
<lifeless> but you could use micro I presume for really really tiny things
<SpamapS> Ok, so its a fail rate thing. Hm.
<lifeless> fail rate + fail mode
<lifeless> if you have a log tailer
<lifeless> for instance, trivial thing
<lifeless> do you want to do that from a different box ?
<lifeless> even a different 'virtual box' using LXC ?
<SpamapS> well a log tailer is a subordinate
<SpamapS> which goes inside the same container
<SpamapS> (which in most cases means inside the same bare VM/machine)
<SpamapS> lifeless: subordinates solves the case for anything that you always want deployed at a 1:1 ratio together
<lifeless> consider oops-tools UI then
<lifeless> let me tell you about oops-tools
<lifeless> it has:
<lifeless>  - a blob store, which is just a directory on disk where oops files are stored. They get there via an AMQP consumer
<lifeless>  - a postgresql DB, which indexes the blob store, it is populated by the same AMQP consumer
<lifeless>  - an AMQP consumer, which receives OOPSes in near-realtime, writes them to the blob store and postgresql
<lifeless>  - a gc process which removes things from both the postgresql DB and the blob store
<lifeless>  - a wsgi web UI that shows things from the blob store + postgresql
<lifeless>  - some helper scripts that run out of cron to do reports and the lie
<lifeless> like
<SpamapS> alright
<SpamapS> all sounds good
<lifeless> now, thats /nearly/ full distributed
<lifeless> if the blob store were e.g. s3
<lifeless> but to use juju today, why would I reach for 3 machines vs 1 ?
<SpamapS> You would not. And in that case, thats all 1:1
<lifeless> perhaps I don't understand subordinates then
<lifeless> I wouldn't want every postgresql server to have apache+rabbit+oops-tools-ui etc
<SpamapS> right, you just want one, the one that does oops , right?
<SpamapS> assuming we convert oops-tools to a subordinate..
<SpamapS> juju deploy pgsql
<SpamapS> juju deploy oops-tools
<lifeless> for this part of the picture yes, but then I also want postgresql for LP :P
<SpamapS> juju add-relation oops-tools pgsql
<SpamapS> that puts oops-tools on the pgsql service
<SpamapS> lifeless: so you want to make *one* server special?
<lifeless> SpamapS: I'm not trying to move the goalposts, honestly.
<SpamapS> well is the pgsql service one server, or +1 ?
<lifeless> one for oops-tools, slony cluster for LP
<SpamapS> It sounds like you have an over-powered pgsql server and want to take advantage of that...
<lifeless> probably a slony cluster for other ancilliary components of LP once some refactorings get done.
<SpamapS> are the pgsql servers for oops and lp the same though?
<lifeless> nope
<lifeless> different
<SpamapS> Ok then yeah, subs solves this nicely *IF* you always want oops-tools to be on the pgsql instance.
<SpamapS> thats where I don't like the rigidity of oops-tools
<lifeless> don't want to impact production LP behaviour with data-analytics from oops-tools
<SpamapS> err
<SpamapS> rigidity of usbordinates
<lifeless> essentially, LP is headed towards a pattern where each cooperating service is a bundle of (pg, amqp-publishers, amqp-consumers, one or more wsgi apps)
<lifeless> and LP as a whole is a group of sunch bundles
<lifeless> some bundles will be HA (via slony, haproxy etc), others (like oops-tools) will be best-effort (and the rest of the system handles their absence in some fashion)
<lifeless> e.g. gpg key verification - if down, ppa uploads get queued, alerts go off, we bring it back up, but it doesn't have to be up 100% of the time
<lifeless> (and bringing it up should be self healable, in fact)
<SpamapS> lifeless: we have this problem w/ nova too. Nova can work w/ its own local sqlite, or a remote mysql server.
<SpamapS> lifeless: for devs, the local sqlite is the simple case for smoke testing.. but no sane deployment uses it.
<lifeless> SpamapS: sure, for clarity though, I'm talking the prod layout; local dev uses test fixtures to bring up transient services
<lifeless> like, we want separate pg clusters, to mitigate failures
<lifeless> thats a place where we *do* want multiple machines
<lifeless> its very unclear to me atm how you run 5 or 6 different slony clusters in one juju environment
<SpamapS> lifeless: juju deploy slony slony-1 ; juju deploy slony slony-2   ??
<lifeless> the way I'm thinking about juju use today, each environment will be extremely narrowly targeted, and we'll export its public surface and manually inject it into other environments.
<SpamapS> lifeless: you can even do this on ec2   juju deploy slony slony-a --constraints ec2-zone=a ; juju deploy slony slony-b --constraints ec2-zone=b
<lifeless> https://juju.ubuntu.com/docs/user-tutorial.html#deploying-service-units
<lifeless> probably wants to mention that optional parameter then ;)
<SpamapS> Yeah its a common problem
<SpamapS> lifeless: I'm fixing that particular page to be more clear now. Really good suggestion.
<lifeless> would that address the subordinates thing?
<lifeless> if you do deploy pgsql oops-pg
<SpamapS> yes!
<lifeless> or would oops-tools still land on all pg server s?
<SpamapS> no it would only be on oops-pg
<SpamapS> the only bummer about that is that you now always have to deploy oops as a sub
<lifeless> presumably because deploy oops-tool does nothing, and add-relation oops-tool oops-pg triggers the actual install
<lifeless> ?
<SpamapS> I'd really prefer there to be a way to have runtime subordination
<lifeless> SpamapS: we have runtime insubordination already :P
<SpamapS> lifeless: thats exactly how it works
<lifeless> you might like to touch up https://juju.ubuntu.com/docs/subordinate-services.html a bit while you are there
<lifeless> it reads like an advert for a coming up feature
<lifeless> not something that exists
<lifeless> it doesn't explain the 1:1 thing, nor the need to name things to get them to be M:N
<SpamapS> lifeless: indeed, its basically the original spec. We need to add a subordinate section to the tutorials
<lifeless> SpamapS: I hope this is useful feedback
<lifeless> I feel as though I've been a bit curmdgeonly
<SpamapS> its unbelievably useful
<SpamapS> we're all so close to the problem
<SpamapS> we don't always see how it relates to the real world
<SpamapS> lifeless: https://code.launchpad.net/~clint-fewbar/juju/docs-clarify-service-name/+merge/104994
<SpamapS> lifeless: I intend to do more, but that at least will fix the cited page
<lifeless> there is a lot in that diff
<SpamapS> Yeah I"m not sure why
<SpamapS> whoa heh I think I branched the wrong thing :p
<lifeless> rather than database-service, perhaps you could say wordpress-db or something
<lifeless> I suspect admins will try to name things so they can remember them
<SpamapS> lifeless: yeah I am not super happy with that name now that I read it
<lifeless> and that will ring truer
<SpamapS> ah the merge target is wrong
<SpamapS> interesting, I think lp-propose doesn't work right
<SpamapS> 'bzr lp-propose lp:juju/docs' merged against the subdir of lp:juju called docs
<SpamapS> not the docs series
<SpamapS> we really need to delete that dir from lp:juju
<SpamapS> lifeless: calling it 'wordpress-db' changes the juxtaposition a bit though.. as now we're suggesting that we couldn't relate non-wp things to it.
<lifeless> SpamapS: do you do that in the example ?
<lifeless> SpamapS: and wearing your paranoid sysadmin hat - I know you have it somewhere - would you ever do that?
<lifeless> one db server, one app
<SpamapS> my paranoid sysadmin hat yells at me from its place in my closet..
<lifeless> -much- easier to think about query behaviour, caching patterns, db recovery, failover, etc
<lifeless> I mean, you are right, yes it changes the slant.
<SpamapS> Yes indeed, though I have made multi-tenancy work fine in the past... its a whole different ballgame.
<lifeless> and rule #1 of devops is KISS :)
<lifeless> this is the same argument juju makes about machines
<lifeless> I think the difference is a matter of intent
<lifeless> sharing a machine with different components of one usecase -> fair call
<lifeless> sharing a machine with components for different usecases -> world of confusion
<lifeless> you can s/machine/DB-server/ there with no change in semantics
<lifeless> and - ahha moment - this is what I've been trying to get at with juju and multiple machines
<lifeless> when you're delivering one use case, it is often (particularly when you aren't gluing full SOA services together, but are homebrewing or whatever), easier to work in a local environment not networked.
<SpamapS> alright pushed s/database-service/wordpress-db/g
<lifeless> when you're delivering two or more use cases, at that point you definitely want things to not stomp on each other
<SpamapS> looks much better
<SpamapS> sentences read more clearly
<lifeless> so if you come to me and talk about LP + juju, I do want multiple machines, for the things that compete for resources, but I also want single machines, for the bits that really are a single unit (like the librarian with its associated helper code)
<SpamapS> lifeless: right, I think a lot of things are well written as a subordinate
<lifeless> its not that they won't in future want and need horizontal scaling etc, its a minimum complexity, maximum gain kindof thing
<SpamapS> lifeless: btw, we just pushed a new primary service into the charm store, called 'ubuntu' .. so any subordinate can be deployed alone by itself too :)
<lifeless> nice hack
<SpamapS> its also useful for pre-allocating machines in ec2/maas
<gogodoit> hi there, trying to install juju on OSX 10.7 via brew, and getting this error: Error: Failed executing: python setup.py install (juju.rb:31)
<gogodoit> (this is with a clean brew installation)
<gogodoit> any ideas what I'm missing?
<Laney> Hey jujuers. I'm trying to play with juju using canonistack but it appears to want to use the hostname of the servers when doing commands (actually, I only tried 'juju status'). Can I make it use the IP? Or, can you give me a hint to get the dns resolving?
<m_3_> Laney: on openstack installs, you need to either configure an ssh proxy into the cloud or assign a public address to the bootstrap node
<Laney> m_3_: I can ssh using the IP address, yes
<m_3_> Laney: often also need to add patterns into .ssh/config in order for it to use the proxies
<Laney> but juju tries to use server-nnnn which I cannot resolve
<m_3_> Laney: alias them in .ssh/config
<Laney> let me try that
<SpamapS> can't you just run juju on the node 0 that gets bootstrapped?
<SpamapS> just copy your environments.yaml and ssh key
<gogodoit>    sorry, I didn't rtfm, found the osx brew fix here https://github.com/jujutools/homebrew-juju/issues/5
<SpamapS> gogodoit: thanks, imbrandon is the author of that, he's at the ubuntu dev summit today and so probably not watching IRC
<Laney> SpamapS: yes, but that is more manual than I like
<Laney> I got it working with a pattern in .ssh/config
<SpamapS> Laney: yeah that usually works
<Laney> I think ...
<Laney> ERROR SSH forwarding error: nc: getaddrinfo: Name or service not known
 * Laney eyes things
<Laney> ah, works
<Laney> does canonistack have a secure transport?
#juju 2012-05-08
<SpamapS> Laney: I don't think so..
<SpamapS> Laney: note that the EC2 API is secure against all but replay attack (and that is mitigated by expiring most commands very soon after they are run)
<lifeless> server can do replay detection anyhow
<lifeless> if we wanted to teach it
<SpamapS> lifeless: if you +1 this https://code.launchpad.net/~clint-fewbar/juju/docs-clarify-service-name/+merge/104995 I'll just merge it.
<lifeless> looking
<lifeless> I think on line 6
<Laney> fair
<lifeless> you should replace :: with
<lifeless> \n\nFirst we need a database for wordpress, so we use the optional name parameter to call it wordpress-db::'
<lifeless> SpamapS: ^ what do you think ?
<Laney> can I have a service exposed on an allocated public address?
<SpamapS> Laney: yes, it will expose the public-address
<Laney> SpamapS: do I have to give it as a parameter to any command?
<SpamapS> lifeless: yeah that makes sense. http://paste.ubuntu.com/974771/
<lifeless> SpamapS: +1 :)
<marcoceppi> Oh crap, shazzner is working on a gitolite charm
<popey> yo yo yo
<marcoceppi> o/
<marcoceppi> popey: did lxc finally get running?
 * marcoceppi is lazy
<popey> marcoceppi: yes
<popey> lol
<marcoceppi> excellent
<popey> however...
<popey> alan bell is having fun
<popey> he had to reboot his machine
<popey> now doesn't know how to start the 3 lxc containers up
<marcoceppi> popey: that sounds fun...
<SpamapS> popey: the incantations for recovery of the lxc containers after reboot has not been fully discovered yet
<SpamapS> popey: best to destroy/bootstrap again
<marcoceppi> SpamapS: that's what we ended up doing. I though LXC could survive reboots, at least it has been for me.
<SpamapS> marcoceppi: seeing as zookeeper and the containers are not restarted, thats surprising
<SpamapS> which is particularly problematic as the machine agent *is* started, and spews forth with ridiculous maounts of zk timeouts
<marcoceppi> SpamapS: happened on my desktop a week ago, did a reboot, came back 5 days later with my disk full
<marcoceppi> SpamapS: ah, that's why. error log just grew due to timeouts
<marcoceppi> so, would restarting zookeeper fix that?
<SpamapS> yes that
<SpamapS> just need to restart it w/ the same data dir
<SpamapS> and then in theory you could start the containers back up and it would all work
<SpamapS> ugh I have to sleep.. have to wake up in 5 hours
<marcoceppi> SpamapS: see ya o/
<_mup_> juju/scale-test r538 committed by kapil.thangavelu@canonical.com
<_mup_> disable extraneous ec2 api usage
<popey> thanks guys. i had fun playing with juju tonight, looking forward to more playing during breaks and lunch tomorrow :D
<bkerensa> gnight charmers
<abo> I am trying out juju on my local machine. I have done a bootstrap and then I deploy a mysql charm. However "juju status" just keeps telling me that it is pending. When I look in the output.log for the unit the only info there is "/usr/bin/python: No module named juju.agents"
<abo> When I look in the lxc rootfs for the unit there is no juju python package installed (in /usr/share/pyshared). Is this a bug I should report or am I doing something wrong?
<james_w> so what does one do to make a charm subordinate? Is it at creation time or deploy time, or both?
 * james_w finds https://juju.ubuntu.com/docs/subordinate-services.html
<SpamapS> james_w: we need to improve the tutorial to include a subordinate example.
<SpamapS> we also need to update the yaml examples to match the new format
<marcoceppi> o/ SpamapS
<james_w> SpamapS, also the config.yaml documentation seems outdated?
<SpamapS> marcoceppi: join us in junior ballroom 1 .. talking about mysql. :)
<james_w> https://bugs.launchpad.net/charms/+bug/886362
<_mup_> Bug #886362: New charm proposal: txstatsd <Juju Charms Collection:New> < https://launchpad.net/bugs/886362 >
<SpamapS> james_w: woot
<james_w> need to complete the graphite-web side now
<marcoceppi> SpamapS: at the Ubuntu Cloud thing :)
<koolhead17> marcoceppi, you at the cloud summit?
<marcoceppi> koolhead17: yes
<FunnyLookinHat> Heyo - was at Charm School last night and was running local juju w/o issue, but all of a sudden today I get this error when I try to bootstrap: "ERROR Unable to create file storage for environment"
<koolhead17> ok. i will join in afternoon. mysql roundtable talk sounds interesting :)
<FunnyLookinHat> also - I'm at the System76 booth in case anyone wants to stop by...  :D
<FunnyLookinHat> marcoceppi, any luck with the glusterfs
<FunnyLookinHat> and a reboot fixed it...
<FunnyLookinHat> :-/
<marcoceppi> FunnyLookinHat: nothing like a Windows fix to an Ubuntu glitch :)
<jamespage> FunnyLookinHat, local juju environments don't recover that well after a reboot
<jamespage> if you get that again try a 'juju destroy-environment' first - that normally sorts things out..
<koolhead17> FunnyLookinHat, i think you need to restart to get the networking part working if you using LXC
<FunnyLookinHat> I destroyed environment and re-did the bootstrap after rebooting - not sure ..
<FunnyLookinHat> Before rebooting the bootstrap didn't work right
<FunnyLookinHat> very strange indeed.
<FunnyLookinHat> Ok - so SSL...  how would I configure a service to use a specific private and public key file?  Is there an easy way to pass that along as an argument?
<m_3_> negronjl: that should be public now
<FunnyLookinHat> Anyone?  Bueller?  Don't make me come up to the charm school...
<SpamapS> FunnyLookinHat: ?
<SpamapS> FunnyLookinHat: usually SSL keys are generated on the hosts that they live on.
<FunnyLookinHat> SpamapS, Yeah - I guess I'm just wondering what the process would be in terms of rolling out and scaling a service that uses SSL
<marcoceppi> FunnyLookinHat: It looks like you're going to just have to come up
<FunnyLookinHat> marcoceppi, hahaha - I'll try to sneak out of the booth in a bit.
<NCommander> Heyall, I'm trying to get juju working locally with lxc. Every command seems to succeed, but I don't get IP addresses appearing in juju status
<NCommander> oh, nm I think. Seems that while deploy works, it returns instantly instead of waiting for juju tofinish its background work
<marcoceppi> NCommander: the first time you deploy to local juju takes a while to build the master image
<marcoceppi> each subsequent time from deployment should be relatively quick
<NCommander> marcoceppi: the behavior confused me since I'm used to commands waiting until they're done
<marcoceppi> NCommander: yeah, Juju is asynchronous in that respect
 * NCommander is learning to writing ajuju charm for quassel-core
<marcoceppi> commands get pushed to the juju bootstrap, and bootstrap "queues" them and manages/co-ordinates everything
 * NCommander tests his charm
<NCommander> marcoceppi: now I've got a weird issue. My charm "works" but the output from APT during RSA key generation is showing up as error
<NCommander> (I think openssl is writing to stderr ...)
<SpamapS> NCommander: ERROR is just "stderr"
<NCommander> Right, but agent-status then ended up in start-error
<SpamapS> NCommander: we all agree we should probably change that. :)
<SpamapS> NCommander: your start-eror is based solely on exit code of the hook
<NCommander> Do I need to redirect stderr to stdout? :-/
<NCommander> Weird
<NCommander> oh, I see what happened
<FunnyLookinHat> SpamapS, so here's my confusion - when I setup an apache server to use SSL, I upload my cert to it and then set the apache virtual host to use that
<FunnyLookinHat> i.e. I have to generate the cert locally with something I grab from my cert signer... and I'm not seeing a proper place to inject those steps or that data
<NCommander> SpamapS: alright, second question. It seems every juju deploy creates a new instance. That is probably desirable for some setups, but for quassel-core, its probably best to have it and its postgresql backend on the same machine (or I suppose I could set it up so when the relation is added, migrate from sqlite -> postgresql)
 * flepied finished the first version of a naxsi charm
 * NCommander is a bit suprised there is no Launchpad charm ...
<NCommander> hrm, also, I could connect to quassel-core without having to expose
<SpamapS> flepied: naxsi?
<lifeless> SpamapS: help needed in #ubuntu-server :( is there some doc we can point folk at?
#juju 2012-05-09
<_mup_> Bug #996857 was filed: Local environment doesn't require opening ports <juju:New> < https://launchpad.net/bugs/996857 >
<dpb_> I'm trying to make a charm that does some deployment testing, i.e., install from a source, deb, or similar.  How should I get the bundle over to the server in the charm?  The bundle is local to me when I'm running juju deploy.
<marcoceppi> dpb_: what do you mean by the bundle?
<jsalisbury> Anyone available for a quick juju deploy question?
<jsalisbury> I'm trying to use a local repository instead of the juju store, but I get this:
<jsalisbury> http://pastebin.ubuntu.com/977122/
<avoine> jsalisbury: juju -v deploy --repository=/home/jsalisbury/juju/charms local:kernel-build
<avoine> jsalisbury: and you must put the charms in a directory named with the ubuntu version
<avoine> like precise or oneiric
<jsalisbury> avoine, awesome, that was it!  I was missing the local:kernel-build
<jsalisbury> avoine, this may need to be updated:
<jsalisbury> https://juju.ubuntu.com/docs/drafts/charm-namespaces.html?highlight=juju%20deploy%20local
<jsalisbury> I doesn't have the local:
<dpb_> marcoceppi: Like a private build a piece of software.  a private deb.  tar.gz file, etc.
<dpb_> marcoceppi: what I'm really wanting is to be able to test deployment from my checkout on my workstation.  I can do that with a cloud instance, but I wanted to do it through juju.
<dpb_> All I need is a way to scp a file over there as part of charm.
<jsalisbury> One additional question.  Am I using the --config option correctly:
<jsalisbury> http://pastebin.ubuntu.com/977144/
<dpb_> jsalisbury: cat out your config file if you can.
<dpb_> jsalisbury: I can use that option, so it may be something with your file
<jsalisbury> dpb_, This is it:
<jsalisbury> name: kernel-build
<jsalisbury> summary: <This charm can be used to compile the Ubuntu kernel.>
<jsalisbury> description:
<jsalisbury>   <Multi-line description here>
<jsalisbury> options:
<jsalisbury>    release:
<jsalisbury>     default:precise
<jsalisbury>    arch:
<jsalisbury>     default:amd64
<jsalisbury> ~
<jsalisbury> This is my first charm, so I may have set this up wrong ;-)
<dpb_> jsalisbury: oh I see what you are doing... --config is for specifying configuration options *into* your charm
<dpb_> jsalisbury: you probably don't need it if you are just getting going
<jsalisbury> dpb_, yes, I need to supply the release and arch
<jsalisbury> dpb_, That tells my script which kernel to build
<dpb_> jsalisbury: ah, ok.  ya, it would be used for that purpose then.
<jsalisbury> dpb_, For now, I can just hardcode it to get it working :-)
<dpb_> jsalisbury: let me give you an example that I have been doing.
<jsalisbury> dpb_, cool.  In my script I do this:
<jsalisbury> RELEASE=`config-get release`
<jsalisbury> ARCH=`config-get arch`
<dpb_> jsalisbury: http://pastebin.ubuntu.com/
<dpb_> jsalisbury: http://pastebin.ubuntu.com/977157/
<dpb_> jsalisbury: so, you need two files... one called "config.yaml" in your charm root folder
<dpb_> jsalisbury: one you pass in with the params
<jsalisbury> dpb_, ok, so I need a metadata.yaml with the basics.  Then create a second file named config.yaml with the config options
<dpb_> jsalisbury: actually, these go in "config.yaml" in your root dir
<dpb_> jsalisbury: metadata is separate and distinct
<dpb_> jsalisbury: then in your charm, you use "config-get name" to retrieve a param called "name"
<jsalisbury> dpb_, awesome I'll give it a try
<dpb_> jsalisbury: cool. :)  This has worked for me.  I'm using the PPA version of juju, btw.
<jsalisbury> dpb_, thanks for the help!
<dpb_> jsalisbury: yw
<marcoceppi> dpb_: Any file that's in the charm room will be included in the deploy, so you can copy items you want to test on to the charm, then deploy, and when you need to interact with them all of the hooks CWD are the root of the charm. so if you have this in a folder called "foo" in the charm you could just do foo/<whatever> to manipulate it
<bkerensa> SpamapS: so I was still having issues with lxc local testing but I made the fixes
<bkerensa> for locker ^
<flepied> SpamapS, naxsi is WAF: http://code.google.com/p/naxsi/
<koolhead17> anyone awake
<SpamapS> koolhead17: just me :)
<SpamapS> flepied: naxsi looks really cool btw
<koolhead17> SpamapS, good morning :)
<flepied> SpamapS, I don't fully master naxsi, it was just another try to do a charm ;-)
<SpamapS> flepied: are you at UDS? Did we meet and I didn't realize it?
<flepied> SpamapS, no I'm in France ;-)
<SpamapS> flepied: ahh ok. :)
<SpamapS> flepied: I think imbrandon is working on an nginx charm, naxsi might be an interesting add-on to that
<flepied> SpamapS, I think it's not an addon to nginx in term of packaging
<flepied> nginx is included in the naxsi package
<SpamapS> flepied: It might be an addon for the charm
<SpamapS> as in.. something you can turn on to increase security
<SpamapS> marcoceppi: Hey, I tried my branch, with our internal "canonistack" and S3.. it worked fine
<SpamapS> $
<marcoceppi> SpamapS: interesting, I'll have to give it a try again, maybe using a different AWS account
<marcoceppi> If this does work, will it land in the core? or forever be a branch?
<SpamapS> marcoceppi: I hope we can get it into core
<SpamapS> marcoceppi: at least as a stop-gap until we can do the right thing and de-couple storage from compute
<marcoceppi> The second it does let me know and I'll update the Ask Ubuntu question and start pushing it out
<SpamapS> in much the same way libcloud does
<marcoceppi> I agree, an eventual de-coupled structure would be great
<marcoceppi> actually, it would be sweet if I could just say USE THIS FOR THE COMPUTE, USE THIS FOR STORAGE, and have storage providers like dropbox, s3, u1, etc
<nathwill> +1
<marcoceppi> Though, native OSAPI would be good too ;)
<SpamapS> marcoceppi: right, OSAPI does not define swift though. ;)
<marcoceppi> SpamapS: http://www.nooooooooooooooo.com/
<SpamapS> hp-cloud: { type: ec2, storage-type: swift }
<marcoceppi> Oh, that's cool then
<SpamapS> thats kind of how I see it working
<SpamapS> and then have flavors that extend and default to things, so eventually hp-cloud: { type: hpcloud } would be short hand for the above.
<marcoceppi> +1 IMPLEMENT ALL THE THINGS
<SpamapS> we need to dive into the review queue tonight
<SpamapS> actually there's no sessions I need to care about until 11:00
<marcoceppi> SpamapS: I'd be be happy to dive in to the review queue, tomorrow <3
<jcastro> hah, cute!
<marcoceppi> Or at least after I finish ze charms
<SpamapS> jcastro: thanks for +1'ing imbrandon. :)
<SpamapS> imbrandon: welcome to charmers!! :)
<SpamapS> GET REVIEWIN!
<jcastro> http://jujucharms.com/~david-duffey/precise/ddclient
<jcastro> isn't that awesome?
<jcastro> ok from my count we're up to 17 entrants
<marcoceppi> +3 from me in an hour
<marcoceppi> or a few hours
<marcoceppi> Wait, charms or entrants?
<SpamapS> oh snap
<SpamapS> thats awesome
<marcoceppi> SpamapS: I've got a few questions about -r and relation-(get|set)
<SpamapS> marcoceppi: fire away. Also if you're in 205 we can just have a G+ hangout w/ the room. :)
<marcoceppi> SpamapS: I am in the room! that would be sweet
<marcoceppi> the commands failed yesterday: relation-get private-address -r unit/# (literally translated to relation-get private-address -r gluster/2) and it failed out
<marcoceppi> what format does -r expect?
<marcoceppi> We're pretty light in the room now, but if we start getting a lot of questions I'll put your face on the wall
<marcoceppi> SpamapS: also, I poked at the nginx reverseproxy and haproxy charm hooks, it looks like they were using relation-get private-address - unit/#
<marcoceppi> Am I missing what the -r does, man pages are a little light on documentation :)
<SpamapS> marcoceppi: -r allows you to reference a relationship from any context
<SpamapS> marcoceppi: so you can run relation-set from a cron job for instance
<jcastro> SpamapS: ok fixed.
<jcastro> SpamapS: juju charm and juju contributions are the same as other membership requirements
<SpamapS> marcoceppi: sent you a G+ invite
<jcastro> so, interacting with the community, sustained contributions, etc.
<jcastro> it counts the same as anything else
<SpamapS> jcastro: sweet
<marcoceppi> SpamapS: so what would an example of a -r value
<SpamapS> marcoceppi: anything that 'relation-ids' spits out
<SpamapS> marcoceppi: or that has arrived in $JUJU_RELATION_ID in a hook
<marcoceppi> SpamapS: I wish i had a second laptop, Otherwise people will see you and you'll be staring at me the whole time
<SpamapS> marcoceppi: so for instance, in joined, you might store $JUJU_RELATION_ID somewhere, and then re-use it to push values in later when a long running background job is finished.
<marcoceppi> SpamapS: interesting that's what I currently do
<koolhead17> marcoceppi, will you have sometime  today? i would like to sit with you and know what all new things have got integrated with juju. i missed last evening session :(
<koolhead17> i want to write a simple blog putting LXC as well as ec2 in mind
<SpamapS> marcoceppi: if you run outside the juju process, you also need to save off the socket and stuff. Check the env for the right JUJU_* variables
<marcoceppi> SpamapS: I keep a directory or $JUJU_RELATION_ID as the file name, and it's remote address in there. So to build that I'm looping through relation-list and performing some simple tests, etc in the first few lines. It's the relation-get portion that fails http://paste.ubuntu.com/978195/
<marcoceppi> SpamapS: It's running inside a relation-changed hook
<marcoceppi> s/directory or/directory of/
<SpamapS> ah ok
<marcoceppi> the -r command fails
<SpamapS> yeah thats wrong
<SpamapS> you're passing unit names
<marcoceppi> bahhhhhh
<marcoceppi> So relation-ids is what I want to loop against?
<SpamapS> Youmay just mean 'relation-ids' there.. but I'm not entirely sure
<jimbaker> SpamapS, marcoceppi - you want to use relation-ids
<SpamapS> You'll have a relation ID per *service* you are related to
<marcoceppi> SpamapS: jimbaker gotchya!
<SpamapS> so if you want to then also loop through the units inside each service you're related to, you need another loop for relation-list
<marcoceppi> SpamapS: awesome jimbaker gave me the lowwwwww down
<marcoceppi> KEEPING CALM, AND CARRYING ON
<SpamapS> werd
<SpamapS> reviewed ddclient
<SpamapS> DING DING promulgated SOLR!
<marcoceppi> Woo!
<m_3_> SpamapS: bumped service-stacks to not conflict with bug triage
<SpamapS> m_3_: thank you!
<SpamapS> m_3_: IMO stacks is not something we can talk about this cycle anyway. :(
<SpamapS> m_3_: unless we're going to make a straw-man implementation in jitsu
<m_3_> SpamapS: yeah, I was more gonna ask if it was a core feature or not
<SpamapS> m_3_: no features this cycle
<SpamapS> The resource map discussion was even a bit reaching. :-/
<m_3_> gotcha
<SpamapS> Important to discuss, but I can't see it getting implemented.
<m_3_> what about tomorrow?  any we should combine/rearrange/delete?
<m_3_> SpamapS: when you get a chance... no hurry, just wanna give michelle as much notice as possible
<SpamapS> yeah I'll review tomorrow
<m_3_> integration's still worth keeping imo
<m_3_> but yeah, I'll let you listen away :)
<SpamapS> heh.. we need an environment option.. "spare machines"
<SpamapS> I've taken to always having one machine deployed using the 'ubuntu' charm
<SpamapS> just sitting there, waiting
<SpamapS> marcoceppi: you know what would be awesome in charm-helper-sh? If you could build in support for scraping MD5's from sourceforge right into ch_file_get
<marcoceppi> SpamapS: I tried that, I ended up bailing to use php :\
<marcoceppi> Since you have to consume an XML file
<marcoceppi> Unless there's another way to get MD5 sums from SF
<SpamapS> marcoceppi: perhaps that is worth putting in a little helper script (I'd suggest python, not php) that gets included w/ charm helper tho
<marcoceppi> SpamapS: if that's okay with you, I think it'd be great
<marcoceppi> (I agree with Python for this instead of PHP, shazzer IIRC moved my php script to python in one of his charms)
<SpamapS> marcoceppi: part of me wants to start pushing for more charms to just embed a tarball tho
<SpamapS> marcoceppi: when we add this mythical tagging thing.. we will be tagging most of these "download the latest" charms as non-repeatable.
<marcoceppi> https://bugs.launchpad.net/charms/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.component-empty-marker=1&field.tag=new-charm&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.o
<marcoceppi> mit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
<jsalisbury> Is anyone here currently using canonistack?  I seem to be having an issue starting an instance.
<marcoceppi> http://bit.ly/lp-charms-review-q
<marcoceppi> SpamapS: $JUJU_RELATION_ID is what you would use against -r correct?
<SpamapS> marcoceppi: correct
<negronjl> SpamapS: ping
<negronjl> SpamapS: I approved puppetmaster and puppet.  Promulgate :)
<alex88> hello, someone tried to deploy openstack with juju?
<negronjl> SpamapS: looking at bug https://bugs.launchpad.net/charms/+bug/996576 ( reviewing ) and I see that you have this bug assigned to you.  Are you reviewing this already ?
<_mup_> Bug #996576: VIVO charm <new-charm> <Juju Charms Collection:New for clint-fewbar> < https://launchpad.net/bugs/996576 >
 * popey wonders if someone could review my (first attempt - be gentle) charm, that would be lovely âº  https://bugs.launchpad.net/charms/+bug/996361
<_mup_> Bug #996361: Charm needed: Yacy <new-charm> <Juju Charms Collection:In Progress by popey> < https://launchpad.net/bugs/996361 >
* JoseeAntonioR changed the topic of #juju to: Coming to UDS? Write a charm for a chance to win one of 3 Dell XPS 13 ultrabooks! http://goo.gl/uTGU2 || Charms at http://jujucharms.com || Want to write a charm? http://juju.ubuntu.com/Charms || OSX client: http://jujutools.github.com/"
* JoseeAntonioR changed the topic of #juju to: Coming to UDS? Write a charm for a chance to win one of 3 Dell XPS 13 ultrabooks! http://goo.gl/uTGU2 || Charms at http://jujucharms.com || Want to write a charm? http://juju.ubuntu.com/Charms || OSX client: http://jujutools.github.com/
 * marcoceppi reviews all the charms
<marcoceppi> Hey SpamapS if you wget an asc does it *have* to be over SSL? I assume yes, but I'm not 100% certain
 * popey hugs marcoceppi 
<SpamapS> marcoceppi: yes it would have to be
<marcoceppi> o/ popey got a few things for you
<popey> oh goody
<popey> is it massively broken? :D
<SpamapS> marcoceppi: best to embed a trusted key in the charm
<marcoceppi> SpamapS: that's what I figured, cool
<SpamapS> marcoceppi: then you don't have to have https for the .asc, you just need to verify the key
<marcoceppi> popey: not that bad! just a few key items and some nitpicks
<popey> ok
<popey> you gonna braindump on the bug marcoceppi ?
<marcoceppi> popey: yeah, just finishing up my reply
<SpamapS> just -1'd VIVO
<SpamapS> If anybody sees Nicholas Skaggs let him know he has some TODO's waiting for him in bug 996576
<_mup_> Bug #996576: VIVO charm <new-charm> <Juju Charms Collection:Incomplete by nskaggs> < https://launchpad.net/bugs/996576 >
<SpamapS> Same for David Duffey for ddclient bug 996905
<_mup_> Bug #996905: New dynamic dns charm ddclient <new-charm> <Juju Charms Collection:Incomplete by david-duffey> < https://launchpad.net/bugs/996905 >
<popey> thanks marcoceppi
<SpamapS> imbrandon: hey, you going to finish drupal?
<SpamapS> 90 minutes left for the laptop contest. Anybody freaking out? ;)
<jsalisbury> SpamapS, is there a document somewhere that explains how to configure environments.yaml to use canonistack instead of AWS or local?
<marcoceppi> SpamapS: yes
<SpamapS> jsalisbury: yes but Its just for Canonical people.
<komputes> marcoceppi: Could we test my charm on Openstack: https://code.launchpad.net/~komputes/charms/precise/remote-assistance/trunk
<marcoceppi> komputes: I can do it on AWS
 * SpamapS will test juju against trystack soon
<jsalisbury> SpamapS, Is there info on the internal wiki?
<lifeless> SpamapS: I'm getting the idea that jsalisbury may be 'Canonical people' :P
<SpamapS> lifeless: indeed, I just don't want others in here thinking we're using some secret cloud. ;)
<SpamapS> which.. canonistack sort of is. :)
<SpamapS> looks like there are no more juju related sessions for today
<SpamapS> at UDS I mean
<SpamapS> so, anybody making last minute tweaks, lets get 'er done
 * tumbleweed has no energy left for last minute tweaks (such as all the things I actually intended to do :P )
<SpamapS> tumbleweed: reviewing ibid right now btw :)
<tumbleweed> UDS-exhaustion :)
<tumbleweed> SpamapS: yeah, just saw that
<SpamapS> tumbleweed: you should move most of the config-get stuff to config-changed
<SpamapS> tumbleweed: so it can be changed post-install
<tumbleweed> oh, duh
 * tumbleweed quickly does that
<SpamapS> tumbleweed: otherwise, it looks pretty cool. I've thought for a while that we need an IRC bot charm. :)
 * SpamapS deploys w/ --constraint mem=64M curious if that will end up with a t1.micro
<marcoceppi> SpamapS: I realized earlier that i collided with someone elses work
<SpamapS> marcoceppi: gitolite?
<tumbleweed> SpamapS: pushed, but entirely untested :)
<SpamapS> tumbleweed: mmmm.. fresh crack
<SpamapS> tumbleweed: another nice thing would be to open the ident port
<SpamapS> SpamsPet: are you a real person?
<SpamsPet> SpamapS: *blink*
<SpamapS> SpamsPet: what is ibid?
<SpamsPet> SpamapS: I'm afraid I have no idea
<SpamapS> SpamsPet: you respond awfully fast
<SpamsPet> SpamapS: What?
<marcoceppi> SpamapS: yeah, not sure what do do about that
<SpamapS> marcoceppi: shazz has first dibs its not his fault you forgot to follow the process :)
<SpamapS> marcoceppi: he's still within 30 days of his last activity
<marcoceppi> right, so mines ready for submission
<marcoceppi> just wait it out?
<SpamapS> tumbleweed: I'm sure you've already guessed, but SpamsPet is an ibid deployed w/ your charm :)
<SpamapS> tumbleweed: I manually installed oidentd, and just used the juju-jitsu 'open-port' command to open port 113
<tumbleweed> SpamsPet: hi
<SpamsPet> lo
<SpamsPet> tumbleweed: By the way, SpamapS on irc told me "tell tumbleweed you are a genius" 6 minutes and 27 seconds ago
<SpamsPet> tumbleweed: By the way, SpamapS on irc told me "tell tumbleweed you are a genius on #juju" 6 minutes and 17 seconds ago
<SpamapS> tumbleweed: also in config-changed, just take the existence check out for ibid.ini ... just overwrite it every time.
<tumbleweed> already fixed that :P
<SpamapS> oh good :)
<SpamapS> hah rapid iteration eh? :)
<tumbleweed> yeah, there are many situations where one doesn't want such a simple config
<tumbleweed> but the hacky temporary solution is to stick a local.ini in
<tumbleweed> I see some other charms have a way to download a config / provide it at deploy. That seems the way to go for non-trivial configs
<SpamapS> tumbleweed: perhaps look at dotdee too
<SpamapS> tumbleweed: it allows you to emulate .d dirs for things that don't have them.
<SpamapS> tumbleweed: automation always gets in the way of customization. Such is the nature of the beast.
<SpamapS> ejat: hey btw, I didn't get a c hance to say hi yesterday, but, HI!
<tumbleweed> SpamsPet: Juju is DevOps DistilledTM
<SpamsPet> tumbleweed: I'll remember that
<SpamapS> negronjl: thanks for +1'ing the puppet charms. PLEASE do add things to them. I think there's a ton of interesting stuff left to do.
 * SpamapS rings the bell twice
<SpamapS> puppet(subordinate)/puppetmaster promulgated
<marcoceppi> fuuuuuuuuuuuuuuuu
<jcastro> heh
<jcastro> running out of time?
<marcoceppi> just realized one of my charms depends on charm-helpers and I never merged the dang code for that
<ejat> SpamapS: its ok .. hi back
<ejat> i guess .. i didnt have time to separate the package to make it scalable .. need to extract the package and see the create db file ..
<SpamapS> marcoceppi: its ok to embed that in your own charm. :)
<marcoceppi> SpamapS: yeah I am, I was just ready to start celebrating :)
<SpamapS> marcoceppi: charm-helpers is just an efficiency play. But its more important that charms work than that they are super efficient.
 * ejat less hope to fullfill the 5 criteria .. 
<SpamapS> jcastro: where can people look to be sure their charm is submitted to the contest btw?
<marcoceppi> http://paste.ubuntu.com/978937/
<ejat> marcoceppi: dont forget to donate ya dv7
<ejat> 0/
<jcastro> marcoceppi: http://www.quickmeme.com/meme/3p7ol1/
<marcoceppi> jcastro: ROFL
<ejat> :)
<ejat> jcastro @ anyone : can u answer SpamapS Q .. so i also can look into :)
<jcastro> SpamapS: launchpad?
<jcastro> SpamapS: all the new-charms ones since april 26.
<SpamapS> jcastro: so, tagged w/ new-charm, commits to a linked branch by 1700 ?
<jcastro> yeah
<SpamapS> ok, lets make sure to snapshot that at 1701
<jcastro> SpamapS: why? Are you working on a list of entries?
<SpamapS> jcastro: I want to make sure we capture it is all
<jcastro> k
<jcastro> so how can I do that?
<marcoceppi> I'm guessing I can't use the gitolite one for the contest?
<jcastro> I mean, the date time is in LP already
<SpamapS> I'm sure we can extract it w/ the lp api .. but simple to just look at the page at the entry time
<jcastro> oh ok
<jcastro> right right, that's easy, I can do that.
<SpamapS> marcoceppi: I'd -1 it pretty hard since you missed the process entirely. ;)
<marcoceppi> Cool, so I have glusterfs and no way to show it's power :)
<bkerensa> :(
<bkerensa> There is no way I can finish the reddit stack charm and openphot charm by 5pm
<bkerensa> le sigh
<SpamapS> marcoceppi: 13 minutes to add it to wordpress ;)
<SpamapS> marcoceppi: in that case, you can use your gitolite just to support gluster's awesomeness
<marcoceppi> à² _à² 
<marcoceppi> okay, whew
<ejat> ok thanks
<SpamapS> marcoceppi: but yeah, it would have been more awesomer to have a charm that uses gluster up for consideration :)
 * marcoceppi is the saddest
<jcastro> 10 MINUTE WARNING
<SpamapS> marcoceppi: contact shazzner, maybe you can get him to relinquish his claim :)
<marcoceppi> don't think that will happen in 10 mins :\
 * ejat ...... scratching .... 
<jsalisbury> SpamapS, thanks for reviewing my charm.  I implemented all your suggestions except using secure git or implementing some form of cryptographic verification(I'm not sure I'l be able to do that in the next 5 minutes, lol).
<SpamapS> marcoceppi: you love me
<marcoceppi> I wish I would have checked earlier
<SpamapS> marcoceppi: https://bugs.launchpad.net/charms/+bug/906176
<_mup_> Bug #906176: Gitolite charm <new-charm> <Juju Charms Collection:Incomplete> < https://launchpad.net/bugs/906176 >
<marcoceppi> I pushed my branch and emailed him
<marcoceppi> here's to helping
<SpamapS> marcoceppi: I got a hold of Chris
<marcoceppi> LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
<SpamapS> marcoceppi: note, unassigned
<marcoceppi> :OOOOOOOOOOOOOOOOOO
 * marcoceppi owes SpamapS ALL OF THE BEERS
 * SpamapS deflects at least one to shazzner
 * popey crosses his fingers
#juju 2012-05-10
<SpamapS> NTP time says pencils UP
<komputes> negronjl: https://code.launchpad.net/~komputes/charms/precise/remote-assistance/trunk
 * SpamapS urges all to bzr commit / push
<bkerensa> OK OK
<bkerensa> pushed at 5pm on the dot
<bkerensa> :D
<SpamapS> nice
<ejat> how to i translate this into postgresql add unit
<ejat> http://paste.ubuntu.com/978954/
<negronjl> SpamapS: It's UDS .... keep working :)
<ejat> negronjl: :)
<SpamapS> oo late entries include zentyal
<bkerensa> :D I didnt finish Openphoto or Reddit stack charms but I did get Locker and Nyancat Termianl pushed :)
<ejat> SpamapS: how to insert / create db after lunching the db instance
<SpamapS> bkerensa: sweet
<ejat> bkerensa: c00l
<SpamapS> ejat: which db?
<marcoceppi> stressful
<ejat> postgresql
<ejat> +1 marcoceppi
<komputes> negronjl: https://bugs.launchpad.net/charms/+bug/997386
<_mup_> Bug #997386: remote-assistance charm created <new-charm> <Juju Charms Collection:New> < https://launchpad.net/bugs/997386 >
<SpamapS> ejat: the pgsql interface creates a database for you
<SpamapS> ejat: and gives you back hostname/database name/password/user to use to access it
 * ejat can we request to extend for another day ... thats make marcoceppi release his stress
<SpamapS> hah, no more stress
<negronjl> SpamapS: when lp complains about a package not there ( ie: /charms/package_name/trunk )  how do you work around that ?
<SpamapS> all the stress is on us judges now
<ejat> SpamapS: if there is createdb.sql for example ?
<SpamapS> negronjl: /charms/series/packagename/trunk
<negronjl> SpamapS: error:  packagename is not a valid package name
<SpamapS> ejat: ??? how can we know what the schema should be
<negronjl> SpamapS: got it
<negronjl> SpamapS: thx
<ejat> SpamapS: its bundle with the apps .. for sample data
<ejat> and schema
<SpamapS> ejat: so do it the way upstream says to do it?
<ejat> SpamapS: https://bugs.launchpad.net/charms/+bug/997339
<_mup_> Bug #997339: Charm needed : Openbravo <new-charm> <Juju Charms Collection:New for fenris> < https://launchpad.net/bugs/997339 >
<ejat> now .. the charm will install its package .. bundle all together
 * ejat just thinking how to make its scale by separating the db to another unit 
<SpamapS> ejat: just check to see if the tables are already created
<ejat> for example .. i juju deploy openbravo3
<ejat> then i juju deploy postgresql
<SpamapS> if tables_do_not_exist; then create_tables ; else juju-log "tables already exist" ; fi
<ejat> juju add-relation openbravo3 postgresql
<ejat> put in in add-relation ?
<SpamapS> ejat: you can't really create the database until you have a relationship with the db server, can you?
<SpamapS> ejat: so yes, you would create the database during the db-relation-changed hook
 * SpamapS goes afk for a few
<ejat> SpamapS:  dont know ... i guess cant create db until there is relationship rite ?
<SpamapS> marcoceppi: 2012-05-09 17:28:31,415 unit:gitolite/0: hook.output ERROR: invalid user: `gitolite:gitolite'
<SpamapS> marcoceppi: oops, disregard.. different gitolite ;)
<SpamapS> stupid revision file!
<roy_> Hey Marco, these charms can't be accessed from precise, but the are listed in the charm store
<roy_> keystone, nova-cloud-controller, nova-volume, glance, openstack-dashboard
<SpamapS> royfeldman: they're a little bit wonky..
<SpamapS> royfeldman: we have a TODO to fix those
<SpamapS> royfeldman: basically, use cs:~charmers/precise/keystone
<royfeldman> OK
<royfeldman> I  will give it  a shot now, right now I am using the charms in a local repo
<royfeldman> Yup, that works. Thanks for the tip.
<royfeldman> Anybody know about the charm github mirror?
<royfeldman> Is say is a mirror updated nightly, but it is missing many of the charms in the store.
<huats> Hi!
<huats> When using juju add-relation
<huats> is there a way to be sure that one part of the relation will be done before the other part
<huats> by instance
<huats> juju add-relation foo-master foo-slave:slave
<huats> I want to be sure that the master-relation-joined to be executed before the slave-relation-joined
<huats> how can I do that ?
<_mup_> juju/scale-test r539 committed by kapil.thangavelu@canonical.com
<_mup_> switch topology from yaml to json
<hazmat> huats, you don't
<hazmat> huats, just do it in rel-changed, and if the master hasn't set some value, then exit in the slave hook side
<nathwill> i'm getting an unbound variable error when trying to use $JUJU_SERVICE environment variable in my relation-joined hook... am i misreading this?
<andrewebdev> morning :) ... So I've been using zc.buildout to do isolated Django website deployment. Looking at Juju, it seems that this can greatly improve my deployment process. I have a couple of Questions tho. Is there a way to test the charm locally, or do I need a EC account?
<nathwill> andrewebdev: http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage
<nathwill> yes :)
<andrewebdev> thanks nathwill! that's quite comprehensive
<nathwill> thank the guy who wrote the answer ;) i just bookmarked it
<andrewebdev> So I followed the instructions here: http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage  and everything worked so far. The status command does not show the same however.
<andrewebdev> I dont have the same machine ips, in fact I just have []
<andrewebdev> and state is just: pending
<dpb_> are there any docs on the apt proxy that is set up automatically for you by juju when using lxc containers?
<hippysurfer> Hi, just playing with juju for the first time. Try to experiment on a local (LXC) setup. All worked fine until I rebooted the host machine. Now, it appears that zookeeper has not been restarted. So everything I try times out. Any clue how I can restart zookeeper?
<dpb_> hippysurfer: juju destroy-environment; juju bootstrap
<dpb_> hippysurfer: don't know if there is a way to keep it up between boots, but that will fix it.
<hippysurfer> thank you, that has at least got me back to a sane state. I little harsh to have to destroy the whole environment, but I suppose the nodes are meant to be desposable.
<dpb_> hippysurfer: well, that is how I was looking at it.  but I'm new as well to juju, maybe someone more experienced will have some magic to keep it useable between boots. :)
<MarkDude> jcastro, I gots me a question about juju- are the dependencies included?
<FunnyLookinHat> Who won the charm competition?  I didn't get to finish mine in time for submission but figured it was sub-par and needed more work anyways :)
<MarkDude> Or anyone else that may know about dependencies
 * MarkDude is trying to see about getting juju in Fedora reops
<MarkDude> repos that is
<dpb_> is there a trick to getting the lxc unit tests to run?
<dpb_> I'm running:  TEST_SUDO=1 ./test juju/lib/lxc/tests/
<dpb_> the work, but the first one fails (test_container_clone).  then it seems to hang after that
<hazmat> jcastro, http://askubuntu.com/questions/134237/error-charm-not-found-in-local-repository
<FunnyLookinHat> Still getting this issue whenever I reboot and try to deploy a local charm: "2012-05-10 10:50:54,730 ERROR Unable to create file storage for environment"
<FunnyLookinHat> then I do juju destroy-environment - which asks for my sudo password and then posts the same error
<FunnyLookinHat> Then - if I reboot and juju bootstrap - it "just works" TM
<mars> SpamapS, nice README for the Puppet charm.  Very readable and concise.
<huats> hazmat: thansk thatsolved my isssue
<balloons> has anyone had success deploying a large local charm? Something like 100mb? It doesn't seem to transmit to ec2 properly
<_mup_> juju/scale-test r540 committed by kapil.thangavelu@canonical.com
<_mup_> extra sanity check for provisioning agent
<zykes-> what does MaaS Enroll mean ?
<hazmat> zykes-, its how a machine registers with maas
<pdtpatrick> Question - im trying to follow this link to install openstack: http://tinyurl.com/bqfpocl  ... however im getting the following errors: http://pastie.org/private/r4cwz6kem3bxmuvuqwhfq
<pdtpatrick> and here's my .cfg file
<pdtpatrick> http://pastie.org/3892150
<zykes-> hazmat: but why does it power down the machine after it's first been booted up +
<hazmat> zykes-, because after it tells maas to manage it, maas turns off the machine till something tells maas it wants to use the machine
<zykes-> ah ok
<zykes-> how can I setup interfaces using the MaaS ?
<zykes-> like bonding and so on
<ahasenack> hi, I'm usinc lxc and tried to deploy a standard mysql charm from the storm on precise, but juju status shows it's pending and I don't know why. The logs inside the container hint at a network problem perhaps:
<ahasenack> http://pastebin.ubuntu.com/980796/
<ahasenack> Failure: txzookeeper.client.ConnectionTimeoutException: could not connect before timeout
<ahasenack> any hints as to where debug further?
<ahasenack> hm, I only have one cgroup fs mounted, which is odd, a colleague has many (cpu, cpuacct, etc) mounted and it's working for him
<ahasenack> ok, found it
<ahasenack> ufw
<pdtpatrick> Question - im new to juju. I've deployed lodgeit  with "juju deploy lodgeit", juju status shows me a private ip. However, browsing to it gives an error. Has anyone gotten this working ?? if so what could i be missing ?
<hazmat> ahasenack, yeah.. ufw breaks lxc local provider typically
<hazmat> interesting that it interfered with cgroups
<hazmat> zykes-, i don't think bonding is supported yet by maas
<hazmat> pdtpatrick, what error?
<hazmat> pdtpatrick, this in local provider or ec2? .. on ec2 you also need to expose the service, via juju expose service_name
<ahasenack> hazmat: I now don't think cgroups had anything to do with it
<pdtpatrick> hazmat, this is a local service. It is giving me a 500 error so a server error.
<ahasenack> hazmat: still something odd going on here in the sense that I don't have cgroup mounted after boot, but I can workaround that
<pdtpatrick> hazmat, http://pastie.org/3892348
<hazmat> pdtpatrick, that looks sane.. so you can't access it the page in a browser, or there is an error from the lodgeit app?
<hazmat> pdtpatrick, that sounds like a problem in the charm
<pdtpatrick> hazmat, i have debug on another screen and im not seeing anything that says why it is failing.
<hazmat> ahasenack, do you have the cgroup-lite package?
<hazmat> ahasenack, thats the one that has the upstart jobs to auto mount the cgroups
<ahasenack> hazmat: yep, that's the initscript I have to call manually after booting to get cgroup mounted, I haven't figured out why yet
<ahasenack> it's upstart, and seem to trigger on /sys being mounted
<ahasenack> seems
<ahasenack> anyway, it's working now, it's just this odd thing
<ahasenack> which I can workaround
<hazmat> ahasenack, cool though unfortunate
<hazmat> pdtpatrick, if you could pastebin the unit log i might be able to help more
 * hazmat runs to the next uds session
<pdtpatrick> hazmat, http://pastie.org/3892379
#juju 2012-05-11
<koolhead17> hello alamo
<timrc> alamo, https://juju.ubuntu.com/docs/provider-configuration-ec2.html
<koolhead17> :P
<alamo> :-)
<koolhead17> SpamapS, you around?
<aljosa> what should admin-secret for local environment be? root password?
<aljosa> in environments.yaml
<marcoceppi> aljosa: No, just a random string of characters
<marcoceppi> Note to myself, relation-set doesn't accept a unit-name and it may be a bug
<marcoceppi> Note to myself, I was not reading my code right
<bkerensa> marcoceppi: so do I get to write about your plenary in the next issue of Ubuntu User Magazine? :)
<koolhead17> morning all
<koolhead17> SpamapS, around
<SpamapS> koolhead17: I am here on IRC. Good morning (I'm back home now though)
<SpamapS> koolhead17: did not have a chance to say bye yesterday. It was good meeting you and having you there at UDS. :)
<koolhead17> SpamapS, same here sir. :)
<FunnyLookinHat> So - who won the charm competition?  :D
<SpamapS> FunnyLookinHat: winners announced today at the closing plenary IIRC
<_mup_> Bug #998153 was filed: example passes passwords via command line arguments <juju:New> < https://launchpad.net/bugs/998153 >
<_mup_> juju/scale-test r541 committed by kapil.thangavelu@canonical.com
<_mup_> pep8ify ec2 provider
<SpamapS> How's it going in room 205 today everybody? ;)
<marcoceppi> SpamapS: pretty good, light today
<SpamapS> marcoceppi: did you fix your gitolite/gluster thing yet? I want to see that stuff promulgated. :)
<marcoceppi> SpamapS: yeah, I'm just testing the final setups
<SpamapS> sweet
<SpamapS> ninjix: hey, are you still working on the proxmox thing?
<ninjix> SpamapS: yes
<ninjix> working on improved client class
<ninjix> was just looking at MaaS docs
<ninjix> getting some more ideas
<SpamapS> ninjix: cool. :)
<marcoceppi> any ideas? http://askubuntu.com/questions/134977/juju-tutorial-with-lxc-fail/135080#comment161056_135080
<SpamapS> marcoceppi: reading
<ahasenack> quick question about default passwords for database admins. From the mysql charm: http://pastebin.ubuntu.com/982179/
<SpamapS> bcsaller: hey didn't you include a tool that users can run to gather a bunch of helpful things for debugging the local provider?
<ahasenack> why store the pass in the file in the install hook? Is the install hook ever called again during the life cycle of the unit?
<SpamapS> ahasenack: yes, in upgrade-charm it gets called again
<SpamapS> ahasenack: or, it might anyway ;)
<ahasenack> SpamapS: ah
<bcsaller> SpamapS: misc/devel-tools/juju-inspect-local-provider but it might not be making into the package properly
<SpamapS> bcsaller: ah yeah it would need to be added to the EXTRA_DIST in setup.py I think
<ahasenack> SpamapS: so, that could be a best practice? That and some chmod 0600 or something I suppose
<SpamapS> bcsaller: thanks tho, I think thats what we need for this user
<SpamapS> marcoceppi: I posted a comment to try and help him run the juju-inspect-local-provider tool
<marcoceppi> SpamapS: thanks, if that works I'll edit it back in to the question
<marcoceppi> that would be good for the docs too
<SpamapS> Yeah I think we should probably distribute that in /usr/share/docs or /usr/lib/juju or something.
<SpamapS> perhaps even the path.. but then I think it needs a man page. :-P
<SpamapS> and on OS X /puppies/unicorns or wherever it is they put extra program data
<SpamapS> ahasenack: the mysql charm is very old, and needs revisiting at nearly every level I suspect. But yes, I think its fine to generate a password and store it somewhere "safe"
<ahasenack> SpamapS: ok, thanks
<ahasenack> SpamapS: to push a charm while I'm working on it, is the lp project called "charms"?
<ahasenack> pushing to "lp:~ahasenack/charms/openldap" doesn't seem to work, for example
<SpamapS> ahasenack: lp:~ahasenack/charms/precise/openldap/something
<ahasenack> ah, ok
<SpamapS> ahasenack: its a distro
<SpamapS> ahasenack: if 'something' is 'trunk' then the charm store will publish that charm
<SpamapS> ahasenack: and will not re-publish it until you increment the 'revision' file.
<ahasenack> SpamapS: but only after approval, right?
<ahasenack> will it publish
<SpamapS> no it will be published as cs:~ahasenack/precise/openldap
<ahasenack> hm
<SpamapS> 'trunk' is special, its like a PPA
<ahasenack> ok, but this is really not ready for consumption
<ahasenack> I just want it somewhere in lp as a backup mainly
<SpamapS> ahasenack: then call it 'inprogress' or something else other than 'trunk'
<ahasenack> ok
<ahasenack> SpamapS: thanks
<SpamapS> ahasenack: and btw, thank you for doing openldap. Do you have a bug open for it?
<ahasenack> SpamapS: and yes, the docs mention all this, sorry for not paying more attention
<ahasenack> SpamapS: no
<SpamapS> ahasenack: Kees was considering doing LDAP so make sure you open a bug to avoid duplication
<ahasenack> SpamapS: I have never done a charm before, he would probably do a better one and I wouldn't want to prevent him from doing it
<ahasenack> meaning, I won't mind if monday comes and he has one ready, what I'm doing is not wasted work, it's learning :)
<SpamapS> ahasenack: no you guys can collaborate on it though. :)
<SpamapS> ahasenack: anyway, that sounds good. :)
<SpamapS> BTW, reviews guys! rreeeeviews!
<SpamapS> 9 ready for action
<ahasenack> the logs can be a bit worrying at first: 2012-05-11 12:20:30,400 unit:slapd/2: hook.output ERROR: + open-port 389
<ahasenack> but that's just stderr
<ahasenack> but being used in the same place as you see DEBUG, INFO, it can make you think it's actually an error
<SpamapS> ahs3: thats only because you're running with set -x :)
<SpamapS> ahs3: sorry that was for ahasenack
<ahs3> SpamapS: heh.  that's what i figured :)
<nathwill> marcoceppi, added comment on that askubuntu question.
<Destreyf_> Is it currently possible in juju to provision multiple services to a single machine?
<Destreyf_> using MAAS as the infastructure.
<Destreyf_> Am i still connected?
<Destreyf_> Looks like it.
<Destreyf> there we go, corrected my nick.
<SpamapS> Destreyf: can you provide an example of where you would want to put multiple services on one machine?
<_mup_> Bug #998238 was filed: local provider should setup ufw to accept connections to zookeeper from containers <juju:New> < https://launchpad.net/bugs/998238 >
<nathwill> yaaay
<SpamapS> nathwill: ;) good find!
<nathwill> pfft. someone in here helped me with it before... i suspect you...
<nathwill> :P
<nathwill> all i did was remember the answer.
<marcoceppi> nathwill: you should make that an answer (though if it's the case, that question should be closed as a duplicate)
<SpamapS> it wasn't me, but its still very cool. :)
<SpamapS> marcoceppi: I think its quite likely
<marcoceppi> mm, I'll wait to see if the author responds
<nathwill> marcoceppi, it's exactly what had happened to me.
<nathwill> also, i tried looking for how to close it as a dupe... couldn't find it, don't believe i have the privs
<SpamapS> nathwill: flag it, but lets make sure thats the problem first
<nathwill> SpamapS: okey doke
<SpamapS> m_3: are you guys going to do a lightning talk about your bazillion node hadoop cluster?
<nathwill> woot hadoop!
<m_3> SpamapS: nope
<m_3> SpamapS: good idea though... didn't think of it
<hazmat> m_3, greetings almost done
<SpamapS> marcoceppi: congrats!
<SpamapS> james_w: you too
<marcoceppi> thanks SpamapS!
<marcoceppi> now to polish
<bkerensa> grats marcoceppi :)
<nathwill> SpamapS, just remembered, hazmat was the one who helped. notchoo
<m_3> jamespage: the "provisioner"... can some of that be handled by running charmtester against maas?
<m_3> I guess it's a little different b/c of ISO testing
<m_3> still seems like there's something there
<jcastro> SpamapS: yo yo debian new queue?
<SpamapS> jcastro: just now retitled the ensemble ITP to juju
<jcastro> \o/
<m_3> nice
<SpamapS> jcastro: need to fix some things, deps and such, to work in Debian
#juju 2012-05-12
<_mup_> juju/scale-test r542 committed by kapil.thangavelu@canonical.com
<_mup_> json EVERYWHERE, feasible ;-)
<ihashacks> anyone else getting "agent-state: start-error" on the puppet/puppetmaster charms?
<ihashacks> Pretty sure it is because of this: http://paste.ubuntu.com/982903/
<SpamapS> ihashacks: well done, that is a problem, fixing now
<SpamapS> ihashacks: fixes pushed as charm revision 7. an 'upgrade-charm --force' should give you the new charm, and then you can try 'juju resolved --retry puppet/1'
<carroarmato0> hello, I'm very interested in getting to know juju and try it out, however, I don't have an Amazon account. Is it possible to try out juju on a stand alone remote server?
<ihashacks> SpamapS: YAY! glad to be of service :-P
<ihashacks> actually, now I have "relation-errors" and a boat load of hook.output ERROR messages - I'll destroy-environment and start fresh to be safe.
<ihashacks> SpamapS: "relation-errors" stick around even after a full destroy-environment http://paste.ubuntu.com/983956/
<SpamapS> ihashacks: reading
<SpamapS> ihashacks: heh.. looks like the puppet charm was pretty badly broken. ;) Another major fix coming
<SpamapS> niemeyer: Hey, I just noticed the charm at lp:charms/ubuntu did not make it into the charm store.
<niemeyer> SpamapS: Hmm..
<niemeyer> SpamapS: Heya
<niemeyer> SpamapS: Let me see if I can tell what went wrong without Tom's help
<SpamapS> niemeyer: would be good if the log was exposed somewhere
<niemeyer> SpamapS: Yeah, sorry about that.. it's all in the database, just not in the API yet
<niemeyer> SpamapS: Will fix it ASAP
<niemeyer> SpamapS: Erm.. charms/ubuntu?
<niemeyer> SpamapS: That URL doesn't look right
<SpamapS> its there on launchpad
<SpamapS> and jujucharms.com
<SpamapS> points to https://code.launchpad.net/~charmers/charms/precise/ubuntu/trunk
<niemeyer> SpamapS: Oh, ok.. you mean cs:precise/ubuntu then
<niemeyer> SpamapS: Is that an official charm?
<SpamapS> right
<SpamapS> yes.. deploys a blank server
<niemeyer> Cool
<niemeyer> {"cs:precise/ubuntu":{"revision":0,"errors":["entry not found"]}}
<SpamapS> hm
<SpamapS> should I try just bumping revision to 1?
<SpamapS> actually, revision is 1 in the branch
<niemeyer> SpamapS: No, this looks like something else
<niemeyer> SpamapS: Is there a symbolic link?
<SpamapS> no symlinks
<niemeyer> SpamapS: The message is not very helpful indeed
<SpamapS> one thing.. bzr spits out extra stuff because it thinks it might be an Ubuntu packaging branch
<niemeyer> SpamapS: We may need Tom's help to see what else went wrong
<SpamapS> Using saved parent location: bzr+ssh://bazaar.launchpad.net/~charmers/charms/precise/ubuntu/trunk/
<SpamapS> Most recent Ubuntu version: MISSING
<SpamapS> not sure if that would confuse the import code
<niemeyer> SpamapS: Oh, hold on
<niemeyer> SpamapS: This error is generated when the store didn't find the charm indeed
<niemeyer> SpamapS: It doesn't say why
<niemeyer> SpamapS: We need to look at the events collection to see why
<niemeyer> SpamapS: Which is where the bundling errors are
<niemeyer> SpamapS: I'll try to bundle it locally with the Go port to see if I can detect any issues
<niemeyer> SpamapS: Nope, all good too
<niemeyer> SpamapS: We'll need Tom really
<SpamapS> niemeyer: Ok, should we just open an RT?
<niemeyer> SpamapS: Not sure.. we'll probably have to grab him live
<_mup_> Bug #998542 was filed: Status Output to SVG Fails When Environment Name Contains - <juju:New> < https://launchpad.net/bugs/998542 >
<marcoceppi> Writes a blank Ubuntu charm to be cliever, BREAKS ALL THE THINGS
<SpamapS> marcoceppi: FYI, this is no-snark-saturday... you're doing it wrong
<SpamapS> marcoceppi: back home yet?
<SpamapS> argh.. hostnames and ips and goblins, oh my
* JoseeAntonioR changed the topic of #juju to: Charms at http://jujucharms.com || Want to write a charm? http://juju.ubuntu.com/Charms || OSX client: http://jujutools.github.com/
#juju 2012-05-13
<nathwill> is charm store by chance importing charms too soon?
<nathwill> i'm really confused to suddenly find a couple charms i submitted on jujucharms.com without any indication of promulgation in the relevant bugs
<nathwill> hrm. no... juju's not finding it in the charm store... that's very strange
<SpamapS> nathwill: if you name a charm branch 'trunk' it will end up on jujucharms.com and in the charm store as cs:~your-lp-id/precise/charmname
<SpamapS> nathwill: in that way, you can emulate PPA-like behavior
<nathwill> interesting. i wasn't aware of that, was kinda surprised.
<nathwill> i figured something like that was going on after juju failed to grab it from non-local. :)
<SpamapS> nathwill: while I like the coolness of 'juju deploy x' .. its not suitable for production. You can't update the charm in any way if your live service needs some tweaks.
<SpamapS> so.. local: is probably going to need to be the way people use most charms for a while anyway. :-P
<nathwill> SpamapS: that makes sense. i imagine most folks're going to be taking advantage of xyz config options anyhow.
<SpamapS> nathwill: thats not really useful at 3am when your pager goes off and the charm is just broken though. ;)
<nathwill> nothing seems useful at 3am when your pager goes off
<SpamapS> least of all one's brain ;)
<nathwill> except maybe a hammer, for the pager.
<SpamapS> hopefully that hammer comes with a good resume template. ;)
<nathwill> lol. indeed...
<ihashacks> $ juju add-relation nagios mysql
<ihashacks> ... that would have been *too* easy, huh?
<nathwill> so, i've noticed a few times that relation-departed doesn't seem to get run if you destroy a service without removing the units first... anybody aware of that or should i file a bug?
<SpamapS> ihashacks: actually, recent changes to juju *should* make it that easy
<SpamapS> ihashacks: we just need to update the nagios charm
<SpamapS> ihashacks: oh wow, nagios is REALLY out of date
 * SpamapS notes that we really really need full testing.. like now
<SpamapS> bit rot is bad
<SpamapS> ihashacks: anyway, I am working on fixing it, lp:~clint-fewbar/charms/precise/nagios/trunk ...
<james_w> \o/
<james_w> getting that working will be a big win for us
<_mup_> Bug #998888 was filed: juju-info should include the remote charm and open ports <juju:New> < https://launchpad.net/bugs/998888 >
<SpamapS> ihashacks: ok, if you deploy cs:~clint-fewbar/precise/nagios , it should be able to relate to *any* service and it will add ping checks. Still needs a lot of work to group units into service groups and also to add more plugins
<SpamapS> still needs a LOT of work
<james_w> SpamapS, any service? or anything with http interface?
#juju 2013-05-06
<vrturbo> HI All, I have an openstack cloud with NO Swift, how can I setup juju enviroments.yaml ?
<vrturbo> tired openstack_s3 but this doesn't work  error: environment "openstack" has an unknown provider type "openstack_s3"
<hloeung> vrturbo: hi, what version of juju are you using?
<vrturbo> juju-core_1.10.0-1~1189~precise1_amd64.deb
<vrturbo> hloeung, installed using the normal ppa:juju/pkgs
<hloeung> vrturbo: I believe that's the Go version. I'd say to try juju, the Python version
<hloeung> vrturbo: I've just tested it against juju-0.7-0ubuntu1 and it still supports the openstack_s3 provider
<vrturbo> can't seem to install 0.7, any ideas ?
<vrturbo> im using 12.04 LTS
<hloeung> vrturbo: how about 0.5? https://launchpad.net/ubuntu/precise/+source/juju
<vrturbo> I'm installing 0.6 now
<vrturbo> I'll see if that works for me with the _s3
<vrturbo> do you know what I use for the admin-secret ?
<vrturbo> and control bucket ?
<hloeung> vrturbo: if you run 'juju bootstrap' for the first time, it should generate these for you
<hloeung> vrturbo: I mean, it should create an environments.yaml where you can use to fill in the remaining bits
<vrturbo> Just not sure where I get the where the admin-secret comes from, do I just make it up ?
<SpamapS> vrturbo: admin-secret is just a string to be shared among clients
<SpamapS> vrturbo: control-bucket should be unique per environment
<SpamapS> I'd suggest long random strings for both
<vrturbo> ok thanks I'll give it a try
<vrturbo> getting the error  ERROR Could not find AWS_ACCESS_KEY_ID
<vrturbo> oh so in order to use the penstack_s3 it's expecting you to use AWS S3
<vrturbo> openstack_s3
<vrturbo> \part
<jakel> hi all
<_mup_> Bug #1176931 was filed: Machine 0 services fail because zookeeper fills storage <juju:New> <https://launchpad.net/bugs/1176931>
<AskUbuntu> Can jitsu deploy multiple service units like juju's "add-unit" command? | http://askubuntu.com/q/291579
<sarnold> jcastro_: hey, that looks like an oakland IP :)
<jcastro_> yeah!
<sarnold> jcastro_: how many people are at the server sprint?
<jcastro_> I think 60 something?
<sarnold> jcastro_: cool, still a lot of people :)
<_mup_> juju/trunk r623 committed by kapil@canonical.com
<_mup_> when upgrading a charm, if the new charm has peer rels, add them.
<free> hello, anyone around for a juju store question?
<free> essentially, what is or was the process for publishing a charm to the store
<free> I ask because for example the default precise charm revision of http://jujucharms.com/charms/precise/ceph is 8, but lp:~charmers/charms/precise/ceph/trunk is at revision 91 (and ftr revision 8 was apparently never checked in, so not sure where the code currently in the store has come from)
<free> jamespage: you might know ^^^
<free> it seems that the actual content of the charm served by the store (rev 8) and the one in bzr (rev 91) is the same, so I guess the charm store just renumbers it
<mfisch> free: I think the docs cover the process to get into the store
<mfisch> free: not sure about those revisions though
<mfisch> free: here's how you get into the store, https://juju.ubuntu.com/docs/charm-store.html the review takes a couple weeks from what I've found
<AskUbuntu> relation error between nova-compute and nova cloud controller | http://askubuntu.com/q/291736
<free> mfisch: thanks, it doesn't mentioned the behavior I noticed, but I think my guess is correct
#juju 2013-05-07
<vrturbo> having issue with agent not running on my zookeeper node 0 as per http://pastie.org/7811335 how do I start the service ?
<vrturbo> restarted with "restart juju-machine-agent" still not working
<lemao> hello
<AskUbuntu> How to configure MAAS to be able to boot virtual machines | http://askubuntu.com/q/292061
<ericmcray> hello guys. I have a wordpress web site and it is getting bigger, everyday visits increase. I'm using mediatemple grid server but now i have gpu overhelming :) So, should i use amazon aws with juju?
<avoine> this is a funny one: juju-core use the exponential notation for server id : https://az-3.region-a.geo-1.compute.hpcloudsvc.com/v1.1/<my_id>/servers/1.006285e+06
<avoine> of course this is not working and I have reported a bug
<avoine> for Goose
<sarnold> avoine: haha, that's awesome :)
<jam> evilnickveitch: https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910
<AskUbuntu> What environment do I need to deploy the virtual-maas charm? | http://askubuntu.com/q/292168
<b1tbkt_> is there an easy way to rotate the logs that are coalesced into debug-log?
<dimitern> b1tbkt_: use logrotate perhaps?
<dimitern> b1tbkt_: http://www.thegeekstuff.com/2010/07/logrotate-examples/
#juju 2013-05-08
<grande> hey guys does juju work with Azure now?
<JoseeAntonioR> hey guys, I don't know if any of you is interested on giving a Juju session for OpenWeek <https://wiki.ubuntu.com/UbuntuOpenWeek>, to get more people involved with the team
<koolhead17> jcastro, ping
<_andres_> Hi. I'm trying to locate the juju sesion that was on ubuntuonair, until yesterday, but I can not find it in the youtube channel. Can sombedoy point me to the video, please. Thank you
<marcoceppi> _andres_: Which one?
<marcoceppi> The charm school session from last Friday?
<_andres_> yes that one Marco, thank you, Somebody already pint me in the right direction, thanks anyway
<torin_> hazmat: are you around? I have a couple questions about your retry-backoff branch.
#juju 2013-05-09
<SpamapS> ugh.. trying to bzr pull from every charm in precise takes *a long time*
<sarnold> yeah, I think I ended up ^C on that, figuring that the first 50 charms would probably have the example code I'd want to learn from...
<SpamapS> I used to publish a tarball with all of the current charms at http://people.canonical.com/~clint/ .. I wonder if my crontab is available for somebody else to set that up again
<timrc> SpamapS: bar is designed to allow you, the developer, long coffee and / or smoke breaks
<timrc> blah
<timrc> bzr
<SpamapS> bar too
<timrc> SpamapS: indeed;)
<b1tbkt> FATAL ERROR: Could not determine OpenStack codename for version 1:2013
<b1tbkt> getting that when deploying keystone
<mattgriffin> jamespage: i don't see zul around. was he going to join the debian-mysql hangout?
<jamespage> mattgriffin, let me go find him
<wallyworld> m_3: hey, are you free for a juju subcommand chat in 208?
<thumper> or marcoceppi
<thumper> some people... are questioning your desire for plugins
<marcoceppi> thumper: wallyworld right now?
<thumper> if possible
<wallyworld> if possible. or later works too
<marcoceppi> not atm, later for sure
<thumper> kk
<marcoceppi> thumper: wallyworld: you guys have time now?
<wallyworld> marcoceppi: yesy please, room 208 ok?
<marcoceppi> wallyworld: yes, we'll be up in 5
<wallyworld> kk
#juju 2013-05-11
<ChrisG_> Hi all
<ChrisG_> Im a juju novice, I only watched the workshop this morning.  I have a couple of questions
<ChrisG_> When it says expose the app in the cloud, does that imply it will give you a fairly hard to remember URL?
<chrisguk> anyone here?
<chrisguk> anyone here
<lemao> there is at least one here :) not sure if I can be of any help as I am just starting with juju
<euphor][a> hi all
<euphor][a> im getting error: unknown constraint "instance-type" when I try to set a contraint?
<euphor][a> what gives :/
<chrisguk> hello
#juju 2013-05-12
<chrisguk> anyone here
<axisys_> so anyone wrote a charm for request tracker?
<axisys_> http://bestpractical.com/rt/ for this
#juju 2014-05-05
<jose> lazyPower: ack
<lazyPower> jose: its not a game changer, just noticed it when I was derping around after my desktop upgrade
<jose> lazyPower: would you think it'd be good to remove the tests until I can get them fixed?
<lazyPower> jose: beg pardon?
<jose> owncloud
<jose> tests are failing
<lazyPower> i'd rather see them fixed vs just removed
<jose> have tried to but can't
<lazyPower> jose: ping me about it tomorrow and i'll take a look
<jose> awesome then :)
<exippy> hello everyone, I need to prevent juju from starting at boot but I can't figure out how to do this, can anyone help me?
<jam> exippy: what is "juju starting at boot", you are running the local provider but don't want your instances to start? Or is there something else?
<exippy> yes this is exactly it :)
<exippy> i have some networking issues on the host, and i'd like to disable juju till i fix this
<exippy> i might have tinkered a bit too much, resulting in some sort of conflict between the internal and external network
<jam> exippy: IIRC jujud is started from /etc/init/juju-$USER-local.conf or something close to that
<jam> if you are just trying to make the LXC instances not start
<jam> I think there is a different flag in the LXC configuration about what should auto-start
<jam> but I think you can play around with the LXC tools to find something about autostart. I'm not personally an expert on it.
<exippy> i commented out the exec line in that script, but i still see the lxc instances starting in the logs
<jam> but if it is an LXC thing, it would be "lxc-$SOMETHING" and tab completion should give some hints
<jam> exippy: the LXC instances are started by LXC itself
<jam> so you have to set them up as "no autostart"
<exippy> ok
<exippy> thank u jam, i'll see if i can find how to disable this
<jam> exippy: this is how we enabled it: https://code.launchpad.net/~waigani/juju-core/lxc-trusty-autostart/+merge/202974
<jam> exippy: so "/etc/lxc/auto" if you are on Trusty, otherwise it is "lxc.start.auto = 0" in the individual config files
<exippy> ok i'll remove that file and see how that goes
<jam> exippy: /etc/lxc/auto is a directory with symlinks in it to each container
<jam> so remove the symlinks and not the dir itself
<exippy> would this prevent the creation of lxc virtual network?
<jam> exippy: I don't think touching these will affect lxcbr0
<exippy> hmm is it normal that i don't see /etc/lxc/auto on trusty?
<jam> exippy: given that you see the containers autostarting it seems strange to me
<jam> can you do "sudo lxc-ls âfancy" and see what it says?
<exippy> unfortunately i only have access to the file system
<exippy> through a rescue kvm
<exippy> well thank u anyway, at least i know what i'm looking for
<tedg> lazyPower, hey, heard you are working on an owncloud bundle. Is it ready to use?
<_mup_> Bug #1316185 was filed: juju bootstrap hangs on Azure <pyjuju:New> <https://launchpad.net/bugs/1316185>
<d3lxa> is there a way to restart jujud or mongodb? juju status says timeout and it's due to overloaded mongodb thing it seems
<jam> d3lxa: restarting mongodb would cause the jujud process to restart itself, though I don't know that it will actually help you
<jam> there should be a "juju-db" service, IIRC
<d3lxa> jam: maybe? I have multiple envs, just want to restart jujud for a specific env
<jam> d3lxa: the service is running in your environment, not on your local machine (unless you are running multiple local environments)
<gnuoy`> is the option to get juju status to create a dot file still a thing ? juju help status seems to suggest not
<d3lxa> jam: so you mean on the cloud, I could restart mongodb or something?
<jam> gnuoy`: juju status by itself cannot create dot output (afaik)
<jam> d3lxa: right, on machine-0 on each environment
<gnuoy`> jam, it used be a thing though didn't it (maybe pyjuju)? or am I going crazy ?
<jam> gnuoy`: I don't know pyjuju very well, it could have been
<gnuoy`> ack, thanks
<d3lxa> jam: I could try to kill the mongodb instance there and restart with the same command line (the password is xxxxx, i doubt thatâ¦)?
<d3lxa> I don't know if destroying the env would work then
<d3lxa> okâ¦ I'm stuck with juju I can't destroy the env
<_benoit_> any juju dev here ? I want to implement a new EC2 compatible provider in juju and want to know If the patches would be welcome
<rick_h_> _benoit_: new providers are always welcome. I lot of folks are away today catching up post sprint.
<rick_h_> _benoit_: I think an email to the juju list would be a great start
<_benoit_> rick_h_: thanks for the answer I will post to the list
<rick_h_> _benoit_: awesome, I look forward to seeing the discussion on it
<lazyPower> tedg: Its really close. There are some papercuts with it that jose has been working through.
<tedg> lazyPower, Papercuts for the small instance case or the large instance case? I'm looking personal.
 * tedg is a big guy, but likes small servers
<lazyPower> tedg: it needs SSL Certificate generation. I'm running it on a $10 Digital Ocean instance
<tedg> lazyPower, Ah, cool. If you could cut and paste that into the bip charm, that'd be cool too :-)
<lazyPower> tedg: i've actually got a blog post covering the howto 1 sec
<lazyPower> http://blog.dasroot.net/replacing-u1-with-owncloud-on-digital-ocean/
 * tedg is reading
<tedg> lazyPower, Are you using the $10 instance for the disk space or for the CPU/RAM ?
<lazyPower> Both, im' hulk smashing everything on a single instance.
<lazyPower> bootstrap + owncloud
<sarnold> on a $10 instance? nice
<tedg> K
<lazyPower> tedg: if you follow that process, let me know how it works for you. i'm doing pretty well with the setup as a single user.
<lazyPower> i wouldn't recommend that setup for multi-users though.
<lazyPower> it gets a bit pokey when doing n changes on n machines. in my use case, several gb file changes, across 4 clients.
<tedg> lazyPower, I'm looking more for shared calendars and addressbooks with my wife, so I'm not too worried about pokey. Don't think that'll be taxing.
<lazyPower> yeah, the only downside is the fact you have to purchase caldav addons and carddav through the play store on android phones
<lazyPower> i dont have an ios device to test with, so YMMV if you're an iphone user. however the entire stack as a whole works pretty well
<tedg> lazyPower, I don't plan on using Android for long, if mhall119 would finish a mail program for me ;-)
<lazyPower> heh :) nice
<mhall119> tedg: I'm not writing anything :-P
<mhall119> tedg: you can help us though, /join #trojita
 * tedg gives up and buys a Blackberry phone
<mhall119> that's a sound investment
<tedg> It keeps me from getting distracted with apps.
<mhall119> heh
<cory_fu> jose: Hey, are you around?
<jose> o/
<jose> cory_fu: here I am!
<jose> sorry, just got back from an exam
<cory_fu> No worries.  Sorry I was less responsive last week, regarding the tracks merge proposal.  I was at a sprint.  :)
<cory_fu> I was wondering if you had any ideas about resolving the upstream gem issue in the tracks MP?
<cory_fu> I'd like to be able to +1 that, since your changes look fine, but I feel like I need to be able to deploy it to do so
<jose> yeah, same here, I'd need to investigate what's really going on
<jose> I have some time in like 15, I need to drop a package on the mail and maybe we can work on it?
<cory_fu> Sure thing
<jose> I'll leave everything bootstrapping and ready to debug
<hackedbellini> hi guys
<hackedbellini> anyone here knows how can I change the branch a service is using, lets say, from launchpad to a local one? I made some modifications on my postgresql charm and I want to make my service use my local fork without having to deploy it again
<hackedbellini> not my postgresql charm, but the one here: https://manage.jujucharms.com/charms/precise/postgresql
<hackedbellini> I forked it and did some modifications which I want to use
<jose> hackedbellini: `juju deploy --repository=charms local:postgresql` where charms is the directory containing a folder called 'precise' and 'precise' contains the charm
<hackedbellini> jose: I used that to deploy a local repository. By doing that, since the service already exists, will it override it in the way I said above (keep the units and just change the charm path to do upgrades)?
<jose> hackedbellini: well, I don't think you can upgrade it - it would only pull changes from the repository it was originally created
<jose> though you can leave that unit and rename the unit with the local branch deployment to psql maybe?
<jose> just put 'psql' or whatever you want at the end (after local:postgresql)
<hackedbellini> jose: hrmm, thanks. I'll give it a try :)
<jose> np :)
<jose> let us know how it went
<jose> cory_fu: I have to do some stuff, but I think I'm about to fix the error. if I get to find it I'll push - otherwise I'll ping you tomorrow?
<cory_fu> jose: Sounds good.  Thanks for looking into that.  :)
<cory_fu> I would have tried my hand at it, but I know less than nothing about ruby.  :p
<qhartman_too> I'm looking to consolidate my maas and juju machines into one host; two is overkill. Is there a clean way to bootstrap juju into an lxc, but have future juju instantiated instances be on MAAS bare metal?
<qhartman_too> I've found some information on doing everything inside lxc containers, but not a blend, and I'm not super familiar with the guts of what's going on, so was hoping for some pointers to docs I may ahve missed
#juju 2014-05-06
<jose> oooooooh, have we now got a smart bot?
<marcoceppi_> jose: ?
<jose> marcoceppi_: I see a bot has filed two bugs
<marcoceppi_> jose: where?
<jose> https://bugs.launchpad.net/charms/+bug/1316361
<_mup_> Bug #1316361: Add nagios connection tests to postgresql charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1316361>
<jose> https://bugs.launchpad.net/charms/+bug/1316362
<_mup_> Bug #1316362: Add test for held package behavior in postgresql charm  <Juju Charms Collection:New> <https://launchpad.net/bugs/1316362>
<jose> psql charm
<jose> the CI bot
<marcoceppi_> jose: no idea where that thing is running or what it's doing
<jose> from the name, I
<jose> I'd say it's the CI bot, but I cannot assure anything
<jose> maybe ask bradm? (vanguard)
<_sEBAs_> hi o/
<_sEBAs_> was thinking the other day, there's a "local" env type for juju, but what about "remote" one?
<_sEBAs_> thats possible today?
<_sEBAs_> uuuhh... so quiet
<_sEBAs_> :P
<marcoceppi_> _sEBAs_: well, by definition all other environments are remotes
<marcoceppi_> _sEBAs_: but I think what you're talking about is the manual provider
<marcoceppi_> https://juju.ubuntu.com/docs/config-manual.html
<_sEBAs_> marcoceppi_: manual env type I would have to provide each machine
<_sEBAs_> right?
<_sEBAs_> marcoceppi_: in a local type, juju provide them creating containers
<_sEBAs_> the problem is that for startups, amazon and others is a little expensive
<_sEBAs_> so buying a dedicated server is less than 100 bucks, and you can have more than 10 machines for dev and prod purpose
<_sEBAs_> and openstack is not a walk in the park to install in ONE server :P
<lazyPower> _sEBAs_: correct. manual is as the name states: a manual process.
<_sEBAs_> lazyPower: exactly
<lazyPower> _sEBAs_: however with some clever charming, you could utilize a single server rather efficiently. Most of the charms in the charm store are aimed at single purpose machines for scale out usage.
<lazyPower> but if you want to build a subordinate to deploy services, eg: your drupal submission - to bolt into a pre-existing apache2 deployment, you can get multi-tennancy fairly quickly.
<lazyPower> just make sure the deployment path, and domain name + ssl configuration is in the charm options.
<_sEBAs_> hmmm
<lazyPower> _sEBAs_: also, did you see that there is another drupal submission to the store using DRUSH as the deployment and configuration mechanism?
<_sEBAs_> lazyPower: yes!!
<_sEBAs_> I'm using drush to deploy the first drupal install
<lazyPower> I thought that would excite you :) Having done a few drupal sites, i was impressed by drush when I was building stuff manually
<_sEBAs_> but not for getting more configurations hover drupal
<lazyPower> now that juju has a nice drush wrapper, i'm really impressed with the overall extensibility of that charm.
<_sEBAs_> lazyPower: yeah thanks!
<_sEBAs_> nice to know that lazyPower
<lazyPower> My thought for improvement would be adding a subordinate to use drush to export/backup the site
<lazyPower> or build a backup server charm with relations that install a cron job to do that for you
<_sEBAs_> hmm thats interesting
<lazyPower> either approach would be good
<_sEBAs_> subordinate charms are in my list of study already :D
<_sEBAs_> lazyPower: there's a lot of thoughts about charms and their types
<_sEBAs_> for example
<_sEBAs_> each project haves some specific libraries installed, and other things
<lazyPower> _sEBAs_: I'm not sure I follow, is this with regard to drupal? or the charm ecosystem as a whole?
<_sEBAs_> so i don't like the ideia of "cloning" the drupal charm and call it with the name of the project
<_sEBAs_> lazyPower: i'm worry about how to extend things
<_sEBAs_> and not repeat code for tasks like install and configure drupal with nginx, etc...
<jose> hello, mr. lazy
<lazyPower> _sEBAs_: idempotency guards would prevent that
<lazyPower> apt is idempotent by default, so no issue w/ the packages
<_sEBAs_> lazyPower: sorry, my english is limited and a little rusty :P
<_sEBAs_> but its not only packages
<_sEBAs_> lets say "tasks"
<lazyPower> and unless you're getting crazy with PHP application pools - the real 'meat' of the charm is just the cloning of the Drupal source, and adding a vhost - which is what you would do as an admin anyway.
<lazyPower> jose: o/
<jose> lazyPower: got some time now?
<lazyPower> jose: to do?
<_sEBAs_> lazyPower: yeah! but thats the thing ;) Juju charms is not only for ops
<_sEBAs_> its almost perfect for devops as well
<jose> lazyPower: fix that messy owncloud test - I want to get changes in the store now! :P
<lazyPower> _sEBAs_: thats exactly what juju's tagline is 'devops distilled' ;)
<lazyPower> jose: ah, i didn't work today, ping me tomorrow (the tomorrow bug is still in effect)
<_sEBAs_> yeah!! I know! hehe thats why Im crazy about juju right now
<jose> haha, ack
<jose> _sEBAs_: and even non-tech people understand how it works :)
<lazyPower> jose: sorry man :( I should have known i'd be taking the day off with all the jet lag + personal crap i have going on.
<_sEBAs_> yeah! exactly
<lazyPower> but if you poke me tomorrow i'll take a look at the tests if i'm around.
<jose> lazyPower: it's good - it's been a messy day for me too. had a super exciting exam today!
<lazyPower> _sEBAs_: the onus of ensuring tasks only occur when they need to are on the charm developer + interested community members. This is why the charm store policy has a requirement that hooks are idempotent so they dont repeat actions that have already happened. Maybe i'm being daft but I dont understand the concern you're bringing up.
<jose> _sEBAs_: if you prefer to speak Spanish, let me know :)
<_sEBAs_> jose: thanks!!! but I need to exercise my english
<jose> np :)
<_sEBAs_> lazyPower: I have to know that do you mean with idempotent, little search will solve that
<jose> _sEBAs_: it means that if something is set, it need to be changeable, that things will not get hardcoded or locked
<_sEBAs_> lazyPower: oohh i get it
<lazyPower> _sEBAs_: http://en.wikipedia.org/wiki/Idempotence
<_sEBAs_> yeah! exactly
<lazyPower> eg: if i set a password at deploy, and the "task" sets /etc/myapp/somepassword.cfg - if that password has not changed, the hook should not touch /etc/myapp/somepassword.cfg
<_sEBAs_> lazyPower: thanks :P
<_sEBAs_> yeah, state
<lazyPower> however, if i change that password - update the configuration file.
<_sEBAs_> yes, and that is one of the biggest challenges of charm developing (for me)
<lazyPower> _sEBAs_: Juju wraps several configuration management tools that have solved this problem for us. Ansible, SaltStack, Chef and Puppet are four good examples that we have charms leveraging them.
<lazyPower> tehre are also incoming changes to charmhelpers that will assist you in the actual configuration value management from tvansteenburgh
<_sEBAs_> thats why I'm starting to wrote the drupal charm in ansible
<lazyPower> if you want to take a pure python approach
<_sEBAs_> yes! lazyPower I learned a lot reading the mysql charm
<_sEBAs_> and the ruby one with chef
<lazyPower> the rails charm is really good - it needs a bit of love
<jose> much ruby such gems wow
<lazyPower> and chef is a beast... its taking a sledgehammer to a 10 penny nail approach.
<_sEBAs_> yeah I sow a maintainers call
<_sEBAs_> hahaha @lazyPower
<_sEBAs_> yeah
<_sEBAs_> so great!, because thats where i wanna to get with this talk
<Azendale> Does anyone have recommendations for the best guide to try to set up openstack in a High Availability configuration with Juju?
<lazyPower> but _sEBAs_, if you need help / review of your charm progress for idempotency, feel free to submit a charm review request for 'as is' - and someone on the charmers team will give it a good reviwe for you and help line out any issues you may be having.
<_sEBAs_> so talking about my concern about DRY avoiding repeating code hover charms
<_sEBAs_> lazyPower: already did that ;)
<_sEBAs_> lazyPower: https://bugs.launchpad.net/bugs/1315428
<_mup_> Bug #1315428: Review needed: Drupal Charm <drupal> <Juju Charms Collection:New> <https://launchpad.net/bugs/1315428>
<jose> _sEBAs_: as far as I know, it needs to be in a bzr branch?
<jose> and you need to subscribe the charmers team
<lazyPower> _sEBAs_: https://juju.ubuntu.com/docs/authors-charm-store.html
<lazyPower> there's a policy for how to get your charm in the review queue
<_sEBAs_> jorge castro, tould me I didn't need it, just jump hover the step #9 of the guide
<lazyPower> and yeah, we're working on moving stuff over to github and use both GH and LP
<lazyPower> no ETA on that - so dont ask :P
<lazyPower> because i have no answers
<_sEBAs_> jose: didn't know about that :(
<jose> lazyPower: oh, oh, I know when it's going to be ready!
<_sEBAs_> lazyPower: glad to know!!
<lazyPower> _sEBAs_: so long as you followed the directions in the charm store doc and omitted the launchpad branch - but inserted another repository location
<lazyPower> we'll be fine.
<jose> soonâ¢
<_sEBAs_> hehehe
<lazyPower> jose: you're absolutely encouragable you know that?
<lazyPower> :P
<jose> yep, and if you want a more precise approach it'll be ready soonâ¢Â©
<_sEBAs_> glad to know, because theres a lot of people that deploy drupal with pour configurations and techs
<lazyPower> _sEBAs_: if you want to be a juju ambassador to the drupal community, let me know when you're ready and i'll republish/reblog/repost your efforts and help syndicate.
<lazyPower> I know several people that use drupal every day
<_sEBAs_> and that charm is using a lot of the experience I and my company haves, the community needs that, with transparency with juju :)
<_sEBAs_> lazyPower: nice!! I would be really honored :D
<lazyPower> de nada my friend. I appreciate your efforts to build quality stuff and excitement for juju :)
<_sEBAs_> actually, I'm going tomorrow to the FISL in Porto Alegre, Brasil
<_sEBAs_> and I'm going to talk(again) about juju and devops principles
<lazyPower> Nice!
<lazyPower> Could you link me your slide deq / talk when its done?
<_sEBAs_> yeah! we are organizing the Drupal Camp over there
<_sEBAs_> yeah ofcourse, theres on, in spanish I did in Peru a few months a go
<_sEBAs_> http://slides.com/sebastianferrari/desenvolvimento-drupal-em-equipe
<lazyPower> Nice
<lazyPower> I see your slides, and raise you my slides in the same framework
<lazyPower> http://dasroot.net/presentations/wplug/#/
<jose> _sEBAs_: and why didn't you let me know so I could be there?
<_sEBAs_> actually, i arrange a charm school in the Drupal Camp of Peru, where marcoceppi_ show us and answer a lot of questions :)
<jose> why wasn't I aware of that?
<jose> why didn't I go?!
<lazyPower> _sEBAs_: i was in that charm school :)
<jose> I'm mad :(
<lazyPower> you had a room with like, 12 developers
<lazyPower> and frequent stops for translation
<_sEBAs_> heheh jose i'm knowing this community now! hehe
<jose> lazyPower: you guys should've let me know it was happening and I would've taken swag
<_sEBAs_> oohhhhh lazyPower didn't know so sorry
<_sEBAs_> hehe
<lazyPower> De nada! no reason to apologize, that was a nice trip down memory lane :)
<_sEBAs_> yeah!
<lazyPower> jose: we weren't speaking yet, i'll put on my psychic helmet and send you some brain waves in the past. maybe we'll create a paradox where you get to go to drupal camp
<lazyPower> this was ~ my 2nd week with canonical when that happened.
<_sEBAs_> so i'm evangelizing juju around the devops principles as lean tools
<_sEBAs_> hahahaha
<jose> well, next time I'll take swag
<jose> I *was* actually thinking on organizing a charm school
<_sEBAs_> we can arrange more
<_sEBAs_> :)
<_sEBAs_> even in the FISL
<jose> still need to find a place and the right time
<jose> I don't think I can go to Brazil this weekend :P
<_sEBAs_> do you know what is FISL right?
<jose> I do :)
<_sEBAs_> nice!
<_sEBAs_> so we can do a nice demonstration
<_sEBAs_> and blow up some brains out!!
<lazyPower> _sEBAs_: the slides are great. good info packed in here
<_sEBAs_> lazyPower: thanks!
<_sEBAs_> i'm trying to get my company 100% devops
<_sEBAs_> but it's hard work
<lazyPower> _sEBAs_: selling culture is difficult.
<_sEBAs_> exactly !!!
<_sEBAs_> thats the main thing you know...
<_sEBAs_> you can have more tools than you can manage, but without culture the hole can folldown
<lazyPower> distill away complexity one piece at a time
<lazyPower> thats the best part of juju
<lazyPower> use as much or as little as you need
<_sEBAs_> yes
<_sEBAs_> talking about that, we are working in a "charm factory" using ansible
<_sEBAs_> so imaging picking ansible roles, to make your charm
<_sEBAs_> we are in architecture steps yet
<lazyPower> _sEBAs_: also  - with your community consisting of such a diverse range of platforms for dev (i'm looking at you mac users) dont forget we have vagrant images to help
<lazyPower> http://blog.dasroot.net/writing-juju-charms-on-osx/
<_sEBAs_> I would love to know what are your thoughts about that
<_sEBAs_> lazyPower: Im with mac
<lazyPower> _sEBAs_: roles are good when they are on the context of a relationship, and should exercise opinionated configurations dependent on the scope of the relationships.
<lazyPower> but if you're not careful they can stomp on one another with unintended side effects, otherwise roles are a great way to extend a charm for opinionated deployments
<_sEBAs_> so i get to the point to discover that the VagrantFile needs an update, those python scripts that install and configure the juju
<_sEBAs_> I think can be more open to people to help to build images with juju and juju gui ready to work
<lazyPower> eg: hardened mode (only core, no cruft, tuned for safety), performance (tuned PHP stack, optimized caching installed)
<lazyPower> _sEBAs_: well they just got an update last monday
<_sEBAs_> lazyPower: get it, thanks for the advice
<lazyPower> they were in dodgy shape over the last month during the 14.04 release rush. Other priorities came up - and some things changed out from underneath the ground. I have a work item task to get those vagrant boxes under CI
<lazyPower> _sEBAs_: but yeah - good idea with roles taking care of the application 'profile' to speak.
<_sEBAs_> nice!!!
<_sEBAs_> lazyPower: glad to know :)
<_sEBAs_> why do we need those redirecting scripts into the box ?
<_sEBAs_> is it for the juju-gui ?
<lazyPower> _sEBAs_: there are 2 layers of redirect - one moment while i compose this
<_sEBAs_> hehe ok
<lazyPower> the first layer of redirect is with regard to the juju gui - that is normally deployed into an LXC container. It has to communicate with the bootstrap node. At present the bootstrap node lives on the host that is producing the LXC containers
<lazyPower> so, thats layer 1 - to get you tot he GUI
<lazyPower> the second layer, with SSHUTTLE is to get you a VPN into your LXC environment in the VM so you can interact with the services on your host computer, hosting the virtual machine (eg, deploy drupal in vagrant, you're routing from host => vm => lxc)
<lazyPower> thats layer 2
<lazyPower> and if there's any other magic going on in between, i'm sorry i omitted it - but its late :P
<_sEBAs_> hehe get it
<lazyPower> i left out some bits about the gui, so glad you followed :)
<_sEBAs_> the first level that came from nothing for me
<lazyPower> its specific ot the UX of the vagrant box. we could have you sshuttle to the GUI, but wouldn't it be nice to just hit localhost:6080 and have the gui? we thought so.
<lazyPower> so thats why that python redirect script is in cloudinit
<_sEBAs_> because i was experiencing some odd issues with that
<lazyPower> yeah... thats the oddities i was talking about that stemmed from about 3 to 4 weeks ago
<_sEBAs_> yeah of course!
<lazyPower> i was going to have a charm school and ran into those issues - so i was madly macguyvering a jujubox with packer prior to the charm school
<lazyPower> instead of telling people how to build hteir own juju vagrant image, we punted and did juju run instead
<_sEBAs_> haha
<lazyPower> where jose got to put on his charm for the world and i spoke crazy fast about something thats insanely handy with CI
<lazyPower> so, _sEBAs_, your next mission should you choose to accept it, is to get juju run doing automated deployments from jenkins ;)
<_sEBAs_> yeah i was getting mad these days with that, so I made another vagrantfile
<_sEBAs_> humm yeah, actually thats where I wanna get, after making provisioning and CM easy for the devs
<_sEBAs_> then jenkins is the next step!
<_sEBAs_> for example
<lazyPower> _sEBAs_: WRT your question about openstack - an option for you  would be buy a beefy server
<lazyPower> deploy MAAS region-controller & MAAS cluster-controller to the host
<lazyPower> and use that to orchestrate KVM machines
<_sEBAs_> jenkins can deploy a hole bundle, just to run all the BDD tests
<lazyPower> the setup took me about 3 hours on my first run through.
<lazyPower> the maas provider in juju is stellar
<_sEBAs_> hmmm nice that you bring that up
<lazyPower> i use that to keep my cloud costs down and orchestrate a 'juju lab' in my closet.
<_sEBAs_> hmmm thats what I want
<_sEBAs_> so let me see
<lazyPower> i'm running a quad core, 12GB of ram (which is in need of an upgrade) and i can orchestrate ~ 13 VM instances on it before i see the host slow down to a crawl.
<_sEBAs_> if i get your right
<lazyPower> you'll want to pay special attention to the networking configuration of this though _sEBAs_
<lazyPower> you need a server with 2 nics
<_sEBAs_> yeah, roger that
<lazyPower> that way you can do ethernet bridging an dkeep a management network, and a public networking (with a bridge that vlan's into your KVM instances)
<_sEBAs_> so I dont need a public ip for every kvm instances
<_sEBAs_> I was trying to install openstack with the devstack and all
<_sEBAs_> docker and lxc worked fine, but
<_sEBAs_> i was having some issue with the swift proxy service
<_sEBAs_> wasn't working right, didn't know what a hell was that
<_sEBAs_> I was going to try with the new icehouse version to see what happen
<lazyPower> _sEBAs_: you'll need a reverse proxy daemon sitting in front of all that
<lazyPower> but its completely do-able.
<_sEBAs_> yes
<_sEBAs_> i was using hipache
<_sEBAs_> but, i needed more than 80/443 ports
<_sEBAs_> i didn't even get it to work, meanwhile i was using sshuttle (not proud about it Â¬Â¬)
<_sEBAs_> in order to juju ssh into the instances and all...
<lazyPower> _sEBAs_: Ah, yeah. Forwarding more than web traffic over that setup will be tricky unless you deploy a virtual router, and push all your traffic there.
<lazyPower> which introduced SPOF
<_sEBAs_> hmmm yeah, i need to study a little more on that
<lazyPower> let me know what you come up with
<lazyPower> i'm interested to see what you learn in this process :)
<_sEBAs_> thank the tip lazyPower
<_sEBAs_> *thanks
<_sEBAs_> :)
<lazyPower> np _sEBAs_, my pleasure
<_sEBAs_> nice to know that theres a nice community over here :)
<_sEBAs_> the other day i wen to an event about cloud solutions, so some hosting and others organizations that haves data centers in-company
<_sEBAs_> were there
<_sEBAs_> but
<_sEBAs_> nobody even know about linux containers, so juju was out of the table
<_sEBAs_> the bright side of that is, everyone went crazy about juju and all...
<lazyPower> Its really brilliant with public clouds...
<_sEBAs_> yeah
<lazyPower> when I go to demos, i usually spin up ~ 18 hosts on AWS or HPCloud
<lazyPower> and dive into the machines to show its really doing something and not just faking it out with the GUI
<_sEBAs_> hehe nice
<_sEBAs_> hahaha
<_sEBAs_> the other day one client ask me, "but that is real, right?"
<_sEBAs_> then i show it the drupal running and all
<_sEBAs_> go mad!!
<_sEBAs_> lazyPower and jose thanks for your advices, i'm glad that i talked with you guys
<lazyPower> (ã) yeah its kind of magical.
<_sEBAs_> i'm going to make me some dinner now, and thats something that juju cant do it
<jose> enjoy!
<jose> maybe we'll have 'juju deploy food' in the future
<_sEBAs_> hehe yeah!
<lazyPower> jose: scope creep ;)
<_sEBAs_> theres a juju that would it be nice to make me food, here in brasil if you only search "juju"
<_sEBAs_> every one that searches for juju here when i talk about it, the results are stunning hehe
<_sEBAs_> well thats it, see you next time guys :)
<silverPony> Hello there!  Is it possible ot re-attach the node that was previously part of juju, without comissioning?
<AJ_> Hi guys, I have some question. We are using Juju on MAAS with multiple environments
<AJ_> If I wanna ssh into machine it gives error: juju ssh 1 -e maas
<AJ_> error code is "ERROR control-bucket: expected string, got nothing"
<AJ_> Any ideas?
<Tug> AJ_, are you using juju-quickstart ?
<silverPony> Hello there!  Is it possible ot re-attach the node that was previously part of juju, without comissioning?
<marcoceppi_> silverPony: in maas?
<silverPony> well, as soon as i juju remove-machine
<silverPony> do i have to commission it in maas to bring back?
<frankban> rbasak: morning
<jose> ohai lazyPower
<lazyPower> o/
<jose> all going good?
<lazyPower> yep
<jose> awesome :)
<jose> I was wondering if you can give me a hand with these tests now
<_sEBAs__> hi lazyPower and jose :)
<jose> hello, _sEBAs__ :)
<_sEBAs__> hey jose now that i get it, you are from lima, peru hehe
<jose> yes, I am :)
<jose> did you google me? :P
<_sEBAs__> i'm from uruguay :)
<jose> awesome to hear
<jose> now I know I'm definitely not the only juju user in south america \o/
<_sEBAs__> sow a name of bug subscriber "JosÃ© ...."
<_sEBAs__> so a i figured out
<_sEBAs__> hehe
<_sEBAs__> hahaha
<_sEBAs__> globo.com use juju too I think
<jose> :P
<_sEBAs__> they have a deployment tool https://github.com/tsuru/tsuru
<jose> yeah, I think I'm subscribed to all charms bugs
<jose> oh, that's cool!
<lazyPower> jose: link to branch in question?
<jose> lazyPower: https://code.launchpad.net/~jose/charms/precise/owncloud/port-change+repo+ssl-support
<_sEBAs__> hey lazyPower awesome slides man!! (you pass me the link, but I didn't see it at the time Â¬Â¬)
<lazyPower> Thanks _sEBAs__
<lazyPower> GPL 3'd - feel free to chop and remix. They are up on the presentation github
<lazyPower> https://github.com/juju/presentations
<_sEBAs__> awesome !
<lazyPower> _sEBAs__: if you want to include your presentation feel free to issue a MP
<lazyPower> we'll get to it as soon as we can
<_sEBAs__> great!! we are working in an inforgraphic about devops using juju
<lazyPower> nice!
<lazyPower> please link me when that's complete. I'd like to see that
<_sEBAs__> of course! as soon I get the first RC, i will paste the link here :)
<lazyPower> jose: running the tests now
<jose> lazyPower: ^c that, it'll give you an error as it is because I try to define the domain before d.setup
<jose> and calling d.sentry.unit['haproxy/0'].info['public-address
<lazyPower> jose: ack. I'm going to let it run and collect the output
<jose> ']
<jose> ok!
 * jose is taking a look at the tracks errors (cc. cory_fu)
<cory_fu> Thanks.  From my reading of the ticket you linked, it sounds like the version that breaks is actually bundled with tracks, which makes me wonder how the charm ever worked with that version
<jose> well, it's not working as is on the store :)
<jose> I'm trying to update to a newer version
<jose> cory_fu: whoops, tracks 2.2 (fixed one) requires ruby >= 1.9.2, it'll need to be compiled
<lazyPower> jose: there's a PPA for that
<jose> oh really?
<lazyPower> unless you *really* want to go the compilation route, then use RBENV plz
<jose> lazyPower: do you have a link for it?
<lazyPower> https://launchpad.net/~brightbox/+archive/ruby-ng
<lazyPower> make sure you update the readme that it's using a PPA if you go that route
<jose> will do, thank you
<lazyPower> gah it looks like they haven't updated the ppa with trusty support
<lazyPower> >.> stinking ppa's
<lazyPower> oh wait, they have. disregard
<jose> :P
<jose> backports ftw
<lazyPower> jose: is this consistent with what you've seen? http://paste.ubuntu.com/7405034/
<jose> correct, sit
<jose> sir*
<lazyPower> tvansteenburgh1: have you seen this? http://paste.ubuntu.com/7405034/
<tvansteenburgh1> lazyPower: i have now
<jose> :P
<lazyPower> tvansteenburgh: gnarly. i'm thinking its choking whenb uilding the deployment map
<tvansteenburgh> lazyPower: are there non-ascii chars in the metadata.yaml?
 * jose checks
<lazyPower> tvansteenburgh: amulet is wiping the yaml before i can check it
<jose> tvansteenburgh: there is, yes, an Ã©
<jose> a unicode Ã©
<lazyPower> jose: wait... wat
<lazyPower> OH, in your name
<lazyPower> in the metadata
<jose> yeah
<lazyPower> jose: i'm changing your name, you will now be known as: 'charmbot 5000'
<tvansteenburgh> jose, lazyPower: if you wanna file a bug i'll fix it
 * lazyPower points jose to the bug tracker so his name can stay in teh yaml
<jose> tvansteenburgh: against what? amulet?
<lazyPower> :P
<tvansteenburgh> but for now the quick path forward is to change jose's name :P
<tvansteenburgh> jose: amulet, yes
<jose> Jose Antonio Rey or CharmBot 5000 will work :P
 * jose goes and files the bug
<jose> tvansteenburgh: bug 1316656
<tvansteenburgh> jose: thanks
<jose> bug #1316656
<jose> _mup_ START WORKING!
<jose> _mup_: ping
<lazyPower> jose: paste the url to the bug
<jose> the URL for the pastebin?
<lazyPower> nope, bug
<jose> https://bugs.launchpad.net/amulet/+bug/1316656
<lazyPower> yep he's borked
 * jose gives _mup_ a revive cookie
<lazyPower> tvansteenburgh: looks like amulet syntax changed with a MP 11 days ago.
<lazyPower> whats the new and improved way to target units in amulet?
<tvansteenburgh> lazyPower: i dunno anything about that.
<jose> marcoceppi_ is the amulet master
<jose> according to LP
<tvansteenburgh> lazyPower: i submitted and MP to make d.add_unit() work properly
<lazyPower> jose: i'm aware but tvansteenburgh did some edits to this.
<lazyPower> https://github.com/marcoceppi/amulet/commits/master/amulet/sentry.py
<jose> oh got it
<lazyPower> which means we just broke a ton of tests we had written
<lazyPower> unless this test was wrong to begin with
<tvansteenburgh> lazyPower: my commits just fix a bug with add_unit()
<lazyPower> tvansteenburgh: too late, i git-blamed you
<lazyPower> :P
<tvansteenburgh> lol
<lazyPower> <3
<jose> urgh, I give up with tracks
 * jose hates Ruby
<jose> cory_fu: after updating to 2.1 or 1.9.3 it gives a redcloth error
<jose> not sure what that is
<lazyPower> jose: a gem
<lazyPower> its a markdown generator by github
<lazyPower> s/generator/interpreter/
<jose> when trying to install it it gives ANOTHER error
<lazyPower> whats the error?
<jose> ERROR: Failed to build gem native extension.
<lazyPower> do you have build-essential installed?
<jose> yes
<lazyPower> pastebin me the full trace
<jose> http://paste.ubuntu.com/7405198/
<lazyPower> jose: you need to install the ruby-dev package for the flavor you installed
<lazyPower> its looking for headers that are non existant
<jose> blargh, thank you
 * jose still hates ruby and ruby on rails
<jose> don't even mention ruby on trains
<lazyPower> it's really not *that* bad
<lazyPower> but i'll let you continue to hate @ it.
<jose> same error after installing -dev
<jose> oh, it was 1.9.1-dev
<jose> w0ot, works!
<cory_fu> Awesome
<jose> tracks... not yet :P
<jose> still installing!
<cory_fu> Aw
<lazyPower> OH
<lazyPower> man, i missed line 26, jose
<lazyPower> you cant get information from the unit before its deployed
<lazyPower> thats why the sentry.unit.info object isn't working
<lazyPower> there's no API server/sentry deployed until d.setup() is called
 * tvansteenburgh is exonerated
<jose> that's what I was telling you
<lazyPower> jose: @!%@#^#@
<jose> those lines need to be moved *after* d.setup()
<jose> I knew that
<lazyPower> why you do this to me?!
<jose> :P
 * marcoceppi_ considers better error messaging
<jose> ERROR: Jose didn't mention that lines had to be moved. RESULT:  â
 * lazyPower hugs jose with a bat
 * lazyPower repeatedly
<lazyPower> :P
<lazyPower> naw, you're good i missed that
<lazyPower> you did tell me to move stuff
<lazyPower> so, with that in mind - we need to set the domain post deployment
<jose> correct
<jose> I'll try the tests with my name without the Ã© after I'm done with this tracks stuff
<jose> *almost* done
<lazyPower> jose: that part works
<jose> which part?
<lazyPower> i'm looking at the amulet stuff to remind myself how to set config post deployment
<lazyPower> removing the e
<lazyPower> unicode, e
<jose> oh, it's not d.configure?
<lazyPower> i'm pretty sure that was patched to support post deploymetn configuration with the 1.4 series
<lazyPower> but i dont remember. i'm fishing up teh bug
<jose> ok!
<lazyPower> https://bugs.launchpad.net/amulet/+bug/1270174
<_mup_> Bug #1270174: Post deployment commands <Amulet:Fix Released by marcoceppi> <https://launchpad.net/bugs/1270174>
<lazyPower> wb mup
<jose> \o/
<jose> lazyPower: w0ot, another ruby error! http://paste.ubuntu.com/7405288/
<jose> even after the gem is installed
<lazyPower> jose: the bundle is missing the mysql2 gem
<lazyPower> thats an old school ruby error
<jose> but it did install it...
<jose> ooh
<lazyPower> its that or the db configuration file is referencing the mysql gem syntax, and should be updated either/or
<jose> boom, found the error
<jose> (or at least I think so)
<lazyPower> jose: it occurs to me, you're setting the domain to the public ip of the unit. DOesn't the charm do this when no configuration is specified for domain?
<lazyPower> default to looking up the public-address and actioning with that?
<jose> lazyPower: it doesn't
<lazyPower> should probably do that, as it's a 'sane default' practice.
<jose> what happens if it's behind haproxy?
<lazyPower> it should relation-set public-address in the relationship-changed hook
<lazyPower> and haproxy will take care of the domain mapping
<jose> huh?
<lazyPower> jose: try it and see :P
<jose> will do... once I finish with this ruby thing :P
 * jose is getting bored of errors
<jose> is there a way to manually enter a hook environment when doing `juju ssh unit/#`?
<lazyPower> sinzui: good catch on https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1294202
<_mup_> Bug #1294202: reused cluster names break services. <canonical-is> <charmworld> <elasticsearch (Juju Charms Collection):New> <https://launchpad.net/bugs/1294202>
<sinzui> lazyPower, I look forward to the day I am not invited to diagnose why elasticsearch has wandered off with a index
<lazyPower> sinzui: it's on the horizon
<lazyPower> this new rev of the charm from mnelson is shaping up to be pretty solid
<jose> cory_fu: mind a PM?
<cory_fu> jose: Why not just use juju debug-hooks?
<cory_fu> No problem, PM away
<jose> yeah, I do that and call an empty 'juju set' :P
<jose> oh, nvm
<jose> still having an error :P
<lazyPower> jose: rm'ing the unicode e, and moving the d.configure line below d.setup appears to have resolved the test issue. I'm re-running it a second time with -v to ensure i didn't miss something.
<jose> lazyPower: ack, will test too after committing these changes - tracks looks to be on track now
<lazyPower> glad we got it sorted :)
<lazyPower> hi5
<jose> o/
<jose> hang on with that tracks review if anyone is doing it - needs an upstart job written and I'm working on it
<jose> and tracks is *really* good to go now
<jose> lazyPower: juju-test.conductor.100_deploy.test RESULT  : â· (â)
<magicrobotmonkey> is the nova-compute charm supposed to have networking working out of the box
<cory_fu> jose: The tracks charm now deploys fine for me, but the process seems to die and isn't listening on port 80.  Do you happen to know if tracks has a log file somewhere (not seeing it in /var/log)
<cory_fu> oh, I see it in /var/log/upstart
<jose> yeah
<jose> otherwise, /var/log/juju/agents/unit-tracks-0/charm/tracks/log
<cory_fu> Could not locate Gemfile
<cory_fu> Hrm
<jose> ooooh
<jose> know that error
<jose> looks like the upstart job isn't into the directory, but let me find a solution for this and push it
<jose> cory_fu: my bad, copied the job from another charm and didn't change the directory
<cory_fu> :)
<jose> awesome, now my pointer isn't working
<cory_fu> o_O
<jose> haha
<jose> will $JUJU_UNIT_NAME give me the name of the current machine in the format of unit/#?
<cory_fu> In the upstart job, or in a hook?
<cory_fu> I think that it will have the format name/# in the charm hooks, but it won't be available in the upstart job
<cory_fu> Oh, but you're generating the upstart conf, so you can replace it there
<jose> yeah
<jose> I'll see how can I awk that
 * jose quickly grabs lunch
<cory_fu> jose: ping me whenever you get back, please
<jose> will do
<cory_fu> Thanks.  Enjoy lunch.  :-)
<jose> thanks :)
<jose> cory_fu: back now!
<cory_fu> Hey.
<cory_fu> So, what were you saying about needing to awk the $JUJU_UNIT_NAME?
<jose> so, if you check the upstart job, it cd's into the folder where tracks has been cloned
<cory_fu> Also, I noticed that this charm is installing tracks under the $CHARM_DIR (by dint of not changing the directory in the install hook), which I'm pretty sure is a bad practice
<jose> that was what I was talking about
<jose> I can surely move it to ~/tracks, if that's better
<cory_fu> Yeah, it should definitely be moved outside of the charm dir.  What user does tracks run as?  Just root?
<jose> yes
<jose> which I think is a bad practice too?
<cory_fu> It's not ideal, but I probably wouldn't ding it for doing so.
<cory_fu> Some packages a harder to get running as non-root, but if you feel like trying, it would be better to have a tracks user
<jose> I'll try
<cory_fu> I think it should be just useradd -r tracks and then chmod -R tracks tracks
<cory_fu> er, chown -R tracks tracks
<cory_fu> lazyPower: What would be the best place for it to live, outside of the charm dir?  /var/local/tracks?  /home/ubuntu/tracks?  /home/tracks/tracks?
 * lazyPower reads
<lazyPower> cory_fu: if its getting an application user, its acceptable to put it in $HOME
<lazyPower> otherwise you're doing chown magic in /var/www, or adding them to a system group
<cory_fu> Ok, in that case, jose, you'd need -m or maybe not make the tracks user a system user
<lazyPower> use your best judgement with the application when it comes to that placement. but in practice i used $HOME for each app.
<jose> well, I'll try and do something that... works
<hackedbellini> hi. I have a postgresql unit in production. I made some changes on the charm which I need on that running unit. I'm trying to change the tracking branch for the service from the launchpad one to my local one (my local one is a fork of the launchpad one)
<hackedbellini> jose yesterday give me some tips, like trying to deploy my local charm with another service name and rename the unit, but I have no idea on how to rename that unit.
<hackedbellini> do anyone here knows what can I do? Is there an easy way to do that? Or to use jose's tip, how can I rename the unit?
<hackedbellini> note that it's in production, so I cant just destroy the unit and deploy another one
<jose> you cannot rename a unit
<jose> oh, assign another name to a unit
<jose> just append the unit name
<hackedbellini> jose: hrm, probably I misunderstood what you told yestarday. What do you mean by "append the unit name"?
<jose> like `juju deploy --repository=charms local:postgresql psql` will give the service the name psql instead of the one in the metadata
<jose> if you do `juju deploy --repository=charms local:postgresql` it will deploy it with the name postgresql
<hackedbellini> yes it will. But I don't want a new unit... I want to change the service for the already existing unit
<hackedbellini> like I said, it's running in production already and changing units is not an option atm :(
<cory_fu> I don't think you can change the name after the fact, because it would cause issues for the relations
<hackedbellini> cory_fu: I could put it in the same name, no problem. I just want to change the tracking branch of the service
<hackedbellini> like, when running 'juju upgrade-charm postgresql' it would pull from my local branch instead of the launchpad one
<cory_fu> Hrm.  marcoceppi, do you know if such a thing is possible?  ^
<cory_fu> Seems like it would be difficult, at best.
<marcoceppi> hackedbellini: yes, you can switch the source of the charm
<marcoceppi> it's not recommended but if you wanted to fork the charm locally and upgrade from the local source you can do so with the switch flag
<cory_fu> switch flag?  I don't see that in juju help deploy
<marcoceppi> juju upgrade-charm --switch --repository /path/to/local/charm-repo postgresql
<marcoceppi> cory_fu: it's an upgrade-charm command
<cory_fu> Oh, because it would be in upgrade-charm, of course
<marcoceppi> it's VERY heavy handed
<hackedbellini> marcoceppi: wow, thank you so much! You are a life savior!
<cory_fu> How so, is it heavy-handed?
<marcoceppi> you have the ability to even change the charm running, like juju upgrade-charm switch to mysql from postgresql, etc, which would probably break everything
<marcoceppi> switch is basically like the --to flag, use carefully
<lazyPower> *hulk repository smash
<thumper> jcastro, marcoceppi: can you guys chat for a minute?
<thumper> I have some questions and news
<marcoceppi> thumper: I can
<thumper> marcoceppi: https://plus.google.com/hangouts/_/gwdavp7sezmqkxxb5sfhp5ivdia?hl=en
<cory_fu> jose: Did moving the chdir to outside of the pre-start / start stanzas fix it?
<jose> I can't tell, because when I do 'start tracksapp' or 'stop tracksapp' it just hangs there
<jose> I ^c and if I try it again, it says it's already started/stopped
<cory_fu> Yeah, I think that's because of the expect fork, that I was mentioning.  I think it's sitting there waiting for the app to fork, which it never does
<jose> I also deleted it
<cory_fu> Deleted the upstart job?  Or the service?
<jose> the line :P
<jose> expect for
<jose> k
<cory_fu> Oh, I see
<jose> still hangs
<cory_fu> Can you send a pastebin of your current upstart job?
<jose> http://paste.ubuntu.com/7406987/
<cory_fu> Did you change the install hook to move the tracks app to /home/ubuntu/tracks or /home/tracks/tracks?
<jose> /home/ubuntu/tracks/
<jose> (though I should change it to /tracks/tracks/
<cory_fu> Hrm.  Seems fine to me.  Maybe someone with more experience with upstart could glance at it?
<cory_fu> Someone like lazyPower, perhaps?
<sarnold> is 'bundle' in the path at that point?
<jose> it is to be ran there
<jose> it's a ruby program
<cory_fu> jose:  Permission denied @ dir_s_mkdir - /home/tracks/tracks/tmp/cache
<cory_fu> Oh, I forgot to chown
<cory_fu> Or, no, the tmp dir didn't get chowned.
<cory_fu> Oh.  It's trying to bind to port 80 which is restricted.
<cory_fu> I think tracks might have to be run as root.  :/
<thumper> marcoceppi: DUDE!!!
<thumper> just had a great thought
<thumper> go and register juju.academy
<marcoceppi> thumper: dude, already did :)
<thumper> ha, awesome
<marcoceppi> it should map to learnjuju.com
<thumper> I read last night that there exists fart.academy
<thumper> :)
<marcoceppi> hahah
<thumper> perhaps juju.academy should be the master...
<marcoceppi> thumper: it's been updated
<marcoceppi> both juju.academy and learnjuju.com now are the same source
<marcoceppi> thumper: it was always designed to be, the links all point to juju.academy
<marcoceppi> etc
<thumper> awesome
<thumper> I should have remembered that
<thumper> I won't forget again
<marcoceppi> \o/
<lazyPower> cory_fu: never ever run a rails app as root
<lazyPower> *never*
<lazyPower> its a death sentence for system security
<jose> cory_fu: sorry, my connection died as it upgraded ffom 200KBps to 400KBps
<jose> marcoceppi: found a 'typo' (not sure if it's intentional)
<jose> lazyPower: the only way to run under port 80 is to run as root, right?
<jose> or I'm missing something
<sarnold> jose: I believe you can get the same effect by using setcap to add CAP_NET_BIND_SERVICE to your executable. it's like a mini-setuid progam, and it would probably be best to drop the capability once the socket has been bound.
<jose> sarnold: thanks, I'm looking into it
<jose> hmm, but how could I add it to a filename?
<sarnold> jose: try setcap cap_net_bind_service jose_executable
<jose> I mean, in my context
<jose> I'm trying to run a service
<jose> not sure what executable it runs
<sarnold> oh I thought you had that :) sorry
<jose> no prob :)
#juju 2014-05-07
<lazyPower> jose: you need to put it behind a proxy service, is the proper way to do it
<lazyPower> eg: setup nginx to forward to the socket or localhost:port
<lazyPower> whichever way you choose to setup the daemon
<jose> cak
<lazyPower> https://github.com/groovyobject/Ansible-Playbooks/blob/master/templates/nginx_site_proxy.j2
<jose> ack*
<jose> hmm
<lazyPower> theres an nginx vhost that would reverse proxy to a port configured daemon. in this case, a node.js app for ghost
<lazyPower> otherwise, you specify the proxy-pass to the full path of the socket file
<lazyPower> jose: also since i didn't specify, thats in a jinja2 template format
<lazyPower> the {{ }} is for variable substitution. You dont want to leave those behind. I bet you gathered that - but just in case.
<jose> tahnk you :)
<jose> I'm looking into that tomorrow, for sure
<jose> lazyPower: did you get the tests to pass? because I got some weird clock
<lazyPower> jose: that means it skipped
<lazyPower> are you still running on free tier of AWS? you'll probably need to kick up the deployment wait time
<lazyPower> if you're running on smalls, the 900 it waits by default should be plenty, and one of the tests failed. run it with the -v flag and you'll get more output to tell you why it gav eyou a skip
<jose> lazyPower: I'm running on the free tier, under micros
<lazyPower> yeah, you'll want to tune the timeout setting to something more reasonable
<jose> 1200 is default
<lazyPower> it was 900 last i checked. that my be set th 1200 and it still may not be long enough
<lazyPower> if you dont get a response messag elike "Unable to connect to MySQL" then chances are it timed out during the d.deploy phase
<lazyPower> you can test with the local provider to keep your cloud costs down if you comment out the NFS tests. and unit. thats the only one in the bunch that doesnt play well with LXC
<jose> well, I don't use local as it takes forever to deploy :P
<jose> my internet connection is still slow
<jose> I can keep up with cloud, it's good for me
<sebas_> Juju and the Drupal charm was just presented here at FISL 15, in Brasil :)
<frankban> rbasak: ping re new quickstart release
<rbasak> frankban: hi! I have looked at it, but haven't finished testing it yet. Had some issues with my test environment.
<rbasak> frankban: I'm at a sprint this week, so I'm quite time limited. Sorry for the delay.
<rbasak> One of the issues I have, BTW, is that on a loaded box, juju times out creating an lxc container template, even though it will finish in the end anyway
<frankban> rbasak: no worries and thanks! so, as I mentioned yesterday, the revisions which should be included are revno 65, 66 and 67. Please feel free to ping me if you need any help
<frankban> rbasak: uhm, timeout while creating the template never experienced that :-/
<rbasak> I think it's an assumption that juju (not quickstart) is making about how long it should take to build the template container
<alexpilotti> natefinch: hi!
<natefinch> alexpilotti: howdy!
<frankban> rbasak: OIC
<alexpilotti> natefinch: good tx, frantically getting ready for Atlanta :-)
<frankban> rbasak: so on slower machines it can timeout
<frankban> rbasak: or on slower connections I guess
<rbasak> frankban: right. WHere I'm testing, IO performance is poor because it's on a VM where the metal is shared by other tenants.
<frankban> yeah
<mhall119> marcoceppi: one of these days I'll remember how to fix this,until then I need your help again
<mhall119> mhall@mhall-thinkpad:~$ juju status
<mhall119> ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: dial tcp 10.0.3.1:17070: connection refused
<mhall119> after having to reboot
 * mhall119 has a tomboy note open now to record the fix
<jcastro> we really need to fix that
<marcoceppi> mhall119: it's okay, if you remember how to fix this I'll not be needed anymore
<marcoceppi> mhall119: initctl list | grep juju
<mhall119> nothing listed
<marcoceppi> mhall119: sorry
<marcoceppi> mhall119: sudo initctl list | grep juju
<mhall119> mhall@mhall-thinkpad:~$ sudo initctl list |grep juju
<mhall119> juju-db-mhall-local stop/waiting
<mhall119> juju-agent-mhall-local start/running, process 1064
<marcoceppi> mhall119: sudo start juju-db-mhall-local
<mhall119> mhall@mhall-thinkpad:~$ sudo start juju-db-mhall-local
<mhall119> juju-db-mhall-local start/running, process 11371
<mhall119> mhall@mhall-thinkpad:~$ sudo initctl list |grep juju
<mhall119> juju-db-mhall-local stop/waiting
<marcoceppi> mhall119: sudo service monogdb stop
<marcoceppi> then start juju-db-mhall-local
<mhall119> still goes back to stop/waiting
<marcoceppi> mhall119: pastebin /var/log/upstart/juju-db-mhall-local.log
<mhall119> marcoceppi: http://paste.ubuntu.com/7410772/
<marcoceppi> mhall119: this was more than a reboot I'm guessing
<mhall119> at 10am today I manually rebooted after updating my system, because hangouts weren't working
<mhall119> a couple days ago my laptop powered itself off for no reason, I haven't tried accessing my juju env since then, so it may have been broken for a while
<marcoceppi> mhall119: so there's a --repair flag for mongo (really just need to remove a lock file but I don't know where it is)
<marcoceppi> mhall119: can you pastebin /etc/init/juju-db-mhall-local.conf
<mhall119> http://paste.ubuntu.com/7410785/
<mhall119> it was ~/.juju/local/db/mongod.lock
<mhall119> removed that, re-ran sudo start juju-db-mhall-local and now I can `juju status`
<marcoceppi> mhall119: awesome, good to know
<marcoceppi> mhall119: thumper is working on a new `juju local` plugin that will make managing local environments way easier in the future
<mhall119> I look forward to breaking it :)
<whit> wwitzel3, you put up your pyramid charm somewhere yet?
<jcastro> http://askubuntu.com/questions/462391/juju-bootstrap-node-cant-access-ubuntu-archives-via-maas
<jcastro> anyone see this problem before?
<tedg> lazyPower, So I got the ownCloud charm setup on docean. It works well.
<tedg> lazyPower, How is the SSL bit going?
<lazyPower> tedg: thats awesome!
<lazyPower> tests are blocking the merge, but its incoming. Jose and I were having a bit of back and forth about it lastnight.
<lazyPower> I expect it to land in the next couple of days
<tedg> Cool, I didn't want to take it beyond playing with if there was no encryption.
<lazyPower> Yeah - another thing to note
<lazyPower> there's a server side encryption plugin - i *highly* recommend it
<tedg> Oh, that's interesting.
<tedg> BTW, I used DAVdroid on Android.
<lazyPower> that way anything you put on your DO instance is encrypted as well. its more of a safeguard in case someone goes spelunking on your instance.
<tedg> You still have to pay, but it's OSS>
<lazyPower> nice! There's a disqus on my blog, would you mind dropping that int eh comment feed for future users that sumble across the post?
<lazyPower> stupid template has a bug where disquss doesn't always load, you may have to reload the article to get it to show :(  I'll eventually get around to fixing that...
<tedg> Ah, k
<lazyPower> thanks for the feedback though tedg - Glad to hear it's helping someone.
<tedg> Hmm, seems you can't post to Disqus with OpenID?
<cory_fu> I'm trying to install cobzr from launchpad, and the instructions on http://labix.org/cobzr just say to do `go install launchpad.net/cobzr` but I get a "cannot find package" error.
<cory_fu> I'm assuming there's a missing step in there (e.g., go get)?
<cory_fu> Why do so many instructions involving go seem to be missing steps?  (`go get launchpad.net/cobzr ; go install launchpad.net/cobzr` worked)
<themonk> how to restart a unit?
<dpb1> hi marcoceppi: any chance we could kick #1259630 a bit now?  I think we would like it to move forward.
<_mup_> Bug #1259630: add storage subordinate charm <landscape> <Juju Charms Collection:Fix Committed by davidpbritton> <https://launchpad.net/bugs/1259630>
<marcoceppi> dpb1: it's on the list for this week
<dpb1> marcoceppi: great, thanks!
<marcoceppi> expect a proper review/response either tonight or tomorrow
<dpb1> look forward it it. :0
<dpb1> :)
<themonk> marcoceppi: how do i restart a pending unit?
<marcoceppi> themonk: what version of juju?
<cory_fu> Man.  Adding bzr-pager, bzrtools (for cdiff), aliasing bzr diff -> bzr cdiff, and creating a ~/.colordiffrc makes bzr much nicer to work with
<themonk> marcoceppi: juju version is 1.18.2-precise-amd64
<themonk> marcoceppi: and why lxc local container deployment is too slow?
<marcoceppi> themonk: odds are something is stuck during deployment
<marcoceppi> themonk: which is why you see it in pending
<marcoceppi> themonk: can you run `sudo lxc-ls --fancy` and report back what is listed?
<themonk> marcoceppi: output is themonk-local-machine-1  RUNNING  10.0.3.113  -     YES
<marcoceppi> themonk: no other machines listed?
<themonk> marcoceppi: no
<cory_fu> jose: You around?
<jose> cory_fu: I am always around ;)
<cory_fu> :)
<cory_fu> I was wondering if you got my message last night regarding the tracks charm?  My IRC client sometimes tells me I'm connected when I'm not
<jose> oh, the permissions one
<jose> yeah, I did
<jose> and ports <=1024 are root only, that one too
<cory_fu> Yeah, so I don't think it will be feasible to use setcap, so I think our only choice is to just run it as root
<cory_fu> :-/
<jose> hey, what we can do is if the port is <1025, then run it as root
<jose> and if port is >1023, run as tracks user
<jose> adding a note to the README, of course
<cory_fu> Yeah, that's a possibility, though it complicates the hooks.  Keep in mind that we need to handle the case of the user changing the port (i.e., we'll have to update the tracksapp.conf file in the config-changed hook)
<jose> it actually does
<jose> I think I can write this up while these owncloud tests are running
<cory_fu> Well, it changes the port in the conf file, but we'd also have to add / remove the setuid line
<cory_fu> Just another sed line, I suppose.  :)
<jose> yep!
<cory_fu> Awesome.  Well, I have to step away for a few minutes, but if there's anything I can do to help, let me know.
<jose> sure thing
<jose> I'll work on this and let you know when I have any results
<cory_fu> Thanks!  :)
<lazyPower> cory_fu: jose - please dont run the service as root
<lazyPower> a) its against CS guidelines, and b) its a huge security hole
<jose> lazyPower: then the quick workaround for me would be to only run it if port is >1024
<jose> will do that
<lazyPower> that's a far better option.
<lazyPower> jose: i'd also mark that in the readme - that the service is intended to be run at scale - so if you want port 80, deploy it behind a reverse proxy.
<jose> mhm, will do
<lazyPower> you can co-locate the service, if the end user is concerned about machine consumption
<jose> at this point the readme is *pretty* lightweight
<astark> Hello.  I am trying to get around the fact that Maas / Juju do not seem to work well with i386 hardware.  I tried 'juju bootstrap --constraints arch=i386', but I get a response that suggests the only valid value is amd64.  Does anyone have any ideas?  Thanks.
<jose> hey guys, has anyone seen this error while testing before? http://paste.ubuntu.com/7412268/
<lazyPower> astark: i'm assuming this is in realtion to ensuring you're getting a 32bit machine?
<lazyPower> *relation
<lazyPower> jose: your test timed out during the deployment
<jose> and I gave it 25 minutes!
<lazyPower> well thats fun
<lazyPower> maybe that's not what happened, but thats what it leads me to believe
<lazyPower> marcoceppi: ^ amulet's being finicky it looks like. Any idea? 25 minutes is long enough to setup pretty much anything....
<jose> I'm running it again just in case
<astark> lazyPower:  I have about 9 boxes.  4 are amd64, the others are i386.  Maas knows the difference.  When I goto do a normal bootstrap, if it targets a 32 bit machine the bootstrap fails (due to always downloading amd64 juju tools), but if it picks a 64 bit machine bootstrapping happens successfully.  I then goto deploy openstack, and when deploying the services only the 64 machines ever move from 'pending' to 'started'.  I was trying initially with
<astark>  1.18 and have been trying 1.19.1 with no success either.
<jose> this time it showed the same signs after 2014-05-07 15:03:36  Adding relation relation-sentry:provides-owncloud_shared-fs-nfs_nfs <-> nfs:nfs
<jose> oh and just gave the same errors I thinik
<marcoceppi> jose: use --set-e and when it's done run juju status
<jose> marcoceppi: like 'charm test -e ec2 tests/100-deploy --set-e'?
<marcoceppi> that looks good
<jose> ok
<jose> running again
<jose> it's been stuck in 2014-05-07 15:21:16 Config specifies num units for subordinate: owncloud-sentry for around 8m
<marcoceppi> jose: it's going to time out
<marcoceppi> jose: I think that one or more of your aws machines aren't being turned on
<marcoceppi> provisioning errors, etc
<jose> it did timeout
<jose> oh, oh, deployment did complete
<jose> but I have another error, let me pastebin
<jose> http://paste.ubuntu.com/7412525/
<jose> for some weird reason it's not able to connect to the machine
<lazyPower> jose: is the service exposed?
<jose> yes, it exposes both owncloud and haproxy
<lazyPower> hmmm
<lazyPower> I'm not sure man :(
<lazyPower> it looks like its attempting to connect over ssl though
<lazyPower> is port 443 active? run it with a --set-e flag so it doesn't tear down the env and you can poke around in it
<lazyPower> also, ensure open-port 443 happens in the hook code when you enable ssl, otehrwise it wont open the port in the AWS security group.
<lazyPower> which would explain why it cannot connect...
<jose> oh, I did run it with that
<jose> port 443 *should* be active
<jose> yes, owncloud has 443 and 80 open
<jose> haproxy, though, only has 80
<jose> which *may* explain the error
<jose> nope, it isn't that, because it's trying to connect to the owncloud address with a failure
<lazyPower> Do you have a d.sentry.wait?
 * jose checks
<jose> I do not
<jose> added; destroying env and rerunning
<mhall119> jcastro: marcoceppi: ok guys, I have a charm that I want to submit to the charm store....what do I do?
<marcoceppi> mhall119:
<jcastro> https://juju.ubuntu.com/docs/authors-charm-store.html#submitting-a-new-charm
<marcoceppi> https://juju.ubuntu.com/docs/authors-charm-store.html#submitting-a-new-charm
<marcoceppi> dangit
<jcastro> :)
<mhall119> hah, jcastro wins
<thumper> mhall119: oh hai
<mhall119> hey thumper
<thumper> mhall119: wanted to talk to you about deploying django apps with juju
<thumper> mhall119: marcoceppi said you were the person to talk to
<thumper> mhall119: my app is not open source (personal startup project)
<thumper> mhall119: how do I get the app payload into the charm?
<mhall119> marcoceppi: I've become "the person to talk to" about deploying django?
<mhall119> that's not a good sign :)
<mhall119> thumper: my django charms pull from bzr on launchpad
<marcoceppi> mhall119: you're the only person I could think that does django stuff :)
<thumper> mhall119: it is a great sign
<mhall119> thumper: alternately you can put the files (or a tarball of the files) into your charm's ./files/ directory
 * thumper sighs...
<thumper> mhall119: this whole tarball thing is one thing I'm fixing this cycle
<mhall119> alternately, you can put your files into cloud storage and configure your charm to pull from there
<thumper> luckily text compresses well, right?
<mhall119> I suppose
<mhall119> thumper: easiest thing to do is to stop hating freedom so much and open source your code :-P
<thumper> mhall119: haha
<thumper> I don't hate freedom
<thumper> I'm free to try and make some money :)
<mhall119> thumper: I can help you with gunicorn, swift and a CDN though ;)
<mhall119> thumper: http://paste.ubuntu.com/7412775/ is my current test deployment
<thumper> mhall119: what is go-pronto?
<marcoceppi> thumper: maybe a subordainte charm that you don't release that has your ssh keys for pulling the source of your app that can plop it in the right place on the django charm/service?
<mhall119> thumper: a new swift-backed CDN from bigkevmcd
<mhall119> marcoceppi: is it possible to make a subordinate charm our of a django app?
<thumper> marcoceppi: yeah, I've been thinking about the subordinate option
<thumper> mhall119: why not?
<thumper> I may poke around
<mhall119> thumper: because I don't know enough juju
<thumper> might need to make a config option in the main charm
<thumper> so it doesn't try to deploy without the subordinate
<mhall119> right now summit-website's charm is coded to setup swiftstorage, but having it a subordinate that you can add or not would make it more flexible
<marcoceppi> mhall119: subordinates are like the glue and string that turn deployments from piles of rocks, to a mcguyver helicopter
<thumper> marcoceppi: haha, classic
<mhall119> so...maybe I'll wait on making that subordinate
<thumper> marcoceppi: do we have docs on deploying local charms?
<mhall119> charm proof tells me that my charm isn't ready to submit yet :(
<mhall119> back to work I go
<marcoceppi> thumper: we shure as hell should
<marcoceppi> https://juju.ubuntu.com/docs/charms-deploying.html#deploying-from-a-local-repository
<thumper> ta
<marcoceppi> haha shure, it's that time of the day when I need to just log off
<thumper> marcoceppi: hmm... that doesn't actually tell the user what the local directory structure should look like
<mhall119> marcoceppi: what category should a CDN service fall under?
<marcoceppi> thumper: pull requests welcome, we cover it somewhere else in the doc now that I think about
<marcoceppi> it
<marcoceppi> mhall119: eh, we only have like 6
<mhall119> marcoceppi: I have file-servers currently, but I don't konw if that's right
<marcoceppi> misc or applications probably
<marcoceppi> mhall119: that works
<mhall119> does it?
<marcoceppi> doesn't it?
<marcoceppi> question aside, categories are arbitrary
<marcoceppi> you could put it in both
<marcoceppi> misc and file-servers
<mhall119> ok
<thumper> evilnickveitch: ping
<thumper> evilnickveitch: docs on local repository structure?
<jose> marcoceppi: I have got exceptions while running the tests but no results yet, that is normal and I should wait, right?
<jose> I got the exception of a exception of a exception
<thumper> rick_h_: help
<thumper> rick_h_: can you deploy a local charm from the gui?
<mhall119> submitted my first charm! https://bugs.launchpad.net/charms/+bug/1317281
<_mup_> Bug #1317281: New Charm: go-pronto <Juju Charms Collection:New> <https://launchpad.net/bugs/1317281>
<jose> wohoo, congratulations mhall119!
<marcoceppi> thumper: you can drag and drop a tarbal
<marcoceppi> of a charm
<jose> mhall119: I think that for a charm to be on trusty it needs to have tests... not 100% sure though
<thumper> marcoceppi: oh.. ok...
<jose> mhall119: and as I mentioned earlier, the details with the README:
<rick_h_> thumper: huh?
<rick_h_> thumper: drag/drop it on the canvas
<thumper> rick_h_: does it handle zip files?
<thumper> or just tarballs
<jose> README has to be in Markdown and Contact Information is for the charm *and* upstream
<rick_h_> thumper: just zips
<thumper> oh, so just zip files
<thumper> hmm..
<rick_h_> thumper: yep, it's what juju upload supports. Does juju take tarballs?
<mhall119> jose: what details were those again?
<mhall119> also, how do you write tests for a charm?
<jose> mhall119: <jose> README has to be in Markdown and Contact Information is for the charm *and* upstream
<jose> `charm add tests` provides an autogenerated test suite
<jose> they're written in python3 with the help of amulet
<jose> https://juju.ubuntu.com/docs/tools-amulet.html has more info
<mhall119> man, this is what happens, you let jcastro on your team and suddently *everything* has to be in Markdown
<jose> haha
<mhall119> jose: $ charm add tests
<mhall119> Error: add is not a valid subcommand
<marcoceppi> jose: mhall119 readme doesn't HAVE to be in Markdown, it just renders better when it is
<marcoceppi> also, tests are still optional and may be changing in the future
<marcoceppi> mhall119: install charm-tools from ppa:juju/stable
<mhall119> why wasn't the README created for me in Markdown?
<marcoceppi> the one in trusty is super outdated
<mhall119> marcoceppi: trusty is 2 weeks old!
<marcoceppi> mhall119: you're using anchinent version of charm-tools
<marcoceppi> mhall119: it hasn't been sync'd since precise
<mhall119> 2 weeks!
<marcoceppi> mhall119: I missed the update window
<mhall119> why not?
 * jose proposes 100 charms for trusty
<marcoceppi> jose: we don't have 100 charms with tests
<jose> didn't you say tests are still optional?
<mhall119> he said Markdown was optional
<mhall119> oh, tests too
<mhall119> missed that
<marcoceppi> jose: not for trusty
<jose> he was proposing for trusty, that's why I mentioned tests
<marcoceppi> jose: but we're reworking what it means to be a charm test
<jose> cool
<marcoceppi> mhall119: so if you have unit tets for your charm, you're golden
<mhall119> not much to test....
<jose> on the other hand, azure is not behaving correctly and my test is stuck
 * marcoceppi looks at the charm
<marcoceppi> ooooo a bash charm
 * jose loves bash charms
<marcoceppi> heh, mhall119, I see what you mean
<mhall119> marcoceppi: my summit charm will have more
<marcoceppi> So, I'll review the charm, but there's a potential problem with it, it's going to be impossible to test with amulet because not all clouds provide swift, etc
<marcoceppi> mhall119: sweet, I eagerly await that one
<marcoceppi> don't ge me wrong, this is awesome
<mhall119> ah, is that what amulet is used for? testing on different clouds?
<mhall119> marcoceppi: you can *technically* run it in a cloud that doesn't use swift....as long as you point it to a cloud that does :)
<mhall119> I'm running it on LXC, pointing to canonistack's swift
<marcoceppi> mhall119: /sure/ but that means hard coding swift creds in to a test
<mhall119> I'm guessing that's frowned upon
<marcoceppi> mhall119: yeah, amulet and "charm tests" as they stand today are designed to do integration testing on charms and we run those across all our providers
<marcoceppi> mhall119: typically
<mhall119> ok, so do I need tests or will they just be pointless for this?
<marcoceppi> it's not a blocker for the store, we'll do the review like normal and give you feedback
<marcoceppi> we've never formalized charm tests being required, we've strongly recommended them for trusty but like I mentioned earlier the concept of what is a charm test may change int he near future
<mhall119> I guess I should make swiftstorage a subordinate then, so I can submit summit-website charm to the store
<marcoceppi> mhall119: is swiftstorage different than go-pronto?
<evilnickveitch> thumper, it is covered in https://juju.ubuntu.com/docs/authors-charm-writing.html, but it would be good to add to the deploy page too. I am thinking of adding a whole page about local charms actually, to cover fetching them too
<mhall119> marcoceppi: yes
<mhall119> swiftstorage is a Django app that makes it use swift for static files and uploaded media, rather that local files
<marcoceppi> mhall119: ah, gotchya
<jose> whoops, just on the 7th day of the month and already exceeded my free 2mil I/O requests for ec2 :P
#juju 2014-05-08
<bl3u> has anyone successfully run juju within docker?
<bl3u> docker doesn't work well with upstart, and it's causing juju bootstrap some pain =/
<waigani> thumper: ping
<waigani> Are we still having our weekly team meeting?
<thumper> hey
<thumper> waigani: not sure
<thumper> waigani: I'm guessing no... a few too many people, unless I hear otherwise
<waigani> thumper: cool, I pmed you too
<thumper> bl3u: you won't really be able to run juju within docker
<thumper> bl3u: not unless you are running a full os docker image as the base
<thumper> bl3u: also, nested lxc type containers don't really work
<thumper> bl3u: I'm assuming you were wanting to run the local provider inside a docker image
<bl3u> thumper: that is correct
<bl3u> i am running the ubuntu 14.04 base docker image
<bl3u> i'm trying to play with it in a safe way; i'll just stand up a VM i suppose
<kryptos> hi
<kryptos> i have  a problem juju configuration
<kryptos> can u assist me on the same
<kryptos> Error details: cannot parse "/root/.juju/environments.yaml": YAML error: line 326: could not find expected ':'
<s3an2_> what is online 326 of the yaml file?
<_benoit_> I am patching goamz to support a new provider
<_benoit_> Should the goamz external API be kept intact at all cost ?
<_benoit_> I would need to modify the S3 constructors to return *S2, ok for example
<mhall119> weird, irssi disconnected me from here and re-connected me to oftc/#juju
<mhall119> anyway, is `juju upgrade-charm` supposed to update the files in /var/lib/juju/agents/ on my instances?
<lazyPower> mhall119: indeed, for the charm specified after the upgrade-charm
<lazyPower> eg: juju upgrade-charm mysql, will upgrade mysql if there is a new revision in teh store. otherwise it will return an error that you're already running the latest revision.
<mhall119> lazyPower: I think my problem was git and LXC
<lazyPower> ah, you're still running 1.18.x right?
<lazyPower> Once the 1.19 branch lands as 1.20, your git merge conflicts will go away. Its a brilliant thing.
<mhall119> hmmm, I think I broke LXC
<mhall119> marcoceppi: does anything look wrong here: http://paste.ubuntu.com/7416306/ ?
<mhall119> that's my all-machines.log
<mhall119> juju bootstrap returned without error, and I've issued several juju deploy commands that are all listed as pending, but nothing is happening
<mhall119> http://paste.ubuntu.com/7416337/ is `juju status`
<mhall119> $ sudo initctl list |grep juju
<mhall119> juju-db-mhall-local start/running, process 456
<mhall119> juju-agent-mhall-local start/running, process 485
<lazyPower> mhall119: he's out today and tomorrow on swap
<mhall119> ah, jcastro then ^^
<mhall119> help me jcastro, you're my only hope
<avoine> mhall119: it's like your don't have cpu-checker installed
<mhall119> it was working fine an hour ago
<mhall119> I haven't rebooted or anything
<avoine> mhall119: t
<avoine> mhall119: what is the result of that command: kvm-ok
<mhall119> kvm-ok
<mhall119> INFO: /dev/kvm does not exist
<mhall119> HINT:   sudo modprobe kvm_intel
<mhall119> INFO: For more detailed results, you should run this as root
<mhall119> HINT:   sudo /usr/sbin/kvm-ok
<avoine> mhall119: it looks like you tried to setup a kvm local environment but you don't have kvm support
<avoine> do you have something like: container: kvm in your environment?
<mhall119> nope
<mhall119> and like I said, it was working an hour ago
<mhall119> container: lxc is in my ~/.juju/environments/local.jenv
<avoine> mhall119: I had a problem like that when I tried to use lxc-clone: true
<avoine> and with an old version of lxc
<mhall119> well, I have lxc-clone: true
<mhall119> but, I'm on Trusty with the juju PPA, it shouldn't be that old
<mhall119> might try rebooting
<roadmr> hey folks, I tried following https://juju.ubuntu.com/docs/config-LXC.html but juju bootstrap got stuck trying to connect to mongodb (which wasn't installed). I had to manually install mongodb-server. Should juju-mongodb take care of this dependency for me?
<lazyPower> roadmr: did you install juju-local?
<lazyPower> that should pull down all the dependencies you need for lxc deployment
<roadmr> lazyPower: I did
<roadmr> lazyPower: it did pull everything *except* for mongodb-server :D
<lazyPower> did you have mongodb installed prior to installing juju-local?
<roadmr> lazyPower: no, it's a fresh install (utopic if it helps, but at this point it's almost identical to trusty)
<lazyPower> ah, i have no idea whats going on in utopic... but i just booted a fresh vm with trusty (thanks maas master) and installed juju + juju-local and i was able to bootstrap
<lazyPower> so, it installs juju-mongodb
<lazyPower> if you're missing that package, give it a go and ping me with the results.
<roadmr> lazyPower: yes, mine installed juju-mongodb too
<roadmr> lazyPower: ok, I'll try redoing the whole thing from scratch, maybe I messed up somewhere :)
<marcoceppi> mhall119: did you get it sorted?
<mhall119> marcoceppi: not yet
<marcoceppi> mhall119: what does sudo lxc-ls --fancy show?
<mhall119> $ sudo lxc-ls --fancy
<mhall119> Swipe your right index finger across the fingerprint reader
<mhall119> NAME                   STATE    IPV4  IPV6  AUTOSTART
<mhall119> -----------------------------------------------------
<mhall119> juju-trusty-template   STOPPED  -     -     NO
<mhall119> mhall-local-machine-1  STOPPED  -     -     NO
<mhall119> I destroyed my old env, bootstrapped a new one and deployed just a single charm (postgresql) this time
<marcoceppi> well, mhall-local-machine-1 stopped isn't nice
<tvansteenburgh> marcoceppi: https://github.com/marcoceppi/amulet/pull/31
 * tvansteenburgh drops the mic and walks off stage
<mbruzek> mhall119, Have you resolved your problem?
<mhall119> mbruzek: not yet, haven't tried rebooting yet though
<themonk> marcoceppi: how do i restart a pending unit?
<marcoceppi> mhall119: destroy environment with the --force flag, run sudo lxc-ls --fancy again see if machine-1 goes away
<marcoceppi> themonk: what provider?
<mbruzek> mhall119, what marco-vacation said.
<themonk> marcoceppi: lxc local
<marcoceppi> themonk: then the machine probably never came up, themonk what does sudo lxc-ls --fancy say for you? (and what does juju status show)
<mbruzek> mhall119, Please paste results of ls /var/lib/juju/locks/
<mhall119> marcoceppi: machine-1 does not go away
 * marcoceppi laments about an updated local provider troubleshooting guide
<marcoceppi> mhall119: lxc-destroy -n blahblah-machine-1
<mhall119> mbruzek: http://paste.ubuntu.com/7416886/
<mhall119> marcoceppi: $ lxc-destroy --n mhall-local-machine-1
<mhall119> Container is not defined
<marcoceppi> mhall119: single -n
<mhall119> ok, now it's gone
<marcoceppi> mhall119: okay, bootstrap and deploy again
<mbruzek> mhall119, Is the juju-trusty-tempate directory out of the locks directory now as well?
<mhall119> mbruzek: nope
<marcoceppi> mhall119: it shouldn't disappear between destroys
<marcoceppi> mbruzek: ^
<marcoceppi> it only needs be removed if it exists and the trusty-template vm does not (or is not stopped)
<mbruzek> OK.  Was just checking my history, for what Thumper helped me with last week.
<marcoceppi> mbruzek: yeah a lot of people had template creation problems, cory and tim not the least
<mhall119> marcoceppi: still doesn't appear to be deploying anything
<mhall119> machine-0: 2014-05-08 16:19:27 WARNING juju.cmd.jujud machine.go:277 determining kvm support: exit status 1
<mhall119> machine-0: no kvm containers possible
<marcoceppi> that's illy
<marcoceppi> mhall119: what does your environments.yaml look like?
<marcoceppi> for the local provider
<tvansteenburgh> marcoceppi: mind if i take a crack at https://bugs.launchpad.net/amulet/+bug/1293878 ?
<marcoceppi> tvansteenburgh: not in the slightest
<marcoceppi> tvansteenburgh: I was essentially going to rsync the contents of the charm to a temp location, run a bzr init, then a commit, then use that as the branch location in the deployer file
<marcoceppi> tvansteenburgh: if you can think of a more clever path, by all means
<tvansteenburgh> marcoceppi: cool, thanks - i'll start there
<themonk> marcoceppi: themonk-local-machine-1  RUNNING  10.0.3.113  -     YES
<themonk> marcoceppi: this is the out put
<qhartman> I have a juju environment running, and I accidentally re-issued a bootstrap command for it (the default env). It looks like it nuked the environment, I can no longer get status from it.
<qhartman> Is that expected?
<marcoceppi> qhartman: uh, no. What version of juju are you running?
<qhartman> 0.18.2  I think, latest in Trusty
<mhall119> marcoceppi: https://pastebin.canonical.com/109888/
<qhartman> 1.18.2
<mhall119> marcoceppi: but it was working for me this morning, so I don't think it's a config thing, I think I just broke the runtime somehow
<marcoceppi> qhartman: yeah, that should never happen, you should get a warning about it already being bootstrapped
<marcoceppi> mhall119: interesting
<qhartman> marcoceppi, yeah, I did see that warning, but the file that I expect to exist in .juju/environments to track it is definitely gone
<qhartman> :-\
<marcoceppi> qhartman: was this local provider?
<qhartman> marcoceppi, nope, maas
<marcoceppi> oh bother.
<qhartman> yeah
<marcoceppi> qhartman: do you have the output from the boostrap command still?
<qhartman> I interrupted it, but I can get it
<marcoceppi> qhartman: ah, interesting, that might be the expected behavior
<marcoceppi> an interruptted bootstrap will attempt to "clean itself up"
<qhartman> oh
<qhartman> well, that's quitet he landmine
<marcoceppi> if you run a bootstrap against a bootstrap it will eventually error out about already being bootstrapped
<marcoceppi> but I'm curious the output regardless
<qhartman> yeah, I'll go grab it
<qhartman> one sec.
<cjohnston> How is the order of relation hooks being run determined?
<cjohnston> I'm using a deployer file, so is it just the order of the relations in the deployer file?
<themonk> marcoceppi: do you have the solution?
<qhartman_too> marcoceppi, http://pastebin.com/qsbnMnPD <- ctrl-c double-bootstrap landmine
<marcoceppi> themonk: can you paste the output of juju status?
<marcoceppi> qhartman: qhartman_too interesting, it looks like it error properly
<themonk> environment: local
<themonk> machines:
<themonk>   "0":
<qhartman_too> I find it interesting that is talks about cleanup before the error about being already bootstrapped. Makes me wonder if there's something happening out of order?
<themonk>     agent-state: started
<themonk>     agent-version: 1.18.1.1
<themonk>     dns-name: localhost
<themonk>     instance-id: localhost
<themonk>     series: precise
<themonk>   "1":
<themonk>     agent-state: started
<themonk>     agent-version: 1.18.1.1
<themonk>     dns-name: 10.0.3.113
<themonk>     instance-id: themonk-local-machine-1
<themonk>     series: precise
<themonk>     hardware: arch=amd64
<themonk> services:
<themonk>   opendj:
<themonk>     charm: local:precise/opendj-0
<themonk>     exposed: false
<themonk>     units:
<themonk>       opendj/0:
<themonk>         agent-state: pending
<themonk>         agent-version: 1.18.1.1
<themonk>         machine: "1"
<themonk>         public-address: 10.0.3.113
<themonk> marcoceppi: sorry for bad paste
<marcoceppi> themonk: paste.ubuntu.com would be helpful next time :)
<marcoceppi> themonk: so, the machine is up, what is likely happening is the install hook is stuck
<themonk> marcoceppi: https://gist.github.com/anonymous/e23b27a7b301b86e7759
<marcoceppi> themonk: pastebin `cat ~/.juju/local/log/unit-opendj-0.log` for me?
<marcoceppi> qhartman qhartman_too yes thatis a clear issue of order of operations
<marcoceppi> qhartman qhartman_too can you open a bug with that and I'll flag it as king of a big issue
<qhartman_too> marcoceppi, sure thing.
<qhartman_too> I'll drop a link in here once it's up.
<marcoceppi> qhartman_too: excellent
<qhartman> marcoceppi, juju-core on launchpad?
<marcoceppi> qhartman: yes
<qhartman> marcoceppi, any recommended steps to clean this up? Is this a case of nuke-and-pave and start over?
<marcoceppi> qhartman: so, all you need to do is regenerate the jenv file
<marcoceppi> qhartman: I don't know how to do that out of band
<qhartman> marcoceppi, yeah, I figured. I have some old "juju status" output lying around. Might that have the needed info?
<qhartman> marcoceppi, https://bugs.launchpad.net/juju-core/+bug/1317596
<marcoceppi> qhartman: not really, the jenv file is created that's basically everything in the environments.yaml def with some others
<qhartman> marcoceppi, I figured
<marcoceppi> natefinch: hey, are you around?
<qhartman> marcoceppi, oh well. Luckily this was not yet a production deployment
<natefinch> marcoceppi: I was just about to ping you.  What's up?
<marcoceppi> natefinch: is there anyway to generate a jenv file other than bootstrap?
<marcoceppi> qhartman: has a bug where in 1.18.2 if you bootstrap an already bootstrapped environment, it errors out but does a "cleanup" after erroring resulting in his jenv missing
<marcoceppi> bug # 1217596
<marcoceppi> bug #1217596
<marcoceppi> lazy mup.
<natefinch> yeah, I think it's broken
<marcoceppi> WHY MUP WHYYYYYYY
<natefinch> no, there's no other way to make a jenv
<marcoceppi> \o/
<marcoceppi> qhartman: so, starting over looks like the only choice
<natefinch> rebootstrapping definitely should not blow away your jenv though
<marcoceppi> natefinch: oh, yeah, that's clearly a bug
<qhartman> I hit ctrl-c when I realized I had accidentally done it again, so that might have played a role
<marcoceppi> qhartman natefinch I think the log is the most interesting
<marcoceppi> Bootstrap failed, destroying environment
<marcoceppi> ERROR environment is already bootstrapped
<natefinch> ahh.... control-c in the middle of a second bootstrap.... that could do it
<qhartman> yeah, I'm guessing it traps the ctrl-c and goes to cleanup before realizing it already exists
<marcoceppi> natefinch: I think the Ctrl-C is a red herring
<qhartman> could be that too for sure
<marcoceppi> it looks like On error clean up is performed, but if already bootstrapped is an error, we enter a weird state
<natefinch> marcoceppi: I'm not so sure.  double bootstrapping is something I do all the time by accident
 * marcoceppi goes to verify with a non Ctrl-C
<qhartman> any rate, thanks for the help guys, I'm going to go fire up my orbital laser platform and start over.
<qhartman> *womp womp*
<natefinch> evilnickveitch: if there's a minor edit to the docs, should I do it right in the github editor, or is there a better process?
<mbruzek> I know charmhelpers best was discussed recently, are we supposed to put the charm helpers inside the hook directory or inside the charm directory in $CHARM_DIR/lib/charmhelpers  ?
<themonk> marcoceppi: it continuously logging this, https://gist.github.com/anonymous/31e426b5314ef51cfb47
<marcoceppi> mbruzek: I'd prefer they be put in lib, but that requires some muxing around for inheritence
<marcoceppi> mbruzek: most people put them in the hooks directory
<mbruzek> marcoceppi, I am doing one from scratch what is the best practise we discussed last week?
<marcoceppi> mbruzek: outside the hooks directory is always considered a best practice
<mbruzek> Done.  Thanks marcoceppi
<marcoceppi> themonk: that's annoying, and will be fixed in 1.19, but this means that the container didn't get setup properly
<marcoceppi> so the agent is running, everything is working as expected, but for some reason cloud init failed
<marcoceppi> themonk: this likly means that the container doesn't not have outside networking access and can't reach the archives
<marcoceppi> themonk: you should be able to `juju ssh 1` and run sudo apt-get update to verify
<themonk> marcoceppi: ok
<marcoceppi> natefinch: the README outlines the process, but you can totally do it from the editor
<themonk> marcoceppi: it has network access
<themonk> marcoceppi: apt-get is updating
<marcoceppi> themonk: can you sudo apt-get install git ?
<themonk> marcoceppi: inside machine 1
<marcoceppi> themonk: yes
<themonk> marcoceppi: ok
<themonk> marcoceppi: git is installing
<natefinch> marcoceppi: sweet.  moving to github and markdown just reduced the barrier for me fixing that docs bug to nearly zero.... which is about where it needs to be for me to actually get off my lazy butt to do it :)
<marcoceppi> I'm adding that to the quotes page ;)
<marcoceppi> jcastro: ^^ o/ \o
<qhartman_too> So, in using maas and juju together, can I specify which node I want juju to boostrap onto if I have multiple available in maas?
<qhartman_too> haven't found anything in the docsabout that
<natefinch> qhartman_too: you can give constraints to bootstrap, which can sorta help, but you can't precisely say "go onto the machine named foo" .... though I think we have stuff in the works for that
<natefinch> qhartman_too: juju help contraints will show you how to use the constraints.  You can set a tag on the node and then use that to get bootstrap to go where you want it to
<qhartman_too> natefinch, ok, will do. Being able to specify by name would be nice too, so I hope that is in the works.
<qhartman_too> thanks
<natefinch> qhartman_too: code for it was merged into trunk a couple weeks ago, so it'll be available in 1.20
<natefinch> (I just checked)
<cjohnston> marcoceppi: any idea why amulet appears to be running tests before the deployment is complete?
<qhartman_too> awesome. So, by set a tag, you mean a maas tag, correct natefinch?
<marcoceppi> cjohnston: it shouldn't, do you have the output from the run?
<natefinch> qhartman_too: yep, then you can do --constraints tags=foo
<qhartman_too> natefinch, cool
<natefinch> marcoceppi: I have a problem with debug hooks on local... for some reason it seems like it not setting up the environment correctly
<natefinch> marcoceppi: I get a prompt like this: root@nate-local-machine-2:~#
<cjohnston> marcoceppi: L77 http://paste.ubuntu.com/7417300/ I guess it shows complete, then 2 seconds later is starts another deployment... L78 shows the output of a command that is being run by the test, where we are trying to get the IP address and the open ports.. the open ports dont exist yet for some reason.. L84 is that same command, and they exist there
<natefinch> marcoceppi: any ideas? I haven't used debug hooks much
<marcoceppi> natefinch: are you in a tmux session?
<natefinch> marcoceppi: yeah, it's a tmux session, it just doesn't have the right prompt, according to the docs, and seems to be in the wrong directory, etc
<marcoceppi> natefinch: you're in window 0
<marcoceppi> natefinch: you need to trigger a hook to get it to bring up a hook context
<marcoceppi> natefinch: so either run a config changed, or if it's in error run resolved --retry
<natefinch> marcoceppi: what I hear is: the docs need to be clarified ;)
<cjohnston> when I run debug-hooks, I get the normal prompt for a bit until the hooks start running, then the hook prompt comes up
<natefinch> marcoceppi: the docs say "When the first hook event is queued for a hook that is in the list of those to be debugged"  .... but it doesn't say how that happens.  Do I have to do something for that to happen?
<marcoceppi> natefinch: you have to have a hook queued for execution then have it execute
<marcoceppi> natefinch: feel free to word smith that line better :)
<natefinch> marcoceppi: I did juju debug-hooks wordpress/0 install
<marcoceppi> natefinch: yeah, that doesn't work (yet)
<natefinch> marcoceppi: that brought me to this prompt.  I don't know what to do now
<marcoceppi> juju debug-hooks wordpress/0 is what got executed
<marcoceppi> natefinch: this is why I break the install hook when I write charms, so I can get to that hook context
<natefinch> marcoceppi: that's fine.  What do I do now?
<marcoceppi> natefinch: trigger a hook
<marcoceppi> natefinch: ie, run juju set against the unit and change a config value
<natefinch> marcoceppi: well, install is the one that failed
<cjohnston> you need to run debug-hooks sooner
<marcoceppi> natefinch: okay, run juju resolved --retry
<marcoceppi> that will re-trigger the hook
<marcoceppi> and put you in a hook context in debug-hooks
<marcoceppi> that's documented /somewhere/ in the docs
<natefinch> marcoceppi: ahh, yeah, that is under "debugging early hooks"
<natefinch> man, juju resolved and juju debug-hooks seriously need better command line docs
<natefinch> purpose: marks unit errors resolved
<cjohnston> any thoughts on the amulet issue marcoceppi ?
<marcoceppi> cjohnston: I'd nee to see your tests to be able to determine further what's oging on
<cjohnston> marcoceppi: http://bazaar.launchpad.net/~canonical-ci-engineering/uci-engine/trunk/view/head:/tests/test_ppa_assigner.py
<avoine> cjohnston: btw your graphite-txstatsd charm looks pretty cool
<cjohnston> avoine: thanks
<cjohnston> still trying to get postgres happy
<natefinch> hmm... this sounds familiar: failed to fstat previous diversions file: No such file or directory
<jose> lazyPower: ping, have a minute?
<lazyPower> jose: kind of, whats up?
<jose> lazyPower: tests are running 'good' but failing because of the (expected) 'invalid' SSL certs, as they're self-signed
<lazyPower> it using pythong requests right?
<jose> lemme double check
<lazyPower> wow banana hands... whit you're contageous.
<lazyPower> its got a loading phase of 3 days though
<jose> lol, what?
<jose> (they're using requests.post
<lazyPower> the massive typos in a single sentence. Whit coined the phrase bananahands... i refuse to let that one go. its too fitting for whats happening.
<lazyPower> jose: http://stackoverflow.com/questions/10667960/python-requests-throwing-up-sslerror
<jose> :P
<lazyPower> so, load the service with a CAFile, and point it at that.
<whit> http://www.lestelecreateurs.com/projects/altoids-banana-hands/
<lazyPower> yep. i think i just found my new canonical directory photo
<jose> :P
<lazyPower> jose: the other alternative would be to set verify=false (which you're not really verifying the ssl cert at that point) but if the url remains https:// and you get the respective content, its 'basically' doing the job we've requested. soo....
<lazyPower> use your judgement on which approach you want to use. I'd accept either
<jose> I prefer to do the latter, as I'm not sure how to generate the other
<jose> as long as I get it to pass it'll be awesome
<jose> then we can move on to upgrading it to 6.1.3 (I think)
<cory_fu> What's the point of doing ssl if you don't verify the cert?
<lazyPower> cory_fu: The fact its stills erved over https would validate its being sent over a secure chanel, you're not validating the key exchange. Whats a good way to perform that using python.requests cory_fu?
<lazyPower> with a snakeoil cert
<cory_fu> Or are you saying that the service you're downloading from doesn't have a valid cert?
<lazyPower> its a snakeoil cert, not invalid, but not issued from a CA
<jose> which makes it look 'invalid'
<cory_fu> Hrm.  If you don't validate the cert at all, then it's not secure since it's open to MITM and spoofing
<lazyPower> again, suggestions?
<cory_fu> You should probably add that specific cert to the list of trusted, temporarily
<lazyPower> ah
<lazyPower> so suggestion 1 - you gen it locally and provide it to the charm right?
<cory_fu> Um, there's a way to give requests a cert that you consider valid.  Lemme look
<cory_fu> Yeah
<lazyPower> jose: i think i'm inclined to agree with cory_fu, he's got a valid point.
<lazyPower> we can't test if the cert is genned on the machine, but there are options to provide a certificate, and its reasonable to assume it doesn't matter if that cert is genned on your workstation or the server. thats just a nicety the charm provides.
<lazyPower> its the same symptom and will yield the same result.
<jose> wait!
<jose> charm-helpers
<jose> will it work in a test?
<jose> if it can then I can just generate the cert and parse it
<lazyPower> jose: I would gen a certificate once and package it as part of the test
<lazyPower> make a non-expiring self-signed SSL certificate and bundle it.
<cory_fu> Right
<jose> hmm, good idea too
<cory_fu> Actually, I may be missing some context here.  Is this cert for something the charm is downloading from an external (but self-signed) resource, or for testing a service that self-signs itself?
<cory_fu> ("Self-signs itself?"  From the department of redundancy department.)
<jose> it generates a self-signed cert in order to enable SSL
<cory_fu> And you just want to test that it's up and running?
<jose> yeah
<cory_fu> Oh
<jose> not verifying any downloads or anything
<jose> it's just a unit test
<cory_fu> I thought you were talking about downloading a resource from a self-signed location
<jose> oh, nope
<cory_fu> I think just tacking on verify=False is fine for a test
<jose> ok then
<jose> I'm running the test now so let's see how it does
<cory_fu> Sorry to complicate the discussion by jumping in without looking.  :p
<lazyPower> cory_fu: hah :)
<lazyPower> <3
<lazyPower> all we really need to verify, is that a) its open on port 443, and b) it responds with context we define.
<lazyPower> teh SSL cert validation is a good idea though, and providing your own cert validates that it is indeed working with a certificate instead of faking it out by serving HTTP over HTTPS
<cory_fu> Yeah.  It would be better, but I'm not sure it's worth the extra headache
<cory_fu> Maybe if charm-helpers had some sugar for it
<jose> if this passes I'll push and then look into it, think it's worth it
<cory_fu> jose: Not to heap too much on you, but I was wondering if you saw my comments on the tracks charm?
<jose> cory_fu: yep, I did!
<cory_fu> thoughts?
<jose> I'm working on them now :)
<jose> sorry I missed the website-relation-joined, I thought I added it
<jose> about the rake db:migrate being called multiple times... I'm not sure if it breaks anything
<jose> maybe lazyPower knows? /me is no ruby expert
<lazyPower> jose: nope
<lazyPower> it wont break anything
<jose> awesome then
<lazyPower> it no-ops if there are no new migrations
<lazyPower> see: gitlab-ci charm for more examples
<lazyPower> https://code.launchpad.net/~lazypower/charms/precise/gitlab-ci/trunk
<jose> what the... timed out
<jose> cory_fu: changes pushed to the branch
<cory_fu> Thanks.  I'll take a look in a minute
<cory_fu> jose: There's still an issue with the port config setting.  Try changing it after deploying with the default port.  Because the .portnotsupported file doesn't exist, neither branch executes and the port doesn't change
<jose> cory_fu: that's why the if [ -f .port ] && [ `cat .port` != "${PORT}" ]; then is in place
<cjohnston> marcoceppi: anything stand out from those tests?
<cory_fu> jose: Oh, I see, yeah.  But there's still the issue of once the port is set to > 1024, the .portsnotsupported file is removed and so neither of the checks is ever made again, so you could set it to 3000 and then change it to 80
<jose> right
<jose> cory_fu: fixed and pushed
<cory_fu> Thanks!  :)
<jose> np :)
<jose> now, time for me to go and do some university stuff, be back later!
<cory_fu> Could we just remove that first block which references .portnotsupported entirely now?
<cory_fu> ok!
<cory_fu> ttyl
<jose> cory_fu: what?
<cory_fu> Oh, I was just saying that the first if / else in config-changed seems redundant now.  Not a big deal
<cory_fu> It looks like it'll work fine
<jose> ooh, got it
<jose> fixing
<jose> cory_fu: changes pushed!
<cory_fu> Thanks again!
<jose> np, let me know if there's anything else I could fix and I'll make sure to fix it once I'm back :)
<cory_fu> Awesome
<cory_fu> You're the best
<tvansteenburgh> hazmat, marcoceppi: either of you around?
<marcoceppi> tvansteenburgh: o/
<tvansteenburgh> hey so about this local charm amulet thing
<marcoceppi> yeah
<tvansteenburgh> it is actually deployer that can't handle a non-vcs charm
<tvansteenburgh> and i'm wondering if it must stay that way
<marcoceppi> tvansteenburgh: basically, and there's no reason that should change
<marcoceppi> tvansteenburgh: the "branch" key assumes a VCS
<tvansteenburgh> fair enough, i'll proceed with your original idea then, thanks
<marcoceppi> tvansteenburgh: we could use the "charm" key
<marcoceppi> and set JUJU_REPOSITORY
<marcoceppi> and build it that way instead
<marcoceppi> either way requries you to build a directory
<tvansteenburgh> yeah ok
<tvansteenburgh> i thought it was curious that deployer required your charm dir to be in vcs
<tvansteenburgh> but if it must be so, that's fine
<marcoceppi> tvansteenburgh: only using the branch options
<marcoceppi> tvansteenburgh: if you use 'charm' intead it doesn't have to be
<natefinch> marcoceppi: where's the right place to report a bug for the wordpress charm?
<marcoceppi> natefinch: http://bugs.launchpad.net/charms/+source/wordpress/
<waigani> fwereade: replace was a typo. I don't know how I managed to propose that, as I thought I'd reverted those changes. Sorry.
<fwereade> waigani, no worries, all too easy to do
<hazmat`> tvansteenburgh, deployer absolutely supports non-vcs scharms..
<cory_fu> jose: You around?
<jose> cory_fu: just came back!
<jose> perfect timing!
<cory_fu> :)
<cory_fu> I was just testing the changes on tracks, and I got one more error
<jose> what's it?
<cory_fu> 2014-05-08 21:26:11 INFO config-changed /var/lib/juju/agents/unit-tracks-0/charm/hooks/config-changed: line 7: 1025: No such file or directory
<cory_fu> I think we need to double up the brackets.  [[ "$PORT" < 1025 ]]
<jose> oooh that's right
<jose> cory_fu: pushed
<cory_fu> Thanks
<cory_fu> Checking
<jose> ok!
<cory_fu> jose: I'm still not able to change the port after deployment for some reason.  :(
<jose> cory_fu: let me deploy and debug what's going on
<cory_fu> Were you able to change the port?  It seems like the .port file isn't in place for me
<jose> it should be on place
<jose> but let's check
<cory_fu> Oh!
<jose> huh?
<cory_fu> db-relation-changed does a cd /home/tracks/tracks before it creates the .port file
<cory_fu> But the config-changed hook checks looks for it in the charm dir
<jose> boom!
<cory_fu> :)
<jose> good catch
<jose> let me deploy before pushing, I want to make sure it works
<cory_fu> jose: I have to head out for the evening.  I might be back on briefly a bit later, but most likely, I'll review what you push tomorrow morning.  Thanks again for being so on top of this!  :)
<jose> no problem
<jose> it's supposed to be changing ports now :)
<cory_fu> Excellent  :)
<qhartman> anyone working on maas/juju/openstack deployments, feel free to drop into #majuos .
<Term1nal> http://pastebin.com/fi86u6DK trying to deploy openstack-dashboard
<benji_> k/quit
<Term1nal> how would I go about seeing how many containers I'm running on a node?
#juju 2014-05-09
<marcoceppi> Term1nal: juju status?
<mhall119> holy crap it worked!
<jose> mhall119: what? what? I just heard an explosion!
<mhall119> jose: it was my head
<mhall119> juju just blew my mind :)
<jose> haha, what did it just do?
<mhall119> I deployed 5 services to 5 machines with all relations and it "just worked"
<mhall119> even using haproxy, which I've never used before, I just deployed it, added a relation to my summit charm, and boom, it's scalable
<mhall119> after fighting with charms and juju and lxc all week, I'm so happy right now
<mhall119> jose: http://paste.ubuntu.com/7419267/ :)
<mhall119> it's so pretty
<rick_h_> mhall119: woot!
<jose> cool!
 * jose is excited to see that summit charm
<sarnold> oooo
<mhall119> jose: https://code.launchpad.net/~mhall119/summit/charm
<jose> awesome!
 * jose <3 summit
<Tug> I have an error when running debug-hooks: duplicate session: shard1/0   Connection to ... closed.
<Tug> I have no other session opened
<Tug> Ok, I found a workaround here: https://bugs.launchpad.net/juju-core/+bug/1255502
<_mup_> Bug #1255502: juju debug-hooks can fail with duplicate session <debug-hooks> <juju-core:Triaged> <https://launchpad.net/bugs/1255502>
<cjohnston> marcoceppi: ping
<lazyPower> cjohnston: he's out today
<cjohnston> lazyPower: ack.. how good are you with amulet ;-)
<lazyPower> Moderately good - I can try to answer your question :)
<_benoit_> Any juju-core developper here ?
<_benoit_> I am trying to find how I could reuse bits of the ec2 implementation in the outscale implementation
<_benoit_> I saw that the types names of the ec2 implementation where not capitalized (exported) so I don't see how I could embed them for reuse
<cjohnston> lazyPower: /27
<cjohnston> sorry for the ping
<lazyPower> no worries
<lazyPower> whats up
<cjohnston> lazyPower: so I have a test running.. and I am attempting to get the IP and port for the instance.. I get a KeyError on open-ports
<cjohnston> lazyPower: L77 http://paste.ubuntu.com/7417300/ I guess it shows complete, then 2 seconds later is starts another deployment... L78 shows the output of a command that is being run by the test, where we are trying to get the IP address and the open ports.. the open ports dont exist yet for some reason.. L84 is that same command, and they exist there
<lazyPower> can you link me to your test code?
<cjohnston> lazyPower: http://bazaar.launchpad.net/~canonical-ci-engineering/uci-engine/trunk/view/head:/tests/test_ppa_assigner.py
<lazyPower> interesting use of amulet
<lazyPower> It may be running through the code before it's finished standing up. try adding a d.sentry.wait()
<lazyPower> that will ensure the sentry units hang the text execution until the topology has 'settled'
<cjohnston> how should we be using amulet?
<lazyPower> s/text/test
<lazyPower> this is by no mean's wrong, but you're the first person i've seen introduce an amulet wrapper class like this :) i like it
<cjohnston> ack.. it wasn't me.. lol.. I can't take the credit
<lazyPower> this is cool stuff, i'm going to pass this off to my team so they can take a look as well
<rbasak> frankban: I cannot get juju-quickstart 1.3.2 as packaged working in Utopic. I've filed a bug on this.
<rbasak> frankban: it may be a juju bug, I'm not sure. But this blocks an SRU to Trusty.
<frankban> rbasak: what's the problem?
<_benoit_> niemeyer: Hi
<niemeyer> _benoit_: Heya
<_benoit_> niemeyer: you seems to be owner of juju core so I would like to ask you what is the best way to integrate the Outscale cloud in juju-core
<rbasak> frankban: details in bug 1317939. It just doesn't work.
<_benoit_> niemeyer: It's mostly ec2 compatible but without s3
<niemeyer> _benoit_: Hmmm.. can we catch up in ~1h?
<_benoit_> niemeyer: yeah sure
<niemeyer> _benoit_: I need to step out for lunch imminently
<niemeyer> _benoit_: Thanks!
<jcastro> ERROR state/api: websocket.Dial wss://10.0.3.1:17070/: dial tcp 10.0.3.1:17070: connection refused
<jcastro> does anyone remember how to get around this?
<avoine> oh oh, I think Rodney Quillo's new ansible release breaks all the charms that use it...
<_benoit_> niemeyer: re
<niemeyer> _benoit_: yo
<_benoit_> niemeyer: should we go private to discuss this ?
<_benoit_> niemeyer: first question do you have time right now ?
<niemeyer> _benoit_: I do have some
<niemeyer> _benoit_: If it's about juju, we can stay here, or go to #juju-dev
<tvansteenburgh> avoine: how so?
<avoine> in 1.6 ansible try to read file that starts with { as json
<avoine> but charm-helpers use yaml
<avoine> tvansteenburgh: ^
<lazyPower> well this is weird, the rails-charm references vim-rails as it's upstream counterpart? https://code.launchpad.net/charms/+source/rails
<tvansteenburgh> avoine: thanks for the heads-up
<tvansteenburgh> avoine: i wonder if there's an option to use the old behaviour?
<lazyPower> avoine: When did that land?
<tvansteenburgh> yesterday it looks like
<lazyPower> urgh so its in the debian package then?
<tvansteenburgh> yep
 * lazyPower deploys gitlab-ci to validate its not broken
<avoine> the error is like: 2014-05-09 19:08:00 INFO install fatal: [localhost] => /etc/ansible/host_vars/localhost: Expecting property name: line 1 column 1 (char 1)
<avoine> I think it could be fix in charm-helpers/contribs/templates/context.py by removing the parentesis around the yaml
<avoine> * contrib/templating/contexts.py
<lazyPower> sinzui: was vim-rails registered against the rails charm to share bugs? Is it going to peeve anyone off if i remove this uplink?
<sinzui> lazyPower, 99% chance it was an error
<lazyPower> awesome. Thanks
<sinzui> most people who link to distros do more harm than help
<avoine> tvansteenburgh: fyi https://bugs.launchpad.net/charm-helpers/+bug/1318036
<tvansteenburgh> avoine: thank you!
<tvansteenburgh> avoine: did you want to propose your branch for merging? your change lgtm assuming all the tests pass, but i don't have the power to merge it
<tvansteenburgh> avoine: will probably need to wait for marcoceppi to merge
<avoine> tvansteenburgh: yeah, should I create a merge request?
<avoine> ok
<tvansteenburgh> avoine: yes, please do
<lazyPower> tvansteenburgh: ping me once your +1's are on the MP
<lazyPower> i'll do a quick review and ack it if it's good
<avoine> tvansteenburgh: done https://code.launchpad.net/~patrick-hetu/charm-helpers/default_flow_style/+merge/219063
<lazyPower> dude, perfect
<lazyPower> avoine: thanks for this fix!
<marcoceppi> jcastro: sudo start juju-db-local-jorge
<jose> lazyPower: still around?
<lazyPower> for a minute or two, whats up jose?
<jose> lazyPower: hey! you said your owncloud tests passed when you did them, would you mind pastebinning the test so I can see if they work for me?
<jose> (in the case you still have those changes)
<jose> I'm getting these random timeouts
<lazyPower> jose: it's whatever is in trunk of the owncloud charm
<jose> hmm... ok(?) (that shouldn't work)
<lazyPower> jose: running them against amazon now
<lazyPower> i'll stick around until they complete running
<jose> thanks! I'm running my tests once more to see if they for any magic reason work
<jose> lazyPower: unit relation-sentry failed hook install
<lazyPower> did you --set-e?
<lazyPower> if you did, can you ssh-import-id on the unit so i can remote in and take a look at the logs?
<lazyPower> actually, i got that too, so nevermind. I'll re-run it with --set-e
<jose> sorry, nope :(
 * lazyPower scratches head
<lazyPower> they worked at one point... otherwise they wouldn't have been acked.
<jose> I find it weird... *that's* the one which shouldn't fail!
<lazyPower>  (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
<lazyPower> well mine filed on deploying the relation sentry
<lazyPower> so
 * lazyPower looks shifty
 * lazyPower breaks for food while this runs its course
<jose> lazyPower: got the timeout again, even though seconds was set to 3000, which is 50mins
<lazyPower> jose: http://paste.ubuntu.com/7425609/
<jose> so that's the thing?
 * jose grrs
<lazyPower> jose: looks like the tests tanked after the merge to update owncloud
<lazyPower> i just reverted back to rev 23 and they work
<jose> so, what should we do?
<jose> I'm not entirely sure on what do to now
<lazyPower> jose: the tests are going to have to be updated. The update got merged without checking the tests
<jose> I personally don't see what could've changed
<lazyPower> file a bug, assign to me, note in the MR that the tests need updated unless you feel like starting from square 0 and rewriting them.
<lazyPower> i'll get to them when I get some time to cycle on it. Possibly later this weekend depending on whats going on
<jose> hmm, will do
<lazyPower> Thanks jose
<jose> thanks to you!
<lazyPower> I'm goign to head out for the evening. o/ appreciate the cycles on trying to discover whats wrong with the owncloud tests
<jose> you have a good rest of your day!
<Term1nal> question about juju, trying to wrap my head around: say for example I do something dumb easy like wordpress and mysql in juju. If I set 2 mysql units for 1 wordpress unit, if one of the mysql units goes down, it's already good to go?
<jose> I'm not exactly sure about how that would go
<Term1nal> I guess I don't understand what the purpose of deploy more units of mysql would do exactly. Do they already replicate at that point?
<jose> I personally don't know, someone else should be able to help around
<sarnold> Term1nal: in general, I think you'd have to check the charm's README to know the capabilities of each charm.
<sarnold> Term1nal: for mysql, it looks like you can deploy mysql slaves easily enough to improve read performance: http://manage.jujucharms.com/charms/precise/mysql
<sarnold> off to walk the dog :) have fun
<Term1nal> I can grok that, but in the juju-gui, what is the benefit of just increasing the amount of units deployed?
<Term1nal> http://askubuntu.com/questions/369231/juju-mysql-adding-units-vs-adding-new-service-with-relation I think that sums up what I was wondering about.
<Term1nal> So adding more units to the charm doesn't do anything :D
#juju 2014-05-10
<Term1nal> Well, after exposing openstack-dashboard, I try to visit it in a browser and am met with an "index of /"
<Term1nal> aww derp /horizon
<rick_h_> Term1nal: heh yea that came up that we need to allow services to express not just exposed but an endpoint for stuff like that
<Term1nal> lol
<Term1nal> rick_h_: quick question.. now that I have it up and running, where do I actually glean the admin credentials for a freshly deployed juju openstack? :D I imagine, the container I deployed keystone to?
<Term1nal> I'm tryin' to3 figure out how to SSH into a container on a remote box.
<rick_h_> Term1nal: that's a good question I don't know about.
<Term1nal> oh..
<Term1nal> wow
<Term1nal> I just SSH'd into the container's IP with ubuntu@addrhere
<rick_h_> yea, it auto adds your ssh key to the instances
<Term1nal> rick_h_: yeah, got that... but now the only password I can glean is the admin_token, which doesn't do me any good for logging into horizon as far as I can tell :D
<Term1nal> anywho, quittin' time
<Term1nal> back at it tomorrow
<Term1nal> peace
<_sEBAs_> hey people! :)
<_sEBAs_> somebody knows if it is possible to have the lxc "server" remotely for the local env type?
<_sEBAs_> that's what i call a silence room hehe
<ahasenack> hi, someone around to review this simple fix? https://code.launchpad.net/~ahasenack/charm-helpers/charm-helpers-ceph-lvm-1317980/+merge/219105
#juju 2014-05-11
<lazyPower> o/ jose
<jose> hey lazyPower!
#juju 2015-05-04
<blahdeblah> Morning all - what do I need to do to get https://code.launchpad.net/~paulgear/charms/trusty/ntp/fix-divide-by-zero/+merge/255660 moving?
<lazyPower> jrwren: ping
<lazyPower> blahdeblah: diff on this MP looks pretty significant compared to what was merged
<lazyPower> blahdeblah: ping me when you circle back around. The changes look related to the test suite vs the hook code - just want to verify intent of this MP
<jrwren> lazyPower: pong
<lazyPower> jrwren: hey dude, hi5 on this logstash charm
<lazyPower> I added a UDP ruleset, and things are magical
<jrwren> lazyPower: cool.
<lazyPower> its using like, 40-60% fewer resources than what i have in /TRUNK as well
<lazyPower> http://i.imgur.com/bTk01BM.png
<jrwren> lazyPower: yes, I like small things
<jrwren> lazyPower: oooh... I Love seeing that logstash icon there. :)
<lazyPower> With UOS being this week - think you'll have time later on like thurs/fri to do a sync on how we can reconcile the divergence?
<lazyPower> i think its just a minor patch to rules inc. from IS, + some UDP rulesets to make this charm robust in receiving from jsut about anything.
<jrwren> lazyPower: yes. Thurs/Fri sounds good
<lazyPower> the TCP works - but not for my application :)
<lazyPower> awesome. Lets get it on the calendar so i dont flake on you. ping me with an invite when you've got an opening and i'll work around it
<jrwren> i think I have some incomplete filter changes myself.
<jrwren> lazyPower: my calendar is wide open, it may be easier for you to pick, but if you don't, I will :)
<nevermam> when deploying a charm, I want to know the service name and the charm name, inside the hook
<nevermam> LIke for eg,
<nevermam>  juju deploy mysql myapp-db
<nevermam> I want to know the service name, inside the install hook
<nevermam> is there any environment variable for the same ?
<blahdeblah> lazyPower: pong
<blahdeblah> lazyPower: I'm about to turn into a pumpkin, so I'll leave you some explanation here, and hopefully that will be enough; otherwise I'll try to catch you at the end of your day today.
<lazyPower> nevermam: when you're in a hook context, run 'env | grep JUJU` and that will give you everything thats available to you
<blahdeblah> lazyPower: I merged the current trunk into the patch to minimise the diffs from my perspective; apologies if that makes it trickier to read the diff.
<lazyPower> blahdeblah: no worries - teh lions share of the changes appear to be in a test file , i spent a good 15 minutes staring at it before i moved on -but i will circle back and get you another review.
<blahdeblah> lazyPower: which test file is that?  I didn't think I had added that, but I could be wrong.
 * blahdeblah looks again
<lazyPower> files/nagios/check_ntpmon.py
<blahdeblah> That's not a test file; that's a Nagios check
<blahdeblah> That is the problem component against which the bug was reported
<blahdeblah> Bug #1441704
<lazyPower> ah, explains why i thought that :) I thought you were doing a health-check in a test
<mup> Bug #1441704: check_ntpmon.py tries to divide by 0 if there is no peer in sync <ntp (Juju Charms Collection):Fix Committed by paulgear> <https://launchpad.net/bugs/1441704>
<lazyPower> I'll deploy + validate this later and get feedback on it. Thanks for confirming intent
<blahdeblah> lazyPower: Short backstory: I wrote the Nagios check for NTP because we couldn't find any existing ones that actually were useful, plus I wanted something to work on to improve my python.
<blahdeblah> lazyPower: And axino is pretty good finding bugs in my python, so I've been fixing them and adding tests for them as we find new issues when we deploy it.
<blahdeblah> lazyPower: The diff is a bit bleh to read; you may find it easier to just read the upstream code (I've just updated the link to it in the MP) and take my word for it that it's a verbatim copy of upstream. :-)
 * blahdeblah ejects for the evening
#juju 2015-05-05
<jcastro> marcoceppi, do you want to lead "What's new in Juju 1.23"? or should I snag someone from core?
<marcoceppi> jcastro: happy to lead, I'll have a demo environment setup
<jcastro> ok awesome
<jcastro> then cory_fu, want to join us after that for debugging and services framework?
<jcastro> then it's us two again for sos and share
<jcastro> and then it's whit, bruzer, and lazyPower for the final session
<lazyPower> jcastro: just whit and I, bruzer appears to be out today
<jcastro> noted
<mwak> o/
<lazyPower> \o mwak
<marcoceppi> jcastro: can we swap sos/share with docker?
<jcastro> hmm, I already sent the schedule to the list, blogged, etc. can we avoid it?
<jcastro> or do we have to?
<marcoceppi> well I won't be able to make it
 * marcoceppi is technically off today
<lazyPower> let me check, i have a charm school at that time i think
<jcastro> I'd rather just fill in for you than move it
<lazyPower> 2-3pm EDT = me charm schooling w/ plumgrid
<jcastro> I know the spec well enough I think
<marcoceppi> ok
<marcoceppi> I'll try to make it
<cory_fu> jcastro: Yep, I registered for it on the site.
<jcastro> marcoceppi,  https://plus.google.com/hangouts/_/hoaevent/AP36tYdytKcXZkxm2XQPwSIZiIxYD3ZDCAUP0f6G9CvgYxn66pq4EA?authuser=0&hl=en
<mwak> o/
<jcastro> marcoceppi, https://plus.google.com/hangouts/_/hoaevent/AP36tYd8RSWXkZw5HhTna2yqHuIc06JqufLI3MxrsuXKq-S12rTYBg?authuser=0&hl=en
<lazyPower> beisner: plumgrid is asking when kilo charms are going to be released. any ETA on that?
<beisner> hi lazyPower, while there may be some final charm tweaks, the charms are already kilo-aware.  kilo packages, however, are in flight at the moment.  they hit proposed today, and we're running validation on those.   this one is a bit tricky as we had to release the 15.04 charms while Kilo was still in RC2.
<beisner> also for clarity, the Trusty OpenStack charms are forward and backward compatible to all currently-supported combinations of Ubuntu + OpenStack.   And that list is:  Precise-Icehouse, Trusty-Icehouse, Trusty-Juno, Trusty-Kilo, Utopic-Juno, Vivid-Kilo.
<jcastro> cory_fu, kwmonroe: 30 minute warning for the big data session
<cory_fu> thx
<kwmonroe> ack
<jcastro> cory_fu, https://plus.google.com/hangouts/_/hoaevent/AP36tYcFfoxfMTDnTxexhzOxtg2B4_QqGzQTC82juF0gx_6s7YkjLg?authuser=0&hl=en
<dpb1> Is there anyway to see what hooks are running?  I have some charms that look like they are storming back and forth, but I can't figure out what hooks are doing it.
<mgz_> dpb1: `juju help debug-hooks`
<dpb1> ya, wanted a log based approach, but this is what I landed on
<dpb1> i.e., for all the stuff written to the logs, something like "Firing hook: config-changed" would be appreciated.
<rick_h_> dpb1: if the hooks add support for the new status stuff it'll be cool/useful.
<dpb1> rick_h_: will status stuff dump out to logs?
<dpb1> rick_h_: btw, filed https://bugs.launchpad.net/juju-core/+bug/1452050 for this request
<mup> Bug #1452050: Add log when firing hook <landscape> <juju-core:New> <https://launchpad.net/bugs/1452050>
#juju 2015-05-06
<wgrant> Using juju-core 1.23.2 with the local provider on a vivid host with trusty containers, I'm not seeing config-changed fire.
<wgrant> debug-hooks never shows anything, despite no errors being visible in juju status.
<wgrant> machine-0: 2015-05-06 00:18:04 ERROR juju.worker runner.go:219 exited "machiner": cannot set machine addresses of machine 0: cannot set machineaddresses for machine 0: state changing too quickly; try again soon
<wgrant> is filling my logs, but that's about the only interesting thing.
<lazyPower_> wgrant: meaning it just skips? or you only get the install hook executed - and the rest of the hook queue is silently dropped?
<wgrant> lazyPower_: I assume the install hook fired, as my services started. But even after a container reboot I still get nothing showing up in debug-hooks after I change config on any of my services.
<lazyPower_> wgrant: install wouldnt necessarily equate to started - that means it thinks it reached the start hook. :|
<lazyPower_> but, no config-changed after updating config is troubling
<lazyPower_> are you certain there's nothing attached to a unit blocking hook context? eg: debug-hooks on a unit in a dependent container?
<wgrant> lazyPower_: Well, I know install or config-changed fired at some point, as code that's only run in those cases has run at least once.
<wgrant> Er, install or upgrade-charm, rather.
<lazyPower_> right, i'm thinking what else could block a config-changed event
<lazyPower_> but if no service is in error, no subordinates attached that are quietly in error, and no debug-hooks action on the unit... it seems like you've uncovered a bug :(
<bdx> Hows it going everyone?
<bdx> Can anyone give a few examples for possible values for the flat-network-providers config
<bdx> for quantum-gateway?
<thumper> bdx: https://jujucharms.com/quantum-gateway/trusty/16 says "Space-delimited list of Neutron flat network providers."
<thumper> bdx: I'm not sure what an individual Neutron flat network provider looks like
<thumper> but a wild stab in the dark would ip addresses
<lazyPower_> thumper: you and I need to learn more about our big buddy openstack.
<thumper> lazyPower_: almost certainly
<thumper> lazyPower_: I'll put it up there with paxos and raft
<thumper> :)
<lazyPower_> I kinda sorta understand raft
<lazyPower_> paxos however - pfffffffffffffffffft
 * thumper goes back to implementing 'juju system login'
<lazyPower_> aint nobody got time for that
<bdx> thumper: Thanks
<bdx> Does anyone know where a good example of deploying a dvr stack using juju might be located at?
<lazyPower_> bdx: are you referring to like deploying mythbuntu? (dvr = digital video recorder?)
<lazyPower_> gsamfira: o/
<bdx> lazyPower: no....openstack with dvr
<lazyPower_> bdx: ah, looking into neutron stuff. i had to google it
<lazyPower_> sorry :( i'm not going to be much help in this effort.
<lazyPower_> hazmat: ping
<hazmat> lazyPower_: pong
<lazyPower_> hazmat: I found a solution to my problem during the break :)
<hazmat> lazyPower_: cool
<jcastro> lazyPower_, https://plus.google.com/hangouts/_/hoaevent/AP36tYfpg6vIOgpBcl3zoASu8vfjOaJViFvk6yT4g7z7CfU8B6QnCw?authuser=0&hl=en
<mgz_> lazyPower_: when you have a mo, can you give some feedback on what output you actually want in the error cases for bug 1444861?
<mup> Bug #1444861: Juju 1.23-beta4 introduces ssh key bug when used w/ DHX <dhx> <ssh> <juju-core:Triaged> <juju-core 1.24:In Progress by hduran-8> <https://launchpad.net/bugs/1444861>
<mgz_> perrito666 has a branch up, and it's pretty simple to make the output less vile at the same time
<mgz_> (I'm thinking duplicate notices should just give fingerprint not whole line, and maybe we want to be more careful about what we call invalid?)
<lazyPower_> mgz_: thanks for the follow up - I think thats a fine solution - i've also referred cory_fu the author of DHX to this error for his feedback if any.
<mgz_> lazyPower_: ta
<ennoble> Anyone know if it's possible to get the juju action id from within the action environment?
<aisrael> ennoble: Yes, it should be there. I can check the key
<aisrael> charmers: This MP needs you: https://code.launchpad.net/~hatch/charms/precise/ghost/trunk/+merge/255168
<ennoble> aisrael: I can't seem to find it in any environment variables, action-get, ...
<aisrael> ennoble: JUJU_ACTION_UUID
<ennoble> - id: e23d3f13-15d6-4b82-8af5-1e151537892a   status: pending unit: test/0
<ennoble> aisrael: interesting, I don't see that environment variable in my action environment. I'm running 1.23.2-trusty-amd64 There is a JUJU_CONTEXT_ID and a JUJU_ENV_UUID=
<aisrael> When you say 'action environment', are you testing this from machine you're running juju from, or inside an action when it's being executed (the action context)
<ennoble> aisrael: inside the action when it's being executed. So I'm running juju debug-hooks <unit name>  and then running juju action do ... on another terminal. the action environment starts in debug-hooks tmux session and I'm looking at the environment variables
<hatch> aisrael: hey that was merged
<hatch> ohh nm
<hatch> it was reviewed but never merged :)
<aisrael> hatch: Yeah, oops!
<hatch> YEAH! get on it :P
<tvansteenburgh> aisrael, hatch: i'll merge it now
<hatch> :) thanks tvansteenburgh
<hatch> that reminds me I should get back working on that
<hatch> I'm torn on how to do backups though...
<hatch> and upgrades
<aisrael> ennoble: action's can't be caught via juju debug-hooks, afaik. It's something we've asked to put on the roadmap for actions 2.0
<ennoble> aisrael: Are you sure? it's happening for me
<ennoble> aisrael: the JUJU_HOOK_NAME is set to the action name and the parameters I passed to the action are available via action-get, so I'm fairly certain it's working
<aisrael> ennoble: confirming
<jw4> aisrael, ennoble  yeah, I discovered recently that debug-hooks works with actions
<aisrael> jw4: Excellent. Do we know if it's 100% working, i.e., the issue ennoble is seeing?
<aisrael> sounds like he's getting a hook context env rather than the action's context
<jw4> aisrael: no, it's accidentally working so I can easily imagine issues like ennoble is reporting
<jw4> we can file a bug and get that fixed
<aisrael> charmers: This one needs some attention. I just +1'd it, based on the testing I did pre-Malta to fix an amulet bug (since released): https://bugs.launchpad.net/charms/+bug/1366834
<mup> Bug #1366834: [New charm] Ubuntu repository cache for cloud partners <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1366834>
<aisrael> jw4: Will you file, or would you like me to do it?
<ennoble> aisrael: sorry I dropped off; is the JUJU_ACTION_ID available in a newer version of juju?
<aisrael> ennoble: The action working in the debug-hook is kind of accidental, and doesn't appear to be working the same as your running action would see it.
<ennoble> aisrael: ok, so if I don't use the debug-hooks I should see the JUJU_ACTION_ID variable?
<aisrael> ennoble: correct. We'll get a bug filed for that so the behavior works as expected in a future release
<ennoble> aisrael: thx! one more actions question: are the actions guaranteed to execute in the order that they were submitted by a single user? I found a discussion about this about 6 months ago on the mailing list and it looks like the conclusion was they should.
<aisrael> ennoble: Yes, they work like charm hooks in that they're queued and run in the order submitted
<ennoble> aisrael: and charm hooks are ordered with actions as well? e.g. juju set ... juju action ... juju set ... juju action would respect that order?
<rick_h_> https://wiki.ubuntu.com/MOTU/GettingStarted
<aisrael> ennoble: I believe it should, yes.
<rick_h_> whoops, wrong channel ignore me
<ennoble> aisrael: thx again
<jw4> aisrael: sorry, OTP
<aisrael> stub: you around?
<lazyPower_> hatch: i lied, ping.
<lazyPower_> er
<lazyPower_> hazmat: i lied, re:ping.
<hatch> what
<ennoble> aisrael: I don't think JUJU_ACTION_ID is being set, even outside of the debug-hooks. i just logged all the environment variables and it's not there
<hatch> oh :)
<hazmat> lazyPower_: what's up?
<lazyPower_> hazmat: any chance we can co-maintain the pypi project for juju-deployer?
<hazmat> lazyPower_: sure
<hazmat> lazyPower_: what's your pypi id?
<lazyPower_> tvansteenburgh :D
<lazyPower_> hehe, hang on, lemme fish that up
<lazyPower_> pretty sure its lazypower - but i need to double check
<tvansteenburgh> yeah add me too
<hazmat> lazyPower_: :-) that works.. i'll have to do it when i get home. don't have my credentials on my current computer
<aisrael> ennoble: it should be JUJU_ACTION_UUID
<ennoble> aisrael: maybe I'm doing something wrong, but I'm not seeing it
<aisrael> ennoble: Can you pastebin what you're seeing? I'll get an environment w/actions spun up shortly and verify
<jw4> aisrael: just got off the phone, but I'm out for a bit now.. if you'd like to file the bug that would be great.  Thanks!
<aisrael> jw4: you got it
<lazyPower_> duuuuude
<lazyPower_> testing windows charms? use pester! https://github.com/pester/Pester
<lazyPower_> #TIL
<rick_h_> lazyPower_: ah yea cloudbase showed that off in nuremberg
<lazyPower_> i just learned about this, i'm really impressed at the level of tooling they've written around charming for windows
<lazyPower_> ahhh they didnt write pester, they just consumed it with great success.
<lazyPower_> nifty all the same
<jcastro> office hours here: https://plus.google.com/hangouts/_/hoaevent/AP36tYeqRbxEExDyG6Q6yjS24zxmhYScseYHDXq0S7Z59CrheB_ahg?authuser=0&hl=en
<jcastro> office hours here: https://plus.google.com/hangouts/_/hoaevent/AP36tYeqRbxEExDyG6Q6yjS24zxmhYScseYHDXq0S7Z59CrheB_ahg?authuser=0&hl=en
<jcastro> for those of you on the other side of the netsplit
<jcastro> we'll be taking questions here and in #ubuntu-uos-cloud
<hazmat> lazyPower_: added tvan for it, i don't see a pypi user for you
<lazyPower_> bueno, i'll bug tim for gating :)
<lazyPower_> thanks hazmat
<hazmat> rick_h_: is there anyone on your team you want to have pypi uploads for deployer ?
<rick_h_> hazmat: francesco and/or brad would be cool, but if we've got the others with access I'm happy to work through them
<hazmat> rick_h_: added frankban
<rick_h_> hazmat: ty
<ennoble> aisrael: are you still around? here is the environment that I see http://pastebin.com/CdsuN7Sd I printed it from a python action so it's a dict (os.environ)
<ennoble> aisrael: I see in the code where it's supposed to have JUJU_ACTION_(NAME|UUID|TAG) but it doesn't appear to be happening in my environment
<aisrael> ennoble: what version of juju are you running?
<ennoble> aisrael: 1.23.2
<aisrael> ennoble: Huh. Definitely a little strange. What's the command line you're invoking the action with?
<ennoble> aisrael: juju action do test/0 bench
<aisrael> ennoble: here's what my env looks like: http://pastebin.ubuntu.com/11000481/
<aisrael> ennoble: Did you upgrade an environment from a previous version of juju?
<ennoble> aisrael: possibly. I certainly was using 1.22 previously but I'm fairly certain I destroyed it and started over, however I'll do that now just in case
<aisrael> ennoble: if you run a juju status, you could see if the unit agents are on the newer version of juju
<aisrael> The only difference I see is the provider. I'm using local, but you're on maas. I wouldn't think that would make a difference, though.
<ennoble> aisrael: yes, the agent version is 1.22,1
<aisrael> ennoble: Ahh, that would probably do it. Either a fresh environment, or `juju upgrade-juju --upload-tools` should take care of it
<ennoble> aisrael: thanks for all your help and sorry about the wild goose chase
<aisrael> ennoble: No worries! I'm glad we figured it out.
<aisrael> ennoble: Also, you should also see the JUJU_ACTION_ variables when you run debug-hooks
<aisrael> jw4: fwiw, I am able to use debug-hooks against actions and everything appears to work.
<jw4> aisrael: nice, thanks for verifying and letting me know too
<ennoble> is there a floating point type that works with actions?
<aisrael> `float` should work, I think
<ennoble> aisrael: it seems like 1.23 is much more strict on action types.. int doesn't work but integer seems to, however float doesn't: invalid action "bench": float is not a valid type
<lazyPower_> i thought actions only supported the same var types we have implemented for config - int, bool, and string
#juju 2015-05-07
<stub> aisrael: Nope, but ping me tonight when you are on
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/neutron-api/kilo-dvr/+merge/258370
<jrwren> i'm having trouble bootstrapping on azure. looks to be a simple streams issue. http://paste.ubuntu.com/11009960/
<marcoceppi> jrwren: weird
<jrwren> Seems to only happen in North Central US
<jrwren> West US hangs on Installing package: cloud-utils
<lazyPower_> jrwren: i can kick off a charm test on azure and see what the general response is from another perspective if you'd like.
<lazyPower_> however i'm not sure  we're looking at the other AZ's in a cloud provider. it hink its isolated to a single AZ
<g3naro> ls -lhrt
<g3naro> hey anyone familiar with deploy mongodb cluster via juju
<g3naro> can do one node ez
<jrwren> the cloud-utils hang seems unrelated to inability to bootstrap in North Central US
<jrwren> I filed a bug: https://bugs.launchpad.net/juju-core/+bug/1452785
<mup> Bug #1452785: os-enable-refresh-update is false and some security packages are not available <juju-core:New> <https://launchpad.net/bugs/1452785>
<lazyPower_> g3naro: there are some race conditions with the mongodb charm and clustering that i'm aware of, specific to sharding + mongos configuration updates.
<g3naro> lazyPower_: ahh ok interesting, im just trying to follow some guide here
<g3naro> https://github.com/charms/mongodb
<g3naro> but with just one configsvr
<lazyPower_> ah, there's a bundle for that formation listed in the README
<jamespage> gnuoy, btw I pushed the renamed neutron-gateway charm to lp:~openstack-charmers/charms/trusty/neutron-gateway/trunk
<lazyPower_> g3naro: https://jujucharms.com/mongodb-cluster/4
<gnuoy> oooooooo, tip top
<jamespage> gnuoy, I'll push that to a /next as well and then update the next.yaml
<g3naro> lazyPower_: saw that,, but 0 deploys doesnt sound too promising
<lazyPower_> rick_h_: we had ~ 50+ deploys on that bundle before, do the deploy counters reset when a new revision is published? ^
<rick_h_> lazyPower_: no, it shouldn't checking
<g3naro> lazyPower_: how do i use this charm? i need to download it
<g3naro> and then deploy it to my cluster
<lazyPower_> g3naro: you can use quickstart if you have the juju-quickstart package installed
<lazyPower_> juju quickstart mongodb-cluster/4
<lazyPower_> if you need to edit the formation (reduce cfgsvr instances)
<lazyPower_> you can grab the bundle from BZR and deploy froma  local bundle
<lazyPower_> juju quickstart bundles.yaml
<g3naro> ohh k interesting
<g3naro> im new to juju as well
<g3naro> so have just installed in my desktop
<lazyPower_> https://code.launchpad.net/~charmers/charms/bundles/mongodb-cluster/bundle
<g3naro> i think just need 1 cfgserver for start
<lazyPower_> yeah, that bundle is kind of beastly at 13 machines out of the gate
<g3naro> yeah.. i dont understand enough mongodb
<lazyPower_> g3naro: what are you trying to do? and i can help - i'm no mongodb master, but i've used it enough in the past to be a certified mongoDBA against 2.4 - so i'm handy with it atleast.
<bbcmicrocomputer> anyone able to answer some quick questions on leader election functionality in juju 1.23.2?
<bbcmicrocomputer> specifically can a leader be unelected?
<bbcmicrocomputer> if so, what things fire then?
<bbcmicrocomputer> or is it the case that once you're elected as leader (leader-elected fires), you are the leader until you die
<bbcmicrocomputer> ?
<gnuoy> jamespage, if you find yourself twiddling your thumbs https://code.launchpad.net/~gnuoy/charm-helpers/status-set/+merge/258533
#juju 2015-05-08
<bdx> charmers, openstack-charmers: for 50 rupes ..... what is the purpose of ext-port and data-port params in neutron-openvswitch?
<bdx> charmers, openstack-charmers: From what I can gather, a hypothetical multi-provider l2/l3 configuration might look like: floating-pool-ext-net-1 --> network-node.eth0, floating-pool-ext-net2 --> network-node.eth1 ----- then we might expect our bridge_mappings to look like: physnet1:br-ex1, physnet2:br-ex2 ----- AND FINALLY THE data-port param could be: br-ex1:eth0 br-ex2:eth1 ? <------- this makes sense to me:
<bdx> eth0 --> br-ex1 --> physnet1, and eth1 --> br-ex2 --> physnet2. We could then create our floating pool nets on their respective interfaces by specifying --provider:physical_network=physnet1, --provider:physical_network=physnet2 and implement multi-provider...... am I on the right track here...as far as the data-port param is concerned?
<bdx> charmers, openstack-charmers: I guess where I am confused is why neutron-openvswitch should be concerned with a configuration of this nature....from what I can gather it only affects the neutron and neutron plugin conf files on nova-compute nodes....is this a common practice to  connect your floating pool provider networks to your compute nodes and network nodes too? <-- for dvr this makes sense... but should
<bdx> it have any implication elsewhere?
<bdx> charmers, openstack-charmers: I have a feeling I'm missing something here....could anyone help me out?
<bdx> jamespage: Could you give any insight on this?
<gnuoy> jamespage, +1 for https://code.launchpad.net/~james-page/charms/trusty/neutron-api/kilo-dvr/+merge/258370
<gnuoy> Happy for me to land it?
<gnuoy> It'd be good to get it into stable too
 * gnuoy lands it into next
<jamespage> gnuoy, ta
<apuimedo> jamespage: ping
<jamespage> apuimedo, o/
<apuimedo> jamespage: how's it going?
<jamespage> good thanks - and you?
<apuimedo> here, doing some changes to our charms for better interoperability :-)
<jamespage> apuimedo, awesome!
<apuimedo> jamespage: I found that it is better that I use the identity-service keystone relation for midonet-api
<apuimedo> the problem I encountered trying to use it is two-fold though
<jamespage> apuimedo, for registering the endpoints and getting credentials?
<apuimedo> yes
<jamespage> apuimedo, def the way togo
<apuimedo> midonet-api needs to get the admin-token
<apuimedo> so it should be a valid-service
<jamespage> you'll probably need to update keystone to understand the midonet service type
<apuimedo> so it should be in valid_services
<jamespage> apuimedo, yah - you got it :-)
<apuimedo> could I submit a patch to keystone stable about it?
<apuimedo> *the keystone charm stable
<apuimedo> the other issue, that does not directly affect me, since I need to be a valid service, is that for non_valid service, I think I stumbled upon a bug
<apuimedo> 2015-05-08 11:14:42 INFO identity-service-relation-changed   File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/keystone_utils.py", line 1521, in add_endpoint
<apuimedo> 2015-05-08 11:14:42 INFO identity-service-relation-changed     desc = valid_services[service]["desc"]
<apuimedo> you are accessing the desc field without checking if it is in valid services
<apuimedo> I mean, you call ensure_valid_service to remove the admin token
<apuimedo> but then on add_enpoint
<apuimedo> you uncondicionally will try access the fields
<apuimedo> -> Kaboom :-)
<apuimedo> uncaught exception
<apuimedo> jamespage: ^^
<jamespage> apuimedo, interesting
<apuimedo> :-)
<jamespage> apuimedo, please do submit a merge proposal for keystone for the new service types you need - that's 100% appropriate
<apuimedo> I think it warrants an amulet test for adding non valid services :P
<jamespage> apuimedo, well a unit test at least :-)
<apuimedo> at the very least, yes :P
<apuimedo> jamespage: do you need me to file the launchpad bug or you take care of it?
<jamespage> apuimedo, I guess the handling could be better - the identity-service relation expects endpoints with valid types to be presented - if that's not the case it errors - not sure whether that is better than handling with a log message or not
<jamespage> apuimedo, please file a bug :-)
<apuimedo> jamespage: well, the fact that there's specific code for removing the admin token from the returned data makes me think that the original intention was to allow arbitrary non-privileged endpoint additions
<apuimedo> so the fix, for keystone/next
<apuimedo> would be to either remove that capability or to make sure that it adds the endpoint ;-)
<jamespage> apuimedo, it might be - I did not write much of that code tbh so I'd have to go grok and learn
<apuimedo> who is ivok?
<jamespage> apuimedo, ivok?
<apuimedo> I see him as the author of this code in the bzr blame
<apuimedo> oh, I see, Ante Karamatic
<stub> gnuoy: Nothing says thank you like a reciprocal review -> https://code.launchpad.net/~stub/charm-helpers/integration/+merge/257748
<apuimedo> jamespage: https://code.launchpad.net/~celebdor/charms/trusty/keystone/midonet_valid_service/+merge/258624
<gnuoy> stub, thanks for the review.  I'm not keen on having the exits in status_set tbh, I was planning to run status_set multiple times in the same hook.
<anacapa> get a wire problem while using JUJU + MAAS
<anacapa> I have 8 nodes are in status "ready" at MAAS. when I use "juju add-machine" command, it will deploying 3 nodes at the same time.   but actually, I only want one.
<anacapa> In before, it will just request one machine. but suddenly switch to 3, after I run add several arguments to "juju add-machine " command like: juju add-machine -n 5,   juju add-machine zone=production.
<anacapa> but, when I switch batch to default command " juju add-machine" it always request 3 machine .....
<anacapa> does anybody have such kind of experience before? thx
<lazyPower_> anacapa: thats interesting behavior and the first time i've seen this reported
<lazyPower_> anacapa: which version of Juju are you using?
<sinzui> natefinch, mgz: can either of you review http://reviews.vapour.ws/r/1633/
<anacapa> lazyPower_ : 1.23.2-trusty-amd64
<anacapa> sorry, went to DataCenter just now
<anacapa> sorry, the version which has the described problem is: juju-1.22.1-trusty-amd64
<anacapa> I just upgrade it to 1.23.2
<anacapa> the problem appears again, even I  use command" juju add-machine -n 1". it asks 3 nodes from mass, and show me the error likes: "106":
<anacapa>     agent-state-info: 'cannot run instances: cannot run instances: gomaasapi: got
<anacapa>       error back from server: 409 CONFLICT (No available node matches constraints:
<anacapa>       zone=default)'
<anacapa>     instance-id: pending
<anacapa>     series: trusty
<nodtkn> juju version 1.23.2 does not appear to queue actions.  I have a script that bootstraps, adds two machines, deploys a service to each machine, adds a relation between the two services, and then runs an action.  That action occurs before the relation-changed hook is fired.
<nodtkn> I am expecting to much or doing something wrong?
<nodtkn> I have a one second sleep between each juju command.
#juju 2016-05-09
<blahdeblah> Is it weird of me that whenever I see $LAYER_PATH, I think SLAYER_PATH, and start thinking it's about metal?  Slayer? Excellent! (insert Bill + Ted sound bite here)
<rick_h_> blahdeblah: you've found out our secret!
<blahdeblah> rick_h_: :-D
 * blahdeblah cranks up some metal
<BlackDex> Hello there. I have the status: "agent is lost, sorry! See 'juju status-history ceph-osd/3" && "agent is not communicating with the server"
<BlackDex> I have restarted the agent on the servers but that doesn't seem to do the trick
<BlackDex> i can ping the bootstack server from the client-machine
<lathiat> BlackDex: what command did you use to restart the agent
<lathiat> thats a known issue you can restart the main jujud agent (not the unit specific part) to fix iirc
<BlackDex> lathiat: on the machines 'sudo initctl list | grep juju | cut -d" " -f1 | xargs -I{} sudo service {} restart'
<BlackDex> also a restart of the server isn't working
<lathiat> on xenial?
<BlackDex> trusty 14.04.4
<lathiat> what services does that restart in what order.. i fyou rnu like sudo ceho service {} restat instead
<BlackDex> sudo service jujud-unit-ntp-6 restart
<BlackDex> sudo service jujud-unit-ceph-osd-0 restart
<BlackDex> sudo service jujud-machine-8 restart
<BlackDex> sudo service jujud-unit-ntp-1 restart
<BlackDex> sudo service jujud-unit-ceph-mon-0 restart
<BlackDex> hmm... two ntp's :p
<BlackDex> ah, thats because of ceph-mon and ceph-osd
<BlackDex> on the same machine
<BlackDex> the strange thing is, it worked before
<lathiat> try restart the the machine agent first maybe
<BlackDex> hmm
<BlackDex> for some reason it has the wrong IP
<BlackDex> wrong subnet
<BlackDex> the bootstack server has two interfaces one external and one interal
<BlackDex> and now it uses the external interface
<BlackDex> i mean bootstrap
<BlackDex> lathiat: I'm now setting the correct ip address in the agent.conf and resting the agents
<BlackDex> that should work
<BlackDex> strange that it has been adapted
<BlackDex> that fixed it :)
<lathiat> ok interesting
<lathiat> the ip of the api server, or somtehing else?
<BlackDex> yea, of the bootstrap node
<Odd_Bloke> Hello all!  We have a CI environment configured using the jenkins and jenkins-slave charms.  However, we have some credentials that the slaves need access to that, currently, we just manually provision to the slaves.
<Odd_Bloke> We're using mojo to deploy our environment(s), so we do have a good way of managing secrets.
<Odd_Bloke> But we don't have a good way of getting those secrets on to hosts.
<Odd_Bloke> My first thought for addressing this is to have a subordinate charm which is configured with, effectively, a mapping from file name ->
<Odd_Bloke> content.
<Odd_Bloke> Does that sound like a reasonable solution?  Does anyone know of anything like this that already exists?
<BlackDex> lathiat: Strange. The bootstrap server has 2 ip's
<BlackDex> one external and one internal
<BlackDex> i need to force bootstrap to push the internal IP instead of the external as IP to the agents
<lathiat> BlackDex: interesting, can you show me some more details on pastebin?
<BlackDex> um
<BlackDex> is there a way to change the bootstrap IP?
<BlackDex> lets say you need to change because of infra changes
<ejat> http://paste.ubuntu.com/16316990/
<jamespage> beisner, hey - I keep hitting an issue where the neutron-gateway is given and extra nic, but the ext-port config is not set...
<jamespage> in o-c-t
<jamespage> have you seen that?
<jamespage> it causes failues in all of the tempest tests that check connectivity
<lazyPower> Odd_Bloke - that does sound reasonable but its fiddly to have to configure a subordinate. I'm wondering if you can't use native jenkins Credentials on the leader, that way the slaves can use jenkins primitives to surface those credentials?
<Odd_Bloke> lazyPower: Does the jenkins charm support loading credentials from configuration?
<lazyPower> Odd_Bloke - i think the only credentials it exposes at present is the admin username/pass... to make it consistent it would probably need to be extended. at one point we were using some python helpers in there to configure the instance
<lazyPower> but to be completely fair i haven't dug deep in the jenkins charm in > 4 months so i'm not sure whats going on in there these days.
 * lazyPower looks
<Odd_Bloke> lazyPower: I guess it also doesn't have any plugin-specific functionality ATM?
<Odd_Bloke> (Looking at the documented config options at least)
<lazyPower> right i'm seeing the same
<lazyPower> jcastro - didn't we engage with cloudbees/jenkins upstream wrt the jenkins charm?
<lazyPower> Odd_Bloke - well, my suggestion seems to involve a lot of engineering work, disregard me :)
<Odd_Bloke> lazyPower: ^_^
<lazyPower> but looking it over, it doesn't seem we're exposing a path to complete what you're trying to do with the charms.
<lazyPower> and that a subordinate would be a workaround... but i'm hesitant to say thats the best path forward.
<Odd_Bloke> Jenkins is a bit of a weird one.
<Odd_Bloke> Because the files we want on disk are really part of the "workload" that Jenkins runs in jobs.
<Odd_Bloke> Rather than the Jenkins workload itself.
<lazyPower> yep
<lazyPower> but, we do need to support rapidly deploying a workload on top of jenkins i feel
<Odd_Bloke> We were looking at https://jujucharms.com/u/matsubara/ci-configurator/trusty/0
<lazyPower> we've run into this very scenario quite a bit with our app-container workloads (kubernetes/swarm) - and layer-docker gave us an entrypoint into deploying/modeling workloads on top.  we're discussing what a layer for communicating with k8's and deploying k8s workloads looks like.. but it does somewhat decouple the workload from the charm as its runtime could be one of n units running kubernetes...
<Odd_Bloke> But we were discouraged from having Jenkins configuration changes deployed by doing a charm upgrade, for reasons I can't remember.
<lazyPower> almost seems like having jenkins as a layer, and a supporting library to model your workloads on top, then derive from layer-jenkinks to get your app runtime going, with a thin layer configuring jobs on top to make up your charm
<lazyPower> i dont know that i like that either.. advocating for snowflake jenkins instances
<lazyPower> i haven't had enough coffee... i'm going to go grab a cuppa and keep noodling this
<Odd_Bloke> :)
<lazyPower> one question tho: are these credentials to members participating? (eg: jenkins/0  and jenkins-slave/2) or are they unrelated units?
<simonklb> the dhcp leases are not initially set correctly when using LXD as provider - not sure if this is a lxc issue or specific to juju because of some hostname managing?
<Odd_Bloke> lazyPower: So the way we currently model our Jenkins stuff is that all jobs can run on all slaves, so we'd want the credentials on all slaves.
<lazyPower> Odd_Bloke - that makes this significantly easier
<lazyPower> you're now talking about a relation/interface modification
<lazyPower> or a new one
<Odd_Bloke> lazyPower: (Though our slaves are deployed in a different environment to our master, so they aren't actually related :( )
<lazyPower> o
 * lazyPower snaps
<simonklb> anyone else have experienced any problems with DNS:es not working straight away when deploying a new charm?
<lazyPower> simonklb - i cant point to a specific instance no, but having a bug to reproduce/reference would be helpful. If you file it targeted at juju-core and it belongs in lxd we can re-target teh bug for you.
<simonklb> lazyPower: yea, the bug is kind of unspecific, the only thing I've found is that the dnsmasq.lxcbr0.leases file is not updated to the juju-xxx-xxx-.. hostnames right away
<lazyPower> that sounds like a likely culrprit, yeah
<lazyPower> are you on juju 2.0-beta6/beta7?
<simonklb> 2.0-beta6-xenial-amd64
<lazyPower> yep, ok
<lazyPower> can you bug that for me? :)
<lazyPower> i'll poke cherylj about it once its file and we can take a look
<simonklb> thanks, I'll try to describe it :)
<simonklb> btw do you know if there is any work done on the lxd profiles?
<lazyPower> i know its been mentioned more than once
<simonklb> I saw that docker support is not working with LXD until that is implemented
<lazyPower> we have specific profiles for docker based workloads in lxd, there's some networking
<lazyPower> and a few other concerns i've heard about wrt profiles, but i'm not 100% clear on what work is being done there
<simonklb> lazyPower: this is the bug thread I saw https://bugs.launchpad.net/juju-core/+bug/1565872
<mup> Bug #1565872: Juju needs to support LXD profiles as a constraint <adoption> <juju-release-support> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1565872>
<lazyPower> yeah :) that was my team poking about our workload support in lxd
<jcastro> lazyPower: we did, why what's up?
<lazyPower> jcastro - just curios on if upstream will be looking at the charms, and i knew we had WIP there. Odd_Bloke is deploying a jenkins workload, and the charms have an end of the sidewalk
<jcastro> we're supposed to be maintaining it in their namespace
<lazyPower> ooo jamespage still owns this charm
<jamespage> ?
<jamespage> jenkins?
<marcoceppi> popey: sudo apt install juju
<lazyPower> jamespage - yep
<lazyPower> popey o/
<jamespage> huh
<jamespage> lazyPower, guess that's the side effect of being a 0 day adopter
<jamespage> you forget about all that stuff you wrote :-)
<lazyPower> haha
<jamespage> lazyPower, I think you can blame me for ganglia as well
<jamespage> lazyPower, dosaboy and beisner have something a bit more recent re jenkins - we should fold that work in and make it generally consumable if thats not already the case...
<popey> marcoceppi: yeah, tried that, but it all failed so I gave up and span up a digital ocean droplet
<lazyPower> Odd_Bloke ^
<marcoceppi> popey: wait, what do you mean it all failed?
<popey> the guide as it is written doesn't work on 16.04
<marcoceppi> get-started?
<popey> the one i linked to above, yes
 * marcoceppi stomps off to correct things
<popey> I didn't have time to debug it so switched to real hardware, sorry.
<marcoceppi> popey: s/real hardware/other people's hardware/ ;)
<popey> s/other people's hardware/working infrastructure/
<simonklb> lazyPower: https://bugs.launchpad.net/juju-core/+bug/1579750
<mup> Bug #1579750: Wrong hostname added to dnsmasq using LXD <juju-core:New> <https://launchpad.net/bugs/1579750>
<simonklb> let me know if you need any more info
<lazyPower> We'll follow up on the bug if thats the case simonklb :) Thanks for filing this
<nottrobin> does anyone know if anyone's tried adding http/2 support into the apache2 charm?
<lazyPower> nottrobin - i don't believe so.
<nottrobin> lazyPower: thanks. do you know if anyone's working on a xenial version of apache2
<lazyPower> I haven't seen anything yet. Might be worth while to ping the list so it gets a broader set of eyes on it.
<nottrobin> lazyPower: I guess maybe not: https://code.launchpad.net/charms/xenial/+source/apache2
<lazyPower> nottrobin - right but the charm store no longer 100% relies on launchpad sicne the new store went live that could live somewhere in github or bitbucket for all we know :)
<lazyPower> still a good idea to ping the list, someone else may be working on that very thing
<nottrobin> lazyPower: oh right. didn't know that
<nottrobin> lazyPower: where's the list? I'm not sure if I'm subscribed
<lazyPower> juju@lists.ubuntu.com
<lazyPower> https://lists.ubuntu.com/mailman/listinfo/juju
<mgz> nottrobin: the effort involved is probably not huge? so if you're keen, I'd go ahead and xenialize, and then link on the list.
<nottrobin> mgz: yeah I'm thinking of giving that a go
<nottrobin> mgz: enabling http/2 is more difficult as even in xenial the default version is compiled without http/2 support
<mgz> yeah, but that can be another branch after.
* lazyPower 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 beta6 release notes: https://jujucharms.com/docs/devel/temp-release-notes
<nottrobin> mgz: yeah of course
<nottrobin> but that's still my ultimate goal
<beisner> hi Odd_Bloke, jamespage, lazyPower - afaik, the trusty/jenkins (python rewrite) has all previously pending bits landed.  i don't believe there is any secret delivery mechanism, though i do also have that need.  right now, we push things into units post-deploy.  a generic-ish subord or secrets layer sounds interesting.
<beisner> jamespage, re: o-c-t, ack.  also seeing all tempest tests fail the nova instance ssh check.  have you diag'd yet?  if not, about to dive in.
<lazyPower> beisner - i think if thats the case i'm more inclined to agree with a subordinate approach vs a layer, unless the layer is abstract enough to accomodate the volume of secrets a large deployment would need
<lazyPower> similar to what kwmonroe and mbruzek pioneered with the interface: java work.    an interface with a complimentary framework to deliver java.... only we get an interface and a complimentary subordinate to deliver n^n secrets.
<beisner> lazyPower, a swiss-army secrets-lander does sound nice.  i wonder if #is is doing anything along these lines with basenode or similar charms?
<lazyPower> they might be
<beisner> it seems like yes, but i can't put my finger on one atm
<jamespage> beisner, o-c-t fixed up - the set call was not actually using the value provided.
<beisner> wow wth lol
<beisner> jamespage, thx for the fix!
<tvansteenburgh> stub: ping to make sure you are aware of https://bugs.launchpad.net/postgresql-charm/+bug/1577544
<mup> Bug #1577544: Connection info published on relation before pg_hba.conf updated/reloaded <PostgreSQL Charm:New> <https://launchpad.net/bugs/1577544>
<jamespage> beisner, np
<simonklb> how can I debug the Juju controller/api?
<simonklb> it's been dying on me several times just today
<cholcombe> jamespage, for cinder it looks like we've settled on a model of 1 charm per driver?  Is that correct?
<jamespage> cholcombe, yes - each is a backend, and can be plugged in alongside other drivers
<lazyPower> mbruzek - have a minute to look over something with me?
<cholcombe> jamespage, ok cool. i might have to do some copy pasta for huawei then
<mbruzek> yar
<jamespage> cholcombe, I'd prefer we did not
<jamespage> cholcombe, the right way is to write a new cinder-backend base layer and use that :-)
<cholcombe> oh?
<cholcombe> ah yes that's what i meant hehe
<jamespage> then the next one that comes along is minimal effort
<jamespage> cholcombe, ok good :-)
<jamespage> cholcombe, you might be trail blazing a bit here
<thedac> Good morning
<lazyPower> mbruzek https://github.com/chuckbutler/layer-etcd/commit/1b8648d41fa336496efbff47e6a643e550361ee6
<lazyPower> this is a little frameworky script i threw together to lend a hand preparing resources offline. similar to what a make fat target would do, but the intention is not to include these files with the charm traditionally via charm push, but to attach them as resources
<lazyPower> I wanted your input on this before i ran down the remaining changes, moving it from curl'ing on the unit to using resource-get, etc.
<jcastro> popey: what was the issue specifically? I would like to fix it
<popey> jcastro: the doc says to install an unavailable package
<popey> 11:20 < popey> https://jujucharms.com/get-started - these instructions do not work on 16.04
<popey> 11:21 < popey> E: Unable to locate package juju-quickstart
<popey> 11:23 < popey> installing juju-core results in no juju binary being installed either.
<jamespage> beisner, we need to switch post-deploy thingy to use mac of added interface, to deal with the network renaming in xenial...
<jcastro> ack
<jcastro> popey: ok, I see the problem, marco's fixing it now, ta
<beisner> jamespage, yes, what's there was a quick fix.  we really need to pluck the mojo utils thing into a library proper and be able to use that outside of both o-c-t and mojo.
<jcastro> that page is supposed to be revved. :-/
<beisner> jamespage, b/c it is fixed much more elegantly and pythonic in the mojo helpers
<jamespage> beisner, I'm sure it is ...
<beisner> to use mac
<simonklb> I got this from juju-db on machine-0: checkpoint-server: checkpoint server error: No space left on device
<simonklb> still got space left on the host machine
<jcastro> popey: that page was for trusty, apparently nobody bothered to check if it worked with xenial
<popey> oops
<popey> jcastro: it doesn't :)
<jcastro> balloons: heya, we should add that to the release checklist.
<simonklb> looks like the container gets full, located it to the /var/lib/juju/db folder
<simonklb> a bunch of collection-*.wt files
<simonklb> anyone can help me to find what is being written?
<simonklb> this happens when I deploy a new charm
<plars> ahasenack: you know that issue with lxc instances of xenial on trusty with juju/maas I was talking to you about last week? It looks like it was choking on systemd with a non-systemd host. So I tried to update my lxc-host in maas to deploy with xenial and hit something I think you've run into also: https://bugs.launchpad.net/maas/+bug/1419041
<mup> Bug #1419041: bootstrap failing  with gomaasapi 400 when updating MAAS images <landscape> <oil> <oil-bug-1372407> <MAAS:Fix Released> <https://launchpad.net/bugs/1419041>
<plars> ahasenack: oh wait, no I think this is the one: https://bugs.launchpad.net/maas/+bug/1537095
<mup> Bug #1537095: [1.9.0] 400 Error juju bootstrapping missing images <landscape> <oil> <MAAS:In Progress by allenap> <MAAS 1.9:New> <https://launchpad.net/bugs/1537095>
<suchvenu> Hi
<suchvenu> Is it possible to change the status of a bug from Fix Released to Fix Committed?
<suchvenu> For a recommended charm, if I need to do some updates can't I use the same bug ?  I changed the status from Fix Released to FIx committed, but it doesn't get reflected in Review Queue.
<marcoceppi> suchvenu: no, to do updates you need to open a merge request
<suchvenu> Hi Marcoceppi
<suchvenu> ok, This is the stream where I have pushed my deployable charm
<suchvenu> https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-db2/trunk
<suchvenu> and layered charm is at lp:~ibmcharmers/charms/trusty/layer-ibm-db2/trunk
<marcoceppi> suchvenu: but you're trying to update db2 in the charmstore, correct?
<suchvenu> yes right. It don;t need any review ?
<suchvenu> So i need to merge from ibmcharmers branch to charmers branch , right ?
<marcoceppi> suchvenu: yes
<marcoceppi> suchvenu: in doing so, that will create a merge that will automatically appear in the review queue
<suchvenu> Will it updated in queue then ?
<suchvenu> oh ok
<suchvenu> and no need to attach a bug ?
<marcoceppi> suchvenu: correct
<marcoceppi> bugs are for charms that don't exist in the system yet
<suchvenu> ok
<suchvenu> And any reviewers to be added ?
<suchvenu> I had changed the bug status from Review Fixed to Review Committed. Should I change it back ?
<marcoceppi> suchvenu: link?
<suchvenu> https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-db2/trunk
<suchvenu> https://bugs.launchpad.net/charms/+bug/1477057
<mup> Bug #1477057: New Charm: IBM DB2 <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1477057>
<suchvenu> Marchceppi, should I change the status of Bug here ?
<marcoceppi> suchvenu: you don't need to touch the bug anymore
<marcoceppi> suchvenu: you need to go here, https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-db2/trunk and click "Propose for merging"
<suchvenu> which should be the target branch ?
<marcoceppi> suchvenu: cs:charms/trusty/ibm-db2
<marcoceppi> err
<marcoceppi> lp:charms/trusty/ibm-db2
<suchvenu> Do i need to add any reviewers ?
<mbruzek> suchvenu: No you do not have to add reviewers. This Merge Request will get picked up in the review queue
<mbruzek> suchvenu: As long as charmers are on the merge you should be good
<suchvenu> https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-db2/trunk/+merge/294153
<suchvenu> created merge request
<suchvenu> Thanks Marcoceppi for your help!
<thedac> dpb: tribaal: +2 on the swift-storage change after manual tests run
#juju 2016-05-10
<beisner> thedac, thx for the extra testing on that
<tinwood> cholcombe, are you joining the retrospective?
<LiftedKilt> has any work been done with lxd and ceph as a backend for cinder?
<marcoceppi> LiftedKilt: lxd and ceph?
<LiftedKilt> marcoceppi: specifically with cinder - I know that ceph and lxd work together insofar as ceph provides a backend for glance images
<LiftedKilt> but my understanding was that there are some issues with mounting ceph RBD's to lxd containers
<LiftedKilt> something along the lines of - when lxd tries to migrate a container, it wants to copy the data along with it, and doesn't know to just remount the rbd
<marcoceppi> LiftedKilt: I'm not sure of any progress there, sadly
<LiftedKilt> marcoceppi: hmmm ok. Who would be running point on that integration? Would it be a canonical thing since it's lxd? Or would it be a general openstack thing because it's nova?
<marcoceppi> LiftedKilt: It's probably a LXD thing, zul do you know?
<tinwood> gnuoy, is there an epic doc for the work I'm going to be doing on barbican & aodh?
<zul> LiftedKilt: nova-lxd doesnt support cinder backends yet\
<LiftedKilt> zul: is work actively being done on enabling that, or is there a roadmap for the integration?
<zul> LiftedKilt: both...it should be ready soon
<LiftedKilt> zul: where would be the best place for me to follow any news on that?
<zul> LiftedKilt: https://github.com/lxc/nova-lxd
<LiftedKilt> zul: awesome - thanks a lot
<LiftedKilt>   
<beisner> thedac, Tribaal's https://review.openstack.org/#/c/314557 is clear for takeoff imo (stable charm update) - can you do the review/landing honors?
<thedac> beisner: will do
<thedac> beisner: Tribaal +2
<lazyPower> yo beisner
<lazyPower> question for you
<beisner> shoot lazyPower
<lazyPower> oh nevermind i click on the reivew and it 404's
<lazyPower> <3
<beisner>  -> not sure if that's good or bad
<lazyPower> great in this case
<lazyPower> i dont need to bug you :D
<lazyPower> not more than i already have anyway
<aisrael> tvansteenburgh: I pip installed bundletester on xenial but don't have a bundletester command in my path. What did I do wrong?
<lazyPower> oh speaking of, do we need a xenial flavor of charmbox soon?
<tvansteenburgh> aisrael: uhhhh
<jhobbs> deej: /wg 8
<jhobbs> oops
<aisrael> tvansteenburgh: I found it in ~/.local/bin/bundletester
<bdx> openstack-charmers: Is this a known bug, or am I doing something wrong here -> https://bugs.launchpad.net/charms/+source/neutron-openvswitch/+bug/1580271
<mup> Bug #1580271: hook failed: neutron-plugin-api-relation-changed for neutron-openvswitch:neutron-plugin-api <neutron-api> <openstack> <neutron-openvswitch (Juju Charms Collection):New for openstack-charmers> <https://launchpad.net/bugs/1580271>
<aisrael> which is not in path
<tvansteenburgh> aisrael: that's weird
<aisrael> Yeah, I've never seen python bits installed there. Usually they go into /usr/local
<lazyPower> aisrael - thats default if you use pip install --user
<aisrael> lazyPower: I didn't use --user, though
<lazyPower> aisrael - you'll need to add that path to $PATH if you want anything installed via your userdir isolation
<tvansteenburgh> -u instead of -U ?
<lazyPower> weeeeiiirrrddd
<lazyPower> maybe xenial has different behavior?
<aisrael> no -u
<magicaltrout> marcoceppi: if i spin up a demo environment today can you promise not to switch it off until after tomorrow? :)
<aisrael> and it dumps a stack trace
<Tribaal> beisner: thedac: thanks a lot!
<beisner> hi bdx - /var/log/juju/unit-*vswitch* may also be indicative on that
<aisrael> tvansteenburgh: http://pastebin.ubuntu.com/16350722/
<magicaltrout> kwmonroe: ping
<bdx> beisner: yea, its spammed with connection errors for not having rabbit up yet
<tvansteenburgh> aisrael: looking
<bdx> that shouldn't depend on rabbits relation or connectivity though
<beisner> bdx, ah yes if rmq is grumpy, generally no one else is happy.
<bdx> beisner: ok, yeah, I'll get rabbit in check and see what gives .... is xenial/rabbit successfully deployable to your knowledge ... I've been having a fit with it
<beisner> bdx, yep xenial rmq is looking good from my perspective
<bdx> beisner: awesome. deployed to lxd as well?
<beisner> bdx, but i've not thrown it at juju-tip+maas-tip like you are doing right now ;-)
<beisner> bdx, ack.  this scenario results in a happy rmq:  https://github.com/openstack-charmers/openstack-on-lxd
<tvansteenburgh> aisrael: what charm or bundle? i can't repro and i'm on xenial
<aisrael> tvansteenburgh: cs:~3-bruno/trusty/quobyte-client
<aisrael> hmm
<bdx> beisner: I see, it deploys for me using lxd cloud type too, just not as a lxd on a MAAS deployed node -- just xenial/rabbit deployed to lxd on maas just hangs on "Waiting for rabbitmq app to start" :-(
<aisrael> tvansteenburgh: Probably unrelated, but I got this running bundletester from ~
<aisrael> http://pastebin.ubuntu.com/16350914/
<aisrael> perms on the file were root:root. easy fix, but kind of odd
<bdx> beisner: trusty/rabbit seems to deploy successfully to lxd on maas though ... I'll see if I can't grub up a bug for this
<tvansteenburgh> aisrael: bt running against that charm, no errors for me
<tvansteenburgh> aisrael: i did install it in a venv thought
<tvansteenburgh> though
<aisrael> tvansteenburgh: I'll do that and try again
<aisrael> I bet it's something with this .local wonkiness
<tvansteenburgh> aisrael: your first paste seems like a legit bug, just not sure how to repro
<bdx> wjst
<tvansteenburgh> aisrael: do you have make installed?
<aisrael> tvansteenburgh: Yep. I installed build-essential
<tvansteenburgh> aisrael: what about charm-tools
<aisrael> tvansteenburgh: negative. installing now
<tvansteenburgh> aisrael: that was the cause of the bug. will fix
<aisrael> tvansteenburgh: confirmed. thanks!
<beisner> tvansteenburgh, i've found that when using --no-destroy but not using --allow-failure, bt keeps on trucking onto the next test instead of stopping/bailing on the first fail.  i was expecting/need it to halt and keep the deployment so we can poke at the model with bots.  idears?
 * tvansteenburgh looks
<beisner> tvansteenburgh, fwiw, we do have reset: True ... perhaps we can't have both?
<tvansteenburgh> beisner-food: any other options?
<lazyPower> beisner - yeah thats what you're looking for. setting reset to false, and not allow failure. That will cause the test to abort and your bots can aggregate the resulting env
<lazyPower> but you say it continues barreling on? thats weird
<tvansteenburgh> beisner-food: afaict there's no correlation between these options in the code. one shouldn't affect the other. if you use -F by itself it works as expected?
<aisrael> tvansteenburgh: May have hit another bundletester issue, at the bottom of this: http://pastebin.ubuntu.com/16351794/
<beisner> tvansteenburgh, lazyPower - yah i'm looking for the best of both worlds:  recycle the bootstrap node, but bail on fail.   /me retries with reset: false ... will holler back
<beisner> tvansteenburgh, i'm not setting -F anywhere, just mentioned that so that you know we're not setting it.
<tvansteenburgh> beisner: -F == --allow-failure
<beisner> tvansteenburgh, right, i'm not using -F.  i want it to fail and halt.
<tvansteenburgh> oh, right
<tvansteenburgh> beisner: so if you don't use --no-destroy, it stops after first failure??
<beisner> tvansteenburgh, not sure actually.  i dove into it with what i wanted, which is --no-destroy + reset: True .. and that blew all the way through tests regardless of pass/fail
<beisner> tvansteenburgh, right now, testing with --no-destroy + reset: False.
<bdx> beisner, openstack-charmers: my primary point of contention with 16.04 deploy is here -> juju bootstrap --config config.yaml localhost lxd
<bdx> ooops
<bdx> hehe
<tvansteenburgh> aisrael: yeah, i guess we could handle that case better
<aisrael> tvansteenburgh: apparently, that fail is because all machines are stuck allocating (due to Your quota allows for 0 more running instance(s). You requested at least 1 (InstanceLimitExceeded)
<bdx> here: http://paste.ubuntu.com/16351894/
<tvansteenburgh> aisrael: indeed
<tvansteenburgh> aisrael:  filed a bug for that but it likely won't be high priority
<tvansteenburgh> aisrael: https://github.com/juju-solutions/bundletester/issues/45
<aisrael> tvansteenburgh: ack, thanks.
<beisner> tvansteenburgh, lazyPower - hrm.  with --no-destroy and reset: False and the first test rigged to fail for debugging, it didn't bail:  http://pastebin.ubuntu.com/16351971/
<lazyPower> beisner that seems like a bug :\
<tvansteenburgh> no, it's per test file
<tvansteenburgh> to bundletester, a test is a file, it does't know anything about the contents of the file
<beisner> is there an equiv to `juju test --set-e` in bt?
<lazyPower> oooo
<lazyPower> thats right
<lazyPower> it'll attempt to complete the current TestCase then bail, right tvansteenburgh?
<beisner> so the first test file is known-fail (and it fails).  but then it proceeds to the 2nd test file.
<lazyPower> when i say TestCase, i mean finish all the test_ methods in that class...
<beisner> in this case, it's the 'deployment' that will knowingly fail
<beisner> not really the test
 * tvansteenburgh squints
<tvansteenburgh> beisner: can you paste the whole log?
<bdx> beisner: I'm subscribing you to the bug I made for openvswitch, is that cool?
<beisner> tvansteenburgh, http://pastebin.ubuntu.com/16352034/
<beisner> bdx, yah, please link here too.  thx man
<bdx> beisner, openstack-charmers -> https://bugs.launchpad.net/charms/+source/neutron-openvswitch/+bug/1580271
<mup> Bug #1580271: hook failed: neutron-plugin-api-relation-changed for neutron-openvswitch:neutron-plugin-api <neutron-api> <openstack> <neutron-openvswitch (Juju Charms Collection):New for openstack-charmers> <https://launchpad.net/bugs/1580271>
<beisner> tvansteenburgh, /me retries w/o no-destroy
<tvansteenburgh> beisner: i'm having trouble coming up with any more excuses for why it doesn't work :P
<lutostag> stub: realize its not your timezone, but curious where I should submit a bug for the https://git.launchpad.net/postgresql-charm ? a default config option makes it fall over on a xenial deploy
<tvansteenburgh> lutostag: i filed mine here https://bugs.launchpad.net/postgresql-charm :)
<lutostag> tvansteenburgh: thanks, looks reasonable :)
<bdx> openstack-charmers: https://bugs.launchpad.net/charms/+source/rabbitmq-server/+bug/1580316
<mup> Bug #1580316: Waiting for rabbitmq app to start <openstack> <rabbitmq-server (Juju Charms Collection):New for openstack-charmers> <https://launchpad.net/bugs/1580316>
<beisner> tvansteenburgh, lazyPower - chit.  so without --no-destroy and with reset: False, i get the same.
<tvansteenburgh> beisner: good, otherwise it's even weirder
<beisner> tvansteenburgh, so it looks like if the fail is a deployment failure, it doesn't count
<tvansteenburgh> beisner: oh...
<bdx> openstack-charmers -> https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1580320
<mup> Bug #1580320: no block devices detected using current configuration <openstack> <storage> <ceph-osd (Juju Charms Collection):New for openstack-charmers> <https://launchpad.net/bugs/1580320>
<tvansteenburgh> beisner: still doesn't make sense, exit code is non-zero which should be all that's needed
<beisner> tvansteenburgh, http://pastebin.ubuntu.com/16352231/
<beisner> tvansteenburgh, ha, right!?   Exit Code: 1 ... call [next test...] is happening though
<tvansteenburgh> yeah
<tvansteenburgh> beisner: humor me an remove the -r and -o switches
<beisner> tvansteenburgh, ack.  couple mins...
<tvansteenburgh> beisner: i can't repro locally no matter what i try
<tvansteenburgh> beisner: what's in your tests.yaml?
<tvansteenburgh> ahasenack: you around/available for questioning?
<tvansteenburgh> beisner: wait a sec...in that last pastebin you were passing -F
 * tvansteenburgh suddenly realizes the whole thing was a giant troll
<beisner> tvansteenburgh, wait.  what.
<beisner> f'ing -F
<beisner> sure enough.  who put that there?
<beisner> tvansteenburgh, lazyPower - lol, yah a lil unintended !failfast troll for ya.
<ahasenack> tvansteenburgh: what's up?
<beisner> sorry for the noise on that folks
<tvansteenburgh> beisner: np
<tvansteenburgh> ahasenack: when someone does `apt install juju-deployer` how does the system know which python to use? does it just use default system python?
<lazyPower> beisner thats brilliant :D
<ahasenack> tvansteenburgh: use for what, to run apt, or to run deployer?
<tvansteenburgh> ahasenack: deployer
<beisner> lazyPower, just making sure we're all paying attention ;-)
<ahasenack> tvansteenburgh: deployer package has a dep on certain version(s) of python,
<ahasenack> tvansteenburgh: other than that, the final call is the shebang line
<ahasenack> $ head -n 1 $(which juju-deployer)
<ahasenack> #! /usr/bin/python
<tvansteenburgh> ahasenack: okay. i thought maybe there was more to it on the packaging side but i guess not. thanks
<ahasenack> tvansteenburgh: packaging is really py2 centric
<tvansteenburgh> ahasenack: deployer with juju2 is only going to work with py3 on trusty, b/c the trusty version of py2 doesn't support TLS 1.2
<tvansteenburgh> ahasenack: so i was trying to figure out if we need to do anything on the packaging side to accommodate that
<ahasenack> tvansteenburgh: and what is switching to tls 1.2 exclusively?
<ahasenack> server-side?
<tvansteenburgh> juju
<ahasenack> I see
<tvansteenburgh> ahasenack: as of beta7
<ahasenack> you mean the juju api endpoint
<tvansteenburgh> yeah
<ahasenack> looke like #eco will have their hands full ;)
<tvansteenburgh> well i already did the work in deployer and jujuclient
<ahasenack> *looks
<ahasenack> to port to py3?
<tvansteenburgh> yeah
<ahasenack> it's a fork?
<tvansteenburgh> no
<tvansteenburgh> py2 and py3 support
<ahasenack> pysix?
<tvansteenburgh> yeah
<ahasenack> ok, that will need some smarter packaging
<tvansteenburgh> branches are here if you're curious https://bugs.launchpad.net/juju-core/+bug/1576695
<mup> Bug #1576695: Deployer 0.7.1 on trusty cannot talk to Juju2 because :tlsv1 alert protocol version <ci> <deployer> <maas-provider> <python2.7> <regression> <juju-core:Invalid> <juju-deployer:In Progress> <https://launchpad.net/bugs/1576695>
<ivandov> Hi, is this an okay area to ask some questions regarding juju2.0 errors I'm having trying to run on Ubuntu 16.04 on Linux on System z (mainframe)... need some pointers
<tvansteenburgh> ahasenack: okay, well that's why i asked. i don't know anything about packaging
<ahasenack> almost 4k lines
<ahasenack> tvansteenburgh: that level of packaging is a bit over my head
<beisner> tvansteenburgh, ok so we failed well without -F.  next ?:   any way to tune the timeout happening @ self.d.setup(timeout=900) ?
<tvansteenburgh> beisner: yes!
<beisner> wee!
<tvansteenburgh> beisner: https://github.com/juju/amulet/issues/119
<tvansteenburgh> ahasenack: what do you mean "that level"
<tvansteenburgh> ahasenack: doing py2 and py3?
<ahasenack> ahasenack: producing multiple binary packages, one for py2, one for py3
<tvansteenburgh> ok
<ahasenack> from one source
<tvansteenburgh> well thanks for your moral support anyway :)
<ahasenack> I'm sure there are tons of tutorials out there
<tvansteenburgh> i've been needing to learn about packaging anyway
<ahasenack> it's just not something I have done before
<tvansteenburgh> my time has come
<beisner> tvansteenburgh, \o/ cool thanks!
<tvansteenburgh> beisner: sure thing
<tvansteenburgh> ivandov: certainly, ask away
<tvansteenburgh> caveat, i know nothing about Z
 * tvansteenburgh looks around
<ivandov> Haha, that's okay... I'm likely needing some basic juju help first... I'll muddle through the z issues afterwards
 * magicaltrout checks his hotel room for a spare SystemZ mainframe to test on
<ivandov> So, I followed the Getting Started devel docs, which worked swimmingly, but now when I try to deploy charms, they fail... I assume because some of the hooks aren't written for z...
<ivandov> But how would I go about actually seeing the error details that are shown under 'juju status' for a particular machine... It doesn't seem to let me do a 'juju ssh' into it... and 'juju debug-logs' just hangs
<tvansteenburgh> juju debug-log --replay
<ivandov> yup, that has no output
<tvansteenburgh> hrm
<tvansteenburgh> sounds like a bigger issue
<ivandov> juju status shows the machine in an error state... and the individual units show a message of "Waiting for agent initialization to finish "
<tvansteenburgh> ivandov: yeah, that's a juju problem, not the charms
<tvansteenburgh> marcoceppi: is juju supposed to work on Z?
<ivandov> Yes, it was announced as supported with 16.04 LTS GA
<tvansteenburgh> okay
<ivandov> The list of supported charms is still something i'm looking for, but from what I understood... Juju was supported
<tvansteenburgh> ivandov: can you pastebin the output of `juju status --format yaml`
<ivandov> http://pastebin.com/CaggRfWU
<tvansteenburgh> ivandov: did you bootstrap with --upload-tools?
<ivandov> No, as per the devel documentation... I followed this line "juju bootstrap lxd-test lxd" for bootstrapping
<tvansteenburgh> ivandov: i'm not sure how to fix the "no matching tools available" error in machine 0...marcoceppi, lazyPower?
<lazyPower> ivandov - can you give it another go with --upload-tools? I'm not certain what the arch is for Z series, and we may / may not have published simple streams for those and the version of juju you are using.
<lazyPower> i'm not terribly familiar with that, and i defer to our release team
<ivandov> z arch is s390x ... okay, do I have to somehow delete the current lxd bootstrapped environment?
<lazyPower> try juju destroy-model default && juju destroy-controller lxd-test
<lazyPower> that should clean up the currently deployed controller + default model. if you created any additional models, it will complain at you that there are active models and they need to be destroyed before you can destroy the controller
<ivandov> yup, that destroyed it... then create a new controller as documented in the devel docs? https://jujucharms.com/docs/devel/getting-started
<magicaltrout> make sure you append --upload-tools
<ivandov> so just "juju bootstrap lxd-test lxd --upload-tools" ?
<magicaltrout> yeah
<lazyPower> ivandov - one additional note. i noticed the workload you deployed was docker. THats going to fail on the lxd provider. It doesn't ship with the proper profile enabled by default, and there are some additional concerns to be worked out there before any docker/layer-docker based workloads will be deployable via lxd
<ivandov> Okay, bootstrap complete... any specific charm I should try to deploy... I have been unable to find a list of charms compatible with z... I doubt the mediawiki-single bundle would work
<lazyPower> if i can suggest an alternate workload - the elasticsearch charm is a good option
<lazyPower> its java based and shoudl work ootb if z has a jvm and/or works with openjdk
<lazyPower> i'm fairly certain that charm assumes openjdk
<ivandov> Okay, deployed elsaticsearch... seems like a slightly different error... http://pastebin.com/K9dHywyk
<magicaltrout> that ones easy :P
<lazyPower> progress :) looks like you dont have the lxd images imported
<ivandov> Haha, okay... any pointers on how to get that done?
<magicaltrout> something like
<magicaltrout> lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty
<lazyPower> i'm looking, but it looks like this got rolled into the provider code now.. its importing the images on bootstrap
<lazyPower> it may only be the xenial image though
<ivandov> magicaltrout: I assume the arch that you have listed in your command won't work with z
<lazyPower> ivandov correct, sub the arch as required
<magicaltrout> yeah that was a copy and paste :)
<magicaltrout> i don't have a mainframe in my hotel room ;)
<ivandov> Haha... come on! Get on that!
<magicaltrout> yeah i'll have a word
<ivandov> It's a great space heater
<lazyPower> question: can i play tetris on it?
<magicaltrout> arosales: tell your boss I would like a system z mainframe in my hotel room to test on please
<ivandov> magicaltrout: with the lxd-images command... is that a utility I need installed?
<magicaltrout> erm
<magicaltrout> i may have changed in recent releases
<magicaltrout> lxc image import <file> --alias <name>
<magicaltrout> according to linuxcontainers.org
<ivandov> Yup, just found that with a little google-fu... now I need to find an image file that would work with z
<ivandov> hmm..
<magicaltrout> theres a published list of images somewhere.....
<arosales> magicaltrout: come to his talk or bof this afternoon and you can tell him yourself  ;-)
<magicaltrout> i might just do that
<ivandov> https://images.linuxcontainers.org/ looks like the list i'm looking for
<magicaltrout> that be the one
<lazyPower> i see s390x images in the list
<lazyPower> \o/
<magicaltrout> not one for trusty though
<magicaltrout> you might be scuppered :P
<ivandov> Yup, was just about to say that
<lazyPower> xenial + though
<lazyPower> i dont see one for trusty
<ivandov> So, I'd need to find a charm that's based off of xenial to get a little further in testing some charm deployments?
<lazyPower> ivandov - well plot thickens. I have a xenial ready charm, that works on juju 2.0 using resources
<lazyPower> do you know if there's an etcd s390x binary or if you're comfortable compiling one?
<ivandov> not sure... I can definitely poke around... I guess it'd be an interesting practice to try to compile one lol
<magicaltrout> 2https://jujucharms.com/q/xenial
<magicaltrout> -2
<magicaltrout> thats about the first time in its history the search function has actually been useful
<lazyPower> magicaltrout nicely done
<lazyPower> the ubuntu charm is probably the lowest bandwidth test to see if it works
<beisner> jamespage, fyi, one to watch re: bundletester switch (re: juju test deprecation) & amulet via tox/venv:   https://review.openstack.org/#/c/314773
<lazyPower> juju deploy ubuntu --series=xenial
<ivandov> should I destroy the model & controller again?
<lazyPower> you shouldn't need to, no
<lazyPower> you can destroy that service that's stuck looking for trusty image data
<ivandov> and, do I need to add an lxd image for s390 before doing that? Or was that done during bootstrapping?
<lazyPower> it should have prepared you a xenial image.   lxc list images  will tell you what you've got available.
<ivandov> hmm lxc list images didn't look promising
<ivandov> http://pastebin.com/eW0T2788
<magicaltrout> mine says the same
<magicaltrout> don't trust it
<magicaltrout> but you can grab an image anyway it doesn't really matter
<ivandov> okay, then i'll just try juju deploy ubuntu --series=xenial
<lazyPower> a lot of this has changed since the last time i used it.
<lazyPower> magicaltrout - dude, resources are p. cool
<lazyPower> this is my new fanfare, is resources. offline'ing charms one dependency at a time :D
<magicaltrout> i'm not entirely sold on resources, I think you should be able to tie a resource into the charm in the charmstore
<ivandov> wooo! the ubuntu charm started
<magicaltrout> excellent
<ivandov> Well, thank you magicaltrout and lazyPower for your help... I gotta run to an engagement I'm late for... but... I'll likely be back on tomorrow trying to figure out the next steps to this
<ivandov> truly appreciated :)
<magicaltrout> cool
<magicaltrout> have fun
<lazyPower> cheers :)
<magicaltrout> yeah i like the idea of resources lazyPower but I'd like to be able to define one in my charm but not have to have a user download and commit the resource
<lazyPower> with store delivery, they dont have to
<magicaltrout> i'd like on the first run for a charm to be able to grab a resource from the web
<magicaltrout> store what?
<lazyPower> you version the resource w/ the charm, and they ship as a packaged resource.
<lazyPower> so you as the charm author
<lazyPower> charm push ~fishy/foo
<lazyPower> charm publish ~fish/foo --attach foo=bar
<magicaltrout> hmm
<magicaltrout> i'll have to dig into that
<arosales> magicaltrout: you at the conf?
<arosales> magicaltrout: specifically in the keynote apache sessions?
#juju 2016-05-11
<jose> marcoceppi: hey, do you know if anyone submitted a talk for txlf? CFP closes in less than 2h and I wanna make sure we have a juju talk
<stub> lutostag: https://bugs.launchpad.net/postgresql-charm is probably best, but I should see a report just about anywhere you can make one :)
<stub> lutostag: Huh. I assumed there might be some minor glitches, but I certainly didn't assume that one :-/
<simonklb> after upgrading to 2.0-beta6 my local charm has started complaining about hook missing - I let them be auto-generated by the reactive template and that worked fine before
<simonklb> anyone know what changed and what needs to be done for it to find the hooks again?
<simonklb> I should add that it seems that it finds the hooks if I create them manually, but then I get "ImportError: No module named 'charms'"
<simonklb> So it's like it looks in the root folder of the charm now instead of in ./trusty or whatever
<hoenir> simonklb, you tried to debug the hook?
<simonklb> hoenir: is it possible to manually execute hooks?
<hoenir> I don't hink soo
<hoenir> you tried to read the docs about hooks?
<simonklb> hoenir: yea, I mean, it hasn't been an issue for the last couple of weeks
<simonklb> only now, after updating to a newer version it's starting to act up
<wesleymason> simonklb: you can use juju run to manually execute a hook, e.g. juju run --unit {unit_name} 'hooks/hook-name'
<wesleymason> or as hoenir said use debug-hooks and run 'hooks/hook-name' inside the tmux session
<simonklb> wesleymason: /tmp/juju-exec390172100/script.sh: line 1: hooks/install: No such file or directory
<wesleymason> simonklb: that definitely looks like the PWD for hooks has changed :-/
<simonklb> yup
<simonklb> is there a changelog somewhere?
 * wesleymason is still on 1.25.x for current infra so haven't tested 2.0 hooks yet
<simonklb> right right
<wesleymason> simonklb: https://jujucharms.com/docs/devel/temp-release-notes
<wesleymason> not really a proper changelog though
<simonklb> thanks, I'll read it and see if I can find something about the hooks working directory
<RAJITH> Hello
<RAJITH> I am working on layered charm, simple charm is WORKLOAD-STATE : maintainence  AGENT-STATE :idle and message is Updating apt cache, please let me know what could be issue
<stub> RAJITH: If it hangs there, your units likely have a networking or apt issue, like an inaccessible or unavailable apt proxy. Its trying to run 'sudo apt update', and it is failing.
<stub> RAJITH: I'd connect to the unit, kill the hook, and try running 'sudo apt update' yourself and debugging from there.
<RAJITH> sure will try that
<RAJITH> if I tried to add a new machine , agent-state going to pending
<RAJITH> have tried this steps: 1. Destroy juju environment, if running. Use --force option if destroy fails.  Uninstall juju  Reboot the system using reboot command reboot     2. Ensure bind9 dns process is stopped, if running  ps -ef | grep named   if named is running: service bind9 stop  To do: ensure that named does not start on reboot, maybe uninstall it  3. Reinstall juju    4. Run the following command:  ifconfig | grep lxcbr0  If lxcbr0 
<RAJITH> lxc-net; service start lxc-net         Run ifconfig | grep lxcbr0              If lxcbr0 not present, do:            brctl addbr lxcbr0           ifconfig lxcbr0 10.0.3.1 netmask 255.255.255.0 up  5. Run the following command:          sudo iptables-save | grep lxcbr0          The output should be as follows:  	-A POSTROUTING -o lxcbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill         -A INPUT -i lxcbr0 -p tcp -m tcp --dport 
<simonklb> hoenir: wesleymason: I wasn't able to find the cause but works if you deploy from the build folder instead of the root
<simonklb> my guess is that they changed something in juju-deployer
<wesleymason> simonklb: well juju-deployer definitely hasn't changed, it's been in maintenance mode for a while...but I think local repo got removed, so it would need to be a full path to the charm itself, not the "root" dir, so perhaps before it was deploying $ROOT and not $ROOT/$SERIES/$CHARM
<simonklb> something like that
<gnuoy> wolsen, I assume you have no major objection to https://github.com/openstack-charmers/charm-interface-hacluster/pull/1 ?
<wolsen> gnuoy: that's correct
<tvansteenburgh> ahasenack: re juju-deployer packaging, python-bzrlib should be removed, python-six added
<tvansteenburgh> ahasenack: (deps)
<ahasenack> tvansteenburgh: ok
<gnuoy> wolsen, do you have the power to hit merge?
<ahasenack> tvansteenburgh: and tox added
<ahasenack> and other stuff
<tvansteenburgh> well not really, make test will do that
<wolsen> gnuoy: it doesn't appear that I do
<gnuoy> wolsen, well thats not right. thanks for looking
<wolsen> gnuoy: sure, thanks for looking@ that finally
<gnuoy> wolsen, np, thanks for doing all that work
<gnuoy> jamespage, can you add thedac, dosaboy and wolsen to the oipenstack-charmers on github please? (Or enable me to)
<jamespage> gnuoy, done (enabled you)
<gnuoy> thanks
<SaltySolomon> hi
<gnuoy> wolsen, with any luck you've got an invite to join
<wolsen> gnuoy: awesome,thanks
<gnuoy> wolsen, np ... any chance of hitting the button on my pull request if you have a sec?
<wolsen> gnuoy: I'm logging back in now
<gnuoy> \o/
<gnuoy> thanks
<wolsen> gnuoy: "only those with write permissions"
<gnuoy> argh, let me look
<wolsen> gnuoy: could be on my end too - let me look
<wolsen> gnuoy: it's my mistake
<gnuoy> ah, tip top
<wolsen> gnuoy: done
<gnuoy> thanks
<gnuoy> wolsen, tinwood I've created a starter for 10 for enabling management of HA resources in the Openstack layer https://github.com/openstack-charmers/charm-layer-openstack/pull/4/files . Please feel free to comment on it if you have any thoughts/objections
<gnuoy> tinwood (I know the importing is not standards compliant and I'll fix that)
<tinwood> gnuoy, thanks for the heads-up; I'm wrangling barbican as we speak.
<wolsen> gnuoy: will do - it'll likely be later this week - I'm in Austin this week
<beisner> thedac, here's the sentry unit foo as an ex: https://review.openstack.org/#/c/314773/3..4/tests/basic_deployment.py
<icey> any estimate of when charmhelpers tip will get onto pip?
<thedac> beisner: thanks, I'll start consuming that now.
<thedac> beisner: gnuoy I added ODL to the mojo specs https://code.launchpad.net/~thedac/openstack-mojo-specs/odl/+merge/294311
<gnuoy> thedac, excellent, thanks
<cory_fu> kjackal_: Hey, are we dropping the separate execution_mode config option for the Big Top Spark charm and moving to auto-switching to yarn mode based on hadoop.yarn.ready?
<cory_fu> (Also, if we keep the config, can we shorten the name a bit?  spark_execution_mode seems unnecessarily long, and somewhat redundant.)
<cory_fu> kjackal_: When you have a chance, can you take a look at https://github.com/juju-solutions/layer-apache-bigtop-base/pull/2  Those are some of the refactors I had played around with when looking at your Spark charm.  I'm thinking it should let you clean up some of the code  in that charm layer to something along these lines: http://pastebin.ubuntu.com/16365652/
<cory_fu> Anyway, that's all completely untested of course, and was just what I had from the time I spent looking at it yesterday.  Let me know what you think
<tvansteenburgh> icey: that has historically been by request. i just took a quick look and there are a number of failing tests.
<icey> tvansteenburgh: ok, that's unfortunate; there's stuff that we've been using in the openstack charms for a while that aren't in the pip version, making a migration to layered charms more difficult -_-
<tvansteenburgh> icey: i would fix them myself but i just don't have time right now
<icey> tvansteenburgh: same boat -_-
<aisrael> Any ideas on a way to force destroy a controller in juju 2 beta 6? There's no more --force flag
<rye_> How can I remove a service that has a unit in an error state in juju2?
<tvansteenburgh> aisrael: do you really want to destroy the controller, or just the model?
<aisrael> tvansteenburgh: Either at this point. I think I've found a bug that's preventing destroy-controller, destroy-model, and kill-controller from working
<tvansteenburgh> rye_: you need to `juju resolve` the unit first
<tvansteenburgh> aisrael: juju destroy-model -y default # or whatever your model name is <- that doesn't work for you?
<aisrael> tvansteenburgh: Nope, the model is stuck in destroying
<rye_> tvansteenburgh: thanks!
<tvansteenburgh> aisrael: well if you just want to keep working, bootstrap a new controller :D
<aisrael> tvansteenburgh: Good point. That'll do while I file a bug
<rye_> Hmm, upon resolution, it continues onto fail another hook (not unexpected). Is there a way to halt that process so that I can remove it?
<tvansteenburgh> rye_: you just have to keep resolving until it finishes what's queued
<rye_> tvansteenburgh: fair enough, thanks again
<icey> is it possible to have a function execute _after_ every hook run with reactive?
<icey> specifically, with reactive+layers
<tvansteenburgh> icey: hookenv.atexit
<icey> tvansteenburgh: would I att an empty @when to get that to register on each invocation?
<icey> also, thanks tvansteenburgh!
<tvansteenburgh> icey: i think you could just do it in module scope
<icey> got it, the leadership layer has a nice example of atstart :)
<zeus`> the'res a way to modify the default image user "ubuntu" to another custom user when doing a juju bootstrap?
<gnuoy> thedac, if you get a sec would you mind taking a look at https://github.com/openstack-charmers/charm-tempest/pull/5
<thedac> gnuoy: sure
<gnuoy> thanks
<LiftedKilt> is maas 2 support merged yet?
<LiftedKilt> I thought I saw something about that a bit ago
<rick_h_> LiftedKilt: yes, in trunk and will be in the next beta
<rick_h_> LiftedKilt: it comes out of feature flag in this next release
<LiftedKilt> rick_h_: What's the release timeline on beta7?
<rick_h_> LiftedKilt: soooooon :) hopefully next two days
<LiftedKilt> haha ok
<LiftedKilt> my maas 1.9 has gotten buggy and I wanted to blow it away and move to 2.0
<LiftedKilt> gotta wait for integration though
<rick_h_> gotcha, yea there's rough work in the beta6 behind a feature flag, but I'd wait the day/two for the next one before jumping
<DavidRama> hello folks, trying to deploy the openstack charm but got ceph-mon lxc's in maintenance/executing status since the start (about 3 hours now) any idea why ? Running on Xenial/juju2.0
<LiftedKilt> rick_h_: for sure - I'll just hang tight
<bdx> DavidRama: I've got the same thing going on here
<bdx> icey: ^
<bdx> icey: is that a thing right now?
<rick_h_> DavidRama: bdx so there's a corner there for lxc because it's going away and should be lxd?
<bdx> rck_h_, DavidRama: my bad ... I've been experiencing that issue on lxd
<bdx> as well as lxc
<DavidRama> same
<DavidRama> ceph-mon/0              maintenance     executing   2.0-beta4 3/lxc/0                10.0.3.181     Bootstrapping MON cluster
<bdx> icey, rick_h_, can we get some <3 in that^ area please
<icey> bdx: DavidRama is that stable or next?
<bdx> stable
<rick_h_> bdx: yes, there's work ongoing (one of the reasons we're still beta) to finish pulling lxc and making lxd 100% equiv.
<bdx> cs:xenial/ceph-0
<rick_h_> bdx: DavidRama what provider is this on?
<bdx> rick_h_: lxd
<rick_h_> bdx: ah, so this is the issue, you can't do nested containers in lxd by default, you have to use the 'docker' profile lxd offers
<rick_h_> bdx: that's got a set of discussions at our sprint next week on how to handle this, as lxd doesn't enable it ootb as a security issue
<bdx> oooh, rick_h_: I'm not nesting...
<rick_h_> bdx: ? so on lxd you're deploying openstack? or am I misreading?
<rick_h_> bdx: is this on maas then? with the lxd container on there?
<bdx> rick_h_: `juju bootstrap lxd lxd-test; juju deploy cs:xenial/ceph-0`
<rick_h_> bdx: oic, ok. Do this is different than what DavidRama pasted my bad
 * rick_h_ is confusing the different issues
<bdx> oh my bad
<rick_h_> so one at a time, bdx there is love going into it
<bdx> nice, thx
<rick_h_> DavidRama: can you try beta6? lots of lxd work between beta4 and 6
<rick_h_> DavidRama: and nested lxd (on the lxd provider) isn't going to work atm, still more to be done
 * rick_h_ thinks that's the summary for the moment
<DavidRama> i'm on local provider
<bdx> icey, rick_h_: while I've got you both here, whats the status of cs:xenial/{ceph,ceph-osd}-0 on for the MAAS provider?
<rick_h_> bdx: so the maas provider will be out of feature flag and available for testing in the next beta release hopefully out by EOW
<rick_h_> bdx: so we'll know more then once the charm maintainers can validate/etc
<bdx> rick_h_: entirely .... what are we looking at here 2-3 weeks, or 16.07 charm release?
<rick_h_> bdx: in between? for final GA of 2.0 I think
<rick_h_> bdx: the charm will be there/working with 2.0 beta in a week I'd say, but GA of 2.0 is on the long end of that 2-3 weeks but well before July
<bdx> rick_h_: ok, great. So what you are saying, is that ceph deploys  will hopefully be squared away within around a weeks time ...e.g. ceph, ceph-osd will deploy successfully using 16.04 in a weekish?
<rick_h_> bdx: I'd hope so, cholcombe is there something else to watch out for besides juju2/maas2? ^
<DavidRama> rick_h_ got the same symtom with beta6:
<DavidRama> ID                      WORKLOAD-STATUS JUJU-STATUS VERSION   MACHINE PORTS          PUBLIC-ADDRESS MESSAGE
<DavidRama> ceph-mon/0              maintenance     executing   2.0-beta6 2/lxc/0                10.0.3.247     Bootstrapping MON cluster
<magicaltrout> kwmonroe:
<magicaltrout> marcoceppi: you around?
<cory_fu> magicaltrout: I don't think kwmonroe is on IRC, but you can ping him on Telegram (or I can ping him if you need me to)
<magicaltrout> its alright thanks cory_fu i figured it out
<magicaltrout> is marcoceppi on holiday or something?
<cory_fu> I don't think so, but he might be travelling
<magicaltrout> bleh
<magicaltrout> fair enough
<magicaltrout> cory_fu: actually just quickly, can i juju expose hdfs from a remote location?
<cory_fu> What do you mean?
<cory_fu> Do you mean, use a Juju-deployed HDFS with something outside of Juju?
<cory_fu> Or vice-versa?
<magicaltrout> yeah so if I have one of your bundles running
<magicaltrout> expose HDFS so I can write from outside the juju network
<magicaltrout> hdfs://.... uri
<cory_fu> magicaltrout: You can, but there are two issues right now.  One is that the port is not opened by default.  That's easy enough to fix with `juju run --service namenode "open-port 8020"; juju expose namenode`
<magicaltrout> is that one issue? or both the issues?
<cory_fu> The other is that I'm not sure if it listens on the public interface by default.  We had a change put in to make absolutely sure it does, but that's not been released yet.
<magicaltrout> ah right, i'm sure I can hack that around
<magicaltrout> its only for this afternoons demo
<cory_fu> magicaltrout: Here's the change to force it, if it doesn't by default: https://github.com/juju-solutions/jujubigdata/commit/0f0ff1bd98eb06661375c699a4172b3e2b94396b
<magicaltrout> ta
<cory_fu> You can just add those to the /etc/hadoop/conf/hdfs-site.xml file manually
<cory_fu> You'll still need to do the open-port & expose thing, tho
<magicaltrout> yup
<cory_fu> magicaltrout: Let me know if you need me to ping kwmonroe for  you on telegram to arrange a rendezvous
<magicaltrout> it's alright i can normally hear his texan drawl from a distance away ;)
<cory_fu> lol, true
<rye_> I'm trying to run bundletester, but jujuclient.py is throwing an EnvironmentNotBootstrapped exception. After digging into it a bit, it looks like I'm missing the account['password'] field here: http://bazaar.launchpad.net/~juju-deployers/python-jujuclient/trunk/view/head:/jujuclient.py#L291
<rye_> I do have a password set up, however (as admin@local)
<rye_> Any suggestions for what else I can check?
<tvansteenburgh> rye_: juju1 or 2?
<tvansteenburgh> rye_: make sure you have latest jujuclient from pypi. if you're testing on juju2, you must be bootstrapped before running bundletester, and you need to pass -e $(juju switch)
<tvansteenburgh> rye_: also make sure you have latest bundletester from pypi
<tvansteenburgh> rye_: if none of those things fixes your problem, pastebin the output
<rye_> tvansteenburgh: juju2, and thanks!
#juju 2016-05-12
<gnuoy> jamespage, got a sec for https://github.com/openstack-charmers/charm-tempest/pull/5 ? fwiw I've tested it
<jamespage> gnuoy, +1 merged
<gnuoy> thanks
<rye_> https://gist.githubusercontent.com/anonymous/569083600b2e95057add2d188e8d1687/raw/665602596e56b071ace4d0b79c6a3c48f489cb06/gistfile1.txt
<rye_> sorry, wrong chat
<DavidRama> hi foilks, got an issue with juju2.0b6/xenial I can't delete a charm from my status:
<DavidRama> [Units]
<DavidRama> ID      WORKLOAD-STATUS JUJU-STATUS VERSION   MACHINE PORTS PUBLIC-ADDRESS MESSAGE
<DavidRama> mysql/0 error           idle        2.0-beta6 1             10.168.71.15   hook failed: "db-relation-broken" for mediawiki:db
<verterok> DavidRama: hi, tried marking the unit as resolved? (juju resolved mysql/0)
<DavidRama> ah yes thanks
<DavidRama> And is there a way to stop/remove a whole bundle easily ?
<lazyPower> DavidRama - not really. Unless you're using the gui you can mark every charm in a single transaction.
<lazyPower> but thats the only easy way i can see to remove an entire bundle in one go.
<cory_fu> kjackal_: https://github.com/juju-solutions/layer-apache-bigtop-base/pull/3
<cory_fu> kjackal_: Example changes in namenode: https://github.com/juju-solutions/layer-apache-bigtop-namenode/pull/1
<cory_fu> kjackal_: And you'll need this openjdk: https://github.com/juju-solutions/layer-openjdk/pull/2
<stub> cory_fu: Have you had a chance to look at the charms.reactive action branch?
<ddellav> jamespage or gnuoy can one of you guys take a look at this and land it? lp:~ddellav/+junk/charm-helpers its the change to support neutron 8.1 in mitaka
<jamespage> ddellav, can you propose that as a merge against lp:charm-helpers please
<ddellav> jamespage sure
<jamespage> ddellav, you might need to rename your branch to lp:~ddellav/charm-helpers/branchname
<jamespage> otherwise lp might lose its target...
<ddellav> it's been awhile since i did a launchpad merge
<ddellav> ok, i'll check it out
<ddellav> jamespage https://code.launchpad.net/~ddellav/charm-helpers/neutron-mitaka-stable/+merge/294529
<cory_fu> stub: Some.  I was discussing it with bcsaller.  I think I'm more inclined to use the state-based version in layer-basic, though we have also realized that auto-removing states like that are not the right way forward long-term, so there's still some discussion
<stub> cory_fu: yes, I expect people will prefer using the states. I felt the @action decorator was needed though to setup that state if necessary, similar to @hook
<stub> cory_fu: The basic model works for you though? Jumping into the reactive handlers and they can choose to call action-set, action-fail? And that actions and hooks are sharing the same bag of handlers?
<jhobbs> juju's api-port, 17070, is what a remote client like python-jujuclient/juju deployer connect to, right?
<rick_h_> jhobbs: yes
<jhobbs> thanks rick_h_
<beisner> marcoceppi, cory_fu - i'm needing to determine a reliable way to programmatically determine from the code tree alone whether a charm is to-be-built or already built.  it looks like the layer.yaml + whether or not the .build.manifest file exists is indicative.  do you have any other suggestions along these lines?
<cory_fu> beisner: I think the .build.manifest would be the most authoritative
<beisner> cory_fu, right so there's no case you can think of where that file would/should exist in a layer or interface?
<cory_fu> beisner: Someone might check it in by mistake, but it really should not be
<cory_fu> If they did that, we would nack them on review
<beisner> cory_fu, ack thx sir
<beisner> cory_fu, is there any case where a built charm or a layer would contain a interface.yaml?
<cory_fu> It will if it includes any interface layers, but it wouldn't be at the top level
<rye_> When my charm is deployed under bundletester, I briefly see a status of "Agent is lost, sorry! ...", but normal deployment goes fine. Is there some common pitfall I might be hitting, here? (juju2)
<jhobbs> i've seen that with juju2 also rye_, not using bundletester
<cory_fu> rye_: Juju always reports "Agent is lost" for a brief period while the unit is bootstrapped.  It just indicates that the unit is up but the agent hasn't checked in with the bootstrap node yet.  It should go away on its own after a second or two
<cory_fu> So, now I have a question about subordinates....
<cory_fu> Can someone tell me if it's possible to "chain" subordinates?  As in, I have the plugin charm that is subordinate to some principal, which is to install Hadoop.  But that requires Java, which is provided by a subordinate charm itself.  So I have openjdk -> plugin -> client where "->" is "subordinate to"
<cory_fu> Juju seems to accept the relation, but the plugin never gets an openjdk unit
<marcoceppi> aisrael: are you going to make 1x1?
<rye_> cory_fu: good to know, thanks!
<aisrael> marcoceppi: I'll be there!
<magicaltrout> marcoceppi: can you find a definitive date when you guys will be in Pasadena so I can dump it in my calendar? We discussed it here and would be cool to hook up with you guys and I can combine it with a NASA onsite at the same time.
<aisrael> NASA?!
<magicaltrout> er yeah
<lazyPower> cory_fu - yeah no, you cant build subordinates on top of one another
<magicaltrout> i moonlight for NASA JPL
<lazyPower> you can use 2 subordinates on the same principal, and exchange the java runtime information that way, but i dont think you can plug in interface:java on your subordinate - unless i completely missed teh question
<lazyPower> what would happen is you need openjdk => client,  and plugin => client, and you'll have to do some data pass in that chain, either through states, unit data, or plain ol relationship proxy'ing info on the same unit
<lazyPower> also rye_  sorry i missed ya lastnight. it was past EOD for me
<lazyPower> rye_ - did you get your charmbox questions sorted in my absence?
<cory_fu> lazyPower: Yeah, you're correct.  You can't chain subordinates currently due to technical / implementation reasons.  However, the modeling of the relations don't work the way you're describing so I'm basically just stuck
<lazyPower> "modeling of the relations dont work that way" - wut
<rye_> lazyPower: not yet, started putting out another fire :)
<cory_fu> lazyPower: Juju is a modeling language.  ;)
<lazyPower> cory_fu no thats fine, but what do you mean "dont work that way"
<lazyPower> you can certainly pass data between layers with unitdata + state combos
<lazyPower> ooo wait no you cant
<lazyPower> thats a different unitdata.db for each sub
<lazyPower> yeah, you're going to have to relation-set -r  out of band for any data you need to get from one to the others via the proxy. and thats messy, i did that with old docker-charm code and it ended in tears
<cory_fu> So, semantically, the relationship is between the two subordinates.  I don't want to demand that every single charm that might want to use the plugin have to *also* support the java relation and *also* have to implement proxying that relationship across
<lazyPower> by tears i mean it was fiddly and always needed attention, and wound up being a big pain to debug and trace that datapass across the charms.
<cory_fu> So, when I said "don't work that way" I meant that it's not semantically meaningful to do that
<lazyPower> yeah
<lazyPower> i agree
<lazyPower> make better choices cory_fu
<lazyPower> <3
<cory_fu> lazyPower: The response I got from asking in #juju-dev was resources  are probably a better fit, with which I mostly agree, except that it drastically reduces discoverability and makes ownership a bit of a nightmare.
<lazyPower> well, resources are still a blocking item right now
<cory_fu> Also, doesn't work in 1.x
<cory_fu> Yeah, that too
<lazyPower> i have a charm thats pending a release because resources coming from the store are currently pooched
<lazyPower> it'll be fixed soon enough, but you're right, it locks you into a 2.0+ deployment scenario
<lazyPower> and thats not always ideal either
<aisrael> magicaltrout: Awesome!
<marcoceppi> magicaltrout: http://summit.juju.solutions/
<marcoceppi> magicaltrout: we should be announcing early next week, but it's all but signed at this point
<magicaltrout> thanks marcoceppi
<magicaltrout> kwmonroe kept changing his mind on the month
<tvansteenburgh> cory_fu: latest bundletester on pypi has your new feature
<cory_fu> Sweet!
<cory_fu> Thanks
<kwmonroe> magicaltrout: i feel like you should be teaching a session right now, and not so much chatting about the summit.
<cory_fu> kwmonroe: Deploy looks good on those PRs
<kwmonroe> thx cory_fu
<marcoceppi> who has used extra-bindings?
<rick_h_> marcoceppi: the openstack team
<rick_h_> marcoceppi: they're the only folks that have updated charms to use it yet
<marcoceppi> beisner: got an example of a charm with extra-bindings?
 * marcoceppi has a need
 * rick_h_ starts loading charms from openstack-base
<beisner> maybe marcoceppi, sec..
<rick_h_> marcoceppi: https://api.jujucharms.com/charmstore/v5/xenial/ceph-osd-0/archive/metadata.yaml
<beisner> marcoceppi, https://github.com/openstack/charm-cinder/blob/master/metadata.yaml#L10
<rick_h_> marcoceppi: and https://api.jujucharms.com/charmstore/v5/xenial/ceph-radosgw-0/archive/metadata.yaml
<beisner> lolz, yah those
<beisner> o/ rick_h_ :)
<rick_h_> :)
<marcoceppi> so it's just an empty dict?
<rick_h_> ? you mean how you define it?
<beisner> usage ex. @ https://github.com/openstack/charm-cinder/blob/master/hooks/charmhelpers/contrib/openstack/ip.py#L112
<marcoceppi> rick_h_: yeah
<marcoceppi> interesting.
<marcoceppi> rick_h_: will these create network interfaces?
<rick_h_> marcoceppi: you can run network-get on those
<rick_h_> in your hooks
<rick_h_> and get config/info
<marcoceppi> right, but does that mean these machines get virtual nics, or what?
<beisner> marcoceppi, thedac + jamespage have championed our initial net spaces implementation - i'm not sure how e/n/i ends up first-hand.
<marcoceppi> beisner: thanks, I'll ping thedac tomorrow about it
<thedac> I am here
<marcoceppi> oh, hey thedac, extra-bindings, how does that translate to the unit?
<thedac> marcoceppi: So  this only works with MAAS for now. The physical machine needs to have an interface defined in a specific network space in MAAS
<thedac> And this just allows the charm to "choose" which interface a relation sends data over
<thedac> for the extra bindings part it maps directly to what the OS charms had as a config value os-{pubilc,admin,internal}-network
<wolsen> marcoceppi: so for that mongodb charm change that I mentioned last week, you mentioned it was a new review so I believe I followed the docs https://jujucharms.com/docs/stable/authors-charm-store#submitting ...
<wolsen> marcoceppi: I ended up not pulling out master/slave because its needed for the amulet tests for sharding, so this only moves stuff out of the upstart/init script modifications to pushing it into the /etc/mongodb.conf --> https://code.launchpad.net/~billy-olsen/charms/xenial/mongodb/trunk
<marcoceppi> thedac: interesting, okay. This is definitely geared towards maas so that's nice
<marcoceppi> wolsen: that should be it, the old review queue is slowly chugging through things so it should show up by tomorrow morning
<wolsen> marcoceppi: ack thanks just wasn't sure - the changes I have are safe for trusty as well fwiw, and I think I'll do a mp for them too
<marcoceppi> wolsen: sounds good
<wolsen> s/them/trusty
<lazyPower> wolsen thank you for adopting some fixes on that charm
<lazyPower> <3
<wolsen> lazyPower: sure thing
 * beisner woots for ppa:juju/daily  \o/
<beisner> hi thedac, so i randomly chose cinder to convert from juju test, amulet, et al via debs --> to bundletester, amulet and friends purely from venv ... and that's all looking good.  now if i can get cinder itself to work as planned.  i'm seeing that pause/resume in cinder isn't really working.  bug 1581171  curious if you can lend a set of eyes on that?
<mup> Bug #1581171: pause/resume failing <uosci> <cinder (Juju Charms Collection):New> <https://launchpad.net/bugs/1581171>
<thedac> beisner: I'll take a look
<beisner> thedac, muchos.   i'm taking a break from good ole cinder before i push overwrite a blank dir to it lol.
 * beisner picks one that passes @master ;-) ...
<beisner> --> glance.
<cmars> mbruzek, lazyPower I'm getting an install hook error in the kubernetes charm. is github.com/kubernetes/kubernetes the right place to open a bug?
<cmars> mbruzek, lazyPower https://paste.ubuntu.com/16382142/
<mbruzek> cmars: Thanks for using our stuff. If you determine the problem is with Kubernetes code itself use that repo. If the bug is in the charm code then please open it here https://github.com/mbruzek/layer-k8s
<mbruzek> actually cmars that is a bug in the docker layer
<mbruzek> https://github.com/juju-solutions/layer-docker/issues
<cmars> mbruzek, thanks, i'll open a bug. do you think it's possibly caused by deploying this on lxd?
<mbruzek> cmars: Absolutely.
<cmars> mbruzek, got it :) ok, i'll find a real cloud
<mbruzek> Docker *can* run  inside lxd, but Juju does not use the docker profile as far as I remember
<mbruzek> There is a core bug my bug got duped against for that
<mbruzek> As far as I know you can not run kubernetes in lxd  at this time.
<mbruzek> because docker will not run by default inside lxd and I don't think they have fixed that yet.
<cmars> mbruzek, ok. we might want to note that on the bundle READMEs, in case anyone tries it
<mbruzek> cmars: is that how you got this?
<mbruzek> cmars bundle?
<cmars> mbruzek, yes
<mbruzek> cmars which one?
<mbruzek> kubernetes-core or observable-kubernetes?
<cmars> mbruzek, observable-kubernetes
<rick_h_> cmars: you need to make the lxd docker profile the one juju uses
<rick_h_> cmars: why i mentioned gce and such
<cmars> mbruzek, what about this one? https://github.com/juju-solutions/layer-etcd/issues/11
<mbruzek> cmars: sorry for the problem. etcd charm can be reved to 2. This bundle is out of date, hard to keep it in sync for all the charms are in
<mbruzek> the bundle
<cmars> mbruzek, thanks!
<cmars> so in theory.. i could just edit the juju-default lxd profile and add the docker stuff. worth a shot
<mbruzek> cmars: I really don't think everything will work inside
<mbruzek> lxd
<cmars> mbruzek, it's possible, but i had to set security.privileged=true on the containers
<cmars> mbruzek, that got past the install hook, anyway. no idea if it actually works :)
<mbruzek> cmars: tych0 indicated that some docker containers will not run well inside lxd.  I would suggest saving the bundle and incrementing the charms to the latest revno and deploying this on a real cloud like amazon or azure.
<cmars> mbruzek, ok, ok :)
<mbruzek> cmars: otherwise your mileage may vary.
<tych0> well, it really depends on what the container is doing
<mbruzek> tych0: These docker containers are go binaries running kubernetes.
<tych0> yeah, i guess i don't know what kubernetes needs to do :)
<lazyPower> tych0 - its going to do the same things any other deployment would request. Run a container confined in cgroups (potentially), request network and disk resources, and add iptables rulesets for the proxy
<LiftedKilt> how does the maas2 feature flag work with conjure-up?
<lazyPower> cmars - how did you get that?
<lazyPower> its failing on setuptools/distutils? thats a new one on me
<cmars> lazyPower, the etcd one? i deployed observable-kubernetes on lxd (which I've since learned is not really supported)
<cmars> lazyPower, but the etcd hook error, i think it's fixed in the latest etcd-2?
<cmars> about to try that
<lazyPower> ok
<lazyPower> lmk if its not, i had a bit of a stir looking over the bug+logs
<cmars> lazyPower, mbruzek etcd-2 fixes my issue. here's a fix for the bundle: https://github.com/juju-solutions/bundle-observable-kubernetes/pull/5
<lazyPower> cmars <333333333 keep em comin
<mbruzek> Thanks cmars
<mbruzek> I am almost done with the readme fix and elasticsearch charm can also be bumped.
<mbruzek> cmars: if you just want kubernetes to run may I suggest the kubernetes-core bundle?
<mbruzek> cmars: it does not have the high constraints as the observable one
<cmars> mbruzek, good point, thanks
<LiftedKilt> nevermind on that front - I just took a guess and got it working
<LiftedKilt> however autopilot is not yet updated to xenial?
<mbruzek> cmars: lazyPower: https://github.com/juju-solutions/bundle-observable-kubernetes/pull/6
<mbruzek> cmars: lazyPower: https://github.com/juju-solutions/bundle-kubernetes-core/pull/5
<mbruzek> cmars those should include the updates you asked about today.
<cmars> mbruzek, thanks, LGTM
<cmars> mbruzek, hey, i've got kubernetes-core deployed in GCE now, thanks for the help
<mbruzek> cmars: great
<mbruzek> cmars: I can publish those bundles here soon I just wanted to test the new YAML as you pointed out in the review
<mbruzek> So far deployer seems OK with it
<cmars> mbruzek, juju 2.0 likes it just fine, i deployed the bundle from the command line
<mbruzek> OK. That new YAML was output from my tool that just bumps the revision numbers of all the charms to the latest according to the charmstore. Keeping bundles up-to-date was too manual for me
<mbruzek> I know why they need to be locked to revision numbers, but that makes it very difficult to maintain large bundles.
#juju 2016-05-13
<magicaltrout> can you build a reactive charm without layer basic?
<magicaltrout> i need to build a centos charm..
<magicaltrout> clearly not, you need to bootstrap wheelhouse
<magicaltrout> bugger
<marcoceppi> magicaltrout: you can build a centos charm with charm build, but there are a few calls in lib/charms/layers/basic.py that apt-install
<marcoceppi> magicaltrout: theoretically, you could create a layer:centos which overwrites that file with yum calls ;)
<marcoceppi> magicaltrout: what we really should do is have layer:ubuntu, layer:centos, layer:windows which all inherit the layer basic but have their own, language specific boostrap mechanisms
<lazyPower> There's some charmhelpers submissions from cloudbase we still need to land that came with a ton of centos abstractions
<marcoceppi> magicaltrout: I'll poke cory_fu about it tomorrow
<Prabakaran> Hi Matt, As discussed in the previous call i have made some changes in the copyright file and reactive file of ibm-java, i pushed my latest code to launchpad but i am not able to see that particular revision with the changes in the charm store.
<Prabakaran> Could someone please advise me on this?
<Prabakaran> Hi Matt, As discussed in the previous call i have made some changes in the copyright file and reactive file of ibm-java, i pushed my latest code to launchpad but i am not able to see that particular revision with the changes in the charm store.
<Prabakaran> that time i push ibm-java charm push we were not doing it. If we do charm push for ibm-java it may affect the ageing in the review queue. So I have pushed my latest code in the launchpad only
<magicaltrout> if I create a test charm for centos and do
<magicaltrout>  juju deploy --repository=. local:centos7/joshua-decoder
<magicaltrout> i end up in a machine error state without anything appearing in juju debug-log
<magicaltrout> any ideas?
<magicaltrout> 6          error                  pending                                             centos7
<cherylj> magicaltrout: if you do a status --format=yaml, you should get some more info about what happened with provisioning
<deanman> Is it possible to use manual provider to create a small group of workload VMs but instead of using KVM by default to deploy service to use lxc instead without having to use the --to lxc: command ?
<magicaltrout> marcoceppi: had a good chat today with a few of the guys, we have a Apache Joshua and Apache Nutch as good candidates for Juju integration soon
<magicaltrout> there was also good buy in from people about a jujucharms.com/apache type url that I discussed with arosales
<magicaltrout> of course for that type of thing I carry no official weight but the idea was well recieved
<hoenir> it is stable enough  to upgrade to 16.04 lts ubuntu server with maas2.0 for juju?
<marcoceppi> magicaltrout: sounds good, I know we can totally do something like jujucharms.com/apache if the community is interested in doing so
<marcoceppi> magicaltrout: I've never heard of nutch, but looks cool
<jcastro> office hours in ~1 hour folks!
<arosales> magicaltrout: I'll be talking to the design folks in person next week and will bring this up
<arosales> Good suggestion magicaltrout. Travel safely!
<jcastro> https://hangouts.google.com/hangouts/_/hoaevent/AP36tYfaxhNCLABMdXEeSBUmjxyh4UyCe5HbASMOwP-CGMF3ru8MtA?hl=en&authuser=0
<jcastro> hangout url for office hours if you want to hang out!
<marcoceppi> Office hours is live, http://ubuntuonair.com/ ask your questions here and we'll do our best to answer them
<tvansteenburgh> ahasenack: i finally discovered the world of bzr-builder and pbuilder and am working through the deployer build issues locally
<ahasenack> nice
<cholcombe> this is a silly question but where do you indicate which ubuntu release versions your charm works for?  I'd also like to indicate one of my charms works for centos7
<lazyPower> cholcombe - see: series in metdata in the release notes
<cholcombe> lazyPower, ah thanks :)
 * lazyPower points @ topic
<lazyPower> :)
<cholcombe> lazyPower, i'm having trouble finding it
<cholcombe> lazyPower, i think i found it. i need to upload a branch for xenial
<lazyPower> cholcombe - you just declare in metadata.yaml, and you dont push to a series
<lazyPower> so, if my charm defines:
<lazyPower> series: ['trusty', 'xenial']
<lazyPower> and i push foobar to cs:~lazypower/foobar - you can deploy either supported series at deploy time
<cholcombe> lazyPower, interesting.  i haven't seen any charms do that.  I'm going to try it :)
<lazyPower> juju deploy cs:~lazypower/foobar --series=trusty
<cholcombe> right
<cholcombe> ok cool
<lazyPower> cholcombe - cs:~lazypower/etcd-7 does this
<cholcombe> ah ok. i was thinking of the ceph* and some of the openstack charms i poked at
<lazyPower> but it also has a dependency on resources, so provide those bins if you are testing
<cholcombe> ok
<lazyPower> (my etcd thing, not ceph)
<lazyPower> <3
<neiljerram> lazyPower, hi there!
<lazyPower> o/ neiljerram
<neiljerram> lazyPower, I'm working on that neutron-calico <-> etcd change, but I think I'm still getting it wrong somehow.
<lazyPower> i'm all ears
<neiljerram> lazyPower, the error is: ERROR cannot deploy bundle: cannot add relation between "neutron-api:etcd-proxy" and "etcd:db": no relations found
<neiljerram> I changed the neutron-calico metadata to say this:
<neiljerram> requires:
<neiljerram>   [...]
<neiljerram>   etcd-proxy:
<neiljerram>     interface: etcd
<neiljerram> Is that what you would expect?
<neiljerram> I'm not sure what the difference is between relation name and interface name.
<lazyPower> yep. i think i see what i did (and its not necessarily good) - change the relation interface at the bottom of the bundle from "etcd:db" to "etcd:client"
<lazyPower> so long as the interfaces match, it should work. I think i declared a different relation name on etcd... which i shouldn't have
<neiljerram> Oh OK.  Is "client", in that context, an interface name or a relation name?
<lazyPower> the relation name
<neiljerram> OK, so the correct etcd-side relation name is "client".
<neiljerram> Cool, I'll give that a go.
<neiljerram> Actually no, hang on, I was misreading...
<lazyPower> neiljerram - and yeah i didnt change the relation name
<neiljerram> The error that I'm now seeing is for neutron-api, not neutron-calico.
<lazyPower> ah ok
<neiljerram> For neutron-calico it says: related neutron-calico:etcd-proxy and etcd:db
<lazyPower> sorry for the red herring, i should have looked first.
<cholcombe> i'm late to the party but this charm publish thing is really cool :)
<lazyPower> so long as the etcd-proxy relation is using the etcd interface, that should work as a drop in until we get the TLS certificates added to the interface data-pass
<neiljerram> So neutron-calico may be working.  I'd expect an error for neutron-api, because I haven't updated its code yet.  (It needs the same kind of change as neutron-calico.)
<neiljerram> Cool, so I'll make a similar change now in neutron-api...
<lazyPower> neiljerram - so, on the bright side if this basic test works for you, i have another version published which will tls terminate your endpoints, and i'm pending the last bits of code in the interface for client certs. we're very close to having POC
<neiljerram> lazyPower, That's great, thanks!
<lazyPower> so you'll get a secure etcd cluster, but nobody can connect to it with what i have done right now
<neiljerram> BTW, what is the correct Juju 2 incantation for tearing down a deployment, so that I can try again with modified charms?
<neiljerram> Perhaps juju destroy-model ? - but I really just want to undeploy all the units.
<marcoceppi> neiljerram: that's it
<marcoceppi> once you destroy model, you can juju create-model and get a fresh canvas
<lazyPower> yep, marcoceppi has the science
<neiljerram> marcoceppi, thanks
<marcoceppi> any questions for the office hours?
<neiljerram> lazyPower, Another random query just arose... does anything in your etcd work rely on Juju 2?  Because I've just heard that the project that I'm involved in is dropping back to 1.25...
<lazyPower> neiljerram - its 2.0 only, correct
<neiljerram> What are the 2.0 specific aspects?
<lazyPower> resources
<lazyPower> resources and series in metadata both cause 1.25 to complain and not function
<lazyPower> er wait, series in metadata was fixed i rescind that bit.
<lazyPower> resources however are a firm 2.0 freature
<neiljerram> But if my target is Xenial - which it is - will we be saved by the fallback kicking in?
<lazyPower> only if you use a local charm deploy
<lazyPower> so, in short:
<lazyPower> charm pull cs:~lazypower/etcd-6
<lazyPower> then put the full path to that local charm in your bundle
<lazyPower> the way resources populate from the store will be a constant problem until https://bugs.launchpad.net/juju-core/+bug/1577415 is resolved
<mup> Bug #1577415: resource-get hangs when trying to deploy a charm with resource from the store <juju-release-support> <resources> <juju-core:Triaged> <https://launchpad.net/bugs/1577415>
<rick_h_> lazyPower: can you make sure juju-min-version is set?
<lazyPower> rick_h_ https://github.com/juju-solutions/layer-etcd/blob/master/metadata.yaml#L14
<lazyPower> igotchoobb
<rick_h_> lazyPower:  we should look ay updating the charmstore on those to help that case
<rick_h_> lazyPower: <3
<lazyPower> neiljerram - i'm going to dip out for a quick lunch. Ping if you need me in the meanwhile.
<neiljerram> OK, cool, I think that's OK for now.
<neiljerram> Thanks!
<tvansteenburgh> rick_h_: the new charm Review Queue needs this https://github.com/juju/charmstore-client/issues/57
<tvansteenburgh> rick_h_: thoughts?
<magicaltrout> cory_fu: i need to create a charm that has access to the hadoop executable
<magicaltrout> can I do it? and what do I make it subordinate to?
<cory_fu> magicaltrout: Have it use the hadoop-client base layer which will enable it to connect to the plugin and then it can connect to either the vanilla Apache Hadoop charms or the Apache Bigtop Hadoop charms
<magicaltrout> fscking cool!
<magicaltrout> i shall do that, thanks
<cory_fu> magicaltrout: https://github.com/juju-solutions/layer-hadoop-client/blob/master/README.md
<cory_fu> Had good info
<magicaltrout> cory_fu: also, is it possible for an action to set a reactive state? For example I don't want my serivce to start until someone executes an action to configure some stuff
<cory_fu> magicaltrout: Absolutely.  If your action is in bash, it can use `charms.reactive set_state foo`.  If it's in Python, just `from charms.reactive import set_state; set_state('foo')` like normal
<magicaltrout> cool thanks
<cholcombe> for the local juju provider do you have to download a xenial image or something if you're running trusty?
<lazyPower> cholcombe - the first time you deploy a xenial series charm it will fetch the base image and create the template, yes
<lazyPower> and when you say local i assume you mean 1.25 local provider
<cholcombe> lazyPower, correct
<lazyPower> yep, thats all valid info then
<thedac> beisner: https://review.openstack.org/#/q/topic:bug/1581171 should help with Bug#1581171
<mup> Bug #1581171: pause/resume failing <uosci> <cinder (Juju Charms Collection):In Progress by thedac> <glance (Juju Charms Collection):In Progress by thedac> <keystone (Juju Charms Collection):In Progress by thedac> <https://launchpad.net/bugs/1581171>
<beisner> thedac, thx.  i think you'll want to rm the __pycache__ bits that got checked in on those reviews though
<thedac> beisner: good catch
<beisner> thedac, likewise ;-)
<beisner> thedac, keystone's python process not running/binding @ https://openstack-ci-reports.ubuntu.com/artifacts/test_charm_pipeline/openstack/charm-keystone/316195/2/2016-05-13_17-07-45/index.html   (see keystone-0-listening.bz2)
<beisner> thedac, i've been seeing that intermingled with this pause/resume thing, may be a separate bug though
<beisner> so the amulet test tries to initialize a keystone client whilst the charm is in that state
<beisner> ultimately, the tests will race if/when workload status "Ready" isn't actually the case of course.
<thedac> beisner: hmm, I'll run that one locally
<cholcombe> lazyPower, i got too crazy with metadata series :).  charm push doesn't allow centos and ubuntu mixed series
<beisner> thedac, looking at the unit log, i actually expect us to race all over the place.  one small snippet of what looks to be a common "I'm Ready ... No, wait.  Watch me fire a hook and render some templates again.." funnybusiness.  http://pastebin.ubuntu.com/16394586/
<beisner> thedac, err, this paste i mean:  http://pastebin.ubuntu.com/16394637/
<thedac> looking
<thedac> Well, I expect the update-status hook will re-render config files. So I am not sure that is a problem
<lazyPower> cholcombe - nope, no cross-distro series sir
<lazyPower> it'll require another layer
<cholcombe> sad
<lazyPower> thankfully with layers, you can do that pretty cheaply
<thedac> beisner: I suspect set_api_version in basic_deployment.py is racing the config change.
<lazyPower> cholcombe - we've talked about making another layer up -  layer:ubuntu, layer:centos, layer:windows
<cholcombe> lazyPower, that'd be nice :)
<lazyPower> which all inherit from layer:basic, and give you all the amenities you need for each platform starting with that layer
<lazyPower> but we haven't got anything concrete
<lazyPower> so, if you're interested, my thought is poke dbulgia@cloudbase, as he has a lot of work already done to abstract host level bits for centos (see: charm-helpers pr listing), and would be a good stakeholder for a first centos layer.
<lazyPower> and i'm fairly certain he would be super jazzed to be working with a charmer  :)
<beisner> thedac, that looks to be the case.  but set_api_version comes later than init, where self._auto_wait_for_status happens
<beisner> b/c we guard _initialize_tests with the wait for status bits
<beisner> in __init__
<thedac> Right but this is failing at test_112_keystone_tenants. There are multiple calls to set_api_version none of which doing any waiting to make sure it is done if it changed
<thedac> biesner: just do a search for set_api_version. It has the possiblilty of changing multiple times https://github.com/openstack/charm-keystone/blob/master/tests/basic_deployment.py#L346
<beisner> right-o indeed!
<beisner> there needs to be a wait for status on every one of those
<beisner> not just a retry diaper
<thedac> Right
 * beisner <3 chasing ð ð
<thedac> beisner: suggest http://pastebin.ubuntu.com/16395138/
<thedac> Does that seem reasonable to you
<beisner> yah just like we've done in rmq, dashboard and wherever else
<thedac> Ok, pushed up to reviews. Let's watch CI
<beisner> this is actually the first time i've looked at the ks v3 amulet tests.  def-o need some race avoidance
<magicaltrout> marcoceppi / kwmonroe : what needs to happen to get openjdk charm on xenial?
<cory_fu> magicaltrout: I think we just need to push it.  I don't see any reason why it wouldn't work
<cory_fu> Give me a second
<magicaltrout> thanks
<magicaltrout> i've cloned it locally so i can check that, but it sucks for normal people ;)
<cory_fu> magicaltrout: A verification would be great.  I'm going to add the series to the metadata and PR that
<cory_fu> lazyPower: What's the syntax for series in metadata?  Just "series: [trusty, xenial]"?
<lazyPower> yep
<marcoceppi> cory_fu: preferablly
<magicaltrout> hold up
<marcoceppi> series:
<marcoceppi>   - trusty
<marcoceppi>   - xenial
<Merlijn_S> @cory_fu I'm here :)
<magicaltrout> it's exploded
<cory_fu> magicaltrout: Oh noes
<magicaltrout>  Package 'openjdk-7-jre-headless' has no installation candidate
<cory_fu> Merlijn_S: Ok, give me a sec to set it up
<cory_fu> Merlijn_S: https://plus.google.com/hangouts/_/canonical.com/eco-wx
<magicaltrout> ah yeah xenial is java8+
<cory_fu> magicaltrout: I thought it should use the default Java for the series by default
<cory_fu> But you can set the config option to use 8
<magicaltrout> yeah, kwmonroe set it to do       apt-get install -qqy openjdk-${java_major}-jre-headless openjdk-${java_major}-jdk
<magicaltrout> so its broken by design ;)
<cory_fu> Ah.  Ok.  Hrm.
<cory_fu> We'd want a different default value for each series, then
<beisner> thedac, my amulet --> venv full recheck passed for glance (but with the pause/resume test disabled):  https://review.openstack.org/#/c/315777/
<beisner> thedac, next - let's land your glance thing then i'll rebase and re-enable that test, yah?
<thedac> Sounds good. Can you do the +2 honors
<beisner> thedac, indeed.  meanwhile, can you give https://review.openstack.org/#/c/315777/ a pass-through and call out anything that's not clear?  worth starting in the README_TESTS.md update to see the new usage, etc.
<thedac> Sure, I'll get to that after lunch.
<beisner> thedac, thx, thx, and thanks.   maybe one more tyvm, i'm losing track. ;-)
<thedac> :)
<magicaltrout> yeah cory_fu works fine when i set the major version
<lazyPower> tvansteenburgh - have we done any amulet tests against any multi-series charms?
<tvansteenburgh> i have
<lazyPower> good results?
<lazyPower>  i've defined series='xenial' in my deployment, yet i'm still getting trusty flavored charms deployed in my tests. :(  so pebkac somewhere
<tvansteenburgh> hmm
<lazyPower> ok weird
<lazyPower> if i define xenial as the first series in my charm, i get a xenial series charm
<tvansteenburgh> lazyPower: yeah...can you file a bug on this, pretty sure i know what's going on
<lazyPower> sure thing, inc.
<tvansteenburgh> lazyPower: was trusty the first one in the list before?
<lazyPower> https://github.com/juju/amulet/issues/137
<lazyPower> yep
<beisner> thedac, glance merged, rebased, smoke passed, full now underway
<beisner> thedac, as an aside - based on most recent fail on dosaboy's https://review.openstack.org/#/c/314063/ - i suspect rmq is also status racing.  in that one, rmq was listening but status was blocked, waiting for it to start.
<magicaltrout> cory_fu: what am I doing wrong?
<magicaltrout> https://gist.github.com/buggtb/a6cb65333e63bc3c905f088469c2fdca#file-gistfile1-txt-L29
<magicaltrout> https://gist.github.com/buggtb/b09631cd57531a730798545ca82c8e2f#file-gistfile1-txt-L11
<magicaltrout> ignore me
<magicaltrout> my update hadn't fired.....
<cory_fu> magicaltrout: Yeah, that action sets the state, but the reactive dispatch loop isn't running so it doesn't have a chance to handle the state.  You can manually call hooks/update-status after setting the state in the action
<cory_fu> There are proposals to make actions part of the reactive dispatch loop, which would make it work a bit clearer
<magicaltrout> cool
<thedac> beisner: ok, rabbitmq will have to go on the pile
<beisner> thedac, ack.  also see comment on your keystone review
<thedac> ok
<thedac> beisner: mind doing cinder so it does not get lost? https://review.openstack.org/#/c/316194/
<beisner> thedac, yep i'm going to do the same there.  land, rebase into my test refactor, retest.
<thedac> got it
<tvansteenburgh> ahasenack: hey, one thing i wasn't clear on re version updates to debian/changelog in the packaging branch...do you just update that when you notice the upstream version has changed?
<tvansteenburgh> ahasenack: and how is that version (e.g. 0.52.0-0ubuntu1~ppa1) constructed? is that a dch thing?
<ahasenack> tvansteenburgh: the recipe grabs the debversion from the last changelog entry, and appends what the recipe instructs
<ahasenack> {debupstream}~bzr{revno}~{revno:packaging}
<ahasenack> "debupstream" is the version
<ahasenack> taken from changelog
<ahasenack> the rest in the changelog is ignored
<ahasenack> so I don't have to update the changelog everytime there is a change in the bzr branch the recipe monitors
<tvansteenburgh> ah, okay, so do you manually type the new version into the changelog?
<tvansteenburgh> was wondering about the ~ppa1 or ~ppa2 bits on the end
<ahasenack> I do that out of convention
<ahasenack> when uploading to ppas
<ahasenack> that comes with the help of dch, yes
<tvansteenburgh> okay cool, thanks
<ahasenack> but it's ignored by the recipe because it's in the release portion of the package full version number
<ahasenack> so it's not inside {debupstream} above
<ahasenack> but helps if doing a manual build locally
<tvansteenburgh> gotcha
<marcoceppi> tvansteenburgh: yeah, for releasing, you'll need to update the debian packaging branch
<marcoceppi> tvansteenburgh: I can so you my workflow if you're curious
<tvansteenburgh> marcoceppi: yeah, i think i get it now. update changelog for new version. but yeah, wouldn't hurt to walk through it once
<tvansteenburgh> marcoceppi: we should do an amulet release soon
 * marcoceppi mods
<tvansteenburgh> for the juju2 stuff in particular
<marcoceppi> yeah
<marcoceppi> tvansteenburgh: is it ready to go today?
<tvansteenburgh> marcoceppi: yep
<lazyPower> i'm doing the hallway test rn
<lazyPower> if that helps confidence any :D
<tvansteenburgh> marcoceppi: merge #137 first
<marcoceppi> its friday, the 13th, whats the worse that could happen
<tvansteenburgh> haha
<lazyPower> oh man, this is glorious. clean output from everything with tip of our tooling.
<marcoceppi> \o/
<marcoceppi> time to release
<lazyPower> tvansteenburgh - passes the lazypower test
<lazyPower> \o/
<tvansteenburgh> sweet
<marcoceppi> tvansteenburgh: should we start an amulet daily ppa?
<tvansteenburgh> marcoceppi: sure
<marcoceppi> eh, later
<tvansteenburgh> actually i was just gonna build all the dailies into one ppa
<tvansteenburgh> is there a reason to have a separate ppa for every package?
<marcoceppi> tvansteenburgh: possibly, but I'm a +1 to a charm-testing daily ppa
<tvansteenburgh> ok
<marcoceppi> okay, 1.15.0 is out
<tvansteenburgh> woot
<tvansteenburgh> thanks
<lazyPower> nice
 * beisner likes those ideas! ^
<beisner> thedac, gears are all turning.   fwiw, that rmq thing 2 for 2 on dosaboy's review.  i've not poked further or logged it on the bug, but i think it's same/similar topic.  thanks again for drilling down on those today.
<thedac> no problem. Seems we have lots of races to track down
#juju 2016-05-14
<alexbligh1> juju-quickstart (creating a local environment) gives me "juju-quickstart: error: error: flag provided but not defined: -e" - debug log at http://pastebin.com/PiR6D5Mn - any ideas?
<tvansteenburgh> alexbligh1: are you using juju2?
<tvansteenburgh> alexbligh1: what's the output of `juju version`
<alexbligh1> tvansteenburgh, looks like it. I followed the instructions at https://jujucharms.com/get-started to the letter.
<alexbligh1> 2.0-beta6-xenial-amd64
<alexbligh1> completely clean install of Xenial done 10 minutes ago.
<tvansteenburgh> alexbligh1: yeah, there's bug open to fix those instructions i believe :/
<tvansteenburgh> alexbligh1: one sec
<alexbligh1> tvansteenburgh, looks like juju-quickstart is using old CLI format or something? All I wanted to do was boot a new local environment...
<tvansteenburgh> alexbligh1: yeah, quickstart only works with juju-1.x, in juju-2 it is folded into juju itself
<alexbligh1> tvansteenburgh, ok let me purge that then.
<tvansteenburgh> alexbligh1: sudo apt install juju-1.25 instead
<alexbligh1> tvansteenburgh, mmm - I was trying to test out the juju with lxd stuff. Does 1.25 do that?
<tvansteenburgh> alexbligh1: heh, so you do want juju2 then
<tvansteenburgh> alexbligh1: you just don't need quickstart
<alexbligh1> tvansteenburgh, indeed. I wanted to play with lxd & zvols etc.
<tvansteenburgh> you can just `juju deploy mediawiki-single`, don't need quickstart on juju2
<tvansteenburgh> https://jujucharms.com/docs/devel/getting-started
<alexbligh1> tvansteenburgh, ah OK I think my mistake is that 'apt-get install juju-local' pulls in juju-1.25.
<tvansteenburgh> alexbligh1: i recommend those docs instead ^
<tvansteenburgh> alexbligh1: still beta, but it has the lxd integration
<tvansteenburgh> i've been running it every day for weeks (on xenial), works great
<alexbligh1> that's what I need. Thanks. Let me give that a go instead
<alexbligh1> tvansteenburgh, thanks - that worked just great.
<tvansteenburgh> alexbligh1: excellent, you're welcome
 * cholcombe tries out juju2.  completely lost lol
<arosales> cholcombe: hello
<cholcombe> arosales, hey there
<cholcombe> freak_, arosales might be able to point you in the right direction
<freak_> cholcombe_ ok i will talk to him regarding my concerns
<rick_h_> what's up cholcombe freak_ ?
#juju 2016-05-15
<cholcombe> charmers: if anyone would be willing to give this a second look/chance I'd really appreciate it: https://bugs.launchpad.net/charms/+bug/1469213
<mup> Bug #1469213: Submitting a Gluster Charm for Review <Juju Charms Collection:In Progress> <https://launchpad.net/bugs/1469213>
<cholcombe> I ran into a roadblock last year with juju storage being in development.  I've since fixed that and added support storage
<cholcombe> support for storage*
#juju 2017-05-08
<kjackal> Good morning Juju world!
<roadmr> hello folks! Hey, periodically I have to "compact" my juju1 db, particularly on node 0. For this I need to stop the juju-db service. Is there a way to compact the DB while keeping juju running?
<rick_h> roadmr: sorry nothing new on that front. There's a ton of work into 2.2 for db size and maintenance but nothing that would compact while it's running. I think that's more a mongodb limitation that the db has to come offline to do the compacting.
<roadmr> rick_h: ok, it's what I thought but felt it couldn't hurt to ask :)
<rick_h> roadmr: definitely
<roadmr> rick_h: thanks though!
<lazyPower> rick_h: i wonder if thats not something we could tune for a maintenance window?
<lazyPower> something like ship w/ a cron job that once a week takes it offline for 15 minutes to compact teh db
<rick_h> lazyPower: well I think the goal is that you won't need compacting with all the work going into maintaining the db better
<lazyPower> unless thats taking too many liberties.... in which case i would then think modeling the controller as a charm and giving it some actions would be ace
<rick_h> lazyPower: but it'd be something that'd be interesting to see if we can get concrete numbers on how/when a user would need to.
<rick_h> lazyPower: :) well that's the long term idea
<lazyPower> aww yeee
<lazyPower> <3
<lazyPower> rick_h: i redeployed my k8s cluster this weekend (in house) so i could really change teh topology. I'm happy to report there were no issues sticking flannel on the controller ndoe
<lazyPower> i did some very dirty things...
<lazyPower> stuff you would approve of, but it all worked
<lazyPower> so all our effort in making 2.x more bulletproof has paid off
<rick_h> lol
<SimonKLB> anyone know how one would go about co-locating in amulet tests? since you can't add an application after you run setup() im not sure if there is any good way to find the correct machine id for placement
<SimonKLB> libjuju to the rescue :D
<lazyPower> SimonKLB: you read my mind :)
<kim0> Howdy channel .. I saw some discussion about cloud-integration (cloud-native) .. Can someone give me an idea what that is about .. Thanks!
<lazyPower> kim0: with respect to kubernetes?
<kim0> yes
<lazyPower> kim0: certainly. Cloud integration would bridge the gaps between CDK and what K8s natively supports. Today we model Kubernetes in a bare-metal first nature, where it behaves the same as it does on bare metal no matter where you deploy it. Many users have requested cloud-integration for supported things like  Service type: load-balancer which will yield an ELB on AWS
<lazyPower> auto provisioning of EBS storage as PV's
<kim0> Aha I see .. yeah that would surely be useful :)
<lazyPower> things of that nature. So our goal there is to model it in a secure way that wont leak credentials, and allow the administrator to plug those cloud-integrations right into CDK for a seamless experience. Bare metal users are still tended to as they just dont enable the intgrations.
<kim0> is that coming any time soon :)
<lazyPower> we have some pre-alpha quality work now, nothing public that I can point you to
<lazyPower> but it is on the docket for this 17.10 cycle
<Budgie^Smore> lazyPower does it usually take this long to hear back about that developer access?
<lazyPower> Budgie^Smore: no
<lazyPower> you should have heard back already. I know that marco is currently at ODS
<lazyPower> so that may be why, it got missed and he's busy giving talks.
<lazyPower> Budgie^Smore: i'll poke him gently and see if we can expedite that
<Budgie^Smore> lazyPower no problem was just curious... probably right con-season can be crazy
<Budgie^Smore> I really want to build a "cluster in a box" that could be "picked up" by devs / iot people
<Budgie^Smore> http://www.asrockrack.com/general/productdetail.asp?Model=E3C226D2I looks a nice mini itx with ipmi support!
<lazyPower> Budgie^Smore: thats a nice lookin box bruv
<lazyPower> s/box/board
<Budgie^Smore> yeah 2 NICs and 1 IPMI separate is really nice to find
<Budgie^Smore> only real prob right now is to find a small yet large enough managed switch (12 port min)
<lazyPower> that doesn't break the bank or require a unifi controller amirite? :D
<Budgie^Smore> something like that... really wondering if I could "crowdsource" this idea maybe even build some sort of backplane that connects multiple boards with a switch
<Budgie^Smore> I can't be the only one that would drop a couple of grand on a "cluster in a box" solution
<lazyPower> Budgie^Smore: you're not, thats why we built the orange box
<lazyPower> Budgie^Smore: a lot of vendors are showing up at conferences with ARM based alternatives like cubie boards or rpi clusters.
<Budgie^Smore> yeah and discontinued it too :-/ although I would say that box was a little bit over powered for a small cluster
<lazyPower> I myself have a stack of about six rpi 2's and 3's next to me on my desk that I fiddle around with periodically.
<lazyPower> well, you wanted some beef to run the workloads + openstack
<Budgie^Smore> oh yeah for conference, etc. it would be awesome but I am thinking more small form factor 5 node box
<lazyPower> its less compelling if its just an openstack box, but if you can deploy stuff on top of it and demo the whole suite of jujucharms on sight without dealing with firewalls, access, et-al. its a handy tool for tech previews
<lazyPower> I hear ya. Thats the entire reason i dubbed my pi cluster "The Clementine Box"
<Budgie^Smore> 1 node maas + 4 nodes whatever the f you want ;-)
<lazyPower> i wanted something to stand up both lxd and swarm on and demo the two container techs working in harmony
<lazyPower> and they do :D
<lazyPower> but provisioning is not as nice as PXE only landed on the rpi3
<lazyPower> and power management is still an issue
<Budgie^Smore> yeah I still want an x86 platform
<lazyPower> but the baseline concept is there and it was a great learning tool
<lazyPower> i stll say grab some gigabyte brix boards
<lazyPower> and hobby to your hearts content
<lazyPower> they're pretty small and beefy enough to run some serious workloads on them, thats 3/4 of my @ home k8s cluster is gigabyte brix units.
<Budgie^Smore> hence looking at that board... having 2 gbic nic and ipmi gives you everything you really need for both power management and network layouts
<Budgie^Smore> pop in an i3 or i5 and you have a beefy little server cluster
<lazyPower> yep yep
#juju 2017-05-09
<Zic> hi here
<Zic> I saw at "juju config kubernetes-worker" that an optional parameter "require-manual-upgrade" is available, if I understand correctly, this tell snaps package to not auto-upgrade in its channel, right?
<Zic> if yes and if I enable this, to upgrade to the next version of K8s, what I will must do?
<kjackal> hi Zic, you will not need to do anything to upgrade the workers incase you se the "require-manual-upgrade". Workers will just upgrade without prompting you
<Zic> kjackal: ah, requireÃ¨-manual-upgrade is set to true by default?
<Zic> thought it was to false
<lazyPower> Zic: its a decoupling of the operations code and the application code. teh thought is if you're riding the edge or when there's a new track release (1.7/stable) - you'll be prompted to run the upgrade action
<lazyPower> Zic: its a way for you to plan for potential downtime during an upgrade.
<Zic> lazyPower: understood, so to sum up, by default:: - Kubernetes components are auto-upgraded via snap channels, but only in minor version (as it's set on the stable/1.6, and for major upgrades like 1.7, I will need to change this channel) / - Juju's charm are manually upgraded via upgrade-charm
<Zic> I was a bit confused because previously, I only upgraded charms where a new version of K8s is available @CDK :)
<lazyPower> :) you'll be able to get patch releases this way in a more streamlined manner
<Zic> lazyPower: so the default behaviour is cool :D I was afraid all was automatic (not the charm's part, as kjackal told me yesterday, but the major release of K8s also)
<Zic> lazyPower: as Kubernetes releases are not "synced" with charm revision, do you stick some "minimum required version" of K8s/charms? like if I let a cluster a long way without human intervention, it will regularly upgrade K8s but not the operational code, can it screw something up?
<lazyPower> Zic: we only test with the latest 2 revisions of kubernetes. so right now our charms support 1.5 and 1.6 respectively
<lazyPower> Zic: its basically a six month support cycle since k8s releases quarterly
<Zic> ok for testing but is there any hardcoded value like "charms revision 29 cannot exceed Kubernetes 1.5.3"?
<Zic> (6 month is large anyway, it's just curiosity)
<lazyPower> we dont have any logic like that in teh charms today, no
<Zic> ok, and last question : if I run through an upgrade process from Kubernetes 1.5.3 with charm revission 12=master, 14=worker, does it will directly jump to 1.6.2?
<Zic> (or just 1.6.1, then snap will perform the 1.6.2 upgrade by itself)
<lazyPower> it'll go to 1.6.2
<lazyPower> thats whats in the stable channel today
<Zic> (hmm, I lied when I said it was my last question... I'm testing upgrading to the latest charm revision our testing cluster, I run correctly through the upgrade-charm kubernetes-worker, but when I did the "juju config kubernetes-worker channel=1.6/stable" just after the upgrade-charm was finished, I got a "blocked Needs manual upgrade, run the upgrade action", so I re-runed the upgrade-charm but I just got a
<Zic> "Error: already running latest charm "cs:~containers/kubernetes-worker-23"")
<lazyPower> Zic: juju run-action kubernetes-worker/# upgrade
<Zic> ok
<Zic> is it normal? it's the testing cluster, all default values from CDK
<Zic> (I think it's because juju config kubernetes-[master|worker] channel switch from stable to 1.6/stable, and it's considering I'm changing of release, right?)
<skay_> mojo question. I upgraded to yakkity. removed old mojo and installed the snap version. should it make a mojo group? there is no mojo group
<skay_> I don't know if that will be a problem yet. I can't get past trying to create a new project
<skay_> when I try to create a new mojo project, the snap barfs on calling mojo-project-new https://paste.ubuntu.com/24543200/
<skay_> I've got /snap/bin in my path
<skay_> mthaddon: are you around for a mojo question? see above
<mthaddon> looking
<mthaddon> skay_: this looks to be a problem with the snap - looks like it's not exposing a number of binaries it should be (including mojo-project-new)
<mthaddon> skay_: can I be annoying and ask you to file a bug? https://bugs.launchpad.net/mojo/+filebug
<skay_> mthaddon: hah, you beat me to it
<skay_> will do.
<mthaddon> thx
<skay_> lp:1689574
<skay_> mthaddon: btw, apt update is complaining about the ppa
<skay_> I don't know if that's me or not. I can file a bug if it turns out not to be me. Update is complaining about a missing Release file
<skay_> and packages
<skay_> (I'm pretty sure it must be me)
<skay_> derp I meant zesty
<skay_> obv I need more coffee
<skay_> workday jetlag
<mthaddon> skay_: https://bugs.launchpad.net/mojo/+bug/1684342
<mup> Bug #1684342: No PPA release for zesty <canonical-bootstack> <mojo:New> <https://launchpad.net/bugs/1684342>
<skay_> mthaddon: I'd like to use the snap, but could use the yakkity distro until the snap bug is fixed.
<mthaddon> ack
<Zic> https://www.youtube.com/watch?v=4ht22ReBjno "The illustrated Children's Guide to Kubernetes" -> very nice intro for customer's presentation :D
<Budgie^Smore> o/ juju world
<lazyPower> heyo Budgie^Smore
<lazyPower> Zic: thats a fantastic story by teh deis peeps
<Budgie^Smore> hows the world today?
<lazyPower> Budgie^Smore: its still spinning :)
<lazyPower> captain kubie is my favorite ;D
<Budgie^Smore> ??
<lazyPower> the owl in the illustrated guide to kubernetes
<lazyPower> https://www.youtube.com/watch?v=4ht22ReBjno
<Budgie^Smore> I think I have watched this before
<lazyPower> i would think so, its been around a little over a year :D
<Budgie^Smore> OK now I am sure of ;-)
<lazyPower> and it got wildly popular at the last kubecon event
<lazyPower> the one pre-berlin
 * Budgie^Smore rarely gets to to go cons :-/ 
<lazyPower> We need to get you outta the office Budgie^Smore
<lazyPower> also i haven't seen marco around so I'm pretty sure you're just buried under his conf schedule. I'll keep it on my todo list until i've confirmed you've gotten a response
<Budgie^Smore> how about getting me into the "office" instead ;-)
<Budgie^Smore> the CRE role is still showing as being in open status
<lazyPower> thats not something i have any insight into
<kwmonroe> lazyPower: it's my quarterly duty to thank you for charmbox.  i docker pull that sucker every couple months, and it's always solid.  thanks!
<lazyPower> <3
<tychicus> is there an equivalent of âconfig use-floating-ip=true and âconfig network=UUID when deploying bundles?
<tychicus> I'm guessing that it has something to do with spaces, but I haven't quite wrapped my head around spaces yet
<hml> tychicus: you can set those values on a per model basis if youâd like
<tychicus> ok, just found juju model-config
<tychicus> hml: thanks
<tychicus> working now
<hml> tychicus: :-)
<h00pz> wondering if Billy Olsen is connected ?  Donât know his handle
<blahdeblah> h00pz: wolsen probably a good bet. :-)
<h00pz> Thanks, I assumed wrong on the first name and looked for B
<h00pz> also who do I complain to about the retarded length of the nova-cloud-controller. ncc would be wayyyyyyy nicer
#juju 2017-05-10
<xavpaice> I'm just about to do a mgopurge of a site running 2.1, and hear rumor that we don't need to stop the state server beforehand - is that the case?
<xavpaice> h00pz, first thing to do is request the ability to change the name of a charm for a running application without redeploying the application
<h00pz> xavpaice, yah im already building my own bundle, next step, make charm names smaller cuz
<xavpaice> at least you can deploy apps with any name you like
 * xavpaice was pointed at https://github.com/juju/juju/wiki/MgoPurgeTool which has everything I might need
<erik_lonroth3> When I'm setting states "set_state('foo.bar') ... am I also required to remove that state when I'm done with it? As I understand it, a "state" is something that otherwise is persistent for the charm until its removed?
<kjackal> Good morning Juju world!
<kjackal> erik_lonroth3: Yes, "foo.bar" is more like a flag that you can raise and lower. It is not automaticaly unset, it is not en event
<kjackal> Hi rick_h, I heard you showed some interest in the Instana charm PoC. https://jujucharms.com/u/instana-charms/instana/  and https://instana.atlassian.net/wiki/pages/viewpage.action?pageId=15630376
<kjackal> This charm is just a PoC that Instana can iterate on. If you want to fill up some slot in the some upcomming juju show, I can help.
<erik_lonroth3> kjackal: thanx
<erik_lonroth3> Also, I'm trying to understand how to differentiate between hooks and states. Its kind of hard to get a good grasp about how it works.
<erik_lonroth3> I've understood that hooks are run by juju as part of some kind of cycke. Byt which are those and how can I access states from different components etc. there are alot of questions and I can't really get my head around the reactive framework
<kjackal> erik_lonroth3: Since you are using the reactive framework you should really not use hooks.
<erik_lonroth3> I know, but I'm perplexed about which states exists, and how I can use them etc. For example. How would I find out which states a different charm is in?
<erik_lonroth3> ... is states.
<erik_lonroth3> or
<kjackal> erik_lonroth3: The way I understand it is that hooks are essentialy executable files under the /hooks dir. Juju will call these hooks at the right time throuout the lifecycle of the infrastructure
<erik_lonroth3> I have  understood that "hooks" are run aswell as setting reactive states.
<erik_lonroth3> juju seems to do both things.
<kjackal> erik_lonroth3: reactive takes over the hooks and from then on you are programming the lifecycle of your infrastructure using states
<erik_lonroth3> I'm looking for the equivalent to "d_relation_joined" state.
<erik_lonroth3> db_relation_joined
<erik_lonroth3> Yes, I understand that part. But all the hooks that exists - do they have a corresponding state?
<kjackal> No, hooks and states are seperate. Let me give you an example
<erik_lonroth3> getting coffee
<erik_lonroth3> =)
<erik_lonroth3> back
<kjackal> You have two charms. MariaDb and and Media wiki. THese two charms use the mysql interface
<kjackal> if you go to http://interfaces.juju.solutions/ and look for the mysql interface you can end to the git repo
<kjackal> Here it is: https://github.com/johnsca/juju-relation-mysql
<kjackal> Interfaces is the only place where hooks and states are mixed. This gives you an understanding how these two work together
<erik_lonroth3> I'll take a look
<kjackal> Have a look here: https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L26
<erik_lonroth3> I'm trying to write a charm that uses a postgresql database. I haven't got it to work yet since I'm struggeling understanding how to use the interfaces, states etc.
<kjackal> The joined method of the interface will be called when the @hook('{provides:mysql}-relation-joined') is triggered
<kjackal> the join method of the interface will set the state conversation.set_state('{relation_name}.database.requested')
<erik_lonroth3> let me read.
<erik_lonroth3> I'll look and come back. Thanx alot for helping me!
<kjackal> Here is the example code to be used for pgsql interface: http://interface-pgsql.readthedocs.io/en/stable/requires.html#example-usage
<kjackal> erik_lonroth3: hope it is uptodate ^
<Zic> lazyPower: just did a quick "real test" : I stopped the VPN between FR (which have kubernetes-master machine and some kube-dns pods) <-> US (some kube-dns pods also) and on FR, all resolving through kube-dns are OK, for US however, resolving works sometime, sometime not... (I think it works when the kube-dns service throw a resolving demand to a kube-dns pod @US, and don't work if it throw to FR kube-dns pods)
<Zic> so, in my case, it's a bit a disaster :(
<Zic> 2 points of presence are tied together
<Zic> don't know if something exist for this kind of case except the kube-fed
<kjackal> Hi Zic from a high level perspective your setup better fits to federation
<Zic> yup, I'm waiting it on CDK, I know it's already planned very soon :)
<Zic> but for now, I don't know what can I do to mitigate this effect :/
<kjackal> Zic: kubefed 1.6.2 is already snapped and we are working on lighting up this scenario but we are not there yet
<magicaltrout> work faster!
<Zic> huhu
<kjackal> stop interupting me magicaltrout lol
<Zic> and my tests was pointed to kube-dns, actually I think I have the same problem with all K8s services: the're not updated with the remaining pods on US
<Zic> they all continue to forward to FR+US instead of just US, as the master located in France cannot send the update information, afaik
<Zic> kjackal: do you know if converting an existing CDK cluster to a "one of" kube-fed CDK clusters will be possible?
<Zic> or do I need to restart from scratch and build a new CDK with kube-fed clusters?
<Zic> (rephrasing my question: do you know if such a scenario is planed to be supported in the future Juju scenario of kube-fed)
<Zic> CDK classic cluster -> CDK clusters, part of a Federation with a new CDK cluster
<kjackal> Zic converting a cluster is a resonable ask. We are looking at what is the most frictionless path.
<Zic> kjackal: in fact, I will let the FR cluster as it is, and deploy a new one, with a full controll-plane at US
<Zic> then linking them through a Federation
<Zic> anyway, for what can I done, I'm thinking about two completely separate cluster in waiting of kube-fed, it's maybe a better way
<Zic> s/done/do/
<rick_h> kjackal: ty, I'll see thanks. I was looking through recently updated charms in the store and ran across it and thought it was cool
<lazyPower> Zic:  i'm not sure i follow
<lazyPower> Zic: help me understand the conundrum with the US DNS scenario
<lazyPower> Zic: ahhhh, i think i'm understanding. As these two clusters are feeding from the same etcd backend, you're getting dns entries that point to services in BOTH clusters
<lazyPower> Zic: is that consistent with your findings?
<lazyPower> erik_lonroth3: are you moving forward now with a better understanding of states?
<lazyPower> magicaltrout: you scallywag :P
<erik_lonroth3> I'm going to work more on it later today as I had to do another thing just nu.
<erik_lonroth3> now
<magicaltrout> just telling kjackal to do some work for a change!
<lazyPower> erik_lonroth3: ok. When you progress into looking at that deeper dont hesitate to ping either myself or kjackal. I've done a fair amount of charm training and relationships + states are arguably one of the harder concepts to grasp because it touches both the old-world of hook based programming, and the new world of state based programming.
<magicaltrout> nooooooooooooooooooooooooooooooooooooooooooooooooooooo
<magicaltrout> not hooks ;'(
<lazyPower> magicaltrout: you have to deal with hooks to set the proper states :)
<lazyPower> and you know this
<erik_lonroth3> Yes, I think thats what confuses me alot. Also read that the old "hook" framework will go away, which makes me hesitant to even use "hooks" in my code.
 * magicaltrout pretends hooks don't exist. Its worked well so far
<lazyPower> as far as i know we're not removing the hooks. Thats still a baseline juju primitive
<magicaltrout> kjackal is quite primitive
<lazyPower> erik_lonroth3: and disregard magicaltrout, someone yanked his chain this morning...
<magicaltrout> its 2pm
<lazyPower> its 8am in KC MO
<lazyPower> time zones are not a thing
<magicaltrout> you're trying to tell me kjackal isn''t primitive?
<magicaltrout> hmm
<magicaltrout> maybe primal then
<lazyPower> well thats debateable
<lazyPower> i'll cede to that
<magicaltrout> hehe
<lazyPower> something something greek geeks something something ;)
<kjackal> LOL!!! You people are crazy!
<lazyPower> :D
<Zic> lazyPower: yup, FR have all the controlplane (kubernetes-master, etcd, easyrsa, kubeapilb) + kubernetew-worker, US just have kubernetes-worker
<Zic> if the VPN go offline between FR and US, Kubernetes services components is buggy, as they continue to forward some request to FR pods from US
<Zic> (which cannot, as VPN is dead)
<Zic> I think there is no local system at kubernetes-worker which check if all pods of a service is alive, it's only the master & etcd which have the info
<lazyPower> Zic: yeah, thats not something we can directly support today without making modifications to upstream
<lazyPower> the expectation there woudl be to run a control plane with independent etcd backends per cluster, and use federation
<lazyPower> you're on teh right path with the analysis this morning
<lazyPower> sorry I didn't catch that before, i clearly had not devoted enough braincells to the question when it was originally posed
<Zic> I think I will do some GeoDNS magic which said "if VPN goes down, switch US traffic to FR" in waiting kube-fed as part of CDK :)
<Zic> it's not the best way, but it can mitigate this issue
<Zic> lazyPower: as I questioned kjackal this morning, do you plan converting an existing CDK cluster to be part of Federation cluster in the next Juju scenario with kube-fed? or should I plan a new cluster(s) to switch to the fed model?
<lazyPower> Zic:  you would need to redeploy the US cluster as its bound to the current FR control plane
<lazyPower> you might be able to just unrelate and deploy a new CP and then relate to the new CP
<lazyPower> but tahts not something I have tested personally.
<lazyPower> and i hesitate to say its a good idea to mix stale state with new state.
<Zic> lazyPower: the US cluster is just AWS instances, no problem to respawn from scratch here :)
<Zic> (it's more the FR part, which is a composition of VMware and physical servers)
<Zic> if I can just juju delete-machine all US, then deploy a new CDK cluster to US and tied it to FR via kube-fed, it will be cool :)
<rick_h> Reminder: Juju show at 2pm EST today!
<lazyPower> Zic: thats the integration path i would propose. We can certainly work with you to test teh feature when its in alpha state to ensure it covers your needs
<lazyPower> kjackal: I'm going to cc you on this as we have a stakeholder for the feature now
<SimonKLB> hey folks! im currentinly in the process of writing a charm to support more advanced forms of configuration which is currently not possible (in a nice way) when only using the normal charm config
<SimonKLB> i would love to use subordinate charms for this but, from what i can see, those are restricted in that they are not removable
<SimonKLB> what is the exact reason for this and would it be possible to make them more flexible in the future?
<lazyPower> ping rick_h ^
<lazyPower> rick_h: i know this was a topic we've visited in the past but I do forget the reasons why they are so tightly coupled.
<kklimonda> I've had to increase timeout on lxd waitready (and lxd upstart service file) -- right now it's 600 seconds. I /believe/ that service was hitting this timeout and some containers were not starting randomly, but I'm not 100% sure (could be a placebo for all I know) - is this something that someone else have ever seen?
<lazyPower> kklimonda: not in my experience but i'm sure there's hardware factors at play there
<lazyPower> for example i tend to put my lxd machines on ssd's backed by either btrfs or zfs for fast cloning
<rick_h> lazyPower: SimonKLB it's the case of hulk smashing. We can't promise they remove and leave the state like they started. It's like hulk-smashing. It's not promised in the model tbh
<SimonKLB> rick_h: how is it different from a poorly written stop hook in a normal charm? i could see how a normal charm could leave the model in a mess as well if you dont clean everything up properly?
<SimonKLB> or what makes the subordinate more invasive in that regard?
<rick_h> SimonKLB: because that's put into a container or on a machine that when torn down goes away
<rick_h> SimonKLB: I admit it's not a perfect system. There's room for improvement. However, it's a bit tough to promise the model is good and solid in some situations and subordinates are one of those.
<SimonKLB> rick_h: are there any differences between co-locating two charms on the same machine and subordinate charms?
<rick_h> SimonKLB: right, but we strongly suggest folks don't hulk smash for the same reason
<rick_h> SimonKLB: and push using lxd containers and the like
<SimonKLB> rick_h: so right now i do `juju deploy X` and `juju deploy Y --to [machine with X]` which works fine, the reason i would like to use subordinates is that you wouldnt have to know the location of X and if you add another unit of X, Y would automatically get installed there as well
<rick_h> SimonKLB: definitely and agree that it's what they're for
<rick_h> SimonKLB: but they carry some extra though on how clean things will be if you're adding/removing them
<SimonKLB> if the only reason for not making stop available for subordinates is that it could leave a mess behind, i dont see why co-locating multiple charms on the same machine is allowed either?
<SimonKLB> or am i missing something?
<rick_h> SimonKLB: it's allowed but not recommended. Almost all bundles in the store don't do it. It's not "good practice"
<rick_h> it's like installing your application and the db on the same machine
<rick_h> sure, you want to do it for testing/etc
<rick_h> but it's not helping with best practices
<rick_h> SimonKLB: so subordinates can do it, but they're not ideal in that they don't remove cleanly and juju shows that.
<rick_h> SimonKLB: like I said, it's the history. I'm not saying it can't be made better
<rick_h> SimonKLB: basically I'm just telling you how it got to where it is.
<SimonKLB> rick_h: yea i see why it's a bad habit of co-locating stuff like that, but im sure there are going to be cases where deploying an extra machine would be unecessary, especially for "add-on charms" like this
<SimonKLB> add-on charms, that you want to be able to add _and_ remove that is
<rick_h> SimonKLB: and so we fully support it in subordinates. Please use them. We do all the time for things like the landscape client, nagios, etc.
<SimonKLB> wait, so removing subordinates is possible?
<rick_h> SimonKLB: no, you can add them and setup add-on charms.
<rick_h> SimonKLB: but if you want to remove and change that thing you need to rebuild it with a new deploy
<rick_h> SimonKLB: by all means, file a bug (there might be one) and we can look at improving things
<SimonKLB> rick_h: that would be for juju core?
<rick_h> SimonKLB: sure thing. https://launchpad.net/juju
<SimonKLB> rick_h: would it be best to propose a new type of charm-type or should i push for stop hooks in subordinates?
<SimonKLB> im worried that trying to get stop hooks in subordinates would have a lot of pushback since that could break a lot of the current setups
<rick_h> SimonKLB: improving subordinates to act like a full application sounds like a starting piont
<rick_h> SimonKLB: basically I'd focus on the pain point.
<rick_h> SimonKLB: e.g. why is the lack of removing them causing you issues
<SimonKLB> rick_h: alright, ill give it a shot! :) thanks
<rick_h> SimonKLB: np, thanks for the feedback!
<bdx> some grumbling going on at a kubernetes workshop about how their workshop doesn't work on ubuntu, but it works on windows ..... https://github.com/apprenda/kubernetes-workshop
<bdx> and osx
<bdx> what haters
<rick_h> bdx: any hint as to what's broken?
<bdx> rick_h: I'm inquiring
<bdx> rick_h: looks like some compiled "provisioning" bins
<rick_h> bdx: yes looking at their stuff its all compiled so not immediately obvious why they'd hit.
<bdx> http://imgur.com/a/awIAW
<lazyPower> SimonKLB: rick_h - i can say that during my pilot of the dex charm - i opted for snap packaging as my delivery format and being able to snap remove and have an atomic operation that just wiped it out from the machine was a pleasant experience.
<lazyPower> (hours later)
<bdx> rick_h: I've spotted some things that would cause the docker file to fail on ubuntu
<bdx> https://github.com/apprenda/kubernetes-workshop/blob/master/DockerFiles/web/Dockerfile#L6
<bdx> http://paste.ubuntu.com/24549762/
<bdx> xenial at least ... I think nginx in trusty still has an nginx conf there
<bdx> not sure if that RUN cmd failing would bork the whole dockerfile or not
<bdx> nah, the conf doesn't exist in /etc/nginx/conf.d in trusty either
<bdx> I bet there are some other small gotchas like that
<bdx> but I guess thats different then the workshop actually running on ubuntu
<SimonKLB> lazyPower: yea if there was some kind of payload i would probably just integrate it into the charm, but in the case of the charm im currently building it's more about using juju stuff such as interfaces, actions and the config
<rick_h> 20min to juju show #12!
<rick_h> https://www.youtube.com/watch?v=oJukQzROo-Q to watch
<rick_h> https://hangouts.google.com/hangouts/_/jurpmjck7ffwhpi2coqxwpl4aye to participate and get your camera/mic working
<tychicus> rick_h: thanks
<rick_h> hatch: jrwren lazyPower kwmonroe ^
<rick_h> bdx: magicaltrout as well if you're feeling chatty today ^
<rick_h> hatch: you coming today?
<bdx> that "accounts" page is awesome!
<bdx> that will be a great place to track ssh keys too
<bdx> when ssh keys become user sensitive
<zeestrat> rick_h: How many more beta/rc's are you aiming for 2.2?
<rick_h> zeestrat: I'm honestly not sure. I definitely think there's at least one more beta coming
<Merlijn_S> Damn, we have to push more of our charms, we do have a reactive non-subordinate jupyter charm, but it's not in the store for the moment..
<rick_h> Merlijn_S: doh!
<rick_h> Merlijn_S: well I might know an italian professor interested in checking it out :)
<Merlijn_S> haha, I'll contact him. It's also heavily used by my colleagues for teaching
<rick_h> Merlijn_S: yea, it seems perfectly awesome for that. I wonder if we could pull off some sort of juju/charmschool with it
<Merlijn_S> it also has an auto-generated xkcd password (to stop students from cheating ;)) maybe less relevant for charm schools :)
<rick_h> lol
<rick_h> have to love open source ops, the great features you get baked in!
<lazyPower> Merlijn_S: I have some updates for che incoming
<Merlijn_S> Awesome!
<lazyPower> is whats in tengu-team's master the latest effort or is there more i've not gotten?
<rick_h> Merlijn_S: I was going to do a blog post around this charm, if you guys push yours up I'd appreciate it so I can compare and maybe adjust the focus there a bit
<Merlijn_S> @rick_h https://jujucharms.com/u/tengu-team/jupyter-notebook/0
<rick_h> Merlijn_S: hah, that's some fast service! :)
 * lazyPower notes charm push vs lp push... the day we finally got to party in real time
<Merlijn_S> @lazyPower master is the latest, I haven't touched it in a while
<lazyPower> Merlijn_S: ack. I have s'more ideas but i'm light on time to contribute them. I will however fix the immutable config since 5.9.1 has some serious UI/UX improvements <3
 * rick_h notes Merlijn_S might not have set perms since he can't see it
<Merlijn_S> @rick_h can you see it now?
<rick_h> Merlijn_S: bingo ty much!
<Merlijn_S> @lazyPower I would really like to have the charm always install the latest, but Che is changing so fast that they break the charm quickly..
<lazyPower> well tbh it works with the nightlies
<lazyPower> but i'm not exactly using your stack anymore because everything i push to github is initially owned by you
<lazyPower> https://github.com/juju-solutions/layer-dex/commits/master
<lazyPower> all that boilerplate credit :D
<Merlijn_S> Ow, that's an issue :)
<Merlijn_S> Any idea how to fix this?
<lazyPower> The only thing i can figure is to omit the .git from that boilerplate
<lazyPower> make the end user initialize the repository
<lazyPower> that or just own all the boilerplate coming from teh che charm and enjoy having bloating GH stats
<lazyPower> either way is fine :) i'm just on a quest to really figure out how this is put together so its more useful when i'm on my chromium book
<Merlijn_S> It's been a while since I looked at it, but from what I can remember, che insists on it being a git repo. Che pulls that from github during project creation
<lazyPower> ah, that makes sense
<lazyPower> i've started initializing a blank stack and go from there
<lazyPower> the workspace snapshots seem to do a good enough job of perserving state that i'm not redoing config management everytime i spin up the container
<Merlijn_S> PS: I've been working on documentation for getting started with developing for-and-in JaaS: https://ibcnservices.github.io/tengu-docs/use/eclipse-che.html
<lazyPower> kick butt! That's a nice start
<Merlijn_S> users can start charming on JaaS without ever leaving their browser
<lazyPower> rick_h: ^
<rick_h> Merlijn_S: very cool. Will look it over.
<Merlijn_S> Would be nice if we could have a way for che to import the credentials of the model/user that deployed che
<Merlijn_S> The "controller" relationship might come in handy here
<lazyPower> now you're cookin
<lazyPower> that's what i'm talkin bout
<rick_h> Merlijn_S: heads up some docs changes will be going live hopefully tomorrow https://github.com/juju/docs/pull/1826
<rick_h> Merlijn_S: yea the representing a controller as an application will be awesome.
<Merlijn_S> @lazyPower: you were the one that talked about connecting the openvpn charm to an SDN-type thing right?
<lazyPower> yep
<Merlijn_S> We're running into an issue with the openvpn charm where it doesn't correctly push the routes to the GCE network, because each GCE VPS is in a 255.255.255.255 subnet.
<lazyPower> hmmm
<lazyPower> is it how openvpn is configuring itself? like is it hard coded to 255.255.255.0?
<Merlijn_S> So we're looking for a way to tell the VPN charm what networks are attached to the server. If we create a relationship that allows another charm to tell the vpn charm what networks it is attached to, is that something you could use to connect an SDN to the charm?
<Merlijn_S> The charm triest to figure out what networks it's connected to based on the output from the puppet `facter` tool
<Merlijn_S> but that fails on GCE because each GCE VPS thinks it's the only server connected to that network. GCE does some funky trickery with the default gateway or smth to make it work
<lazyPower> Merlijn_S: i think so. I can try to strawman something between openvpn and flannel when i'm not up to my eyeballs in kubernetes features
<lazyPower> maybe a friday lab
<lazyPower> the basic bit would be adding the route to openvpn incoming from flannel, and then making sure that route is connected and its subnet is accounted for
<lazyPower> the rest should be automagic
<Merlijn_S> Hm, so would you need anything from the openvpn side? What would that relationship look like?
<lazyPower> it should only need to pass its network configuration over
<lazyPower> such as cidr
<lazyPower> the rest we can probe from route
<kwmonroe> hey petevg, wadda you make of this?  http://paste.ubuntu.com/24550557/ -- i def have bt-0.12.0 on the system and verified this commit is in place:  https://github.com/juju-solutions/bundletester/commit/96f323abd81c537b99612a8fab3cf2fcf41170f5
<petevg> kwmonroe: That's bad.
<petevg> kwmonroe: that var should just default to a falsey value (that's the default behavior of the argparser lib)
<petevg> ... I have no idea why it wouldn't be doing so.
<petevg> kwmonroe: are you calling bundletester from a cli, or are you invoking it in some other way?
<kwmonroe> petevg: it's cwr that's calling bt, sorry i didn't show the invocation before:  http://paste.ubuntu.com/24550619/
<petevg> kmwonroe: that's the problem. cloud weather report runs the tester class of bundletester directly, but it doesn't bother to setup the args.
<petevg> kwmonroe: two solutions:
<petevg> 1) Make cloud weather report exercise bundletester's arg parser (not great).
<petevg> 2) Pass in "no-matrix" explicitly when invoking bundletester from cloud weather report.
<petevg> ... or "no_matrix". I think that the dash has been converted to an underscore by the time we invoke the tester.
<kwmonroe> ack petevg, i'll give option 2 a whirl shortly
<petevg> Cool. thx, kwmonroe.
<Merlijn_S> @rick_h I have some more feedback on the getting started page. Where can I put that?
<rick_h> Merlijn_S: shoot me an email and I'll work it into next doc updates I've got going on.
<rick_h> Merlijn_S: or pr or pastebin or whatever works for you
<Merlijn_S> aight, I'll send you an email
<Budgie^Smore> wow I almost fell asleep watching a docker intro video!
#juju 2017-05-11
<ryebot> Is there a way to customize hostnames when launching machines with juju? Or are we stuck with the juju-... hostnames?
<bdx> ryebot ... I'm not sure ... I think its a provider thing ...
<bdx> like ... have you ever tried to change your instances host name on aws?
<ryebot> I have not
<bdx> (I haven't either lol)
<ryebot> :D
<ryebot> alright, cool, I'll look in that direction; thanks bdx
<bdx> np
<lazyPower> you can change it post deployment without any reprocussions, but it does default to the juju- hostname schema.
<lazyPower> if we ever start doing computed DNS that may change.
<lazyPower> but that's a future ryebot problem, not a today ryebot problem.
<ryebot> lazyPower: ah, excellent, I'll give it a shot, thanks
<lazyPower> actually rye, i think that may not be 100% true. I'm pretty sure we run dnsmasq on lxd
<lazyPower> that'll break hostname resolveability
<lazyPower> which matters if you care about specifying hostnames as the remote
<lazyPower> eg: in the context of k8s nodes you'll no longer be able to kubectl exec or kubectl logs
<kklimonda> can juju 2 authenticate against Keystone V2 API?
<erik_lonroth3> lazyPower: I've been looking at that example you sent me and its the one I started with - without success. Its perhaps me being stuck in some wrong mental view of how things work with states or something. But I can't so far get my head around how things work. The example http://interface-pgsql.readthedocs.io/en/stable/requires.html#example-usage for example doesn't mention anything about how to include this in the "metadata.yaml
<erik_lonroth3> " or how the "admin-pass" variables are to be used etc. I guess its somehow implicit or perhaps I'm also not reading the right things? Also, I've been trying to read and look how others have made this things and still don't really get it to work with states. I feel that using "hooks" is straight foreward and by using hooks, I can likely get further, but I need to work alot more to get a better understanding of the reactive frame
<erik_lonroth3> work.
<erik_lonroth3> I feel a bit worried about this since I also think its very important for my friends at work to be able to "understand" this concept. Most of them are not used to hard-core programming and the steep learning curve here worries me alot. If it takes weeks and months to get practical about juju charming, its likely not going to take off at work either. Does anyone provide education on this matter today?
<kklimonda> right now after setting endpoint: http://[ip]:5000/v2.0/ it's trying to access V3 path for tokens: http://[ip]:5000/v2.0/auth/tokens
<erik_lonroth3> lazyPower: I will try to summarize my technical problem later. I will try some more today and see if I manage to get through. I'm likely also  just doing something wrong.
<erik_lonroth3> kjackal: I looked also at your example interface and I can "sort of" understand. However, the pattern of implementation used in that example is new to me and also I so far have not been touching with "interfaces" yet. Another hurdle I guess...
<kjackal> erik_lonroth3: Nice to hear you are moving forward with this
<kjackal> erik_lonroth3: If you have your code public somewhere I would be pleased to take a look and give hints on any problems you may have
<kjackal> erik_lonroth3: I just read what you wrote above, do not be afraid about the learning curve. Do not be scared with the docs. You are probably over the hard part (understanding hooks)
<erik_lonroth3> Thanx!
<kklimonda> can I disable lxcfs for containers spawned by Juju, or is this going to lead to even more sadness?
<erik_lonroth3> I've come to the understanding that you normally mix  "hooks and states" only in "interfaces" or "layers" ?
<kjackal> erik_lonroth3: only in interfaces
<kjackal> erik_lonroth3: regarding the metadata.yaml entries, you will need to specify if you require or provide the interface you want to use and you will also need to add the 'interface:foo' in your layer.yaml
<erik_lonroth3> OK, because I've looked at https://api.jujucharms.com/charmstore/v5/trusty/python-django-19/archive/hooks/hooks.py to try to understand how "other charms" have used the postgresql charm and that "python-django" charm does mainly use hooks to use the postgre-sql. Then I've been looking at https://github.com/johnsca/juju-relation-mysql/ (an interface) which I don't yet understand.
<kjackal> erik_lonroth3: You are on a wrong path :)
<erik_lonroth3> I probably am =D
<kjackal> erik_lonroth3: ok, lets fix this :)
<kjackal> let me grab some example code
<erik_lonroth3> My intention is to be able to create a simple charm using a postgre-sql database.
<erik_lonroth3> and to "join"them with a relation.
<erik_lonroth3> I can commit my test to github so you can se what I've been doing so far
<kjackal> erik_lonroth3: yes please do that
<kjackal> erik_lonroth3: and let me know where the repo is
<erik_lonroth3> Setting it up as we speak
<kjackal> thanks
<kjackal> erik_lonroth3: btw stub is the maintainer of postgresql so if we hit any wall we will call for his help :)
<erik_lonroth3> https://github.com/erik78se/pgtest
<erik_lonroth3> Mind that what I just commited is not working. Let me fix it and lett you know when you can pull
<erik_lonroth3> There, you can pull now
<erik_lonroth3> What I currently was failing on, was/is that my charm never see the state "db.connected'. https://github.com/erik78se/pgtest/blob/master/reactive/pgtest.py I believe thats because its not any "interface" acctually setting that state - so. I'm left with acting on "hooks" instead.
<kjackal> erik_lonroth3: gitve me 15 minutes
<erik_lonroth3> No worries, I'm going to try to clone the mysql interface and see if I can replicate it to work the way it does for mysql
<erik_lonroth3> Oh, I managed to get "db.connected" to execute once I implemented the interface:pgqsl by simply cloning the mysql and replacing all Mysql stuff with postgresql. However, I'm sure I'm doing this very akwardish
<kjackal> erik_lonroth3: nope, please give me 5 minutes :)
<erik_lonroth3> Oh, and after breaking through that wall . I found this : https://git.launchpad.net/interface-pgsql
<erik_lonroth3> ... so now I'm rebuilding the charm to test again.
<erik_lonroth3> (after having cloned this repo)
<kjackal> erik_lonroth3: Have a look here: https://github.com/ktsakalozos/pgtest/blob/master/reactive/pgtest.py
<kjackal> first of all NEVER mix reactive and hooks
<kjackal> remove all the @hook from your reactive part
<erik_lonroth3> Cool. I understand the code.
<erik_lonroth3> But so far, I nver got the part "db.connected" to execute.
<kjackal> doing a deployment right now to see if it works
<erik_lonroth3> Great! I believe my problem is that I need the "interface" code added also to my charm.
<stub> erik_lonroth3: The example with hookenv.config()['admin-pass'] is exactly that - an example. That one is just a handler that is retrieving a password from somewhere and setting a reactive state.
<stub> erik_lonroth3: You have no handler setting the admin-pass state, but you are using it to guard the pgtest.connected handler and it never gets run
<stub> oh, its guarding the handler with pgtest.available. So that would be a different issue to the pgtest.connected guarted handler being called.
<erik_lonroth3> Its OK. I don't care about that admin-pass thing.
<erik_lonroth3> I could have removed that part, but I stilll wont see the "db.connect" code beng run.
<stub> Do you have a relation named 'db' with interface 'pgsql' defined in your metadata.yaml ?
<erik_lonroth3> I think this is that part where my knowledge breaks
<stub> requires:
<stub>   db:
<stub>     interface: pgsql
<erik_lonroth3> Yes I do.
<stub> And it is called db ? Because that name needs to match the state name 'db.connected'
<erik_lonroth3> This is the part where I'm really confused in how these names repate to interfaces or just some user-defined name/strings ?
<erik_lonroth3> Because in the documentation, I've read that these "states" are really only just that - some user-defined names.
<erik_lonroth3> So, how would I know that @when("<db>.<xxx>.<yyy>" ) is supposed to be related to a interface, rather than to just some random dead-code or acctually something that is being enforced by the framework ?
<kjackal> stub: can you tell me if I am using the interface correctly here: https://github.com/ktsakalozos/pgtest/blob/master/reactive/pgtest.py#L29
<kjackal> stub: i get "Got connection string None"
<stub> In the example above, the relation name is 'db' and you get to choose that. The interface is 'pgsql', which declares the type of relation and needs to match the interface in the charm you are connecting to. It is also used by charms.reactive to discover and install an implementation of that protocol so you have less work to do.
<stub> charms.reactive uses the name to set states for that particular relation. So when you join the 'db' relation, the 'db.foo' states get set and it isn't confused with any other relations you have declared.
<stub> kjackal: .connected is when the relation is connected. You won't have a connection string until .available
<kjackal> thanks stub
<erik_lonroth3> In the example it states that "db.master.available" is when I acctually seem to be able to access configuration items...
<stub> Its confusing because we are crossing three bounaries here. Relations are a juju thing, and is documented there. Then we go through charms.reactive, which defines how the relation states work. Then the interface, which defines what the relation states are, when they get set and how it can be used.
<stub> But I think there are some all-in docs now in the main Juju docs? Probably nothing PostgreSQL specific though.
<erik_lonroth3> stub: I agree and can recognize the situation as we are interscting alot of areas within juju. This is also part of my worries, since this kind of maneuver is very common for "sysadmins" who likely are target for juju-related things. I'm struggeling with all of this and I can immagine that others are too. Its very easy to "give up".
<erik_lonroth3> Building "services/applications" with juju should ideally be easy (given the powerful framework). But the number of hurdles, complexities are dauting. Also consider that sysadmins normally are not hardcore programmers. These "concepts" with interfaces, relations etc. are really not trivial things to grasp.
<erik_lonroth3> Having a few "tutorials" that takes one though some common tasks within juju would be great and in the case of connecting an application to a (mysql,postgresql,oracle,mongodb,...)-database should be really well covered... if you ask me.database
<erik_lonroth3> Also - thank you alot for helping me out so far... I wouldn't have made it so far without you help...
<erik_lonroth3> ... if I only could get this pgtest to work today. I've been fighting with it for a few days not.
<erik_lonroth3> now*
<stub> There have been things like that in the past, but they tend to get lost in the sea of blog posts rather than into the official docs
<stub> (I could have sworn there was at least one example in the main docs, but not having success finding it)
<erik_lonroth3> stub: I understand. I do think the documentation site would be good to place a few "best practices" or "common tasks" tutorials.
<kjackal> erik_lonroth3: here is the PR with how to get pgtest running: https://github.com/erik78se/pgtest/pull/1
<erik_lonroth3> For example. I'm about to try package a system we have built in my startup. We have some code-base which involves setting up database, connecting our software to it and get going with juju. However, its taken me almost 3 weeks now to get to where I am. I do think this is the right path for us, worth the time, but I'm sure there are alot of other companies/persons that do not come to the same conclusion. Getting to apoint when yo
<erik_lonroth3> u can deploy your system on juju really have to be alot easier.
<erik_lonroth3> kjackal: Thanx! I'll merge
<kjackal> erik_lonroth3: indeed the juju has its complexities. The abstractions imposed are there to make sure the approach you are taking in setting up your cluster can scale
<magicaltrout> just from the peanut gallery, for us part timers getting the hooks reacting correctly in a new charm can be an absolute ballache, of that there is no doubt. Also I come from a Java background so we have IDEs and validation and stuff that tells us when we're being stupid. Clearly with relations and states its a lot harder, but I do dream of that day in Juju land
<magicaltrout> on the flip side, compared to non reactive charms, this shit is a breeze
<erik_lonroth3> kjackal: I will test and I saw the changes you did and understand them.
<erik_lonroth3> Would it make sense to add url:s that points to where the interfaces are kept that makes the charm work ?
<kjackal> erik_lonroth3: so honestly some toy examples indeed seem overengineered. But if you have a big infrastructure with many services juju will realy help. I am not aware of any other framework that allowes you to handle the complexity of large infrastructures so elegantly
<kjackal> magicaltrout a "part-timer"... yeah right.... You heard it here at #juju first!
<kjackal> erik_lonroth3: two points to remember 1. Never mix hooks and reactive 2. What you use in the metadata.yaml to reference an interface will be used in the states that interface sets
<kjackal> erik_lonroth3: for exmample we used "db" to ref pgsql interface so the states this interface set are "db.<whatever>"
<erik_lonroth3> I'm not arguing juju isn't good. Really the contrary. I'm arguing that having a few paths that assists you into acctually producing "common task" juju charms will make it easier to grow a community aroud it also. I'm happy to help here.
<stub> erik_lonroth3: I think we actually want to replace interface:pgsql with a URL to a repo, because people want to pin versions, test forks etc.
<stub> erik_lonroth3: (but I don't think that has moved beyond the vague notion stage yet)
<erik_lonroth3> stub: I think thats really important. Its critical to be able to know how to reproduce a charm.
<kjackal> erik_lonroth3: would you be able to tell us your experience in this list: juju@lists.ubuntu.com Your feedback is much appreciated and deserves more visibility!
<erik_lonroth3> kjackal: I would love to at some stage. I do however need to get to a point where I'm experienced enough to differentiate between my "novelty-beginner-experience" and "inherent problems with juju".
<erik_lonroth3> I don't want to bloat your input when I'm still so new to this.
<anrah> erik_lonroth3: I can comfort you as I started with 0 knowledge of Juju last October and I was as confused as you are now. But after multiple trials and errors things just slowly started to make sense
<kjackal> erik_lonroth3: I think it is right the oposite. We know what to do for the experienced users. We need to understand what we are doing wrong with the begginers
<anrah> Our team has now developed for our internal use multiple charms and I like the simplicity of reactive framework and how that eases the deployment
<erik_lonroth3> anrah: Thanx. But wouldn't you also agree from your opinion that its not so good that it takes well over a year to get to a point where you can do more advanced stuff?
<erik_lonroth3> anrah: I like to hear that you are saying so.
<erik_lonroth3> about your team.
<anrah> erik_lonroth3: well yes, the learning curve was quite steep
<erik_lonroth3> kjackal: testing your stuff now.
<anrah> We've refactored our charms couple times after we got something working.. First it was just bash that was run through Juju hooks
<anrah> And after getting comfortable with reactive we rebuilt everything from scratch using reactive only
<erik_lonroth3> anrah: sonds like a common path =)
<anrah> Yes :) And well I don't know whether half a year is long period to learn something
<anrah> It took also half a year of me to learn how to write chef cookbooks in a decent way
<erik_lonroth3> anrah: Perhaps its me wanting too much. =)
<anrah> But I can comfort you that after you get your head around with states and interfaces things get lot easier and charming is quite straight-forward
<erik_lonroth3> kjackal: Thanx, it works. After my lunch, I'll try to wrap up some of my experiences and maybe provide an email to the list.
<kjackal> thanks erik_lonroth3
<lazyPower> magicaltrout: well you do know that galgalesh is working on the whole IDE part... so your dream is coming together one piece at a time
<lazyPower> if there were some kind of clairvoyance.py we could tap into to lint your intent, we would totally be able to deliver your entire dream ;)
<magicaltrout> true that
<CoderEurope> Kubernetes made it to HN https://hackernoon.com/what-is-kubernetes-and-why-should-you-care-f4c8da25b143
<lazyPower> Well thats an interesting way to cross promote
<lazyPower> I wish it had more substance though, it seems like its missing a lot of detail
<tychicus> probably a really low priority item but it looks like the juju charm store counts tags rather than charms when you search for a charm
<tychicus> https://jujucharms.com/u/cloudbaseit/#charms
<tychicus> charm count 17, but only 10 charms
<tychicus> there are 17 tags though
<lazyPower> magicaltrout: https://twitter.com/lazypower/status/862699798654275586
<magicaltrout> #lol
<magicaltrout> indeed lazyPower
<magicaltrout> we use it to stalk you!
<lazyPower> even better
<rick_h> NOTICE with usso having some issues logging into JAAS and such is going to have issues. Apologies to those that choose now to "I'll just logout and back in"
* rick_h changed the topic of #juju to: NOTE: USSO is currently out causing login issues to JAAS | Juju as a Service - Beta now available at https://jujucharms.com/beta | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms
* rick_h changed the topic of #juju to: Juju as a Service - Beta now available at https://jujucharms.com/beta | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms
<lazyPower> as such anyone attempting to build layers hosted out of launchpad will also have similar issues assembling charms.
<lazyPower> stub: FYI - during the outage i repointed layer-snap to point @ your github mirror until its resolved. I'll revert to launchpad once we get the all-clear signal from IS
<erik_lonroth3> kjackal: I wrote that mail you asked for to the juju mailing list.
<lazyPower> erik_lonroth: that was a solid and well-detailed write up. Thank you for sharing
<zeestrat> erik_lonroth: Great write up. We've been deploying Juju stuff for a year and now more into developing/fixing charms and we feel the same. Major need for better docs, tutorials and more opinionated guidelines/best practices
<rick_h> erik_lonroth: zeestrat +1 on the great feedback. One note, I'm looking to pull together juju material for https://tutorials.ubuntu.com/ if anyone's interested I'm happy to help put tutorials together for things.
<arosales>  Hello, is there a arch doc that describes communication between Juju and MAAS to provision services?
 * arosales understand its communications via the MAAS API, but didn't know if there was an arch doc out there that described that a bit better
<Catbus> stokachu hi
<Catbus> Conjure-up kibernetes returns unable to locate package kibernetes. What may go wrong?
<Catbus> Snaps is the latest.
<Catbus> Snapd
<Catbus> Snapd 2.24.1, conjure-up 2.1.5
<arosales> rick_h: not sure if you would know of any doc that exists
<hml> catbus: try âconjure-up kubernetesâ   :-)
 * arosales poking around https://github.com/juju/juju/tree/develop/provider/maas atm
<Catbus> Tried that, it was a typo in my irc msg
<Catbus> It was a copy and paste from the doc.
<Catbus> Conjure-up openstack works. But not kuberbetes.
<stokachu> Catbus: hey!
<Catbus> Hey
<stokachu> so what's happening?
<Catbus> Conjure-up kubernetes returns unable o locate package kubernetes
<Catbus> Conjure-up openstack works.
<stokachu> strange
<stokachu> this on 16.04?
<Catbus> Me is on the phone, pardon my typos here
<stokachu> np
<stokachu> Catbus: are you typing that or is someone else?
<stokachu> im bringing up a 16.04 system now
<rick_h> arosales: hmm, so there's the https://github.com/juju/gomaasapi which was basically built for the provider and I there was a new provider checklist spreadsheet that lists calls/etc but I can't seem to find that doc now
<Catbus> Helping someone else at Marcos hands on session at openstack summit. Only one person on the room has this problem. They are using VM on aws.
<stokachu> that is crazy
<stokachu> i just booted a aws vm and tried it
<stokachu> are they sure they are on correct Ubuntu?
<Catbus> Aws credentials are prepare by Marco.
<stokachu> i dunno :(
<stokachu> it works for me
<stokachu> and obviously everyone else
<stokachu> so it's gotta be something with that vm
<Catbus> Yeah
<stokachu> conjure-up doesn't even have an error message like 'unable to locate package kubernetes'
<rick_h> arosales: tim drove most of that maybe he's got something personally that'll cover that better.
<Catbus> Wow, ok.
<stokachu> Catbus: if they just run conjure-up
<stokachu> can they select kubernetes from the list?
<arosales> rick_h: thanks I'll ping thumper
<Catbus> Tried that, but the menu doesn't appear.
<stokachu> uh
<stokachu> im out of ideas
<Catbus> It  complains a spell is required to run.
<stokachu> other than kill the vm and try again
<stokachu> Catbus: what does dpkg -l |grep conjure-up show
<Catbus> Yeah, I just gave him another VM.
<stokachu> Catbus: i bet he apt install conjure-up
<stokachu> he/she
<Catbus> No, he used snap
<stokachu> Catbus: you sure? i have a feeling they have an older conjure-up installed
<stokachu> the old old version of conjure-up pre-snap used to look for deb packages in the form of `openstack`
<stokachu> so conjure-up openstack would apt-get install openstack which was a metapackage we used
<stokachu> there is no deb package named kubernetes
<stokachu> that's why they are hitting the error
<Catbus> It works on the new VM. But your explanation makes sense.
<Catbus> We just moved on, I don't want to verify so he can focus on the session.
<Catbus> Thanks.
<Catbus> Again.
<stokachu> np
#juju 2017-05-12
<erik_lonroth3> Good moring jujuers
<kjackal> Good morning Juju world!
<kjackal> thank you for taking the time to write this email erik_lonroth3
<Zic> hi here, iirc, the etcd charm nos do daily backup on its own, do you know where?
<Zic> s/nos/now/
<lazyPower> Zic: Ok clue me in as to where you got that info
<lazyPower> because thats news to me :)
<Zic> sounds like I'm wrong here xD
<Zic> oh I remembered: etcd do an automatical backup when upgrading from .deb to snap, but there is no "daily" ones, I just dreamed about
<lazyPower> Zic: right, you can also snapshot using the action... which you could put on a cron job to run the action, parse the action output and fetch teh snapshot to do dailies
<lazyPower> the primitives are all there to do it... so there's nothing really stopping you from doing that as a jenkins job
<Zic> yup, it will be sexier than my old cron
<Zic> which looks like this today: 0 0 * * * root cd /data/etcd-backup && etcdctl backup -data-dir=/var/lib/etcd/default -backup-dir=etcd-backup_$(date -I) && tar zcf etcd-backup_$(date -I).tar.gz etcd-backup_$(date -I) && rm -rf etcd-backup_$(date -I)
<Zic> (I got to update this one with the new path of "etcdctl" as "/snap/bin/etcdctl")
<lazyPower> :) I have an open todo to change the snapshot format to support the etcdctl backup command
<lazyPower> right now it just tarballs up the data directory, when you reinit the cluster from the snapshot it takes care of cleaning up any dirty state that may be left around in the db
 * Zic add to his TODO "Test to restore and etcd backup in case of disaster"
<Zic> never did it, and as you all know, you can't call something a "backup" since you don't have test it to restore
<Zic> :>
<Zic> lazyPower: what is the complete line to run the action ? I have a missing parameter :o
<lazyPower> Zic: juju actions etcd --format=yaml --schema
<Zic> thx
<Zic> lazyPower: oh, I forget to tell you that the main CDK cluster (the big one) is now publicly accessible, the Android & iOS app has been released by our customer yesterday (as beta) on mobile stores
<lazyPower> \o/
<lazyPower> we made it
<Zic> :crossfinger:
<lazyPower> thats awesome that you're in that new milestone of the journey
<Zic> lazyPower: hmm, I have a strange thing with juju run-action etcd/0 snapshot
<Zic> http://paste.ubuntu.com/24560810/
<Zic> it show "exited status 1" in show-action-status
<Zic> see above for juju debug-log
<lazyPower> hmm
<lazyPower> ok, can you bug that for me Zic and I'll take a deeper look? i'm not certain off the top of my head
<Zic> "open /var/snap/etcd/current/member/snap: no such file or directory" <= the correct path is /var/snap/etcd/current/etcd2.etcd/member/snap
<lazyPower> ah
<lazyPower> the migration path schenanigans
<lazyPower> I -completely- forgot about that
<lazyPower> good catch Zic, that should be a simple fix, i just need to do a quick path check for unit_name as teh first data path in the backup action before presuming its the default location.
<Zic> do you want that I fill a bug in the bundle-canonical-kubernetes@GitHub?
<lazyPower> certainly. i can cross post to the layer-etcd repo and get both when i push a fix later
<Zic> lazyPower: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/285
<lazyPower> Zic: thanks for filing that and sorry about the bug D:  I'll make sure that a fix for that makes its way to the layer today
<Zic> no problem :) was just searching if we always need our home ugly (= as behaviour can change between version) cron or if I can switch to something more standard handled by Juju
<Zic> we skip a few backup days of etcd the time I saw that the old cron does not work anymore since we siwched to snap
<Zic> +w
<lazyPower> Zic: yeah, i'd like to keep the admin interface clean for you as well
<lazyPower> Zic: feel free to file any usability bugs that you feel would make your life easier
<rahworkx> Hello all, how can I specify apt cache when using conjur-up
<lazyPower> rahworkx: as far as i know you would have to add the model, and set it on the model-config, then use conjure-up in headless mode
<lazyPower> cory_fu: does that sound correct?
<lazyPower> ooo wait, what about model-defaults?
<cory_fu> stokachu: ^
<stokachu> rahworkx: conjure-up -h
<cory_fu> lazyPower: Yeah, you could probably manually bootstrap a controller, set some model defaults, and then select that controller with conjure-up
<stokachu> apt-proxy and apt-https-proxy are available
<cory_fu> Oh, look at that
<cory_fu> :)
<rahworkx> ok thanks will take a look.
<stokachu> rahworkx: thanks, feel free to ping in here if you need help
<rahworkx> stokachu: thanks will do.
<Budgie^Smore> lazyPower want to see the case design idea I have for a cluster in a box?
<Budgie^Smore> https://goo.gl/photos/V8UxiobqgNA6Xtn39
<bdx> Budgie^Smore: want to see mine?
<bdx> http://imgur.com/a/BYHPG
<bdx> http://imgur.com/a/DpsrW
<bdx> http://imgur.com/a/GDpyO
<bdx> she has been through many stages
<bdx> http://imgur.com/a/SU1vd
<bdx> http://imgur.com/a/oUQEU
<bdx> http://imgur.com/a/fYeWV
<Budgie^Smore> oh nice a nvidia tesla!... I have been meaning to build a desk case for my main workstation and go with liquid cooling... the box in that link is for a 5 node mini itx with a 16 port switch
<bdx> oh sick
<Budgie^Smore> was thinking individual aio liquid cooled cpu coolers for it
<Budgie^Smore> at least for the "worker" nodes
<jrwren> that is a lot of GPU power.
<Budgie^Smore> well it would only be the onboad GPUs... not really looking at GPU power as I didn't design in space for a PCIe card
<Budgie^Smore> oh the tesla, yeah that is a nice card :)
<bdx> I rip the resistors off the gtx cards and turn them into grid and teslas
<bdx> super simple
<Budgie^Smore> did you get the case custom made?, just looking at the drive bay layout
<bdx> yeah
<bdx> unfortunately danger den closed their doors a few months after I ordered that
<Budgie^Smore> yeah I have heard of them :-/
<Budgie^Smore> I would really like to figure out how to get customer boards built so I could basically build a midplane with connectors for multiple systemboards, etc. and make the unit a lot smaller
<bdx> Budgie^Smore: have you considered just doing a microblade enclosure?
<bdx> in a mini rack
<bdx> http://www.wiredzone.com/startech-racks-kvm-chassis-power-racks-and-cabinets-enclosure-cabinets-2636cabinet-30956242
<lazyPower> wow Budgie^Smore nice subwoofer box! "Thats my computer...." Nice computer! ;D
<lazyPower> i tease, this looks neat
<lazyPower> bdx: thats a nice lookin rig too
<lazyPower> Budgie^Smore: whats budget on that box build looking like?
<bdx> lazyPower: thx
<Budgie^Smore> yeah just do you want to spend 1k on a glorified case? that is also massive in comparison... my design is basically 22.25" x 16.5" x 12"
<Budgie^Smore> lazyPower for the parts you are talking 5 x itx board (recommend one with ipmi like the asrock on at $210 each) but you could use a small speced board for the maas node
<shann_> Hi, juju purpose endpoint for charms inside hypervisor ? i try find documentation for subject
<Budgie^Smore> the PSUs I found that are a nice form factor are $30 each
<lazyPower> shann_: I'm not sure i understood the question. Are you looking for the network endpoint of the controller node?
<Budgie^Smore> if you want liquid cooled it is another $70 / node and the case can handle 4 of those / 2 layers, but easily use some 120mm fans and blower cpu cools and bring that down a bit
<lazyPower> yeah man, looks like a solid layout from my perspective
<Budgie^Smore> oh and about another $80 for a 16 port managed switch
<Budgie^Smore> just haven't figured out the cost of the case
<shann_> lazyPower, i think mount lab's with Juju, serve apps, but i think not use couple of public_ip:port, i think possibility to use endpoint proxy to redirect traffic on app
<Budgie^Smore> oh and I have designed it in a way that you can add more levels to increase the cluster size
<bdx> Budgie^Smore: I like man ... super cool
<lazyPower> ah we dont expose anything like that in juju. You can add users to the controller, and share the juju-gui url to your lab students. Then they can in turn manipulate and deploy/destroy applications in their model, using their individual apps public ip:port combination
<lazyPower> shann_: would that satisfy the requirement?
<lazyPower> at least, we dont expsoe anything like that if i'm understanding correctly.
<lazyPower> allow me to be clear on that. i'm still a little confused as to what you're asking for
<shann_> i found this, https://github.com/vtolstov/charm-haproxy, if i understood, it's define single endpoint.
<lazyPower> shann_: ah yes, you can certainly use haproxy to reverse proxy into applications in a model
<shann_> yes infact, but this configuration it's correctly usage with juju, or juju has own method implemented ?
<bdx> shann_: possibly `juju deploy haproxy` is what you want
<shann_> example haproxy can serve several apps relations ? ex haproxy => first_app, haproxy => second_app, ...., i try to understand archi before mount demo on my computer.
<shann_> but i think better is test ^^
<Budgie^Smore> bac the idea would be to do the design work and then try and crowd source a few purchases to bring the individual cost down
<bdx> shann_: yeah it can do that ... but you have to write the code for the other side of the relation that connects to haproxy to correctly pass the information needed to haproxy charm to make it do what you want
<bdx> shann_: so you can connect haproxy to a single application and it will automatically do what you want
<bdx> reverse proxy to that app
<bdx> but it doesn't know what to do when you connect subsequent applications
<shann_> bdx, yes infact seem work out of box for haproxy linked app. It's possibly wrong way for my reflexion.
<shann_> i try to execute juju bootstrap localhost controller, but blocking with "Waiting for address" :(
<bdx> shann_: do you have lxd installed and working? (does `lxc launch ubuntu:16.04 u1` work for you?)
<shann_> bdx, yes u1 launched but not have ip :(
<shann_> lxd installed, bridge lxdbr0 seem up, with ip defined with dpkg-reconfigure -p medium lxd
<shann_> no missing deps (bridge-utils, dhcp,.. ?)
<bdx> shann_: `lxc delete u1 --force`
<bdx> then
<bdx> sudo lxd init
<bdx> you might need to remove the image too
<bdx> lxc image delete juju/xenial/amd64
<bdx> shann_: sudo service lxd-bridge restart; sudo service lxd restart
<shann_> yes infact, i remove image, also i restart lxd.socket, seem "lxd init" warning them still activate
<shann_> wait 5/10mns with my little connexion
<shann_> 400ko/s :'(
<shann_> bdx, ok image download, but continue to blocked at "waiting for address :("
<bdx> hmmm
<bdx> shann_: will you paste the output of this command `cat /etc/default/lxd-bridge | pastebinit`
<shann_> humm, in log i have "invalid pid for SIGHLD. Received pid yyy expected pid xxx" (for juju-<random_id>Ã 
<shann_> humm, in log i have "invalid pid for SIGHLD. Received pid yyy expected pid xxx" (for juju-<random_id>Ã 
<shann_> paste.ubuntu.com/24563015
<bdx> shann_: looks good to me
<bdx> hmmm
<shann_> bdx, lxdbr0 bridge need matched with nic ?
<shann_> brctl show, lxdbr0 interface <nothin>
<shann_> i have enp0s... and wlp0s3 for wireless
<bdx> shann_: it shouldn't be bridged to any interface I don't thing
<bdx> can anyone give me a quick run down on deploying windows with juju on aws?
<bdx> is that a thing?
<Budgie^Smore> lazyPower think you will appreciate the color now ;)
#juju 2017-05-13
<godc> is there a way to configure juju to execute some script after provisioning a machine?
<marcoceppi> godc: there is a convention in charms that allows you to pre-exec before anything in the charm runs. What are you trying to achieve?
<bdx> what are the constituents for deploying Windows with Juju?
<bdx> like, can it be done on any cloud provider?
<bdx> or only maas
<godc> marcoceppi: currently the proxy settings are not written to /etc/environment and the snapd service fails to install the kubernetes components, as it cannot reach the external servers
<godc> right now i can work around that by executing a script with juju run that copies the proxy settings to /etc/env, but i have to execute it before each worker scaling, which can be a bit annoying (and error prone))
#juju 2018-05-07
<veebers> kelvinliu, babbageclunk: re: add-k8s command: it requires a kubernetes config, at the moment that's done by deploying a cluster and grabbing it off that. That would point that to add-k8s you need a cluster deployed, which would mean you need a model thus a bootstrapped controller. Does that sound right kelvinliu?
<veebers> kelvinliu: or is the k8s config a requirement that can be satisfied outside of juju?
<veebers> and really the req is just that config, regardless of controller/model exisiting Or is the content of the config dependant on the cluster being deployed using juju
<kelvinliu> veebers, I also mentioned this in the email. In my understanding, we should be able to add cloud by selecting the cluster context/credentials from the `.kube/config` file, so it doesnot matter if the cluster was created by juju or not
<veebers> kelvinliu: ok, so seems you shouldn't need an active model nor a bootstrapped controller, just a valid kubernetes config to add-k8s
<kelvinliu> veebers, so we probably consider to replace the model name with the cluster name
<veebers> kelvinliu: where is that change needed?
<kelvinliu> veebers, but we might need the name at least coz the endpoint will be uniq per cluster
<kelvinliu> veebers, one cluster one cloud
<kelvinliu> veebers, I think this need to be discussed
<kelvinliu> veebers, ah, if we decide the use the cluster name as the cloud name, then `juju add-k8s <name>`, so just one arg
<veebers> kelvinliu: ok, agreed some discussion/clarification needed. I'll hold off actioning that bug then :-)
<kelvinliu> veebers, sounds good, it actually rely on #1768837.
<mup> Bug #1768837: add-k8s should be more flexible in loading config <caas> <k8s> <juju:Triaged by kelvin.liu> <https://launchpad.net/bugs/1768837>
<veebers> kelvinliu: are you looking at https://bugs.launchpad.net/juju/+bug/1768845 or should I take a look? (seeing as that other bug needs further discussion :-))
<mup> Bug #1768845: add-k8s incorrectly reports "cloud already exists" <add-cloud> <add-k8s> <caas> <k8s> <remove-cloud> <juju:Triaged by kelvin.liu> <https://launchpad.net/bugs/1768845>
<kelvinliu> veebers, I am not looking on this yet.
<veebers> kelvinliu: Cool, you mind if I have a look? I suspect it needs less k8s context than the 3rd bug there
<kelvinliu> veebers, u can take a look on this if you'd like to
<veebers> kelvinliu: sweet, if it's too hard I'll hand it back ;-)
<kelvinliu> veebers, ah, haha
<veebers> kelvinliu: re: your email, would you mind updating the bug (https://bugs.launchpad.net/juju/+bug/1768845) with it's contents? That way there is pubic record of it
<mup> Bug #1768845: add-k8s incorrectly reports "cloud already exists" <add-cloud> <add-k8s> <caas> <k8s> <remove-cloud> <juju:Triaged by veebers> <https://launchpad.net/bugs/1768845>
<kelvinliu> veebers, this card is more related with remove-cloud(clean up clearly) for one cloud but not directly related with multi cloud, i think
<veebers> kelvinliu: indeed, seems perhaps add-k8s is adding stuff that remove-cloud isn't removing. I'll be diving in shortly
<kelvinliu> yeah, we can add the context to the other relatd cards later after we are all clear about the final solution for this.
<veebers> kelvinliu: I take it I need an actual cluster deploy to add-k8s or can I fake it with fake contents in the config? A quick look at the code, it doesn't seem to validate the data or try reach out to anything
<veebers> kelvinliu: would you have an example config I could use in my testing (just need to add-k8s)
<vino> babbageclunk: the issue is fixed by just making use of my WriteSystemdAgent() which i refactored for updateseries.
<vino> its simple.
<vino> no need to go thru complete Installation process
<babbageclunk> oh, nice!
<vino> yea.
<vino> however, i do see some issues if the I Fix the other issue in the way i swap the PerfomrUpgrade steps..
<vino> it can be a problem.
<vino> u r correct.
<kelvinliu> veebers, yes, take a look this https://pastebin.ubuntu.com/p/yS4mv6fwZ5/
<veebers> kelvinliu: mean cheers
<vino> babbageclunk: so i shd find another way to fix that problem.
<kelvinliu> veebers, cheers
<babbageclunk> vino: yeah, maybe - it might be that we just need another category of upgrade steps that we run before running state upgrade steps, and the service install step would go in that category?
<vino> babbageclunk: yes. something similar to  newUpgradeOpsIterator
<vino> which only calls installServiceFiles and it is for 2.4 upgrade
<babbageclunk> vino: that sounds reasonable - although you may as well make it so that we could add other steps to it (for a different version maybe) if we needed to.
<vino> babbageclunk: yup.
<veebers> babbageclunk: you have a quick minute? I won't take up much of your time
<babbageclunk> veebers: for you, a long minute!
<babbageclunk> in standup?
<veebers> babbageclunk: \o/ quick text should be ok:
<babbageclunk> oh, ok
 * babbageclunk removes headset sadly
<veebers> babbageclunk: this is logs of interest re: the CMR test and tearing down the model failing: https://pastebin.ubuntu.com/p/km7Ndcmxn6/
<veebers> hah sorry :-|
<babbageclunk> ok
<veebers> This test started failing when I used percona-cluster instead of just mysql, but it passes (when using percona-cluster) on a slightly older 2.4-beta2 build (I haven't narrowed down when the failure was introed)
<babbageclunk> ok
<veebers> babbageclunk: This is errounous behaviour right? Different to the suggested by Ian?
<babbageclunk> hang on, reading more carefully
<babbageclunk> in the email about CMR?
<veebers> babbageclunk: I hijacked the email to talk about the bug I'm looking at, it's talking about CMR and offers
<babbageclunk> yeah, I see the one - just comparing what he's saying with the log now
<babbageclunk> So the crit logs are your additions?
<babbageclunk> veebers: ^
<veebers> babbageclunk: huh, maybe it is what Ian outlined in the email "And because the application can't be deleted, model destruction never completes"
<veebers> babbageclunk: hmm, if they are they shouldn't be there. Let me confirm (I just re-built an older juju, the merge of the macaroon changes)
<veebers> babbageclunk: ugh no, this is a build of develop sorry, but yeah I'll check the crit log addition
<babbageclunk> oh, I thought they might have been something you'd added chasing this.
<veebers> babbageclunk: ok, so yes they are my crit logs, but the should not be there, they are left over cruft
<babbageclunk> it kind of does look like what he was suggesting - the offer keeping the application alive because of the remote applications that are still connected to it.
<babbageclunk> veebers:
<veebers> babbageclunk: ok, so presumably behaviour added sometime in the 2.4-beta2 lifespan.
<veebers> babbageclunk: although odd that it doesn't happen when using mysql :-\
<veebers> babbageclunk: I'll email with the log and my questions to try get clarity on it
<babbageclunk> veebers: maybe? yeah, that is odd. Seems unlikely when you put it like that.
<veebers> I'll also push up a PR shortly removing those extra logging that snuck past me
<babbageclunk> So it doesn't happen with mysql either on develop or beta1, and only happens with percona-cluster on develop?
<veebers> babbageclunk: correct. I'm just going to re-run using mysql now see if I can't capture something useful
<veebers> babbageclunk: oh, also seems odd that the machine the application was on is removed even though the app wasn't removed. Or is that not so surprising?
<babbageclunk> veebers: yeah, that's surprising, usually the application is removed when the last unit goes.
<veebers> babbageclunk: ack thanks, I'll fire off an email
<babbageclunk> veebers: oh, also - looking at the log it seems like it's actually the model log rather than the controller log? You wouldn't normally see messages about applications and relations starting in the controller log. Maybe there are some details in the controller log that would be useful?
<veebers> babbageclunk: that is the controller machine-0.log. I didn't catch the failure before the models machine was removed :0\
<veebers> babbageclunk: SInce I grabbed that log I see further entries, namely: ERROR juju.worker.dependency engine.go:551 "environ-tracker" manifold worker returned unexpected error: cannot read environ config: settings not found (not found)
<veebers> the model is still there (controller and relation-sink)
<veebers> and I see this error in status; attempt 2 to destroy model failed (will retry):  model not empty, found 1 application (model not empty)
<babbageclunk> veebers: ah, ok
<babbageclunk> veebers: any errors in the log?
<babbageclunk> veebers: I mean, other errors?
<veebers> babbageclunk: heh, I just killed those machines.  I don't think so, but I'll set it up to run again and collect the useful bits after dinner (the test annoyingly takes a while)
<babbageclunk> veebers: Could it be that the handling that was added to deal with dots in config need to be added somewhere in the CMR config propagation as well? Maybe it was succeeding in beta1 because the dot handling bug was there?
<veebers> babbageclunk: oh, interesting idea!
<bdx> elastic-peeps: ELK 6.x on bionic https://paste.ubuntu.com/p/5GyQ2pQFNY/
<bdx> https://jujucharms.com/u/omnivector/elk/
<veebers> ah man, I keep deleting my test machines out from under juju, I need to stop trying to do 2 things at once
<magicaltrout> thats not bad, I wiped my entire work laptop yesterday ;)
<veebers> magicaltrout: 0_0 d'oh that's a wee bit more annoying!
<babbageclunk> yeah, I keep removing machines when I meant to ssh to them. (Still not as bad as wiping laptop though. Pushes to github just in case.)
 * veebers wonders if he should *finally* get a proper backup solution sorted
<veebers> I think I may have jinxed myself now
<veebers> when I 'juju add-k8s' it hits the controller and inserts data in it's DB. Is that because that's needed for add-k8s, or needed for add-cloud in general or is that happening now because I have a controller bootstrapped, if I didn't have a bootstrapped controller and added a cloud (at the moment you need that for add-k8s) it wouldn't happen until I did bootstrap and it would happen at that point?
<veebers> Ok, seems that add-k8s is special, add-cloud does not hit the controller to add data
<wpk> veebers: I recently put an odroid hc2 + 4TB drive on another continent, in case of a gamma ray burst.
<wpk> veebers: should something happen I'll get it shipped with fedex, will be faster than transferring it back
<veebers> wpk: now that's a backup strategy!
#juju 2018-05-08
<babbageclunk> wpk: Uh, I don't think you'll be needing your data after a gamma ray burst. https://www.youtube.com/watch?v=RLykC1VN7NY
<veebers> anastasiamac, babbageclunk are there any other clouds that need special treatment on 'add-cloud', specifically details stored on the controller?
<anastasiamac> veebers: when u say 'other clouds', which ones u've catered for?..
<veebers> currently add-k8s updates the controller with details, and is listed in 'juju clouds', but if you bootstrap another controller that controller does not have those details (yet 'juju clouds' lists the add-k8s added cloud)
<veebers> anastasiamac: I'm looking at the add-k8s command and it seems to do some 'special' things
<anastasiamac> veebers: it is the only special one that i know of... :)
<babbageclunk> veebers: not that I know of.
<veebers> ack, I had assumed so :-)
<veebers> anastasiamac, babbageclunk: A controller should be able to have different models in different clouds right? Or are there restrictions? I've bootstrapped in lxd and add-cloud a new lxd cloud (just with a different name) but add-model chokes on it, it's not a clouds supported by that controller
<veebers> ah, it doesn't like any other cloud other than the localhost (and k8s if added)
<babbageclunk> veebers: no, generally a controller is one cloud only (although I guess caas relaxes that slightly).
<veebers> babbageclunk: ack ok that makes sense.
<veebers> babbageclunk: so, add-k8s adds details to the (currently selected) controller which means that if you bootstrap a different controller you'll need to add-k8s again, but that would fail as it's locally stored too. That seems odd, right?
<veebers> I was wondering if perhaps the controller needs some sort of JIT cloud up details update (like when you add a model for that cloud) or perhaps this is expected behaviour that needs fleshed out a bit
<babbageclunk> veebers: yeah, that seems odd.
<babbageclunk> (sorry for slow response.)
<babbageclunk> I'm not sure about the last point
<veebers> babbageclunk: no worries I know you're busy :-) I'll update the bug and email to try get clarity on it
<anastasiamac> veebers: i think that will fail because at the moment u can only locally add a controller once.. in this case, it's still the same controller
<veebers> anastasiamac: I don't understand that, adding a controller?
<anastasiamac> veebers: the fix is no simple... bthe same happens with controller registration, for e.g. u cannot run 'juju register' on the same client more than once
<anastasiamac> veebers: to rephrase (without typos...): at this stage, any given client can only b 'aware' of any given controller once
<veebers> anastasiamac: I think that's  a slightly different issue to what I'm looking at. add-k8s updates the controller with cloud details (stored in the db), but it only does that with the active controller, any others (and any newly boostrapped ones) will not contain that detail.
<veebers> anastasiamac: which means that if you "bootstrap test1, add-k8s blah, bootstrap test2, add-model -c test2 blah" it'll fail because test2 controller doesn't have the k8s details, except "juju clouds" will list it among available clouds
<veebers> *but* maybe that's somewhat expected? that a k8s cloud is added to a controller and not a juju config? (if that is the case it needs more work to clarify and harden that)
<anastasiamac> veebers: oh yes, of course :) my understanding is that 'add-k8s' is equivalent to enabling a controller to be k8-compatible... u need to be explicit... so only controllers that u have explicitly 'switched on to b k8 compatible' will have the ability
<anastasiamac> veebers: bu tbh, dunno if in ur scenario u can assume that test2 has the ability...
<anastasiamac> maybe if u boootstrap both first, then add-k8s they may both be k8-compatible... but that makes no sense either...
<veebers> anastasiamac: ack, that's not completely outrageous, but there is some cleanup work needed around that area
<anastasiamac> veebers: i think if we could specify what controller we r making k8 compatible explictly, that might clear up the mud ;D
<veebers> anastasiamac: it almost feels like it should be a 2 stage process, add the k8s-cloud and enable a controller
<anastasiamac> veebers: yes ^^
<anastasiamac> veebers: altho, does it make sense to enable 2 controllers to use the same k8s? dunno...
<veebers> anastasiamac: but even then you couldn't have 2 controllers looking at the same k8s cluster. Perhaps that's expected though
<veebers> anastasiamac: hah, jinx, asking the same question at the same time
<anastasiamac> veebers: :) there must b a delay btw our thinking but we r on the same page, which is a +
<anastasiamac> :D
<anastasiamac> :D :D
<veebers> ^_^
<veebers> anastasiamac: huh, I lied (well, only just now tried). add-k8s won't fail if you run it for a different controller (new controller is updated)
<anastasiamac> veebers: \o/ someone must have travelled the same road we r  :D
<veebers> anastasiamac: so I have a single character change I might put up for PR, or should I wait and put it in a different (unrelated) PR to make it "worthwhile"?
<veebers> I think a single char PR woudl be fine
<babbageclunk> better than fine!
<veebers> "It's better than bad, it's good!"
<babbageclunk> All kids love log!
<anastasiamac> veebers: :) we do prefer isolated changes :D but single char PRs are kind of like a treat :0
<babbageclunk> kelvinliu_: I think your PR looks great - I don't have any more to add over what anastasiamac said. Having a warning so we don't just silently ignore what the user's tried to set is good too.
<babbageclunk> gah, I think I'm going crazy here - does anyone have a moment to talk something through?
<anastasiamac> babbageclunk: i do
<babbageclunk> anastasiamac: awesome - in standup?
<anastasiamac> k
<veebers> Can I get a +1 please? https://github.com/juju/juju/pull/8676
<kelvinliu_> thx babbageclunk .
<babbageclunk> anastasiamac: thanks you're a genius!
<kelvinliu_> anastasiamac, babbageclunk updated the PR, appreciate if you could take a look. thx https://github.com/juju/juju/pull/8675
<babbageclunk> veebers: looking, then I'll look at yours kelvinliu_
<anastasiamac> veebers: i've commented too... are you sure?...
<veebers> anastasiamac: ah shit, I changed the wrong command 0_0
<anastasiamac> veebers: \o/
<veebers> hahaha, how can one of the simplest PRs be wrong
<anastasiamac> :)
<veebers> anastasiamac: thanks for the catch, I've push -forced so no one will ever know it took 2 commits to get that right >_>
<kelvinliu_> while testing my PR, I found bug on caas, https://bugs.launchpad.net/juju/+bug/1769806
<mup> Bug #1769806: infinitely scale up k8s managed units after upgraded controller <juju:New for kelvin.liu> <https://launchpad.net/bugs/1769806>
<veebers> kelvinliu_: in that bug the first command is "kubectl get all -n testcaas" and the 2nd "kubectl get all -n testcaas1" is that extra '1' on purpose?
<anastasiamac> veebers: nws, checking now :)
<veebers> anastasiamac: ah great, your comment on the PR is visible for all to see now, I can't get away with it :-)
<anastasiamac> veebers: ah babbageclunk beat me to it :)
<anastasiamac> veebers: but the important thing is the content, surely :D
<anastasiamac> veebers: FWIW, it was not an easy to pick up, thank you for seeing it with ur eagle eye (and fixing it!!)
<veebers> anastasiamac: surely pride first, then correctness ;-)
<kelvinliu_> veebers, good finding! updating
<babbageclunk> kelvinliu_: approved, a couple of minor wording tweaks.
<anastasiamac> haha, veebers, that might explain how proud ppl can be wrong :)
<anastasiamac> (not that it applies to this case, of course!!) :-)
<veebers> ^_^
<kelvinliu_> babbageclunk much better msg. updated, thx
<anastasiamac> babbageclunk: PTAL when u get a chance -   https://github.com/juju/juju/pull/8677
<anastasiamac> (the actual interesting bits with call back)
<babbageclunk> anastasiamac: ok, looking
<anastasiamac> \o/
<veebers> kelvinliu_: you may be intersted in my comments on bugs https://bugs.launchpad.net/juju/+bug/1768847 and https://bugs.launchpad.net/juju/+bug/1768845
<mup> Bug #1768847: add-k8s requires a model <add-k8s> <caas> <k8s> <juju:Triaged by veebers> <https://launchpad.net/bugs/1768847>
<mup> Bug #1768845: add-k8s incorrectly reports "cloud already exists" <add-cloud> <add-k8s> <caas> <k8s> <remove-cloud> <juju:Triaged by veebers> <https://launchpad.net/bugs/1768845>
<manadart> jam: I have a holiday here today, but I opened https://github.com/juju/juju/pull/8678 for 2.3.
<manadart> Will likely drop by for today's stand-up too.
<jam> hi manadart, enjoy your day off
<jam> thanks
<jam> morning all
<babbageclunk> morning jam, welcome back!
<jam> hi babbageclunk
<jam> thanks
<jam> babbageclunk: how's it going in Juju land?
<babbageclunk> jam: goooood? I'm still bashing my head on raft clustering.
<jam> babbageclunk: would it help to talk through it? I've done at least some of it for Mongo, so I might have enough context to help
<babbageclunk> jam: yeah, that would be really great, but I can't tonight - need to rush off soon. Can we do tomorrow?
<babbageclunk> jam: yay, I just saw my cluster recovery thing actually work!
<jam> babbageclunk: nice ! Give me a ping tomorrow. I'm happy to chat if I have time. I'm not sure if ian and tim are back around for meeting at 4UTC, and then I have to take my dog to the vet at 6UTC, but if we can find a time, I'm happy to chat.
<babbageclunk> jam: ok, awesome, thanks!
<jam> babbageclunk: if you have code you want me to look at, you could push it up as WIP, or something.
<babbageclunk> jam: yeah, I'm going to push it up now - I'll send you a link.
<babbageclunk> needs some tidying to remove the huge amount of debug logging I just added.
<babbageclunk> jam: ran out of time, I'll create a WIP PR when I get back later this evening
<magicaltrout> multi monitor support in 18.04 is absolutely abysmal :)
<babbageclunk> hey jam, here's the WIP PR: https://github.com/juju/juju/pull/8680
 * babbageclunk goes to sleep
<jam> externalreality_: for bug #1761706 I know we landed your patch for develop, did you also backport it to 2.3 ?
<mup> Bug #1761706: Bootstrap on Openstack fails if there is an IPv6 subnet <juju:Fix Committed by ecjones> <juju 2.3:Triaged by ecjones> <https://launchpad.net/bugs/1761706>
<jam> and/or *can* you backport it?
<externalreality_> jam, checking
<externalreality_> jam, looks like it was already backported: https://github.com/juju/juju/pull/8630
<jam> externalreality_: thanks, we just didn't update the bug
<externalreality_> jam, my fault. I just saw that, and updated to fix-committed.
<jam> thanks
<admcleod_> i see 2.3.8 is candidate in the snap store, when would that go to stable?
<rick_h_> admcleod_: not sure. We just put out .7 and the .8 will be tracking the 2.3 trunk as it moves forward
<rick_h_> admcleod_: something in there you're waiting on?
<admcleod_> yep bug..
<admcleod_> 176317 and ...
<admcleod_> 1765571
<admcleod_> that doesnt look right does it
<rick_h_> no, not quite
<admcleod_> 1764317 and 1765571
<rick_h_> admcleod_: ah, there's one more bionic bug that needs to land for that. I'm not sure what timeline it'll be.
<rick_h_> admcleod_: once that's done we can make sure to work to time a release witht he bionic fixes in place
<admcleod_> rick_h_: yeah - would be great to start that before next tuesday
<rick_h_> admcleod_: k, ty for the feedback there. What's next Tues?
<admcleod_> rick_h_: openstack charm freeze
<rick_h_> admcleod_: ah ok
<admcleod_> rick_h_: how would i know if those backports on the bugs, to 2.3.8, are in the snap candidate? any way for me to find out?
<rick_h_> admcleod_: looking
<admcleod_> thanks!
<rick_h_> admcleod_: so the snap info shows the git sha on the end there and that matches up to the latest commit in the 2.3 tree here: https://github.com/juju/juju/commits/2.3
<admcleod_> ah!
<rick_h_> admcleod_: I see the lxd init one there, looking for the second one
<rick_h_> admcleod_: looks like those two bugs are the last two commits just landed in the last 6hrs so they're fresh
<rick_h_> admcleod_: you're just bleeeeeeding edge heh
<admcleod_> awesome
<admcleod_> thanks rick
<rick_h_> np
<TheAbsentOne> Hi all, I once again (sorry for that) ask for some help when writing a charm and an interface layer. It seems I still fail to grasp everything. I start prototyping the main aspects on this page: https://github.com/Ciberth/Logboek-Thesis/blob/master/prototyping.md Could someone take a quick look to see if this is the right way and if my reasoning is correct? Once i get home I'll try building everything and putting repo's online, 
<bdx> TheAbsentOne: you are getting warmer for sure
<bdx> TheAbsentOne: have you followed the charm authors docs and built the vanilla charm?
<TheAbsentOne> yeah more or less on a smaller project bdx gotta run now though Im back in an hour
<bdx> TheAbsentOne: https://jujucharms.com/docs/stable/developer-getting-started
<bdx> should solve all your problems if you understand whats going on ^
<TheAbsentOne> bdx: I'm just having troubles with writing the interface layer properly I think,
<bdx> totally
<bdx> can you go through ^ example a few times please?
<bdx> I think it may serve you well
<bdx> TheAbsentOne: this too https://jujucharms.com/docs/stable/developer-layer-example
<TheAbsentOne> Sure I'll reread it first, then create the repo's and go from there. I'll get back to you,
<TheAbsentOne> though I think I know these docs by heart by now xD
<bdx> TheAbsentOne: you shouldnt need to create any interfaces
<bdx> they already exist
<bdx> see how its done in the vanilla charm example^
<TheAbsentOne> oh but I do sir, I really need the ability to have a generic-database inside a requires/provides from the metafile for my use cases bdx (back in an hour or so)
<rick_h_> what's up bdx?
<bdx> rick_h: what's going on???
<bdx> I'm breaking the qtrly budget getting these blades ordered for the openstack, writing company docs like a mad man, snapping and charming everything in sight
<bdx> you know
<bdx> the usual
<bdx> :)
<bdx> rick_h: you back in the states?
<bdx> thinking about just making these public https://imgur.com/a/lgEkHKn
<bdx> talking to the guys doing ceph at GARR about a little collab on some intro -> advanced juju ceph and openstack operations documentation, hoping to fold in my hoard ^
<bdx> currently working on an xpak subordinate for the elastic stuff
<rick_h_> bdx: sorry, made some tea :)
<rick_h_> bdx: yea, back home and working on TZ adjustments
<rick_h_> bdx: nice on public-fying fun stuff
<rick_h_> reminds me, i need to figure out what I'm doing for the show tomorrow.
<rick_h_> cory_fu: you going to be around? want to show off that aws stuff?
<sfeole> rick_h_, hey, just fyi , juju2.4-beta2 daily appears to have working bionic lxd containers: https://pastebin.ubuntu.com/p/mqbZR4BsNz/
<sfeole> :)
<rick_h_> sfeole: yea, that's got the same two fixes in there
<sfeole> rick_h_, just fyi, i'm using it today, figured i would let you know
<sfeole> :)
<admcleod_> rick_h_: just confirmation
<rick_h_> sfeole: nice to see, awesome!
<rick_h_> externalreality_: manadart ^
<rick_h_> admcleod_: sfeole so the one thing known out is an issue with bonds and bionic (in case you tinker with that)
<sfeole> rick_h_, i don't actively but will keep that in mind
<bdx> few random questions
<bdx> in 2.4, will juju opt to install lxd from a snap, or will it continue to install lxd from apt?
<bdx> also, will it be possible to use custom storage pools with juju deployed lxd instances in 2.4?
<bdx> `juju deploy ubuntu --to lxd:0` - I want the lxd to use storage backed X
<bdx> backend*
<bdx> possibly these things will be taken into consideration as lxd 3.0 sinks in over the next amount of time
<rick_h_> bdx: so, not sure on install from snap. We'll have to look and see. The one thing that makes me nervous is the story behind the firewall off the top of my head, but it's something that's got to be done/figured out at some point
<rick_h_> bdx: as far as custom storage, there's a roadmap item for the next cycle to improve lxd 3 support including constraints/instance types, remote clusters, and some profile customization methods
<rick_h_> bdx: I'll note that as part of the conversation there
<bdx> rick_h_: awesome, thx
<thumper> moring team
<thumper> or morning
<TheAbsentOne> hi, goodnight x)
<veebers> Morning all o/
<veebers> hey thumper how's things?
<TheAbsentOne> bdx: still here by any chance?
<TheAbsentOne> When I try to build a charm that uses a local interface, I get the error that build doesn't find the interface, but when I echo $JUJU_REPOSITORY everything is exported correctly, did I miss something?
<bdx> TheAbsentOne: did you also export LAYER_PATH and INTERFACE_PATH
<bdx> ?
<TheAbsentOne> yep both echo fine bdx
<bdx> TheAbsentOne: is your interface under $INTERFACE_PATH?
<bdx> TheAbsentOne: can you paste the output of `ls -la $INTERFACE_PATH | pastebinit`
<TheAbsentOne> https://www.dropbox.com/s/arwlx108kjgys51/tempinterfacerror.png?dl=0 bdx
<TheAbsentOne> bdx: paste.ubuntu.com/p/S6Y4gP8wwN
<TheAbsentOne> ow sorry: https://paste.ubuntu.com/p/S6Y4gP8wwN/ *
<TheAbsentOne> It's not like you need to build or anything an interface right?
<bdx> TheAbsentOne: `mv $INTERFACE_PATH/generic-database-layer $INTERFACE_PATH/generic-database`
<bdx> TheAbsentOne: then try building your layer
<babbageclunk> hey thumper, welcome back!
<TheAbsentOne> bdx: oh god ofcourse, I'm retarded, thanks so much
<bdx> np
<TheAbsentOne> so stupid >.<
<thumper> veebers: things are generally good
<thumper> although jet lag has hit me particularly hard this time
<bdx> TheAbsentOne: its a common mistake, no worries - I think there is an initiative to infer the interface from the name in the interface.yaml file instead of the name of the directory
<bdx> not sure what ever happened to it
<bdx> let me see if I can find it
<TheAbsentOne> that would be interesting, to be honest I thought that was the case first bdx
<bdx> TheAbsentOne: totally, I feel it should be too
<veebers> thumper: "generally good", very ominous :-) hopefully the lag wears off shortly
<wpk> thumper: bists du ein berliner?
<TheAbsentOne> bdx: like in my case I have a repo called "generic-database" which is my charm and not my interface but this might become confusing when using the interface "generic-database"
<bdx> totally
<bdx> TheAbsentOne: I've found prefixing the layer, interface, bundle, snap repo name with what they are, see how I do them here https://github.com/omnivector-solutions
<TheAbsentOne> bdx: I have another remark/question. The output of the build now states: "build: layer.yaml includes generic-database-layer which isn't used in metadata.yaml" where does he get's this from?
<TheAbsentOne> bdx: yeah I might have to rename them idd, good tip
<bdx> ahh, look at any of the layers ^^ and look at the metadata.yaml and see how it defines the interface under either the requires or provides stanzas
<TheAbsentOne> the metadata defines it as "interface:generic-database"
<TheAbsentOne> that "generic-database-layer" is never used or typed only in folder name
<bdx> TheAbsentOne: link to the repo?
<TheAbsentOne> https://github.com/Ciberth/generic-database-layer is the interface, https://github.com/Ciberth/consumer-app uses it at requires side, https://github.com/Ciberth/generic-database uses it at provides side
<TheAbsentOne> I find it weird that the build procedure even finds that
<TheAbsentOne> bdx: maybe it does take the name from the interface.yaml; I made a mistake there!
<bdx> ok
<bdx> thats what I thought
<TheAbsentOne> yep that was it! Maybe I should call it a day and sleep haha xD thanks again though bdx
<bdx> np
<babbageclunk> veebers: hey, did you work out what was happening with the problem you were seeing with CMR and percona-cluster?
<veebers> babbageclunk: not yet still working on it, annoying as the test I run to uncover it takes *ages*
<babbageclunk> veebers: sucks
<babbageclunk> I mean, the slow test meaning it's hard to investigate
<veebers> babbageclunk: I'm trying to narrow down the commit range to narrow down where to look for the issue (I'm not familiar enough with the codebase to make a fully educated guess based on symptoms)
<veebers> hah ^_^
<babbageclunk> What's the time range/commit range?
<babbageclunk> I can have a look at a list of commits to see if there's anything poignant to suggest good starting places.
<veebers> babbageclunk: hah so far between the macaroon version bump (works) and the catacomb tomb v1 ->v2 change. Somewhere there :-) Narrowing it down now
<veebers> babbageclunk: am I correct in thinking that ControllerCommandBase commands are commands that take "-c <controller>" args and act on a controller (as opposed to a hosted model)
<babbageclunk> veebers: yup
<veebers> sweet, cheers
<vino> babbageclunk: just a quick note - I didnt fix in the way we discussed on Monday(adding one more upgrade step for 2.4). I can explain u what happens around that code part.
<babbageclunk> vino: ok, let me have a read through the PR and we can talk about it
#juju 2018-05-09
<vino> babbageclunk: sure. SO for now i will address the systemd unit tests. Becuase if the fix around mongo.go is not justfied. then there is no point me fixing those mongo_tests. But i am sure the fix around that verification is ok.
<babbageclunk> vino: makes sense
<vino> I will also add a note around there in PR so that anyone looks into it can have a say abt that part in mongo.go. Maybe Ian can look into it later.
<babbageclunk> vino: can we chat in a hangout? I've got some questions about the PR.
<vino> babbageclunk: hi can u gimme 5 mins please... i am almost done fixing all issues in systemd.
<vino> please :)
<vino> or 2 mins
<babbageclunk> vino: ok, ping when you're ready. :)
<vino> babbageclunk: thank u
<vino> babbageclunk: lets go to hangout
<babbageclunk> ok
<veebers> Could I get a review on this quick one? (removing debugging logging) https://github.com/juju/juju/pull/8673
 * anastasiamac looking
<veebers> cheers anastasiamac
<anastasiamac> \o/
<veebers> argh, the failure reason: I'm a bid dumb doo-doo head :-\
<veebers> replace "return modelcmd.Wrap(cmd)" with "return cmd", *should* have been: return modelcmd.WrapController(cmd)
<veebers> kelvinliu: FYI https://github.com/juju/juju/pull/8683
<kelvinliu> veebers, looking now
<veebers> babbageclunk: ^^ thats the PR for the work I spoke with you about the other day (add-k8s command being a BaseCommand or controller command vs a model command)
 * thumper EODs
<babbageclunk> veebers: consarn it, why didn't I get a notification about that! Sorry. Looking now anyway.
<babbageclunk> veebers: approved
<veebers> yay cheers
<srihas> hi guys, I have added 10 machines using juju add-machine. if I do juju machines I get all machines 0-9 with state started
<srihas> I am trying to deploy openstack-base using juju deploy ./openstack-base
<srihas> but I have removed the "machines" section from the bundle.yaml file
<srihas> https://paste.ubuntu.com/p/cqfrKJQkPW/
<srihas> These are the errors I am getting
<srihas> if I keep the machines section, then the error is like No available machine matches constraints: [('zone', ['default']), ('agent_name', ['ca16835a-e545-49b1-89ac-d59fea465599'])] (resolved to "zone=defau
<srihas> can someone help?
<zeestrat> srihas: If you're trying to map existing machines then you might want to look into mapping them: https://jujucharms.com/docs/2.3/charms-bundles#recycling-machines
<srihas> zeestrat: saved my day
<srihas> thank you :)
<zeestrat> srihas: No problemo.
<srihas> zeestrat: the bundle doesn't have corosync+pacemaket thing for HA, can I add it later and map using relations?
<srihas> pacemaker*
<zeestrat> srihas: We usually deploy it straight away, but should probably work later to as long as you set the correct options. See https://jujucharms.com/hacluster/ for more details
<srihas> zeestrat: will look at it, I might need to tweak a little bit :) ty
<srihas> zeestrat: it installed mysql 5.6 along with the bundle not mysql 5.7
<srihas> I will wait and see if it upgrades after deployment
<srihas> cinder/3                waiting   idle   4/lxd/0  10.80.22.3      8776/tcp        Incomplete relations: messaging
<srihas> how can I see the logs?
<srihas> rabbitmq-server/5       active    idle   6/lxd/5  10.80.22.36     5672/tcp        Unit is ready and clustered
<srihas> Am I missing something?
<cory_fu> tinwood: I updated https://github.com/juju/charm-tools/pull/396 per your review, when you have a chance to take a look.  I'm also looking over your PR and I'm just about ready to +1 it.  Should we consider updating the snapcraft.yaml to use Py3, though?
<tinwood> cory_fu, hi!  Sure, I'll take at look at 396.  I hadn't thought of the snapcraft.yaml to be honest :)  Yes, it's probably a very good idea.  Shall I do that too as part of the PR?
<cory_fu> tinwood: Sure.
<tinwood> cory_fu, kk, I'll take a look at that.
<bobeo> o/
<bobeo> with my juju deployment via maas, I can account for 17 physical servers, but inside of maas, I only see 9 nodes accounted for. 2 of the 17 are dedicated for a physical instance of vmware, 1 for an haproxy instance, so thats 3 of 17, plus 9, for 12. 5 are unaccounted for, but 89 devices are listed in maas. What are some suggestions on best ways to approach this situation? Also, I would like to move machines and applications between models
<manadart> guild cats: https://github.com/juju/juju/pull/8686
<bobeo> with my juju deployment via maas, I can account for 17 physical servers, but inside of maas, I only see 9 nodes accounted for. 2 of the 17 are dedicated for a physical instance of vmware, 1 for an haproxy instance, so thats 3 of 17, plus 9, for 12. 5 are unaccounted for, but 89 devices are listed in maas. What are some suggestions on best ways to approach this situation? Also, I would like to move machines and applications between models
<bdx> bobeo: I would back wayyyyy out
<bdx> bobeo: 1) get everything working/showing up correctly in maas
<bdx> without juju being a part of the picture
<bdx> bobeo: 2) bootstrap maas with juju only after you have #1 ironed out
<bdx> bobeo: that should get you moving in the right direction
<rick_h_> bobeo: so MAAS will search the network for devices out of the box on the network
<rick_h_> bobeo: this could be wifi access points, tvs, really anything
<rick_h_> bobeo: so the nodes view is only comissioned hardware that Juju would use
<rick_h_> bobeo: anything on the devices list aren't in Juju's realm. That's a MAAS/network thing
<rick_h_> if I'm reading that right
<bdx> ahh I think I may have read it wrong, @bobeo my bad - sounds like your maas may be working legitimately and you are just confused about the extra devices showing up in maas?
<bdx> "with my juju deployment via maas, I can account for 17 physical servers" - possibly some of these are lxd
<bdx> ?
<bdx> rick_h wins
<bdx> :)
 * rick_h_ does victory dance...if he's right
<rick_h_> mainly looking for opportunities to dance
<TheAbsentOne> rick_h_ I hope your victory dance isn't one that makes it rain x)
<TheAbsentOne> Does anyone see why I get a TypeError method() takes 1 positional argument but 2 were given on https://github.com/Ciberth/generic-database/blob/master/reactive/generic-database.py#L35 I'm confused as I used the pgsql interface before and it worked like this :s
<TheAbsentOne> https://interface-pgsql.readthedocs.io/en/stable/requires.html#example-usage <-- exactly the same no?
<bdx> TheAbsentOne: I'm 0/1 today so no promises
<bdx> TheAbsentOne: they aren't the same, I can spot the difference, can you?
<TheAbsentOne> well I feel more and more retarded every day I work with the reactive framework so go ahead become 1/2 haha
<bdx> TheAbsentOne: the new endpoints stuff should help with this issue because you can forego passing the arguments into the function at all and just use endpoint = endpoint_from_flag('psqldb.master.available'); endpoint.master['dbname'] -  basically you are passing two objects into that function because of the two flags in the @when, and you only defin
<bdx> e one argument
<bdx> TheAbsentOne: https://github.com/jamesbeedy/mysql-shared-example/blob/master/reactive/mysql_shared_example.py#L39
<TheAbsentOne> that's what I was thinking the second flag passes a second object so basicly 2 'selfs' right? bdx
<TheAbsentOne> so in this example I can just delete the parameter then?
<bobeo> bdx: rick_h_  Yea, its working right, and synced right with juju. my issue is I have hardware that is an outlier to juju/maas, and I want to keep it that way for that existing infrastructure. I made the mistake of not configuring the IPMI intelligently, which was my mistake, and so now Im trying to unfubar myself
<bdx> lol ok then :)
<TheAbsentOne> and what is the proper way to have the object then where I can call set_database on in the function above bdx ? Can you do that too with endpoint?
<bobeo> The idea being identify the other 8, which I have now,a nd figure out A. How did I miss 8 servers? and B. Reconfigure their IPMI networking so they arent mixed in, so I dont make the same mistake twice.
<bdx> TheAbsentOne: yes
<bdx> TheAbsentOne: another example  https://github.com/omnivector-solutions/layer-logstash/blob/master/reactive/logstash.py#L53,L56
<TheAbsentOne> so i can endpoint = endpoint_from_flag('..'); endpoint.set_database()? bdx
<bdx> yessir
<TheAbsentOne> that's awesome, thanks for that example of logstash
<bdx> np
<TheAbsentOne> I'm really messing things up by combining new ways with old ways it seems
<bdx> TheAbsentOne: yeah, things just recently got changed around a bit, I'm totally in favor of the endpoints patter (the new way) - I feel its far cleaner and more explicit amongst other things
<bdx> TheAbsentOne: its probably just more confusing for you combining the two
<bdx> TheAbsentOne: the olden way should be gone and deprecated soon enough, I would just stick with the endpoints pattern going forward unless you have a reason not to
<TheAbsentOne> yeah definitely the endpoint pattern is awesome, it's just that I try to look at other examples for help and stuff and I mix it up doing weird stuff
<TheAbsentOne> I'm gonna try to fix it in a bit thanks again bdx, maybe you should write a tutorial ;)
<bdx> np
<bdx> TheAbsentOne: seems to be all I do lately - https://imgur.com/a/lgEkHKn
<bdx> thats only a small subsection of the overall docs
<TheAbsentOne> Hehe shows how fluent you are with it! I'll try to write some things to and let you guys review it, might be interesting for newcomers
<TheAbsentOne> is it public available? bdx
<bdx> TheAbsentOne: awesome
<bdx> not yet
<bdx> they will be soon
<TheAbsentOne> looking forward to it!
<bdx> getting lots of good feedback internally, should give for a better end product when I release them to the wild
<bdx> give me a week or so,  I'll ping the list when I start releasing them
<TheAbsentOne> Good stuff, sounds very nice
<rick_h_> Juju Show reminder in 40min kwmonroe cory_fu bdx zeestrat and anyone else that wants to hang out or stream
<rick_h_> get
<rick_h_> get your coffee filled up
<kwmonroe> ahoy rick_h_, i won't be able to make it today -- we welcomed a baby girl into the world last week, so i'm just getting caught up from paternity leave.  i'll see your coffee advice and raise you a redbull.
<rick_h_> kwmonroe: congrats!!!!!
<rick_h_> kwmonroe: time to setup the mainline
<kwmonroe> :)
<rick_h_> kwmonroe: assume everyone is doing ok?
<kwmonroe> yup yup rick_h_, everyone is doing great!
<TheAbsentOne> kwmonroe congratz, enjoy it!
<kwmonroe> thanks!
<rick_h_> kwmonroe: so awesome, get a good nap in :)
<bobeo> bdx: rick_h_ ok so I solved that problem, now juju is trying to deploy in two zones I dont want it to deploy from, which arent the defalt zone. any ideas?
<rick_h_> Links for the show today: to join and chat https://goo.gl/4kZPBT and to watch all the things from the comfort of an un-mike'd browser use https://www.youtube.com/watch?v=HIDcHiNV-6o
<TheAbsentOne> I still love that foto and the fact it was taken at my college x)
<rick_h_> TheAbsentOne: cool
<bdx> kwmonroe: congrats!!
<kwmonroe> thx bdx!
<bobeo> rick_h_ bdx kwmonroe how do I deploy to a specific zone?
<bdx> bobeo: --to zone=<zone-name>
<bobeo> bdx: HAZAAAH!
<bobeo> I kept doing --zone=<zone name> I thought I was going crazy XD
<kwmonroe> bdx: tell rick_h_ that his screen is not the primary
<TheAbsentOne> yeah not catching the terminal
<kwmonroe> nope, bdx, tell him to screen share better -- he's showing Erik's face
<bobeo> bdx: ok so Im losing my mind here. Does the hardware state need to be in "Ready" or "Allocated" state in order to be allocated to a juju application?
<bdx> bobeo: ready
<TheAbsentOne> wait I was behind a bit, what happened to the stream xD
<kwmonroe> TheAbsentOne: it died for me around 15m :/
<kwmonroe> probably because i was lamenting the fact that rick_h_'s terminal was not being presented.
<TheAbsentOne> yeah same, too much eric for the stream to handle x) just kidding ;)
<kwmonroe> lol
<TheAbsentOne> the call is probably still busy?
<rick_h_> uh oh
<bobeo> bdx: Ok, so then why isnt this working? juju deploy cs:~graylog-charmers/graylog --to zone=Security
<rick_h_> when I dropped to reconnect did it kill the livestream?
<bdx> possibly
<bobeo> the box is in the ready state in the Security zone
<rick_h_> oh crap it did!?!?!?!
<TheAbsentOne> rick_h_: youtube posted vid of almost 16 min
<rick_h_> oh man...rick fail
<rick_h_> even worse than I thought I did
<TheAbsentOne> all is lost after that xD
<bdx> bobeo: whats does the error say?
<rick_h_> well actually it's there after I reconnect
<rick_h_> so that didn't kill it, but something else did
<TheAbsentOne> do you have local recording rick_h_ ?
<rick_h_> TheAbsentOne: nope...I had to switch machines and such
<rick_h_> bdx: zeestrat (bdx is your friend here?) https://insights.ubuntu.com/2018/05/03/lxd-clusters-a-primer
<bobeo> bdx: Thats the weird part, its not giving an error. The system isnt shifting from ready to allocating, maas specifically, and juju is just saying pending machine
<bobeo> agent says "allocating"
<bobeo> should I kill the app and restart it?
<bdx> idk, @eriklonroth^
<bobeo> the install*
<bdx> the node is probably booting
<bobeo> bdx: thats the thing though, its not moving from the ready position in maas, its just sittng there
<bdx> bobeo: ahh I see
<rick_h_> kwmonroe: oh damn, I see what you're saying. Since I reconnected and wasn't the "driver" of the stream I could click and see my terminal but it didn't make it the stream's main view
<rick_h_> man, what a can of fail today
<rick_h_> ok, pulling the video
<bdx> bobeo: can you capture a few screen shots
<bdx> of the node details page in maas and the juju status
<bobeo> sure!
<TheAbsentOne> rick_h_: don't be bothered by it too much man it happens
<rick_h_> hah, /me just put together eriklonroth is erik from the HO. https://insights.ubuntu.com/2018/05/03/lxd-clusters-a-primer for you too
<bobeo> bdx: ok I got them
<bdx> bobeo: use your fav img posting service and send some links
<bobeo> bdx: https://imgur.com/a/vt20E8A
<bobeo> bdx: Do you think its because of this from the link vs the instruction set? cs:graylog-15 vs juju deploy cs:~graylog-charmers/graylog --to zone=Security
<bobeo> bdx: Do you think if I changed it to juju deploy cs:graylog-15 --to zone=Security  that it will deploy?
<bdx> bobeo: what I usually do in this situation is go back to square 0
<bdx> bobeo: try just `juju deploy ubuntu`
<bdx> or `juju add-machine`
<bdx> we need to get the most basic use case working before trying to deploy charms to zones
<bdx> possibly `juju add-machine` may be best here
<bdx> see if you can get that to work
<bobeo> bdx: see if I can get a machine to add at all, then add the app to the machine with the --to machine:"X" sufix?
<bdx> yeah, but more or less, we just want to verify
<bdx> this isn't the long term fix
<bobeo> dangit, its hung not aborting two add-machine commands
<bobeo> tried juju remove-machine "X"  and with --force, its not working
<bdx> after you verify that you can add machines successfully, then try adding them to specific zones `juju add-machine zone=Security`
<bobeo> still trying to add the machines
<bobeo> yea, thats what I meant to do
<bdx> I see
<bdx> bobeo: yeah, you may have gotten your model stuck possibly
<bobeo> bdx: Any ideas? I checked all IPMI to make sure no mismatched IP, and no issues there.
<TheAbsentOne> bdx: you still here? I'm close to having a working thing but I'm once again lost in my own thoughts. I basicly want to pass a flag from one charm to another. How do you that in endpoint pattern properly?
<TheAbsentOne> I want a @when in my other charm on this https://github.com/Ciberth/generic-database/blob/master/reactive/generic-database.py#L70
<TheAbsentOne> https://www.dropbox.com/s/n27pznx2ms3ew4d/temphandlerquestion.png?dl=0 <-- this in the requires.py doesn't make sense right?
<veebers> Morning all
<thumper> morning team
<babbageclunk> morning
<TheAbsentOne> Welp I see the morning's time for me to go to bed, I'll try again tomorrow ^^ bye everyone
<magicaltrout> so... if you trash your laptop
<magicaltrout> is it possible to reconnect to a manually provisioned juju setup?
<magicaltrout> or do i need to find a backup from somewhere?
<admcleod_> magicaltrout: was the controller on your laptop too?
<magicaltrout> nope
<magicaltrout> i tried `juju register <ip address>`
<admcleod_> magicaltrout: you could run 'juju add-user' on the controller host
<magicaltrout> I have zero clue if its doing anything
<admcleod_> magicaltrout: that shuld probably work but i guess you still need some creds - maybe try with --debug
<magicaltrout> debug shows nowt also
<admcleod_> magicaltrout: try 'juju add-user' on the controller machine
<magicaltrout> hmm so the controller is remote, but I didn't bootstrap it on the remote machine
<magicaltrout> so there's no juju binary
<admcleod_> hrm
<babbageclunk> magicaltrout: I feel like this must have happened to someone before...
<magicaltrout> meh one of the other guys has access to it I can get him to prod it and sort it out tomorrow, i just trying to cheat
<babbageclunk> I think you could make the controllers.yaml file you'd need, given that you can ssh to the controller machine, but it would be fiddly.
<magicaltrout> yeah.... not that bothered ;) I'll figure it out via a working install tomorrow :P
<magicaltrout> thanks chaps
<admcleod_> \o/
<babbageclunk> magicaltrout: cool
<thumper> magicaltrout: I strongly recommend keeping a backup
<magicaltrout> backups are for wimps
<thumper> magicaltrout: in theory it is possible to reconstruct the components necessary to build up what you need to reconnect
<thumper> but it isn't easy
<thumper> and not automated
<thumper> if you had credentials on the controller
<thumper> then IIRC there was a connect command
<thumper> either done or planned
 * thumper looks
<veebers> well this doesn't make sense at all, my initial bisect suggests that 9d4339d (inc to beta2) is good and 9d4339d is the first bad (adding caas unit test bits). How can that break the CMR test 0_0
<thumper> magicaltrout: if the controller doesn't have a public cert, there is no easy way to reconnect
<thumper> as the client doesn't know the server CA cert
<thumper> so there is no client command to do this
<magicaltrout> who cares about SSL, GCHQ can crack it anyway.....
<magicaltrout> fair enough thumper !
<thumper> np
<thumper> babbageclunk: got a few minutes?
<babbageclunk> thumper: yup - give me 1 min? Just finishing a review.
<thumper> ack
<babbageclunk> thumper: ok
<babbageclunk> in 1:1?
<thumper> yeah
#juju 2018-05-10
<veebers> Where would I start looking to learn how a model is added (specifically a caas model). I'm wanting to figure out how to determine if a controller has something that is using the "add-k8s" added cloud details for that controller
<anastasiamac> veebers: depends on ur patience but maybe from cli that adds a model? that should take u thru all the layers :)
 * veebers puts on spelunking kit
<veebers> anastasiamac: sweet, I'll dive on in :-)
 * veebers takes of kit
<veebers> no, need to eat first
<anastasiamac> veebers: good idea, no need to look at code hungry... oh... wait...
<anastasiamac> :)
<veebers> anastasiamac: you have a moment, want to outline how I might implement the code to fix this bug https://bugs.launchpad.net/juju/+bug/1768845
<mup> Bug #1768845: add-k8s incorrectly reports "cloud already exists" <add-cloud> <add-k8s> <caas> <k8s> <remove-cloud> <juju:Triaged by veebers> <https://launchpad.net/bugs/1768845>
<veebers> anastasiamac: Roughly remove-cloud needs to ask the controller if anything is using that cloud, if so error. If nothing using it we remove it from the controller and then locally.
<veebers> query: Querying the controller like that, that'll be a new facade call? Should it be 2 calls? (1. check for usage 2. remove cloud details)
<veebers> babbageclunk: when would one use GetRawCollection over GetCollection? Context, I want to do a simple query on models collection: find count where cloud == <cloud name> and type == "caas"
<babbageclunk> veebers: the non-raw one will add the state's model uuid to any ids in queries or updates. So if you want to query across models you'll need to use GetRawCollextion, I think.
<veebers> babbageclunk: ah ok, so a query run on the controller checking which models may be caas on that cloud should be fine with a raw, right (I just need to know if any exist)
<babbageclunk> veebers: yeah, that sounds right.
<veebers> babbageclunk: If you have a second could you respond to my question I should have asked the room but singled out anastasiamac :-)
<babbageclunk> veebers: How would you expect it to behave if it was in use in one controller but not in another? Error without removing any? Or remove it from the ones where it's not in use and then error about the ones where it is?
<babbageclunk> (I think the former, not totally sure.)
<veebers> babbageclunk: I still haven't gotten clarity on that, there is a discussion on the 2 bugs, but nothing definitive for when there might be multiple controllers using the cloud
<veebers> babbageclunk: in the bug (the other one with the discussion is: https://bugs.launchpad.net/juju/+bug/1768847) I suggest perhaps removal be a 2 part step (2-part commands are frowned upon I know :-)). Split it into remove from controller and remove locally
<mup> Bug #1768847: add-k8s requires a model <add-k8s> <caas> <k8s> <juju:Triaged by veebers> <https://launchpad.net/bugs/1768847>
<veebers> babbageclunk, anastasiamac: https://github.com/juju/juju/pull/8689 this updates the upgrade functional test to use percona-cluster. I've not done the CMR test yet as I'm still scratching my damn head on that one.
<veebers> (so I thought screw it land the upgrade test, CMR can land later)
<babbageclunk> veebers: whoa, that's bigger than I was expecting from the description.
<babbageclunk> oh, because of the local mediawiki.
<veebers> babbageclunk: lol yeah I forgot to specifically mention it uses a local copy of mediawiki to fix anissue that was breakint the trest
<veebers> aha typing is hard
<veebers> I'll update the PR comment to make it more obvious
<babbageclunk> Are you on a bouncy castle now?
<veebers> babbageclunk: oh man I wish, that would explain how non-productive I've been today :-\
<veebers> I did break into that kvm node though, so *yay*
<anastasiamac> yes and m sure that experience beats bouncy castle any day!!
<veebers> hah ^_^
<jam> anyone able to get to CI Jenkins? I'm on the VPN but  http://10.125.0.203:8080/ isn't returning for me
<manadart> jam: Doughnuts for me too.
<manadart> Latest CI run for my PR got a 503 installing Go from snap too.
<jam> manadart: snap store was down for a bit
<jam> manadart: but I thought it was back up
<jam> manadart: it seems there has been a general connectivity problem to the Canonical datacenter
<manadart> jam: Ack. Seems to be running now.
<jam> guild: can I get a review for https://github.com/juju/juju/pull/8690
<jam> stickupkid: so... before going to the effort, could we just copy that repo and name it to something useful?
<jam> (before I set up a bot on a repo that I'd like to kill :)
<manadart> jam: Approved it.
<jam> manadart: hm. just got a "took to long to connect" to hangouts, trying again
<ice9> when i run juju destroy-controller, the command hangs, how can i debug this issue?
<stickupkid> ice9: have you run with --debug flag?
<ice9> stickupkid, juju.juju api.go:67 connecting to API addresses: [10.96.159.38:17070] seems this IP doesn't exists
<ice9> is there away to force a juju command?
<ice9> even list-machines hangs
<manadart> ice9: Try kill-controller
<ice9> manadart, it hangs as well, even juju status
<ice9> since i deleted those containers, juju cannot execute it's commands against non existing containers so it hangs!
<manadart> If the controller machine is already gone, try "juju unregister <controller>"
<TheAbsentOne> Is there a charm reactive/endpoint pattern wonderperson online that can help me out with implementing my layer?
<TheAbsentOne> https://github.com/Ciberth/generic-database/blob/master/reactive/generic-database.py#L58 I want to implement this but now I'm once again in doubt if I should use that share_details function or if I should create a handler in the provides.py that reacts on the available flag sharing it
<tvansteenburgh1> cory_fu: ^
<cory_fu> TheAbsentOne: No, I think what you have there looks right.  As long as you're not directly accessing to_publish or received in your charm layer, then you're respecting the encapsulation and future-proofing yourself to allow for the interface layer to evolve.
<cory_fu> TheAbsentOne: And in general, if you need to pass data around, like with your share_details, then it needs to be a method like that and not just a flag, since flags can't pass data.
<cory_fu> TheAbsentOne: However, in https://github.com/Ciberth/generic-database-layer/blob/master/provides.py#L19-L26 you're basically saying that every connected application will always be sent the same relation data; if an application is related and requests mysql, and then another application is related and requests pgsql, the loop will overwrite the mysql data on the first relation with the pgsql data.
<cory_fu> You should probably add something like "if relation.joined_units['technology'] == technology: continue" to the start of the loop
<cory_fu> And also make https://github.com/Ciberth/generic-database-layer/blob/master/provides.py#L11-L14 loop over the relations and check the technology on each one, since they could be different for different relations
<TheAbsentOne> cory_fu: thanks for the input, but each generic-database should only receive a request once! This means that if a new consumer-app connects he should receive the same connection details. On the other hand the same consumer-app should be able to connect to multiple generic-databases though
<TheAbsentOne> cory_fu: could you tell me how I can pass a flag? I kinda want to set a flag in my generic-database and when he is set the same flag should be set in my consumer-app? This: https://www.dropbox.com/s/n27pznx2ms3ew4d/temphandlerquestion.png?dl=0 doesn't make sense right?
<cory_fu> TheAbsentOne: Why make that restriction, though?  Why not allow both wordpress and django to connect to the same generic-database, with one requesting mysql and the other pgsql?
<cory_fu> Granted, any pgsql connections would end up sharing the same db, since I don't think it supports a named db relation...
<TheAbsentOne> cory_fu: because the version of this generic-database charm assumes that 1 charm represents only 1 database if you need 2 you need a second charm/unit
<TheAbsentOne> so wordpress and django are allowed to connect to the same generic-database but it will only be 1 database with 1 technology, 1 connectionstring
<TheAbsentOne> the idea behind this approach is that I want an entity as small as possible, and we can add layers on top of it if we want what you suggested!
<cory_fu> TheAbsentOne: Ok, if that's how you're designing it, then disregard my comments.  :)  As for the flag question, you're right that flags are local to the unit they are set on.  If you want a flag to be set on the other side of the relation, it needs to be driven by some bit of relation data and set by the (in this case) requires side of the interface layer.
<cory_fu> Fair enough.  :)
<cory_fu> TheAbsentOne: Does that make sense about the flag?
<TheAbsentOne> cory_fu: so for example in the requires.py I can do @when('generic-database.changed.port') set_flag('myflag')
<cory_fu> Yep
<TheAbsentOne> cory_fu: No I think not x) I'm making stupid mistakes again. The thing is I want to react in my consumer-app as soon as this function is finished https://github.com/Ciberth/generic-database/blob/master/reactive/generic-database.py#L37
<TheAbsentOne> so in other words my generic-database knows the data (connectionstring), I now want to pass the data to the consumer-app
<cory_fu> TheAbsentOne: Right, but that data has to get to the consumer-app over via the relation data, which you're already doing with share_details.  Then you just have to add something on the requires side that observes that that data is now available and sets the flag accordingly.  From the consumer-app charm's perspective, it will be the same: as soon as the data is available on the consumer-app machine, the flag will be set and the charm can react to it
<TheAbsentOne> cory_fu: I had the flag @when('generic-database.postgresql.available') render config file so it was this flag that I wanted to set in my requires
<TheAbsentOne> allright I'll try it out in a bit and I come back to you thanks already cory_fu!
<cory_fu> TheAbsentOne: No problem!  :)
<[Kid]> how do you guys normally do a juju/MAAS controller? Do you just have a small footprint machine to run the commands from/
<[Kid]> for example, if i have 6 machines I want to put into a compute cluster for Openstack and I want to use juju and MAAS to deploy it, i don't want to chew up one of those machines to install juju and MAAS on to deploy to the others
<[Kid]> i mean, i thought as crazy as making my MAAS and juju roles being on a raspberry pi
<[Kid]> or maybe it is good to have a lxd container for these roles.
<pmatulis> [Kid], no, if those 6 are beastly then don't dedicate one of them to the MAAS server & the Juju client
<pmatulis> [Kid], you'll need to find a mediocre system for those. maas docs have hardware requirements for the server
<pmatulis> [Kid], the harder part will be finding a suitable system in the MAAS cluster to dedicate to the Juju controller. best find yet another mediocre system for that and make it a MAAS node
<pmatulis> you can then target that system (usually via a MAAS 'tag') when creating the controller (`juju bootstrap`)
<rick_h_> [Kid]: yea, I actually run maas on an old laptop for my 8nuc cluster. I do end up using one to bootstrap to, but might also use that to run a workload if I have to. The main thing is if the openstack is important how HA are things going to be/etc
<bobeo> [Kid]: Also remember that you can deploy a modest additional maas box to swap out the original maas system if you overallocated hardware to the initial maas box by building an addtional maas box
<cory_fu> tinwood: Were you working on https://github.com/juju/charm-tools/pull/397/ by chance?
<tinwood> I'm certainly looking at it.  I'm not sure what's going on though (I've only just got to it).
<tinwood> cory_fu, ^^
<cory_fu> tinwood: I think the issue is here: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/python.py#L373-L390
 * tinwood is looking
<cory_fu> But I also think I might have a workaround.  I just found the override-stage option
<cory_fu> tinwood: https://docs.snapcraft.io/build-snaps/scriptlets#overriding-the-stage-step
<cory_fu> Trying it now
<tinwood> kk
<bobeo> so ive got graylog installed, configured via rsyslog, I set the daemon to send it via tcp via /etc/rsyslog.conf, and I bounced the rsyslog service on an ubuntu server. in addition, I also added an input for syslog tcp in graylog, but im not receiving any logs. any ideas?
<zeestrat> [Kid]: Small physical host for maas controller then a couple of kvm's on the same host as juju controller. No HA but decently small footprint
<jam> manadart: so whatever patch you *just* landed on develop broke the lxd test suite on bionic.
<jam> I was trying to reproduce a failure but it wasn't failing, and then I updated by bionic branch and it started failing and the last commit is: lxd-remove-client-config
<cory_fu> tinwood: I had to use override-prime, but it did work.  Hit another unicode error in charm build, but that's easy enough to sort out
<jam> http://10.125.0.2038080/job/RunUnittests-amd64-bionic/11/testReport/github/com_juju_juju_provider_lxd/TestPackage/
<bobeo> so ive got graylog installed, configured via rsyslog, I set the daemon to send it via tcp via /etc/rsyslog.conf, and I bounced the rsyslog service on an ubuntu server. in addition, I also added an input for syslog tcp in graylog, but im not receiving any logs. any ideas?
<manadart> Jam: That landed this morning. I will take a look.
<bobeo> as an update, I can now see data loading in inputs, but its not showing anything in searches or extractors
<[Kid]> pmatulis, got your info, that's kind of what i thought
<[Kid]> pmatulis, you think a pi might work for the juju controller/client and the MAAS server?
<[Kid]> or maas controller
<admcleod_> hi guys
<admcleod_> any update on when 2.3.8 will be the stable snap?
<rick_h_> admcleod_: we're currently working on the 2.4beta2 and after that will do the 2.3.8. Our goal is to get it out before your Tues release of stable charms
<sfeole> beisner, ^^
<jam> manadart: i was able to reproduce it with a checkout of develop on bionic and TestOpen started failing. I'll see if I just pop off your change if it passes, give me a sec
<pmatulis> [Kid], i'm not sure, you will have to compare specs - https://docs.maas.io/2.3/en/#minimum-requirements
<tinwood> cory_fu, excellent; are you pushing to the same PR?
<cory_fu> tinwood: I can't push to your fork
<tinwood> I thought I'd picked up all the py3 isms.
<bobeo> anyoen have any connections to the graylog project for a warm intro? Im trying to fix a weird issue with graylog via juju install
<tinwood> cory_fu, really?  I'm sure I ticked the box ... let me check.
<bobeo> somehow I have 12kb of log data into a system, but no data?
<cory_fu> tinwood: Ticked the box?  Hrm.  Maybe I can, I didn't actually try
<tinwood> cory_fu, tbh, I don't know if it actually works; but I did tick "let maintainers push to this ..."
<jam> manadart: nope, still fails, was something earlier than the last change
<tinwood> So I'm hoping it does!
<admcleod_> rick_h_: thanks
<[Kid]> pmatulis, yeah a Pi isn't enough.
<[Kid]> i need to get a cheap rack mount to host that
<[Kid]> then i can put all the simple roles on it
<cory_fu> tinwood: Oh yeah, it worked!  :)
<cory_fu> tinwood: https://github.com/juju/charm-tools/pull/397/commits/5a391458d452c93a40af3b7ec5fee481a052dd53
<tinwood> even more excellent!
<jam> manadart: ugh... it failed, it failed again, and just now it passed on upstream/develop
<tinwood> cory_fu, thanks also for taking a look at it and pushing it on.  I started this branch over Xmas break when i was a bit bored!
<manadart> jam: I was looking at the PR. Hard to see how that would be it. I'll look at my priors. The fix to run init on Bionic.
<cory_fu> tinwood: So, that works in the snap, but there's some discussion happening about getting the deb package for xenial updated and I'm not sure if these changes will cause any issues in the deb package or not
<manadart> jam: great*
<jam> manadart: methinks there is some sort of race condition.
<jam> manadart: and/or the fact that we are mutating host machine state is *not* conducive to working correctly all the time
<cory_fu> tinwood: Oh, I thought it was because you were hitting some issue that needed Py3 support.  Ah well, into the future!
<tinwood> cory_fu, It should be py2+py3?  At least the tests passed.
<tinwood> cory_fu, yeah, that's what resurrected it!
<jam> manadart: example, it only works after it has failed once, which always passes for humans, but never for bots :)
<tinwood> cory_fu, what we need in openstack is py3 charm-list and build as we're going py3.
<tinwood> So it suddenly became an issue again.
<tinwood> So, yes, definitely needed.
<cory_fu> tinwood: Yeah, it should be py2 compatible still, but I'm not sure if the pip bundling behavior was needed in the deb package.  TBH, I'm not even sure if it ever worked in the deb package, though, because the deb package is quite out of date
<cory_fu> Ah, good to know it's needed
<tinwood> :)
<jam> manadart: if I "lxc network delete lxdbr0" the test suite fails
<cory_fu> tinwood: I seem to have broken the tests
<tinwood> ah
<jam> manadart: /me really doesn't want us to depend on having "lxd init" run on the host prior to running the test suite. *any* test *mutating* a local LXD is bad mojo.
<manadart> jam: we shouldn't be using the real deal for my money. GoMock.
<jam> manadart: definitely
<jam> manadart: 8691 passed the test suite now. are you ok with it landing ?
<manadart> jam: yes. I am about transit for 90 mins or so. Will look at those tests when I can sit down with the laptop.
<manadart> About *to* transit. Will be working en route.
<TheAbsentOne> cory_fu are you still here? Can I borrow your eyes for a minute once again?
<cory_fu> TheAbsentOne: Yep
<TheAbsentOne> https://github.com/Ciberth/consumer-app/blob/master/reactive/consumer-app.py#L59 <-- pgsql here seems to be empty when I look at my rendered file
<TheAbsentOne> https://github.com/Ciberth/generic-database-layer/blob/master/requires.py#L10 is the requires
<TheAbsentOne> but shouldn't I return an object as a whole?
<TheAbsentOne> as a side note question cory_fu is it the convention to use 'endpoint.{endpoint_name}.changed' but with fields: '{endpoint_name}.field' or what is the best-practice in naming convention according to you?
<cory_fu> TheAbsentOne: 'endpoint.{endpoint_name}.changed' and 'endpoint.{endpoint_name}.changed.<field-name>' are set automatically by the framework.  You can document that you use those in your interface layer, or you can translate them into other flags that you have more control over if you want.  When converting interface layers from the older style, it's common to translate them to '{endpoint_name}.changed' or similiar, because the old convention didn't
<cory_fu> include a prefix (which did lead to some confusion if the charm name and endpoint name were the same)
<TheAbsentOne> ah I see, I was unsure if I should use 'endpoint.{endpoint_name}' or '{endpoint_name}' in my case but it doesn't really matter I guess cory_fu
<cory_fu> TheAbsentOne: "details" in your requires layer isn't a valid field name.  You probably want to use 'endpoint.{endpoint_name}.changed' and then check one of your attributes (e.g., technology) and if that's set, then set the available flag
<cory_fu> No, it doesn't really matter.  It's just a convention.  I like to make the flag names more explicit to avoid confusion, but it does require more typing.  *shrug*
<TheAbsentOne> cory_fu: and what do I return? Can I still return the details dictionary?
<cory_fu> TheAbsentOne: Oh, I misread your code there.  I see that you moved everything under a single "details" key, in which case your check is correct but you need to update the accessors
<cory_fu> Handlers shouldn't (and can't, really) return anything.  The return value is ignored.  You should set the flag, and then the charm code can react to the flag, as you have done, and use the accessors to get the relevant data.
<TheAbsentOne> yeah I thought that would be better so less flags are set
<TheAbsentOne> so what do you mean by updating the accessors cory_fu what am I missing in my requires?
<cory_fu> You could also have a single accessor that returns the whole "details" data structure, but you should be a bit careful there as you're leaking details about the communication protocol that might be better being encapsulated
<cory_fu> TheAbsentOne: https://github.com/Ciberth/generic-database-layer/blob/master/requires.py#L26 should be "return self.all_joined_units.received['details']['dbname']
<cory_fu> "
<TheAbsentOne> ahn right ofcourse
<cory_fu> That's probably why you're seeing None values in your handler in your charm
<TheAbsentOne> exactly
<TheAbsentOne> so what do you think, still use the details way or use 6 flags instead
<TheAbsentOne> cory_fu
<TheAbsentOne> so instead of changed.details flag a when() with changed.port, changed.user, changed.dbname... all in one when
<cory_fu> TheAbsentOne: You can use a single flag and a non-nested data structure, or you can nest the data structure and just update your accessors, it doesn't really matter, it's just up to you when creating the interface protocol
<cory_fu> If you want to use a non-nested data structure, you could use @when('endpoint.{endpoint_name}.changed') with an if check inside the handler to verify the value(s) are set, or @when('endpoint.{endpoint_name}.changed.technology') and leave off the other flags because you expect them to be all set together.
<cory_fu> I usually do the former, but it really is just up to you
<TheAbsentOne> right I'll update it so you can review
<cory_fu> kk
<TheAbsentOne> Ohn and 1 more question, right now my request functions goes over all relations. But in reality my request is only meant for 1 generic-database. How can I achieve that? If you add-relations manually there will always be a first one but if I would create a bundle I don't know if this might give conflicts.
<TheAbsentOne> cory_fu: so like this right? https://github.com/Ciberth/generic-database-layer/blob/master/requires.py#L10
<cory_fu> TheAbsentOne: So, you want the client to be able to connect to multiple generic-databases on a single relation endpoint?  Your requires class would need to provide some way for the charm layer to distinguish them, like assigning each one an ID (or re-using the relation.relation_id, but take care to document that it is an "opaque" ID so that charms don't start depending on the specific value).  But it might be better to say that if a charm wants to
<cory_fu> use multiple generic-databases, then it should probably use a separate relation endpoint name for each one so that it knows which is which
<cory_fu> TheAbsentOne: And yes, that update looks good, assuming you also update the provides side to not publish the nested structure
<cory_fu> TheAbsentOne: i.e., undo this bit: https://github.com/Ciberth/generic-database-layer/blob/master/provides.py#L38
<TheAbsentOne> yes absolutely I completely forgot about that, they should just use multiple generic-databases in their metadata
<cory_fu> Yep.  :)
<TheAbsentOne> cory_fu: oh right, uncomment all these lines right, or what do you mean? I still have to fill the details dict no?
<cory_fu> TheAbsentOne: No, you don't need the nested structure any more.  Can revert back to this: https://gist.github.com/johnsca/038c34657b2ee59f47c79f8443f4cf2e
<TheAbsentOne> wait now I'm confused, in my requires I thought I was still using the nested structure
<cory_fu> TheAbsentOne: Oh, now I'm confused.  It seems that you went in both directions in your requires, and I missed it
<TheAbsentOne> ow wait but I shouldn't xD I'm gonna change the all_joined_units.received['details']['...'] back to all_joined_units.received['...'] and try that
<TheAbsentOne> yeah my bad cory_fu xD
<cory_fu> TheAbsentOne: Ok, so leave provides.py alone, and change https://github.com/Ciberth/generic-database-layer/blob/master/requires.py#L12 to juse "if self.technology():"
<TheAbsentOne> gimme a sec
<cory_fu> *just
<TheAbsentOne> or yes thats even better
<cory_fu> :)
<TheAbsentOne> haha damn I'm retarded
<TheAbsentOne> it feels like since I started writing charms I completely forgot how to program o.O
<cory_fu> Creating interface layers requires a certain type of thinking and can be pretty confusing at first.  I keep meaning to create a tutorial on tutorials.ubuntu.com walking through one but never seem to find the time
<TheAbsentOne> Well if you are up to it I want to help with it with my use case here. I'll start it and maybe you can review it and publish it if you would want that cory_fu
<cory_fu> TheAbsentOne: Yeah, I'd be happy to collaborate on a tutorial
<TheAbsentOne> As soon as I get this to work, I'll work on it and get back to you as it would help me a lot too, having you review the code would be awesome
<TheAbsentOne> thanks again for the help before cory_fu gonna deploy my charms ^^
<cory_fu> TheAbsentOne: \o/  Good luck!  :)
<bdx> jujucharms.com is down
<bdx> awe sits back
<rick_h_> bdx: wfm? /me tries more urls
<TheAbsentOne> everything works fine from my end
<bdx> hmm yeah its back for me now
<bobeo> must have been a slight outage wile things rebooted?
<bobeo> not sure o.O
<bdx> although multiple users hit it in different areas of the globe
<bdx> yeah strange
<bobeo> may be geo to me
<rick_h_> I'll keep an eye out but nothing flipped in nagios/etc
<TheAbsentOne> cory_fu I missed something; I get a nonetype not subscriptable error; I'm gonna try it without the nested structure
<cory_fu> TheAbsentOne: I know what the issue is.  Moving away from the nested structure will help, but if you're unsure and curious, I can explain what's happening
<cory_fu> (Obviously, I missed it before, too)
<TheAbsentOne> oh go ahead, love to learn cory_fu
<cory_fu> TheAbsentOne: :)  So, the .changed flag is going to be set pretty early due to some implicit and automatic data that juju sets (specifically, private-address).  But the "details" structure won't be in there yet.  However, the technology() accessor assumes that it's there and tries to subscript it, which leads to the NoneType error.  To fix it with the nested structure, the accessors would all need to include an "if 'details' in self.all_joined_units
<cory_fu> .received" check
<cory_fu> TheAbsentOne: I think moving away from the nested structure will be easier.  And it will also be easier if you ever need to debug this by viewing the relation data directly (with, e.g., juju run --unit unit/0 -- relation-get -r rel:id - other-unit/0)
<TheAbsentOne> cory_fu: right I get it makes sense thanks for that, I didn't know private-address happens before everything
<TheAbsentOne> I changed requires and provides correctly now I think, could you give it another quick look: https://github.com/Ciberth/generic-database-layer/blob/master/provides.py
<cory_fu> TheAbsentOne: I would keep https://github.com/Ciberth/generic-database-layer/blob/master/requires.py#L12 as "if self.technology():" instead just because then you only have one place where that key has to be correct, rather than two
<cory_fu> But other than that, it looks great
<TheAbsentOne> allright perfect ill change that
<TheAbsentOne> works like charm x) cory_fu thanks a lot!
<TheAbsentOne> you made my day
<cory_fu> TheAbsentOne: Glad I could help!
<bobeo> how do I switch back and forth between local juju controllers and jaas?
<rick_h_> bobeo: juju controllers
<rick_h_> will show you the different controllers
<rick_h_> bobeo: and you can use `juju switch jaas`
<rick_h_> to switch
<bobeo> rick_h_: I can see my controllers, but how do I move from one controller to another?
<bobeo> ooo!
<rick_h_> bobeo: and you can specify what model in those controllers with `juju switch controller:model`
<rick_h_> bobeo: as optional more specific values
<rick_h_> bobeo: so watch out naming your models the same as a controller or it might get confusing :)
<TheAbsentOne> rick_h_ is there a way to pass entire files over a relation or do I need to read the contents of the file and pass it as a variable?
<rick_h_> TheAbsentOne: yea, have to pass contents or put them in a common place like a s3 bucket or something
<rick_h_> TheAbsentOne: the relation data is meant to be a databag, sending whole files is kind of a bit much
<TheAbsentOne> allright thx rick_h_ the idea is a .sql file for example
<rick_h_> TheAbsentOne: right, but if you have a connection why not just run the file as the client?
<TheAbsentOne> rick_h_: because the client needs to install packages/stuff to make that happen but you are right though ;) it was a showerthought
<blahrus_> anyone used conjure-up for OpenStack yet?
<rick_h_> blahrus: bunch of folks have used it. What's up?
<rick_h_> (and by bunch of folks I'm not included heh)
<blahrus> rick_h_, just trying to understand the networking requirements going into.
<blahrus> eno0 is for PXE/MAAS network - Then we have vlan100 - vlan103 on the remaining 3 ports
<rick_h_> blahrus: hmm, so not sure how much conjure up walks through on the binding of apps to the various vlans bit.
<rick_h_> beisner: do you all have any person run through of conjure up with > flat networks
<blahrus> rick_h_, everything is on the same switch stack and the only IPs that are routed are the publicly accessible IPs
<blahrus> rick_h_, Looks like conjure wants to setup bridges (which is fine) but I not sure what needs setup in MAAS before hand then
<beisner> rick_h_: i think the conjure-up openstack use case is indeed just a simple network.
<rick_h_> beisner: k, yea I wasn't sure how much customizing it let you do
<blahrus> simple network = everything in the same vlan?
<rick_h_> blahrus: so typically you want to setup different network spaces in MAAS, and then you can get Juju to map the traffic patterns you need onto those spaces with Juju commands during the deploy and setup.
<rick_h_> blahrus: this is a little old but has the idea: https://insights.ubuntu.com/2016/01/21/introduction-deploying-openstack-on-maas-1-9-with-juju
<blahrus> rick_h_, thanks! I'll check it out
<blahrus> beisner, would that be everything running over eno1 ?
<blahrus> no vlans?
<blahrus> trying to make sense of step 5: https://www.ubuntu.com/download/cloud/build-openstack
<veebers> Morning all o/
<bdx> blahrus: what has helped me in the past is to just forget about the multiple nets at first
<bdx> get it all deployed on a single flat network
<bdx> once you have that working, then try adding/diversifying the base networks etc etc
<blahrus> bdx: got it, you use conjure to do that?
<bdx> yeah, you definitely can
<bdx> blahrus: you can also create your own bundles and `juju deploy` them
<bdx> blahrus: 3 most recent gists here https://gist.github.com/jamesbeedy
<bdx> are 3 recent tutorials on basic openstack deploys
<bdx> have at it
<bdx> there are a few configs to swap out in the bundle if you wanted to make it work on your own env
<bdx> but, hopefully you get the idea
<blahrus> bdx: Minimal VLAN + External might prove very very helpful
<blahrus> thanks!
<bdx> np
<thumper> morning team
<babbageclunk> morning!
#juju 2018-05-11
<thumper> babbageclunk: ping
<thumper> anastasiamac: ping
<anastasiamac> thumper: ?
<thumper> anastasiamac: quick review? https://github.com/juju/bundlechanges/pull/38
<anastasiamac> thumper: sure, can i trade u for this one https://github.com/juju/juju/pull/8692?
<thumper> sure
<thumper> approved
 * anastasiamac still looking  :)
<babbageclunk> thumper: oops looks like I'm too late?
<thumper> babbageclunk: slacker
<thumper> babbageclunk: yeah, I think anastasiamac has it in hand
<thumper> babbageclunk: although, if you like, you can do the next one: https://github.com/juju/juju/pull/8692#pullrequestreview-119300874
<anastasiamac> thumper: approved too :) m sure it was result of overthingking ;) and anticipating
<thumper> no, that's not it
<thumper> babbageclunk: https://github.com/juju/juju/pull/8693
<babbageclunk> ok, I'll look after this one from kelvinliu_
<thumper> anastasiamac: yeah, while testing the pr that babbageclunk is going to look at, I realised the mistake I made
<thumper> so going back to fix the mistake,
<thumper> then update the juju PR with the new bundlechanges
<anastasiamac> :) yeah, that was the difficulty - to get all the permutations right: u have the machines and user specified placement; u have machines but user did not specify placement (or specified different placement); and the equivalent for it when u don't have machines... :)
<anastasiamac> thumper: thnx for doing the hard work - thinking ;)
<thumper> :)
<thumper> it makes a change...
<babbageclunk> thumper: approved
<anastasiamac> veebers: trying to merge a PR and it failed with godeps? http://ci.jujucharms.com/job/github-merge-juju/435/console
<anastasiamac> shall i just re-try?
 * veebers looks
<anastasiamac> veebers: fwiw, it was just a helpdoc text, so no deps were touched...
<veebers> anastasiamac: odd failed n "fatal: unable to access 'https://gopkg.in/retry.v1/': Could not resolve host: gopkg.in" let me have a look
<anastasiamac> veebers: k, while u look, i'll re-try :)
<veebers> anastasiamac: don't retry
<veebers> anastasiamac: I'm looking why it can't hit that host :-)
<anastasiamac> veebers: k
<anastasiamac> veebers: the check suceeded tho, only merge failed on that PR...
<veebers> anastasiamac: yep, the host that runs the merge/check is having trouble hitting that url, so any other attempt will fail
<anastasiamac> veebers: ack
 * anastasiamac waits for green light from veebers before hitting the big red button
<veebers> anastasiamac: huh maybe it can hit it at the moment, might have been a hiccup at the time? not sure will follow up with IS.
<veebers> anastasiamac: I did take a momement to fix the script so it checks the error code properly, so we should see "2 unknown command" in the output now ^_^
<veebers> anastasiamac: feel free to re-try a run
<anastasiamac> veebers: ta
<thumper> babbageclunk: thanks... but I have found another problem
 * thumper sighs
<veebers> anastasiamac: any joy?
<magicaltrout> hello folks
<magicaltrout> juju manual deployment
<magicaltrout> we've juju add-user'd
<magicaltrout> but juju ssh fails
<magicaltrout> with permission denied
<magicaltrout> even though keys are added and
<magicaltrout> ssh ubuntu@<server> works
<magicaltrout> https://asciinema.org/a/n3TN4kTmH59dZQ8fWMKA2Yncx <- kjackal admcleod_ any ideas?
<kjackal> magicaltrout: could it be the shell of the user you are adding is not set to bash?
<magicaltrout> what are these words you are typing?
<kjackal> can you run any other command via ssh?
<magicaltrout> eh?
<kjackal> looking for docs
<kjackal> magicaltrout: ssh user1@server1 date
<kjackal> would this work?
<kjackal> actually I am not sure if that should work
<magicaltrout> well when you add-user whod does it try and authenticate as?
<magicaltrout> I assume it still tries to login to ubuntu@
<kjackal> can you make sure that in /etc/passwd the last field of the user you are trying to connect with is not /bin/nologin or /bin/false
<kjackal> looks like this: https://stackoverflow.com/questions/608533/ssh-to-debian-server-instantly-logs-out?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa
<kjackal> magicaltrout: ^
<magicaltrout> eh, you can see from the screenrecording that you can ssh into the box successfully
<magicaltrout> as ubuntu user
<magicaltrout> and from there I can do whatever I want
<magicaltrout> sudo -i etc
<magicaltrout> the ssh key for ubuntu@ is also my default ssh key so I don't really need to send the key i'm just making mirror what I tried with juju ssh
<kjackal> ah sorry did not read the "$ logout"
<kjackal> magicaltrout: I think there is a juju ssh-add-key or something... let me search for it
<magicaltrout> the juju ssh debug though tells me nothing about the ssh command its actually trying to run
<magicaltrout> yeah kjackal thats how our keys ended up in /home/ubuntu/.ssh/authorized_keys
<magicaltrout> thats all working
<magicaltrout> but when it tries to ssh its doing something wrong
<magicaltrout> but debug shows you f all
<magicaltrout> juju ssh 0 -i ~/key
<magicaltrout> should in theory at least pump in the correct key
<kjackal> the "juju ssh-keys" seems right to you?
<magicaltrout> yeah works fine
<magicaltrout> both mine and my colleagues keys got added to the ubuntu user
<magicaltrout> which is why we can manually ssh into any box in the juju cluster
<magicaltrout> juju ssh isn't really the problem
<magicaltrout> we can't
<magicaltrout> juju run stuff
<magicaltrout> and thats a pain in the balls
<kjackal> magicaltrout: so you got something deployed to the machine and you cannot juju run
<magicaltrout> I can't
<magicaltrout> nor can I ssh
<magicaltrout> or anything that requires any form of ssh access
<magicaltrout> https://github.com/juju/juju/blob/develop/cmd/juju/commands/ssh.go looking at this
<magicaltrout> you'd have thought
<magicaltrout> juju ssh ubuntu@0 -i ~/.ssh/id_rsa.pub
<magicaltrout> would work
<magicaltrout> becuase i've both told it the user and the key I want to use
<magicaltrout> which is no different to
<magicaltrout> ssh ubuntu@<ip> -i ~/.ssh/id_rsa.pub
<kjackal> juju run --all --debug -- hostname -f
<magicaltrout> but that still tells me permission denied
<magicaltrout> ERROR permission denied (unauthorized access)
<magicaltrout> 10:33:30 DEBUG cmd supercommand.go:459 error stack:
<magicaltrout> permission denied (unauthorized access)
<magicaltrout> github.com/juju/juju/rpc/client.go:149:
<magicaltrout> github.com/juju/juju/api/apiclient.go:924:
<magicaltrout> and clearly when i say .pub i'm lying
<magicaltrout> alos
<magicaltrout> also
<magicaltrout> if I look in the target servers auth.log
<magicaltrout> it doesn't even log a failed login attempt
<magicaltrout> amazeballs
<magicaltrout> just did the samething with a lxd local deploy kjackal
<magicaltrout> same shit happens
<magicaltrout> I was pondering whether tthe permission error is actually the fact the snap can't see the key?
<kjackal> which snap?
<kjackal> juju?
<magicaltrout> yeah
<kjackal> I think snaps cannot see hidden directories (starting with .)
<magicaltrout> jesus h christ
<magicaltrout> hmm
<magicaltrout> doesn't seem to make a difference
<magicaltrout> copying the key out
<magicaltrout> basically
<magicaltrout> juju ssh works for the admin user with the embedded key
<magicaltrout> but doesn't work for any add-user
<rick_h_> magicaltrout: so you added the user and then added their keys?
<rick_h_> magicaltrout: juju [add,import]-ssh-key
<magicaltrout> I did rick_h_
<magicaltrout> you can replicate this on lxd local
<magicaltrout> as 1 user bootstrap
<magicaltrout> then add another local user as a juju user
<magicaltrout> and then try and ssh post add-key as that other user
<magicaltrout> the admin ssh works
<magicaltrout> the other user doesn't
<rick_h_> magicaltrout: huh...ok. I was just using that the other day. I'll wonder if something broke
<magicaltrout> of course.... I'll caveat all of this with, it might just be my misunderstanding
<magicaltrout> rick_h_: for us its been broken for 6 months
<magicaltrout> which is why it might just be me :)
<rick_h_> magicaltrout: and the user has been granted access to the model with admin access?
<magicaltrout> yeah
<magicaltrout> juju status works
<magicaltrout> juju ssh/run doesn't
<rick_h_> magicaltrout: what's juju show-model have?
<magicaltrout> but ssh ubuntu@<machine> for the added user does work
<rick_h_> magicaltrout: and can you check the .ssh/authorized_keys to see if the key made it?
<rick_h_> magicaltrout: I guess and is this with import-ssh-key or add-ssh-key? (/me used import recently)
<magicaltrout> we know it made it in rick_h_
<magicaltrout> because you can manually ssh using the key you added
<rick_h_> oh...so the key made it to the machines?
<magicaltrout> yeah
<magicaltrout> https://pastebin.com/rZEfsuAs
<magicaltrout> we have the same issue on 2 laptops rick_h_ one Xenial one Bionic both with the snapped juju installed
<rick_h_> magicaltrout: k, I'm looking at the email you sent
<magicaltrout> ignore the fact i tried to pump in my public key ;)
<rick_h_> magicaltrout: is there a proxy or anything involved?
<magicaltrout> nope
<rick_h_> magicaltrout: the code from your tracebacks come out into code checking proxy details before any ssh stuff is run
<magicaltrout> rick_h_: the fact the same thing happens on lxd local suggests proxies are a red herring
<rick_h_> magicaltrout: yea, but looking at what's giving the permission denied error in that trace is https://github.com/juju/juju/blob/b47854c63ad6345ffd4642e3b22520b43068ef56/cmd/juju/commands/ssh_common.go#L256
<rick_h_> magicaltrout: k, will have to basically go the bug route and figure out wtf. I'm not sure at this point.
<magicaltrout> just checking/recording lxd local again as a reproduction path
<rick_h_> magicaltrout: check pm
<magicaltrout> rick_h_: https://asciinema.org/a/JIlCubAF7LBdg6cc86ZcKoBLU
<magicaltrout> there's a full LXD example
<rick_h_> wheeee
 * rick_h_ is watching the movie 
<rick_h_> oooohhhhhh
<rick_h_> superuser != model level access with all machines
<rick_h_> that's why even as superuser if you want to see all models you have to use --all
<rick_h_> try granting admin on the model directly
<rick_h_> magicaltrout: ^
<magicaltrout> oooh
<magicaltrout> there we go
<rick_h_> magicaltrout: yea, so superuser is kind of special. Just because you can do anything doesn't mean you want your keys on every machine in the controller and such
<rick_h_> magicaltrout: just like you don't want to see every model from every user on the controller
<rick_h_> magicaltrout: even though technically, you can gain access to them all as it's YOUR controller
<magicaltrout> brain melting... so superusers, whilst superusers don't actually posess any model level superpowers
<rick_h_> magicaltrout: it's kind of like sudo, technically you can `sudo dosomething` at any time
<rick_h_> magicaltrout: but as you run around the system you get access denied until you sudo
<magicaltrout> thanks rick_h_
<rick_h_> magicaltrout: it's a bit of a corner world, but kind of done for the controller admin's sanity
<rick_h_> magicaltrout: ty for the video, that helped
<magicaltrout> no probs rick_h_ thanks for that, hours of confusion solved in moments ;)
<rick_h_> magicaltrout: think on it and if you think Juju is doing the wrong thing let's chat.
<rick_h_> magicaltrout: clearly we can error better at the minimum
<rick_h_> but I'm nervous about making it "just work" though
<magicaltrout> no i get the ethos behind it, there could possibly do with some more info in the --help output or something because its not obvious
<bobeo> o/
<bobeo> hey magicaltrout Im having issues registering to a controller, can you provide me a sample command for registering to one?
<bobeo> i tried juju register <controllerIP> as well as juju register <controllerName>
<rick_h_> bobeo: so there's a command that gets created you have to use that has some auth/security bits baked into it
 * rick_h_ wonders if we ever got around to that bug that you couldn't re-get the register command
<TheAbsentOne> is the postgresql charm author in this irc by any chance?
<rick_h_> TheAbsentOne: sometimes, but he's in APAC region so timezones is a bit off usually
<rick_h_> TheAbsentOne: best thing is to file bugs or something. What are you looking for?
<rick_h_> or maybe the mailing list, async coms ftw
<TheAbsentOne> ah I see, you know his name? rick_h_
<rick_h_> stub: is our pgsql charm hero
<TheAbsentOne> rick_h_ not really a bug. You see I created a charm that acts as a proxy and all data (connection details for postgres) are shared nicely BUT it is my proxy charm that is the one who requests this database. So in the auth file of postrges he is allowed but my real "consumer" isn't. I'm looking for a way to make sure both my consumer and proxy charm are both inserted in the auth file
<rick_h_> TheAbsentOne: hmmm, that's sticky. you might have to set config or something and set the config for the extra_hbaconf or whatever that config value is
<TheAbsentOne> the pgsql has a set_roles function which I'm looking into now but if that doesn't work out I have a big problem
<rick_h_> there's a config I know I've used to manually add in entries
<bobeo> rick_h_: can you share this magical command? o.O
<TheAbsentOne> rick_h_ could you explain it a bit more what you mean? I kinda don't want to edit the pgsql charm or interface
<rick_h_> TheAbsentOne: https://jujucharms.com/postgresql/#charm-config-extra_pg_conf
<rick_h_> bobeo: so when you run juju add-user it spits out a register command with some hashed bits around the ip, a security code, etc.
<rick_h_> bobeo: the command is meant to be sent to the user for them to use to register
<TheAbsentOne> rick_h_: hey that might work thanks man
<bobeo> rick_h_: how do I generate that? Also, I have a user that exists on the controller already, I need to access the controller itself
<rick_h_> bobeo: and prevents just general brute force hacking against the register call since you'll never have the right bits
<rick_h_> bobeo: run juju add-user xxxx
<rick_h_> bobeo: right, so I tend to create users when I connect from a diff machine to be honest. We've not setup a good way to dump/import the config bits into the .local/share/juju/...
<TheAbsentOne> argh I don't think it will work rick_h_ it's only for postgres specific options, not for the host authentication
<rick_h_> TheAbsentOne: right, but this config allows you to add the user/ip address allowed to connect
<TheAbsentOne> but there is another one: extra_pg_auth <-- this might work
<rick_h_> TheAbsentOne: that's the one I linked to
<rick_h_> oh, sorry
<bobeo> rick_h_:  just to confrim, to grant privs, its juju grant <username> --controller <controllername> super-user correct?
<rick_h_> TheAbsentOne: actually my bad, that's the one I MEANT to link to
<TheAbsentOne> rick_h_: my bad in not looking but thanks man ^^
<rick_h_> bobeo: correct
<bobeo> rick_h_: its not working x...x
<rick_h_> bobeo: oh sorry, superuser
<rick_h_> bobeo: one work, no dash
<rick_h_> one word
<bobeo> rick_h_: ok, so i am losing my mind
<bobeo> rick_h_: its taking so long to load :(
<rick_h_> bobeo: sorry, I'm jumping around too much.
<bobeo> process? whats te correct term there? does it load, or "process" a command query?
<rick_h_> bobeo: what's taking long to load? the grant command?
<bobeo> because technically you load it ot the controlelr before it runs
<bobeo> yea the grantocmmand rick_h_
<bobeo> it keeps hanging
<rick_h_> bobeo: k, try with --debug to see if you can get a hint on what's hanging
<rick_h_> bobeo: usually that's pretty darn fast as long as the client can reach the controller IP
<bobeo> rick_h_: its a lan communication
<rick_h_> bobeo: https://docs.jujucharms.com/2.3/en/tut-users is the short tutorial on the sharing/access stuff if you've not peeked yet
<bobeo> rick_h_: im an idiot. forgive me, for surely my caffiene hasnt made it to work yet
<bobeo> was trying to send it to a non-existant controller
<rick_h_> bobeo: ooooohhhh, yea that'll wait a while and make itself a sandwhich waiting for a timeout
<TheAbsentOne> rick_h_ is it okay to fill an option from within a charm? Is there a best-practice for this, how do you actually do that?
<bobeo> rick_h_: so I have access to the correct controller now, with login privs, but I dont see the models
<rick_h_> TheAbsentOne: heh not usually because the charms don't normally get to change config on other charms
<rick_h_> bobeo: right, so because you're superuser you don't see all models by default, only those shared with you directly
<rick_h_> bobeo: run `juju models --all`
<rick_h_> bobeo: and if you want to have them be "my models" you can grant yourself admin privs on them
<rick_h_> bobeo: so that admins don't get a super long list of all models from all users on the controller all the time, and can mange their own list of stuff they work on directly
<TheAbsentOne> richt thought so x) welp
<TheAbsentOne> right*
<manadart> I have borked something. "lxc list" hangs and Juju can not contact my LXD controllers.
<rick_h_> magicaltrout: try lxc list with -v
<rick_h_> err manadart ^
 * rick_h_ can't type today evidently...when did monday get here
<manadart> rick_h_: Also hanging with no output...
<aceng> Hello anyone know if I used the same physical server to install nova controller and keystone why the keystone configuration get overwritten when the nova relations is complete.  Do I have to install with separate containers to prevent this?
<rick_h_> break all the things! manadart so searching around finds various bugs/debugging tracks with lxc-monitord and such causing hangs that involve a bunch of killing of things and getting them to restart.
<bdx> aceng: try keystone in a container, nova-compute on the host to work around this when using a single machine
<manadart> There's a beer in my fridge whispering "Leave it till Monday" seductively to me :)
<aceng> okay I guess there is no workaround to preserve the apache and haproxy config when each relation is updating.
<rick_h_> manadart: lol, sounds like good advice
<rick_h_> manadart: listen to the beer
<manadart> rick_h_: You're the boss.
<rick_h_> manadart: :) have a good weekend
<stub> TheAbsentOne: You might want to look at the pgbouncer charm, which is not nice, but does something similar. It uses an administrative connection to PostgreSQL so it can create its own users.
<stub> TheAbsentOne: The trick is that if your proxy uses the db-admin relation to PostgreSQL, it is allowed to connect to any database as any user.
<stub> TheAbsentOne: Its the only way I can see it working with the current charm; there is no protocol for a client charm to get the PostgreSQL service to do complex config changes like insert entries into pg_hba.conf
<stub> Using the extra_ charm config options on the PostgreSQL charm would work, but is a poor UI since the operator has to set the config options to the magic values rather than the client charm handle it automatically.
<TheAbsentOne> hi stub, thanks for the feedback. Currently I used the db instead of db-admin relation actually, maybe I should try first but I don't think it will make a lot of difference. The point is that my proxy itself doesn't care to connect to postgresql it's the consumer of my proxy that needs to do this.
<TheAbsentOne> I will take a look at pgbouncer!
<TheAbsentOne> But it's idd a problem that I need to perform this manual option config step
<stub> If is just a broker rather than an actual proxy, you may be stuck with the PostgreSQL charm config.
<stub> Because as you have found, the IP address will be denied access and you can't request it to be opened.
<stub> The feature would need to be added.
<stub> (It used to be possible to lie about your IP address, but the newer networking stuff thankfully removed that hack)
<TheAbsentOne> yeah it needs the entry in the pg_hba.conf file to connect properly then I can connect with adminer idd stub
<TheAbsentOne> stub: wouldn't it be a possibility to add an optional parameter to the set_database function that takes a list of hosts that also gain access to the database?
<TheAbsentOne> I think if that feature got implemented the problem is solved
<stub> Yes, it would be possible to add that feature. A comma separated list of CIDRs. It wouldn't work cross-model, since the client won't know what IP address the server will see.
<stub> It needs a good hard think, to be sure it doesn't open any security escalation issues. Gut feeling says it is ok.
<TheAbsentOne> not sure if I understand why it wouldn't work cross-model, but if works and is fine within the same model it would already be a huge and interesting thing, give it a thought stub ;)
<TheAbsentOne> I can only pray hehe, it kinda sucks I have to request it though, it was kinda a requirement for me to use existing charms without modification.
<stub> It would probably work out of the box if you connected to pgbouncer instead of postgresql. pgbouncer handles its authorization differently, and doesn't restrict by IP address
<stub> And you want pgbouncer in any non-trivial production deploys anyway
<TheAbsentOne> allright interesting, I will look into that stub
<roadmr> hey juju friends
<roadmr> I have a sick juju env, this appears in logs for all services : INFO juju.worker.dependency engine.go:352 "uniter" manifold worker stopped: failed to initialize uniter for "$SOME_UNIT" : cannot create relations: tomb: dying. How can I fix this?
<bobeo_> o/
<bobeo_> o/
<bobeo_> anyone on got any experience with graylog? im digging through it right now and having issues.
<kwmonroe> hey bobeo_, i have experience with the graylog charm. what's going on?
#juju 2018-05-12
<bobeo_> kwmonroe: honestly, im not sure. I went through a rebuild thanks to some help with bdx, so im hoping its resolved. Ill update very shortly, im checking out the new build now
<bobeo_> kwmonroe: ok so the update is Ive got rsyslog forwarding from....annnnd im an idiot
<bobeo_> ok, so just to clarify, I send the logs to graylog, not to elasticsearch correct?
<bobeo_> graylog is the logging server portion of graylog right? im not losing my mind here?
<bdx> any sad souls hanging around on a weekend want haproxy charm options parsing fixed see here https://code.launchpad.net/~jamesbeedy/charm-haproxy/options_newline/+merge/345463
<TheAbsentOne> do you ever stop working bdx? x)
<bdx> TheAbsentOne: ahah, I have to catch up on bugs I hit during the week and didn't have time to tend to
<bdx> either filing them or fixing or both
<TheAbsentOne> bdx much respect sir!
<TheAbsentOne> bdx: since you are here I can ask it, do you have experience with the pgbouncer charm?
<bdx> ahh .. I haven't used it for a few years, but yeah kindof
<bdx> looks like its actively maintained
<bdx> and has docs and stuff
<TheAbsentOne> I heard the pgbouncer charm would allow me to set multiple authentication hosts in the charm itself, but I don't really see how
<TheAbsentOne> gonna have a look at the code
<TheAbsentOne> bdx: correct me if I'm wrong but shouldn't an interface allow this instead of a charm?
<bdx> interfaces are really just for helping communicate information from one application to another ....
<bdx> take it as you will
<bdx> thats how I understand it
<TheAbsentOne> yeah exactly bdx
<TheAbsentOne> I fail to see how the bouncher charm would help me in adding an extre entry to the host auth file on the pgsql server
<bdx> ahh
<bdx> TheAbsentOne: Possibly because pgbouncer would be the one communicating with postgresql
<bdx> so you just communicate with pgbouncer at that point
<bdx> then postgresql only need a single entry in the pg_hba.conf for pgbouncer
<bdx> I could be entirely wrong, but I seem to remember something to that degree
<bdx> TheAbsentOne: https://gpdb.docs.pivotal.io/43180/admin_guide/access_db/topics/pgbouncer.html#pgb_config
<bdx> ^ something similar to that may be going on under the covers, I'm really not familiar enough to say
<TheAbsentOne> but can I request that in my charm using pgbouncer bdx?
<bdx> TheAbsentOne: I'm unsure what you are trying to do
<TheAbsentOne> yeah my bad I'll try to illustrate it: Assume I have a model with the postgresql charm and the pgbouncer charm deployed. Now assume that I have charm A that is a website that will access a postgres database and charm A is connect to charm B. The one connecting to (either postgresql or pgbouncer) is charm B however. This means that charm B is automatically configured in the host auth files but charm A's host is not allowed to conn
<TheAbsentOne> I want in charm B to write code that set's, "host A should be allowed to connect to the db as well"
<TheAbsentOne> does that makes sense bdx?
<bdx> yeah
<bdx> TheAbsentOne: what you are trying to do essentially is bypass part of the postgresql auth system
<bdx> do you understand that?
<TheAbsentOne> well not really I want to pass a config string that the postgresql charm needs to handle; as a matter of fact there is an option for that in the postgresql but this means manual interaction which I want to evade
<bdx> got it
<bdx> yeah, thats how I've always gotten around it
<TheAbsentOne> the postgresql charm does "something" (<-- add an entry in the host auth file) for the requesting charm. I want the postgresql charm to do the same thing but for a host that I pass instead
<bdx> setting extra_pg_auth
<bdx> totally
<TheAbsentOne> yep that works ok I guess
<TheAbsentOne> but it would be awesome if there was a function that would allow it in the pgsql interface, or an optional parameter in the set_database method that requests a db and makes everything happen
<bdx> "I want the postgresql charm to do the same thing but for a host that I pass instead" - got it, so just a custom entry to the pg_hba.conf
<bdx> totally
<bdx> I would make a feature request against the pgsql interface for that
<TheAbsentOne> I hope I can convince stub for something like that x) I can see it being usefull for others too
<bdx> yeah, if you make a feature request/bug for it post it here and I'l give it some heat for you
<bdx> I can see that being super handy
<TheAbsentOne> I talked about it though with stub it was he who said take a look at pgbouncer
<TheAbsentOne> The only problem is that I don't have a launchpad account and the pgsql interface is not hosted on github x)
<bdx> TheAbsentOne: sounds like you know what you need to do then :)
<TheAbsentOne> or is there another way to request it formally? bdx as I haven't used launchpad before
<bdx> yea, thats totally annoying, but people have the right to use what version control they please
<TheAbsentOne> totally bdx I'm creating an ubuntu one account as we speak
<bdx> TheAbsentOne: that will be useful for many things, charmstore, JAAS, etc etc etc
<bdx> but will also allow you to interact with the greater community too
<TheAbsentOne> Yeah thought so too but I hadn't the need for it so far. Could you point me where I can ask/feature request/issue on launchpad, it seems I'm blind
<TheAbsentOne> ahn wow was only look at the git....
<bdx> there should be a link on the charm webpage
<bdx> to "submit a bug"
<bdx> follow that and submit your feature request there
<TheAbsentOne> yeah found it, Ill just submit a bug idd, thanks for the help bdx
<bdx> np
<TheAbsentOne> It is done, back to writing x)
<bdx> TheAbsentOne: post it here
<TheAbsentOne> bdx: https://bugs.launchpad.net/interface-pgsql/+bug/1770885
<mup> Bug #1770885: add support for multiple host auth when requesting db <pgsql Interface for charms.reactive:New> <https://launchpad.net/bugs/1770885>
<bdx> TheAbsentOne: nice work
<TheAbsentOne> haha thanks, we'll see what happens and I hope it might help others too
<bdx> kwmonroe: https://github.com/jamesbeedy/charm-graylog/blob/endpoints/reactive/graylog.py#L479,L522 - getting close
<bdx> we will make this thing scale out and drop the apache2 bs here soon
<TheAbsentOne> nice code bdx I wish I had my eyes on things like that weeks ago!
<TheAbsentOne> I feel like I'm only startint to understand it right now and I feel stupid for it xD
<bdx> TheAbsentOne: its cool man, everyone has their own learning curve
<bdx> TheAbsentOne: fyi, I've been eyeing these changes for months
<bdx> still don't have it perfect, but I'm real close
<bdx> why I need a fe hours on the weekends to hack these types of things out
<TheAbsentOne> yeah it's very time consuming for some reason while it seems so little/easy at first
<bdx> ^ programming
<TheAbsentOne> basicly xD but still, I underestimated reactive programming very hard
<bdx> TheAbsentOne: its all relative :)
<bdx> last bug
<bdx> https://bugs.launchpad.net/charm-haproxy/+bug/1770890
<mup> Bug #1770890: haproxy should wait to write out a front end and backend until they are configured by relating service <charm-haproxy:New> <https://launchpad.net/bugs/1770890>
<bdx> im off to get some sunshine now
<bdx> lates
<TheAbsentOne> bdx enjoy!
#juju 2018-05-13
<KingJ> One of my machines managed by MAAS has a HP RAID controller in it. Sadly, there's no HBA mode so each disk is a RAID0 array. However, this means that MAAS can't run smartctl-validate against the drives as the /dev/sdX entry doesn't support SMART.
<KingJ> Ach, wrong channel, sorry
<KingJ> Is there a way to put a custom certificate on the Juju API/GUI (2.4). Right now, i'm using the self-signed one and although I see there's an option to use LetsEncrypt to autogenerate a certificate I don't want to expose Juju to the internet and would prefer to use an interal CA.
<KingJ> Is an agent for 2.4-beta2 supposed to not exist? juju bootstrap is attempting to download https://streams.canonical.com/juju/tools/agent/2.4-beta2/juju-2.4-beta2-ubuntu-amd64.tgz but it doesn't exist - beta1 is the nearest.
<KingJ> I've logged https://bugs.launchpad.net/juju/+bug/1771001
<mup> Bug #1771001: Agent for 2.4-beta2 Missing <juju:New> <https://launchpad.net/bugs/1771001>
<thumper> veebers: morning
<thumper> veebers: could I get you to take a look at https://bugs.launchpad.net/juju/+bug/1771001 ?
<mup> Bug #1771001: Agent for 2.4-beta2 Missing <juju:New> <https://launchpad.net/bugs/1771001>
<thumper> looks like it could be fallout of the automation around releases
<veebers> thumper: yeah sure that doesn't seem good :-P
<thumper> thanks
<wallyworld> vino: i forgot to talk to you, i'll come back to hangout
<wallyworld> or ping me when you are free
<vino> wallyworld: I am here.
<wallyworld> coming to HO
#juju 2020-05-04
<jam> timClicks, are you around today? are we still doing the charming doc meeting? I know both Facundo and chipaca are out, and I didn't know if you were or not
<timClicks> jam: yes, I had intended on being there.. but I'm happy to chat you to later in the week
<jam> timClicks, I'm happy to be there, we can talk through what you commented on last week.
<timClicks> perfect
<timClicks> jam: would you like to chat now rather than in 30 mins?
<timClicks> jam: actually, I've just noticed that niemeyer has indicated that he would like to take part
<achilleasa> hml: can I get a CR on https://github.com/juju/juju/pull/11526 please? QA steps will take a while... sorry ;-)
<hml> achilleasa:  sure
<hml> achilleasa:  line 46 of: https://pastebin.canonical.com/p/b46yRMvvmJ/
<hml> ran the k8s charm qa steps.  unsure of the last result
<achilleasa> hml: that looks correct. If you don't set the application databag via mariadb-k8s/0 it shows up empty
<achilleasa> note that these charms are pre 2.7 so they are storing the credentials in the unit databags
<achilleasa> instead of the app one
<hml> achilleasa:  am i using the correct charms/ bundle then?
<achilleasa> yes. you need to run the 'relation-set' command from the QA steps to populate the databag
<achilleasa> if you run the last command on rc0 you would hit the bug
<hml> achilleasa: i only ran relation-set on 1 of the units, not both
<achilleasa> hml: yes, you ran it on /1 which is not the leader so nothing got set
<achilleasa> (the set reported an error in the pastebin output)
<hml> achilleasa:  crap - hit a new bug after i added a model to the controller to start overâ¦. : ERROR cannot deploy bundle: cannot deploy application "mariadb-k8s": cannot add application "mariadb-k8s": series "kubernetes" in a non container model not valid.
<hml> achilleasa:  nmâ¦ let me figure this out. s omething is off in my config
<jam> achilleasa, https://github.com/juju/juju/pull/11527 adds appropriate behavior to 'juju debug-code'
<jam> and adds tests of how debugAt interacts with shell scripts.
 * jam eod
<hml> achilleasa:  is it necessary to update the uniter api version?  iâm having an internal debate
<achilleasa> hml: since rc0 is out we need to if we want to ensure a proper upgrade path, right?
<hml> achilleasa:  rc0 would be fuzzy for me with this.  better safe than sorry though
<jam> achilleasa, we have only officially released beta1, right?
<jam> rc1 is the 'edge' not officially released
<jam> achilleasa, so we have to have a way to *upgrade* from beta1 to final, but that doesn't mean beta1 has to be compatible with final
<jam> achilleasa, so if what you are changing would affect *upgrade* then you definitely need to version it. if there is an error, but upgrading still works, that is ok.
<achilleasa> jam: I bumped it to be on the safe side as I was not entirely sure about facade schemas (my change adds a new call) and pylibjuju
<hml> achilleasa:  a comment and a question.
 * thumper is looking at a very mocked worker trying to work out how to write a test for the current failure
<thumper> :( I can't help feel that these tests are racy
<thumper> perhaps I don't understand the mocks
<babbageclunk> kelvinliu: if you're around could you take a look at https://github.com/juju/juju/pull/11528 please?
<kelvinliu> babbageclunk: sure
<kelvinliu> babbageclunk: could u take look this one as well https://github.com/juju/juju/pull/11505 please?
#juju 2020-05-05
<thumper> anyone on know mocks well? I need to discuss a test
<thumper> babbageclunk, wallyworld[m] ?
 * thumper goes to make lunch instead
 * thumper looks for babbageclunk again
<thumper> o/ kirkland
 * thumper checked calendar and saw babbageclunk out
<thumper> wallyworld: I was wanting to chat about a test using mocks
<thumper> as I'm struggling a little
<thumper> wallyworld: could probably get it over in 5 minutes
<wallyworld> sure, i'm free
<thumper> wallyworld: I'll jump in your standup
<thumper> wallyworld: https://github.com/juju/juju/pull/11530
<wallyworld> ok
<wallyworld> just finishing this other one
<thumper> ack
<wallyworld> thumper: lgtm
<thumper> ta
<wallyworld> thumper: a small fix to restore a api method to the latest facade https://github.com/juju/juju/pull/11529
<wallyworld> and a +1/0 https://github.com/juju/juju/pull/11531
 * thumper loogs
 * thumper looks even
<thumper> wallyworld: already commented on the first one
<thumper> approved second
<wallyworld> ta
<babbageclunk> wallyworld: hey, you already merged my stuff forward into develop!
<babbageclunk> thanks!
<wallyworld> thumper: nah, not useful to me, just a pita to keep up to date. YMMV. i was also going for consistency. i can add them back if you feel strongly
<babbageclunk> huh, I think I've gotten confused from too much birthday cake
<wallyworld> babbageclunk: how was the birthday?
<babbageclunk> about as much fun as you can have at a party! (given that you're not allowed to invite friends)
<babbageclunk> She decided that you don't turn 4 until you've eaten the cake, it was very cute
<wallyworld> well, none of *my* parties have friends
<babbageclunk> Bugger, I landed that change in the wrong branch, backporting
<babbageclunk> I mean, I intended to get it into develop, but had meant to do it first
<babbageclunk> in 2.7
<wallyworld> ooops
<babbageclunk> fixing now
<thumper> wallyworld: I think I do feel strongly enough to keep them, I'd like to see that pattern extended
<thumper> wallyworld: the key here is that if they change, it should be obvious
<thumper> and we shouldn't be changing older facades
<wallyworld> ok, i'll revert. but it's not a great check for facade breakage since you can add methods to a facade and not even know about the interfaces
<wallyworld> i do question whether they carry their weight
<wallyworld> thumper: pr much smaller now, interfaces restored
<babbageclunk> kelvinliu: want to rubber-stamp the PR you've already approved but this time for the 2.7 branch? :) https://github.com/juju/juju/pull/11532
<kelvinliu> babbageclunk: yep
<babbageclunk> thanks!
<kelvinliu> np : >
<wallyworld> thumper: small one if you're still here https://github.com/juju/juju/pull/11533 otherwise can wait
<babbageclunk> wallyworld: I done it
<wallyworld> ty
<thumper> ty
<thumper> well that was a very annoying hour debugging
<thumper> for the record, if you use a standard http client and have an url that looks like "http://something//action" and you call PostForm, it gets converted into a Get silently
<thumper> remove the double slash and you're fine
<thumper> FFS
 * thumper well past EOD
<thumper> later peeps
<achilleasa_> jam: do you want me to take a look at 11527 or do you want to land it as it's already approved?
<jam> achilleasa_, I'm happy to have your feedback, if you're busy I can just land it.
<achilleasa_> jam: will take a look now since I am waiting on CI ;-)
<jam> great!
<skatsaounis> Hi, I have a question regarding cloud-init of juju models' machines and juju controllers
<skatsaounis> Is there an option during juju bootstrap or by providing juju model constraints to set some options to cloud-init of created machines?
<skatsaounis> for example, I would love to add a user with password to troubleshoot some issues with my OpenStack cloud provider.
<skatsaounis> Being more specific, I want to use the virsh console to login to a juju machine (nova instance) and login with my user to troubleshoot my connectivity issues
<Eryn_1983_FL> hey guys
<Eryn_1983_FL> I got an issue
<Eryn_1983_FL> i remove my nic config on a server in the cluster and i cant login to it locall
<Eryn_1983_FL> locally
<Eryn_1983_FL> this is for openstack
<achilleasa_> manadart: I am trying to add an address dedup layer on top of the NetworkInfo API call (uniter). An interface address is a tuple (host, address, cidr). I am trying to recall whether it is legal to have the same CIDR in two different spaces
<achilleasa_> or do you think that dedupping on the address alone would be sufficient?
<manadart> achilleasa_: As of right now, where CIDR:Subnet is 1:1, a CIDR can only be in one space.
<Eryn_1983_FL> hello
<Eryn_1983_FL> so how do i get into an admin account for a node on the cluster?
<Eryn_1983_FL> i cant ssh into it.
<Eryn_1983_FL> ???
<Eryn_1983_FL> can somebody tell me how i can rescue a box w/o any networking working?
<manadart> Eryn_1983_FL: If you add an interface via OpenStack, Juju should detect the change shortly thereafter, allow you to `juju ssh`.
<hml> achilleasa_:  11526 is looking good, just running a few of the qa steps again
<Eryn_1983_FL> ok..
<Eryn_1983_FL> i dont think it can even communicate to it manadart
<Eryn_1983_FL> i cant ping any nics
<Eryn_1983_FL> heading towards a rescue cd..
<manadart> Eryn_1983_FL: This node is part of a Juju model, correct?
<Eryn_1983_FL> yeah
<Eryn_1983_FL> i move the netplan file
<Eryn_1983_FL> and it messed it up
<Eryn_1983_FL> atleast i found u guys finally
<Eryn_1983_FL> and the docs the proper docs
<Eryn_1983_FL> i got serious network issues
<Eryn_1983_FL> i have broken the fabrics of spacetime/network :(
<Eryn_1983_FL> can you explain how openstack is using netplan and vswitch?
<Eryn_1983_FL> it seems like it was making only one bridge eth0 and thats what i remove thinking it was in error and then everything went down after reboot
<flxfoo> hi all,
<flxfoo> sorry to bother, I killed a juju process during bootstrap attempt, now I have `ERROR no API addresses" when trying to do a `juju status`, any idea?
<flxfoo> thanks in advance
<flxfoo> (still wanted to create a new controller)
<Eryn_1983_FL> not sure flxfoo
<Eryn_1983_FL> manadart: ?
<Eryn_1983_FL> noobie here
<flxfoo> Eryn_1983_FL: ok, got something
<Eryn_1983_FL> ok
<Eryn_1983_FL> whats the root passes?
<Eryn_1983_FL> damn it
<Eryn_1983_FL> i didnt add it to the admin group or whatever
<Eryn_1983_FL> sigh
<Eryn_1983_FL> so i got vswitch and netplan running on the same boxes..
<Eryn_1983_FL> why is that?
<Eryn_1983_FL> is that normal?
<Eryn_1983_FL> ok i almost got it back to normal i hope
<Eryn_1983_FL> well less broken
<hml> flxfoo:  you need to remove the attempted controller and rebootstrap.  remove the controller machine via your cloud, and run juju unregister <controller name>
<petevg> flxfoo: the --force flags on destroy controller, and the juju unregister <controller> command should help you get into a state where you can cleanup the borked controller. You can then bootstrap a new one.
<Eryn_1983_FL> ok guys i am going to post some pastebins of whats going on with my stuff
<petevg> Eryn_1983_FL: the internals of how the OpenStack charms work are documented at https://docs.openstack.org/charm-guide/latest/
<petevg> If you have specific questions after reading the docs, we'd be happy to answer them.
<Eryn_1983_FL> https://paste.debian.net/1145121/
<Eryn_1983_FL> ok
<petevg> Eryn_1983_FL: juju and the charms are meant to abstract a lot of the internals away, so that you don't have to worry about them. You're welcome to experiment with your system, of course, but you will break things if you start removing network interfaces and network configuration files around. :-)
<Eryn_1983_FL> ok
<Eryn_1983_FL> well is there a way to go back?
<Eryn_1983_FL> i think the problem is the co worker used juju and messed soemthing up
<Eryn_1983_FL> the switching fabric  broke
<Eryn_1983_FL> lets start with how can i verify the status of my openstack, and juju, and then what can i do to reinstall rebuild
<Eryn_1983_FL> https://paste.debian.net/1145123/
<Eryn_1983_FL> that looks good to me petevg
<Eryn_1983_FL> except for ceph
<petevg> Eryn_1983_FL: if there are still problems, it looks like juju doesn't know about them. Do you know what actions the co-worker ran?
<Eryn_1983_FL> no clue
<Eryn_1983_FL> we ere getting permission denied erros when we try to start instances
<Eryn_1983_FL> i need to reinstall the switching on the machines is there a way to do that
<Eryn_1983_FL> i think the rest is fine
<Eryn_1983_FL> if i were to redeploy like web4
<Eryn_1983_FL> does that affect my instances or whatever
<petevg> Eryn_1983_FL: were you getting permission denied in the OpenStack tooling? What lead you to think that the root cause was networking?
<Eryn_1983_FL> well i saw the networking when i went in
<Eryn_1983_FL> i think we saw some errors for br-int was busy
<Eryn_1983_FL> and then the processes for openvswitch was down
<Eryn_1983_FL> failed
<Eryn_1983_FL> the webgui we got the permission denied error
<Eryn_1983_FL> when we tried to restart the instaces after some external network issues and reboots
<petevg> Eryn_1983_FL: Open vSwitch is the virtualized networking layer for OpenStack. If you remove the bridges or interfaces or configuration it creates, you'll interfere with the OpenStack services' ability to communicate with each other.
<petevg> When you fixed the external network issues, did you bring the network back up in the same state that it was in before? i.e., do machines still communicate on the same subnets, and have the same ip addresses?
<Eryn_1983_FL> not sure what he did on that layer either, i can still ssh from maas
<Eryn_1983_FL> i can ping out on them
<Eryn_1983_FL> at this point i just want to build another 4 host cluster and rescuse this data off and put it there..
<petevg> Eryn_1983_FL: that sounds like a good idea. There's enough uncertainty here in the history to make it hard to troubleshoot over IRC. If you have the option to rebuild, I'd go with that option. :-)
<achilleasa_> manadart: if around can you take a look at https://github.com/juju/juju/pull/11535?
<achilleasa_> manadart: you were right, the cause of the bug is indeed https://bugs.launchpad.net/juju/+bug/1855263 but we should probably leave that be and resolve it once your refactoring work lands
<mup> Bug #1855263: Duplicate link layer device entries when running on AWS <juju:Triaged by manadart> <https://launchpad.net/bugs/1855263>
<manadart> achilleasa_: Yep; looking now.
<Eryn_1983_FL> ok question guyes
<Eryn_1983_FL> where are the root partitions stored for instances?
<Eryn_1983_FL> ??
<Eryn_1983_FL> found it /var/lib/nova/instances
<Eryn_1983_FL> petevg:  do you know how to open these files?
<petevg> Eryn_1983_FL: I wouldn't recommend introspecting vm filesystems unless you are very comfortable with what you're doing. If I were troubleshooting this myself, I'd probably be looking for root cause of the issue in log messages.
<Eryn_1983_FL> yeah its the vswitch
<Eryn_1983_FL> but nobody know how to help me
<petevg> Eryn_1983_FL: what are you trying to accomplish by inspecting the vms? Are you trying to recover data? Or look at logs?
<petevg> You can use openstack tools to look at the console logs. For example: "openstack console log show <some instance name>"
<Eryn_1983_FL> i need the conifgs and data from them
<Eryn_1983_FL> so i rebuild the entire thing
<Eryn_1983_FL> looks like its qcow
<Eryn_1983_FL> i think i can handle that
<petevg> Eryn_1983_FL: yes. They are qcow images. Just as a note: you probably don't need to be looking in the images for information like how things were networked together. That information should exist in your juju bundle.yaml.
<petevg> If you're looking to recover data unique to applications that you had deployed on top of OpenStack, then it might make sense to look in those images, assuming that you don't have backups elsewhere.
<petevg> Eryn_1983_FL: also, since you're deploying on MAAS and Juju, do you have a support contract with Canonical? If so, I would reach out through your support channels. Those would be a better place to ask for step by step instructions on disaster recovery.
<Eryn_1983_FL> haha
<Eryn_1983_FL> nope no support
<Eryn_1983_FL> boss was like lets do this and installs it..
<Eryn_1983_FL> nah this was not backuped else where,
<flxfoo> petevg: hml thanks guys ! :)
<petevg> You're welcome!
<babbageclunk> hpidcock: wanna do an easy +0/-0 review? https://github.com/juju/juju/pull/11536
<babbageclunk> or anyone else - wallyworld?
<hpidcock> sure
<hpidcock> babbageclunk: doneski
<babbageclunk> cheers
#juju 2020-05-06
<hpidcock> small pr https://github.com/juju/juju/pull/11537
<thumper> simple review for someone
<thumper> https://github.com/juju/juju/pull/11538
<thumper> hpidcock: approved
<babbageclunk> thumper: approved
<thumper> babbageclunk: ta
<wallyworld> tlm: everything working out with the model agent connectivity?
<tlm> wallyworld: yeah so far so good
<wallyworld> gr8 ok
<tlm> may have messed up some naming i just realised
<tlm> will fix it up later. Think this should be caasmodeloperator ?
<wallyworld> naming things is hard
<wallyworld> yeah
<kelvinliu> wallyworld: ru still around?
<manadart> achilleasa: Mechanical one when you have a chance: https://github.com/juju/juju/pull/11540
<achilleasa> manadart: can look in a few min
<achilleasa> manadart: trade you for https://github.com/juju/juju/pull/11541 ;-)
<manadart> OK.
<manadart> achilleasa: Will just grab a quick bite and sit down with it.
<achilleasa> manadart: sure thing
<gsamfira> folks, any chance we can get win2019 series in simplestreams?
<gsamfira> http://streams.canonical.com/juju/tools/streams/v1/com.ubuntu.juju-devel-tools.json <-- win2016 seems to be the latest one
<petevg> gsamfira: wallyworld dropped some code into 2.8rc1 that might help you work around this: https://discourse.juju.is/t/easier-centos-and-windows-image-selection/2991
<petevg> gsamfira: nm. hml points out that you were looking for tools, rather than an image.
<gsamfira> petevg: yep :). For windows images we have our own tooling to generate them here: https://github.com/cloudbase/windows-openstack-imaging-tools/
<gsamfira> petevg: but we currently have to build our own tools and host them somewhere for win2019
<gsamfira> not a huge issue, but win2019 works, and it would be nice to have tools available for it in simplestreams
<petevg> gsamfira: got it. I'm working on adding the win2019 tools to our build process. It won't happen right away, but the ball is rolling!
<gsamfira> petevg: thanks! No rush on this. Whenever it gets in, it will be a welcome adition
<Mmike> Howdy, fellow Juju-ers!
<Mmike> 'juju sync-agent-binaries' is downloading EVERYTHING it has (like, architectures I'll never use). Also, it requires controller to be fired up, although I don't understand why is that needed.
<Mmike> Is there a simplestreams tool that I could use to download just the tools I need?
<Mmike> sstream-mirror !
<Mmike> will take a look
<pmatulis> is there a max value to the --timeout option available to the 'juju run' command?
<pmatulis> (e.g. will --timeout=300m be honoured?)
<timClicks> pmatulis: I don't believe so, I think that the validation checks that it's a positive integer. I'll take a peek at the code and check for you :)
<pmatulis> timClicks, thank you!
#juju 2020-05-07
<tlm> wallyworld: got 5 minutes for HO problem ?
<wallyworld> sure soon
<wallyworld> tlm: free now
<tlm> k
<babbageclunk> wallyworld: https://github.com/juju/juju/pull/11543
<babbageclunk> I think it might have a problem with something in feature tests that rely on legacy leases though.
<wallyworld> babbageclunk: looking
<wallyworld> babbageclunk: yeha, there's a MachineLegacyLeasesSuite in cmd/jujud/agent machine_test
<wallyworld> so a few tests to fix
<hpidcock> wallyworld: quick pr https://github.com/juju/juju-db-snap/pull/2
<wallyworld> sure
<wallyworld> lgtm
<hpidcock> danke
<flxfoo> Hi guys, sorry to interrupt again. But someone is asking me some questions like
<flxfoo> Is JUJU able to provision AWS resources or is managing only application deployment/layer?
<flxfoo> and
<flxfoo> If able to deploy AWS resources, is it able to deploy autoscaling groups? Or just fixed defined number of instances?
<flxfoo> if anyone has some answers... you are welcome :P
<timClicks> fixfoo: provision, yes to autoscaling
<timClicks> except it's not autoscaling as per kubernetes, it's manual
<timClicks> e.g. you ask juju to change the application's scale, and it will update all config on your behalf
<flxfoo> timClicks: thanks!
<flxfoo> still don't know what they are calling "groups"
<jam> timClicks[m], are you around?
<manadart> achilleasa: Got a couple of small patches to come in under the one I am working.
<manadart> This is the first: https://github.com/juju/juju/pull/11545
<manadart> achilleasa: And this is the other: https://github.com/juju/juju/pull/11546
<achilleasa> manadart: looking
<hpidcock> PR for someone https://github.com/juju/testing/pull/148
<hpidcock> another PR https://github.com/juju/juju/pull/11547
<achilleasa> hml: got any time to look at 11547 ^^
<hml> achilleasa: not really, i was thinking we needed to look at it though from email.
<hml> achilleasa:  iâm tight on time - read thumperâs email on RC1
<hml> :-D
<achilleasa> hml: ah... that email! No worries, I will take a look then
<hml> achilleasa:  ty
<hml> achilleasa:  we should look at 11544 also
<pmatulis> if i reboot a juju machine and immediately send it a command like 'juju upgrade-series 0 complete' is that guaranteed to work or do i need to wait?
<pmatulis> hml, any idea? ^^^
<hml> pmatulis: you could have a race, if the machine doesnât go down fast enough, iâd think.  cannot guarantee.
<hml> pmatulis:  a bit swamped at the momment to dig into how our CI tests this
<hml> manadart: do you have an easy answer for pmatulis ^^^ ?
<manadart> pmatulis hml: You should be able to send the command immediately. It needs the agent to do the work, so the command will implicitly wait for the worker to do its thing.
<manadart> This is actually a known issue with it - reliance on a well connected client should not be a thing.
<pmatulis> manadart, you're saying it will work out fine as long as the client maintains connectivity with the controller?
<manadart> pmatulis: Yes, there is an open bug around it.
<manadart> https://bugs.launchpad.net/juju/+bug/1855013
<mup> Bug #1855013: upgrade-series hangs, leaves lock behind <seg> <juju:Triaged> <https://launchpad.net/bugs/1855013>
<pmatulis> manadart, thanks a lot. i don't see anything about bad client:controller connectivity as the cause though
<manadart> pmatulis: The symptoms line up with what we know about how the feature was written.
<pmatulis> manadart, alright
<manadart> achilleasa, hml, petevg: This is finally ready to go now: https://github.com/juju/juju/pull/11534
<petevg> Woot!
<petevg> achilleasa, manadart: if either of you have time to take a look at hml's draft for https://github.com/juju/juju/pull/11542 before your eod today, I'd appreciate it. That would help us try to sneak it in to the rc1.
<manadart> petevg: I can look now.
<petevg> +1. Thx!
<achilleasa> petevg: I ... think ... I have finally managed to reproduce the kvm bug
<petevg> achilleasa: nice! Was it a caching issue, or something else?
<achilleasa> petevg: still going through my logs but I believe after we get the metadata from the stream and before we fetch the actual image, the base URL (which should point to the model-config) is left empty...
<petevg> Interesting.
<achilleasa> petevg: so if it's not correctly propagated, we get here: https://github.com/juju/juju/blob/develop/environs/imagedownloads/simplestreams.go#L77-L79
<achilleasa> and this is why they fall back to cloud-images.ubuntu.com
<achilleasa> looks like the streams index was fetched from the correct location but the image used the fallback
<petevg> Aha.
<hml> manadart:  ty for 11542, I pushed up some commands testing.  there is an acknowledged short cutâ¦..
<hml> achilleasa: manadart  how do i get the skipped github actions to run after converting a pr from draft to open?
<hml> havenât done this since we changed it
<hml> no buttons are appearing to me.
<pmatulis> manadart, hi, i got a similar question re actions. is there a timing concern for a unit that has had an action applied if the --wait option is omitted?
<pmatulis> (my use case is pausing a unit prior to 'upgrade-series prepare' for the associated machine)
<hml> pmatulis: what command are you using with âwait?
<hml> pmatulis:  show-action-output
<hml> ?
<pmatulis> hml, run-action
<pmatulis> (to pause the unit)
<hml> pmatulis:  iâd recommend checking the action status at the very least.
<hml> there is also a show-action-status
<pmatulis> hml, realise that. just wondering if there is indeed a timing issue
<pmatulis> (potentially)
<pmatulis> to be clear, if keystone/2 is on machine 0 can i perform these two commands safely without waiting?
<pmatulis> juju run-action keystone/2 pause
<pmatulis> juju upgrade-series 0 prepare bionic
<achilleasa> petevg: are there any plans for another 2.6 release? I have a fix for the kvm bug currently targeting 2.7 but can also do 2.6 -> 2.7 -> develop
<achilleasa> hml: approved but without QA as I am near EOD
<hml> achilleasa:  ty, iâll get petevg  to do qa. :-)
<hml> achilleasa:  do you know how to switch the github actions back on for a pr?
<achilleasa> hml: no :-( do you need admin permissions?
<hml> achilleasa:  dunno?  iâll check with hpidcock later
<petevg> achilleasa: I don't know whether we're planning another 2.6 release or not. Let's just target 2.7 and develop with the fix for now.
<achilleasa> hml: can you take a look at https://github.com/juju/juju/pull/11550? Perhaps petevg can lend a hand with the QA steps as well. Since I am EOW it would be great if you (or anyone from APAC) could forward-port (should be a clean merge) to develop and update the bug with a link to the other RP
<hml> achilleasa:  looking
<hml> achilleasa:  you used guimaas to test?
<achilleasa> hml: yes but the image server must be accessible by it (I used a VPS for testing)
#juju 2020-05-08
<wallyworld> hpidcock: here's the 2.7 port https://github.com/juju/juju/pull/11551
<hpidcock> wallyworld: were there any merge conflicts?
<wallyworld> no
<wallyworld> clean
<hpidcock> wallyworld: done
<wallyworld> ta
<hpidcock> wallyworld: when you get back https://github.com/juju/testing/pull/148
<hpidcock> wallyworld: can you make sure the Github webhooks for https://github.com/juju/testing are correct please
<wallyworld> hpidcock: looks ok, was fired successfuly for https://api.github.com/repos/juju/testing/issues/148 30 minutes ago
<wallyworld> or 20
<hpidcock> weird, ok thanks
<wallyworld> now i gotta run to vet
<hpidcock> yeah wallyworld the webhooks look misconfigured for the https://github.com/juju/testing project
<wallyworld> hpidcock: it just fired again a few minutes ago. do the jenkins logs reflect that?
<hpidcock> yep it does
<hpidcock> ugh
<hpidcock> time to dig deeper
<wallyworld> hpidcock: deploying kubeflow bundle, yay..... controller-0: 13:01:51 ERROR juju.worker.dependency "caas-unit-provisioner" manifold worker returned unexpected error: panic resulted in: runtime error: invalid memory address or nil pointer dereference
<wallyworld> lots of cert noise i been meaning to look at also controller-0: 12:57:43 WARNING juju.worker.httpserver http: TLS handshake error from 10.1.51.1:38792: remote error: tls: bad certificate
<hpidcock> no stack trace?
<wallyworld> sadly no, i'm adding extra logging to log it
<wallyworld> any luck on your end?
<hpidcock> just starting at looking on the bug
<hpidcock> was busy fixing some jenkins stuff
<wallyworld> all good
<hpidcock> will have a pr up soon fixing unit tests with vendored deps
<kelvinliu> wallyworld: https://github.com/juju/juju/pull/11544 im still filling the description, but it's ready to review now
<wallyworld> gr8 ty
<babbageclunk> wallyworld: I'm *this close* to getting those machine agent tests to pass but haven't quite managed it and don't want to miss rc1 so have pushed up a last-minute commit to skip them
<wallyworld> babbageclunk: ok, ty
<hpidcock> wallyworld: if you are still here https://github.com/juju/testing/pull/149
<wallyworld> looking
<wallyworld> hpidcock: lgtm. dumb tests
<hpidcock> wallyworld: sigh this testing stuff overriding home makes me sad. Going to have to figure out another way.
<wallyworld> ok, i'm fighting with jenkins, finally got it unblocked i think
<wallyworld> great s390 slave is having issues
<hpidcock> wallyworld: the fun way to solve this problem https://github.com/juju/testing/pull/150
<hpidcock> with this all the juju tests pass with juju-db snap
<tvansteenburgh> Any one here using a remote lxd server as a lxd cloud in Juju?
