#juju 2013-08-12
<drecute> how do I perform code versioning in juju?
<drecute> like for example, I make changes to my charm and need to push updates
<marcoceppi|away> drecute: You can push your changes to bzr or git at any time
<marcoceppi|away> drecute: However, if you want to "upgrade" the charm running, you can run the upgrade-charm command
<marcoceppi|away> `juju upgrade-charm --repository="/path/used/during/deployment" <service>`
<marcoceppi|away> that should increment the revision file in your charm, which for local deployments, is what juju uses to track changes
<marcoceppi|away> the revision file is completely optional and only used for deploying from your local machine, if you're deploying from the charm store, the charm store keeps it's own revision of the charm, which is monitors the official repository for changes then increments number
<marcoceppi|away> So if you run `juju deploy mysql` find a bug, fix the bug, get it merged in to the official charm, you just need to run `juju upgrade-charm mysql` and juju will see the version in the store is higher and run the upgrade
<drecute> excellent.
<drecute> Thanks marcoceppi|away
<disposable> i'm trying to use juju with maas. I have both from ppa to make sure i use the latest versions. i've configured maas, have 2 nodes (1 declared and 1 allocated to root), however, after bootstrapping juju, when i type 'juju status', I get """error: Unable to connect to environment "". Please check your credentials or use 'juju bootstrap' to create a new environment. Error details: no reachable servers
<disposable> i do not see any errors in /var/log/maas/*. what else should i check?
<disposable> and my maas web ui works fine.
<davecheney> disposable: it sounds like bootstrap didn't work
<davecheney> could you try again with
<davecheney> juju bootstrap -v
<davecheney> (if you environment is bootstrapped, nothing will happen)
<disposable> error: environment is already bootstrapped
<davecheney> ok, cool
<davecheney> could you do the status with -v for me ?
<disposable> http://pastebin.com/SJVGsaTL is what's in my environments.yaml
<davecheney> (i really wish -v was the default)
<disposable> davecheney: juju status takes forever to run (5+ minutes)
<disposable> davecheney: so please don't think i've left
<davecheney> hmm, sounds like a timeout
<davecheney> it smells like the mongodb server onthe bootstrap node didn't start up
<davecheney> i'm guessing there are lots of timeout errors
<disposable> davecheney: the verbose output isn't that much more informative - http://pastebin.com/FUri1dx3
<davecheney> disposable: weird, why is you environment named ""
<davecheney> is node1 resolvable from your client ?
 * davecheney is asking in #juju-dv
<disposable> davecheney: it isn't. i haven't installed maas-dns and i'm using external dhcp server.
<disposable> should node1 be running?
<davecheney> yes, if i understand correctly, node1 has been designated as the bootstrap node, or what we call machine 0
<davecheney> if it's not running, that would explain what is going on
<disposable> when i list the nodes in maas web ui, i see node1 as "Status: Allocated to root". I can't say i understand what that means.
<disposable> davecheney: if i start node1, it'll try to pxe boot. will it not just get overwritten/reinstalled again?
<davecheney> disposable: tbh, i'm not sure, i'm not a maas expert
<davecheney> i only know it from the POV of juju and the provider interface
<davecheney> i *think* what has happened is your node 1 has been used as the bootstrap node
<davecheney> but becuase it is off, the environment is unaccessable
<disposable> davecheney: since it's in virtualbox, i've taken a snapshot and it's now booting up
<davecheney> ok
<disposable> i've made node1 resolvable, ran juju status -v and got this error - http://pastebin.com/5L5iXbxh On node1, i see network activity when juju staus is running, but otherwise there's no disk/net activity at all.
 * davecheney looks
<davecheney> disposable: here is what may have happened
<davecheney> you may have shut down node 1 before the bootstrap process was complete
<disposable> i do not believe it was on while bootstrap was running. is there a way to un-bootstrap and re-bootstrap juju?
<davecheney> disposable: yes juju destroy-environment will remove the environment and release the machines back to the maas controller
<jamespage> davecheney, lol - (i really wish -v was the default)
<disposable> davecheney: thank you. i'll try that later.
<jamespage> alias juju="juju -v"
<jamespage> juju is just a little to quiet these days :-)
<davecheney> jamespage: +1
<davecheney> saves you having to run the command twice when it goes wrong
<marcoceppi|trave> disposable: virtual box is not a good virtualizer for Maas
<marcoceppi|trave> for one, pxe booting doesn't work (didn't work for me when I did this a year ago)
<bbcmicrocomputer> is proper networking with containers ala 'juju add-machine 1/lxc' working in latest 1.13.1?
<davecheney> bbcmicrocomputer: i'm going to say a conditional yes
<davecheney> but i'd like to check with thumper before I say any more
<bbcmicrocomputer> davecheney: ah ok, thanks!
<disposable> i'm trying to start over with juju+maas. when i issue juju destroy-environment, all i get back is - ERROR juju supercommand.go:274 command failed: gomaasapi: got error back from server: 409 CONFLICT
<disposable> what should i do next (apart from reinstall)?
<disposable> nevermind, deleting declared node from maas, fixed it.
<disposable> s/maas,/maas
<m_3> can any OSX users help test out the brew instructions in https://code.launchpad.net/~evarlast/juju-core/osx-homebrew-goget/+merge/178379 ?
<m_3> it should be easy to check... it's just installing go with brew, then using go get to install juju client
<sidnei> adam_g, hazmat, around? seems like 'units:' was renamed to 'num_units:' in the rewrite?
<sidnei> juju-deployer that is
 * hazmat pokes around orig src
<hazmat> sidnei, hmm. it does look that way
<hazmat> sidnei, i'll add in a back compat for it
<sidnei> hazmat: thanks
<JamesTait> Hi all.
<JamesTait> I upgraded to Ubuntu Saucy over the weekend, and with it to juju-core 1.12.0 (later to 1.13.1 via PPA).  I've been using jitsu watch to wait for a node to come up, but now I'm getting an error "ImportError: No module named juju.control".
<JamesTait> Am I missing a dependency somewhere?
<marcoceppi> JamesTait: jitsu is depreciated and no longer compatible with juju > 0.7
<JamesTait> marcoceppi, ah, that'd explain it. Is there something I should be using instead?
 * JamesTait hasn't been keeping up to date with the charm schools. :(
<marcoceppi> JamesTait: so, we have juju plugins (being that we can create arbitrary juju subcommands much like bzr and git) however, at this time we dont' have a comperable watch alternative
<marcoceppi> JamesTait: what were you using watch for primarily?
<JamesTait> marcoceppi, I'm using it in a Makefile where I wait for solr-jetty to be started and then use juju status to get its public IP address to put into a configuration file for something else.
<marcoceppi> JamesTait: Gotchya, would it be better to mock that exchange in a relation instead?
<JamesTait> marcoceppi, this is for a local dev environment (for click package index), and I'm not quite sure what the status is of the dependent service (which is the click package index WSGI service).  I think I'll need to have a chat with the chap who charmed it for production and see what we can work out.
<marcoceppi> JamesTait: ah, I see, so the ip isn't used directly with other charms, but for external service
<marcoceppi> services*
<marcoceppi> So, there's a tool called amulet that I've been working on, it's designed with testing in mind, but it has a port of the jitsu watch command in the form of `amulet wait`
<marcoceppi> in that the command will block until either a timeout is reached or the environment/service is moved to started
<JamesTait> marcoceppi, yeah.  The way the dev environment is currently set up, we use juju for solr-jetty, but the wsgi service is just run directly under gunicorn.
<JamesTait> marcoceppi, ah yes, I recall reading about amulet.
<marcoceppi> JamesTait: So, it's in the ppa:juju/pkgs ppa, it's purpose is for functional tests, but you could certainly run that command add-hoc until I port the code to a juju plugin :)
<JamesTait> It sounds like an option.  I'm currently drafting an e-mail to the team to describe the problems I've had during the upgrade so others don't need to. :)
<JamesTait> And "I'll fix the Makefile so you can all continue working as you are" sounds so much better than "We're going to need to re-work the dev environment and..." ;)
<JamesTait> marcoceppi, thanks for your help, I'll give it a bash and let you know how we get on.
<marcoceppi> JamesTait: cheers, please let me know if you have any questions or feedback!
<JamesTait> marcoceppi, will do!
<JamesTait> marcoceppi, is amulet available on Saucy?
<marcoceppi> JamesTait: Oh, let me kick off a saucy build
<JamesTait> Awesome, thanks. :)
<andreas__> adam_g: hi, I added the tests, could you take another look? https://code.launchpad.net/~ahasenack/charm-helpers/ceph-wait-for-device/+merge/179429
<andreas__> thanks
<adam_g> andreas__, ack,, will in a bit
<adam_g> ahasenack, any chance you can add the 'slow' attribute to those tests that wait on a timeout?
#juju 2013-08-13
<bradm> anyone know how to create an icon.svg for a charm?
<rick_h> bradm: check out https://juju.ubuntu.com/docs/authors-charm-icon.html
<rick_h> bradm: be aware that only icons for reviewed charms show up. Otherwise the category icon will be displayed if it has one.
<bradm> rick_h: huh, I have to draw something?  that's not going to go well :)
<rick_h> bradm: hah, yea time to take some designer'y type out for a drink
<marcoceppi> bradm: A template is provided, if a luddite like me can do I think anyone can :)
<bradm> rick_h: I wonder if there's a way to convert the logo from upstream to a svg file
<marcoceppi> bradm: you can embed a bitmap instead of trying to convert it to SVG
<rick_h> bradm: yea, best thing is if you can find an svg of the upstream logo, check license on it and all that.
<rick_h> marcoceppi: how does that work for the bitmap? We take the icons from 27ishpx to 160px. So pretty wide range for non-vector
<marcoceppi> rick_h: get the largest size bitmap you can find, hope for the best
<rick_h> marcoceppi: sorry, was more a 'how well does that work' question
<rick_h> lol
<marcoceppi> rick_h: liferay and a few others have embeded bitmaps
<rick_h> "paste and pray" method? :)
<rick_h> cool, liferay shows up pretty well
<bradm> ok, I might try doing something less than optimal for my first revision, and try and get a better looking logo later
<rick_h> marcoceppi: autocomplete in comingsoon :) it's purdy stuff for you and jcastro
<bradm> not that my charm is anything major, just a bip client
<rick_h> bradm: hey, never know when someone else finds it useful
<bradm> rick_h: yeah, plus it was more for me to learn how charm helpers works, etc
<marcoceppi> rick_h: <3333333333
<ahasenack> adam_g: like     @nose.plugins.attrib.attr('slow') ?
<ahasenack> adam_g: done
<Skepchurn> http://mrkinnikumike.blogspot.com/
<melmoth_> with 1.12.0-raring-amd64  "juju debug-hooks" tells me there is no such command.. I dont see debug-hooks neither in "juju help commands"
<jam1> melmoth_: it is new in 1.13.1
<melmoth_> ahh.
<melmoth_> i ll just watch the demo and not try it myself then :) thanks
<jam> melmoth_: I can point you to where you can get 1.13.1, but if you want to stick with a stable version, its up to you
<melmoth_> jam i m just playing with it so yep, a 1.13.1 version woul dbe  handy
<jam> melmoth_: ppa:juju/devel
<melmoth_> ahhhhh... right, i was using ppa:juju/stable. Thanks !
<jam> I think we still need to copy the 1.12 and 1.13.1 tools to canonistack let me check
<melmoth_> i m using local provider right now, as i m having issue deploying charm on canonistack (with juju-core)
<jam> melmoth_: np, I'm copying the tools now anyway. Also, I think you need 1.13+ to get local provider
<jam> thumper would know better, but he won't be around for a couple days (still traveling back from Isle of Man)
<melmoth_> worked with 1.12 (untill i try debug-hooks)
<melmoth_> jam btw im the guy you replyed to on cloud-list about juju-core on canonistack.I m wondering, if default-image-id is obsolete, how does juju knows wich image to pick when you bootstrap or deploy stuff ?
<jam> melmoth_: you want the long or short answer?
<melmoth_> short please :)
<melmoth_> just enough to understand what i m doing and not ending up firing up an image i dont want
<jam> there is a catalog, we look it up. We have a keystone entry in canonistack that tells us where the catalog lives.
<jam> we map from "precise-amd64" to an instance-id on the cloud.
<melmoth_> oh, i guess it s the product-streams endpoint
<melmoth_> jam thanks a lot, i dot know if it s the 1.13 version or the fatc i commented out the obsolete settings, but now i can deploy stuff on canonistack
<jam> melmoth_: I think it could as easily be canonistack got some more resources freed.
<jam> our experience has shown that occassionaly canonistack is a bit overloaded
<vila> hi there, trying to setup a local juju provider with lxc, 'juju get-environment'  fails with:
<vila> error: error parsing environment "local": no public ssh keys found
<vila> where can I find the juju config documentation ?
<vila> mgz: ping, may be you know ^
<jam> vila: juju currently requires you to have ~/.ssh/id_rsa.pub available, so it can set up authorized-keys on the target machines.
<jam> It should optionally let you get by without them, but probably just warn that you won't have ssh access.
<vila> jam: thanks, found authorized-keys-path dusting off my memory, I'm all set on that
<vila> jam: now, juju get-environment says: error: file "provider-state" not found
<vila> ... which juju bootstrap created ;)
<jam> vila: I just set up a local env here, and it seems to be working. You did 'juju bootstrap" and it succeeded, right?
<vila> jam: a bit surprising to not be able to use get-env before bootstrap but I can imagine why
<vila> jam: well bootstrap ended up with 'error: no reachable servers' :-/
<jam> vila: get-env is 'read the environment from the server' not from your local configuration.
<vila> jam: ha ! makes sense then ;)
<jam> local config sets up the initial env, but the source-of-truth is the remote location
<vila> jam: running saucy, using ppas juju/devel and juju/pkgs, I add to manually install mongodb-server to make bootstrap happy
<jam> vila: 'apt-get install juju-local' if you want all the things we need for the local provider. In the stable ppa, not sure about devel.
<jam> ppa:juju/stable
<jam> adds mongodb-server and lxc
<jam> vila: you don't need them to run juju-the-client, so we didn't want to make them required on the juju-core package itself.
<vila> jam: that's it !
<mgz> hm, we still don't have a better error message with the packages missing?
<jam> mgz: looking here: https://launchpad.net/~juju/+archive/stable/+packages it looks like the 'juju-local' package is built from the juju-core package. So there isn't a way to just copy it into ppa:juju/devel, right?
<jam> We have to fix up our packaging for devel?
<mgz> yeah, we can
<jam> mgz: we had one
<jam> I don't know if it landed in 1.13.1
<jam> mgz: https://code.launchpad.net/~axwalk/juju-core/lp1204094-verify-local-prereqs/+merge/178496
<Elvo> Hi, can I have few question regarding juju?
<Elvo> 1) Is it opensource or not?
<Elvo> 2) is it offering stuff like autoscaling and auto-healing in the cloud?
<Elvo> 3) Is it working with Rackspace?
<marcoceppi> Elvo juju is opensource, it doesn't directly offer autoscaling or auto-healing but it is on the roadmap to be addressed (it does do scaling though), it doesn't work with rackspace yet because Rackspace hasn't updated their openstack install. It does however work with Amazon, HPCloud, OpenStack, MAAS, and LXC (local) with more providers coming online soon
<marcoceppi> Elvo: Juju also has a restful API which can be used to implement autoscaling and auto-healing yourself using a tool of your choice
<Elvo> Thanks for answers. Question more - is there or it will be later - Windows client for juju?
<hazmat> jam, does it only search id_rsa.pub ? any others.. like id_dsa.pub  or other default keys?
<hazmat> Elvo, yes, there will be
<jam> hazmat: I'm not positive what it needs, just that it needs something, and if you have nothing it complains.
<hazmat> from the src looks like it will accept any of "id_dsa.pub", "id_rsa.pub", "identity.pub"
<jam> hazmat: I believe you can set it in the environ config directly if you like
<jam> (set the string)
<jam> d
<hazmat> jam, yup, just wanted to double check re other default keys for inspection
<jam> hazmat: I'm a bit surprised it picks dsa before rsa, TBH. I thought dsa was deprecated.
<hazmat> jam, what's your criteria for triage importance levels?
<jam> I guess it is just alphabetical
<jam> hazmat: so it should be: Critical: block the next release until fixed, High: On the priority queue for the next X months, Everything Else.
<jam> I may not always get those right
<hazmat> jam fair enough, was just curious cause its always clear re criteria ie openstack_s3 (high) before provider constraints (ec2-zone, maas-tags ) (low)
<hazmat> er.. not always
<jcastro> Elvo: Juju is written in golang so running on windows is just a matter of compiling it
<jcastro> we have not yet done that
<jcastro> but we are in progress, you should see Windows and OSX clients fully supported quite soon
<marcoceppi> jamespage: what's the login information for openstack-dashboard once deployed?
<jamespage> marcoceppi, it gets it from keystone
<jamespage> marcoceppi, and the admin username and password is configured using config in keystone
<marcoceppi> jamespage: So. I just deployed openstack and I have no idea how to log in
<marcoceppi> jamespage: thanks!
<jamespage> marcoceppi, you need todo a "juju set keystone admin-password=XXX"
<jamespage> otherwise is randomly generated :-)
<jamespage> usname is admin
<jam> jamespage: it can be hard to guess a randomly generated password :)
<jam> jamespage: could you "juju get keystone" ? (is there a reason to force it to something new)
<jamespage> jam: indeed - and as juju was no way of sharing something back to the user ....
<jamespage> jam: there is no 'config-set' from within a deployed charm
<marcoceppi> jamespage: does the admin-password need to be set prior to deployment?
<marcoceppi> jamespage: because setting it causes config-changed to barf
<jamespage> marcoceppi, juju-core?
<marcoceppi> jamespage: yes :( http://paste.ubuntu.com/5981025/
<jamespage> marcoceppi, ohyes
 * jamespage scrabbles for the patch
<marcoceppi> jamespage: you've got 8 hours before demo :)
<jamespage> marcoceppi, http://paste.ubuntu.com/5981028/
<jam> jamespage: how would you "juju set" on a service you haven't deployed yet? Just run "juju set" before the instance actually starts?
<jamespage> jam: nope - 'juju deploy --config config.yaml keystone'
<jamespage> that injects the configuration at deploy time
<marcoceppi> jamespage: if you want to propose merge, I'll ack and land it
<jamespage> marcoceppi, doing so now
<marcoceppi> jamespage: logging in now produces "Unable to retrieve authorized projects."
<jamespage> marcoceppi, hmm
<jamespage> marcoceppi, https://code.launchpad.net/~james-page/charms/precise/keystone/juju-core-fixes/+merge/179920
<jamespage> marcoceppi, it logged you in though right?
<jamespage> marcoceppi, and which openstack-origin are you using?
<jamespage> (more config)
<marcoceppi> jamespage: no, I get that error on the login screen, cloud:precise-grizzly, here's a URL!
<marcoceppi> http://15.185.188.159/horizon/auth/login/
<marcoceppi> admin123 for the password
 * marcoceppi fears no lurkers
<jamespage> marcoceppi, hmm - well thats annoying
<marcoceppi> slightly :)
<marcoceppi> let me know what I can do to get you any additional information
<marcoceppi> other than this is openstack on openstack
<jamespage> marcoceppi, can you pastebi /etc/openstack-dashboard/local_settings.py please
<marcoceppi> jamespage: http://paste.ubuntu.com/5981086/
<jamespage> marcoceppi, can you access your deployment using command line tools?
<marcoceppi> jamespage: let me try (using the keystone admin data?)
<jamespage> marcoceppi, yes
<jamespage> marcoceppi, http://paste.ubuntu.com/5981092/
<jamespage> source that as a file and then do 'keystone catalog' and see if it works
<Beret> ?
<marcoceppi> Beret: Hi, did you have a question?
<Beret> marcoceppi, sorry, typed in the wrong window :)
<Beret> I'm good thanks
<marcoceppi> o/
<adam_g> wedgwood, am i on crack or did this change / this bug is valid? i keep hitting older code that was looking for Nones. https://bugs.launchpad.net/charm-helpers/+bug/1203241
<_mup_> Bug #1203241: relation_get() on a non-set relation setting does not return None <Charm Helpers:New> <https://launchpad.net/bugs/1203241>
<wedgwood> adam_g: I don't remember seeing anything that would have changed that
<wedgwood> adam_g: Could be that it's always been that way?
<adam_g> wedgwood, the helper itself looks like it should be returning None for unset relations
<adam_g> at least, IIRC
<adam_g> but if the the difference in output of relation-get vs config-get is new..
<wedgwood> Could be. I'm not sure if that's right though. Does relation-set give a non-zero exit value for un-set keys?
<wedgwood> If not, there's no difference between no value and an empty one
<wedgwood> And that may be the reason for the inconsistency
<adam_g> wedgwood, IIRC relation-set will exit non-zero if its arguments are not key=value
<wedgwood> that makes sense. but I mean if I run "relation-get relationname somethinginvalid", do I get an empty string and a 0 exit?
<wedgwood> what I'm saying is that both config-get and relation-get probably do the same thing. if there's no difference in output between unset and empty, then the implementations may just be inconsistent because it wasn't clear which was correct.
<wedgwood> I'm leaning toward an empty string until we can tell the difference.
#juju 2013-08-14
<marcoceppi> jamespage: ping
<jamespage> marcoceppi, hey
<marcoceppi> jamespage: thanks for your help yesterday, we had a question today about the ceph charm during our charm school
<jamespage> marcoceppi, fire away
<marcoceppi> fsid config option says "fsid of the ceph cluster. To generate a suitable value use `uuid`. This configuration element is mandatory and the service will fail on
<marcoceppi>       install if it is not provided."
<marcoceppi> Why not just have the charm generate an fsid using uuid during a hook instead of having the charm fail deployment? Or, why have the charm fail at all, why not just silently wait until it's set?
<jamespage> marcoceppi, because it has to be consistent across all of the monitor nodes and there is no reliable way todo that in hooks (even cluster hooks)
<marcoceppi> jamespage: you can't have peer election of fsid?
<jamespage> marcoceppi, so injecting it as config (as well as the monitor secret) is a simpler and more reliable approach
<marcoceppi> jamespage: gotchya, any feedback on the second half of their question?
<jamespage> marcoceppi, well I wanted to ensure that a charm user knows that they have not done something required
<jamespage> so erroring out the hook is pretty much the only way to provide feedback!
<marcoceppi> jamespage: right
<jamespage> marcoceppi, I guess I could have provided default values
<jamespage> but I wanted to avoid there being 100's of ceph clusters all with the same fsid and secret :-)
<marcoceppi> jamespage: yeah, it rubs me wrong because charms should provide sane defaults
<marcoceppi> but I understand why it was done this way
<jamespage> marcoceppi, if we had a nice way of doing atomic sharing of stuff like this across peers then it would be a different approach
<marcoceppi> they were just laughing at the idea of having to run uuid, and I didn't know enough about the charm to say why it didn't just do that
<marcoceppi> jamespage: what happens if you change the fsid after initial deployment? does it ruin everything or will the charm properly accept it?
<marcoceppi> can ceph handle a change in fsid*
<jamespage> marcoceppi, no it can't
<marcoceppi> Okay, so that's why
<jamespage> requirement for immutable config - I have expressed this to the juju-core team
<marcoceppi> jamespage: what you have now is fine, I can echo that sentiiment saying "this affects users"
<marcoceppi> give us immutable configs!
<marcoceppi> jamespage: thanks for the information
<jamespage> please!
<jamespage> marcoceppi, oh - the other thing is that changing source does not actually do anything post install
<jamespage> marcoceppi, I know some charms (like the openstack ones) support upgrades through that route
<jamespage> ceph does not
<marcoceppi> jamespage: thank you sir!
<jamespage> marcoceppi, np
<_mup_> Bug #1212146 was filed: JuJu fails installing a unit (Failure: exceptions.KeyError: 'JUJU_ENV_UUID') <juju> <juju-jitsu> <maas> <twisted> <juju:New> <https://launchpad.net/bugs/1212146>
<utlemming> what is the PPA where Juju pulls its mongodb from for juju-core?
<jamespage> utlemming, ppa:juju/stable
<utlemming> jamespage: thank you kindly Mr. Page
<jamespage> sidnei, for the life of me I could not work out why the lxc provider was using and apt proxy of "http://localhost:8000"
<jamespage> sidnei, but then I realised it was using the setting from the host
<jamespage> sidnei, which is my case self refers
<jamespage> ...
<sidnei> jamespage: you can change the host to use 10.0.3.1 which is the lxc bridge
<jamespage> sidnei, yeah - testing that now
<sidnei> jamespage: im open to suggestions on how to improve that. hazmat suggested just assumming that if 3142 is listening on 10.0.3.1 just use that blindly, which i'm not a big fan of. squid-deb-client would auto-detect a proxy but that might be too magic.
<jamespage> sidnei, hmm
<sidnei> maybe the answer is just documenting
<jamespage> sidnei, in my setup I actually run squid-deb-proxy on my laptop
<jamespage> and I have it configured to use a peer squid-deb-proxy that I have at home if its contactable
<jamespage> otherwise it just goes direct to the archive
<jamespage> sidnei, the nice things is that everything is local off SSD with no network in the way
<jamespage> sidnei, I'd be open to adding squid-deb-proxy to the juju-local package on the list of Depends
<sidnei> jamespage: i don't have any preference, but pyjuju had apt-cacher-ng instead
<jamespage> sidnei, I never liked that personally
<jamespage> sidnei, squid-deb-proxy is in main, apt-cacher-ng is not
<sidnei> that's a pretty good argument :)
<sidnei> apt-cacher-ng has some advantages that you can tell it to mirror a whole repo and there's a way to purge unused files manually, but again, for someone that's advanced enough to care they can set that up themselves
<jamespage> sidnei, I agree its more repository aware
<jamespage> sidnei, but me likes squid :-)
<jamespage> sidnei, I swung big time when I realised it did intelligent peering
<jamespage> sidnei, although its nicer in that apt-cacher-ng will map all *.archive.ubuntu.com to a single source
<sidnei> *yes*
<jamespage> oh - and welcome back debug-hooks
 * jamespage had missed that
<sidnei> jamespage: ultimately, you're in a better position to advise how to auto-configure the containers and wether to pick squid-deb-proxy or apt-cacher-ng than me.
<jamespage> sidnei, OK _ lemme give it some thought
<arosales> jcastro, do you want to fire up the G+ for the weekly charm meeting?
<jcastro> DSJFGHWERTHJFWEDFSA
<jcastro> I totally forgot
<jcastro> ugh
<jcastro> I am totally unprepared
<jcastro> one sec.
<jcastro> https://plus.google.com/hangouts/_/62e91c8590f44673e739cf992bc2ac06bfebbc3d?authuser=0&hl=en
<arosales> Weekly charm meeting URL: https://juju.ubuntu.com/community/weekly-charm-meeting/
<arosales> ether pad: http://pad.ubuntu.com/7mf2jvKXNa
<arosales> For folks interested in joining our weekly charm meeting
<arosales> ^^
<ev> is there some trick to testing relation-get/relation-list outside of normal execution in gojuju. I vaguely recall being able to set the right envvars in pyjuju, but the socket path doesn't seem to stay around in gojuju
<ev> just trying to test a for x in relation list; do relation-get private-address $x; done
<sidnei> ev, debug-hooks is back
<ev> sidnei: I've never entirely understood debug-hooks. I run it, I get tmux, and then I'm supposed to add relations and things to see them pop up in additional windows?
<sidnei> ev, correct. you trigger any hook and it will pop a new window, where you can do some manual stuff and optionally call ./hooks/<hook>
<ev> but I'd like to just work with the current arrangement, rather than having to do an add-unit to force it to give me relation-get and relation-list
<ev> is this not possible?
<sidnei> it may be possible, i just never bothered
 * ev shrugs
<ev> I'll give that a try
<ev> thanks!
<ev> that worked. Thanks again, sidnei
<sidnei> \o/
<jcastro> arosales: ok I think I found a problem with the HP instructions
<jcastro> but it might be just me
<jcastro> in the instructions the tenant-name is like evilnick-project1
<jcastro> but in my HP cloud panel it's long number
<jcastro> arosales: https://bugs.launchpad.net/juju-website/+bug/1212396
<_mup_> Bug #1212396: HP Cloud instructions need update <Juju Website:New for evilnick> <https://launchpad.net/bugs/1212396>
<arosales> jcastro, are you looking at the tenant name or id?
<arosales> jcastro, in the HP console go to
<jcastro> yeah
<arosales> Account --> Manage Projects
<jcastro> right
<jcastro> that wasn't there before
<jcastro> which is why the docs are out of date
<arosales> you should see the project name, and then the ID
<jcastro> I know where it is now
<arosales> ya, the console has changed since the docs where screen cap'ed
<arosales> jcastro, what you want here is the "name" not the ID though
<jcastro> right
<arosales> jcastro, thanks for updating it. Let me know if you need me to validate anything
<jcastro> it's working for me now, did a deploy, etc.
<jcastro> I wonder if we can set a watch on an HP cloud console page
<jcastro> or if this will just be the nature of the beast
<marcoceppi> jcastro: tennant name, tennant id, project name are all the same (though different values) it's the "Project Name" now in HP Cloud
<adam_g> uh. with juju-core,  how do i remove a relation between two services, when a previous relation joined hook had failed?
<adam_g> agent-state-info: 'hook failed: "relation-joined"
<adam_g> remove-relation command succceeds, but the relation isn't actually removed. and i am unable to re-add it
<thumper> :(
<thumper> sounds like a bug
<thumper> adam_g: is there a --force or something?
<adam_g> thumper, doesn't look like it
<adam_g> FWIW, i see the unit attempting to fire the departed and broken hook. but in this case, the charm does not implement either
<marcoceppi> adam_g: we ran in to this yesterday. juju resolved the service
<adam_g> marcoceppi, huh?
<marcoceppi> adam_g: if service is in an error state you can't process anymore actions against it until the service/unit has been resolved. Meaning the remove-relation was accepted by bootstrap and is queued until you resolve the relation error on the unit.
<marcoceppi> running juju resolved aganist the machine until it drops out of error would then allow it to continue processing the events queued (removal) which would then allow you to re-add the relation
<adam_g> marcoceppi, oh, i read your last comment differently. yeah, i believe i tried to resolve the error and remove the relation
<marcoceppi> adam_g: I noticed, yesterday, that we had to run resolved a few times to get a unit back to health, fwiw
#juju 2013-08-15
<melmoth> is there a known issue with juju 1.12 with destroying-service ? Since i switch to juju >=1, destroy-service fails silently most of the time
<melmoth> the service are shown as dying, but nothing else seems to happen
<raywang> melmoth, i do have seen this
<melmoth> i do quite a lot those days
<raywang> melmoth, me too
<bac> hi mectors
<juju> hi
<juju>  8-)
<juju>  :p
<juju> hi
<juju>  hi is any one her
<geme> jcastro, can Debian / Redhat images be deployed ?
<jcastro> not currently no
<jcastro> I think debian has cloud-init now, all that's needed is for someone to do the work
<geme> I tried using Debian with juju awhile back - problems with cloud-init confg & upstart
<hazmat> jcastro, re the rack charm, tell the author he has bug in his config.
<hazmat> that's preventing the store publishing, fwiw
<geme> jcastro, Can different ubuntu images be used in the same environment ?
<jcastro> geme: like different versions?
<jcastro> or different images as in cloud images?
<jcastro> hazmat: got any more detail?
<jcastro> hazmat: or is it that encoding issue sinzui and him ran into?
<geme> yes - different ubuntu cloud images ?
<jcastro> we do what is defined in "series" in environments.yaml, we don't have a way to specifify a custom image, for example
<hazmat> jcastro, nothing to do with encoding he has a bad config default value .. config: options.deploy_key.default: unexpected value <nil>
<geme> So, just the one image available for say precise ?
<jcastro> geme: yeah it will fetch the latest supported cloud-image and deploy that
<jcastro> http://cloud-images.ubuntu.com/releases/precise/release/
<geme> jcastro, is there a timescale to support other oses ?
<jcastro> not really, any help would be accepted and appreciated, but we're not actively working on that at the moment
<arosales> smoser, utlemming: talking with mgz on bug https://bugs.launchpad.net/juju-core/+bug/1188126
<_mup_> Bug #1188126: Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured <canonistack> <openstack> <serverstack> <juju:New> <juju-core:Triaged> <https://launchpad.net/bugs/1188126>
<arosales> any way to tell cloud-init to bring up all detected networks?
<utlemming> arosales: generally with a cloud-drive you can send /etc/network/interfaces, but if they are using the EC2 meta-data source, then no
<arosales> utlemming, (brainstrom) any way to patch cloud init to take ingest a value to detect and init all attached networks (ie not stop in the first)
<arosales> smoser, ^
<hazmat> arosales,  i don't think it an issue of bringing up the network
<hazmat> afaik, the issue is that is being able to correctly identify which network juju should be using
<hazmat> given multiple
<arosales> hazmat, just an idea mgz and I were batting around. mgz would have more insights then myself
<geme> jcastro, attempting 1st bootstrap using juju-core 1.13.1 and it errors - http://*.*.*.*:8080/v2.0/AUTH_ca452007af584a7f933e6a3e281f1c85/juju-dist/"/"streams/v1/index.sjson": cannot find URL "http://*.*.*.*:8080/v2.0/AUTH_ca452007af584a7f933e6a3e281f1c85/juju-dist/streams/v1/index.sjson" not found
 * hazmat drops back to #juju-dev for it
<mgz> hazmat: I don't see why, in the elmo-case, we shouldn't expect both to work
<geme> should index.sjson be index.json
<mgz> (ie, they're trying to migrate an existing deployment to a new ip range, by adding an extra address to every instance)
<marcoceppi> geme: does it actually fail? AFAIK that's a common error during juju bootstrap -v but doesn't nessiarily mean it's failing. Is this a private openstack deployment?
<geme> yes - it's a private openstack
<marcoceppi> geme: Do you see any instances online started by juju in the dashboard? does juju status work? Was that the error that juju threw during bootstrap (actually, could you pastebin the the full output to the shell)
<geme> No instance deployed
<arosales> geme, sounds similar to the https://lists.ubuntu.com/archives/juju/2013-August/002826.html thread
<marcoceppi> Have you created image metadata for your dpeloyment using the juju metadata command?
<marcoceppi> finally, what version of juju are you using? (juju version)
<geme> yes - image metadata created and posted to the public-bucket
<geme> juju-core 1.13.1
<geme> error: cannot start bootstrap instance: no "precise" images in RegionOne with arches [amd64 i386]
<geme> pastbin url ?
<geme> pastebin url
<arosales> geme, http://pastebin.ubuntu.com/
<marcoceppi> geme: http://paste.ubuntu.com
<marcoceppi> ^^
<smoser> arosales, sorry. back now.
<smoser> ah. for ec2, there is a well identified solution.
<marcoceppi> geme: juju will attempt to access several locations. starting with .sjson, then .json, then public simplestream data
<smoser> that is simply just not implemented.
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1153626
<_mup_> Bug #1153626: Multiple Interfaces and IPs not detected in AWS VPC <aws> <cloud-images> <ec2> <vpc> <cloud-init:Triaged> <cloud-init (Ubuntu):Triaged> <https://launchpad.net/bugs/1153626>
<smoser> arosales, ^
<geme> marcoceppi, bootstrap -vv console output in pastebin
<marcoceppi> geme: can you paste the link please?
<geme> http://paste.ubuntu.com/5989532/
<marcoceppi> geme: what's the region set to in your index.json file?
<geme> RegionOne
<marcoceppi> geme: could you paste the results of that file in a pastebin
<marcoceppi> also, it's nearing bed time for me. So if you're unable to get futher assistance, feel free to post to ask ubuntu or juju@lists.ubuntu.com for "offline" help
<geme> index.json ?
<marcoceppi> geme: yes
<marcoceppi> geme: I'm also assuming the *.* in the addresses are just you anonymizing the data?
<geme> yes
<geme> http://paste.ubuntu.com/5989600/
<marcoceppi> geme: you dont' actually have any cloud data in there
<geme> ran this command - juju-metadata generate-image -i 65a1e7ba-eb56-48e6-9b4e-8f7c0c05e779  -s precise -r RegionOne -u http://15.25.24.11:5000/v2.0/
<geme> Am I missing something ?
<marcoceppi> geme: not sure he's an example working index.json file for hpcloud
<arosales> smoser, the conversation continued in #juju-dev between mgz and hazmat
<geme> marcoceppi, so the index.json is incorrect ?
<marcoceppi> geme: it's missing data, one sec
<marcoceppi> geme: what does imagemetadata.json look like?
<geme> http://paste.ubuntu.com/5989688/
<geme> marcoceppi, need to drop off. Pick up tomorrow ?
<marcoceppi> geme: yes, I need to do the same
<geme> ok - catch you tomorrow. Thanks
<sidnei> uhm, where do i make changes to https://juju.ubuntu.com/docs/charms-constraints.html ?
<jcastro> arosales: wotcha think: https://juju.ubuntu.com/events/
<juju> hi-
<arosales> jcastro, looks good, thanks for updating it
<arosales> lot of topics I am really interested in there too
<arosales> good content
<juju> hi
<marcoceppi> sidnei: lp:juju-core/docs
<sidnei> thanks marcoceppi
<irossi> jamespage, How's it going? Was wondering if you could help me with some strange issues?
<irossi> Hey can someone help me troubleshoot a strange Juju issue?
<arosales> irossi, its end of day for europe and america time zones so may be good to mail the list and get some help there.
<arosales> https://lists.ubuntu.com/mailman/listinfo/juju
<arosales> or leave a post on askubuntu
<irossi> OK thanks very much
<arosales> irossi, I can try to help, but may have to point you to the list or askubuntu
<irossi> arosales, Thanks. I have Openstack on 28 nodes deployed by Juju. Every once in a awhile, the juju machine agent starts to hog a lot of memory and I can't access the nodes.
<arosales> irossi, which juju version are you running?
<irossi> arosales, I'm able to reboot the bootstrap node, but it still shows instance-state: unknown while the agent-state is running
<sarnold> irossi: check log sizes, I think I've heard that juju logs never get rotated and can fill the disk they are on..
<thumper> we should fix that...
<sarnold> irossi: check df output on the inolved machines..
<arosales> sarnold, ah good point
<irossi> arosales, sarnold Checking on all of the above
<sarnold> thumper: we may have already, this might be old cargo-culting :)
 * thumper nods
<sarnold> all I know is tracking down problems due to full filesystems is -always- harder than it sounds.
<sarnold> so check them first :)
<arosales> sarnold, thumper so juju rotates logs on 1.13 >
<irossi> Most of the nodes are so pegged I can't ssh into them
<irossi> arosales, sarnold: Juju 0.7
<sarnold> arosales: excellent! thanks. :)
<arosales> sarnold, I was actually asking :-)
<arosales> I should have appended a "?" to that
<irossi> arosales, sarnold: Checking on the logs too
<sarnold> arosales: oh :) haha
<arosales> sarnold, but thumper would know the latest on log rotate in 1.13
<irossi> arosales, sarnold : So it Juju 0.7 too old? Are there bugs in that version that are good reason to upgrade? What's the recommended version?
<irossi> arosales, sarnold : 1.13 ?
<arosales> irossi, I don't know for certain the issue you are hitting is addressed in 1.13, but I would recommend it
<thumper> arosales: I don't actually know about the log rotation...
<irossi> arosales, What's the easiest way to upgrade?
<arosales> sudo add-apt-repository ppa:juju/devel && sudo apt-get update && sudo apt-get install juju-core gets you the latest
<irossi> arosales, Why devel? That doesn't sound stable...
<arosales> there is also sudo add-apt-repository ppa:juju/stable
<arosales> which is at 1.12
<thumper> haha
<arosales> just was saying that devel got you the latest version if you were looking for a comparison
<arosales> irossi, right now there is not a clean upgrade path from .7 to 1.13, but juju core devs are working on improving that.
<arosales> irossi, probably not the answer you wanted to hear :-/
<irossi> arosales, OK
<arosales> irossi, juju core devs are working on bugs such as https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1200878
<_mup_> Bug #1200878: Upgrade breaks existing pyjuju deployment <apport-collected> <papercut> <regression-release> <saucy> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1200878>
<arosales> and making a better transition story from .7 to 1.x
<irossi> arosales, So the upgrade path you describe, would you mind describing it a bit more and perhaps any risk?
<arosales> irossi, I would have to ping hazmat on the current upgrade story from .7 to 1.x
<arosales> not sure if he around atm
<irossi> arosales, Ok thx
<irossi> arosales, I'll check in tomorrow
<arosales> irossi, apologies, wish I had a better answer
<arosales> irossi, but I also don't want to give you false info either.
#juju 2013-08-16
<arosales> irossi, for upgrading from .7 to 1.x I am not sure of the steps needed
<hazmat> irossi, there is no upgrade path atm between the two for live migration, you can export and import the topology (config, services, machines, relations) with something like juju-deployer or the gui (hotkey shift-D), but its a fresh start effectively.
<rogpeppe> anyone know of a decent way of enumerating all the charms in the charm store? i did a screenscrape of the charm website ages ago and got 90, but i'd like to get as many as possible.
<rogpeppe> currently my best guess is going through https://code.launchpad.net/charms and looking for all lp:charms/xxx branches, but there's surely a better way
<axw> rogpeppe: charm-tool? "charm list" lists all the charm branches in https://code.launchpad.net/charms
<axw> you'd need to clean them a bit
<rogpeppe> axw: hmm, i didn't know about the charm tool
<axw> rogpeppe: it's basically just scripting what you just said anyway
<rogpeppe> axw: yeah, i've just done that anyway, but it would be nice to be able to make it automatic
<rogpeppe> axw: where did you find the charm tool?
<axw> rogpeppe: https://launchpad.net/charm-tools
<geme> marcocepp1, picking up from yesterday. Looks like there's a typo index.sjson in the code. When I upload an index.sjson in the public-bucket the bootstrap completes
<mattyw> I get permission denied (publickey, password) when try to juju ssh to local instance, have I missed something obvious?
<geme> juju-core 1.13.1 won't bootstrap on private openstack. /var/log/cloud-init-output.log reports : ERROR juju open.go:89 state: connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused. There's nothing running on this port.mongod is running on 27017 and 28017 thoght
<geme> bootstrap problems behind the firewall : Is there away to set proxy so that cloud-init can hit external apt repositories ?
<mgz> geme: if no one turns up, the best fallback is probably to describe your setup and issue on the juju mailing list, see lists.ubuntu.com
<geme> thanks
<geme> juju-core : what constraints are recogned ? instance-type doesn't appear to be.
<geme> recognised
<rick_h> geme: I believe you have to use ram/cpu
<geme> rick_h: openstack uses flavors ( ram/cpu combos ) which was supported in the python version
<geme> rick_h: you're correct --constraints "cpu-cores=8 mem=32G" picks the flavor. Thanks
<jamespage> hazmat, has anyone mentioned packages jujuclient and juju-deployer officially for Ubuntu?  getting nearish feature freeze - so if we want something in distro now is good :-)
<hazmat> jamespage, i haven't heard it mentioned but it sounds like a good idea, we've got ppa builds for both,  but  both are still under active dev. there's some new usage of core trunk features in a branch (api-endpoints, and switching out separate cli juju-plugins). what's nesc. to get a push into universe?
<_mup_> Bug #1213169 was filed: DB instance loses zookeeper access and drops pg_hba.conf entries for appservers, juju status shows no errors <juju:New> <https://launchpad.net/bugs/1213169>
<kurt__> Does anyone know the status of juju-gui in quantal?
<kurt__> Is it working?
<kurt__> I am trying to use it from here: cs:~pmcgarry/quantal/juju-gui and it appears to have some dependency reconcile issues
<hazmat> kurt__, it should work, the best way might to pull the charm local into a different series dir.. ie mkdir charms/quantal && cd charms/quantal && bzr branch lp:charms/juju-gui && juju deploy --repository=../.. quantal/juju-gui
<kurt__> Ok thanks.  I can try that.  The big problem I am running in to is nodejs conflicts with nom on the package install hook
<kurt__> nom rather
<kurt__> npm
<kurt__> hazmat: sorry, I'm researching usage of deploying juju locally - but could you check your juju deploy command for accuracy?
<kurt__> nevermind...
<kurt__> Can someone confirm juju-gui needs full internet access to work?  That will create problems when using maas since the clients may not necessarily need have internet access.  I see the install script trying to do an apt-get update and it bails (install-error) when it can't do it.
<kurt__> http://pastebin.ubuntu.com/5993501/
<kurt__> Per hazmat's instructions, I am using latest quantal branch install
<sarnold> kurt__: if your clients won't have internet access, you'll need a local mirror of some sort..
<kurt__> sarnold: the script appears to be wanting to do an update thoughâ¦when that fails, everything breaks - how do I resolve that part?
<sarnold> kurt__: I'd investigate some way to provide a local mirror that can satisfy an apt-get update; I think quite a few pre-written charms will expect that to work. charms you write yourself, of course, can wget sources from wherever :) but most charm authors will expect apt-get to work.
<kurt__> ugh, I think that breaks mass's cloud model
<kurt__> maas's rather
<sarnold> hrm. It might. :/
<kurt__> wouldn't it be prudent to check somehow if maas is the deployment model and then do the apt-get update accordingly?
<sarnold> another option is maas growing a debmirror function.
<hazmat> kurt__, that branch is trunk, its used to cut the precise release, the instruction i had there is for creating a local charm repository  with the trunk branch setup as quantal.. i don't understand what you mean by local usage, you can deploy an lxc container of precise on a quantal host.
<kurt__> I got it deployed
<hazmat> cool
<kurt__> thanks - but still dealing with the internet access problem for apt-get update
<kurt__> trying to set up NAT
<kurt__> sarnold: I now have internet issue solved, but same problem with juju-gui - I can post output from debug
<sarnold> kurt__: please do.. I figured that getting access to the archive would let you past that.
<kurt__> http://pastebin.ubuntu.com/5993717/
<kurt__> and output from apt-get update in client node: http://pastebin.ubuntu.com/5993719/
<kurt__> being run from a quantal client
<sarnold> kurt__: hrm. did you use add-apt-repository to add the ppa?
<kurt__> on the client? no - on the root node, yes
<kurt__> and juju-gui was being installed from the bzr branch
<kurt__> not that that matters
<kurt__> sarnold: I managed to use precise and finally got juju-gui working :D
<sarnold> kurt__: nice!
<sarnold> kurt__: was there something specific that fixed it?
<kurt__> I had to ensure the internal clients had internet access (NAT) and I used precise for the images instead of quantal
<sarnold> hrm, it might be worth a bugreport against quantal juju or juju-gui if just changing between precise and quantal is enough to fix or break it.
<kurt__> that allows the client's clock to sync properly.  Even though its in EST, it's still correct.
<kurt__> that solved my OAuth problems
<kurt__> there is no quantal release of juju-gui
<sarnold> ah, makes it hard to file a bug then :)
<kurt__> :D
<kurt__> but, I don't know what the latest bzr branch is based on
<kurt__> that is two weeks worth of work finally solved
<kurt__> phewww....
<sarnold> yeah, me neither. the juju team is in a bit of a tough spot since precise is where people will have deployed workloads that they need supported, but they are trying to make the next lts, 14.04, as awesome as they can. most people get to just maintain the old stuff, but they were ambitious and wanted new stuff on older platforms too..
<kurt__> is 14.04 LTS?
<sarnold> of course all the charms are another matter, people again have precise-based workloads, but some people wanted features from newer releases..
<sarnold> kurt__: that's the current plan; I think it'd take an immense event to change it..
<kurt__> right
<sarnold> and since 13.10 appears to be shaping up well, every thing feels to be on track -- to me, anyway :)
<kurt__> are you canonical?
<kurt__> with rather
<sarnold> kurt__: yes, I am, but not on the juju team, I'm just an enthusiast there :) hehe
<kurt__> ah ok - what's your specialty then?
<sarnold> kurt__: security
<kurt__> i c
#juju 2013-08-18
<hazmat> kurt_, you can file bugs against the gui charm directly against the upstream (launchpad.net/juju-gui)
<hazmat> kurt_, whyat i don't understand is why its problematic to deploy the gui on an lts instead of quantal for your use case
<kurt_> Does anyone know if keystone works off the shelf in Precise with juju-gui?
<thumper> I don't know what is worse, saying "No" or saying nothing...
<thumper> all I can say is I don't know
<thumper> but someone may :)
<kurt_> :)
<kurt_> seeing an error about missing config option for vip
<kurt_> 2013-08-18 14:16:11,995 unit:keystone/3: unit.hook.api INFO: FATAL ERROR: ERROR: Config option has no paramter: vip
<kurt_> but in the nice pretty demo I look at that Mathew Scott put together, it appears to work off the shelf
<weblife> I want to use juju within the free tier of AWS but when I run : juju bootstrap --constraints "instance-type=t1.micro"  I am getting the following error :  error: invalid value "instance-type=t1.micro" for flag --constraints: unknown constraint "instance-type"
<weblife> Has something changed? Or what the heck am I doing wrong?
<jrwren> weblife: have you not bootstrapped?
<weblife> I am trying to bootstap to a t1.micro and not a m1.medium
<weblife> according to the documentation this should be legal: juju bootstrap --constraints "instance-type=t1.micro"
<thumper> weblife: the new juju, version 1.x doesn't support instance-type constraints yet
<weblife> thumper: blah(lol), thank you.  I wanted to use it on the AWS free tier.  Just got a bill for $247 because I didn't realize they charge on anything higher than t1.micro. Luckily they waived it this time once I called them.
<marcoceppi> weblife: you can specify mem=128 to get a micro
<marcoceppi> weblife: it's also only 700 hours of micros a month. so if you run 14 micros for 50 hours each additional hour per machine is billed to you
<marcoceppi> personally, I found hpcloud to be way cheaper. with local provider being the cheapest :)
<weblife> marcoceppi: you life saver, its actually 750 now.  I am looking into trying to use it to deploy a single website on 1 server,  kinda defeats the purpose of using juju i know.
<weblife> marcoceppi: it actually launched a m1.small instance when using that constraint.  Thank you. Guess I'll have to wait for the 2.0 bootstrap change or whatever option appears for this.  HPCLOUD only allows 1 instance free per month for the first three months(blah). I see what your saying though for larger go-live deployments though, thanks for that tip.
<marcoceppi> weblife: there's a way to get a micro using constraints. I think the cpu-power needs to be tweaked too. Try setting cpu-power, cpu-cores to 0 and mem really low (it'll find the next highest match) like 128, 256
<weblife> marcoceppi:  that worked.
<jrwren> weblife: what settings got you to micro?
<weblife> juju bootstrap --constraints "cpu-power=0 cpu-cores=0 mem=128" : Hard to say which actually pushed it to t1.micro as marcoceppi mentioned it will find the highest match but my bet is on cpu-cores=0. Try to find out for sure in a little bit for you.
<weblife> kinda strange, I don't know how doing a 'make -j' would react on other services but with ec2 it makes the compiler error.
<kurt_> Anyone know what the correct openstack nova-compute distro to use with juju-gui is?
<kurt_> I've tried essex, folsom and grizzly and on folsom and grizzly getting some 403 errors
<kurt_> http://pastebin.ubuntu.com/6001151/
<weblife> kurt_ not sure but I know with node-app you sometimes need to refresh once or twice to get it going
<kurt_> weblife: yes, I've tried a few times.  I don't know enough about repositories to know if I need to add something or not
#juju 2014-08-11
* lazyPower changed the topic of #juju to: Welcome to Juju! || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP || Weekly Reviewers: mbruzek & jcastro || News and stuff: http://reddit.com/r/juju
<mattyw> jamespage, do you think it should be possible to do a naive install of openstack using this kind of script using juju local? http://paste.ubuntu.com/8016698/. The reason I ask is I'm getting an "Couldn't acquire DPKG lock. Will retry in 10 seconds." error when deploying nova-compute
<jamespage> mattyw, nova-compute won't deploy under LXC
<jamespage> well it will try and be completely non-functional
<jamespage> mattyw, as to why you are getting a dpkg lock - not sure
<mattyw> jamespage, ok  thanks
<khuss> looking for some help with nova-compute charm
<khuss> when nova-compute is executed, it setups the nova.conf file. How does it get the IP address information of various services such as neutron gateway, glance, os controller etc?
<marcoceppi> khuss: that happens when you add relations to those services
<khuss> marcoceppi: yes.. it does. but my question how does it actually determine the IP address of lets say, glance
<marcoceppi> via those relations
<marcoceppi> so that information is fed through nova-cloud-controller to nova-compute iirc
<marcoceppi> something likethat
<marcoceppi> it's all over relation wire
<khuss> marcoceppi: I'm adding some additional hooks to configure different files.. trying to figure out ip address of glance, for example
<marcoceppi> khuss: then you'd need to add a relation from glance to the nova-compute charm if it doesn't already have that information
<khuss> marcoceppi: i know it happens when you add the relations so my question how do those hooks actually determine the IP of os-controller, glance etc
<marcoceppi> in the relation hook, it calls something like `relation-get private-address`
<marcoceppi> or whatever the interface deems is the hostname/ip key for that service
<khuss> marcoceppi: lets i'm adding relation from nova-compute to cinder
<khuss> marcoceppi:  in the cinder-joined hook, I can do relate-get private-address to get the ip of cinder?
<marcoceppi> khuss: yeah, `relation-get private-address` will always have the ip of the unit
<marcoceppi> but there may be another key to get instead, since some of the openstack charms allow you to configure ip/networking for services
<marcoceppi> you'd have to look at the cinder charm and look at it's hook for what it provides
<khuss> marcoceppi: thanks for that info. Is there a way I can simulate the charm environment to test these hooks without going through the entire life cycle?
<jcsackett> s
#juju 2014-08-12
<gnuoy> jamespage, your thoughts on https://code.launchpad.net/~gnuoy/charms/trusty/nova-cloud-controller/disable-services-until-db-ready/+merge/230495 would be greatly appreciated if/when you have a moment
<jrwren> What is the right way to use charmhelpers.core.hookenv.relation_get ?  I do not like that it is outputting errors.
<marcoceppi> jrwren: what errors are you getting?
<jrwren> no relation id specified
<marcoceppi> jrwren: is this being called out of band of a relation call?
<marcoceppi> of a relation hook*
<marcoceppi> alternatively, just supply the current JUJU_RELATION_ID
<marcoceppi> from os.environ
<marcoceppi> jrwren: give me a min to open the code, the docs are light on this one
<jrwren> yes, out of band. I should look it up.
<marcoceppi> jrwren: docs are here, FYI: http://pythonhosted.org//charmhelpers/api/charmhelpers.core.html#charmhelpers.core.hookenv.relation_get
<marcoceppi> jrwren: in that case you need to provide the JUJU_RELATION_ID and the unit you wish to query this information
<marcoceppi> during a relation hook, both JUJU_RELATION_ID and JUJU_REMOTE_UNIT are environment variables set in the hook environment
<marcoceppi> jrwren: hum, the docs are out of date with the function signature
<marcoceppi> you pass unit and relation_id as parameters
<marcoceppi> elation_get(attribute=None, unit=None, rid=None)
<marcoceppi> relation_get(attribute=None, unit=None, rid=None)
<marcoceppi> tvansteenburgh: can we get the docs re-generated?
<jrwren> marcoceppi: where are the format of rid and unit documented?
<marcoceppi> jrwren: the format are the values of JUJU_RELATION_ID and JUJU_REMOTE_UNIT respectively
<marcoceppi> remote unit being in the format of "service/#"
<marcoceppi> relation id is typically "text:#"
<marcoceppi> you can query them using relation_id
<marcoceppi> you can query them using relation_ids*
<jrwren> I didn't have much like with any of that when I was debugging the hooks. I'll try again.
<marcoceppi> jrwren: they're only set during the execution of a relation hook
<marcoceppi> so you'll want to cache them somewhere
<marcoceppi> so you can use them later
<jrwren> marcoceppi: huh, ok. so... no point in aiming for stateless hooks?
<marcoceppi> alternatively, you can list all the relations_ids, find the relation_id you want, then get all the units
<marcoceppi> jrwren: you can do that
<marcoceppi> jrwren: IIRC, relation-id is comprised of <relation-name>:<an-arbitrary-number>
<marcoceppi> so you can infer what relation_id you need by checking the start of the string of the list of items core.hookenv.relation_ids() provides
<jrwren> marcoceppi: This sounds good.
<marcoceppi> then there's core.hookenv.related_units(rid) which will give you a list of all the units in that relation id
<jrwren> marcoceppi: isn't that a different format of rid?
<marcoceppi> using those two pieces of information, jrwren, you should be able to loop through and call relation_get(rid=relation_id, unit=u)
<marcoceppi> rid and relation_id are interchangable in this context
<jrwren> marcoceppi: the call to related_units() still takes a relation:# format? will it work even if # doesn't exist?
 * marcoceppi will bug Tim VanSteenburger to update the docs on pythonhosted.org
<marcoceppi> jrwren: probably not, that depends on how flexible juju is
<marcoceppi> since it's just a passthrough to `relation-units -r <relation_id>`
<jrwren> marcoceppi: Then list and startswith it shall be.
<marcoceppi> worth a try, but I'm guessing no
<jrwren> marcoceppi: understood. The source is easy enough to read, its just what <relation_id> is there, which is unknown.
<marcoceppi> right, that's something juju makes up
<marcoceppi> typically out of thin air ;) but should follow relation:<id>
<marcoceppi> the idea being, if you break and recreate
<marcoceppi> you'll get a new unique relation id
<marcoceppi> which may or may not be incremental from the last
<jrwren> It would be very nice if all this was documented on links from https://juju.ubuntu.com/docs/authors-charm-writing.html too.
<marcoceppi> jrwren: it's on the roadmap
<marcoceppi> both charmhelpers and better author docs
<jrwren> marcoceppi: Thank you for your help.
<marcoceppi> jrwren: np, feel free to ping if you have any others
<marcoceppi> fwiw, a lot of the openstack charms have atomic-like functions that do relation calls, so there's use of this pattern in charms already
<jrwren> marcoceppi: I cannot call relation-ids or relation-list without a relation name
<jrwren> marcoceppi: I'm pretty sure that hookenv.relation_ids() will always fail.
<jrwren> marcoceppi: As will hookenv.related_units()
<marcoceppi> related_units needs a relation_id
<marcoceppi> jrwren: it looks like relation-ids takes a relation now
<marcoceppi> which is cool
<marcoceppi> jrwren: so you can say, "db" or whatever the relation name is
<marcoceppi> and get the ID that way
<marcoceppi> isntead of having to iterate through a list
<marcoceppi> you'll either get a value or None iirc
<jrwren> that is good.
<marcoceppi> rather, a list of relation ids
<marcoceppi> for that relation
<marcoceppi> in case there's more than one
<marcoceppi> IE, MySQL -> WordPress, MySQL -> MediaWiki
<marcoceppi> query database on MySQL you'll get two relation ids
<marcoceppi> loop through the ids to get the units, etc, etc
<jrwren> marcoceppi: indeed. I must have misunderstood what you wrote before.
<oskars> hey all, has anyone set up multiple l3 agents with the quantum-gateay charm?
<oskars> I feel like i'm frustratingly close to getting it working, but i'm getting a TooManyExternalNetwroks exception in the nova-server logs.
<oskars> it also seems to be taking away my ability to spell things correctly
#juju 2014-08-13
<gnuoy> jamespage, another review for a LS blocking bug if you have a moment https://code.launchpad.net/~gnuoy/charm-helpers/bug1354471/+merge/230593
<jamespage> gnuoy, merged
<gnuoy> thanks
<gnuoy> jamespage, I've created a bunch of mp to sync charm-helpers into the next charm to pickup the srcpkgcache fix from earlier if/when you have a moment
<jamespage> gnuoy, if its just a resync then auto +1
<jamespage> merge away
<gnuoy> jamespage, Mostly it is, on a few I've added the charmhelpers sync smarts and I had to fix a unit test in the keystone charm
<gnuoy> are you happy for me to go ahead with all of them ?
<jamespage> gnuoy, yes
<gnuoy> thanks
<mfa298> I've been playing with a small ceph cluster using three nodes (using the ceph) charm. I pulled one node out with a juju remove-unit ceph/1 altered the hardware (added drives and changed network cards around), recommisioned in maas and then rebuilt is as a new unit however it doesn't seem to be rejoining the cluster and the mon list on the other nodes hasn't updated. any suggestions as to what to look at
<jamespage> mfa298, hmm - pulling part of the mon quorum like that is probably not a great idea
<jamespage> I'm not sure the cluster bootstrap process will support that
<mfa298> that doesn't bode well for running something similar in production
<mfa298> If a node failed I'd want to be able to replace it easily
<jamespage> mfa298, I'd need to check
<gnuoy> jamespage, I have a similar set of updates for the stable charms (add
<gnuoy> charm helper smarts and sync)
<gnuoy> should I create mps for those ?
<jamespage> gnuoy, yes pls
<gnuoy> will do, ta
<mfa298> it also looks like the replacement node isn't setting up extra OSDs
<mfa298> jamespage: any thoughts on how I might be able to fix that ceph cluster.
<mfa298> could one (drastic) option be to delete the ceph service, then re-create it with the format-osd option set to off ?
<mfa298> I'm assuming that would then recreate it and find the existing OSDs to use
<jamespage> mfa298, you have two service unit remaining right?
<mfa298> yes
<mfa298> The plan was to change out the hardware on all three but do one at a time and wait for things to re-sync so the cluster kept quorum
<jamespage> mfa298, looking at the code, I can't see why introducing a new ceph service unit would not initiate it correctly into the cluster
<jamespage> mfa298, I wonder if its something todo with reuse
<jamespage> mfa298, let me test somehting
<mfa298> the OSD drives changed (although I still have the original) but I wiped the OS drive and the interface being used to build it from maas changed (was on a 10G card I wanted for something else)
<mfa298> although I didn't wipe the box from maas (just did a re-commision) but I don't think that should have caused an issue
<jamespage> mfa298, so the new mon daemon is joining OK?
<jamespage> mfa298, OK - so here is what I just tested successfully
<jamespage> small three node ceph cluster; destroyed and terminated one of the nodes via juju, added a new node
<jamespage> bootstrapped into the cluster OK - appeared in MON list, new OSD inserted
<jamespage> I had to remove the old node OSD and MON entries via the command line
<jamespage> that I would expect;
<mfa298> that sounds similar to what I did
<mfa298> I had three nodes, each running MON and OSD, I did juju remove-unit ceph/1 and juju terminate-machine 22 to remove the node
<mfa298> then changed bits of hardware then did juju add-unit ceph to add it back in. IP of the node then changed as the hardware had changed.
<mfa298> As it's the same machine in MAAS but using a different interface I wonder if the maas and juju side have got confused (I found maas remembering old IP's once before when it probably shouldn't have)
<mfa298> juju status is showing the node as started but it doesn't seem to have created the OSD and it didn't update the ceph config for the new mon IP (although it sounds like you had to change some of that manually from what you said)
<ctlaugh> The openstack-dashboard charm (among others) seem to overwrite /etc/network/interfaces and create a bridge with eth0. My MAAS preseed file had previously enabled eth1 as well, but now it is not getting enabled. Is there a way to get both eth0 and eth1 up without the charm(s) undoing it?
<jamespage> mfa298, I think its some sort of confusion
<jamespage> possibly due to the IP change
<jamespage> mfa298, I did not update any ceph configuration files - the operations I did where using the cli tools to ceph mon rm <oldmon> and some similar things for the old osd references
<mfa298> the ip changing confusing things seems likely
<mfa298> I've not manually run any ceph commands, I was hoping juju would handle it all but it seems like that might be the route to take.
<mfa298> I might try removing it fully from juju and maas first tomorrow and see if that makes it recover at least then hopefully everything will thinks it's a completely new node.
<mwhudson> why does the maas provider move eth0 onto a bridge?
<jamespage> mwhudson, for use with LXC or KVM containers
<jamespage> mwhudson, its a little raw
<mwhudson> jamespage: ctlaugh is trying to use it on nodes with two nics
<mwhudson> and it seems to be messing things up
<jose> mbruzek: how is that thing that you cannot promulgate a charm without an icon? since when have we had this problem?
<mbruzek> jose, I don't know how long we have had it but now the promulgate command runs charm proof and halts on anything W and E
<jose> mbruzek: I'll open a thread about it, seems nonsense to me
<mbruzek> The cakephp charm looked good to me otherwise.
<jose> we do have charms without icons in the store atm
<mbruzek> jose I already took this up with marcoceppi
<jose> yeah, I quite liked how it got there
<jose> mbruzek: oh, I'll leave it there, then. keep me informed on the output, please :)
<marcoceppi> jose: it's always been policy
<marcoceppi> you can't promuglate without proof passing
<marcoceppi> proof has just evolved overtime
<jose> marcoceppi: you told me without Es, but nothing about Ws
<mbruzek> jose I really wanted to approve the cakephp charm
<jose> I don't see anything bad on a warning
<jose> in this case, for example, it's throwing a warning because there's no icon due to the author asking for permission to the organization
<jose> and... it's just an image. I agree, it may not look awesome in the GUI, but Juju is about services, and in this specific case it deploys it perfectly and runs awesome
<marcoceppi> jose: there's nohing stopping the author form creating a temporary icon
<marcoceppi> for the time being
#juju 2014-08-14
<html> hi
<mfa298> jamespage: looks like success. I used the ceph tool to remove the mon and osd in ceph and removed the node from maas. Then added it back into maas and used juju add-unit and it seems to have setup the monitor. I'm not sure it's got the OSD yet but that could be due to bad gpt partition table.
<mfa298> next bit will be waiting for it to come up properly (currently has clock skew) and for the osd's to rebalance then I'll try the next node.
<lazyPower_> natefinch: wrt: reviewboard - whats the question being proposed? teh charm has been accepted to the store. https://jujucharms.com/precise/reviewboard-1
<natefinch> lazyPower_: sorry, I should have given more context.  we're trying to set it up for use with juju core and github, with a plugin so we can log in with our github usernames.
<lazyPower_> natefinch: ah ok. I thought it was with relation to teh service not having been charmed yet or something. *hattip* ok glad its nothing thats pending on ~charmers
<natefinch> lazyPower_: thanks for pointing out my email was too vague :)
<mattyw> stokachu, ping?
<stokachu> mattyw, hey
<zirpu> is it possible to 'expose' a service to a specific IP or set of IP addresses?
<zirpu> or is that a planned feature? (i haven't search the issues list yet.)
<sarnold> zirpu: I think the solution would be preparing a subordinate service that runs appropriate ufw or iptables commands yourself; the different cloud providers have different granularities on their "security groups"
<natefinch> jcastro, marcoceppi: do you guys have time to talk about charmer pain points today?
<zirpu> sarnold: agreed. i'd already thought about that. just was hoping it was included as a possible parameter to 'expose'.
<sarnold> zirpu: agreed :)
<marcoceppi> natefinch: I do!
<natefinch> marcoceppi: for a minute I thought you guys didn't have any complaints, and I was just going to stay home for the rest of the week :)
<natefinch> ....the joke is funnier when you don't work from home :/
<marcoceppi> natefinch: hah, you wish. was otp
<marcoceppi> natefinch: what you want to know?
<natefinch> marcoceppi: have you seen this: https://docs.google.com/a/canonical.com/spreadsheets/d/1ZC76hkbxDF7idcSbU9DI-homfom224q484HOLNFSIM8/edit#gid=0
<marcoceppi> natefinch: not yet
<natefinch> marcoceppi: take a look, let me know what you think about the charmer stuff... my team will be working on those.  Mostly, I need details on how you'd like it to work.
<ayr-ton> Guys, is possible to make a charm that deploy and setup other charms?
<natefinch> marcoceppi: meeting time for me
<marcoceppi> ayr-ton: technically, yes, but it's not a very clean and pretty thing
<marcoceppi> natefinch: want me to just dump them here? or email? or?
<ayr-ton> marcoceppi, What is the best practice for do something like this? For example, if I want to setup a jenkins master, 4 runners, a gitlab server, a sonarquobe and integrate this. Like, calling a script with all the steps.
<natefinch> marcoceppi: let's hang out later today if you have time
<ayr-ton> Like, I want to setup this enviroment in my development machine, with a script. And then, push this to another juju environment.
<marcoceppi> natefinch: i have time for this
<marcoceppi> ayr-ton: that's a bundle
<ayr-ton> marcoceppi, hmmm
<marcoceppi> ayr-ton: a bundle is a static representation of a deployment with configuration and relations coded in
<natefinch> marcoceppi: cool... in a meeting for the next 30-60mins but any time after until 5 is  cool
<marcoceppi> natefinch: I've got a standup at 3p, I'll ping after that
<ayr-ton> marcoceppi, this: https://juju.ubuntu.com/docs/charms-bundles.html?
<marcoceppi> ayr-ton: yeah, that's the doc page, I'll link you to a few examples too.
<marcoceppi> ayr-ton: http://bazaar.launchpad.net/~maarten-ectors/charms/bundles/presto/bundle/view/head:/bundles.yaml is an example and here's a bunch more: https://code.launchpad.net/charms/bundles
<ayr-ton> marcoceppi, thank you very much (: It is enough to get started.
<jcastro> natefinch, marcoceppi, let's hop on a G+
<marcoceppi> jcastro: he's in a meeting, we should sync post-our-daily
<jcastro> marcoceppi, that link nate showed you is the addition of all the feedback from our team, plus others.
<marcoceppi> jcastro: yeah, it's awesome
<sebas5384> uhuuu! https://bugs.launchpad.net/charms/+bug/1315428 "fix commited"
<mup> Bug #1315428: Review needed: Drupal Charm <drupal> <Juju Charms Collection:Fix Committed by sebas5384> <https://launchpad.net/bugs/1315428>
<sebas5384> what that means? :P
<marcoceppi> sebas5384: it changes nothing, justsome testing with the new review queue
<sebas5384> ahhh :(
<sebas5384> hehe
<sebas5384> marcoceppi:I run to the charm store to see if the charm was recommended hehe
<marcoceppi> sebas5384: fix released is when it gets promulgated
<sebas5384> ahhh ok marcoceppi thanks :)
<lazyPower> hey hatch - http://blog.dasroot.net/the-power-of-community-charming/
<hatch> loooking
<hatch> your blog looks so good
<lazyPower> O_o
<lazyPower> thanks
<sebas5384> awesome post hatch :)
<sebas5384> wops!
<sebas5384> lazyPower: sorry now that i sow it was yours hehe
<hatch> haha THANKS
<hatch> :P
<lazyPower> Thanks :D
<lazyPower> if you dont mind, syndicate that. We need to get the word out about personal namespaces being the recommended path for starting - i've got a todo item to updat the docs as well
<lazyPower> We should see that land sometime by early next week.
<marcoceppi> yo natefinch
<natefinch> marcoceppi: sorry, stepped out for a bit.  Want to talk now?
<marcoceppi> natefinch: yeah jcastro ^^
<jcastro> I have a call, but pass me the URL
<jcastro> I'll join after
<natefinch> marcoceppi: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
<MrDan> Hi to all.  Can anyone help me get my head wrapped around the differences between Salt and Juju?
<MrDan> Are they simply two different approaches to the same problem, or are the complementary tools.  I'm obviously a noob.
<thumper> MrDan: I'm not really familiar with salt
<thumper> MrDan: juju is not just about setting up environments, but also making sure the different services communicate
<thumper> and keep communicating as things change
<MrDan> thumper: my understanding is that Saltstack has been adopted by LinkedIn among other large sites.
<MrDan> thanks for the reply, though.
<thumper> MrDan: sure, there are many users of all the deployment tools
<MrDan> thumper: One of the differences I see from just a very cursory reading of Salt - it provides remote execution management.  Am I correct in thinking this might make a good complement for Juju?
<thumper> MrDan: juju has some now, and gaining more with actions
<MrDan> Ah.  Interesting.
<MrDan> I just came across the "salt-master" charm.  Looks like I need to do some more digging.
<MrDan> thanks for the feedback.
<MrDan> One small rant about this space.  The cheeky vocabulary used by tools like Chef, Puppet, Salt, etc.... is more hurdle than help (IMHO).
<thumper> cheeky?
<MrDan> As an example, since I've been talking about Salt, it has "minions", "pillars", "grains", etc....
<MrDan> More thematic than helpful.
<MrDan> maybe "cheeky" is the wrong work.
<MrDan> *word
<lazyPower> MrDan: Salt is very much a config management toolchain. Juju is a layer above that
<lazyPower> juju can orchestrate a salt stack, and push salt to the limits of its capabilities by providing information outside of salt that juju then plugs into a remote (salt, chef, bash, python, puppet, etc) CM framework to perform operations.
<lazyPower> Juju is like the all powerful all knowing oracle of your deployment infrastructure
<lazyPower> and it makes things dead simple when you combine that with the simplicity of the Juju GUI
<lazyPower> so to think of Juju as just config management of machines is only the first step, its also responsible for scaling, relations between services in a SOA approach, and has some capacity to do more with the use of juju-run and well scripted tasks.
<MrDan> lazyPower: that's helpful.
<lazyPower> MrDan: a bit wordy in terms of adverbs - but juju really is an amazing tool with what it brings to the table when you consume well written charms.
<lazyPower> are there any specific questions you have about juju that I may be able to answer for you?
<MrDan> Unfortunately, my inquiry is still at the forest level.  I have a lot more digging to do, but am impressed with the responsiveness of this group.
<lazyPower> We try to be. Community is our biggest winner when you go with juju - the charm store is an amalgamation of a community of effort.
#juju 2014-08-15
<thumper> lazyPower: so much more eloquent than me
<jamespage> congrats dpb1!
<mattyw> stokachu, morning mate, got another question for you I'm afraid
<rharper> can you specify the location of the environments.yaml file ?
<rharper> something else besides ~/.juju/environments.yaml ?
<lazyPower> rharper: you can by setting JUJU_HOME
<lazyPower> but the directory structure will need to reflect that of whats in ~/.juju
<lazyPower> stub: pingaling
<rharper> lazyPower: excellent, thanks!
<dpb1> thanks jamespage!  good to be on the team. :)
<lazyPower> :) We're happy to have ya dpb1
<rick_h__> tvansteenburgh: any chance we could get a +1/merge on https://code.launchpad.net/~evarlast/charm-tools/warn-description-newlines/+merge/230899 ?
<rick_h__> tvansteenburgh: jrwren ran into some fun chasing that down this week ^
<tvansteenburgh> rick_h__: sure, i'll take a look
<rick_h__> ty much kind sir
<lazyPower> tvansteenburgh: pulled, merged, ran tests
<lazyPower> LGTM
<rick_h__> lazyPower: oh thanks, beat him to it!
<lazyPower> I'm letting tim run point - but i gave it a +1 review :)
<tvansteenburgh> somebody convince me we shouldn't allow newlines in an option description
<lazyPower> i can't do that, because newlines keep it readable in the yaml. Occasionally in the GUI when it gets smashed together its hard to read. so i'm +1 for newlines - but the linter appears to be checking for the presence of the pipe character for newlines.
<rick_h__> tvansteenburgh: yea, it's a yaml parsing thing I think
<rick_h__> jrwren: ^
<tvansteenburgh> no, it's just checking for \n afaict
<tvansteenburgh> according to the bug, "we don't want newlines b/c `juju get` formats them badly"
<jrwren> tvansteenburgh: https://bugs.launchpad.net/juju-core/+bug/1292116
<mup> Bug #1292116: juju get output is ugly (broken line wrapping and escape characters) <canonical-is> <config> <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1292116>
<lazyPower> ah you're right, line 0 only checks for \n
<lazyPower> its not even looking for carraige return...
<lazyPower> O_O I STILL +1 THIS
<tvansteenburgh> i think it's more appropriate to fix `juju get`
<jrwren> Part of the issue AFAICT is that yaml Marshal/Unmarshal is not round trippable for formatting.
<tvansteenburgh> marcoceppi, you have any opinion on this?
<jrwren> If you use | or > on input, in config.yaml, and then Unmarshal to yaml as juju get does, you do not get | or >, you get quotes and ugly newlines.
<marcoceppi> otp, brb
<tvansteenburgh> jrwren: my thinking was that `juju get` could clean up it's formatting by stripping newlines
<tvansteenburgh> s/it's/its/
<jrwren> tvansteenburgh: i don't know the goals around juju get output.
<jrwren> tvansteenburgh: I suggest that yaml Unmarshal and them manipulating that output would be very error prone, especially to maintain valid yaml, if that is a goal.
<jrwren> tvansteenburgh: Good data out starts with good data in. This helps keep good data on input.
<tvansteenburgh> jwren: that's not the goal, we don't need to go back to yaml, just display the contents in an easy-to-read fashion
<jrwren> tvansteenburgh: Its not easy-to-read now. This change lets proof find places that it is not easy-to-read.
<tvansteenburgh> jwren: it *is* good data in though, it's perfectly valid yaml. i think imposing arbitrary restrictions on which yaml contructs can be used would lead to a suprising user experience
<tvansteenburgh> jwren: my point is that we could make it easy to read by fixing the way the data is displayed, not by imposing restrictions on the data itself
<jrwren> tvansteenburgh: Maybe surprising at first, and then not surprising.
<tvansteenburgh> jrwren: :)
<jrwren> tvansteenburgh: If that is the path you choose, that is fine. I find the current state unacceptable and I may submit merge requests for everything in charmstore to fix their text which is displayed poorly today.
<tvansteenburgh> jrwren: why not just submit a patch to fix juju get?
<marcoceppi> tvansteenburgh: whats the tldr?
<tvansteenburgh> marcoceppi: https://code.launchpad.net/~evarlast/charm-tools/warn-description-newlines/+merge/230899
<jrwren> tvansteenburgh: becasue I find it the wrong solution :)
<tvansteenburgh> jrwren: ok, then we disagree. i'll let marcoceppi be the deciding vote
<marcoceppi> tvansteenburgh: drop your opinion in the merge
<marcoceppi> jrwren: what does juju get look like with newlines?
<marcoceppi> does it show \n or what?
<tvansteenburgh> marcoceppi: https://bugs.launchpad.net/juju-core/+bug/1292116
<mup> Bug #1292116: juju get output is ugly (broken line wrapping and escape characters) <canonical-is> <config> <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1292116>
<marcoceppi> yeah, this is a core issue
<marcoceppi> making YAML human readable is kind of it's point
<marcoceppi> some of these options are huge, like the openstack-origin, which include code examples, etc
<jrwren> marcoceppi: all of those can still work, just don't use | or >
<jrwren> marcoceppi: just wrap normally
<marcoceppi> jrwren: but that's the point of | > and it's multiline string
<marcoceppi> otherwise you have to start escaping ' and "
<marcoceppi> juju just isn't respecting the YAML spec
<marcoceppi> fwiw, if I can find where this is in core I might be able to patch it
<marcoceppi> it's either change 200 charms which are following YAML spec
<marcoceppi> or fix core
<jrwren> marcoceppi: ok.  fwiw, neither pyyaml or goyaml currently round trip those correctly.
 * marcoceppi reads the spec
<marcoceppi> hum, I mean, thanks for trying to tackle this jrwren, but this presents a huge task for ecosystem if it's indeed merged
<jrwren> marcoceppi: ok. gl with that bugfix. I think it will be challenging.
<marcoceppi> jrwren: yeah, I'll take a task to investigate this later tonight
 * marcoceppi fears golang no more
 * jrwren never fears golang, he just isn't very good with it... yet.
<marcoceppi> oh, well we're both in the same boat then ;)
<jrwren> marcoceppi: in what TZ are you? What time are you thinking? If I'm available, can I pair with you?
<marcoceppi> jrwren: I'm EDT, probably going to take a stab around 20:00, but might not get to it until Monday
<marcoceppi> want to take a stab at it monday for sure?
<jrwren> marcoceppi: sure. I am EDT also. Sounds like a plan.
<marcoceppi> jrwren: cool, I'll ping you Monday and we can pair up on this and knock it out
<sinzui> bac, rick_h__ I fixed juju-reports, I think charmworld has the same problem since we created both sites, see bug 1357403
<mup> Bug #1357403: Charmworld is a single user website <charmworld:Triaged> <https://launchpad.net/bugs/1357403>
<rick_h__> sinzui: looking
<mbruzek> Hello jose.  CakePHP landed this morning thanks to Frederico's icon.
<mbruzek> Thanks for your feedback jose
<mbruzek> http://manage.jujucharms.com/charms/precise/cakephp
<sebas5384> great news! mbruzek !
<mbruzek> yes it is!  thanks sebas5384
<sebas5384> :D
<bloodearnest> heya all
<bloodearnest> saw some discussion of a juju sync-charm command
<bloodearnest> I've got a plugin I use to sync charm changes down to the host here: https://github.com/bloodearnest/plugins/blob/master/juju-sync-charm
<bloodearnest> it could easily push those changes to all other units if needed, as discussed
<mattyw> stokachu, ping?
<lamont> I have a containter creation issue...
<lamont> I need to figure out what is telling networkConfigTemplate that my lxc bridge network is 'br0' instead of 'lxcbr0'... anyone who can help me with that?
<jrwren> lamont: what does /etc/lxc/default.conf say?
<jrwren> lamont: also, what does /etc/default/lxc-net say?
<lamont> on the host where I'm running juju, or on the host were the lxcs are getting created?
<lamont> jrwren: both of those refer to lxcbr0.  but juju runs lxc-create -f /var/lib/juju/containers/juju-machine-4-lxc-5/lxc.conf ..., and that file says: lxc.network.link = br0, for the failure to create any lxcs
<lamont> so I'm trying to figure out where that br0 is coming from, and (more significantly) how to override/fix that, and whether or not it's abug
<lamont> brctl show
<lamont> bridge name     bridge id               STP enabled     interfaces
<lamont> lxcbr0          8000.000000000000       no
<lamont> and since I suck at reading go, ...
<lamont> and huh.  we appear to have fixed that on the prior existance by using br0... though tbf, that was deployed a long time ago.
<lamont> the other "interesting" thing is that the working machine (that uses br0) has ethN interfaces, and the one that doesn't work has emN interfaces
<lamont> this is a maas/juju deployed machine on which I'm creating numerous lxcs
<ezobn> Hi All! Do exist any how-to for move the bootstrap node for a juju environment to the new machine ?
<lamont> interestingly, this appears to be maas not handling the case where eth0 is not the default network iface
<stepheno> Hey all. I've got a quick question about beploying charms in an openstack environment. I'm using ceph as the cinder backing store, and i'd like to boot machines using cinder volumes(instead of instance storage on the hypervisors)
<stepheno> I don't see any way to do this at the moment, though i could see a way to do it via the openstack api(it's multiple api calls which are presented as one distinct action in the openstack gui)
<stepheno> Am i missing some setting, or might this be a feature request?
<natefinch> man, it bugs me that launchpad has human-readable URLs, but you can't actually edit the URL to navigate to logical places... like I'm at http://bazaar.launchpad.net/~charmers/charms/precise/wordpress/trunk/files  and I think "oh, I wonder what other charms are under precise?" so I edit the url to "http://bazaar.launchpad.net/~charmers/charms/precise/" ... 404
<ayr-ton> My friends, I created a local environment under ubuntu 14.04 and bootstraped it. I did a juju deploy juju-gui --to lxc:0  and then a expose. The agent-state is pending since then (4 hours). The ufw is disabled. There's some other workaround?
<marcoceppi> ayr-ton: why would you do juju deploy --to lxc:0
<marcoceppi> just do juju deploy juju-gui
<marcoceppi> which will spawn an LXC container on your host machine
<marcoceppi> that won't work because 0 on the local provider is your actual machine
<marcoceppi> so juju will try, then fail, to set it up
<ayr-ton> hmmm...
<ayr-ton> let me try =x
<ayr-ton> marcoceppi, there's a new machine number, but the state is pending
<ayr-ton> For like 15 minutes.
<jcw4> ayr-ton: what is the output of 'lxc-ls --fancy' ?
<ayr-ton> jcw4, empty, just the first line: NAME  STATE  IPV4  IPV6  AUTOSTART  and the second with: ----------------------------------
<jcw4> ayr-ton: I was just checking that the template file wasn't locked... doesn't look like that was the issue.. although I *would* expect there to be at least one lxc container if you're using local juju
<ayr-ton> jcw4, Yes. It does make sense. Let me see If I can found some problem in my lxc. One sec.
<ayr-ton> jcw4, It feels to be some problem with permissions. I'm trying to figure out how to fix it.
<ayr-ton> I'm trying the last one: https://juju.ubuntu.com/docs/troubleshooting-local.html
<ayr-ton> My image is from Aug 13.
<ayr-ton> jcw4, Not worked. ;~
<jcw4> ayr-ton: :(
<jose> mbruzek: awesome, good to know! thanks for giving me the heads up :)
<jcw4> ayr-ton: I'm afraid I'm out of ideas
<ayr-ton> I just removed the old image from cache, destroyed the environment, bootstraped it again, juju deploy juju-gui..
<mbruzek> jose thanks for sending out the email
<ayr-ton> http://paste.ubuntu.com/8056048/
<jcw4> ayr-ton: hmm; same thing? hanging for a long time, state pending?
<jose> mbruzek: it was nice to hear what others thought about it
<ayr-ton> Yep. And lxc-ls is empty
<ayr-ton> actually: sudo lxc-ls give me ayrton-local-machine-0-lxc-0  juju-trusty-template
<jcw4> ayr-ton: hmm; that's promising, although now it's sounding like the template lock file issue
<ayr-ton> The debug-log shows me a error related to mongo, this time: http://paste.ubuntu.com/8056065/
<ayr-ton> juju.mongo open.go:82 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
<jcw4> ayr-ton: http://irclogs.ubuntu.com/2014/07/30/%23juju-dev.html
<jcw4> look for convo starting around 02:07
<ayr-ton> jcw4, let me see..
<ayr-ton> jcw4, Holly mother of God. It is working: http://25.media.tumblr.com/tumblr_m6td1wPntx1rrgtiio1_500.gif
<ayr-ton> jcw4, The template lock was the issue.
<ayr-ton> Thank you very much (:
<marcoceppi> ayr-ton: \o/
<natefinch> marcoceppi: I'm trying to deploy a very slightly modified postgresql charm, and I kee getting 2014-08-15 19:52:11 INFO install subprocess.CalledProcessError: Command '['open-port', '5432/TCP']' returned non-zero exit status 1 during the install hook.  Any idea why that would be happening?
<ayr-ton> natefinch, Theres something using the port 5432?
<natefinch> ayr-ton: shouldn't be, this is just a default deploy of the charm on a brand new EC2 instance
<natefinch> looks like it's not just my teaked charm, the standard precise postgres charm hits the same error
<natefinch> says there's a conflict with the port
<natefinch> marcoceppi: relevant to your interests: https://github.com/juju/juju/pull/528
<marcoceppi> natefinch: can you elaborate on "the first argument"
<marcoceppi> natefinch: like, "default-hook install" or will it just be "install"
<natefinch> os.args[1] == hook_name
<marcoceppi> os args[0] will still be default-hook
<natefinch> correct
<marcoceppi> so*
<natefinch> marcoceppi: I can't change os.args[0]
<marcoceppi> hum, that would require some patching in charm-helpers
<marcoceppi> natefinch: wellllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
<natefinch> marcoceppi: for the charm I tweaked, that's actually what i did
<marcoceppi> natefinch: you patched charm-helpers?
<marcoceppi> I can't see where it's patched
<natefinch> marcoceppi: https://github.com/natefinch/pgcharm/blob/master/hooks/default-hook#L2335
<natefinch> marcoceppi: no,  I patched os.args
<marcoceppi> oh, psh
<marcoceppi> you patched it in the python code
<marcoceppi> gotchya
<marcoceppi> We'll probably create an update to charm-helpers where when using hooks.Hook you can define if you want to do legacy support or not
<marcoceppi> actually
<marcoceppi> we can make it smart
<marcoceppi> if os.argv[0] == default-hook, use os.argv[1]
<natefinch> marcoceppi: yep, if arg 0 is default-hook the hook name is arg 1
<marcoceppi> yup
<natefinch> nicve
<natefinch> nice
<marcoceppi> I'll submit a patch to charm helpers soon for that
<marcoceppi> natefinch: you da man!
<natefinch> marcoceppi: I figured that one would be easy.... surprised we didn't do that forever ago, when we realized most people just want to write one script, not 20
<marcoceppi> heh
#juju 2014-08-16
<ezobn> how I can replace machine with what the environment was bootstrapped ?
#juju 2015-08-10
<beisner> hi jamespage, can you review c-h mp? @ https://code.launchpad.net/~1chb1n/charm-helpers/charm-helpers.liberty-fetch-init/+merge/267515 - fixes invalid install source re: liberty, also adds a couple of amulet helpers for updated test WIPs.
<jcastro> jose: ah nuts I missed sebas
<jcastro> jose: the talk looks awesome, though, I suck at Spanish!
<jose> jcastro: hey, it's good that we have it recorded! you can always try using the automatic spanish CC on youtube and then the English translation
<mbruzek> jose:  How did your conference go?
<jose> mbruzek: it was super awesome! I didn't get to catch much of the sessions as I was running around, but it was great
<jose> people left the auditorium with a big smile :)
<mbruzek> jose:  awesome
<mbruzek> jose: Yeah you really can't enjoy the events you are organizing, I know that too
<mbruzek> Jose link to vids?
<jose> mbruzek: youtube.com/ubuntuonair, scroll down a bit and there's an ubuconla+ playlist
<mbruzek> ok
<jose> oh, and seb's talk is there too!
<mbruzek> I see that, how did you say to translate?
<beisner> wolsen, can you confirm an observation?:   enabling ssl in the rmq charm is a one-way deal.  ie. hooks aren't present for disabling ssl once enabled.
<lazyPower> ouch
<lazyPower> that seems like we broke a cardinal rule there beisner
<beisner> lazyPower, yeah, ran into this while test writing.  tests want to flip ssl on and off and run some of the same checks with it enabled and disabled.  i can turn it on ok ;-)
<lazyPower> you do good work my man
<beisner> same @ ya, lazyPower
<beisner> wolsen, lazyPower - actually, turn-it-off logic is there, but it leaves the key files behind.  probably should clean those up when disabling.
<beisner> so, error in my test logic .. it sees key files and says "fail, ssl isn't disabled dood"
<lazyPower> well, thats tricky. are they self signed certs?
<lazyPower> or are they provided base64 encoded certs?
<lazyPower> i guess either way you would want to not keep them on disk
<beisner> lazyPower, functionally, the charm seems fine.  just that lil bit about leaving old news behind that may or may not be of concern.
<jose> Odd_Bloke: ping, still around?
<Odd_Bloke> jose: Yo.
<jose> Odd_Bloke: you have a min to talk about the ubuntu-repository-cache charm? got some thingies after using it for production the past weekend :)
<Odd_Bloke> rcj: Around?
<jose> mr. Jennings has been idle for over 140 hours
<Odd_Bloke> He's been active more recently in internal IRC. :p
<jose> oh cool
<Odd_Bloke> jose: Do you want to brain-dump?  rcj can catch up when he's around.
<jose> sure
<jose> mbruzek: enable automatic CCs on the video, then choose 'translate' to english, and it should do good
<jose> Odd_Bloke: so, I installed the charm and started working alright. however, when I did the DNS redirect to archive.ubuntu.com, I needed to make sure the redirect didn't point to the same machine, otherwise I would end up in a loop
<jose> also, jjox helped me find a bug, bug #1483093
<mup> Bug #1483093: .archive.ubuntu.com is non inclusive <squid-deb-proxy (Ubuntu):Incomplete> <https://launchpad.net/bugs/1483093>
<jose> so, that means I had a problem right away. when users connected from archive.ubuntu.com it would give a 403. solution was to remove the . in front
<jose> however, what happens if I want to mirror something else? or have the mirror use another domain name? it also needs to be specified on the file, otherwise users will end up with a 403 and won't know what to do
<jose> that's... basically it :)
<jose> apart from that, it did a great job
<Odd_Bloke> So we haven't hit the redirect loop problem before because all of the cloud images are built to use <cloud_name>.clouds.archive.ubuntu.com (or something along those lines).
<Odd_Bloke> So we don't have to do any DNS magic.
<Odd_Bloke> jose: "specified on the file" <-- What needs to be specified, and which file?
<jose> yeah, but happened to me when I was using the manual provider :)
<Odd_Bloke> Thanks for the feedback, glad to hear it was useful!
<jose> check the bug, the mirror-dstdomain.acl file needs to have the domain name that's gonna be used, so I'd suggest a config option to have any domain names you want in there
<Odd_Bloke> Ah, OK, I see what you mean.
<jose> if it's not there squid-deb-proxy will throw a 403 error, and it's a bit hard to spot
<jose> need to navigate between several files
<Odd_Bloke> Yeah, I run squid-deb-proxy at home, so I've hit that problem before.
<Odd_Bloke> jose: So I suspect that we won't find time to fix the 'extra domains' thing any time soon; we're using this as a mirror of archive.u.c, and that's unlikely to change.
<Odd_Bloke> jose: But I would certainly be happy to review a patch.
<jose> I'd love to give a hand, I'd have to find my way around python charms as I'm not experienced, but definitely willing to take a look
<Odd_Bloke> jose: As for the DNS loop, I'm not sure what to suggest, unless perhaps the charm didn't try to hit archive.u.c but tried to hit a subdomain of it?
<jose> for the DNS loop, a quick note on the readme could do :)
<jose> something like 'make sure you don't end in a DNS loop when you are using the manual provider, otherwise your repository will not update!'
<Odd_Bloke> jose: So what exactly did you do to fix it?
<jose> put a custom entry on /etc/hosts, since the firewall was somehow blocking 8.8.8.8, reason why I didn't edit resolv.conf
<Odd_Bloke> So hard-coded an IP address that you knew was archive.u.c?
<jose> yep, directly from canonical
<Odd_Bloke> Hmm, that's probably fine for a temporary deployment but you could end up with it breaking if that IP address ever stopped being an archive mirror.
<Odd_Bloke> (Or, worse, continued to be an archive mirror but was taken out of the DNS rotation because it wasn't updating properly)
<jose> right. maybe a resolv.conf entry edit or making sure it doesn't use the custom dns but google's, for example, should be good
<jose> just that in my case it wasn't enough
<Odd_Bloke> Well, I'm wondering if we should mirror from 'urc.archive.ubuntu.com' or somesuch.
<Odd_Bloke> Provided people don't advertise their mirror as a wildcard, that should work.
<jose> yeah, mine was a wildcard too :D
<jose> so I could've hit it from different dns records
<Odd_Bloke> I feel like my lack of experience with configuring DNS servers is letting me down here. :p
<jamespage> beisner, how do you normally do the switch helpers/tests to stable thing?
<beisner> jamespage, i believe in the past, coreycb has done both and pushed into stable as the first commit after the release.
<beisner> jamespage, i have a batch, which would result in 1 MP per charm, as i (thankfully) can't push straight into the charms  ;-)
<coreycb> beisner, thanks, lemme know if you need a review
<wesleymason> I have charm related conundrum..I'm revisiting an earlier attempt to get one of our internally used subordinates into the store, proper, and trying to add some basic amulet tests per review feedback..however there aren't any public charms which currently have a rel for this subordinate (although part of getting it promulgated is to encourage more charms to
<wesleymason> support it)...so do I either a) try and spend some time adding support to a charm like the wordpress one (which would be nice eventually anyway, but a fair bit of work to undertake properly), or b) can I add a "dummy" charm with minimal amount of mcok data fed back over the relationship to the subordinate to make it testable in the amulet test?
<marcoceppi> wesleymason: what does the charm do exactly? A lot of people have used an Ubuntu charm as the base of a subordinate and will modify it (with the amulet test) so it will mimic a potential client charm
<beisner> jamespage, coreycb - so shall i do the charm-helpers yaml + stable test bit flipping MPs?
<jamespage> beisner, pls
<jamespage> beisner, lemme push the big button and publish the stable charms
<beisner> jamespage, coreycb - curious, does stable charm-helpers branch also get a push from dev in tandem with our release?
<jamespage> beisner, it does
<wesleymason> marcoceppi: it installs a utitliy (conn-check), and takes either a filepath to a config file or the config itself as a string and creates the file from the relation (but this is deprecated in the charm), and if related to nrpe sets up a regular nagios check
<beisner> jamespage, ok good.  lmk when the charms are pushed, i'll update my batch o matic thing and do those flips.
<marcoceppi> wesleymason: doing route (a) sounds best either by using an existing charm in your personal namespace as an example or by forking the ubuntu charm as a "vanilla" implementation. Having that will go a long way to helping people grok how to implement the bits required to make their charms compat with yours
<wesleymason> marcoceppi: :+1+, ta will do that
<ddellav> coreycb, can you take a look at this amulet output? I'm not sure why it failed http://paste.ubuntu.com/12049127/
<jamespage> beisner, apparently I'm done
<beisner> jamespage, ok, c-h.yaml + amulet flip batch underway.  will ping when ready for review.
<coreycb> ddellav, I've not seen that error.  for many charm errors you can look in the jenkins artifacts and find logs from the run, typically you'd want to look in /var/log/juju/unit*.log.  but I dont' think that'll help here
<coreycb> ddellav, could be related to this?  https://bugs.launchpad.net/juju-core/+bug/1468586
<mup> Bug #1468586: juju 1.24.0 bootstrap failure - Waiting for API to become available - Error connection is shutdown <oil> <juju-core:New> <https://launchpad.net/bugs/1468586>
<stub> marcoceppi: Is there any particular reason that the storage subordinate has not been promulgated to trusty?
<jamespage> coreycb, beisner: you guys ok to handle landing those branches for the stable switch?
<beisner> jamespage, yep we've got it
<coreycb> jamespage, sure
<marcoceppi> stub: no one's asked?
<stub> marcoceppi: ok, asking now :)
<stub> marcoceppi: ok, asking now :)
<marcoceppi> stub: just open a bug like you would a new charm asking to promulgate storage charm to trusty and it'll go iunto the review queeu
<stub> but laaazy
<marcoceppi> stub: me tooo
<lazyPower> stub: you rang?
<beisner> coreycb, pile o' openstack charm merge proposals for c-h/amulet stable flips @ http://paste.ubuntu.com/12049694/
<coreycb> beisner, k, queued!
<beisner> coreycb, woot, thank you
<beisner> meanwhile...   bots gone wild!
<jose> mbruzek: ping
<beisner> coreycb, oh fyi, only expect lint + unit results on that batch, as amulet was green on all of them.  though, as soon as those land, i plan to release a full run of stable charm tests for new baslines.
<beisner> baselines even
<coreycb> beisner, ok
<wolsen> beisner, coreycb ... release day - I can feel it... literally - the cell phone buzzes with each email sent for merge lol
<coreycb> lol
<beisner> bzzzt bzt!
<wolsen> lol
<lazyPower> marcoceppi: do we have charm helper wrappers that gracefully degrade to determine is_leader? My current strategy for approaching this is to panic and halt execution - https://github.com/whitmo/etcd-charm/pull/16
<marcoceppi> lazyPower: not that I'm aware of, the openstack charmers implemented the code. I'd have to look to see
<lazyPower> ok, i think where i'm at today satisfies the bug, but I'll circle back and look into making the charm gracefully degrade
<marcoceppi> hatch: it also runs the config-changed hook
<hatch> marcoceppi sorry?
<marcoceppi> and potentially the install hook (if upgrade-charm isn't present)
<hatch> I must have missed a previous message
<lazyPower> marcoceppi: thats what you get for trying to ninja
<marcoceppi> hatch: I'm just really good at predicting the question you're about to ask
<hatch> lol
 * lazyPower plays sadtrombone.wav
<hatch> marcoceppi so when upgrading a charm, it overwrites everything? or just matching files in the charm path?
<marcoceppi> hatch: it just unpacks the zip file ontop of the charm_dir
<lazyPower> only the files contained in the charm itself. if the charm creates for example .foo - .foo will persist so long as it does not exist in the charm package.
<marcoceppi> it won't delete anything
<hatch> mm ok - the root of this question is that I need somewhere to write keys supplied via config
<hatch> so I wasn't sure if the charm directory was stable enough to do so
<lazyPower> hatch: are you using charm helpers? if so, there's a storage module to do this, and it has a handy side effect of letting you know if the value has changed which helps with idempotency
<hatch> no I'm writing it in bash
<lazyPower> welp, nothing to do here then *whistles*
<marcoceppi> hatch: you acn use charm_dir, or you can always just use /etc :)
<hatch> lol - I was surprised that there was no 'common charm actions' section in the docs with code examples
<marcoceppi> lazyPower hatch the kv stuff is available through the chlp bash interface :)
<hatch> thanks for the information marcoceppi lazyPower
 * lazyPower hattips
<hatch> Is the $CHARM_DIR environment variable always defined? Or only during hook execution? I'm wondering if I can use it in an upstart script
<marcoceppi> hatch: only during hook execution
<hatch> marcoceppi is there any way to know where the charm path is from the upstart script?
<marcoceppi> hatch: have the charm write it to the init script?
<hatch> Or should I copy everything to usr/local/bin or something
<marcoceppi> hatch: it's best to use the linux filesystem, either usr/local/bin or /opt or something like that
<marcoceppi> I typically go with /opt/<thing>
<marcoceppi> but that's just a convention I grew up with
<hatch> alright I'll do that  , I need a place to put the bin and keys and whatnot
<hatch> so I'll just have to make sure the upgrade script properly replaces those
 * marcoceppi nods
<hatch> thanks again :)
<coreycb> beisner, those are all merged except rmq which I don't have upload rights for
<coreycb> beisner, however, precise and trusty charms are now different, so can you propose all of them against precise too?
<lazyPower> thumper: ping
<thumper> lazyPower: with you shortly
<lazyPower> thumper: its a quickie. you were hacking on django and used features that only exist in newer juju, i used the proposed semver approach we riffed in about a month ago - and it got nacked in peer review, you may want to take a look here at this cleaner block update that you can recycle - (reason why is inline) https://github.com/whitmo/etcd-charm/pull/16
<thumper> lazyPower: ok, will look
<thumper> lazyPower: btw, I support the min-version idea
<thumper> will raise again
<thumper> lazyPower: however, it does raise the interesting point of "how to fall back"
<thumper> lazyPower: if I have, say, the django charm that now uses leadership, and has min-version of 1.24
<thumper> lazyPower: what would the expected behaviour be of someone using 1.22 going 'juju deploy python-django'
<lazyPower> thumper: i think thats on a case by case basis
<thumper> I believe this is the main sticking point w.r.t implementation
<lazyPower> if you can probe if you have it available, you're already leaps and bounds ahead
<lazyPower> you can either chose to work around it, or raise an error with a meaningul output with regard to "Yo, your version of juju is crusty, please update if you want to use this charm"
<marcoceppi> lazyPower thumper it seems that leader election is the only hard sticking point atm. status and storage have feasable workaround to degrade nicely
 * thumper nods
<wesleymason> PSA: !juju now works on duckduckgo.com to redirect searches to the charm store ð
#juju 2015-08-11
<jamespage> and charmers around? I could do with a review of https://code.launchpad.net/~james-page/charm-helpers/liberty-versioning/+merge/264998
<wesleymason> marcoceppi: are there any py3 compatible rules/guidelines/points for charmhelpers? (is it even a thing?), #askingforafriend
<marcoceppi> wesleymason: first of all \o/ on duckduckgo
<wesleymason> :D
<marcoceppi> wesleymason: I'm not sure I understand the question, charmhelpers should be py2/py3 compat if that's what you're asking
<wesleymason> marcoceppi: yes, partially, but also is there anything that needs to be considered (e.g. any bits that won't work)
<marcoceppi> wesleymason: not that I'm aware of, if you come across any issues though, let me know
<pedronis> marcoceppi: hi, it's a bit strange it doesn't say so in HACKING for example though
<stub> wesleymason: The tests get run against both py2 and py3, and whenever someone breaks py3 I bitch about it and fix it.
<wesleymason> stub: cool
<stub> wesleymason: the biggest headache is subprocess.check_call and friends, which returns bytes by default and charms like to call a lot.
<wesleymason> eurgh
<stub> wesleymason: easy peasy, just remember to add 'universal_newlines=True' on every call.
<marcoceppi> pedronis: sadly that hacking doc hasn't been updated in over 300 revisions :\ if you have text taht would fit better in there lmk or submit a patch!
<wesleymason> stub: ð
<marcoceppi> stub: have you played much with tox?
<wesleymason> (â¯Â°â¡Â°ï¼â¯ï¸µ ÊÊÉÉâ¾ÊÉÇÉ¥É
<stub> marcoceppi: No, but it would be what I would first look at if I needed something like buildout/tox/etc.
<marcoceppi> stub: I think we're going to add it to charm-helpers instead of what currently performs the unittests. So far it's been added to a number of other tools and it's a very nice interface
<stub> marcoceppi: yup. Talk to barry on the internal chans or the guys in #launchpad-dev if you want - I think they might know the gory details.
<ddellav> jamespage, I had to re-run amulet tests again due to a timeout on the undercloud (i guess?) but everything is green now. Take a look when you get a chance and let me know: https://code.launchpad.net/~ddellav/charms/trusty/glance/upgrade-action/+merge/265592
<hatch> can you not upgrade a local charm with a local charm? It's giving me an error that local:trusty/mycharm is an invalid charm name
<hatch> er service name
<lazyPower> hatch: you can upgrade a local charm with a local charm
<lazyPower> do you have $JUJU_REPOSITORY set?
<hatch> yeah I literally just changed `deploy` to `upgrade-charm --force`
<lazyPower> ah
<lazyPower> you dont need local:foo/bar with upgrade charm
<lazyPower> just the name of the service is fine
<lazyPower> juju upgrade-charm --force bar
<lazyPower> juju will do the source resolution for you since it has a local: reference listed in the output
<lazyPower> you can verify w/ juju status
<hatch> ahh there we go
<hatch> quite an odd failure case
<lazyPower> i dont think its an odd failure. upgrade-charm depends on a service directive. suppose you deployed 2 services, same charm, different names
<lazyPower> and you only want to upgrade a single service, not both
<sparkiegeek> hatch: pah, you should consider yourself lucky. Using local charms is getting easier. Back in the day it was seriously difficult :P
<lazyPower> ^
<hatch> lazyPower ahh I suppose that makes sense
<sparkiegeek> hatch: you know about dhx and it's syncing abilities right? (automagical syncing of locally editted charm to deployed environment)
<lazyPower> hatch: context sensitivity is arguably one of the nicer things about juju :)
<hatch> lazyPower but the error messages are real poor
<lazyPower> sparkiegeek: have you tried sync-watch? where it works in reverse. Edit locally - force push remotely
<lazyPower> hatch: a bug would go a long way
<sparkiegeek> lazyPower: ah, yeah that's the one I meant
<hatch> I had a typo in my metadata.yaml, so it gave me an error about that and then said it couldn't find the charm lol
<hatch> juju sync-watch?
<hatch> lazyPower I don't think this upgrade charm is actually working
<lazyPower> hatch: https://github.com/juju/plugins/pull/53
<lazyPower> hatch: what appears to be the behavior?
<hatch> it's uploading the code, but not re-running the install hook
<hatch> is it not supposed to re-run the install hook if there is no config-changed?
<lazyPower> do you have a hook trapped on the unit? and i dont think upgrade-charm implicitly calls the install hook
<lazyPower> it calls upgrade-charm => config-changed
<hatch> ohh yesterday marcoceppi said that it called the install hook if there was no upgrade-charm
<lazyPower> marcoceppi: upgrade-charm calls the install hook? wat?
<hatch> I mean, it kind of makes sense
<lazyPower> hatch: it may, but i'm not aware of that. i defer to the answerer
<hatch> the install hook is the place that would install deps
<hatch> which may change between versions
<lazyPower> ehhh
<lazyPower> i dont know that i agree with that
<hatch> lazyPower well it's not calling mine
<hatch> lazyPower you don't install sysdeps in the install hook?
<lazyPower> i mean if you want that behavior, implicitly call install from your upgrade-charm
<lazyPower> otherwise, why does it make sense to implicitly call it?
<lazyPower> hatch: i'm going to grab a bite to eat. be back in 10 to 15.
<lazyPower> but, one thing before i go
<lazyPower> you should have at bare minimum seen it call config-changed
<hatch> lazyPower sure np
<lazyPower> if upgrade-charm didn't call config-changed, something is either trapped, in error state, or broken
<hatch> ok lemme check that out
<hatch> lazyPower I can confirm that config-changed was not called, the unit is in the install hook failed state from previous runs but I thought that --force should 'just do it'
<lazyPower> hatch: --force only force upgrades the charm code
<lazyPower> if your unit is in failure state, you still need to resolve --retry
<hatch> lazyPower ohh...that'll teach me to assume
<hatch> lazyPower so if a hook is in an error state and you try and upgrade it without --force it won't copy the files for any unit?
<lazyPower> it will upgrade the charm, but it queues, and the upgraded code wont land until that upgrade-charm cycle is reached
<lazyPower> the --force kind of stealth bombs the upgraded hook code in place
<hatch> so you would end up in a state where some units have the upgraded code but the ones with hook errors won't?
<lazyPower> hatch: they will eventually reach consistency, as that upgrade-charm hook is queued
<lazyPower> but correct. the units in error state will be in halted execution state
<lazyPower> so the ones that are not in error will continue to cycle as you would expect
<hatch> right, but the admin would have to resolve all hook errors first?
<lazyPower> yep
<hatch> lazyPower ok and is there a way to force resolve all errors? When the install hook fails you have to resolve all the next hooks to get it into a functional state
<lazyPower> just juju resolved or juju resolved --retry
<hatch> oh ok so I'll have to run `juju resolved` three times if the install hook fails
<lazyPower> mbruzek: marcoceppi - if either of you have a moment, this was a priority fix that just got proposed for the store - https://code.launchpad.net/~kubernetes/charms/trusty/etcd/trunk/+merge/267696
<mbruzek> lazyPower: you need better bzr foo
<lazyPower> ?
<mbruzek> <<< TREE >>> MERGE-SOURCE
<mbruzek> You have merge conflict messages in the readme.
<lazyPower> i dont even know where that came from
<lazyPower> it was not a merge
 * lazyPower eyeballs the github repository
 * mbruzek coughs 'vendor'
<lazyPower> mbruzek: you're welcome to contribute if you dislike how it works :)
<mbruzek> You are right.
<lazyPower> This isn't in the local copy
<lazyPower> i dont know where that came from
<lazyPower> and worse yet, its a whitespace collision
<mbruzek> IBM has problems with spaces and tabs too don't feel bad
<lazyPower> mbruzek: feeling spunky today huh?
<lazyPower> mbruzek: doesn't exist in the repo either
<lazyPower> http://bazaar.launchpad.net/~kubernetes/charms/trusty/etcd/trunk/view/head:/README.md
<mbruzek> lazyPower: I was going off the diff in the merge propsal
<lazyPower> the readme diverged from the store charm and whats in ~kubernetes
<mbruzek> How would that happen?
<mbruzek> Is he charm store touching a file?
<lazyPower> mbruzek: you broke it w/ rev 15
<lazyPower> http://bazaar.launchpad.net/~charmers/charms/trusty/etcd/trunk/revision/15
<lazyPower> made changes to the push copy @ the store that dont reflect whats in ~kubernetes
<lazyPower> arigato obama san
<lazyPower> also since we're in here
<lazyPower> we have a typo. "Man"-tainers
<lazyPower> :D
<mbruzek> yeah I noticed that too.  My change was to clean up the promulgated namespace
<lazyPower> mbruzek: @_@ you make my life difficult
<mbruzek> The Force is strong with this one
<lazyPower> i'm fixing it tho
<lazyPower> 1 sec
<lazyPower> mbruzek: rev 17 should have that backported fix
<lazyPower> mbruzek: ploz stop diverging our namespace <3
<mbruzek> do proper merges and this wouldn't happen.
<mbruzek> :)
<hatch> lazyPower are there any restrictions for hook scripts accessing other files? They run as root correct?
<lazyPower> correct, its run as root.
<hatch> odd....the script can't access the file, says it doesn't exist, but when I run it manually as root it works
<hatch> lazyPower and `juju run` executes the files in the hook context based from their directory?
<lazyPower> hatch: juju run `whoami && pwd`
<hatch> oh...it's running it as the cli user
<lazyPower> :)
<hatch> wait nm heh
<lazyPower> depends on if you're running it at --unit --service level
<hatch> lazyPower so hooks are executed from the hooks dir or from the charm dir?
<hatch> juju run is giving me the charm dir
<lazyPower> from $CHARM_DIR
<hatch> ahhhh
<hatch> damn
<hatch> ok that's why it's not working
<hatch> thanks again lazyPower
<lazyPower> cheers :)
<mwenning> hi juju team, is there a way to set --keep-broken after bootstrap?
<pmatulis> i'm confused. juju bugs are tracked on github but juju-core bugs are tracked on launchpad?
<pmatulis> and what's the difference between these two "projects"?
#juju 2015-08-12
<thomi> Hi all, is anyone able to help me parse this log message please? "unit spi-mongodb/1 cannot get assigned machine: unit "spi-mongodb/1" is not assigned to a machine"
<thomi> it's the last 'ERROR' in a failing deployment, and I have zero clue what that means
<thomi> In fact, it seems paradoxical to me...
<lazyPower> thomi: thats interesting, i only see that during the first steps of deployment
<lazyPower> i think its related to the agent deployment but i'm not entirely sure
<thomi> hmmm
<lazyPower> thomi: however its not critical, and i never see it again once the agent is up and running
<lazyPower> is this a manual provider environment?
<thomi> lazyPower: no, local
<lazyPower> which juju version? I assume this is 1.24.3 the current -stable release?
<thomi> 1.24.2
<thomi> which is the latest in vivid... unless a new release came out this week?
<lazyPower> 1.24.4 was released this week actually
<thomi> ahh, ok
<thomi> I'll upgrade and retry :D
<thomi> It's all complicated by the fact that I'm also using mojo and therefore juju-deployer
<lazyPower> thomi: another question, have you tried deploying something "simple" like the ubuntu charm to verify the local provider is indeed working?
<thomi> so I have three places to look for errors :D
<thomi> lazyPower: yes - by the time it errors I've already deployed apache, haproxy and a few other things
<lazyPower> ok, well thats promising that its not a full scale local provider issue
<lazyPower> should narrow things down a bit when debugging anyway
<thomi> hmmm, I'm not seeing a new juju in vivid?
<lazyPower> interesting, i wonder if vivid packages weren't published yet, i just got 1.24.4 today on trusty
<lazyPower> seems that its in the ppa
<lazyPower> https://launchpad.net/~juju/+archive/ubuntu/stable
<thomi> hmmm
<lazyPower> ah, i mis-spoke. 14.10.1 has 1.24.2-0
<lazyPower> thomi: but if you're on vivid, 15.04 - you should have 1.24.4 available to you.. the 1.24.2 is for utopic(?)
<thomi> apt-cache policy says 1.22.1 is all that's in the archive.
<thomi> I could add the PPA and get it
<thomi> I'm just wondering if that's going to break anything else
<thomi> lazyPower: who should I talk to about juju-deployer?
<lazyPower> thomi: our devx team currently maintains juju-deployer. tvansteenburgh (out on vaca) and marcoceppi are 2 good resources
<thomi> thanks. I guess it's a bit late for marcoceppi :D
<crab> hi.
<lazyPower> hello crab
<lazyPower> thomi: it is, its 10:20 here
<lazyPower> however to be fair, you never know when he's lurking about
<marcoceppi> thomi: hello o/
<lazyPower> speak of the force of nature
<marcoceppi> thomi: is spi-mongodb a subordinate?
<pmatulis> should bugs be filed on github or launchpad?
<pmatulis> i see tracking on both sites
<lazyPower> pmatulis: Launchpad is the preferred location
<pmatulis> lazyPower: ok, but why 2 trackers?
<lazyPower> Good question, there was an open discussion about it on the list last year and it was decided to not have an issue tracker on github. I'm not sure why that was overturned. It may be to reduce the barrier to entry for bug contributors that are not on launchpad
<pmatulis> lazyPower: awfully confusing and inefficient
<marcoceppi> pmatulis: bugs are tracked on launchpad for juju, all project management is done there
<pmatulis> marcoceppi: alright. maybe we should shut down the github tracker then
<marcoceppi> pmatulis: we probably should
<marcoceppi> pmatulis: I'd email juju-dev@lists.ubuntu.com to start that discussion
<pmatulis> marcoceppi: alright, thanks for clarifying
<thomi> marcoceppi: sorry, was AFK. Are you still here?
<marcoceppi> thomi: yup
<thomi> marcoceppi: I'm seeing juju-deployer errors like: http://pastebin.ubuntu.com/12058570/ when I run my mojo spec
<thomi> marcoceppi: most of those ERROR lines occur even on a successful run
<thomi> but the 'Unknown error' doesn't
<thomi> any ideas what could be happening?
<marcoceppi> what version of deplyer?
<marcoceppi> thomi: also, it appears that deployer is having a hard time parsing your bundle
<thomi> marcoceppi: 0.5.1-3
<marcoceppi> thomi: cool, that's latest
<marcoceppi> thomi: do you have the bundle? could you pastebin that?
<thomi> marcoceppi: by 'bundle' you mean the yaml files?
<marcoceppi> yes
<thomi> sure, one second..
<thomi> marcoceppi: there's two files: http://paste.ubuntu.com/12059115/ and http://paste.ubuntu.com/12059114/
<marcoceppi> thomi: okay, so it lists charm, I'm not 100% sure on mojo stuff, but are those "charms" in a local directory somewhere? It's trying to parse the charm URL for those and it's failing
<marcoceppi> it expects a protocol like cs:<series>/<charm>
<marcoceppi> or local:<series/<charm>
<marcoceppi> or instead of a charm key, a branch key with a bzr branch
<thomi> marcoceppi: I think that's a red herring - mojo builds the charm repo, and those ERROR messages about missing charms happen even for successful runs
<marcoceppi> thomi: then your next error is "deployer.deploy: Invalid config charm result-enum-worker nagios_context=None"
<marcoceppi> does the result-enum-worker charm have a nagios_context configuration option?
<marcoceppi> You may also want to try setting it to ""
<thomi> I'm 90% sure... just double checking
<thomi> marcoceppi: ugh... that'd be it... now I feel silly :D
<thomi> marcoceppi: the change to the charm didn't land yet it seems.
<marcoceppi> I feel like I should dig into mojo more, those charm/branch errors seem so...weird
<thomi> marcoceppi: I will buy you many $(beverage_of_choice) if it means juju and mojo devs start talking to each other
<thomi> I'm not even joking. SO MANY BEERS.
<marcoceppi> thomi: so, on the devx team we have dedicated time to work on tooling each week (amulet, deployer, charm-tools, etc) we may take one of these slots to just get a bunch of info about how mojo is using deployer and see if we can make it happier
<marcoceppi> thomi: we just landed something that might be useful for mojo, where charm: can now be an absolute path to a charm directory on disk, may help streamline some of what mojo is trying to do
<thomi> marcoceppi: that sounds good. It seems like there's lots of places where mojo & juju could work better together
<thomi> marcoceppi: if you're still around: What's the best way to make your team aware of  such issues? Perhaps there's a bug tag to use, or something? a mailing list, or...?
<marcoceppi> thomi: if you want to tag bugs with mojo on lp:juju-deployer (or any project) we can use that for filtering
<thomi> marcoceppi: will do - thanks
<lazyPower> marcoceppi: did you know juju-reboot existed?
<marcoceppi> lazyPower: yes, it came into existance because of windows charms
<marcoceppi> lazyPower: I troll juju help-tool a lot to keep up to date with new stuff landing in hookenv
<lazyPower> man, thats awesome. I just discovered it tonight poking around in the tools dir
<lazyPower> i'm working off the feat-proc-mgmt branch and finding out whats impl and whats pending - ran across that nugget of goodness
<thomi> Is there a way I can get juju to show me all the relations that a deployed charm supports?
<thomi> 'juju stat' seems to only show me relations that are actually connected to something
<thomi> I guess I want a 'juju list-relation'
<Tribaal> Hi all. The ingestion queue for the charm store seems to be incredibly slow. I've been waiting for my branch to be ingested for hours... Can somebody have a look?
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charm-helpers/liberty-versioning/+merge/264998
<jamespage> that's the other ch bit for liberty version detection
<gnuoy> jamespage, merged
<gnuoy> jamespage, https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-api/vpp/+merge/263224 for the neutron-api changes
<jamespage> gnuoy, one niggle
<gnuoy> hit me
<gnuoy> oh, I see, you have. ta
<gnuoy> jamespage, fixed
<jamespage> gnuoy, http://paste.ubuntu.com/12060702/
<jamespage> just noticed that
<gnuoy> argh, on it
<gnuoy> jamespage, fixed
<jamespage> gnuoy, +1
<gnuoy> \o/
<gnuoy> thanks
<jamespage> I'll asume the lint will pass now :-)
<gnuoy> defo
<g3naro> anyone familiar with aws ?
<marcoceppi> g3naro: as familiar as the next person
<g3naro> marcoceppi: elastic-beanstalk
<g3naro> jooojooo
<Bigdeal> Newbie seeking help on JUJU: ssl when connecting to openstack
<Bigdeal> newbie question, problem bootstraping juju with openstack due to ssl error
<Bigdeal> How can I foce juju to accept a self sign cert
<jose> Bigdeal: there are no newbie questions at all :) someone should be around soon to give you a hand, I need to leave
<Bigdeal> Jose: Thanks
<jose> Bigdeal: what juju version are you using? (juju version gives you that)
<Bigdeal> Jose: 1.24.4-trusty-amd64
<jose> huh, I see a bug but it was fixed on 1.15+... let's wait for someone else to check on that :)
<Bigdeal> Jose: I ran the quickstart -i
<Bigdeal> used ssl-hostname-verification : false
<hatch> I have a config field for a 'secret' this secret can be any series of characters but it fails if it is all numbers because juju says the types don't match...quoting the value solves the problem but that's not going to be very user friendly as I have to strip the quotes off if they exist (and aren't part of the actual secret string) and the user has to know to quote it...are there any other workarounds for this?
<ddellav> Bigdeal, whats the exact error you are getting? and is it during the bootstrap process or is it in a browser we trying to access juju-gui/horizon dashboard?
<Bigdeal> this is during the bootstrap process
<Bigdeal> ddellav: I used quickstart -i then filled in the parameters for my openstack env.
<ddellav> ok, can you paste me the error output? You can use http://paste.ubuntu.com
<ddellav> hatch, as far as i know right now we only support integer, string, and boolean types for config valus.
<ddellav> *values
<Bigdeal> ddellav:
<Bigdeal> ERROR there was an issue examining the environment: authentication failed.
<zeron> ddellav: sorry for the delay, Bigdeal is currently at a meeting, he will revert to you as soon as he comes out of it. thanks.
<ddellav> if it's a string value (meaning quoted) then you can put whatever you want in there and you shouldn't have to remove the quotes when retrieving it later (though Im not 100% sure about this)
<hatch> ddellav, yeah, is there maybe a way to make the yaml field a 'string' without quotes?
<hatch> yeah this is kind of an edge case bug....because it's a secret it can be anything, (the user, or I have control over this secret value)
<ddellav> hatch, not that I know of but there may be something in the YAML spec that allows for it, I'd have to look it up. Something like heredoc syntax.
<ddellav> zeron, no problem :)
<ddellav> Bigdeal, have you tried setting ssl-hostname-verification to true?
<hatch> ddellav alright np thanks, I'll keep looking
<ddellav> also Bigdeal what provider are you using?
<ddellav> (maas, aws, azure)?
<Bigdeal> ddellav: I am pointing to my own Openstack environement
<ddellav> Bigdeal, so you are using your own openstack environment as the provider?
<Bigdeal> ddellav: I am pointing to my own Openstack environement as the provider, my environement uses selfsigned certs
<ddellav> ok, i'm not quite sure what that could be and I can't find any relevant information on ssl issues when deploying juju on top of openstack. Perhaps lazyPower or beisner have some ideas?
<Bigdeal> ddellav: would ssl-hostname-verification=false help?
<Bigdeal> but I am not sure where it should go
<ddellav> Bigdeal, that would go into your environments.yaml file
<ddellav> https://jujucharms.com/docs/devel/config-general#alphabetical-list-of-general-configuration-values
<Bigdeal> can you please tell me the path of the file?
<ddellav> that's usually in ~/.juju/envionments.yaml
<ddellav> *environments.yam
<ddellav> ugh.. new keyboard, still breaking it in :(
<g3naro> mechanical ?
<lazyPower> Bigdeal: that would be a sub-key of your openstack provider environment defined in $HOME/.juju/environments.yaml
<Bigdeal> my file is empty
<ddellav> g3naro, yea, razer blackwidow chroma
<lazyPower> Bigdeal: are you using encrypted homedir?
<ddellav> Bigdeal, when using openstack provider you might want to read this: https://jujucharms.com/docs/devel/config-openstack
<Bigdeal> lazyPower: not sure abour home dir
<g3naro> ddellav:  nice one
<g3naro> ive got corsair k70
<g3naro> i tried them all
<Bigdeal> I added the line and still getting  error: Bootstrap failed, cleaning up the environment.
<Bigdeal> ERROR there was an issue examining the environment: authentication failed.
<plars> I have some services that I want to deploy to lxc under maas. I'm using juju-deployer to deploy a empty ubuntu charm named something like service-host, and the rest with to: lxc:service-host
<plars> but one of the things my service needs to do requires some changes to the default lxc apparmor template
<plars> is there some way to pre-configure this when I deploy? or do I have to deploy some decoy to lxc, go modify the template by hand, and destroy the decoy?
<plars> It's /var/lib/lxc/juju-trusty-lxc-template/config that I need to edit, but that doesn't seem to exist until I actually deploy something to:lxc:foo
<lazyPower> plars: right, thats the chicken/egg of lxc configuration. What you can do, is deploy a subordinate that modifies that template and use juju-reboot to reboot the host.
<lazyPower> plars: i ran into that when working w/ the fan and wanting to fully automate the fan networking setup
<plars> lazyPower: I'm not sure I follow... how does a subordinate help unless you've already deployed something to an lxc container on the host?
<plars> lazyPower: oh... I think I get it, you deploy everything, then the subordinate gets deployed, modifies the config, and reboots the host (eventually causing all the lxc instances to get restarted)
<lazyPower> yep
<plars> lazyPower: but is there some way to ensure that it doesn't reboot the host until after the lxc instances are finished deploying?
<lazyPower> its not ideal as instances will reach error state, but on reboot they should re-execute and resolve themselves.
<plars> ok
<lazyPower> there is not, as there's no garantee that no hook is firing
<lazyPower> juju-reboot will do its best to stop the containers then reboot the host
<plars> lazyPower: I'll give it a try, thanks
<Bigdeal> still stuck on the ssl issue
<Bigdeal> my juju fesh install cant connect to my openstack private cloud, I get an authentication issue that is due to selfsigned certs
<lazyPower> beisner: do you have any experience with openstack and selfsigned certs for auth?
<lazyPower> beisner: the user has left, however this seems like good info to have for the future
<beisner> lazyPower, i'd have to stand up a new environment to exercise that, in order to be able to t-shoot.
<beisner> lazyPower, we'd also want to grab a juju stat, and know which version of OpenStack is deployed, juju version, ubuntu version, all that good stuff.
 * beisner has to head out for a bit
<thomi> marcoceppi: As per our conversation yesterday: https://bugs.launchpad.net/juju-deployer/+bug/1484260
<mup> Bug #1484260: juju-deployer logs ERROR messages during successful deployment from mojo <mojo> <juju-deployer:New> <https://launchpad.net/bugs/1484260>
<apuimedo> jamespage: gnuoy: Is there some flakiness with deploying nova-cloud-controller on an lxc container?
<apuimedo> I got it failing when establishing the relation with nova-compute
<lazyPower> apuimedo: they're UK based and probably not around. Can you hit the list with your findings of flakiness?
<apuimedo> ah, that's true
<apuimedo> I sometimes forget that people don't live in IRC :P
 * lazyPower smirks
<apuimedo> lazyPower: how are you?
<lazyPower> guilty as charged
<lazyPower> apuimedo: doing well, i sent you a follow up this morning about your charms and if there was anything required from me
<apuimedo> oh, I didn't see it
<apuimedo> let me check my mail filters
<lazyPower> no worries :) You're probably not used to me emailing you since we have such an excellent record of IRC contact
<apuimedo> oh, that was after I got home
<lazyPower> ah yeah, important to specify *my* morning, not morning over in EU
<apuimedo> I didn't check my email much since then
<apuimedo> gotta entertain the child
<apuimedo> :P
<lazyPower> :D totally understood
<lazyPower> and nothing pressing if you're chugging along well, thats excellent.
<lazyPower> just wanted to make sure you're getting the help required
<apuimedo> thanks ;-)
<lazyPower> np np. I'm here to help
<beisner> hi thedac, you may also be interested in checking out bug 1484260.  it's doesn't impact the run itself, but it does raise a brow or two with error noise.  not sure if mojo needs to pass things differently to deployer, or if deployer needs to just like it  ;-)
<mup> Bug #1484260: juju-deployer logs ERROR messages during successful deployment from mojo <mojo> <uosci> <juju-deployer:New> <https://launchpad.net/bugs/1484260>
<Bigdeal>  my juju fresh install cant connect to my openstack private cloud, I get an authentication issue that is due to selfsigned certs
<Bigdeal> Anyone knows how to resolve it?
<lazyPower> Bigdeal: i got some feedback from an openstack dev while you were disconnected
<lazyPower> Bigdeal: we'd also want to grab a juju stat, and know which version of OpenStack is deployed, juju version, ubuntu version, all that good stuff.
<lazyPower> Bigdeal: one of the things we'll need to do is try to reproduce your setup so we can accurately debug and see if we cant find an answer for you. Can you get me  a pastebin with the requested output above that i can forward over to the openstack team?
<Bigdeal> lazyPower: We're running HP's Cloud System 8.1
<lazyPower> Bigdeal: which version of juju, and which platform? (osx, ubuntu trusty, et-al)
<lazyPower> beisner: ^ HP Cloud system 8.1 - i'm not familiar with this setup.
<Bigdeal>  lazyPower: The Openstack version is Icehouse
<Bigdeal> JUJU on ubuntu trusty
<Bigdeal> I basically loaded a VM with Ubuntu 14.04 LTS, then I installed Juju
<Bigdeal> then I ran juju-quickstart -i and created a new openstack config
<Bigdeal> it fails bootstraping
<beisner> hi Bigdeal, do you have debug output from the juju client?   fyi you can add --debug to just about any juju command.    ie.    `juju bootstrap --debug`
<beisner> Bigdeal, also, can you paste your ~/.juju/environments.yaml  (remove passwords and other sensitives of course)?
<beisner> Bigdeal, @ http://paste.ubuntu.com/
<Bigdeal> I will run it again and share the output, when I looked earlier it was an SSL error, I assumed it has to do with the fact that I have self signed certs on my Openstack setup
<beisner> Bigdeal, another bit that would be helpful is your `keystone catalog` output (sanitize to your comfort)
<beisner> Bigdeal, however, keep in mind that i'm not specifically familiar with the undercloud you're running.  but with that ^ info we may be able to see what's going on.
<Bigdeal> http://paste.ubuntu.com/12065817/
<Bigdeal> here is the conf http://paste.ubuntu.com/12065827/
<lazyPower> Bigdeal: missing object store - i think i found the issue
<lazyPower> do you have swift/glance in this stack and have access to create object buckets?
<Bigdeal> beisner: We running Openstack wth Vcenters for compute
<Bigdeal> we have glance but I am not sure about object buckets
<Bigdeal> I am new to openstack/juju
<lazyPower> beisner: i may be mis-remembering if glance is an object store.... ally oop me?
<lazyPower> Bigdeal: ah glance is the VM Image store, i am mis-remembering. i think it requires swift - there's a hard requirement of juju prior to 1.25 (currently in a highly unstable beta phase) which requires object storage. 1.25 will remove that limitation as i understand it
<beisner> lazyPower, having object storage available via either swift or ceph-radosgw for object stores is pretty much a requirement with the juju openstack provider
<beisner> er i mean, Bigdeal ^
<lazyPower> ^
<lazyPower> yeah, thats what I thought when i saw that output is we have found the culprit
<beisner> lol
<lazyPower> its not so much SSL as it is missing object storage
<beisner> yep
<lazyPower> juju writes a backup "state" pointer to the object store, which is used if your client .jenv is ever corrupted
<lazyPower> so it can rebuild itself
<lazyPower> we remove this requirement as it cut out over 1/2 of the cloud providers out there. Apprently this one included - as its missing a key component we are using today.
<beisner> Bigdeal, `keystone catalog` would need to show a registered 'object-store' service to indicate that cloud is ready to juju
<lazyPower> let me see if i can find the object storage removal bug and link you to that Bigdeal so you can track its progress. If you're fine with using a testing client you might even be able to install juju 1.25 and be an early adopter/driver of this provider code update.
<Bigdeal> let me check what I have on that
<lazyPower> or i can wait for that first :)
 * lazyPower is notorious at putting cart before the horse
<lazyPower> beisner: see? this is why i call you in on these projects. Mr big guns over there.
<lazyPower> beisner: remind me in DC to buy you all the beer you can consume for being my go to for openstack stuff
<beisner> lazyPower, ah thanks sir.   we should gather around beers regardless ;-)
<lazyPower> a truer statement hath not been typed in this channel.
<Bigdeal> How can I check if I have the object store?
<Bigdeal> btw I dont mind being an early adopter, I 'll be happy to contribute
<beisner> lazyPower, /me didn't know --object requirement @ ~1.25!
<beisner> lol
<beisner> xmas in aug
<lazyPower> yessir!
<lazyPower> Bigdeal: ok let me go dive into the bug tracker and ping some people and see what i can turn up
<lazyPower> Bigdeal: it may not be landed in the devel ppa just yet, so there's a bit of digging i need to do before i can promise anything
<Bigdeal> Keystone tells me I have cinder object store
<beisner> Bigdeal, hrm.  cinder is block storage
<Bigdeal> CinderV2 Block Storage Service API
<Bigdeal> ok get it
<lazyPower> Bigdeal: heres your bug you'll want to track - https://bugs.launchpad.net/juju-core/+bug/1456265
<mup> Bug #1456265: Openstack provider should work without object-store <openstack-provider> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1456265>
<Bigdeal> block vs objct sorry
<lazyPower> beisner: ^ might want to flag that as well since its fix committed
<beisner> Bigdeal, ah ok.  so not object-store available?
<beisner> lazyPower, tyvm!
<Bigdeal> http://paste.ubuntu.com/12065894/
<Bigdeal> That's the keystone service list
<beisner> Bigdeal, yep, no object store
<lazyPower> Bigdeal: i've got open questions out, and will circle back once i get an answer.
<beisner> lazyPower, where is devel pushing packages these days?  https://launchpad.net/~juju/+archive/ubuntu/devel  looks stale
<Bigdeal> mhh so what are my options? would it easy enough to setup an object store in openstack (swift?)
<lazyPower> ayy, yeah
<lazyPower> those are some old bins
<beisner> while https://launchpad.net/~juju/+archive/ubuntu/proposed  appears fresh
<lazyPower> beisner: that should be where we stage the beta versions. I admittedly have not been on the -devel ppa in a while since i'm building nightlies in docker these days
<beisner> lazyPower, Bigdeal - gotta switch into evening, dinner, kiddo mode.  may  check in later this eve, if not, catch you tomorrow.   thank you.
<lazyPower> ack beisner, thanks for the last minute checkin
<lazyPower> see you in the AM o/
<lazyPower> Bigdeal: just got word back that we dont have an update for the -devel ppa yet as core hasn't had a blessed release yet w/ the new features, so its coming but is not trivial to test right this minute.
<Bigdeal> lazypower: Thanks a lot for your help
<Bigdeal> in the meantime I will try to setup swift
<lazyPower> Best of luck Bigdeal. If you encounter any further questions feel free to ask and someone will be with you shortly. Sorry I didn't have a quick answer for you to get moving right away today, but we're actively working on it :)
<Bigdeal> Thank a lot I will keep trying this evening and get back to you tomorow
<lazyPower> Cheers Bigdeal
<lp|conference-mo> aww my -mode got nuked
#juju 2015-08-13
<IceyEC> I'm trying to setup the ceph charm for development of a charm that will connect to it, I try: `juju deploy -n 3 ceph`
<IceyEC> and then juju status shows that each node is at: ` 'hook failed: "mon-relation-changed"'`
<IceyEC> looks like I need to add the monitor-secret and fsid, adding those now
<IceyEC> I'm looking at the Charmhelpers code, specifically, https://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/storage/linux/ceph.py#L292
<IceyEC> am I correct that this cannot work on LXC?
<IceyEC> I'm developing with the local provider and am getting modprobe errors, digging in it looks like modprobe is not supported in LXC containers
<marcoceppi> IceyEC: you are correct, at the moment ceph requires block devices and there are none in the LXC/Local provider with Juju
<marcoceppi> IceyEC: you can use KVM instead of LXC for the backend to local provider
<marcoceppi> IceyEC: that way modprobe would work as epected
<IceyEC> ok, thanks
<marcoceppi> IceyEC: I see zero docs on this, but lp|conference and mbruzek have done this recently
<IceyEC> cool, I'm trying to add ceph support to the solr-jetty charm and discovered that it isn't letting me setup the block device :-P
<marcoceppi> IceyEC: heh, yeah, ceph on local provider def does not work in LXC, might work in KVM, jamespage would probably know better
<jamespage> IceyEC, marcoceppi: actually it does
<marcoceppi> :O
<IceyEC> sounds great :)
<jamespage> you can provide a directory name as a block device - e.g. /tmp/osd
<jamespage> for example
<IceyEC> in lxc?
<IceyEC> because, I did that
<jamespage> IceyEC, yes
<IceyEC> /var/ceph was the device name I gave it, and it still tries to do modprobe
<jamespage> IceyEC, the ceph charm does?
<IceyEC> yeah
<IceyEC> well
<IceyEC> no
 * jamespage looks
<IceyEC> I'm using the code that the MySQL charm uses to configure Ceph
<IceyEC> which is almost the same as the CharmHelpers code for Ceph
<jamespage> IceyEC, right - that does not work under LXC at all
<IceyEC> both of which do hit modprobe in the configure function
<IceyEC> so, I can setup cep but I cannot use it under lxc?
<jamespage> IceyEC, its a limitation of running in a LXC container - you can't modprobe or suchlike
<IceyEC> yeah, will just reconfigure to use kvm :)
<jamespage> IceyEC, ack - that would work
<IceyEC> sounds good :)
<jamespage> even if its a bit heavier on resources
<IceyEC> hope to have something for you and arosales soon ;-)
<IceyEC> this machine has 32G of RAM, dual dual core XEON's
<IceyEC> have resources to deal with :)
<g3naro> jooooojooooo
<marcoceppi> IceyEC: I'll swing mbruzek your way when he comes online, should be able to get you the short of the long of KVM as local provider
<IceyEC> cool, thanks marcoceppi
<suchvenu> Hi Matt
<mbruzek> Hello
<suchvenu> I got a review comment on  Performance for DB2 charm
<suchvenu> Can you please help me to understand that better
<mbruzek> Sure!
<marcoceppi> mbruzek: when you get a second, can you share how to use KVM as the provisioner for local with IceyEC? They're having some modprobe issues with LXC and IIRC you addressed that in docker with KVM on local
<mbruzek> When I deployed db2 on amazon the disk space on the VM was highly consumed.
<suchvenu> ok
<mbruzek> suchvenu:  I don't remember the exact number but it was nearly out of hard drive space.  With Juju you can request larger instances with constraints, but there was also a /mnt directory that had 190GB free
<suchvenu> I checked the DB2 and found that we an create Databases and logs to using "create database db name on <>" commands
<suchvenu> Is that the one you are looking for ?
<mbruzek> suchvenu: I also know that the minimum Amazon instance has low RAM 1.7GB.  I don't know how much RAM DB2 needs to run at optimum performance
<suchvenu> ok
<mbruzek> suchvenu: No, I was thinking if the README could make some suggestions on disk size and or RAM size for the best performance of DB2
<suchvenu> ok
<mbruzek> suchvenu: I don't know where the database is written on that charm,but if the database gets used and grows I fear the filesystem on those small instances will be totally consumed.
<mbruzek> Running out of disk space is a very difficult problem to diagnose, because even log files can not be written.
<suchvenu> okk
<suchvenu> So you are suggesting to add the RAM and disk size requirements in Readme ?
<mbruzek> suchvenu: The juju constraints you can set are root-disk (file system) and mem (RAM)
<mbruzek> Yes to what is recommended.  And perhaps a warning that an install of DB2 will consume a large percentage of free space if the constraints are not used.
<suchvenu> okk
<suchvenu> All these in README, right ?
<marcoceppi> IceyEC: there are docs! Just in devel still: https://jujucharms.com/docs/devel/config-KVM
<suchvenu> Ok Thanks mbruzek... I will add the details in README and push it back for review.
<mbruzek> suchvenu: Yes find out what is recommended and put that in the README.  But if we find that the small instance is not sufficient we should list that as well in the RADME
<IceyEC> heh, I have that open already ;-) following along, will hopefully have ceph mounts purring along shortly :) thanks marcoceppi
<suchvenu> Ok
<mbruzek> suchvenu: Also consider deleting the unneeded RPMs or packages for other architectures in the charm code
<IceyEC> so, I've got it creating the block device, but when I try to mount it with charmhelpers.contrib.charmsupport.volumes.configure_volume, I'm getting `mount: block device /dev/rbd1 is write-protected, mounting read-only\nmount: you must specify the filesystem type`
<IceyEC> something I broke removing other code? possibly!
<jcastro> hey beisner
<beisner> hi jcastro, back in 1 min..
<jcastro> ack, I want to talk about: https://bugs.launchpad.net/bugs/1373862
<mup> Bug #1373862: MySQL doesn't deploy due to oversized dataset <mysql (Juju Charms Collection):Fix Committed by marcoceppi> <https://launchpad.net/bugs/1373862>
<beisner> jcastro, howdy, back
<jcastro> yeah so basically, people keep running into this issue when trying Juju on LXC
<beisner> jcastro, right.  i totally understand.
<beisner> jcastro, but imho, we can't just change a long-standing default value.
<jcastro> iirc, all we did was just pick a percentage
<marcoceppi> clint chose a default over 3 years ago
<marcoceppi> Oracle says that default is not a sane value
<marcoceppi> and provided us with a better value
<marcoceppi> I understand teh upgrade delemia, I want to see if Juju does teh right thing or not
<beisner> jcastro, right, but that makes it even more important to discuss.  we have an established expectation with a fairly large user base, who are accustomed to that default value.
<jcastro> beisner: sure, happy to do that, maybe we should do it on the list?
<jcastro> and I'd like to counter that we keep losing users when they try juju and it doesn't work
<arosales> IceyEC, good to hear :-)
<jcastro> beisner: should I bring it up on the list? I am curious as to what would happen during upgrades
<beisner> jcastro, marcoceppi - here's a use case to consider:
<beisner> i'm joe admin and company X.  i have a couple of juju-deployed database servers with 256GB of ram (the charm's established behavior gives mysql 204GB).  i like it.  i need to add more servers at another site location in a new juju environment.
<jamespage> rick_h_, urulama: hey - fyi I've finally got the openstack-base bundle updated and in-store
<beisner> joe will now have 128 MB whereas he had 204GB for his service, unless he changes his ways.
<marcoceppi> beisner: so beacuse we made a mistake 3 years ago we can't fix it? Sounds like Joe should be using bundles and explicitly setting values. While the GUI won't export default config options, it doesn't mean that shouldn't change
<jcastro> so I suspect someone using it in production is setting explicit values for everything with like a yaml file, but I could be wrong
<beisner> marcoceppi, i don't necessarily disagree.  arbitrary value setting stinks.
<beisner> jcastro, could be.
<marcoceppi> beisner: the way you've set up this defense means that no default values should really ever be changed ever
<beisner> i do think it merits this type of convo, and advanced notice before committing, if that is what is decided (and i can be completely fine with that).
<jcastro> ok cool, I'll summarize your examples and post nowish
<jcastro> beisner: marco and I are on a mission today to crush papercut charm bugs
<jamespage> jcastro, hey - we've discussed having the percentage still - but capping at a sane max based on 'defaults'
<beisner> marcoceppi, kind of yeah.  we try very hard to never change default behavior in the openstack charms for this reason.   reason:  any time you alter default behavior, you risk borking someone.
<beisner> marcoceppi, not to say it doesn't happen, or can't happen.  just raising the "we should talk about this" flag.
<marcoceppi> jamespage: there may well be databases big enough to need 28GB of the 32G it's installed on
<marcoceppi> for innodb-buffer
<jamespage> marcoceppi, sure
<jamespage> marcoceppi, I was thinking like 80% or 32G, whichever is smaller
<marcoceppi> jamespage: still won't fix the container story
<marcoceppi> or local provider issue
<beisner> marcoceppi, setting the value will fix both, no?
<jamespage> marcoceppi, the only thing that will fix the container story is lxcfd
<jamespage> lxcfs
<jamespage> rather
<marcoceppi> jamespage beisner I'd even be find with having this set to the default innodb-buffer-pool-size from distro, which might be the best way to solve this
<marcoceppi> jamespage: true, can't wait for that
<jamespage> marcoceppi, agreed
<beisner> marcoceppi, yeah keeping somewhat in line with the underlying product's default sounds like a good thing, generally speaking.
<jcastro> ok, mail sent to list.
<jcastro> that way we have more people chime in
<marcoceppi> jamespage beisner FWIW, deafult innodb_buffer_pool_size is ~134MB
<marcoceppi> I'll update my merge proposal to reflect this, the readme to outline it better, and the tests to work with the update (while teh discussion on the list happens)
<jcastro> marcoceppi: man, I was really hoping we could have just lit the thing on fire and walked away in slow motion with dramatic music playing.
<marcoceppi> jcastro beisner: if a value is marked as "default" in juju, on upgrade it gets the new default value
<marcoceppi> i hate everything
<beisner> marcoceppi, bahh.  i was hoping the opposite.
<marcoceppi> I guess mysql will just be forever broken until lxcfs
<jcastro> hah man, awesome.
<marcoceppi> I just wish there was a way in upgrade-charm to mark configuration as no longer default
<jcastro> marcoceppi: ok, so we need to ask core for it to behave the other way
<marcoceppi> jcastro: not exactly
<marcoceppi> there is no right answer to this, except to give the charm more control over aspects like configuration
<jcastro> I am fine with anything that isn't "leave it broken until lxcfs"
<marcoceppi> jcastro: well, asking for a feature like this in core is basically tandamount to that
<hazmat> you can try and detect running in the container and the self cgroup, but juju doesn't touch cgroup constraints unfortunately so there's no valid value to assume (even with lxcfs).
<hazmat> there's a long standing bug to have juju set constraints on the container per the service constraints
<marcoceppi> hazmat: I wonder if moving from direct lxc to lxd for local provider would help this
<hazmat> marcoceppi: in and of itself, probably not.. juju needs to set constraints on the container else any given container will still see host resources as its own.
<marcoceppi> just gaining an actual bootstrap node on local would be a win, and I think thumper is working on this, but I'm not sure if it would address the constraints/cgroup issue
<hazmat> marcoceppi: moving to lxd has other benefits though, like making machine 0 not special
<hazmat> marcoceppi: i still use my jury rigged lxc scripts for local dev, just so i can avoid the machine 0 as host setup that local provider currently tries.
<marcoceppi> hazmat: ack, I'll go find the bug and see if I can't get it a little higher in priority
<hazmat> marcoceppi: https://bugs.launchpad.net/juju-core/+bug/1323446
<mup> Bug #1323446: constraints on local provider <constraints> <local-provider> <lxc> <juju-core:Triaged> <https://launchpad.net/bugs/1323446>
<marcoceppi> jcastro: ^
<jcastro> looking, sorry was on the phone
<rick_h_> jamespage: cool, I know the team was getting a fix in for the nested lxc issue and a new deployer/gui/quickstart to make sure that works as well.
<rick_h_> jamespage: I'm on holiday today but don't hesitate to grab frankban or Makyo if anything isn't right there.
<Makyo> o/
<jamespage> its all cool ta
<jamespage> rick_h_, enjoy your holiday
<pmatulis> with HA, how does the juju master get associated with the mongodb master? is it random (among the ones which are about to be created) or is it always the initial single state server?
<hatch> is there a way for me to get a single configuration value from the cli?
<rick_h_> hatch: can't you juju get the single option?
<thumper> yes
<thumper> hatch: environment or service?>
<hatch> service
<hatch> you can't according to the 'get' docs
<rick_h_> hatch: yea, see thats in the docs. I might be thinking of the charmhelpers in python :/
<rick_h_> thumper: service config for a single config item
<rick_h_> thumper: help is showing nothing to help at that level
<hatch> I suppose it's partially irrelevant, my issue is that I have to put keys into a config option (because juju doesn't allow files as configuration options)
<thumper> rick_h_, hatch: wow... that sucks
<hatch> but when I write them out to the file they are malformed
<thumper> you should be able to
<rick_h_> thumper: yea, seems like it'd be an obvious one but just adding that as an narg fails
<thumper> also, the format difference between 'juju get' and 'juju get-env' is jarring
<rick_h_> thumper: gotta love a consistent api :/
 * thumper sighs
<thumper> we suck
 * thumper adds a tech-debt bug
<hatch> basically what I'm trying to determine if the `config-get mykey` returns the value formatted, the key file ends up with a bunch of \'s instead of real newlines
<rick_h_> hatch: hmm, I know we use the @filename.txt thing in a charm script to get a file contents read in properly
<rick_h_> hatch: maybe need to lok at that?
<hatch> rick_h_: I have to set about 15 config values so I have a yaml file which I provide when deploying
<rick_h_> hatch: ah ok
<hatch> rick_h_: so you're saying to do it manually for each key?
<rick_h_> hatch: no
<hatch> I think that the `config-get mykey` is returning the value with \'s for newlines
<hatch> from within the service unit is there any way for me to open up a window that's in a 'hook environment' ?
<rick_h_> open up a window?
<rick_h_> e.g. debug-hooks or dhx?
<rick_h_> let you get a terminal in a hook context
<hatch> right but I have to drop out to my normal machine, set up debug hooks, then go make a config change or something
<hatch> then it'll pop up
<hatch> I feel like I should be able to do something like... juju ssh service/0 --hook-context
<rick_h_> check out charmhelpers contrib? does dhx do it?
<hatch> nope :)
<hatch> it does some cool things like allowing you to customize a window
<hatch> but not let you actually open one in the hook context
<rick_h_> well, debug-hooks + config change it is :P
<hatch> yeah....I've just done a few of these 'simple' charms and have noticed a lot of small pain points that start to add up
<rick_h_> yea, have to see/add them to the eco list they've had on charming pain points.
<rick_h_> hatch: maybe some use of juju-run can help? isn't that in a hook context or is it not? I can't recall
<hatch> it is when you're executing a file (running the hook file works) but not when you're passing a command odly enough
<marcoceppi> hatch: there's no way
<marcoceppi> welcome to the wonderful world of the developer experience
<marcoceppi> you have to trigger a hook to get the hooke context in juju, and the only way to do that is with with debug hooks or using juju-run (but that's not an interactive session)
#juju 2015-08-14
<thumper> marcoceppi: *bzzt* wrong
<thumper> marcoceppi: juju run runs within a hook context
<thumper> marcoceppi: however, it isn't as easy as it should be
<thumper> marcoceppi: I managed to execute juju run to get a relation config value using the CLI
<thumper> but it requires a bit of prior understanding that isn't entirely obvious
<pmatulis> with HA, how does the juju master get associated with the mongodb master? is it random (among the initial one + the ones which are about to be created) or is it always the initial single state server?
<rick_h_> pmatulis: I'd assume it'd have to be the first ones. Until the others are brought up and sync'd they're not able to be a master.
<pmatulis> rick_h_: makes sense
<rick_h_> pmatulis: I guess it's not final/official. I think natefinch might know more/better if I'm incorrect.
<natefinch> pmatulis, rick_h_: Mongodb chooses a master, and we make that Juju server the master
<natefinch> pmatulis, rick_h_: if there's only one state server, obviously it's the master.  When you add more, mongodb chooses a new master through its magical and mysterious algorithm
<pmatulis> natefinch: ah, the juju master always resides on the same host as the mongodb master?
<natefinch> pmatulis: yep, just easier that way
<pmatulis> natefinch: perfect
<bloodearnest> so, it seems destroy-environment in manual provider doesn't invoke destroy-service on the environments services. Is this expected?
<bloodearnest> means I need to remember to manuall destroy-service's first, before tearing down the env
<skylerberg> Hi guys. I am starting to write my charm and I see that pretty every charm (that I have looked at) calls execd_preinstall at the start of the install hook. It is not clear to me after looking at the source code for this function what it does.
<marcoceppi> skylerberg: this is really for our IS team, they do a special bit that adds an execd directory to call additional files
<marcoceppi> it's how they add code for certs and stuff
<skylerberg> marcoceppi: Alright. Thanks Marco.
<mbruzek> Hello marcoceppi.  I am still having trouble getting amulet to deploy with this added binary.  I tried deleting the .bzr directory, but then I got juju-deployer errors, and I have tried your commit trick and which didn't work.
<mbruzek> marcoceppi: Any other options?
<marcoceppi> mbruzek: wait until next week and try again?
#juju 2015-08-15
<redelmann> Hi, anyone can give me a hand with some strange problem in juju-gui?
<redelmann> Already open a bug in: https://bugs.launchpad.net/juju-gui/+bug/1485249
<mup> Bug #1485249: Juju gui is not loading. <juju-gui:New> <https://launchpad.net/bugs/1485249>
#juju 2015-08-16
<dni> hi, have some troubles getting to juju-gui following https://jujucharms.com/docs/devel/config-vagrant
<dni> i dont get to output of the gui with the password like shown in the example
<dni>  https://gist.github.com/dni/a416d991dd5bc9efee16
<dni> anybody can help me ;)?
<dni> a also created the box successfully
<dni> do i have to manually edit the Vagrantfile? ;)
#juju 2016-08-15
<blahdeblah> Any ecosystem folks around by chance?  Looking for some guidance on getting the 2.x-compatible version of juju-deployer & python-jujuclient up & running
<blahdeblah> Alternatively, can anyone point me to an up-to-date packaged version of juju-deployer & python-jujuclient?
<miken> Can anyone tell why I see a install hook failure here that seems to be juju itself failing with a socket error? http://paste.ubuntu.com/23057586/
<andrey-mp> jamespage: could you look to my question in review https://review.openstack.org/#/c/348336/6/metadata.yaml ?
<gennadiy> hi everybody, i try to use layers in my juju charm. as i understand i need to execute `charm build` and publish result. but in this case result charm is pretty complicated(it contains code from all layers). is it possible to publish only my own layer?
<lazyPower> gennadiy - sure, you can checkin your layer to git. If you've built a middle layer, we have a web-service to warehouse those. However in order to push to the charm store you will need to push your assembled charm. Top layers typically aren't useful without all their supporting layers code.
<gennadiy> @lazyPower, it's clear for me when we use local charms. but i think it can be implemented for charms from store too. juju can run "charm build" during deployment process
<lazyPower> gennadiy - right now charms are built and assembled externally to the deploy process. That sounds like a reasonable feature reuqest to bring up on the list or the issue tracker.
<gennadiy> yesterday i tried to create custom charm with docker layer. i have added small part of code but when i built by charm i was surprised. my charm contains all code from all layers
<lazyPower> gennadiy - anything you dont want from a lower layer can be ignore'd or overridden with a file in your top layer.
<lazyPower> there is an ignore keyword in layer.yaml that should help you sort out what you dont want to bring forward
<lazyPower> https://github.com/juju/charm-tools/issues/214 <- some info here
<lazyPower> and additional info here: https://github.com/juju/charm-tools/issues/220
<jcastro> stokachu: can you check this one out? http://askubuntu.com/questions/811389/openstack-install-fails-because-of-wrongly-specified-ubuntu-version
<stokachu> jcastro: done
<jcastro> thanks!
<BlackDex> hello.. How can i unblock specific services
<BlackDex> some have the "workload/status" blocked
<rick_h_> BlackDex: so they tend to be blocked for some reason. for instance a web app might be blocked until it's realted to a database for the back end
<rick_h_> BlackDex: so it's dependent upoon the application you're working with at the moment
<geetha> Can any one please check this bug : https://bugs.launchpad.net/juju-core/+bug/1602572
<mup> Bug #1602572: Handler function is not being called even after changed one of the config values of the config.yaml <juju-core:Triaged> <https://launchpad.net/bugs/1602572>
<rick_h_> geetha: ty, asked cory_fu to take a peek when he gets a chance.
<geetha> Please...it's stopping me to push my charm.
<geetha> thanks rick_h_
<valeech> Is there a good mechanism to install containerized openstack (ie docker) via juju? Has anyone seen a write up?
<MonsieurBon> Hi all
<rick_h_> valeech: there's a lxd deployment notes here: https://github.com/openstack-charmers/openstack-on-lxd
<valeech> rick_h_: thanks!
<MonsieurBon> anyone here who could help me with setting up glance with swift? Everything seems to work fine but when creating an image in glance a 500 internal server error is thrown: http://paste.ubuntu.com/23058730/
<MonsieurBon> I checked the configuration of glance and swift_store_key is present in /etc/glance/glance-api.conf
<andrey-mp> try restart glance-api
<andrey-mp> but i don't know what happens
<andrey-mp> if you relate glance to swift then all should works
<andrey-mp> it can be dependent from OpenStack version
<MonsieurBon> andrey-mp, I have swift-proxy related to glance, keystone and swift-storage
<MonsieurBon> ok, but I think it worked!
<andrey-mp> I've never configured glance to swift
<andrey-mp> only to cinder )
<andrey-mp> what version are you use?
<MonsieurBon> andrey-mp, trusty/swift-proxy-54, trusty/glance-251 not sure what versions those are
<andrey-mp> i mean version of OpenStack
<MonsieurBon> how can I tell?
<andrey-mp> dpkg -s python-cinder
<andrey-mp> on node with cinder
<andrey-mp> or check config parameter of any openstack charm - there should be version
<MonsieurBon> Is that what you're looking for? 1:2014.1.5-0ubuntu2 this if from dpkg -s python-cinder. I couldn't find any information on the charms
<andrey-mp> yeah
<andrey-mp> this is IceHouse
<andrey-mp> very old version )
<MonsieurBon> Well it's the current Trusty version of the charms
<andrey-mp> are you really want to use this version? i would try to use newer first...
<andrey-mp> version can be defined with paramter "openstack-origin": "cloud:trusty-mitaka"
<MonsieurBon> Ok, I will give it a try.
<andrey-mp> looks like it is a bug in glance charm
<andrey-mp> or in the glance )
<andrey-mp> anyway - IceHouse version is not supported now...
<MonsieurBon> Ok, I'll try with a newer version :)
<MonsieurBon> juju is not stable on Xenial yet, is it?
<rick_h_> MonsieurBon: not juju 2.0, juju-1 is
<MonsieurBon> rick_h_, that's what I meant :)
<bdx> how's it going everyone?
<bdx> I'm trying to write a consul-base layer to be consumed by my consul-agent and consul-server charms here -> https://github.com/jamesbeedy/layer-consul-base
<bdx> having some trouble understanding how I might have the consul agent interface to the consul server using 'raft' relation stub .... it seems its service name sensitive though, so I'm having a tough time understanding how I might join services with a different name e.g. 'consul-agent' to the consul-server cluster ...
<bdx> any ideas?
<kwmonroe> petevg: wasn't there an issue where zk would not honor 0.0.0.0 for clientPortAddr?  is this checking that the value gets changed, or do we expect zk to actually re-bind to all interfaces? https://github.com/juju-solutions/bigtop/pull/38/files#diff-f5b8005c1652359285aac30975c6290bR67
<petevg> kwmonroe: Yep. Forgot to drop in a comment. I'm skipping the test because Zookeeper is broken.
<petevg> Will drop one in ...
<kwmonroe> ahhh, roger that petevg.  i recall you saying that wasn't valid until upstream zk handles it.  my bad.
<kwmonroe> .. and i see the 'return' right up in my face on that test case now
<kwmonroe> bdx: how is it being 'service name sensisitve'?  is something looking for an explicit 'consul-server' string?
<petevg> kwmonroe: I decorated that test with unittest.skip, with appropriate note. Thx for the catch.
<kwmonroe> nice petevg!  i didn't know about unittest.skip.  TIL.
<bdx> kwmonroe: when I `juju deploy -n 3 consul`, the consul service uses raft protocol to facilitate determining the cluster creation, state and member states ... etc ... I guess I'm wondering how the consul-agents would use the raft stub to join the cluster too
<kwmonroe> your problem here, bdx, is that i don't know how the current consul stuffs work ;)  i'll poke around and see if i can offer a suggestion.
<bdx> kwmonroe: awwwe shucks .... I'm might be mistaken by thinking that the consul agents need to participate in raft -> https://postimg.org/image/5rdlif72n/
<bdx> kwmonroe: np, thanks
<magicaltrout> thanks for swapping that meeting lazyPower
<lazyPower> magicaltrout - np sorry for the scheduling conflict :)
<magicaltrout> they have to pry my protective contacts out
<magicaltrout> the sooner the better
<magicaltrout> was just telling jcastro I got asked to present at mesos usergroup london as well lazyPower
<lazyPower> Nice, so you're going to be the traveling engineer on all this :D
<lazyPower> i got pinged by marketing this morning about the topic page. Did you wind up syncing with someone over that? i got disconnected from that whole process over the last few weeks
<jcastro> hmm, we should have given you shirts when you were in london
<magicaltrout> i did have a big long chat with someone about it off the back of your email
<magicaltrout> i'm not sure what happened after that
<petevg> kwmonroe: I just updated https://github.com/juju-solutions/layer-apache-bigtop-base/pull/39 -- it had a stray reference to charms.unit, which isn't release yet (I changed the reference back to point at bigtop_harness).
<kwmonroe> cool petevg
<bdx> question on subordinate charms/relations ...
<bdx> so I'm working with the consul service, I have a need for consul-server and consul-agent server charms
<bdx> blah .. consul-server and consul-agent charms *
<bdx> the problem I'm having is this
<bdx> how can I make a subordinate charm install software on a primary when related to one service, and just do something else when related to another service (not install software on primary)
<bdx> I've been looking at cinder-ceph, and nrpe as examples
<bdx> oooh, I think I see .... you have to use 'scope: container'
<mayurisapre> hello everyone..
<mayurisapre> how to bootstrap in openstack environment with JUJU 2.0?
<rick_h_> mayurisapre: is it an openstack setup for you? or something you've setup?
<mayurisapre> i have openstack env
<mayurisapre> i just confused with all add-credential, config.yaml, credential.yaml, cloud.yaml files
<mayurisapre> i am trying to add openstack cloud with add-credential command with credential.yaml file
<mayurisapre> it is giving me an error
<rick_h_> mayurisapre: https://jujucharms.com/docs/stable/clouds#specifying-additional-clouds is the user end side
<miken> Can anyone tell why I see a install hook failure here that seems to be juju itself failing with a socket error?  http://paste.ubuntu.com/23057586/
<miken> If I try to debug-hooks, I see "failed to connect to server"
<miken> it drops me in a session, but the debug-hooks session is never started when resolved --retrying
#juju 2016-08-16
<bjf> how do i set the http/https proxy in juju 2.0 ?
<stokachu> bjf: juju set-model-config http_proxy=<url> https_proxy=<url>
<stokachu> https://jujucharms.com/docs/master/models-config
<lazyPower> miken - I cannot speak authoritatively, but it appears that either its missing its own network config, or something is already bound to the ip/port its trying to bind to
<bjf> stokachu, yeah, thanks, found it
<shruthima> Hello Team , We are developing a new charm for IBM Installation Manager on Z platform. As already an IM charm exist in charm store as ibm-im, What would be the charm name for IM on Z?
<rick_h_> shruthima: does the Z charm need to do things a lot differently such that it can't be made to work on Z?
<rick_h_> shruthima: ideally, we'd have the single ibm-im charm and if it was deployed on Z would do the right things to work there, if on power do those things, etc. So the end user can't use it incorrectly and there's no confusion between "which similarly named thing do I use?"
<shruthima> minor changes but similarly we have 3 more products we have do on Z which requires more changes , so we want to know what name can be given to Z platform charms if charm exist already
<rick_h_> shruthima: you can add a -z to the name or the like. I'd just like to encourage that things work as widely as possible without potentially causing confusion to users.
<shruthima> is ibm-im-z can be fine ?
<mbruzek> Actually rick_h_ we talked about this at the meeting with the IBM developers
<lazyPower> That seems counter intuitive to have a charm per platform
<lazyPower> i would think your original suggestion was more correct rick_h_, where there is a lsb_release check at the very beginning, and you can adjust based on states from there
<mbruzek> rick_h_: The ecosystems team talked about this at length and think that they can add z-support on the series boundary but need to support all platforms in a new charm.
<lazyPower> @when('z-series'); @when_not('ibm-im.installed')  -- #perform z-series steps     @when('ppc64le'); @when_not('ibm-im.installed')  -- # perform ppc steps
<rick_h_> mbruzek: lazyPower k, I'll leave you all to work it out with folks.
<mbruzek> shruthima:   to avoid juju user confusion the charm should have the same name.
<lazyPower> thanks rick_h_  <3
<shruthima> ok thanku mbruzek ,lazypower and rick_h_
<Prabakaran> hi mbruzek/ kwmonroe , Good Morning.. I have pushed ibm spectrum symphony to charm store under cs:~ibmcharmers stream but it is not reflecting under charm store. Could you please check and advise on this?
<mbruzek> what revision number?
<Prabakaran> cs:~ibmcharmers/ibm-spectrum-symphony-storage-0
<Prabakaran> this is supported on both trusty and xenial
<bdx> icey: ping
<rick_h_> Prabakaran: did you publish the revision?
<Prabakaran> yes i did
<Prabakaran> i remember
<rick_h_> Prabakaran: and granted everyone permissions?
<Prabakaran> yes i did
<fuzsz> Just like to share the difficulties of using Google Cloud. It seems to like to change the external IPs from underneath the user and without the IPs to the controller machine your bonked until you go and update them.
<fuzsz> Only way I found this was using the --debug flag on `juju list-models`
<fuzsz> And checking that the IPs match the local configuration controllers.yaml
<fuzsz> I've noticed juju automatically tags each machine with metadata specific to juju, so can't it just auto-negotiate the IP change by using the tags to find the controller?
<rick_h_> fuzsz: interesting, can you file a bug on that please?
<fuzsz> Sure. But the github repo doesn't seem to have bugs anymore?
<fuzsz> I've also found a workaround. Google App Engine allows setting a static ip address to a machine.
<rick_h_> fuzsz: right, https://bugs.launchpad.net/juju-core is the bugs
<fuzsz> Any reason why launchpad can't sync with GitHub API to allow for bugs on the juju repository? Just an opinion; I'm not a fan of launchpad.
<Prabakaran> thanks rick_h_ .. i tried giving charm grant ... i am able to see my charms now
<Prabakaran> Hello Team, I have 3 charms letâs say A, B and X. Out of which A, B are principle charms and X is a subordinate charm. Here X is a subordinate charm to charm A. So I will be adding relation between A and X like
<Prabakaran> Juju deploy add-relation A X
<Prabakaran> In this scenario if X wants perform some operation on charm B
<Prabakaran> how would I relate these charms? Whether I need to add relation like
<Prabakaran> 1, juju add-relation A B   2, Juju add-relation X B ( Subordinate charm may sit into principle charm B, if so , I donât want this to happen) Could someone explain me this scenario in detail?
<Prabakaran> hi cory_fu
<Prabakaran> can you please help me on the question?
<cory_fu> Prabakaran: Hello
<Prabakaran> Hello Team, I have 3 charms letâs say A, B and X. Out of which A, B are principle charms and X is a subordinate charm. Here X is a subordinate charm to charm A. So I will be adding relation between A and X like
<Prabakaran> Juju deploy add-relation A X
<Prabakaran> In this scenario if X wants perform some operation on charm B
<Prabakaran> how would I relate these charms? Whether I need to add relation like
<Prabakaran> 1, juju add-relation A B   2, Juju add-relation X B ( Subordinate charm may sit into principle charm B, if so , I donât want this to happen) Could someone explain me this scenario in detail?
<cory_fu> Prabakaran: Ok, sure.  It's basically what you suspected; you add a relation from X to B, and it should be a normal relation (i.e., not scope: conntainer) and then it will work just fine
<Prabakaran> can u give me some hint on metadata.yaml file on these?
<cory_fu> Prabakaran: As an example, you can look at https://jujucharms.com/apache-hadoop-plugin/  It is subordinate (the hadoop-plugin relation) and has non-subordinate relations as well (namenode, resourcemanager)
<cory_fu> The metadata.yaml file, of course, is at https://api.jujucharms.com/charmstore/v5/apache-hadoop-plugin/archive/metadata.yaml
<Prabakaran> k i will refer this.. I tried all these i was getting some issue.. I suspect it is becused of the provide /requires in the metadata.yaml file only. can u help me with the requires/provides section of metadata.yaml on this scenario for A, B and X.
<Arjun> hi
<cory_fu> Prabakaran: Ah, yes.  provides / requires for subordinates is confusing.  The principle charm should provide the scope:container relation and the subordinate should require the scope:container relation.  For the non-subordinate relation (between B and X), which side provides and which requires doesn't matter as much, so should just be whatever makes the most sense.  If X is using some functionality that B gives, then B would provide and X would
<cory_fu> require.  But X could also provide something for B to require if that makes more sense for your specific use-case.
<Prabakaran> k let me send u pastebin link can u correct if i am wrong in this scenario?
<cory_fu> In the case of the apache-hadoop-plugin, the NameNode, for example, provides DFS services to the plugin, so on the plugin all the relations are requires, but it could be that the subordinate relation was requires (has to be) and the other relations could be provides
<cory_fu> Sure
<Prabakaran> hi cory_fu , below are the metadata.yaml files can you please correct me if I am wrong? I will correct it now only. Here I am using mysql-charm and mysql-root interface. X â Subordinate Charm - http://pastebin.ubuntu.com/23062310/ A â Principle Charm - http://pastebin.ubuntu.com/23062312/ B (mysql) - Principle Charm - http://pastebin.ubuntu.com/23062316/
<Prabakaran> correct me on the metadata.yaml file of X charm and A charm
<cory_fu> Prabakaran: Ok, just remove "scope: container" from the mysql block in the X (i.e., delete line 14)
<cory_fu> That should be all you need to do
<Prabakaran> k cory_fu .. i did changes.. i am deployin now i wil let you know how it goes
<cory_fu> Ok
<bdx> charmers: I seem to be at an impasse with my reactive consul/consul-agent charms, I'm so close I feel .... would someone mind taking a look at consul/consul-agent for me?
<cory_fu> bdx: Sure thing
<cory_fu> bdx: link?
<bdx> cory_fu: https://github.com/jamesbeedy/layer-consul-base, https://github.com/jamesbeedy/charm-consul-agent, https://github.com/jamesbeedy/charm-consul
<bdx> cory_fu: http://paste.ubuntu.com/23062337/
<bdx> cory_fu: what appears to be happening, is my 'consul.connected' state doesn't seem to be getting recognized by the vault charm -> https://api.jujucharms.com/charmstore/v5/~chris.macnaughton/trusty/vault-0/archive/reactive/vault.py
<bdx> such that vault never writes out the config.hcl .... I've been messing around with the consul-agent container relation .... taking it in and out of container scope, but I don't think thats what my problem is
<bdx> the built charms are at https://jujucharms.com/u/jamesbeedy/consul/0, https://jujucharms.com/u/jamesbeedy/consul-agent/4, https://jujucharms.com/u/jamesbeedy/vault/4
<cory_fu> bdx: The interface layer that's registered for consul-agent on interfaces.juju.solutions is https://github.com/ChrisMacNaughton/juju-interface-consul and that has an empty provides.py
<cory_fu> I don't know if that's causing your problem (shouldn't, unless you're rebuilding the vault charm), but it's certainly an issue
<bdx> oh ... I am rebuilding the vault charm
<bdx> oooo
<Prabakaran> cory_fu: I am able to add relation it is working fine but i am not able to perform any operation on the mysql database by Subordinate charm X
<cory_fu> Then that's your issue
<bdx> cory_fu: you are the man!
<cory_fu> bdx: :)
<cory_fu> Prabakaran: What do you mean by "perform an operation"?  Do you mean using the relation interface, or do you mean that mysql itself is giving you errors?  Can I see a copy of the errors?
<bdx> cory_fu: I wonder why that ended up getting commented out lol?
<bdx> icey:^?
<cory_fu> bdx: No idea.  Definitely looks wrong
<bdx> good grief
<Prabakaran> i will be running database quries on mysql charm using subordinate charms
<cory_fu> Prabakaran: Ok, so the queries are failing?  That sounds like an issue with the reactive code, not the relations
<Prabakaran> it is working on principle charm mode
<Prabakaran> i will give u my sample code... it is very simple and it wil not take much time .. can u please check and tel me is there any issue .. i can correct it now only
<cory_fu> Sure
<bleepbloop> Any ideas why on juju 2.0 beta12 after rebooting my state machines I am getting `health ping failed: connection is shut down` and no output from juju status?
<cory_fu> Prabakaran: Are you trying to access the same database from both the principle and the subordinate?  I think each relation to the mysql charm gives you a separate database, username, password, etc.  You might need to use the mysql-shared interface instead.  Or, if you really want the subordinate to act on behalf of the principle, then the DB info can be explicitly passed from the principle to the subordinate over their shared (scope:container)
<cory_fu> relation
<cory_fu> bleepbloop: It sounds like the juju services aren't coming back up, but I have not heard of that being an issue.
<cory_fu> bleepbloop: Beta 15 is out now, so you could possibly try that.  Otherwise, you might be better off asking in #juju-dev
<cory_fu> Unless one of the core devs is on here and can chime in
<bleepbloop> @cory_fu: Okay, thanks. I was considering upgrading to juju beta 15 but I was a bit concerned about doing it when things were broken
<bleepbloop> I'll ask in juju-dev and see if they have a comment
<Prabakaran> cory_fu: I am performing database operation on subordinate charm side only. below are the code files can you please correct me if I am wrong? I will correct it now only. Here I am using mysql-charm and mysql-root interface.
<Prabakaran> Subordinate Charm  https://code.launchpad.net/~prabacha/charms/trusty/sampledatabase/trunk Principle Charm - https://code.launchpad.net/~prabacha/charms/trusty/sampleprin/trunk Mysql database principle charm: https://code.launchpad.net/~prabacha/charms/trusty/mysql/trunk
<cory_fu> Prabakaran: If you are only performing database operations in the subordinate, why does the principle need a relation to mysql at all?
<Prabakaran> correct
<Prabakaran> i think i can remove that part
<Prabakaran> i can add relation between mysql and sampledatabase (subordinate) charm
<Prabakaran> if so, any changes in the metadata.yaml file
<Prabakaran> Let me give u what are the juju  commands i ran..
<cory_fu> Prabakaran: Just remove the mysql block from the requires section
<Prabakaran> Juju deploy mysql
<Prabakaran> juju deploy sampledatabase
<Prabakaran> juju deploy sampleprin
<Prabakaran> juju add-relation sampledatabase sampleprin (As per the code It should show status as âwaiting for mysql relationâ)
<Prabakaran> juju add-relation mysql sampledatabase
<Prabakaran> these are the deployment command i ran
<Prabakaran> here mysql and sampleprin are principle charms
<Prabakaran> and sampledatabase is a subordinate
<Prabakaran> Post deployment sampledatabase subordinate charm doesnt perform any database operation on mysql charm cory_fu
<Prabakaran> cory_fu: do you want me to remove the mysql block from the requires section?
<cory_fu> Prabakaran: It shouldn't really matter, but it just confuses things if the principle isn't going to interact with mysql anyway
<cory_fu> I don't see anything that looks wrong with the subordinate charm code, though.  I'm deploying it now
<Prabakaran> k let me know if it goes fine for you
<Prabakaran> cory_fu:
<cory_fu> Prabakaran: Ok, I got the ACCESS DENIED error when it tries to do the GRANT.
<cory_fu> Prabakaran: Did you modify the mysql charm?  Why do you have a copy of it in LP instead of deploying it from the store?
<Prabakaran> you deploy mysql charm from the link
<Prabakaran> ya
<Prabakaran> this is related to mysql-root interface.. i have give pull request for the same that is y keeping local copy instead
<cory_fu> I see.  Re-testing with your branch now
<Prabakaran> k sure
<cory_fu> Prabakaran: Ok, with your mysql branch it works.  What is the problem, then?
<Prabakaran> is it working fine?
<Prabakaran> cory_fu: i am referring my LP links
<cory_fu> Prabakaran: Yes, they deployed fine and the relations were ok.  I didn't get any charm errors
<cory_fu> And the code in the charms looks fine
<Prabakaran> k r u following any orders of running deployment commands
<Prabakaran> can you paste all the command that u ran
<Prabakaran> during deployments
<Prabakaran> juju commands
<Prabakaran> cory_fu:
<cory_fu> Prabakaran: http://pastebin.ubuntu.com/
<Prabakaran> cory_fu: link is empty
<cory_fu> Prabakaran: ha.  Sorry about that.  http://pastebin.ubuntu.com/23062540/
<Prabakaran> which version of juju that you are using?
<Prabakaran> cory_fu:
<cory_fu> 1.25
<Prabakaran> 1.25
<Prabakaran> i am using 2.0
<cory_fu> Ok, let me try it in that
<Prabakaran> i am tried in 2.0-beta15-xenial-ppc64el
<Prabakaran> cory_fu: exactly
<Prabakaran> cory_fu: It is time for me to sleep ... can you please let me know the status on juju 2.0 deployment ? If it goes fine send me the all details with deployment command to this email prabacha@in.ibm.com.
<cory_fu> Prabakaran: Ok, just finished deploying on 2.0-beta15 and it worked fine.  I don't have access to Power machines, though.
<Prabakaran> :)
<cory_fu> Prabakaran: The deployment commands were basically the same: http://pastebin.ubuntu.com/23062578/
<Prabakaran> thank you so much cory_fu i wil also try the same
<cory_fu> Ok.  Have a good night!
<Prabakaran> thanks againg cory_fu for your patience
<cory_fu> No problem
<miken> lazyPower: Thanks for the reply... actually it was just https://bugs.launchpad.net/bugs/1613489
<mup> Bug #1613489: juju service names limited to 66 characters <pyjuju:Invalid> <https://launchpad.net/bugs/1613489>
<cory_fu> Is there a way to attach a resource from a URL so that I don't have to download it locally only to re-upload it to the controller?
<cory_fu> It's a rather large file on S3 and I'm deploying to AWS
<jrwren> cory_fu: not that I know of, but doing the attach from an ec2 instance should make that reasonably fast.
<mayurisapre> How can I add-unit of a service from another running charm of a service?
<mayurisapre> If I have a relation between these 2 services
<cory_fu> jrwren: Hrm.  But that would require setting up and configuring Juju 2 on the instance.  Though I suppose that shouldn't be too hard with charmbox
<cory_fu> mayurisapre: Applications can't add or remove units on their own.  You'd have to grant them access to the Juju API by giving them the auth token, and that's not recommended
<jrwren> cory_fu: copy .local/share/juju to a new ec2 instance?
<cory_fu> jrwren: Isn't there a share command to send credentials?
<jrwren> cory_fu: not in 2.0 beta14, but things are moving quickly. maybe it does now.
<cory_fu> Hrm.  I thought that was something that had been around for a while
<cory_fu> jrwren: I'm thinking of add-user and register.  Doesn't that provide access pretty easily?
<cholcombe> is there a guide to what is supposed to or allowed to be in the layers.yaml file?
<cholcombe> s/layers/layer/g
<cory_fu> cholcombe: The basic layer README covers pretty much everything, I think: https://github.com/juju-solutions/layer-basic/blob/master/README.md
<cholcombe> cory_fu, thanks :)
<cory_fu> Hrm, no, I'm wrong.  It's missing some
<cory_fu> This has more: https://github.com/juju/charm-tools/blob/master/doc/source/build.md#layeryaml
<cory_fu> We need to consolidate that
<cory_fu> Looks like that was started, but needs a bit more work: https://jujucharms.com/docs/devel/reference-layer-yaml
<cholcombe> cory_fu, i see.  yeah charm build was telling me to add a repo field to my layer.yaml but i didn't know what it wanted in that field
<cory_fu> cholcombe: The message telling you to add it should give you an example.  It just wants the link to the repo for the layer, so that `charm pull-source` knows what to fetch.
<cholcombe> cory_fu, all i saw was this: build: Please add a `repo` key to your layer.yaml, with a url from which your layer can be cloned.
<cholcombe> so repo: url: blah
<cory_fu> cholcombe: Hrm.  Was your layer not a bzr or git repository, or perhaps it hadn't been pushed yet?
<cholcombe> yeah it was  a git repo that i hadn't pushed yet
<cory_fu> Ah, I see
<cory_fu> Well, anyway, it's not required, just strongly suggested, thus why it's yellow
<cholcombe> i added it :)
<cholcombe> cory_fu, question about the apt layer if you've used it.  i added 2 sources to the layer.yaml options: apt: packages: install_sources.  It only seems to set the first one and skips the second
<cholcombe> i can paste my layer.yaml
<cory_fu> cholcombe: install_sources is actually a config option, since it might be changed by the user at deploy time
<cory_fu> cholcombe: It's documented pretty well in the README, I think: https://git.launchpad.net/layer-apt/tree/README.md
<magicaltrout> lazyPower: i've double booked you again =/
<magicaltrout> ffs
<lazyPower> magicaltrout - i'm off tomorrow and was coming in for the meeting anyway
<cory_fu> So, you'd want to override the default for install_sources in config.yaml, but set the apt: packages: in layer.yaml
<lazyPower> lets cancel and reschedule
<cholcombe> cory_fu, i'll mess around with it some more
<magicaltrout> fair enough i was gonna suggest later in the day
<magicaltrout> but that works
<lazyPower> magicaltrout - hows friday? you busy mid-day friday?
<cholcombe> cory_fu, i see
<lazyPower> (mid-day utc)
<magicaltrout> friday is good, can you do 3pm BST or is that too early?
 * lazyPower googles 3pm BST
<lazyPower> you bet, thats 9am for me
<magicaltrout> cool shoot for then, the west coasters are still fetching coffee at that time
<lazyPower> magicaltrout - moved, thanks for following up :)
<lazyPower> we'll eventually make this happen
<lazyPower> like all things :P
<magicaltrout> yeah sorry about that, this is what happens when you book meetings with a blind m an
<lazyPower> well, i'm glad you're recovering well, i see you've adapted to the TTD workflow pretty well
<lazyPower> s/pretty well/quickly/
<magicaltrout> hehe
<magicaltrout> we'll see, got worse today when they took the contacts out, but then is supposed to imrpove  quicker from now on
<magicaltrout> so by friday i might actually be able to see a screen ;)
<magicaltrout> i have my JPL slack zoomed at 180% currently to read it ;)
#juju 2016-08-17
<kjackal> Hello Juju World!
<andrey-mp> Hi! jamespage: are you here?
<marcoceppi> if anyone is interested, charm and charm-tools are now snapped up in edge for testing.
<marcoceppi> `snap install charm --edge`
<rick_h_> marcoceppi: sweet
<rick_h_> marcoceppi: was there any issues with the macaroon storage path and such?
<marcoceppi> not when you PLUGinto home
<marcoceppi> git was the biggest problem >_>
<marcoceppi> rick_h_: https://github.com/juju-solutions/charm-pkg/blob/master/snapcraft.yaml
<marcoceppi> rick_h_: however, putting the macaroon data in $SNAP_DATA_PATH is a good idea
<rick_h_> very cool marcoceppi
<cholcombe> stub, question for ya with the apt layer
<stub> cholcombe: yo
<cholcombe> stub,  i know it's super late there.  I'm running into some trouble getting the config.yaml correct with the apt layer.  I followed the readme closely but it won't build or deploy
<cholcombe> stub, i'm falling back on adding the apt sources in my reactive.py which isn't really the best
<stub> Got a pastebin?
<cholcombe> sure one sec
<cholcombe> stub, https://gist.github.com/cholcombe973/e1405d70ba4921178e0908d7c4a6ba1c
<stub> cholcombe: at first glace that looks fine. What happens when you deploy it?
<cholcombe> nothing it seems.  it doesn't setup either of the sources in the /etc/apt/sources.list file
<cholcombe> when i include the same thing in the python reactive.py file it works ok
<stub> cholcombe: Does your layer.yaml declare its using layer:apt, and its all been rebuild and upgraded?
<cholcombe> stub, yeah i have this in there: includes: ['layer:basic', 'layer:apt', 'interface:ceph-client']
<stub> The indentation seems wonky - it doesn't parse as yaml
<cholcombe> oh yeah i fixed that
<cholcombe> i recreated the file to show you what it looked like
<stub> I'd need to see the logs to diagnose further
<cholcombe> stub, ok no problem.  i can pack them up
<cholcombe> stub, do you have a working example i can take a look at?
<stub> The PostgreSQL charm uses the apt layer. Or are you after a mojo spec that configures it?
<cholcombe> postgres charm sounds fine.  i'll check that out :)
<cholcombe> either one.  i'm looking for how the config.yaml was setup
<cholcombe> prob the mojo spec then
<stub> telegraf-charm might be better
<cholcombe> ok
<stub> launchpad.net/telegraf-charm
<cholcombe> awesome thank you
<stub> cholcombe: In your logs, you should see 'Initializing Apt Layer', soon after which it will call charmhelpers.fetch.configure_sources() (not sure if that gets logged)
<stub> One easy way to test the layer is being bootstrapped - set the 'package_status' config to 'bogus'. It should put your unit into a blocked state until you give it a valid value.
<cholcombe> ok
<stub> cholcombe: oh, that is your config.yaml you posted.
<stub> cholcombe: You are setting install_sources and install_keys to strings, but in config.yaml options are mappings. You want to be setting options: install_sources: default: , not options: install_sources:
<stub> https://git.launchpad.net/telegraf-charm/tree/config.yaml
<stub> (I was thinking that was a deployment config for some reason)
<andrey-mp> anybody knows where is jamespage? or where I can find him? maybe he is on vacation?
<mbruzek> magicaltrout: Are you able to join the meeting?
<cholcombe> stub, thanks!
<stub> cholcombe: I'm surprised juju let you deploy it at all
<cholcombe> stub, juju is lazy haha
<cholcombe> stub, i updated the gist.  is this more like what the apt layer expects: https://gist.github.com/cholcombe973/e1405d70ba4921178e0908d7c4a6ba1c
<stub> that doesn't look right
<stub> https://gist.github.com/stub42/0438059a79dd1cf7d020fa8ad039b3dc
<stub> gah... just revised it. I had bad yaml in one of the strings
 * stub wishes again we had richer data types than strings
<cholcombe> stub, i'll try that :).  Yeah this yaml is miserable
<stub> I don't mind yaml. Its having to encode yaml into strings that get embedded in yaml :)
<cholcombe> lol
<cholcombe> stub, nope that doesn't work either.  nothing is added to the /etc/apt/sources.list file
<stub> cholcombe: How about /etc/apt/sources.list.d ?
<cholcombe> nope that's blank also
<stub> Do you see the 'Initializing Apt Layer' message in the logs?
<cholcombe> i do yeah
<stub> Output from gpg after that?
<cholcombe> nope.  lemme gist it
<cholcombe> https://gist.github.com/cholcombe973/7438f1a25fe2da1a1c6c3a1014c67898
<stub> There isn't much logging here, as it is just calling out to charmhelpers
<cholcombe> right
<stub> Have a look at your generated charm's config.yaml, and see if charm build included your updated defaults
<cholcombe> stub, my bad i forgot to run charm build again.  let me try and deploy this again
<cholcombe> stub, ah yes now we're getting somewhere.  invalid gpg armor header :)
<petevg> cory_fu: For testing the new jdk setup we have in the bigtop base layer, which bundle is the most up to date for testing? Is it https://github.com/juju-solutions/bundle-bigtop-processing-mapreduce, or one of the others?
<cory_fu> Is that still a thing?  We need to delete that repo
<cory_fu> petevg: https://github.com/juju-solutions/bigtop/tree/master/bigtop-deploy/juju/hadoop-processing
<petevg> cory_fu: aha. Thx.
<bdx> cholcomb: sup
<bdx> cholcombe: sup
<bdx> cholcombe: what plans have you for vault_charm?
<bdx> cholcombe: I think we need to combine forces on the vault thing
<bdx> cholcombe: https://jujucharms.com/u/jamesbeedy/consul/1, https://jujucharms.com/u/jamesbeedy/consul-agent/6, https://jujucharms.com/u/jamesbeedy/vault/8
<bdx> they all need readme, icon, and tests :-(
<bdx> the^ consul, consul-agent, vault ha stack deploys successfully :-)
<bdx> cholcombe: I've put alot of work into it recently .... lets chat when you get a minute
<cholcombe> bdx, i'm trying to get the vault charm to hook up with consul so i can store cephx keys on it
<cholcombe> bdx, do you have a bundle i can deploy of that whole setup?
<bdx> cholcombe: omp
<bdx> cholcombe: https://gist.github.com/jamesbeedy/102d1bbcfe5dbf6227f014348026d0a3
<cholcombe> bdx, sweet thanks
<bdx> cholcombe: one existing caveat to the vault charm is that non-leader units error when you request a token though
<bdx> http://paste.ubuntu.com/23065296/
<cholcombe> bdx, i see
<bdx> cholcombe: because they all try to request the token
<bdx> but only a singleton request need be made
<cholcombe> yeah
<cholcombe> that should be a leader only thing
<bdx> yeah ... is there an 'is_leader()' call of some sort that you know of?
<cholcombe> bdx, yeah.  are you using layers or old school?
<bdx> layers
<cholcombe> there's a leadership layer i remember seeing on interfaces.juju
<bdx> yeah, vault is already using it
<cholcombe> cory_fu, do you have any experience with the apt layer and custom sources?  I can't get it working :-/
<cory_fu> cholcombe: A bit.  The most common thing I've seen go wrong is that, since config options can't be nested and thus it uses an embedded yaml string, the indentation on the value is really finicky
<bdx> cholcombe: this might help there too -> https://github.com/jamesbeedy/layer-kibana/blob/master/config.yaml
<cholcombe> bdx, yeah i'm having trouble with the gpg key.  it's complaining about an invalid header but i know it's valid
<cholcombe> cory_fu, yeah the value is hard to get right
<cory_fu> cholcombe: Can you point us to your config.yaml?
<cholcombe> bdx, i'll try to copy your example
<cholcombe> sure
<cholcombe> cory_fu, bdx https://gist.github.com/cholcombe973/e1405d70ba4921178e0908d7c4a6ba1c
<cory_fu> cholcombe: Your indentation is off on your GPG key
<bdx> you need another space
<cholcombe> ok
<cholcombe> so 2 spaces in
<cory_fu> Told you it's super finicky.  It's really annoying to deal with, and setting it on the CLI is even worse
<bdx> I somewhat feel like those params should be options instead of configs
<cholcombe> yeah.  we need a better way than this
<cory_fu> This will get way better when config options support the schema syntax that action params do
<bdx> aah
<bdx> ha
<cory_fu> Unfortunately, that's a breaking change and since it doesn't look like it's going to be in 2.0, I'm not holding my breath.
<cory_fu> Unless the core devs can find a way to make it backwards compatible, which would be rather a bit more work
<cholcombe> 11th deploy is a charm? lol
 * cholcombe crosses fingers
<cory_fu> :)
<cory_fu> petevg: Any objection to me rebasing and squashing BIGTOP-2476-zookeeper?
<cory_fu> No conflicts
<petevg> @cory_fu: other than it never being a good idea to edit the history of a branch that multiple people have checked out :-)
<petevg> The Bigtop people upstream don't seem to like to use github, including github's convenient "squash this when I merge" feature, though.
<cory_fu> Yeah, except that the Bigtop reviewers have specifically asked for nicely squashed PRs
<petevg> So, it's probably fine to just squash it now.
<cholcombe> bdx, yeah so there should be an is_leader() function.  just requires a little searching
<cory_fu> Right.  We could stop using the GitHub <-> Jira integration and submit patches that we manually update instead, but I personally don't find dealing with rebases all that painful
<petevg> cory_fu: yeah. Go ahead. I have some outstanding changes against my local branch, but they're not difficult to recreate.
<cory_fu> git stash is your friend.   ;)
<petevg> cory_fu: In the past, I've had people do really horrible thing with merges when they tried to "fix" a squashed, which is why I try to avoid them. I won't do bad things with it, though, so we should be okay.
<petevg> *things, *squashed branch
<petevg> cory_fu: what we really need to do is get the dang PR merged so that we can stop merging other things to it.
<bdx> cholcombe: yeah, just found it. thx
<cholcombe> bdx, cory_fu thanks!  That got it to install finally
<bdx> np! nice!
<bdx> cholcombe: I'll keep you posted with my vault progress, going to get this mult-token-request thing squared away asap
<cholcombe> bdx, awesome
<cholcombe> what do people typically do for charms if the deb package being installed has an ncurses setup interface that gets invoked while installing?  coreycb you might know this
<coreycb> cholcombe, I'm not sure, but I think that's frowned upon for deb packaging.  for openstack packages, one of the reasons we have separate core packages from Debian, is because Debian uses debconf prompts to configure things.
<coreycb> frowned upon for Ubuntu that is
<cholcombe> yeah the openattic package has debconf prompts.  i don't know how to disable them
<cholcombe> or how i can give it a config file or something
<coreycb> cholcombe, It looks like you can disable debconf - http://stackoverflow.com/questions/4401431/disable-prompts-while-installing-a-debian-package
<cholcombe> coreycb, interesting.  thanks
<coreycb> cholcombe, good luck
<cholcombe> coreycb, ugh.  it's always something
<coreycb> yep
<mayurisapre> is there a way to access auth_url specified in environment.yaml file used for bootstrap, in charm hook?
<mayurisapre> hi all.. is there a way to access auth url specified in environment.yaml file from charm hook?
<marcoceppi> mayurisapre: no, the charms are disconnected from the environment they're deployed in
<mayurisapre> marcoceppi : okay..is there a way to inject these values in deployed charm?
<marcoceppi> mayurisapre: you can have them set via a configuration option on the charm
<marcoceppi> mayurisapre: may I ask what you're charming up?
<mayurisapre> i am deploying in openstack env
<mayurisapre> and need these values for further operations in charm hooks
<mayurisapre> what is the configuration option you just suggested?
<mayurisapre> marcoceppi : ohh sorry .. are you talking about config.yaml file  provided in charm?
<marcoceppi> mayurisapre: yes
<mayurisapre> yes.. i thought of that option but if I could get auth_url that is more suitable in my case
<bdx> cholcome: https://github.com/jamesbeedy/charm-vault/blob/master/reactive/vault.py#L56
<bdx> cholcombe: ^ thats all it took
<cholcombe> bdx, correct
<bdx> pumped
<marcoceppi> bdx: I don't have context, but could you use `@when('leadership.is_leader')`
<marcoceppi> instead of an if block
<marcoceppi> also, love seeing progress on the vault charm
<marcoceppi> it's something I've heard a few people ask for already
<bdx> marcoceppi: thanks for pointing that out, -1 me for not seeing that state decorating the function directly above ;/
#juju 2016-08-18
<aisrael> Any recent packaging change with Juju 2 in xenial? I just updated to beta 15 and now the (symlink?) from /usr/bin/juju to /usr/bin/juju-2.0 is gone
<marcoceppi> aisrael: yeah, that's been gone for a while
<marcoceppi> aisrael: you can do the following to add it back
<marcoceppi> aisrael: it's actually juju1 that breaks it up
<marcoceppi> sudo update-alternatives --install /usr/bin/juju juju /usr/bin/juju-2.0 30
<marcoceppi> then sudo update-alternatives --config juju
<marcoceppi> aisrael: ^^
<aisrael> marcoceppi: Huh. I remember when juju-1 was changed. I thought I'd installed this vm after that, though
<marcoceppi> aisrael: 1.25.6 was released
<marcoceppi> which reset that, probably
<aisrael> Aha, that'd be the culprit!
<aisrael> marcoceppi: when you have a chance, could you kill any instances owned by aisrael? Seems I've hit my quota
<marcoceppi> aisrael: ehhhhh, it's not easy to find instances by you
<marcoceppi> aisrael: what region
<aisrael> oh. us-east-1. That's the issue, isn't it?
<marcoceppi> aisrael: not nessisarily
 * marcoceppi helps
<marcoceppi> aisrael: seems there's a 20 instance cap on us-east-1
<marcoceppi> which is not right
 * marcoceppi contacts amazon _again_
<aisrael> marcoceppi: Weird. us-west-2 is working, fwiw
<marcoceppi> yeah
 * marcoceppi frees up more resources
<marcoceppi> I may have to start actualy reaping
<marcoceppi> lots of activity, which is awesome
<aisrael> Yeah, that's a good problem to have
<marcoceppi> us-east-1 might be boned, everything there is legit, us-west-2 seems to have way more capacitt, despite having a butt load of instances running
<aisrael> is it a hard resource cap set by amazon?
<marcoceppi> yeah, it's typicall 20 instances per region
<marcoceppi> I've contacted them like 12 times about increasing
<marcoceppi> us-west-2 got an increase
<marcoceppi> but none else did for whatever reason
<aisrael> This is working well enough for my mini charm school, so I'm off for the night. Have a good one!
<thumper> marcoceppi: still hanging around?
<thumper> or lazyPower
<marcoceppi> thumper: I am
<thumper> sweet
<thumper> for the python library that (most) charms use
<thumper> when you call hook tools
<thumper> are you explicit about format?
<thumper> and if so, which?
<marcoceppi> yes, json
<thumper> awesome
<thumper> I'm just about to land a change that changes the default from smart to yaml, and remove smart
<thumper> which will make zero difference if you say "json"
<thumper> existing behaviour will be kept if you use the feature flag "smart-formatters"
<thumper> but I'm thinking most charms use the charm tools code
<marcoceppi> thumper: http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/core/hookenv.py#L330
<marcoceppi> thumper: odds are there will be like 2 charms this affect
<marcoceppi> thumper: and those charms have bigger problems
<thumper> :)
<kjackal> Hello Juju World!
<jcastro> magicaltrout: around today?
<Anita_> Hi Matt
<mbruzek> Hello
<Anita_> This is regarding IBM-WXS design doc
<Anita_> Did you get a chance to go through the mail?
<mbruzek> Not yet this morning I just got in.
<mbruzek> Let me read it
<Anita_> Ok
<mbruzek> Anita_: OK I am up to speed.
<mbruzek> Anita_: What is your question?
<Anita_> The third charm of ibm-wxs i.e ibm-wxs-client can be deployed in two topologies
<Anita_> one is standard and another is mixed. In case of standard topology, ibm-wxs-client is a standalone/normal charm. in case of mixed topology, ibm-wxs-client is subordinate charm
<Anita_> in the metadata. yaml, subordinate charm will be having either true or false.
<Anita_> So thought of splitting ibm-wxs-charm as two charm. for standard : ibm-wxs-client ( not a subordinate one) and for Mixed topology charm ibm-wxs-was-client
<Anita_> ibm-wxs-was-client is a subordinate charm.
<Anita_> Is this approach correct?
<mbruzek> Anita_: You would have to name the subordinate charm something different than the "regular" charm. At that point you will have a different layer for the two, but what you are telling me is the IBM WXS application software would be the same between those two charms?
<Anita_> In both topologies, wxs client charm function is same. In case of standard, wxs-client can be used through command-line. Where as in case of Mixed, users are allowed to use Websphere Console UI to use wxs-client
<Anita_> IBM WXS Software packages are different for different topologies
<mbruzek> Anita_: What is the reason that the charm needs to be a subordinate in the first place? does the WXS software need to run on the WAS server? Or are there simply configuration differences between the two scenarios?
<mbruzek> Anita_: OK I see you answered my quest in the previous statement
<Anita_> In case of sub-ordinate charm, WAS ND will deployed. The installation path will be exposed by WAS ND. Under the same installation path, WXS Client needs to be installed
<mbruzek> Anita_: The approach you have outlined seems OK then. It seems like more work for you (the author) to have 2 charms and potentially more confusing for the user to know which ibm-wxs charm they want to deploy and how to correctly relate them in the situation they want.
<mbruzek> Anita_: The README for each charm would have to describe the situation where this charm would be used, and how it is different than the closely related one.
<Anita_> is there any other method to specify in the metadata.yaml to have both subordinate and non-subordinate charm, depending on user's topology option?
<mbruzek> Anita_: No not that I know of.  I brainstormed about this a little bit after reading your email. I came up with 2 possible options.
<Anita_> can you please let us know?
<mbruzek> Option 1) You make the charm a subordinate only, and relate it to ibm-was-nd (code would have to detect if nd was installed and install appropriately), and in the case where it is client only relate the subordinate to a ubuntu charm, which is the most simple non-subordinate charm.
<mbruzek> Option 2) Re-evaluate the requirement of subordinate. Make the ibm-wxs-client a non-subordinate and see if you can pass all the software/information over relations, so the ibm-wxs-client -> ibm-was-nd does everything it needs to the ibm-was-nd charm, with the absence of the relation it simply sets up as a stand alone line.
<mbruzek> Anita_: However if the path is clearer to make a subordinate and non-subordinate charm that is also a valid option. But the README on both charms would have to be very clear about what situation to use the different charms.
<Anita_> In case of both options, user's options are to be taken?
<mbruzek> Anita_: I don't understand the question. Can you rephrase?
<Anita_> Option 1) I understood, But Option 2) I could not get. In case of Option 2) - If its a non-subordinate charm and user selects "Standard Topology", it will be normal charm. But if user selects Mixed Topology, ibm-was-nd will pass the informations to ibm-wxs-client and then ibm-wxs-client will proceed?
<Anita_> But in case of Mixed topology, ibm-wxs-client needs was-nd to be installed on the same machine.
<mbruzek> Anita_: Right. In the case of Option 2) the ibm-wxs-client would not be a subordinate and you transfer the software to the ibm-was-nd server. It *can* be done but may be very complicated
<Anita_> Hmm Option 1 will be a better Option.
<Anita_> In case of Option 1 I have a query.
<Anita_> Option 1- subordinate charm. If user selects standard topology, then user will be having a simple ubuntu charm and add-relation with ibm-wxs-charm. If user selects Mixed Topology, user has to deploy ibm-was-nd-dm charm and ibm-wxs-client charm and have to do add-relation between ibm-was-nd-dm and ibm-wxs-client. Am I correct?
<mbruzek> Anita_: Yes that is correct. The code would have to detect if was-nd was installed on the host system, and that code should not be too hard.
<Anita_> Ok. Actually currently I have implemented partially ibm-wxs-client on WAS-ND. after add-relation between ibm-wxs-client and was-nd-dm, was-nd-dm is exposing the installation path, user name, password and profileName. Those informations are being used by ibm-wxs-client to install WXS Client.
<Anita_> Is this approach correct?
<Anita_> ibm-wxs-client needs to be installed under the same installation path of was-nd-dm. installation path, user name, password and profileName are configurable for was-nd-dm charm
<mbruzek> Anita_: That looks correct. For the connection to ibm-was-nd-dm you should create a relation that exchanges that information.
<Anita_> While relation will be departed, wxs needs to be uninstalled from was-nd-dm. But once relation departed, wxs client will not have those above informations. So is it better to store those informations in a file and use those for uninstallation?
<Anita_> Actually Installation path and profile name can be extracted from was utility files. But admin and password needs to stop the running process and uninstall wxs client
<mbruzek> Anita_: Breaking a relation has two parts. *-relation-departed and *-relation-broken you should be able to get the values from the relation in the first one *-relation-departed, if not the ibm-wxs-client should know the value from the last *-relation-changed event and can store that in a key value store that is provided
<Anita_> mbruzek_:Ok
<Anita_> mbruzek_:The latest design doc sent was having changes of split charms for wxs client. Will revert to the earlier design.
<mbruzek> Anita_: OK good luck and if you encounter implementation problems let me know.
<Anita_> mbuzek_:Thanks a Lot for clarifying all the doubts and for your time.
<mbruzek> you are welcome, have a good night.
<Anita_> mbruzek_: Will let you know if i will have any problem while implementing.
<Anita_> mbuzek_:Thanks
<bleepbloop> Any ideas why trying to import a file that was exported from juju would throw a `unmarshal errors: line 1: cannot unmarshal !!str `xenial` into charm.legacyBundleData`
<beisner> marcoceppi, <3 the requirements of requirements dance:  https://github.com/juju/charm-tools/issues/246    thoughts?
<mayurisapre> hi all.. i can have subordinate charm with global scope right?
<marcoceppi> beisner: wtf
<marcoceppi> mayurisapre: it will need a scope: container to define where it deploys to, but scope: global is implicit for all othe rrelations
<mayurisapre> so what i want is .. subordinate charm should access to some processes in principle charm.. at the same time i dont want my subordinate charm to be deployed on each unit of principle charm..
<mayurisapre> what is the way to achieve this?
<marcoceppi> mayurisapre: you can't have both, if you need access to a process on the running machine, but don't want the charm on that machine there's no way to rectify those two properties
<marcoceppi> mayurisapre: could you elaborate your usecase more?
<bwallis> sorry I couldn't find documentation on this anywhere, but is there any way to place the juju controller inside the default model?
<bwallis> it used to happen by default in older releases
<marcoceppi> bwallis: any reason why you'd want to?
<marcoceppi> bwallis: well, the controller was the only model
<bwallis> yea, it burns a machine
<bwallis> i don't have any low powered compute, and don't want to run it virtual
<marcoceppi> bwallis: if you want to put stuff with the controller, you can `juju switch admin`
<bwallis> i tried that, but it seems the juju-gui doesn't place nicely
<bwallis> play*
<marcoceppi> since admin is the model where the controller lives
<marcoceppi> bwallis: juju-gui comes out of the box now
<bwallis> with the controller model
<marcoceppi> bwallis: `juju gui`
<bwallis> let me try bootstrap again
<marcoceppi> (everyone kept deploying --to 0, so we decided to do it for you)
<bwallis> yea :)
<bwallis> that part is OK, it just doesn't seem to work well with the controller model
<bwallis> or maybe my juju gui was just broken
<bwallis> i'm bootstrapping right now, so will try again
<marcoceppi> bwallis: well the juju-gui charm is no longer needed for 2.0
<marcoceppi> which is why it was probably breaking
<bwallis> so, don't deploy it then? because yea i did last time
<bwallis> i can see in the logs it is installing, almost finished
<bwallis> so i'll give it a whirl
<marcoceppi> bwallis: just type `juju gui --show-credentials`
<bwallis> yea, when i connected to the GUI last time, no models were available at all
<bwallis> the usual model drop down was missing
<bwallis> i don't actually use the GUI for anything anyway, but want to show it off during a demo
<bwallis> so it's not a massive problem for me
<marcoceppi> bwallis: yeah, there was sometime around beta12-14 that the gui broke becaues of API changes
<bwallis> yea, I think it was beta13 I was on
<marcoceppi> bwallis: those should all be fixed now so long as you're on beta15
<bwallis> so bootstrap is finished, it says it installed the GUI, but I can't see any processes using tcp 80 or 443
<bwallis> on the controller
<bwallis> this is was maas rc4 and juju beta15
<bwallis> with*
<marcoceppi> bwallis: just type `juju gui --show-credentials`
<marcoceppi> gui runs on a different port
<marcoceppi> it's built onto the API server
<bwallis> oooooh
<bwallis> you're absolutely right, port 17070
<bwallis> let me try
<bwallis> @marcoceppi: works! thanks!
<marcoceppi> bwallis: cheers!
<cholcombe> coreycb, so i ran debconf-get-selections on openattic.  I see a bunch of stuff in there. Do all debconf questions have default answers?
<coreycb> cholcombe, I'm not really sure
<cholcombe> ok
<coreycb> cholcombe, if not then the charm would have to configure things I suppose
<coreycb> cholcombe, where's the package located?
<cholcombe> coreycb, http://download.openattic.org/
<cholcombe> better yet: http://apt.openattic.org/pool/main/o/openattic/
<coreycb> cholcombe, the debian source is at: https://bitbucket.org/openattic/openattic/src/d9caeb7619363c9126a77a2f4e206ad33d351014/debian/?at=development
<coreycb> cholcombe, you could grep through that and find the debconf questions
<cholcombe> coreycb, :)
<coreycb> maybe there's defaults
<magicaltrout> jcastro: you rang?
<magicaltrout> i am around jcastro i just can't read the screen :)
#juju 2016-08-19
<kjackal> Hello Juju World!
<rick_h_> kjackal: howdy
<kjackal> hi rick_h_!
<lazyPower> o/ juju add-unit hello-world
<lazyPower> magicaltrout i am excite! We have a meeting in ~ 30 minutes, and there's a new com truise album! I dont know what i did to deserve today, but it must have been something right
<rick_h_> lazyPower: lol, my brain turned that into "a new tom cruise album"
<lazyPower> rick_h_ - i do the same thing sometimes ;)   California based electronic artist != eccentric billionare movie star
<balloons> is there anyone running xenial who can verify a bug for me?
<lazyPower> balloons - i've got several xenial containers/vm's. Whats up?
<balloons> lazyPower, I'm trying to figure out bug 1614959. You need a xenial with juju-1-default installed and to have not upgraded to 1.25.6 yet
<mup> Bug #1614959: /usr/bin/juju is missing after upgrade to 1.25.6 <juju-release-tools:New> <juju-core-1 (Ubuntu):New> <https://launchpad.net/bugs/1614959>
<lazyPower> weird, let me try to repro -- i'm headed into a meeting shoirtly but will ping back with results if i can repro
<lazyPower> that awkward moment when you realize a system restore nuked your VM's because you omitted them from the backups...
<magicaltrout> rick_h_: my double vision also turned that into Tom  Cruise
<lazyPower> https://www.youtube.com/watch?v=jTgttHHjGRI
<lazyPower> maybe that will help
<balloons> lazyPower, I'd like the output of all those commands in the bug before and after the upgrade. ls -al /usr/bin/juju* and dpkg-divert --list | grep juju
<lazyPower> balloons - ack, will do. just wrapped up creating a new vm
<lazyPower> magicaltrout - jwaiting on you sir https://hangouts.google.com/hangouts/_/canonical.com/troutpocalypse?authuser=0
<magicaltrout> my hangout says its requesting a join
 * magicaltrout tries again
<magicaltrout> oh i was joining as meteorite.bi
 * magicaltrout swaps
<lazyPower> that awkward moment when you realize you have the hangout locked up from the casuals
<magicaltrout> lazyPower: Amazon Music just said
<magicaltrout> "We ran the numbers and we think you'll like this station"
 * lazyPower smirks
<magicaltrout> It was Little Mix....
<magicaltrout> :'(
<lazyPower> little mix?
<lazyPower> i'm not familiar
<magicaltrout> girl band
<magicaltrout> their learning algo sucks
<lazyPower> heh, do you have family members using your prime acct?
<lazyPower> that's a sure fire way to mux up their learning algs
<magicaltrout> aye. No one else uses it, the only stuff in it is Weather Report, Blue Brothers, and a few punk albums
<magicaltrout> not sure what planet they're on
<jrwren> "we ran the numbers and the record label paid us to promote this factory band"
<lazyPower> ^
<lazyPower> i think thats more than likely the culprit
<magicaltrout> hehe
<magicaltrout> maybe they mistyped s/the/our
<magicaltrout> oooh its so nice to nearly be able to read a screen today
<magicaltrout> that said I have a 4k screen with gnome-terminal on full zoom
<lazyPower> magicaltrout - they say trouts are wall-eyed
<lazyPower> do you feel like you're looking through a fish-eye lense?
<magicaltrout> hehe it does at times
<magicaltrout> its weird today
<magicaltrout> sometimes i can see with perfect clairty for a split second
<magicaltrout> then it switches to fuzzy
<magicaltrout> but keeps repeating for a few minutes
<magicaltrout> like my eyes remember how to focus and then forget
<jrwren> magicaltrout: are you ok? detached cornea?
<magicaltrout> na jrwren lasek
<lazyPower> i'm living vicariously through magicaltrout's surgery. i've considered it myself bu ti'm hyper scared to have someone lazering on my eyeballs
<magicaltrout> hehe
<magicaltrout> i can read a license plate from 36 meters today when i tested it
<magicaltrout> which is pretty cool
<magicaltrout> its just the close up stuff that i'm having issues with
<magicaltrout> but thats normal
<magicaltrout> for 7 - 14 days
<lazyPower> so if i do it, it'll be over xmas shutdown
<magicaltrout> depends what you have done as well lazyPower
<lazyPower> i cant afford the time away from reading a monitor :( too much to do, too little time
<magicaltrout> lasek or lasik
<magicaltrout> lasik is more standard and much quicker recovery
<magicaltrout> but my cornea was too thin
<lazyPower> i have astigmatism so i'm likely to have the extra expensive and tricky lazering
<magicaltrout> yeah i had an astigatism as well
<magicaltrout> it wasn't cheap, but i don't like my lenses and glasses get on my nerves
<lazyPower> agreed
<lazyPower> they fog up in winter, and slide off your nugget in summer
<magicaltrout> yup
<lazyPower> the only perk is transitions
<lazyPower> i always have sunglasses on hand
<jrwren> i've only had glasses for a month. :p
<lazyPower> i've been wearing glasses since i was 12 :/
<magicaltrout> except i now have hipster sunglasses without the problems of a prescription ;)
<lazyPower> i'm over it
<magicaltrout> yeah i had them around 12
<magicaltrout> i like lenses because of the all round vision
<magicaltrout> but they just wear your eyes out
<lazyPower> yeah
<lazyPower> eyestrain is a real thing
<lazyPower> I tend to work until my eyes hurt and thats when i know its time to EOD
<lazyPower> not the best policy by any means
<magicaltrout> hmm
<magicaltrout> i don't get eyestrain
<magicaltrout> maybe thats why i just keep going
<jrwren> I never felt eyestrain, but maybe its because I've trained my eyes since I was 6yo :p
<jrwren> And now with fancy pants lenses doing that whole polarization filtering thing... even less eyestrain, not that I ever noticed.
<magicaltrout> well assuming my near sighted vision clears up i'm well happy with this investment
<magicaltrout> even if i need glasses for some near sighted stuff which isn't the plan, i'd still consider it money well spent
<lazyPower> fair enough :)
<magicaltrout> funnily when i had my checkup the other day i couldn't see anything out of my right eye
<magicaltrout> today its much clearer than the left eye
<magicaltrout> they need to hurry up and align so I can write talk content ;)
<lazyPower> your cones and rods are working against you
<balloons> lazyPower, did you try replicating the bug?
<lazyPower> balloons - i have the vm stood up, was just about ot circle back and run through the log
<lazyPower> balloons - give me 15 minutes and i'll context switch to this until i have your log output
<balloons> lazyPower, thank you. The key is to ensure juju-1-default is diverting /usr/bin/juju to juju-1 before and after the upgrade
<jcastro> rick_h_: so far for the summit I only have your talk and dimiter's on networking for core-ish talks.
<jcastro> rick_h_space is filling up so if you want more core-ish talks please lmk asap
<kjackal> kwmonroe: petevg: I have a question regarding the Barcelona style issue that we have,  what zookeeper charm should we use for promulgated bundles?
<lazyPower> balloons - to be very specific, if i install juju-1.25=1.25.5-0ubuntu3  and then upgrade
<petevg> kjackal: I think that we should use the trusty version.
<lazyPower> thats the path we are looking to have tested?
<kjackal> petevg: the one we have from james, right?
<petevg> kjackal: correct. The one that's already in the store.
<petevg> The xenial one isn't promulgated yet.
<petevg> And when we do promulgate it, we'll probably do so without the need for the openjdk relation.
<petevg> cory_fu: does the above sound correct?
<kwmonroe> petevg: the xenial is promulgated
<kwmonroe> https://jujucharms.com/zookeeper/ (xenial only)
<balloons> lazyPower, yes. And make sure juju-1-default is installed
<petevg> kwmonroe: cool! In that case, kjackal: I think that you should still use the trusty one, if the rest of your bundle is trusty stuff. Though if you want to wait for the xenial one to get re-deployed without the need for the openjdk relation, then you could use the xenial one.
<balloons> lazyPower, and record the values before and after so we can vet it looks good before (and works), and doesn't afterwards
<kwmonroe> petevg: kjackal, the trusty version (james') has to be explicitly namespaced (cs:~charmers/zookeeper/trusty): https://jujucharms.com/u/charmers/zookeeper/trusty
<petevg> kwmonroe: Did we deploy a trusty version of the new zookeeper charm, then?
<shilpa> Hi, can we have a package name without any extension say .zip or tar.gz in resources ?
<lazyPower> balloons http://paste.ubuntu.com/23070607/
<kwmonroe> no petevg.. bigtop zk for trusty is not promulgated.  that version is only available in bd-dev: https://jujucharms.com/u/bigdata-dev/zookeeper/trusty
<kjackal> kwmonroe: have we promulgated the bt spark? (You are our official release manager!)
<kwmonroe> negative kjackal, latest spark with your most recent "Spark tests need to pass" fixes is https://jujucharms.com/u/bigdata-dev/spark/trusty/9
<kwmonroe> kjackal: i was going to promulgate after checking out your "spark houskeeping" review
<kjackal> Cool, thank you
<lazyPower> balloons - all that looks sane to me
<lazyPower> i've nuked and repeated twice now... unable to reproduce
<kjackal> petevg: I got multiple agents in failed state when deploying the hadoop bundle, digging into this
<petevg> kjackal: cool. thx for investigating.
<balloons> lazyPower, that makes me very happy to hear.. Although I'm still not sure why others are seeing it
<balloons> lazyPower, thank you
 * lazyPower nods
<lazyPower> happy to help, sorry it took so long
<lazyPower> who knew friday would be busy when you come back from time off ;)
<kwmonroe> shilpa: i just checked out the latest resources docs (https://jujucharms.com/docs/2.0/developer-resources), and it seems like there is some logic to check the extension.. so i'm not sure if you can omit one.  the test would be to specify a non-extension filename in metadata.yaml and see if juju allows you to subsequently attach a non-extention file to that charm.
<kwmonroe> shilpa: here's the sentence that makes me think there's some extension logic happening:  "The filename is what Juju will name the file locally when it is downloaded. Juju will check the extension on the file being uploaded and will prevent files with different extensions from being uploaded."
<kwmonroe> shilpa: based on this bug, it seems you should be able to define a filename with no extension in metadata.yaml and attach a resource with no extension:  https://bugs.launchpad.net/juju-core/+bug/1578383
<mup> Bug #1578383: incorrect extension on resource upload <resources> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1578383>
<kjackal> petevg: this is in the ganglia nodes but it seems unrelated... http://pastebin.ubuntu.com/23070770/
<petevg> kjackal: interesting. I think that I may have seen something similar. Will dig around in the logs in a bit (right now, my local juju is busy bootstrapping a new aws controller).
<shilpa> thanks kevin, sometime back i had tried without specifying extension in metadata file, when i did juju attach, it was throwing some error.
<shilpa> i will try once again without extension in metadata and do juju attach.
<petevg> kjackal: hmmm. I don't seem to have that particular error in my current ganglia node. You're right that it's probably not related, though.
<kjackal> petevg: going to queue the tests on a different machine
<rick_h_> jcastro: k, tganks fornthe heads up. have we reached out to bac about something around the charmstore/gui?
<jcastro> are you asking me or telling me?
<rick_h_> jcastro: and any suggestions on core thing that would go over well for the audience? /me isn't sure who' coming to this one
<rick_h_> jcastro: asking
<rick_h_> jcastro: and slightly suggesting if the answer is no
<cholcombe> how do you specify local charms in a juju2 bundle?
<cholcombe> it seems to have changed
<cholcombe> nvm, giving it the full path works
<jrwren> cholcombe: I think relative path works too, it just needs to start with ./
<cholcombe> does charm push take into account layer+reactive charms?  I'm guessing I push the built bits correct?
<jrwren> cholcombe: charm push knows nothing about layer or reactive. push the built bits.
<cholcombe> jrwren, ok cool that's what i thought
<bdx> marcoceppi: what is secretstorage ?
<petevg> kwmonroe: are you able to get bundletester to work at all with juju beta 15? I fail on a KeyError in jujuclient (it looks like its due to some consistencies in how "juju show-model" and "juju switch" name the models).
<marcoceppi> bdx: it's like a dependency or a dependency of a dep that got bumped and broke a bunch of stuff
<marcoceppi> bdx: beisner has the details
<ahasenack> hi, do you guys know what's up with juju(2) storage?
<ahasenack> I can't get a pool list
<ahasenack> $ juju-2.0 storage pool list --filesystem
<ahasenack> "machine-pool" is not a valid machine tag
<ahasenack> "machine-list" is not a valid machine tag
<ahasenack> juju-2.0 help storage also doesn't match, at all, what's described in https://jujucharms.com/docs/2.0/charms-storage
<rick_h_> ahasenack: yes, there's a bug open on the docs to get it caught up to the 2.0 cli updates
<ahasenack> rick_h_: according to help, there isn't any subcommand for storage anymore, is that right?
<rick_h_> juju help commands | grep pool
<ahasenack> ah
<rick_h_> ahasenack: yes, like everything else in 2.0 there's a pool "noun" and verbs to list, etc
<ahasenack> list-storage-pools lists the types, not the pools I created
<ahasenack> I guess that's when "juju-2.0 storage" comes in
<rick_h_> ahasenack: hmm, there's show-storage for a specific one, is storage the list-storage equiv that shows the created ones?
 * rick_h_ needs to play with that more
<ahasenack> I grepped for pool :)
<rick_h_> heh
 * ahasenack refines the grep
<ahasenack> ok, I see
<ahasenack> lots of aliases
<ahasenack> since we are still in beta, these aliases could be dropped
<rick_h_> ahasenack: yes, definitely
<rick_h_> ahasenack: another bug that's filed to clean those up somewhere.
<ahasenack> I think pool, count and size are in the wrong order
<ahasenack> The acceptable format for storage constraints is a comma separated
<ahasenack> sequence of: POOL, COUNT, and SIZE, where
<ahasenack> ...
<ahasenack>       juju add-storage u/0 data=ebs,1024,3
<rick_h_> ahasenack: heh yes, agree
<wolsen> lazyPower: for the kubernetes bundle on openstack, looks like they need to be able to add an external keyserver... so if there is firewalled access I'll have to clear the firewalls right
<lazyPower> wolsen - there's quite a few external dependencies there
<lazyPower> external key server, external image registry, and github access required to clone easy_rsa
<wolsen> lazyPower: ack thx, let me just enable the squid proxy in general
<petevg> hiya, bradm: are you still maintaining the bip charm? There are a couple of open PRs against it (start at https://code.launchpad.net/~josvaz/charms/trusty/bip/client_side_ssl-with_helper-lp1604894/+merge/301802) that need some love from the maintainer (and possibly a redirection to your branch).
<cloudguru> Have a strange error.  We are building new layer-docker charms that passed proof and build back in March .  The exact same code now produces the following error when running 'charm build ./hss' :
<cloudguru> Traceback (most recent call last):
<cloudguru>   File "/usr/bin/charm-build", line 9, in <module>
<cloudguru>     load_entry_point('charm-tools==2.1.2', 'console_scripts', 'charm-build')()
<cloudguru>   File "/usr/lib/python2.7/dist-packages/charmtools/build/__init__.py", line 673, in main
<cloudguru>     build()
<cloudguru>   File "/usr/lib/python2.7/dist-packages/charmtools/build/__init__.py", line 516, in __call__
<cloudguru>     self.generate()
<cloudguru>   File "/usr/lib/python2.7/dist-packages/charmtools/build/__init__.py", line 467, in generate
<cloudguru>     self.formulate_plan(layers)
<cloudguru>   File "/usr/lib/python2.7/dist-packages/charmtools/build/__init__.py", line 408, in formulate_plan
<cloudguru>     self.plan = self.plan_layers(layers, output_files)
<cloudguru>   File "/usr/lib/python2.7/dist-packages/charmtools/build/__init__.py", line 319, in plan_layers
<cloudguru>     next_layer / BuildConfig.DEFAULT_FILE, True)
<cloudguru>   File "/usr/lib/python2.7/dist-packages/charmtools/build/config.py", line 81, in add_config
<cloudguru>     c.configure(config_file, allow_missing)
<cloudguru>   File "/usr/lib/python2.7/dist-packages/charmtools/build/config.py", line 69, in configure
<cloudguru>     tactic = load_tactic(name, basedir)
<cloudguru>   File "/usr/lib/python2.7/dist-packages/charmtools/build/tactics.py", line 661, in load_tactic
<cloudguru>     obj = utils.load_class(dpath, basedir)
<cloudguru>   File "/usr/lib/python2.7/dist-packages/charmtools/utils.py", line 321, in load_class
<cloudguru>     dpath, workingdir))
<cloudguru> OSError: Unable to load tactics.docker.DockerWheelhouseTactic from /home/juju/charms/deps/layer/layer-basic
<cloudguru> Any advice is appreciated
<marcoceppi> cloudguru: have you updated the layers recently?
<cloudguru> i've done apt update .. how do you update layer-docker layers ?
<cloudguru> It looks like the charm pulls in the latest layer-docker .. I also tried to pull in from git but had the same result
<cloudguru> could this be a simple permissions issue ?
#juju 2016-08-21
<magicaltrout> how dare lazypower not be working on a weekend
<marcoceppi> magicaltrout: I know, right?
<magicaltrout> disgrace marcoceppi
<magicaltrout> absolute disgrace
<bradm> petevg: I know technically I was the maintainer, but I'm not in ~charmers so I doubt I can even write to the main branch
<petevg> bradm Got it. I'm not in charmers, either.
<petevg> I think that we're supposed to be moving stuff out of charmers, anyway, though.
<petevg> I'll bug people about it tomorrow -- I'm still kind of fuzzy on what is supposed to happen with some of these charms that still have their main branch in charmers.
#juju 2017-08-14
<natefinch> anyone here have suggestions on the best way to use juju on a mac?  I miss lxd on ubuntu.  Is there anything similar on mac?  Will lxd work in an ubuntu vm on mac?
<natefinch> marcoceppi rick_h ^
<rick_h> natefinch: so if juju is on the VM then yes. I think that's how most folks use juju on a mac
<rick_h> natefinch: personally, I use maas/jaas on a mac and don't lxd much on there
<rick_h> natefinch: let me know if you hit any issues with the client on the mac. I try to do most of my juju-ing from my mac to test it out and keep the brew packages up to date
<primeribz> natefinch: I as well curently have a setup running ubunutu in a vm with juju installed thhere.
<rick_h> natefinch: another thing to test out is something that hit the email list on friday https://launchpad.net/multipass
<rick_h> natefinch: I've not tried it out yet, but might be a nicer way to get the VM going to use juju/lxd on there. Not sure
<natefinch> rick_h: that link 404's
<rick_h> natefinch: oh sorry, it's internal testing I guess my bad
<natefinch> heh :) . s'ok
<rahworkx> natefinch: have a look at this. https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to-virtualbox-vms-on-os-x-a06a8046756a
<natefinch> rahworkx: that sounds awesome
<rahworkx> natefinch: thanks to bdx :)
<natefinch> gah, the default lxd init parameters don't work with juju :/
<natefinch> lxd-bridge has IPv6 enabled. Juju doesn't support IPv6
<natefinch> at least it gives me instructions on how to fix lxd.  But geez.  Also, that lxd init wizard is insanely long.
<zeestrat> rahworkx: Regarding the reusing username issue, there's an old issue on it. Feel free to add some fire to it :) https://bugs.launchpad.net/juju/+bug/1668335
<mup> Bug #1668335: `delete-user` doesn't fully delete user <juju:Triaged> <https://launchpad.net/bugs/1668335>
<rahworkx> zeestrat: ok will do.
<hallyn> stupid question.  i did a conjure-up to try kubernetes-core onto localhost.  i ctrl-c'd it when it was mostly installed.  now i see stuff is still running, but juju status no longer shows anything other than
<hallyn> conjure-kubernetes-core-59c  conjure-up-localhost-267  localhost/localhost  2.2.1    unsupported
<hallyn> how do i 'reconnect' to that?
<rick_h> hallyn: juju status shows that? what does `juju controllers` show?
<rick_h> hallyn: I'd expect you to be able to `juju switch conjure-kubernetes-core-59c && juju models` and see a model listed there. From there you can destroy the controller and such if you wanted to cleanup.
<hallyn> rick_h: indeed i see models there,
<hallyn> i don't want to destroy it, i want to investigate :)
<hallyn> thanks rick_h
<rick_h> hallyn: and so you can juju switch into those models, run juju status, etc
<hallyn> now to remember how to connect to its apparently private lxd socket
<rick_h> hallyn: hmm, lxc list and such should show the containers. I'm not sure about the private socket
<hallyn> hm lxc list shows nothing and lsof -U shows a private socket...
<hallyn> but yay i can attach to the model, that's a start.  this controller/model thing is confusing to me stil :)
<hallyn> thanks
<hallyn> imma start over :)
<hallyn> my fault for exiting early
<rick_h> hallyn: sec, let me get you a walk through.
<rick_h> hallyn: https://youtu.be/FqPjO0NZ8z0?t=363 walks through it a bit from a talk I gave
<hallyn> rick_h: thanks i'll look at that too.  was looking at https://insights.ubuntu.com/2017/01/27/deploying-the-canonical-distribution-of-kubernetes-onto-aws/ and mainly https://kubernetes.io/docs/getting-started-guides/ubuntu/
<rick_h> hallyn: and I think there's a blog post and such somewhere. the docs have an intro as well here: https://jujucharms.com/docs/stable/controllers
<hallyn> bbl
<rick_h> let me know if there's confusion
<rick_h> hallyn: k, good luck!
<hallyn> rick_h: will do thanks!
#juju 2017-08-15
<stub> tinwood: https://code.launchpad.net/~stub/charm-helpers/fix-gpg/+merge/329024 , since I think you touched it last and likely care most.
<tinwood> thanks stub, I'll take a look.
<stormmore> hello juju world o/ miss me yet?
 * rick_h checks who let stormmore back in here :P
<stormmore> rick_h: :P
<rahworkx> buffer /3
<TikTok> how can I use local images when doing juju bootstrap vsphere/myregions --bootstrap-constraints "cores=2 mem=4G root-disk=32G"  rather than the downloading of the ova? Same thing for the images used in bundles ..
#juju 2017-08-16
<Zic> hi here, all my kubernetes-worker are showed as "failed" in juju status since this morning, but everything is fine in practice... I ran a "juju debug-log" and saw a lot of "too many open files" of this kind : http://paste.ubuntu.com/25324995/
<Zic> so I tried to modify the file.fs-max sysctl value & limits.conf, but nothing change
<Zic> do you have clues ? :(
<Ting_> hi there, I am deploying a application (postgresql in this case) on maas, it gets stuck at waiting for machine. Tried with print out log with "juju debug-log", but got no respond from that, anyone have idea about why juju debug-log doesn't work? How could this be fixed?
<rick_h> Ting_: hmm, try the deploy with --debug in the command "juju deploy postgresql --debug" and see if that has some info
<Ting_> yes, i deployed it with --debug, it showed some info and said command finished at the end.
<rick_h> Ting_: ok, is there a machine in juju status with a number?
<rick_h> Ting_: if so, try to do "juju show machine X" and see if there's any output about why it couldn't get the machine
<Ting_> ok, i'll try it
<Ting_> it shows some infor like juju-status: pending, machine-status:allocating
<Ting_> rick_h: from maas gui, i can see the machine is deploying which takes very long time than expected.
<rick_h> Ting_: ah ok. Assumed there was an error. Go Maas go!
<Ting_> rick_h: sure, thanks!
<stormmore> o/ juju world
<rick_h> reminder juju show in 30 woot woot
<rick_h> awesome 2.3 early feature demo coming
<rick_h> well, future feature (probably not 2.3)
<rick_h> Juju Show linkages: https://hangouts.google.com/hangouts/_/n4gmxnhlgrhkpibqzdn3gf7c2qe for joining in the conversation (tvansteenburgh, hml, kwmonroe, arosales, bdx, and anyone else)
<rick_h> and for watching check out https://www.youtube.com/watch?v=NUx6kYE60Mc
<arosales> rick_h: thanks, I'll be in read only mode today
<tvansteenburgh> i'm on TV!
<tvansteenburgh> i'm famous!
<tvansteenburgh> https://lists.ubuntu.com/archives/juju/2017-August/009294.html
<sfeole> i'm putting together some updates to a charm I use.  I'm curious , I have a function that I only want to run once, however I need it to wait until a specific condition is met. so can I stack 2 decorators like this: @when('condition_met') \n @only_once  \n def do_this_action()
<blizzow1> So I have 3 decent servers that I used maas to wipe and put a default installation of ubuntu on them. I'd like to test openstack or kubernetes using these three servers and was contemplating using juju to do it. I keep running into issues with conjure-up. All the pages I see about deploying openstack or kubernetes suggest starting with maas+conjure-up+juju to get things up and running. Do I need conjure-up?
<stokachu> Depends, is the problem conjure-up or your maas setup
<blizzow1> stokachu: I don't think my maas is busted? but who knows.
<blizzow1> wtf, why do I need lxd and zfsutils to run juju?
<blizzow1> Why in the hell do I use snap? What happened to using apt??
<stokachu> Well that's where most applications are heading coming from us
<blizzow1> argh. yet another f'ing packaging/installation system.
<blizzow1> what was the matter with apt? who knoooows?
<stokachu> And I don't know what problems you are having as you haven't provided any additional information
<stokachu> There is also a #maas channel
<blizzow1> well, I'm over using conjure-up+snap to do stuff because it's always failing. So I'm trying to install juju on it's own VM and add the maas cloud. Then I'll get started on testing whatever I want...I see this page which seems to be how to install juju... https://jujucharms.com/docs/2.2/reference-install.  Where do I go from that page?
<stokachu> Fair enough
<stokachu> if you get bored and actually want to debug your maas+conjure-up then let me know
<blizzow1> I guess my question was whether or not I even need to use conjure-up got get juju running? I'd prefer not to use lxd containers in a VM to provision bare metal that can provision more VMs. can I run a juju controller without LXD and adding some bridging to a VM that's already bridging?
<stokachu> you dont need conjure-up to get juju running
<stokachu> if you have maas you can just use this https://jujucharms.com/docs/stable/clouds-maas
<stokachu> and juju deploy canonical-kubernetes
<blizzow1> stokachu: thanks.
<stokachu> blizzow1: you just want to make sure that maas is able to auto power on/off your nodes
<stokachu> without you having to do anything
<stokachu> blizzow1: also i usually create a VM on the maas server and register that as a node
<stokachu> and do juju bootstrap --to vmhost.maas
<stokachu> so you aren't using a whole machine for the bootstrap node
<blizzow1> stokachu: maas is able to power up and power off these servers at will. I'm trying not to use a whole server to run maas or juju. I'm trying to use these servers to run openstack or kubernetes as a proof of concept, so my maas and juju servers are VMs on separate hypervisors.
<blizzow1> So from my juju VM. I did an add-credential maas-cloud.  Then when I try an do a bootstrap, I get an error about failing because of constraints.
<blizzow1> ERROR failed to bootstrap model: cannot start bootstrap instance: cannot run instances: cannot run instance: No available machine matches constraints: [('agent_name', ['cf1fbc63-9ad1-4556-8159-43a2f4f7aa32']), ('mem', ['3584']), ('name', ['maas01.mydomain.com'])] (resolved to "mem=3584.0 name=maas01.mydomain.com")
<blizzow1> So if I already have a maas server running, how do I register that instead of bootstrapping another with juju?
<thumper> blizzow1: so using maas with juju?
<thumper> https://jujucharms.com/docs/2.2/clouds-maas
#juju 2017-08-17
<braziercustoms1> @thumper thanks for the link!
<CoderEurope> rick_h, hiyas. you there ?
<rick_h> CoderEurope: kinda sorta, after 9pm and such doing stuff. What's up?
<CoderEurope> last week rick_h I stated that this page wasn't reflecting marc's update. I am grumbling that I have been side-lined, again.
<CoderEurope> https://jujucharms.com/u/marcoceppi/discourse/
<rick_h> Ah, I reached out to him but didn't hear back. Sorry.
<CoderEurope> linux just works, hey ?
<rick_h> CoderEurope: I'm in and out atm, do me a favor and shoot me an email reminder and I'll push more. rick.harding@canonical.com
<CoderEurope> right-oh
<rick_h> ty
#juju 2017-08-20
<D4RKS1D3> Hi, why when I deploy new units take a lot of time? Why juju do not parallelize the actions?
<rick_h> D4RKS1D3: it should work async and work in parralel. How are you adding units?
<D4RKS1D3> juju add-unit mysql --to name
<D4RKS1D3> the vm in maas is in ready state
<D4RKS1D3> but take lot of time to change ready to deploying
<D4RKS1D3> you know something about this problem?
<D4RKS1D3> sometimes is around waiting 30 minutes between these to states rick_h
<rick_h> D4RKS1D3: what version of juju? Not seen anything about that recently no.
<D4RKS1D3> rick_h, juju-2.0                              1:2.2.2-0ubuntu1~16.04.1~juju1             amd64
<rick_h> D4RKS1D3: hmm, might check the Maas logs during the add-unit and if something isn't going there file a bug please.
<D4RKS1D3> let me check
<D4RKS1D3> thanks rick_h
<D4RKS1D3> rick_h, https://pasteboard.co/GGxwDrk.png take a look, this is what is hapenning if I deploy 10 new units
<D4RKS1D3> Only to machines start to run the petition, the other 8 still waiting
#juju 2018-08-13
<vinodhini> wallyworld: v2 also does the same identity/keystone.go @@L73
<vinodhini> its just like v3
<vinodhini> so we shd fix both
<wallyworld> yes we should
<thumper> babbageclunk: do you have some time this afternoon?
<babbageclunk> thumper: sure - what's up?
<thumper> babbageclunk: I want to discuss some future design stuff and need a sounding board
<babbageclunk> ok
<thumper> and it has cross-over concepts with recent work of yours
<babbageclunk> cool - when do you want to talk?
<thumper> after I have made coffee
<thumper> as long as you are able
<thumper> how about at 2?
<babbageclunk> yeah, sounds good
<thumper> wallyworld: /home/tim/go/bin/dep ensure -vendor-only taking way more than 10s
<wallyworld> kelvinliu_ promised me it was fast :-)
<wallyworld> he ran a test
<wallyworld> took that long for him
<kelvinliu_> wallyworld, 0.0
<kelvinliu_> thumper, was it the 1st time to run?
<thumper> yes, first time
<wallyworld> sigh
<wallyworld> my discourse post mentioend that
<thumper> taken about 5 minutes so far
<wallyworld> the first tinme is slow
<kelvinliu_> thumper, that should be much longer than 10s, :->
<wallyworld> there after stuff is cached
<thumper> cached where?
<wallyworld> some local dir, kelvinliu_?
<kelvinliu_> wallyworld, thumper ll $GOPATH/pkg/dep/sources
 * thumper nods, ok
 * thumper must stop eating this chocolate orange
 * thumper is running make check
 * kelvinliu_ finger crossed
<vinodhini> wallyworld: are u around ?
<veebers> rick_h_: ah, that's a bit of a bummer missing the build snaps when sorting out the new dep stuff
<rick_h_> veebers: yea
<rick_h_> veebers: and no easy fix I can see in my research today
<veebers> rick_h_: do we have a way forward at the moment/
<veebers> oh :-|
<veebers> rick_h_: the dep.csv needs to be in the source tree and not the packaging branch?
<rick_h_> veebers: I think the best thing is to add a new alternative plugin to https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/godeps.py
<rick_h_> veebers: or auto build a dep.csv from our deps stuff but I'm not sure what gaps there are in thata
<veebers> rick_h_: aye, would need to automate the dep.csv somehow, seems a bit tricky
<rick_h_> veebers: I'll bring it to the release call
<rick_h_> veebers: but in my research today I think a new plugin is the only long term route, but then again we don't plan on staying on deps forever either so...
<veebers> rick_h_: aye, it'll be module (i think it's called now) in the future assuming all goes to plan
<veebers> rick_h_: any idea on amount of work needed for a plugin?
<rick_h_> veebers: I don't think the python is bad just forking the godeps one and updating commands called where appropriate. The harder thing is if deps supports new config/ideas and what's it take to get it merged/pushed out and supported in LP builders?
<veebers> ah ack
<rick_h_> veebers: e.g. it's not something that'll have snaps being built by tomorrow :)
<veebers> :-| understood
 * veebers gets back to fixing the machine he, uh, mistakenly wiped yesterday
<rick_h_> lol
<rick_h_> did you get a bit aggressive with the house cleaning veebers?
<veebers> rick_h_: My inexperience with powershell and windows reared it's ugly head, I missed out the -WhatIf flag and poof a bunch of stuff cleaned up
<veebers> so we had plenty of space, just in the wrong places
<rick_h_> veebers: oops
<veebers> indeed, embarrassed and angry with myself :-P oh well, onwards and upwards
<babbageclunk> Seriously, they call --dry-run "-WhatIf"?
<babbageclunk> That seems wilfully obtuse.
<veebers> babbageclunk: hah it's like a different planet altogether, I'm sure it all makes sense when you get into it (or if it's what you know) but I'm not a fan
<veebers> there is also no cli text editor :-|
<babbageclunk> ugh
<babbageclunk> Sounds painful enough that you'd just RDP in all the time?
<veebers> oh, it's almost all RDP (which is gross ^_^), I couldn't get copy and paste to work, so needed to get the authorised key on there
<babbageclunk> bleh
#juju 2018-08-14
<babbageclunk> externalreality: what thumper said - if you call the API with the right creds (tag and password), you shouldn't get permission denied, no matter whether the agent's been removed from init.
<externalreality> babbageclunk, thumper I am calling the endpoint once (no problem), then I call it again after killing the init system service, after that I get permission denied errors.
<thumper> I don't understand how you are killing it and calling the endpoint at the same time
<thumper> whom are you killing?
<babbageclunk> externalreality: you're definitely killing the unit agent and not the machine agent?
<externalreality> babbageclunk: I am killing the unit agent's service directly
<externalreality> Then I am trying to update a record based by calling a service with its tag
<babbageclunk> I'm not clear what you mean by "calling a service with it's tag".
<babbageclunk> What facade/method are you calling? How are you connecting?
<babbageclunk> externalreality: (not trying to be pedantic, just want to understand what you're seeing)
<externalreality> babbageclunk, no worries, gathering logs to make things clear
<externalreality> babbageclunk, endpoint calls `canAccess(tag)`
<externalreality> babbageclunk, in the case before I call the service all is fine
<externalreality> babbageclunk, after killing the service - I get:
<externalreality> babbageclunk, `juju.worker.dependency "upgrade-series" manifold worker stopped: Access permission denied for string unit-ubuntu-0`
<externalreality> Indicating the I no longer can call `canAccess(tag)` where the tag is `unit-ubuntu-0` the tag of the service for whom I have killed their systemd/upstart service
<externalreality> Admittedly, I find it hard to follow the Auth code. Which is why I just thought I'd ask
<externalreality> I'll do more testing tomorrow to ensure that I am seein what I think I'm seeing before digging through Auth code.
<babbageclunk> I'm fairly sure canAccess isn't looking at services. I can help you track through the auth code if you want?
<externalreality> babbageclunk, I'll take a look in the morning. I am 5:28 minutes past EOD.
<babbageclunk> externalreality: Ok, ping me tomorrow if you want help then! (Where are you at the mmoment?)
<externalreality> babbageclunk, ack
<externalreality> babbageclunk, I am EST -1
<babbageclunk> Oh right - so pretty late for you then!
<rick_h_> kelvinliu_: ping, just a heads up taht if those changes work for the snap we need to update https://git.launchpad.net/~juju-qa-bot/+git/juju-edge-snap/tree/snap/snapcraft.yaml#n17 and the other git branches there as well.
<rick_h_> kelvinliu_: veebers might be able to get you the full links. I don't have my phone on me to 2fa into LP atm
<veebers> rick_h_: I'm on it :-) Just pulled myself to make sure I could
<rick_h_> veebers: gotcha cool. you all rock! :)
<veebers> kelvinliu_: so the sep packaging branch uses source-type, as it's source it pointing to a repo. This may trip us up
<kelvinliu_> rick_h_, yeah, i will need veebers help me understand how everything is setup. thx
<veebers> kelvinliu_: remind me the command to cleanup after dep?
<kelvinliu_> veebers, clean up what?
<veebers> kelvinliu_: ah sorry, i.e. when I'm switching between 2.4 and develop i need to remove vendor I think (I'm pretty sure this is covered in the discourse post and I should just RTM)
<veebers> ah right, just remove it :-)
<kelvinliu_> ah make godeps
<veebers> kelvinliu_: if you remove vendor from your working dir and try a snap build it'll fail
<kelvinliu_> veebers, develop branch?
<veebers> I'm not 100% sure why yet, but snapcraft will do a go get, then some sort of check/build before it's finished that and does the prepare (or now override-build)
<veebers> kelvinliu_: yes
<veebers> kelvinliu_: it only worked because we had that dir pre-populated and use a source of ./
<veebers> wallyworld, thumper FYI the win unit test job is running again. It has a build failure, seems to be due the the length of a filename or extension. That rings a bell from previously
<wallyworld> ty
<thumper> hmm...
<thumper> is it in the vendor directory?
<veebers> thumper: http://10.125.0.203:8080/job/RunUnittests-win2012/666/console
<thumper> ooohh... 666
<veebers> thumper: hah yeah ^_^ Aye, it looks like it is
<veebers> kelvinliu_: I've got a 'going to fail' run with --debug so hopefully will get some more info
<kelvinliu_> veebers, yes, we need to inject `make dep` after git clone immediately
<thumper> wallyworld: this switches the default https://github.com/juju/juju/pull/9061
<thumper> wallyworld: I'll add another later to deal with not starting the pingers
<veebers> kelvinliu_: aye, indeed. Just digging in to try figure that out
<kelvinliu_> veebers, either write dep plugin or ensure dep before plugin
<veebers> am I being blind or is there no search for https://docs.snapcraft.io/build-snaps/
<veebers> kelvinliu_: much like the override-build, there might be an override-pull
<veebers> FYI https://docs.snapcraft.io/build-snaps/scriptlets looks like it's possible (read the 1st paragraph so far)
 * veebers tries something out
<veebers> kelvinliu_, wallyworld: I'm failing to see a way around this. I tried override-pull, but the pull does a go get and tries to do some build (as it chokes on the deps), if I override to not do the pull then we don't have the source there to do anything with.
<wallyworld> veebers: i'm not up on the current core issue
<veebers> I also tried changing back to the godeps plugin and doing an override-pull: snapcraftctl pull || true; make dep. But the pull still fails
<kelvinliu_> veebers, im looking to write dep plugin
<veebers> wallyworld: essentially we fail at the pull stage, as the goplugin and godeps plugin does a go get ... + something else that fails so we have no chance to inject the make based dep handling
<veebers> kelvinliu_: ack, I think that's the only way forward
<veebers> kelvinliu_: I imagine it'll be a big ol' cribbing of the godep one
<veebers> hah you could potentially subclass the godep one and change pull().
<wallyworld> hmm, sad that it's this hard
<veebers> I see babbageclunk has a flying spaghetti monster WIP he's working on^_^
<veebers> #dadkjokes
<babbageclunk> ha
<wallyworld> thumper: lgtm
<veebers> thumper: if you have a moment could you sanity eyeball https://github.com/CanonicalLtd/juju-qa-jenkins/pull/71 please? It's adding a caas image build step after a edge snap build trigger
<veebers> then I'll merge that and deploy a handful of jobs that have changed recently
<kelvinliu_> veebers, im looking to see if we can put the dep.py to ./snap/plugins/
<veebers> kelvinliu_: intersting
<veebers> kelvinliu_: I take it you saw: https://docs.snapcraft.io/build-snaps/plugins
<veebers> (it outlines what you're trying to do I think)
<kelvinliu_> veebers, yes,
<veebers> sweet ^_^
<vinodhini> wallyworld: I am waiting for ur approval have pushed commits in both.
<wallyworld> ok, will look
<wallyworld> best to ping me when you need a re-review
<wallyworld> vinodhini: looks like there's still confusion about errors. let me know if you need a HO to clarify
<vinodhini> wallyworld: are u around
<wallyworld> i am
<vinodhini> I reverted whatever u have mentioned in the review
<vinodhini> pushed the commit
<vinodhini> I have made the previous chnages wheever the cause wasnt captured i changed all to fmt.Errorf that was my fault.
<vinodhini> i reverted back all.
<wallyworld> ok, looking
<wallyworld> vinodhini: almost there, main thing is a missing test still
<wallyworld> the reason for wanting the test is that we have shown that auth will fail if there's a mistake in the code in that area
<wallyworld> we need to also guard against future code breakages
<vinodhini> wallyworld
<vinodhini> I was going thru ur comments
<parlos> Howdy; i messed up. I've killed the host running the juju controller. :( Its not a big problem, its a testing environment. But; what would be the suitable path to start a new controller on the same cloud.
<parlos> would destroy-controller (or kill-controller), and the just bootstrap the new one be suitable, or would it potentially have some side effects on the running models?
<parlos> My guess, it would not, as the device running the controller is dead, hence the destroy command would have no way to talk to the models..Which also were hosted on that device..
<magicaltrout> https://github.com/juju/layer-index/pull/39 anyone around to give me a merge?
<vinodhini> wallyworld: are u around
<vinodhini> I have left comments for the test u have requested.
<vinodhini> Its already there without TenantName and TenantID
<vinodhini> wallyworld I have added the same comment in PR. Please let me know your input.
<wallyworld> parlos: you can juju unregister the existing controller (to clear it from the local juju cache). if the controller machine also hosted the model worker machines via containers or whatever, then they are all gone anyway and you can start again
<wallyworld> vinodhini: there's still no test
<wallyworld> for the v3auth scope
<parlos> wallyworld; thanks. The controller was just controller, the models/applications are fully functioning. But, I will redeploy them as to have them under control. I'll also start doing controller backups..
<wallyworld> parlos: if you want to redeploy, you should also manually kill the machines running the workloads
<wallyworld> juju unregister is the command you want to clear the controller away from juju's cache
<parlos> wallyworld; eventually; but one of the workloads is an openstack deployment, and its in use....( for another couple of weeks).
<wallyworld> ah ok
<wallyworld> if you had a juju backup you could have recreated the controller
<parlos> I'm reading on the backup, does this only apply to a specific model?
<magicaltrout> thanks
<wallyworld> magicaltrout: done
<wallyworld> parlos: if backs up the entire controller database; all models
<parlos> Ok, and if the controller has gone to /dev/null, then you need the downloaded backup file. Correct? This will basically bootstrap a new controller when the information in the backupfile..
<wallyworld> vinodhini: the test that's there isn't testing what I'm asking for. the code that was changed in the PR was to change how auth.Auth.Scope is set according to what cred values we have. I can't see a test for that
<wallyworld> the tests you are referring to appear to be testing other aspects
<wallyworld> we specifically need to ensure that what is passed to the identity endpoint is what we need
<wallyworld> it's very much a whitebox test. we need it because if the code is wrong, auth will fail
<npochet> I just had an issue with SCP (https://github.com/juju/python-libjuju/issues/259) and raised a PR fixing it: https://github.com/juju/python-libjuju/pull/260
<npochet> Thanks beforehand for the review!
<jamespage> tinwood, cory_fu: what's the reactive way of handling the 'stop' hook
<jamespage> ?
<tinwood> jamespage, good question. Probably @hook for the moment, unless @hook has been removed now
 * tinwood goes off to check
<cory_fu> tinwood: It hasn't been removed.
<cory_fu> jamespage: Yeah, I think @hook, I guess
<tinwood> thanks cory_fu
<jamespage> ok good
<jamespage> I was not wrong then - someone asked me
<cory_fu> jamespage: Ideally I'd like to add a framework-driven flag for it, just for consistency, but stop is always going to be a bit of a special case
<stickupkid> rick_h_: with this mutliple credentials, so this issue is that when using lxc to auto detect credentials, localhost breaks, as there are always multiple credentials - i wonder if we just never return locally discovered credentials?
<rick_h_> stickupkid: processing ...
<stickupkid> i.e. we can discover the remote, but you have to add the credential manually?
<stickupkid> so it will show in "add-clouds", but you can't bootstrap to it
<rick_h_> stickupkid: k works for now to move forward
<stickupkid> although you're likely to get a cryptic message about localhost not the right credentials for nuc5
<rick_h_> and puts the right priority on what's easier vs more akward
<rick_h_> stickupkid: ?
<stickupkid> i think it's both akward
<stickupkid> maybe we should back out autodectection of local lxc configurations
<rick_h_> stickupkid: when would you get that message?
<stickupkid> bootstrap
<rick_h_> stickupkid: but if I bootstrap a remote I added as a cloud with a credential why would I get that error?
<stickupkid> so say you have some lxc remotes in your lxc client, you forget to add a credential for that lxc remote, and then do bootstrap
<stickupkid> it will try and use localhost, because LXD is special provider and always returns localhost creds :|
<stickupkid> as we've conflated local vs remote for LXD we can't differentiate when you want which
<rick_h_> stickupkid: I thought we were looking into stopping that. What came of auto creating the localhost cloud credential automatically?
<stickupkid> hmmm... i'm thinking when we could do that
<stickupkid> during bootstrap?
<rick_h_> stickupkid: HO?
<stickupkid> if so, we would need something like "providers.RegisterCloudCredentials()" <- tbh that would solve a lot of issues :|
<stickupkid> sure please
<magicaltrout> https://discourse.jujucharms.com/t/connectivity-issues/163/3
<magicaltrout> if anyones bored
<rick_h_> magicaltrout: ping'd the charmstore folks to see what's up. none of them in here :(
<magicaltrout> thanks rick_h_
<zeestrat> Yeah, charmstore is having a bad day here as well.
<stickupkid> rick_h_: this is looking and feeling good - i'm going to play with it more...
<stickupkid> rick_h_: at least I'm on the right track \o/
<rick_h_> stickupkid: good to hear
<veebers> Morning all o/
<babbageclunk> externalreality_: You're working on something to do with update-series, is that right?
<externalreality_> babbageclunk, the owner of the connection to the api was the machine agent, it was trying to auth as its units.
<babbageclunk> Ah, right.
<externalreality_> babbageclunk, instead we now auth as the machine and collects its units apiserver side
<externalreality_> babbageclunk, do you think that sounds more correct... I kind of think it does
<babbageclunk> Ok, that sounds like exactly what I'd have suggested, awesome.
<externalreality_> babbageclunk, ack, thank you for the ear sir
<veebers> kelvinliu_, thumper, rick_h_: Note: with the snap changes being made for the dep change we'll have to add some extra smarts to the release job so we can release either a 2.4.* or a 2.5.* in the future)
<babbageclunk> externalreality_: no worries, it sounds like you sorted it out independently anyway!
#juju 2018-08-15
<kelvinliu_> veebers, agreed.
<veebers> kelvinliu_: great work on the snap plugin stuff, lgtm
<veebers> oh, let me comment that on the PR :-)
<veebers> kelvinliu_: is this cribbed from the godep one?
<veebers> if so, would it be possible to inherit from that and just change what's needed (I suspect the pull part)
<kelvinliu_> veebers, the go and godeps plugin are very similar.
<veebers> kelvinliu_: ack, I wouldn't want to hold up the PR, twas a thought :-)
<veebers> kelvinliu_: is GepPlugin a typo?
<kelvinliu_> veebers, i was also thinking to inherit existing plugin, but later think the plugin could be changed more often and is not like lib, might be very easy to break.
<veebers> kelvinliu_: ack, fair enough
<kelvinliu_> veebers, typo! lol
<veebers> ^_^
<babbageclunk> thumper: hey, quick question? I've upgraded yaml, and a slight behaviour change is causing problems in the netplan tests.
<thumper> babbageclunk: what is the problem?
<babbageclunk> thumper: we're using UnmarshalStrict and relying on the fact that it will overwrite keys in maps (if you unmarshal into an existing structure).
<babbageclunk> thumper: the new version refuses to do this.
<babbageclunk> (of UnmarshalStrict)
<thumper> what does it do?
<babbageclunk> although normal Unmarshal will (but also that implies silently ignoring unrecognised attrs).
<babbageclunk> Errors.
<thumper> is it a bug in the yaml code?
<thumper> or defined behaviour?
<babbageclunk> The latter, I think
<babbageclunk> Yeah, it's mentioned in the doc
<thumper> probably worth checking that bit
<thumper> is it only effecting tests and not real code?
<babbageclunk> thumper: It's affecting real behaviour
<thumper> ugh... what is the new yaml changes needed for?
<babbageclunk> I use NewDecoder and NewEncoder in the raftlease code.
<babbageclunk> I could rewrite it without them, but that's kind of leaving the problem for someone else who tries to upgrade it next time.
<thumper> I guess we should fix the netplan code
<thumper> can you do a separate branch that just updates yaml and the netplan bits?
<babbageclunk> Also, the feature that netplan uses it for is kind of broken anyway. It's using this to merge multiple configs, but this doesn't merge the mapping values, it just replaces the object at one key with a new one: https://bugs.launchpad.net/juju/+bug/1701429
<mup> Bug #1701429: Netplan bridger does not properly merge yaml files <juju:Won't Fix by wpk> <https://launchpad.net/bugs/1701429>
<babbageclunk> Yeah, I'll do that.
<babbageclunk> (Separate branch for the yaml upgrade.)
<thumper> babbageclunk: will you fix bug 1701429 while you are at it?
<mup> Bug #1701429: Netplan bridger does not properly merge yaml files <juju:Won't Fix by wpk> <https://launchpad.net/bugs/1701429>
<babbageclunk> thumper: No, I wasn't planning on that, but it would be a step towards doing it.
<thumper> ok
<thumper> leave a bug reference in the code
<babbageclunk> Wilco
 * thumper sighs...
<thumper> vinodhini: commented on goose PR
<thumper> oh ffs, I fubared my git thing again
 * thumper wonders how to do this...
<thumper> how do I merge just one file out of a commit?
 * thumper wonders WTF is going on now...
 * thumper works it out
<thumper> nm everyone, it's all fine
<veebers> thumper: to merge a single file from another commit, in the past I've used 'git checkout <branch/commit> -- <paths>'
<thumper> oh... nice
<thumper> I ended up cherry picking then discarding
<veebers> ah, that'll work too
<thumper> babbageclunk: please ask jam to review your yaml netplan branch update
<babbageclunk> thumper: ok, will do
<veebers> kelvinliu_: awesome work with the edge snap, looks like their building fine now
<kelvinliu_> veebers, thanks for the help. :->
<thumper> hazaah
<thumper> well done veebers and kelvinliu_
<kelvinliu_> thumper, ^_^
<vinodhini> thumper: i have replied to ur comments and added few more unit tests.
<thumper> vinodhini: awesome, I'm EOD now, but I'll look tomorrow morning
<thumper> later peeps
<babbageclunk> hey jam: would you be able to take a look at this? https://github.com/juju/juju/pull/9063
<jam> babbageclunk: sure
<jam> babbageclunk: reviewed 9063, lgtm
<elox> I'm trying to deploy to a specific zone, but "juju status" ends up in "pending" how can I figure out why?
<hadrianweb> maybe stack on retrieving lxd image? or downloading rootfs?
<elox> Its a maas, to the servers are physical
<hadrianweb> so you can see the pxe installation progress
<elox> This is what i do: "juju add-machine zone=b209-1040
<elox> The output from juju status is "pending"
<hadrianweb> have you acces to server, ilo os ipmi to se quehre they are stacked?
<elox> I can perform a "power check" successfully, I don't think its the ipmi
<elox> If I run "juju deploy ubuntu --to able-stork.maas" .... that works (which is the only host in the zone I need) the host successfully deploy. But as soon as I deploy with "juju deploy ubuntu --to zone=b209-1040", it ends up in pending.
<elox> Maybe this is a MAAS specific question.
<rick_h_> elox: do you see a machine pop up and start allocating in MAAS?
<elox> rick_h: The node works
<elox> I'm trying out the zone concept, so its not a crisis, but I keep getting stuck at "pending"
<rick_h_> elox: right, so from a Juju perspective it seems it's asked for a machine. So I'm wondering if MAAS is seeing/bringing up that machine at all?
<elox> rick_h: It seems that it could have been due to me using another users model which I seem to be able to deploy machines, but not using "zone" as a placement directive... very confusing. I'm now using a model I own and it seems to work now ?
<jam> elox: if you're using another users model, then likely it is deploying using *their* credentials. Are they able to see the zone in MAAS?
<jam>  and/or do they have machines in that zone available to them from MAAS?
<jam> we do a check to see if the availability zone specified is available, and generate a "availability-zone "blah" is unavailable" if we don't see it.
<elox> jam: It started to work just now, but stopped to work for newly added zones (!)
<elox> Could this be due to some delay in some update frequency for the nodes metadata?
<elox> It seems it might not have been due to the ownership of the modes since now after I have made some modifications to the zones again in MAAS, again, I'm getting the "pending" status for using the new zones.
<hml> stickupkid: do you want me to wait on reviewing pr 9065 or go ahead?
<stickupkid> hml: go ahead
<hml> stickupkid: k
<elox> I have found that only when starting a new model, it seems to work to deploy to a zone. As soon as I create a new model, it works for that model. This must be a maas/juju bug ?
<elox> Is this perhaps "by design" ? keeping zone information imutable ?
<stickupkid> hml: I responded to your questions... i've got a potential fix for register credentials comming, but thought i'd give a heads up https://github.com/juju/juju/pull/9065#pullrequestreview-146467062
<veebers> rick_h_: you may have seen that kelvinliu_ sorted out the edge snap builds
<rick_h_> veebers: yep, awesome stuff. Used it today to test out some stuff
<rick_h_> veebers: and ty for your discourse post around the snap stuff
<veebers> nw, always good to get the siloed info shared
<thumper> anyone? https://github.com/juju/juju/pull/9064
 * babbageclunk is someone!
<thumper> vinodhini: ping
<kwmonroe> thumper: i enjoy reading your PRs.  i'm not qualified to review them, but by golly, i like that even you have to add a 2nd commit that says "fix the tests".
<thumper> heh
<thumper> kwmonroe: and you can even see that the commit that fixes the test doesn't just delete them or comment them out :)
<kwmonroe> yeah thumper, that was weird.  i look forward to a discourse post that says "don't just delete the tests; fix them!"
<thumper> :)
<kwmonroe> (ps, most tests can be fixed with global vars)
 * babbageclunk narrows eyes
 * babbageclunk reaches for an obscure unicode character
<babbageclunk> I didn't even send it!
<kwmonroe> ha babbageclunk!  it took me a minute to get the ref... don't you worry, unicode away, for i have just upgraded my quassel.  you can't hurt me now â
 * babbageclunk hmms
<babbageclunk> Did he just auto-lart?
<vern> hey thumper: I've got several bundles that are only different by a few lines in the variables section. can an overlay bundle simply be a variables section? or do I need to also define every application/option that I want to change with those variables?
<thumper> vern: the variable substitution is done before the merging code
<thumper> as the substitution happens as part of the yaml parsing
<thumper> vern: so the latter
<vern> thumper: ah, I was worried about that. okay, thanks
<kwmonroe> dag nab it.  quassel-client wasn't the problem.  â« â Ã¸ all day now babbageclunk
<vern> thumper: slight variation to the same question: do juju bundles allow any kind of include directive?
<thumper> vern: only post parsing... for include and include-base64 for config values
<vern> thumper: thank you
#juju 2018-08-16
<anastasiamac> babbageclunk: PTAL https://github.com/juju/juju/pull/9069 - create-backup options check revisited..
<babbageclunk> kwmonroe: yay, glad you got all the glitches sorted out! â
<babbageclunk> anastasiamac: looking
<anastasiamac> \o/
<babbageclunk> anastasiamac: approved!
<anastasiamac> \o/\o/\o/
<anastasiamac> review anyone - https://github.com/juju/juju/pull/9071? one line change to remove an xtra newline..
<veebers> anastasiamac: I can hit it
<anastasiamac> veebers: tyvm!
<veebers> anastasiamac: hah always keen to grab the easy ones. LGTM
<anastasiamac> veebers: :D
<thumper> vinodhini: ping
<vinodhini> thumper
<vinodhini> yes.
<veebers> thumper: to set logging to debug, it's a model-config command, do I need to do something so the controller is set to that logging level too, or does that hit everything?
<vinodhini> thumper:
<veebers> kelvinliu_: have you deployed a k8s cluster in aws recently? I'm trying but failing (following Ians post in discourse)
<kelvinliu_> veebers, last time was ~ 1 month ago, i think
<kelvinliu_> veebers, any errors u got?
<veebers> kelvinliu_: this time around it's different, I see a complaint about too many tags
<veebers> https://pastebin.canonical.com/p/ZkFg7HY3k3/
<anastasiamac> thumper: is another 2.3 release on the cards?
<anastasiamac> i have a bug I am fixing in 2.4 and + and wondering if it should go futher back too...
<thumper> anastasiamac: at some stage, and it depends on the ease of back porting
<anastasiamac> thumper: real easy backport... was just wondering if it was worth the effort... but since the answer is 'yes, there is such a thing happenning', I'll backport ;)
<thumper> it is happening at some stage
<anastasiamac> ack. ta!
<veebers> kelvinliu_: you used eks with caas before?
<kelvinliu_> veebers, looks like too many tags on subnet? weird. No, I didn't use eks yet.
<veebers> Can someone educate me on tags in aws and how juju uses them, It seems we have 298 of them in this region. Is this a cleanup failure issue? Is there an account limit to how many there is allowed?
<veebers> hmm, no because a different region has more tags, is it per region? *shrug* I'll try use a different region
<kelvinliu_> veebers, i think the error is for that subnet resource has too many tags
<anastasiamac> veebers: do u mean that 'tags' are separate entity in aws?
<anastasiamac> i thought tags where just sort-of-labels on the instances
<veebers> kelvinliu_: hmm, ok. Might be a cleanup issue? as there is nothing running in that region
<anastasiamac> we use them to identify special purpose of the instance, like 'controller' machine or 'juju' machine, etc..
<veebers> anastasiamac: It might be a charm layer error too. I"m just trying to make sense of it
<veebers> well, actually right now I'm trying to ignore it for the immediate future :-)
<kelvinliu_> veebers, can u describe this subnet subnet-60510a26 to see the tags of it?
<veebers> kelvinliu_: I'm not sure how, via the aws console?
<kelvinliu_> veebers, i guess we are not always creating a new vpc and subnets for it, but always reuse existing subnets. But we always add new tags to that subnet, which exceeded the max ~50 tags per resource limit.
<kelvinliu_> veebers, either awscli or console. console would be easier
<kelvinliu_> veebers, if my assumption was correct, we should consider to remove the tags added to existing resources when we tear down the cluster.
<veebers> kelvinliu_: by console I mean the web ui, we're talking about the same thing?
<kelvinliu_> from the subnet tag issue, I remembered another thing - I think we should have only 1 cluster in same vpc. if not, the k8s traffic would have troubles. im not sure how we manage this in CDK now.
<veebers> kelvinliu_: I was spinning up in the same region wallyworld has in the past, not sure if things got left lying around etc.
<kelvinliu_> veebers, yes, console -> web ui, awscli -> boto cli
<veebers> kelvinliu_: ack, sweet. Sorry a bit slow right now :-P
<kelvinliu_> veebers, take a look how many tags the  subnet-60510a26 has, 50?
<veebers> kelvinliu_: just figuring out how to view that now
<kelvinliu_> veebers, i don't have web ui access setup yet. u should be able to find it from vpc -> subnets -> search  subnet-60510a26
<veebers> kelvinliu_: ack, just found the tags tab now
<veebers> kelvinliu_: it has a bunch, all starting with 'kubernetes.io/cluster/kubernetes-<bnlah>" no count though so would have to do manually ^_^
<kelvinliu_> veebers, my assumption is correct. :-
<veebers> kelvinliu_: ah, I missed the 'the max ~50 tags limit'. Ok so that makes sense
<veebers> kelvinliu_: so right now I should be able to deploy a cluster to a 'fresh' region as we wouldn't have filled up the subnet with tags.
<kelvinliu_> veebers, https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-tags.html would be  helpful
<veebers> I presume it'll be safe enough to manually remove those tags as there are no instances running in that region
 * veebers looks
<anastasiamac> thumper: this si the PR I want to backport to 2.3 - https://github.com/juju/juju/pull/9073
<anastasiamac> as per jam's suggestion, we will not format single value 'config' output to allow for machine consumption...
<thumper> I think the stderr output by default will be confusing
<anastasiamac> i thought i did stdout...
<anastasiamac> thumper: only warning is on stderr
<thumper> 	c.Assert(cmdtesting.Stderr(ctx), gc.Equals, "format yaml is ignored\n")
<thumper> ï¿¼
<thumper> for every time
<anastasiamac> thumper: oh i c, u mean for wraning msg...
<anastasiamac> yes, sure, can make it a debug
<anastasiamac> like log..
<thumper> even logged at info level
<thumper> but not ctx.Infof
<anastasiamac> yep...
<anastasiamac> apart form that u r +1?
<anastasiamac> thumper: ?
<thumper> yep
<thumper> approved
<anastasiamac> \o/
<thumper> vinodhini: where are we with the goose PR?
<vinodhini> thumper: i am fixing the mock.
<thumper> ok
<jam> anastasiamac: thanks for the patch. did you test at all with non-strings? Like an Int or Bool config type? I think Println does the right thing, I was hoping to be sure.
<vinodhini> thumper: i have pushed a commit now./
<vinodhini> just did.
<vinodhini> thumper : can u have a look please
<thumper> vinodhini: yep
<anastasiamac> jam: i have
<jam> great
<anastasiamac> what concerns did u have ober println? that it would not print the line?
<anastasiamac> i find that it does and is actually safer on platforms where newline is not \n..
<vinodhini> thumper: thanks
<veebers> thumper: on bionic we use a different mongo package? i.e. I need to update my juju-mongo script to use /usr/bin/mongo not /usr/lib/juju/mongo*/...
<thumper> veebers: yes
<vinodhini> anastasiamac:
<vinodhini> thumper asked me to revert back the export-bundle command to dev mode only CLI part
<vinodhini> i have also removed the ci becuase the command is not exposed and bootstrap will fail.
<vinodhini> could u please take a look and approve
<vinodhini> this is for 2.4.2 relaese
<elox> What charms/bundles exists that can deploy an "ovirt" cluster for us to use as a MAAS pod?
<jam> guild review requested for https://github.com/juju/txn/pull/43
<stickupkid> jam: i'll have a look
<stickupkid> jam: done
<wpk> thumper: o/
<magicaltrout> kwmonroe: you understand the bigtop packaging more than i do
<magicaltrout> if we wanted to expose the spark thriftserver
<magicaltrout> what do we need to do?
 * magicaltrout has a feeling it needs sticking in the deb
<magicaltrout> but worth checking
<magicaltrout> hmm maybe not, it seems to be kicking around in the deb spark rules
<magicaltrout> hrmmm
<kwmonroe> magicaltrout: i think we do not enable the thriftserver by default because of a port conflict. remember when you asked about this in 2015? https://lists.ubuntu.com/archives/juju/2015-September/005688.html
<kwmonroe> magicaltrout: that said, i don't see how port 10000 conflicts with sparksql, but whatevs.  gimme 4 minutes to deploy spark and make sure thriftserver is even a thing we can start.
<kwmonroe> magicaltrout: if it is, it's just a matter of "juju run --application spark '/start/thrift/server'" and "juju run --application spark 'open-port xxxx'".
<kwmonroe> magicaltrout: so it seems we don't have an action for the thriftserver :/
<magicaltrout> yeah kwmonroe I was poking around and saw the stuff in the deb but it doesn't seem to materialise on the serevr
<magicaltrout> server
<kwmonroe> magicaltrout: hive does, can i interest you in some hive? https://github.com/apache/bigtop/blob/master/bigtop-packages/src/charm/hive/layer-hive/README.md#thrift-interface
<magicaltrout> unless i'm missing something
<magicaltrout> well
<magicaltrout> the service
<kwmonroe> here's the thing magicaltrout, and you must know i hate saying this in a publicly logged channel, you're not missing anything.  we have no charming method of activating a thriftserver on spark.
<magicaltrout> well the charm bit i can cope with
<magicaltrout> root@ip-172-31-24-148:~# less /etc/init.d/spark-
<magicaltrout> spark-history-server  spark-master          spark-worker
<magicaltrout> i'm surprised it doesn't have an init script
<magicaltrout> /home/ubuntu/bigtop.release/bigtop-1.2.1/bigtop-packages/src/common/spark/spark-thriftserver.svc
<kwmonroe> magicaltrout: don't be so surprised.  the .svc bits haven't made it through bigtop yet because nobody's sure if systemd is a thing yet.
<kwmonroe> magicaltrout: do this:
<kwmonroe> juju run --unit spark/0 'sudo -H -u spark /usr/lib/spark/sbin/start-thriftserver.sh'
<magicaltrout> yeah i shall :P
<magicaltrout> fair enough, i thought the svc bits were in use
<kwmonroe> yeah, you thought
<kwmonroe> (j/k, maybe they are, but when in doubt, i just like to run java by hand)
<magicaltrout> i have an oozie question coming in 5 minutes when i've remembered what it was
<kwmonroe> i'm EOD in 4 minutes
<kwmonroe> maybe less if you ask your question too early
<magicaltrout> fair enough i'll leave it to tomorrow
<magicaltrout> oozie is missing a linux level user somewhere
<kwmonroe> magicaltrout: for reals though, the deb doesn't need to be altered -- start-thriftserver.sh is there on the unit, you'll just have to juju run it vs having a service (or install the svc as a proper service)
<kwmonroe> magicaltrout: the thing that bigtop could use is a jira to say that the spark deb is providing a service that is never activated -- that feels like an oversight to me.
<magicaltrout> k
<magicaltrout> i'll upstream it
<kwmonroe> +1
<kwmonroe> magicaltrout: i missed your comment earlier, but i'm having real trouble parsing "oozie is missing a linux level user somewhere".  like, the user isn't created, or it's expecting to use some pre-defined user?
<magicaltrout> na, i'm trying to put the bits back together cause its been a few weeks, but last time i ran oozie against the bigtop charms, i had to useradd <user> on the namenode/resmgr to get it to run jobs
<magicaltrout> so there's a misconfiguration on one side or the other, my fix the other week was a manual useradd, but that clearly doesn't scale :P
<kwmonroe> aaaaah yeah magicaltrout
<kwmonroe> one sec, i know your struggle
<kwmonroe> magicaltrout: before i forget, don't do that thriftserver run.  i'll tell you why in a minute.
<kwmonroe> magicaltrout: read this: https://github.com/apache/bigtop/blob/master/bigtop-packages/src/charm/hadoop/layer-hadoop-namenode/reactive/namenode.py#L81
<magicaltrout> aah that seems very similar
<magicaltrout> cool okay i'll try and remember what was broken tomorrow and then possibly send over a PR for that bit cause it certainly fixed it up last time
<magicaltrout> and it was something not on the oozie unit itself
<kwmonroe> magicaltrout: that's the same issue you're describing with oozie.  we had to do it so the NN could recognize files owned by 'mapred', 'spark', and 'yarn': https://github.com/apache/bigtop/blob/master/bigtop-packages/src/charm/hadoop/layer-hadoop-namenode/layer.yaml#L13
<magicaltrout> i've not gone completely mad then, thats good to know
<kwmonroe> nah, not completely magicaltrout, i think you can make a case for adding 'oozie' (or any other service that has a user that needs to drop bits in hdfs that the NN needs to know about) into that layer.yaml "users" dict.
<magicaltrout> cool
<kwmonroe> of course, cory_fu_ and i will vote whether or not we care about your case.  you know how that likely goes.
<magicaltrout> i also meant to say i can't believe you've missed out on cold wet London in November for a trip to spain or some shit
<kwmonroe> magicaltrout: before i forget, don't run that thriftserver
<magicaltrout> yeah why not?
<kwmonroe> shit, i've forgotten
<kwmonroe> lemme check debug logs
<magicaltrout> it starts and stops
<magicaltrout> living the dream
<kwmonroe> oof, looks like it fails to start an apache derby instance and then removes $HOME
<magicaltrout> lol
<magicaltrout> hmm did it fail or did it just return
<kwmonroe> magicaltrout: the process failed.  the machine is fine.  j/k on removing $STUFF.
<kwmonroe> magicaltrout: i think it might be because i told you to run it as sudo -u spark and spark can't write to $CHARM_DIR
<kwmonroe> java.sql.SQLException: Directory /var/lib/juju/agents/unit-spark-0/charm/metastore_db cannot be created.
<kwmonroe>         at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
<kwmonroe> lemme try again running that mama jama as root
<kwmonroe> lemme export $HOME=/ first
<magicaltrout> yeah runs as root
<kwmonroe> yeah, much better magicaltrout
<kwmonroe> $ juju run --unit spark/0 '/usr/lib/spark/sbin/start-thriftserver.sh'
<magicaltrout> just weirdly stops logging like its crashed
<magicaltrout> thats cool. Okay great, I might tack on a subordinate or something to fire that up. We've got most of the hue bits and pieces bolted on and working
<magicaltrout> just trying to tidy up sparksql and oozie properly
<magicaltrout> then it should be about ready along with the druid cluster in a couple of weeks
<kwmonroe> magicaltrout: i will outright reject any thrift subordinate, so don't bother.  you can propose an action to start the server, nothing more, nothing less.
<magicaltrout> i didn't say i'd bother giving it to you :P
<magicaltrout> what i would like is for it to work without a user having to flip a switch
<kwmonroe> magicaltrout: i'll take a config thriftserver=true or an action 'start-thriftserver'.  i'm not even kidding, don't you dare make a spark suboridnate that is is just 'spark' with only the thriftserver running.  i'll find you.  i'll be angry.
<magicaltrout> okay i might be happy with a config option
<magicaltrout> i dislike actions
<kwmonroe> then it seems like we've found a middle ground.  let's stop here before we start cursing one another.
<magicaltrout> alright fair enough, you're still in my bad books for passing up a trip to london. Thanks for the tips, expect some PR's to land sometime soon.
<kwmonroe> +1 magicaltrout, gotta see a guy about a horse now.
<rick_h_> kwmonroe: hah. If you're serious we need to catch up sometime
#juju 2018-08-17
<rick_h_> How goes vinodhini ?
<babbageclunk> anastasiamac: PTAL https://github.com/juju/juju/pull/9078?
 * anastasiamac looking
<babbageclunk> ta
<babbageclunk> thumper: trivial review? https://github.com/juju/pubsub/pull/8
<vinodhini> hi rick_h i am good.
<vinodhini> I fixed all minor test issues.
<vinodhini> If u can take a look please.
<anastasiamac> babbageclunk: so neat! loved it :D
<babbageclunk> I'm going to put that quote on the cover of the paperback when it comes out!
<babbageclunk> Thanks anastasiamac
<babbageclunk> hmm, good question about 2.4 - rick_h_, what do you think? https://github.com/juju/juju/pull/9078
<vinodhini> rick_h : regarding the error handling issues.Where you able to test that same scenarios in GUI ?
<rick_h_> babbageclunk: hmm I don't think oci is in 2.4
<babbageclunk> rick_h_: ah, ok - then that makes it simpler. I'll just look
<rick_h_> vinodhini: I didn't. What are we looking for or expecting?
<babbageclunk> rick_h_: yeah you're right - the package is there but it's all just NotImplemented stubs.
<rick_h_> babbageclunk: cool
<vinodhini> rick_h: approval for PR. Plus regarding the errorhandling  issues u have mentioned. Yes. there is a delay until the whole setup comes up fully.
<rick_h_> vinodhini: feedback inbound
<rick_h_> vinodhini: yes, so thumper had some ideas around some of those, implementation-wise
<rick_h_> vinodhini: so the version thing I think needs to be right for that PR other than that thanks so much for the great updates
<vinodhini> ok. then i would like to discuss regarding that delay issues today.
<vinodhini> let me fix the version so i can get that merged.
<vinodhini> rick_h: isnt better not to have version in that error message so there wont be any misinterpretation.
<rick_h_> vinodhini: that's ok for the moment.
<rick_h_> vinodhini: do me one favor though, make sure to call it the "bundle export feature"
<rick_h_> vinodhini: as any juju 2.x supports deploying bundles
<rick_h_> vinodhini: just to be clear to users
<vinodhini> sure then i will remove the version and update the message.
<rick_h_> vinodhini: awesome
<vinodhini> rick_h: i have push the commit now.
<vinodhini> so, we are done with cosmetic changes related to export-bundle.
<vinodhini> We have now: 3 pending
<vinodhini> delay and error handling, series, machine constraints
<rick_h_> vinodhini: k, approved
<vinodhini> rick_h: ty
<rick_h_> vinodhini: are you also able to get the good update in during your day so we can lock down 2.4.2?
<rick_h_> Sorry, goose, not good
<vinodhini> rick_h: goose - not good ?
<rick_h_> vinodhini: so thumper says that we need to update the goose dependency with your fixes in the 2.4 branch to be part of the release we're locking up tomorrow morning.
<vinodhini> rick_h: i have updated the goose dep with my changes i mean after merging goose stuffs and merged the juju PR: https://github.com/juju/juju/pull/9049
<rick_h_> vinodhini: ok, so 2.4 branch is all caught up with your goose changes?
<vinodhini> yes.
<vinodhini> thumper: i have updated the juju side PR which got merged after the goose chnages landed with dependencies.tsv update.
<vinodhini> Apologise i didnt inform but i did it.
<rick_h_> vinodhini: cool ignore me then. Sounds good.
<vinodhini> rick_h: sure. Its ok to double check.
<vinodhini> thumper: that PR : https://github.com/juju/juju/pull/9076 - export-bundle in dev mode should go with 2.4.2 correct ?
<vinodhini> i have answered ur question this morning. Could u please take a look when u get time ?
<thumper> vinodhini: commented on PR, I'd like us to keep the file
<vinodhini> thumper: sure
<vinodhini> reverting now.
<vinodhini> thumper: pushed to commit.
<thumper> ack
<thumper> approved
<vinodhini> thumper: ty
<thumper> bugger...
<thumper> that thing that I knew was going to be a problem in the future is a problem
 * thumper thinks how to fix with minimum impact
<thumper> babbageclunk: busy?
<vinodhini> i believe rick_h is offline. thumper: when u get time before you leave for the day i would like to discuss regarding the other issues in export-bundle.
<thumper> vinodhini: sure
<thumper> I can do now if you like
<vinodhini> I have updated the doc with few questions which rick_h also can read thru
<vinodhini> ok.
<vinodhini> ho ?
<thumper> yep, in 1:1
<babbageclunk> thumper: sorry, totally missed your ping
<babbageclunk> is now good?
<thumper> yep
<thumper> babbageclunk: ^^
<babbageclunk> saw that one!
<thumper> babbageclunk: I'm in our 1:1
<anastasiamac> thumper: we have some fairly old PRs (say from Jan this year)... do we still want them around?
<magicaltrout> is it me or is JAAS really sad this morning?
<rick_h_> magicaltrout: not sure just waking up.
<rick_h_> magicaltrout: passed the report along. Any details?
<fnordahl> for a bundle without a `machines` section, is there a way to decide in which order the machines will be allocated for charms?
<rick_h_> fnordahl: in what order? no. It just means juju will ask for machines that meet the application constraints and take what the underlying cloud gives it
<magicaltrout> if anyone is still here can you give https://github.com/juju/layer-index/pull/42/files a merge before you all bugger off for the weekend
 * rick_h_ wonders what an oozie is
<rick_h_> magicaltrout: "The repository for this project is empty" :(
<magicaltrout> pfft
<magicaltrout> i was padding it out so someone could merge it :P
<magicaltrout> there is now a relation
<rick_h_> magicaltrout: :)
<magicaltrout> in answer to your question, oozie is a big data workflow manager
<magicaltrout> in the bigtop stack
<rick_h_> magicaltrout: ok, hit the merge button
<rick_h_> magicaltrout: hope I don't get in any trouble :P
<magicaltrout> thanks. Just finishing up our hue charm
<kwmonroe> magicaltrout: did you mean to have #41 closed in favor of #42? https://github.com/juju/layer-index/pull/41 -- i see both included oozie, but jdbc was already there?  i'm so confused.
<magicaltrout> don't think it matters kwmonroe
<magicaltrout> your user tip from yesterday worked a treat thanks
<magicaltrout> sweet and a working spark config for the thrift server
<magicaltrout> i'll have a couple of PR's for you on monday kwmonroe to complain about and throw back in my face
#juju 2018-08-19
<thumper> Looks like the base snap layer has a behavioural clash with the new snap proxy model settings
<thumper> as in it will overwrite what Juju says with what it thinks...
<thumper> and it thinks wrong
<thumper> babbageclunk: hey
<thumper> babbageclunk: did you want to finish our chat from friday?
<veebers> thumper: snap layer, is that something in juju or the snapd bits?
<thumper> it is used in reactive charming for things using snaps
<veebers> ah I see, charm layer gotchya
<babbageclunk> thumper: hey - maybe? About your stuff or my bug that I was chasing?
<babbageclunk> In theory I have a 1:1 with wallyworld any minute now.
<thumper> babbageclunk: yours, I spent all weekend worrying about mine and realised I was looking at the wrong thing
<babbageclunk> d'oh
<thumper> I still need the open method
<babbageclunk> no, I've got a thread I'm pulling on mine.
<thumper> ok
<babbageclunk> well, really it's hundreds of goroutines but still
<thumper> mechanical change: https://github.com/juju/juju/pull/9079
<thumper> can I get a +1 from someone on the package moves?  https://github.com/juju/juju/pull/9079
 * veebers looks
<veebers> thumper: done
<thumper> veebers: ta
#juju 2019-08-12
<wallyworld> babbageclunk: here's a small gomaasapi https://github.com/juju/gomaasapi/pull/81
<babbageclunk> wallyworld: looking
<babbageclunk> wallyworld: approved!
<wallyworld> ty
<timClicks> babbageclunk: it looks like names for vapps must be globally unique
<babbageclunk> ?
<babbageclunk> weird
<babbageclunk> so when you clone one you give it a uuid for a name?
<timClicks> it's possible (probable?) that i'm not specifying the path properly
<babbageclunk> timClicks: yeah, it would make more sense that it needs to be unique within the resource pool
<wallyworld> babbageclunk: https://github.com/juju/names/pull/92
<babbageclunk> wallyworld: looking
<babbageclunk> wallyworld: approved - sorry, got sidetracked
<wallyworld> babbageclunk: ty, no worries
<wallyworld> kelvinliu_: whenever you get a chance https://github.com/juju/juju/pull/10510
<wallyworld> no rush
<kelvinliu_> yep
<kelvinliu_> wallyworld: lgtm thanks!
<wallyworld> timClicks: any luck with cloudinit/vsphere?
<timClicks> wallyworld: progress, but not completion - I'm still getting naming conflicts
<wallyworld> timClicks: you're not blocked? ie no need to ask for advice on their slack channel?
<anastasiamac> wallyworld: kelvinliu_ : add-k8s UX PTAL https://github.com/juju/juju/pull/10511
<wallyworld> o
<wallyworld> k
<anastasiamac> :)
<anastasiamac> dunno what to think of that response
<wallyworld> anastasiamac: did you want to discuss the k8s host cloud behaviour?
<anastasiamac> wallyworld: yes but m out of time now...
<anastasiamac> do u want to do it late-ish or tomorrow
<wallyworld> no worries, tomorrow is fine. i have soccer in about 3 hours
<anastasiamac> k
<anastasiamac> actually i could call u from the car in about 20/30... does that work
<anastasiamac> ?
<anastasiamac> wallyworld: ^^
<wallyworld> sure
<anastasiamac> \o/
<hml> manadart:  review pls?  https://github.com/juju/juju/pull/10512
<hml> manadart: there is an add-subnet featuretest left to be resolved from the subnet ID change.
<hml> manadart: have you played with the networking common cache?
<hml> looks like a different idea of a cache
<manadart> hml: I have not written code against it, but I saw it while reworking stuff into core/network.
<hml> manadart: yeah.. the code is juju 1.x
<hml> wondering if we should keep it or not
<hml> manadart:  do we have plans for BackingSubnetInfo in the long run?
<manadart> hml: It looks like a lot of optimisation effort for a not-particularly-hot path.
<hml> manadart:  agreed.
<manadart> hml: I noted the comments against Backing[Space|Subnet]Info too.
<manadart> hml: I think we audit the benefit of the stuff in networking/common. If we can throw it away, the backing types go too.
<hml> manadart:  thatâd be nice.
<manadart> If we keep it, I think we should look at replacing them with the core xInfo types.
<hml> it maybe giving me grief with one of feature tests and the id change
<hml> thereâs little overlap between the two SubnetInfos
<manadart> hml: Just doing QA on your patch. Added a card to audit networkingcommon.
<hml> manadart: rgr
<manadart> hml: Approved. Going EoD too.
 * manadart waves.
<hml> manadart:  ty and g'night
<wallyworld> timClicks: just wanted to check vsphere status before release call... how's it going?
<timClicks> wallyworld: I'm still working my way through incompatibilities between vapps and vms
<timClicks> wallyworld: debugging is *very* slow because I need to stream the vmdk every time, which adds about 30mins of latency to every code change
<babbageclunk> timClicks: you could hardcode the vmdk path to not be based on the controller uuid and then just reuse it each time.
<babbageclunk> (and comment out the deletion too)
<timClicks> that's a good suggestion
<timClicks> babbageclunk: do you have a few minutes?
<babbageclunk> timClicks: yup
<babbageclunk> in standup?
#juju 2019-08-13
<timClicks_> babbageclunk: hey sorry to bother you again, would you mind helping me out with an interface/type coercion issue I've encountered
<babbageclunk> timClicks_: sure sure!
<timClicks_> I'm 90% sure that I've identified the cause of the import issues
<babbageclunk> oh awesome
<thumper> timClicks_, babbageclunk: what's the tl;dr on vsan?
<timClicks_> thumper: tell you in a few minutes
<thumper> ack
<timClicks_> thumper: we've identified what's causing the cloud-init the issue; specifying user-data is available into a VirtualApp (container for 1 or more VMs) rather than a VM
<timClicks_> annoyingly, the call to ImportVApp (which we
<timClicks_> we have been using) returns a VM if the OVF only defines a VM
<timClicks_> it looks like we need to customise the OVF XML file that we embed
<timClicks_> babbageclunk: it looks like we need to wrap the <VirtualSystem> tag within a <VirtualSystemCollection>
<babbageclunk> timClicks_: yeah that makes sense
<timClicks_> babbageclunk: tweaking the ovf is creating a vapp
<timClicks_> *babbageclunk: tweaking the ovf is working, currently creating a vapp
<babbageclunk> timClicks_: I got distracted by the following rabbit-hole: VirtualMachineConfigSpec.VAppConfig.Property (which looks like it would let you edit the fields on that form in the clone VM wizard)
<timClicks_> babbageclunk: that looks promising
<timClicks_> using a vapp directly doesn't seem like a good option
<babbageclunk> Having dug around a bit I think extraConfig is still actually what we want though - trying that now
<babbageclunk> timClicks_: bums - yeah, I was worried about that
<timClicks_> babbageclunk: we have a method to modify extra config in our vsphereclient code
<babbageclunk> bugger, looks like I'm still uploading a vmdk
<babbageclunk> looking for that
<timClicks_> babbageclunk: it looks like you've been able to power on a machine?
<babbageclunk> yeah, but no dice - it still lists the same values in its vapp options
<babbageclunk> ok, I'm going to have a go at changing the VAppConfig stuff. It's all a bit black magic though
<babbageclunk> timClicks_: trying using govc to extract info about the vm so I can feed that back in
<wallyworld> kelvinliu_: there's a k8s bug :-( https://github.com/juju/juju/pull/10515
<kelvinliu_> wallyworld: looking
<kelvinliu_> wallyworld: lgtm, thanks!
<wallyworld> ty
<wallyworld> stupid typo
<kelvinliu_> [Facepalm]
<stickupkid> rick_h, achilleasa here is the output of a bash cmr bundle example https://paste.ubuntu.com/p/k2S8gTbBJk/
<stickupkid> achilleasa, it works really nicely
<stickupkid> the great thing is, that test from e2e ran in 2m28s which beats the hell out of the python one
<gizmo693> Hi Guys. Newbie question. I am working the the docs on https://jaas.ai/docs/getting-started-with-charm-development and when I get to the charm build command it is failing
<gizmo693> According to magicaltrout there is a missing series in the metadata.yml ?
<gizmo693> Any pointers/advice?
<rick_h> gizmo693:  the metadata.yaml needs a series key to say what ubuntu series the charm works on.
<gizmo693> I have a trout that is magical in my office so will be able to ask what that means
<stickupkid> gizmo693, example https://api.jujucharms.com/charmstore/v5/~jameinel/ubuntu-lite-7/archive/metadata.yaml
<gizmo693> From a newbies perspective how would I (anyone) know that
<stickupkid> gizmo693, good shout tbh
<rick_h> gizmo693:  if you're using a starting template I think it defaults to the latest stable series for you
<rick_h> gizmo693:  but the question is what os/version does the software your charm works against work on?
<gizmo693> I'm just trying to work through the getting started guide as opposed to actually building a charm of my own
<stickupkid> achilleasa, export bundle test https://github.com/SimonRichardson/juju/blob/tests-suite/tests/suites/cmr_bundles/export_overlay.sh#L1-L36
<gizmo693> magicaltrout said is it charm build or charm create I should be using?
<achilleasa> stickupkid: looks nice! One neat trick that I like to use is to pipe the output to something like "sed -e 's/^/ |/g'" so you can get it indented
<rick_h> gizmo693:  ok, if you've got comments/feedback/edits please note the link at the bottom which goes to the discourse post for the page you're on. https://discourse.jujucharms.com/t/getting-started-with-charm-development/1118
<rick_h> gizmo693:  charm create will let you start with a known template
<rick_h> gizmo693:  charm build is the command to build your charm (compile it really)
<stickupkid> achilleasa, i was thinking about that, but then i'm wondering if we should do it everywhere?
<achilleasa> stickupkid: possibly; or create library functions that you include in your script (ala init.d's functions)
<stickupkid> achilleasa, yeah, that's easy to do, anything in side this folder gets included across all tests https://github.com/SimonRichardson/juju/tree/tests-suite/tests/includes
<achilleasa> stickupkid: any plans for handling timeouts? (for juju deploy)
<stickupkid> achilleasa, we could easily use timeout
<achilleasa> stickupkid: +1
<stickupkid> achilleasa, i.e. `timeout -k 10m juju bootstrap lxd test`
<rick_h> achilleasa:  time to catch up?
<achilleasa> rick_h: sure
<rick_h> achilleasa:  k, meet you in daily
<rick_h> stickupkid:  "no description provided" boooooo :P
<stickupkid> rick_h, for?
<rick_h> stickupkid:  your PR
<stickupkid> rick_h, ah, i'll fill that in now
<stickupkid> rick_h, done
<rick_h> stickupkid:  k, review done
<rick_h> stickupkid:  anything else you needed in particular for today?
<stickupkid> rick_h, sometime to quickly have a look at the bash stuff
<rick_h> stickupkid:  k, that's going to go up as a PR of sort right?
<stickupkid> rick_h, yeah
<rick_h> stickupkid:  ok, let me know when that's up and will peek at it
<stickupkid> rick_h, i'll make that PR then, let me close out the pylib juju
<stickupkid> rick_h, sure
<stickupkid> rick_h, looks like https://github.com/juju/python-libjuju/pull/336 is good to me
<rick_h> stickupkid:  cool, aisrael going to hit merge on that then
<aisrael> rick_h: stickupkid: ta, thanks!
<achilleasa> rick_h: the async charm stuff works with macaroons as well :-)
<stickupkid> this annoys me https://paste.ubuntu.com/p/Yxq6sjpg93/ - juju returns something on stderr in none json format when I ask it to do so
<stickupkid> doing this makes me sad "juju status --format=json 2> /dev/null"
<rick_h> achilleasa:  woot
<rick_h> stickupkid:  seems less than ideal
<stickupkid> rick_h, esp. considering we're now hiding error messages :(
<stickupkid> rick_h, at some point in the future it would be nice to add better ux/design to the CLI - it's a bit rough and showing it's age esp. when comparing snap, kubectl etc
<rick_h> stickupkid:  yea, I think that's goals for the 3.x flow
<stickupkid> rick_h, let's go mental and add graphs https://github.com/gizak/termui
<stickupkid> :wink:
<rick_h> lmao
<thumper> morning
<rick_h> morning thumper
<wallyworld> babbageclunk: timClicks: what's the goss on vsan?
<babbageclunk> wallyworld: some progress - but have hit another snag, not sure what the issue is
<wallyworld> ok, i'll try and organise access to a vsphere technical person whom we can enage with
<babbageclunk> wallyworld: that would be awesome
<babbageclunk> wallyworld: things are looking pretty good
<babbageclunk> wallyworld: charmed-k8s seems to be deploying happily
<babbageclunk> (all machine agents are up, waiting for charm installs)
<timClicks> wallyworld, thumper: looks like babbageclunk's nailed it
<wallyworld> oh, goody. i'll catch up  and get the details soon
<babbageclunk> wallyworld: it looks like our vsphere machines can't install snaps though
<babbageclunk> might need a network change
<wallyworld> can you create an RT?
<timClicks> on it
<wallyworld> ty
<timClicks> just confirming that we haven't somehow introduced it via the patch by reproducing on 2.6.7
<thumper> what snaps are we installing?
<wallyworld> cdk uses snaps
<thumper> ah, right
<timClicks> as a side issue, using juju 2.6.7 to deploy multiple new units feels comically slow compared to the new patch
<timClicks> babbageclunk: the cdk install issue isn't due to us
<babbageclunk> timClicks: woot
#juju 2019-08-14
<thumper> babbageclunk, timClicks: vsan summary?
<babbageclunk> thumper: summary is: good - just testing out the non-hacked together version
<thumper> cool cool
<wallyworld> thumper: new azure regions turned out to be lots-o-fun https://github.com/juju/juju/pull/10518
<timClicks> wallyworld: thanks for wrangling through all of that
<timClicks> babbageclunk: hey btw could you raise a PR against my branch? I think that thin disk provisioning may be closer than we think
<timClicks> but I need the VM template stuff working
<babbageclunk> timClicks: pushing as we speak
<babbageclunk> timClicks: https://github.com/timClicks/juju/pull/1
<babbageclunk> ha, it's prompting me to delete my fork of timClicks/juju
<babbageclunk> and I'm all like "nuh-uh! If anything timclicks/juju is a fork of babbageclunk/juju!"
<timClicks> babbageclunk:  thanks for ruining my day by destroying all of my stuff github
<wallyworld> kelvinli_: i just need a +1 on a forward port of 2.6 https://github.com/juju/juju/pull/10519
<kelvinli_> wallyworld: done!
<wallyworld> ty
<kelvinli_> np
<stickupkid> merge 2.6 branch of pylibjuju into master https://github.com/juju/python-libjuju/pull/338 - only 120k of changes :|
<stickupkid> achilleasa, if we get rick_h to make a 2.7 branch once i've merged https://github.com/juju/python-libjuju/pull/338 into master, then you should just be able to copy the schema to the client folder and ln -s correctly with latest and then run make client
<achilleasa> stickupkid: thanks for the tip!
<rick_h> stickupkid:  land your branch first so the branch has that in it
<stickupkid> rick_h, achilleasa yeah, i've kicked it off
<stickupkid> achilleasa, pointers here https://discourse.jujucharms.com/t/python-libjuju/1553
<stickupkid> love me some discourse :D
<stickupkid> rick_h, achilleasa it's landed
<rick_h> stickupkid:  k, after the call I'll try to get it up
<rick_h> stickupkid:  achilleasa created the 2.7 branch
<stickupkid> rick_h, pylibjuju new version with CMR, 0.11.8 or 0.12.0 or 1.0.0?
<rick_h> stickupkid:  hmm, we talked about matching juju right?
<rick_h> stickupkid:  what do you think of the 2.6.x?
<stickupkid> rick_h, well, yeah, that could work, as it would make sense
<stickupkid> rick_h, should i mention anything in the readme about that?
<rick_h> stickupkid:  yea, and maybe discourse about moving to matching the juju versions
<rick_h> stickupkid:  always better to overshare vs under
<stickupkid> rick_h, 100% agree
<achilleasa> stickupkid: so for the bundle bit do I need to set my version to 2.7.0? 2.7-rc1 ?
<stickupkid> achilleasa, i'm never sure, we shouldn't release it with that, so maybe rc1 to ensure people delete it and replace it with 2.7.0
<stickupkid> 2.7-deleteme
<achilleasa> or 2.7-dev?
<achilleasa> I see some with the -rcX suffix
<stickupkid> 2.7-dev
<stickupkid> achilleasa, the rcX suffix ones need to be removed
<rick_h> stickupkid:  HO?
<stickupkid> CR for 2.6.6 release for pylibjuju https://github.com/juju/python-libjuju/pull/339
<manadart> hml: I am about to finish up, but could you look at https://github.com/juju/juju/pull/10520 in your day?
<hml> manadart:  sure.  trade you for a short one? https://github.com/juju/description/pull/59
<manadart> hml: Done deal.
<pmatulis> in an overlay, i needed to include a machine definition not used in the overlay but that *is* used in the accompanying bundle. what is the rationale there?
<stickupkid> pmatulis, achilleasa might know that
<achilleasa> pmatulis: is this with 2.6 or develop? can you share the bundle/overlay so I can take a look?
<rick_h> pmatulis:  I think it's just a limitation of the merging logic
<pmatulis> achilleasa, v.2.6.6
<pmatulis> rick_h, seems odd. especially when the error references the bundle and not the overlay
<rick_h> pmatulis:  right, a matter of the merging/resolving process is my guess
<achilleasa> pmatulis: can you please try the same with develop? We have completely refactored the merge logic for the upcoming 2.7 so it might work as expected with the latest edge
<pmatulis> achilleasa, ohh, fyi: https://pastebin.canonical.com/p/CGPR6ZsnMF/
<pmatulis> achilleasa, will the upcoming changes have potential for breakage if people don't make changes?
<achilleasa> pmatulis: no, the changes should be backwards-compatible (actually even better as some stuff like for instance the 'trust' flag cannot be currently overwritten via an overlay). The 2.7 version additionally supports the cmr-in-bundle work
<rick_h> stickupkid:  one question on the versioning in the PR
<stickupkid> rick_h, shoot
<stickupkid> rick_h, actually i'll trade you a PR for a question https://github.com/juju/cmd/pull/66
<rick_h> stickupkid:  sorry, replied with it. mainly...as much as I don't want to...2.6.6.1?
<stickupkid> hmmm
<stickupkid> 2.6.6.0?
<rick_h> stickupkid:  e.g. if we have to rev a libjuju version without a new juju version?
<stickupkid> rick_h, yeah, but start a 0
<stickupkid> ?
<rick_h> stickupkid:  is it enough to do 2.6 and then rev libjuju indepdenent?
<rick_h> stickupkid:  fair enough
<pmatulis> achilleasa, sweet, thanks
<stickupkid> rick_h, "is it enough to do 2.6 and then rev libjuju indepdenent" - not sure i understand
<achilleasa> pmatulis: the QA steps for https://github.com/juju/juju/pull/10476 include examples of the upcoming overlay changes. Note that the multi-doc yaml bundles are only processed by the new code path (but they are only used by the CMR features which older clients ignore anyway)
<rick_h> stickupkid:  so do we say that python-libjuju tracks 2.6 and so 2.6.3 might actually have the release note item of "updated to 2.6.7 api changes"
<rick_h> stickupkid:  e.g. since the api facades are locked in a way you should be able to use python-libjuju 2.6.x with any 2.6 juju?
<stickupkid> rick_h, ah in that case shouldn't it be 2.6.7 and we jump versions?
<stickupkid> rick_h, that might luck ugly though
 * rick_h doesn't follow that...
<stickupkid> rick_h, ho?
<rick_h> stickupkid:  omw
<pmatulis> first time i've seen one of my machines' state suddenly go from 'started' to 'down'. why does this happen?
<pmatulis> machine agent croaks?
<pmatulis> corresponding MAAS node shows it's powered off
<stickupkid> pylibjuju 2.6.0 released with CMR support
<stickupkid> manadart, released, i'll make a discourse post for it
<stickupkid> manadart, here you go https://discourse.jujucharms.com/t/pylibjuju-2-6-0-release-notes/1926
<rick_h> pmatulis:  so the agent restarts as part of going up
<rick_h> pmatulis:  if you time it right you can catch it in a down state but it should flip back
<rick_h> pmatulis:  if it doesn't then something went boom/etc
<pmatulis> rick_h, yeah, the node just crapped out on me. i had to power it back on via the MAAS web UI. everything looks fine now though. scary
<rick_h> pmatulis:  ah, yea don't trust hardware :)
 * rick_h secretly adds cards and sticks stickupkid's head on them for later in the week bwuhahahaha
<rick_h> hml:  can I bug you to make sure I typed "python" right please? https://github.com/CanonicalLtd/juju-qa-jenkins/pull/261
<hml> rick_h: sure, looking
<hml> rick_h: approved
<rick_h> hml:  ty
<stickupkid> rick_h, :worried:
<rick_h> stickupkid:  lol, all good you already did it
<rick_h> just didn't see it right away
<stickupkid> rick_h, haha
<wallyworld> timClicks: any luck with the thin disk spike?
<timClicks> wallyworld: I've found the two places that we need to change, but something weird happened when I tried to bootstrap
<timClicks> the process hung indefinitely
<wallyworld> could be related to the changes i guess. sounds like it needs a little more work to be acheievable
<wallyworld> thanks for trying
<timClicks> wallyworld: out of curiousity, how does juju/mutex work? I think bootstrap is hanging because a previous mutex hasn't been released
<wallyworld> timClicks: it's a machine wide mutex which uses flock on *nix and something else on windows
<thumper> review for someone: https://github.com/juju/schema/pull/19
<thumper> ugh, no merge bot set up for schema package
<thumper> looks like we have never had one set up
<thumper> babbageclunk: got a moment? ^^
 * thumper remembers that babbageclunk is busy this morning
<thumper> wallyworld: ^^
<babbageclunk> thumper: sure - in 1:1?
<thumper> oh... you are here
<thumper> babbageclunk: I was pointing to the simple schema review
<thumper> I tried to use a schema.TimeDuration in controller config
<thumper> and the error message it gave was not overly helpful,
<thumper> so fixing the root problem
<babbageclunk> oh sorry, thought you were asking about a merge
<babbageclunk> -bot
<babbageclunk> ok taking a look
<thumper> nah, just the PR
<hpidcock> thumper: LGTM
<thumper> the duration was added by copying the time one
<thumper> unfortunately, I wrote the time one four years ago
<thumper> so I can't even really blame someone else for missing it
<thumper> thanks hpidcock
<babbageclunk> I also have approved it
 * thumper waits just in case babbageclunk has a question
<thumper> thanks
<babbageclunk> just in case
<thumper> all good
<babbageclunk> only comment was about the horrible formatting you fixed
<thumper> you mean gofmt fixed
<babbageclunk> Sure, your robot minion
<babbageclunk> sometimes I deliberately format code wrong so I can watch it fix it
<thumper> now I need to remember how to update the vendor shit
<babbageclunk> make rebuild-dependencies?
<thumper> anastasiamac: that is a bit of a burn
<babbageclunk> Oh but you need to add it to the toml file first
<thumper> yeah
<anastasiamac> thumper: https://discourse.jujucharms.com/t/juju-dependencies-managed-by-dep/139
<anastasiamac> thumper: haha u picked on that? :D
<thumper> anastasiamac: thanks, I think I remembered enough
<anastasiamac> \o/
<anastasiamac> that discourse post has instructions on how to bring/update deps for juju/juju
<anastasiamac> i refer to it when needed - less to remember :D
 * thumper runs to the gym
<anastasiamac> wallyworld: PTAL https://github.com/juju/juju/pull/10523
<wallyworld> ok
#juju 2019-08-15
<babbageclunk> timClicks: could you review this plz? https://github.com/juju/juju/pull/10524
<anastasiamac> a review plz   https://github.com/juju/juju/pull/10526
<anastasiamac> wallyworld: ^^
<hpidcock> review plz https://github.com/juju/juju/pull/10527
<thumper> wallyworld: https://bugs.launchpad.net/bugs/1839970 could use a comment
<mup> Bug #1839970: Unpredictable behaviour selecting Unit public IP address <juju:New> <https://launchpad.net/bugs/1839970>
<wallyworld> ok
<wallyworld> hpidcock: looking
<wallyworld> hpidcock: why not filter out the manual provider for kuku
<hpidcock> wallyworld: yeah good point, I was just considering that you should always be able to bootstrap manually
<hpidcock> I'll make the change
<wallyworld> awesome
<wallyworld> thumper: i don't have an answer off the top of my head for that network question, will have to go code diving
<thumper> it may be the public address shown in status
<wallyworld> there's logic used to categorise and select the "best" default public address
<wallyworld> somewhere
<wallyworld> hpidcock: another option is to always have manual *except* when just k8s provider is specified
<wallyworld> what's there will work though
<thumper> wallyworld: bug 1813025 was assigned to you back in jan
<mup> Bug #1813025: new pods do not run due to rbac issues? <juju:New for wallyworld> <https://launchpad.net/bugs/1813025>
<thumper> can you triage the bug?
<achilleasa> stickupkid: about that bundlechanges API call for the python bits... did we version it when we landed the cmr changes? I certainly haven't done so for the channel stuff... so I don't have a clean way to decide whether I need to skip the channel integration test or not
<stickupkid> achilleasa, so no, pythonlib is actually a head of juju CLI in this regard, but it should be fine
<stickupkid> CR anyone? https://github.com/juju/cmd/pull/67
<achilleasa> stickupkid: looking ^^^
<stickupkid> it's a nice and simple one
<achilleasa> stickupkid: quick question: how would the error on L629 be printed out?
<stickupkid> achilleasa, same as previous `super normal`
<achilleasa> but what about the "unrecognized command: " prefix?
<stickupkid> ah, d'ho
<stickupkid> will fix that now
<stickupkid> achilleasa, updated
<achilleasa> stickupkid: approved
<stickupkid> achilleasa, ta
<stickupkid> achilleasa, considering you did the previous PR check, mind if you do this one https://github.com/juju/juju/pull/10522
<achilleasa> stickupkid: sure thing
<achilleasa> stickupkid: can you take a look at https://github.com/juju/python-libjuju/pull/340 ?
<rick_h> stickupkid:  if you get a sec can you peek at https://discourse.jujucharms.com/t/lxd-woes/1928 please?
<stickupkid> achilleasa, which version of python are you using?
<stickupkid> achilleasa, i'm wondering why the type definitions https://github.com/juju/python-libjuju/pull/340/files#diff-66da3249a52dcd990fa827c60a5360caL665
<stickupkid> are missing
<achilleasa> stickupkid: 3.6.7
<stickupkid> who wants a horrid code review ? https://github.com/juju/juju/pull/10529
<rick_h> stickupkid:  I'd like to poke several people on those please
<stickupkid> rick_h, sending an email
<rick_h> stickupkid:  can you setup a juju-crew list and ask folks to go through
<rick_h> stickupkid:  +1
<magicaltrout> hello folks
<magicaltrout> anyone got any clue how this openstack-ingration charm is supposed to work?
<magicaltrout> or its requirements
<pmatulis> magicaltrout, that integrator charm in particular or integrator charms in general?
<magicaltrout> the openstack one pmatulis
<magicaltrout> i can't get it to work, so i'm trying to find out if its still how you do things
<magicaltrout> or if its retired and i'm just reading old docs
<pmatulis> magicaltrout, afaik, integrator charms are the way to go. what is not working? there should be something in the juju logs
<magicaltrout> i documented it here pmatulis https://discourse.jujucharms.com/t/what-are-the-requirements-for-this-openstack-integrator-charm/1932/2
<magicaltrout> cause when i test the examples they seem to generally just be broken
<pmatulis> magicaltrout, ohh. first issue looks like a storage class simply does not exist. so maybe something else you need to do (not openstack-itself related). i don't know about the 2nd issue
<rick_h> magicaltrout:  it's definitely not deprecated. We use it for CDK setup on OpenStack and we're doing that for customers/etc.
<rick_h> magicaltrout:  sounds like assumptions/etc that might need love. I'd suggest filing bugs (don't I always...) but it should be alive/well.
<magicaltrout> thanks rick_h pmatulis i'll dig more then. I don't know what it tries to do for loadbalancing i'll look at the code as itrs not dead
<magicaltrout> didn't want to go down a rabbit hole to be told there's a better/newer way :0
<rick_h> magicaltrout:  :) what? That never happens :P
<magicaltrout> hello pinocchio!
<rick_h> magicaltrout:  one of these days we should chat. long time no catch up
<rick_h> magicaltrout:  I'm not seeing anything in the charm doing loadbalancing
<magicaltrout> indeed rick_h ! I'm in the process of exfiltrating from 4 months of chaos and getting back to doing some charming stuff and upgrading the data charms.
<rick_h> magicaltrout:  and the charm readme just as kubectl notes vs anything charm/config
<magicaltrout> it just sets up kubernetes for the external loadbalancer
<rick_h> magicaltrout:  nice, congrats on getting through the tunnel
<magicaltrout> but i'm not entirely sure what its complaining about
<magicaltrout> as far as I can tell I filled in the details correctly, so I'm assuming something isn't configured on the openstack side
<dannf> i'm trying to use juju as a testing backend for different ubuntu releases - unfortunately i'm finding that i can't e.g. test 19.04 because no tools are available. is there a workaround for that?
<timClicks> dannf: you can force which series you're deploying
<dannf> timClicks: yeah, i can force it, and that appears to override charm restrictions, but then i get:
<dannf> Machine  State  DNS  Inst id  Series  AZ  Message
<dannf> 0        down        pending  disco       no matching agent binaries available
<timClicks> hrm that's strange .... just a second, I'll check something
<timClicks> dannf: which juju version are you running?
<dannf> 2.3.7-xenial-amd64
 * thumper cringes
<dannf> should i switch to the snap?
<thumper> dannf: can you use the juju snap?
<thumper> yeah
 * dannf honestly thought i was using the snap until you asked :)
 * timClicks is glad I did
<timClicks> (ask about the version, anyway!)
<babbageclunk> timClicks: did you work out what was happening with the extendDisks failing? I've got the cleanup sorted. (Getting the tests right was the fiddly bit as usual.)
<babbageclunk> timClicks: well, that and my machine forgetting it could boot to linux
<timClicks> babbageclunk: no, I wasn't able to diagnose what the issue was
<babbageclunk> timClicks: can you take a look at this anyway? https://github.com/juju/juju/pull/10530
<timClicks> oh sure :)
<babbageclunk> timClicks: I'm just testing it out now - will try reproducing the thing you saw anyway
#juju 2019-08-16
<babbageclunk> timClicks: I just saw the missing VMDK issue again. :(
<timClicks> !
<babbageclunk> it was after I removed some applications from a model (which removed some machines) so I'm going to see if that's the cause.
<wallyworld> anastasiamac: sorry about delay, +1 on pr
<wallyworld> kelvinli_: there's definitely something amis with the 2.6 ci runs not being triggered
<wallyworld> i'll have to kick off another by hand
<kelvinli_> wallyworld: ok, i will have a look
<timClicks> am in the process of rewriting our project's README.. if you would like to take a look at where I've got to, you're welcome to preview the draft here https://github.com/timClicks/juju/tree/develop-docs--readme-upgrade
<stickupkid> manadart, can you come up with a suggestion to the ports one, so i can look at other comments in ineffassign branch - pretty please :D
<parlos> Good Morning!
<stickupkid> morning parlos
<parlos> Is it possible to add an 'endpoint' to an already deployed application? Im testing something, and I've deployed a 'ubuntu', application (juju deploy ubuntu). Now I want to a proxy to forward traffic to port 80 on the device.
<manadart> stickupkid: Didn't I put the suggestion there?
<stickupkid> manadart, dunno, there are A LOT of comments, just wading through
<stickupkid> manadart,  if you did, ta
<manadart> stickupkid: Any chance you can QA https://github.com/juju/juju/pull/10520 today?
<manadart> Got an approval based on code review from hml already.
<stickupkid> manadart, any chance england can win today?
<stickupkid> manadart, of course, give me a sec
<manadart> stickupkid: Hopefully it dries out and goes flat as a road before breaking up on day 4/5 :)
<stickupkid> haha
<stickupkid> i wish
<rick_h> parlos:  you have to add support for that on the charm. You can run it via juju run "open-port 80" and then expose it I think, but it's kind of hacky
<rick_h> stickupkid:  hah sorry, I asked in the team meeting for everyone to go through as much as possible
<rick_h> stickupkid:  cause I know you love comments so much!
<parlos> rick_h thanks for the info, it was just for proof-of-concept. Gave up, and took a different path.
<rick_h> parlos:  ok
<rick_h> parlos:  so the key to the port opening is going to be the open-port hook tool and then exposing an application. Normally it's baked into the charm's hooks, but you can juju run stuff in a hook context for hacky purposes
<parlos> rick_h; so I was using two charms, gitlab and and and ssl proxy. The gitlab deployed version 9.x something. So, I deployed a clean ubuntu, and placed the new 12.1 version on it. Then I wanted to point the proxy to the service/app on the new host, and there was the problem..
<rick_h> parlos:  I see, yea that needs to be done more officialy with relations/etc working right
<parlos> rick_h; so solution, find another charm of gitlab, and then change the version that it deployed (as that version supported taht)
<rick_h> yep, sounds about right :)
<parlos> Have a nice day!
<magicaltrout> i'm assuming the answer is no but can you not run-action on every unit?
<aisrael> Has anyone run into "ERROR: Cannot uninstall 'PyYAML'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall." while deploying a (reactive) charm?
<aisrael> in the install hook
<stickupkid> anyone want to CR this one https://github.com/juju/juju/pull/10508
#juju 2019-08-18
<Routhinator> Based on the messaging in #conjure-up I'll ask here: Hi folks, wondering if it's possible to use conjure-up against SSH targets, or if the localhost mode of kubernetes-core can do two baremetal machines for a dev cluster? I'm getting the idea that it's going to setup two LXD nodes on the baremetal box.. while that might not be bad (I guess I could
<Routhinator> have two nodes on each baremetal box) I kinda wanted to give kube 100% of the resources of each baremetal host.
#juju 2020-08-10
<wallyworld> _thumper_: one for the road if you have a moment https://github.com/juju/juju/pull/11885
 * thumper looks
<sou> Hey good people, I am trying to understand different ways of scaling an openstack compute cluster. I know that we can scale a compute cluster by adding number of units. For example using the below command will add
<sou> 2 compute units: juju add-unit -n2 nova-compute
<sou> But I was wondering if there is any way I can scale the cluster by just running : juju deploy habundle.yml
<sou> habundle.yml has details about 3 machines with constraint "tag=compute"
<sou> machines:  '0':    series: bionic    constraints: tags=controller  '1':    series: bionic    constraints: tags=controller  '2':    series: bionic    constraints: tags=controller  '3':    series: bionic    constraints: tags=compute  '4':    series: bionic    constraints: tags=compute  '5':    series: bionic    constraints: tags=compute
<sou> Without modifying habundle.yml, is it possible to scale?
<sou> I want to add 4th compute machine
<sou> My nova-compute application looks like this
<sou>   nova-compute:    charm: cs:nova-compute-302    num_units: 3    options:      cpu-mode: custom      cpu-model: kvm64      config-flags: default_ephemeral_format=ext4,instance_name_template=%(hostname)s      enable-live-migration: true      enable-resize: true      migration-auth-type: ssh      virt-type: kvm      encrypt: true
<sou> ephemeral-device: /dev/bcache2      openstack-origin: cloud:bionic-stein      flat-interface: eno6      libvirt-image-backend: raw      resume-guests-state-on-host-boot: True      worker-multiplier: 0.015    to:    - '3'    - '4'    - '5'
<sou> Appreciate any tips
<wallyworld> sou: the scale is defined in the bundle yaml as num_units, so you need to change that to 4 if you want to reapply the bundle to scale up
<sou> Thanks a lot wallyworld. This would mean each time I want to scale the cluster I will have to update ha_bundle.yml. Do you think by using constraints here would work. For example:
<sou> nova-compute:    charm: cs:nova-compute-302    num_units: 3,new constraints: tag=compute ...
<sou> I am trying to understand if I can achieve scaling by having a generic bundle.yml, which would take care of any new machines with tag=compute
<wallyworld> constraints are used to help define on what node a unit should be placed when a unit  needs to be deployed somewhere, rather than the concept of "fill all machines that have this tag with a unit". juju provides the add-unit primitive to enable workloads to be scaled up or down. but it doesn't do things automatically like you are wanting to do. the idea is that folks that need bespoke scaling behaviour can write scripts to do it
<wallyworld>  using the juju primitives
<sou> Perfect. Thanks wallyworld for the insight!!
<wallyworld> no problem
<stickupkid> manadart_, achilleasa https://github.com/juju/charm/pull/312
<stickupkid> One thing I really need to work out, if I do update all the charm urls, then uniters will notice a change I'm guess and force a charm update
<stickupkid> *guessing
<achilleasa> can I get a review on https://github.com/juju/juju/pull/11887?
<achilleasa> stickupkid: can you take a look at https://github.com/juju/juju/pull/11889?
<stickupkid> achilleasa, done
<achilleasa> hml: can you take a look at this small PR? https://github.com/juju/juju/pull/11890
<hml> achilleasa:  sure, will start in 30 or so
<stickupkid> hml, also CR for this one https://github.com/juju/juju/pull/11888
<hml> stickupkid: adding to the queue.  ;-)
<hml> stickupkid: you have a compile fail on the test run
<achilleasa> stickupkid: looks like that echo -e was needed... it doesn't expand line-feeds otherwise ;-(
<achilleasa> I will put it in the develop path and in my removejujuservices one that is pending review for 2.8
<hml> achilleasa: one suggestion and a tic
<achilleasa> hml: nice catch
<achilleasa> hml: updated the PR; looks OK now? (I added one extra commit for adding a -e to the test-runner changes that I missed in my other PR)
<hml> achilleasa:  approved
<stickupkid> hml, nice, we don't need a charm URL upgrade step for https/http v2 charm URLs, it's impossible to get the old version in state even if it's written to mongo somehow
<hml> stickupkid: ha
#juju 2020-08-11
<thumper> https://github.com/juju/juju/pull/11893 adds ability to introspect the leases on the controllers
<thumper> wallyworld: ^^
<thumper> or anyone really
<wallyworld> thumper: sorry, ffs, missed ping, done
<jam> morning all
<hpidcock> @jam morning
<jam> I like how mattermost characters leak into IRC :)
<hpidcock> jam: haha yeah. I have blended everything into one client.
<jam> I'm guilty of it as well. I start typing names in mattermost and wonder why they aren't completing
<manadart_> stickupkid: This is the fix for AWS constraints/bindings: https://github.com/juju/juju/pull/11886
<stickupkid> manadart_, nice, will jump on that soon
<achilleasa> manadart_: stickupkid quick poll. I am moving the IngressRule type to core/network and tweaking the code (e.g. use set.Strings for src CIDRS). When you get (or print) the src CIDRs do you think that I should list the _effective_ source CIDRs or the actual CIDRs?
<stickupkid> actual
<manadart_> achilleasa: Actual.
<achilleasa> in other words: if I have 192.168.0.0/24 and then add 192.168.0.0/16 does this yield the latter (as it is a superset)
<achilleasa> or both?
<stickupkid> achilleasa, for print, get, it should return actual
<stickupkid> achilleasa, also you could make a new type that allow you to get both
<stickupkid> achilleasa, also I wonder if we should specialise the CIDR, so the type isn't a string in core/network?
<achilleasa> cool. I am too lazy to implement it for printing only. There is some code that merges CIDRs to reduce the number of ingress rules so I might add this functionality via a method once I get there
<stickupkid> achilleasa, manadart_ I worry about the overuse of strings and set.Strings
<achilleasa> Ideally that should be a *net.IPNet but ... mongo
<achilleasa> subnets, spaces... all those bits work with string CIDRs
<stickupkid> achilleasa, fair, although `type CIDR *net.IPNet` and hang everything off CIDR
<stickupkid> achilleasa, you can then implement SetBSON (*sick* inside!)
<achilleasa> yeah... but then you have to parse CIDRs early on (could be problematic for tests)
<stickupkid> achilleasa, sure, sure, agree with you
<achilleasa> ha! can't override SetBSON for type aliases I think
<achilleasa> (or other methods)
<stickupkid> not sure, maybe
<achilleasa> or is that only for existing methods?
<stickupkid> existing ones I'm sure of it
<achilleasa> yeah... not sure if the restriction extends to other methods
<achilleasa> I will check later :D
<stickupkid> manadart_, tick
<manadart_> stickupkid: Cheers.
<manadart_> stickupkid: Quick HO?
<stickupkid> sure
<b1juj> Hi, I'm having problems setting up gnocchi and ceilometer with juju. Gnocchi has been in waiting state for >12hrs with messages "'shared-db' incomplete" and "'db-router' incomplete, Waiting for proxied DB creation from cluster". Ceilometer is in blocked state with message "Incomplete relations: database, Run the ceilometer-upgrade action on the leader to initialize ceilometer and gnocchi". I have tried running the
<b1juj> ceilometer-upgrade action but it fails with message "The identity-credentials and or metric-service relations are not complete.
<b1juj>   ceilometer-upgrade cannot be run until they are ready."
<stickupkid> achilleasa, HO?
<achilleasa> stickupkid: omw
<achilleasa> manadart_: https://github.com/juju/juju/pull/11896
<stickupkid> hml, also you left this as a comment and not approved :) https://github.com/juju/juju/pull/11888
<hml> stickupkid: i didâ¦ need to qa
<hml> iâll merge if qa is good
<stickupkid> hml, ta
<hml> achilleasa:  the hook context read the charm state data, no the unit state data.  is that the context you were refering too?
<achilleasa> hml: the uniter has its own state plus a state for each relation (there is a thing in the relation package that reads that from disk). I thought the latter was read at context creation time but I could very possibly be wrong and it could get cached at start time
<hml> achilleasa:  I couldnât find it
<achilleasa> it was that weird map struct
<achilleasa> one sec
<achilleasa> hml: https://github.com/juju/juju/blob/2.7/worker/uniter/relation/relationer.go#L92
<achilleasa> it's the one from 2.7 which gets replaced in 2.8 with the stuff we added
<achilleasa> I think L96 reads from disk
<achilleasa> also the CommitHook method just after that writes to disk
<hml> achilleasa:  i was thinking context, as in running hook contexts
<hml> yes, data is read at preparehook
<achilleasa> hml: ah... I meant the hook contest (runner/context/context.go)
<achilleasa> so if we upgrade (+migrate), then a hook fires before the agent restarts... boom?
<hml> achilleasa:  okay, so same context then.  i guess i was thinking literally, not in prehook
<hml> achilleasa:  that could be it
<hml> achilleasa:  moving the upgrade step to the unit will take care of that
<hml> achilleasa:  PrepareHook  calls State() which makes a copy of whatâs there already then Validate() is called.  Data is read when NewRelations is called.  And when NextHook is called, part of update().  so just different location.
#juju 2020-08-12
<moon127> my
<moon127> bah wrong window
<manadart_> stickupkid, achilleasa: Manual provider incremental subnet discovery: https://github.com/juju/juju/pull/11899
<achilleasa> manadart_: or stickupkid got a massive PR with mostly mechanical refactoring changes (though it's a net -6 LOC). Can either of you take a look? https://github.com/juju/juju/pull/11900
<manadart_> achilleasa: Yep.
<achilleasa> manadart_: ooh nice. I need that for the firewall stuff
<stickupkid> hml, charmhub URL PR - https://github.com/juju/charm/pull/313
<hml> stickupkid: ack
<stickupkid> hml, we need to tag this as v8 before we land, as this contains a breaking change
<hml> stickupkid:  is that how branching works there?  did we change it?  i see v6, v5 etc branches
<stickupkid> hml, see tags
<hml> stickupkid:ack
<stickupkid> hml, we'll have to make a 7 branch, so that we can always update the 7 tag in the future
#juju 2020-08-13
<jam> manadart_, do you have write access to Thumper's grafana? I do, but we should make sure several people can see the details.
<manadart_> jam: I assume I don't; none of the menus allow me to change anything.
<jam> manadart_, you have to "sign in" from the little icon on the bottom left.
<achilleasa> interestingly, the firewall worker has a per-machine watcher for the units, a per-application watcher etc. Any ideas why that is the case instead of watching all units, applications etc?
<stickupkid> achilleasa, can only think of granularity
<stickupkid> achilleasa, but even then it's a weak argument
<achilleasa> but in a large model...
<achilleasa> it's one watch loop (==goroutine) for each
<stickupkid> achilleasa, we totally could optimise for that
<stickupkid> achilleasa, yeah - hence my "weak argument"
<achilleasa> yeap... that's my plan
<achilleasa> because I need to also monitor spaces
<achilleasa> manadart_: ^^^ this means getting a SpaceInfos API method
 * stickupkid tries to make witty joke about manadart_ and a dentist
<achilleasa> stickupkid: we will have to drill the bits we need out of the API. Good enough? :D
<stickupkid> hahaha
<stickupkid> achilleasa, I'm unsure, it might be a painful extraction
<achilleasa> It will be painful, but I am pretty sure it will be the _crown_ of the refactoring process
<stickupkid> I think you're just _filling_ in the pieces here
<stickupkid> We might need to polish some methods and scale the requests to make it whiter than white
<achilleasa> But as you know, when you introduce new APIs you might get teething problems that need to be addressed, rough edges that you need to be extracted etc
<achilleasa> however working with FLOSS is fun
<achilleasa> stickupkid: there is much more room for optimization it seems.... e.g here(https://github.com/juju/juju/blob/develop/worker/firewaller/firewaller.go#L545-L564) we grab instance details for each machine in the model. However, the Instances method now (after the instancepoller changes) accepts a slice of instance.Id
<achilleasa> soo 500 machines -> 500 API calls to the provider + 500 calls to grab the ingress rules (if we are using instance fw)
<achilleasa> (although the latter calls might be already cached in the instance data depending on the provider)
<stickupkid> nice and fast - lol
 * achilleasa senses another long PR description coming up...
<hml> stickupkid: https://github.com/juju/juju/pull/11901
<hml> i have to look at static anaylsis and i think there are a couple of tests which need fixing. but can start on the review
<hml> rebasing to your change was interesting.  i think i got it right
<hml> stickupkid: approved 313
<hml> fix for intermittent unit test failure, review please:  https://github.com/juju/juju/pull/11903
<hml> achilleasa, stickupkid, manadart_ ^^
<hml> review please https://github.com/juju/juju/pull/11904
<achilleasa> hml: looking at 11904; ticked 11903
<hml> achilleasa:  ty
<achilleasa> btw, was the ports one caused by my refactoring changes? I wonder whether I missed a sort call somewhere
<achilleasa> hml: left some comments
<hml> achilleasa:  reading, ty
<hml> achilleasa:  on the ports thing, is order important?  i was wondering, but itâs also a very old test
<hml> achilleasa:  updated 11904
#juju 2020-08-14
<achilleasa> manadart_: stickupkid when deploying a unit, we create documents for the machine and the unit. If I am watching (separately) the machines and units, is there a guarantee that I will get the machine change before the unit change?
<stickupkid> achilleasa, I'd say without doubt no
<achilleasa> that's unfortunate :-(
<bdx> manadart_: https://bugs.launchpad.net/juju/+bug/1881431
<mup> Bug #1881431: bootstrap not respecting subnet assignment <juju:Fix Released by simonrichardson> <https://launchpad.net/bugs/1881431>
<manadart_> bdx: Thanks.
<stickupkid> hml, so the deploy only fails with that machine lxd profile
<stickupkid> hml, I'm go and test more stuff for the rest of the day
<hml> stickupkid: rgr
<stickupkid> hml, all the integration tests pass, except for that one which is weird
<hml> hrm
<hml> manadart_: I checked out 11188 on the openstack network open ports.  it kicks out if there are no spaces in the constraints.  if you list a space as a contstraint you must specify a network.  otherwise no such requirment
<hml> stickupkid: which profile test in deploy integration test is failing for you?
<stickupkid> hml, ===> [ x ] Fail: deploy lxd to machine (103s)
<hml> stickupkid:  ===> [ â ] Success: deploy lxd to machine (73s)
<stickupkid> wat
<hml> unless i forgot to run make install or something
<stickupkid> let me test again
<stickupkid> hml happens again for me
<hml> hrm
<stickupkid> try and pad out the wait time
<hml> stickupkid: my deploys are really slow.  takes a long time to download images for the containers in machines
<hml> like is something wrong with my network slow
<stickupkid> hml, never mind
<stickupkid> sigh
<stickupkid> i've already got the sodding profile in my profiles, it wasn't deleted from a borked test
<hml> stickupkid: oops
<hml> stickupkid: i just got a fail on bundles deploy
<stickupkid> did you, i got ok'd everything for me
<stickupkid> I'm going to test more monday if you don't mind
<stickupkid> deploy is massive
<hml> it might have been cmr-bundles-deploy
