#juju 2013-09-02
<jamespage> adam_g, https://code.launchpad.net/~james-page/charm-helpers/cloud-source-improvements/+merge/183404
<X-warrior> is there a bug with juju logging?
<X-warrior> I just saw my bootstrap machine logging increase a lot. Even if I'm not creating anything new, or updating, or using juju commands...
<X-warrior> and if I use 'cat /var/log/juju/all-machines.log  | grep postgresql-9.1' I see the same message repeated a lot of times
<X-warrior> PS: I deployed the postgresql to bootstrap machine
<X-warrior> The all-machines log keep increasing, but the machine-0, postgresql-0-debug, unit-postgresql-0 don't increase.
<sidnei> hey jamespage, i wasn't around friday. any issue with the juju-deployer backport?
<jamespage> sidnei, nah - I was surprised when all my backports got rejected - as you had already done them :-)
<jamespage> sidnei, one minor thing - I've been backporting to the stable PPA with a ~juju1 suffix
<jamespage> but that a nit
<sidnei> jamespage: yeah, i only noticed afterwards. will tack a -S on backportpackage next time :)
<jamespage> sidnei, great - thanks!
<jamespage> sidnei, I'll try to do them as soon as I upload stabled to the Ubuntu release
<AskUbuntu> juju ceph deployment | http://askubuntu.com/q/340465
<kurt__> Before I file a bug, is it a known issue with the inability to destroy service in 1.12 with status showing stuck in "life: dying" ?
<X-warrior`> If I would like to add a new hook to already deployed service, how could I add it? Just update metadata.yaml file on /var/lib/juju and the hooks folder as well? It doesn't seem to work. It complains 'no relation found'
<X-warrior`> have to go out for a while, later!
#juju 2013-09-03
<jamespage> adam_g, if you are in today - https://code.launchpad.net/~james-page/charms/precise/keystone/fix-requested-roles/+merge/183580
<jamespage> that's the cause of the openstack-dashboard lack of member role stuff that jpds hit last week
<jamespage> they are not using swift and the keystone identity-changed hook was not creating the role for services not registering endpoints....
<raywang> helle jamespage
<marcoceppi> kurt__: Is the unit in a dying state? RE: Before I file a bug, is it a known issue with the inability to destroy service in 1.12 with status showing stuck in "life: dying" ?
<marcoceppi> hazmat: pong
<kurt__> hi marcoceppi: I did file bug.  Sorry have to run
<marcoceppi> kurt__: no worries
<marcoceppi> kurt__: is the unit in an error state* is what I meant to ask
<kurt__> I think so, yes
<marcoceppi> kurt__: cool, next time you want to kill them off, just run `juju resolved <unit-in-errror-that's-dying>` a few times
<marcoceppi> this is expected behaviour of juju
<X-warrior> If I'm receiving relation not found, when adding a relation between 2 charms. It means that the metadata from both doesn't match?
<marcoceppi> X-warrior: Is this in regards to your editing the metadata.yaml file after deployment?
<jcastro> jamespage: http://askubuntu.com/questions/340465/juju-ceph-deployment
<jamespage> jcastro, posted
<jamespage> its a bitch
<jamespage> second hit in three days on that one
<jcastro> nice!
<jcastro> jamespage: where else? should I post it somewhere?
<jamespage> jcastro, raywang pinged me about it as well
<jamespage> thats where I raised that bug from
 * jcastro nods
<jamespage> I pulled back the point release to ensure it got included
<X-warrior`> marcoceppi: yes, I created a service but I forgot to add a 'relation joined' on it to provide the service address
<hazmat> marcoceppi, pong
<marcoceppi> hazmat: hey, just got your ping from a day ago
<marcoceppi> 2 days*
<hazmat> hmm.. that thought is paged to disk
<hazmat> oh..
<hazmat> marcoceppi, i was wondering about getting juju-plugins up to snuff
<marcoceppi> hazmat: sure
<hazmat> i'm currently tossing tangentially related plugins into deployer
<hazmat> but some are not.. and i'm wondering if we should fold everything into something like juju-plugins
<marcoceppi> hazmat: I've got juju-plugins already, it's really light weight, but I'm happy to beef it up in terms of adding more plugins to it
<hazmat> some of the packaging dependencies might increase though depending on the plugin
<marcoceppi> hazmat: I was considering doing a package per plugin, with a "juju-plugins-all" package to install all plugins
<hazmat> marcoceppi, the juju-faststat plugin for example from the ml.. is a nice speed focused status replacement for the moment.
<marcoceppi> hazmat: just to keep the list of dependencies down for single plugins
<hazmat> marcoceppi, package per plugin sounds bad..
<hazmat> er. overkill
<marcoceppi> hazmat: okay
<marcoceppi> well if
<marcoceppi> well it's a trade off then, lots of deps, or bunch 'o packages
<marcoceppi> I'm fine either way, whichever convention makes the most sense
<marcoceppi> hazmat: right now they're just all in one package
<marcoceppi> so we can just keep it that way
<X-warrior`> this is my 2 metadata.yaml ( http://pastebin.com/KbXLkQ4K ), if I would like to add a relation from service to authserver, where authserver will provide it ip address ... does the authserver needs a hooks/authserver-relation-joined and the service needs a hook hooks/authserver-relation-changed. And the commmand should be 'juju add-relation authserver service'
<marcoceppi> X-warrior`: Pretty much, you can get the IP address of a current running unit with `unit-get private-address` so your hooks/authserver-relation-joined hook would look like `relation set hostname=$(unit-get private-address)` and the authserver-relation-changed on the other service would havethe following `relation-get hostname` to recieve that value
<marcoceppi> X-warrior`: however, unless it truely implements the HTTP protocol (which requires both a port and hostname to be set) I'd recommend naming the interface something different
<marcoceppi> using the HTTP interface tells juju that your authserver could work with haproxy, varnish, etc. If that's not the case you'll want to use a different interface name
<marcoceppi> If that is the case you'll want to make sure you set both the hostname and the port options in the relation-set command
<marcoceppi> likewise, your service charm requring the http interface means it could connect to wordpress, mediawiki, and a majority of other charms and be able to handle that data properly. So, if that isn't the case, you'll want to do what I recommended above and create a new interface name (or find an existing interface that matches what you're trying to do)
<marcoceppi> Since the interface name is what juju uses to match charms with each other
<X-warrior`> marcoceppi: could I name it with any name as I want?
<marcoceppi> X-warrior`: yup! Anything that makes sense to what that interface is for
<marcoceppi> X-warrior`: so you could call it "authserver" as the interface, then the first metadata.yaml relation name could be server and the second one's relation name could client
<marcoceppi> X-warrior`: interface could be authserver for both, but you could name the relations in a way that makese sense of what the role of the relation is to the charm
 * marcoceppi creates an example paste
<marcoceppi> X-warrior`: http://pastebin.com/iUVJb6Fk
<marcoceppi> X-warrior`: I wouldn't use such a generic name as "authserver", unless you can make the interface generic, If it's a particular authentication softare, like ldap, I'd name the interface ldap or something similar
<marcoceppi> X-warrior`: the interface should embody exactly it's purpose. So we have generic interfaces, like http, and specific ones, like mysql or pgsql
<marcoceppi> X-warrior`: while the name is up to you, we do prefer people to name them wisely, at least for the store.
<marcoceppi> If these are just for you, you can do whatever
<marcoceppi> FOr the store we'd prefer it to be more specific, but again it's up to you
<X-warrior`> for now I'm just running more tests to understand how it works
<X-warrior`> but I know what you mean
<X-warrior`> :D
<X-warrior`> marcoceppi: the test worked destroying the machines and redeploying...
<marcoceppi> X-warrior`: sweet!
<X-warrior`> ty
<X-warrior`> :D
<X-warrior`> What does the 'IDEMPOTENCY' means? I mean, let's say I have a hook to a db relation changed... and this hook add the options (login, pass, dbname, etc) to a file... if it is idempotent the login, pass, dbname will not be updated. So I'm not sure I understand what does the "# IDEMPOTENCY is very important in all charm hooks, even the install hook. " means from https://juju.ubuntu.com/docs/authors-charm-writing.html
<jrwren> it means it can run again with the same result.
<jrwren> where same result means it doesn't hurt either.
<jrwren> so I can run it 100 times and everything is still good. I don't have things like messed up config with 100 screwed up lines.
<jrwren> of course that is my bad interpretation of what it means. It has a much nicer computer science definition which you are free to google.
<X-warrior`> well the definition means it will be exactly the same.
<X-warrior`> But on a relation-changed event... if you do it, it will preserve the values that was there before it calls the hook... so it doesn't make sense to me
<X-warrior`> le
<marcoceppi> X-warrior`: idempotency means with the same set of parameters, the hook will produce the same results
<X-warrior`> marcoceppi: ty
<m_3> bbcmicrocomputer: please mark reviews in progress when you start them this week
<m_3> so we won't step on each others toes
<jcastro> fwereade: heya
<jcastro> or jam
<bbcmicrocomputer> m_3: ok, sure
<mrsolo> hi where does juju store ssh private-key?
<mrsolo> nm got it
<fwereade_> jcastro, heyhey
<jcastro> fwereade_: hey so I was wondering when we can default to the local provider
<jcastro> but I think we can do that at the distro level instead of upstream?
 * jcastro needs to ask jamespage
<fwereade_> jcastro, to be fair, I should not be trusted with anything distro-related
<jcastro> fair enough ... James Page it is!
<jamespage> jcastro, ?
<jcastro> jamespage: hey so I was thinking, we should default to local in juju in the distro
<jcastro> instead of "amazon"
<jcastro> so when someone apt-get install's juju
<jcastro> they can deploy right away without anything else
<jamespage> jcastro, is that not driven by their environments.yaml?
<jcastro> it is
<jcastro> but by default right now it's "amazon"
<jamespage> ah
<jamespage> hmm
<jcastro> jamespage: also, out of curiosity .. do we need all 61MBs of mongodb-clients?
<jcastro> seems like a rather heavy dep ...
<jamespage> jcastro, yeah - that does suck
<jamespage> I'll take a look
<jamespage> juju generate-config generates environments.yaml tho
<jamespage> jcastro: so I think thats a change in juju-core right?
<jamespage> we can Recommend: juju-local from juju which means by default you get the local provider
<jcastro> ok
<jcastro> I was unsure if this would be an upstream thing or a distro thing, the choosing of a default
<jcastro> I think I'll just ping thumper when he comes online and ask him to do it
<jamespage> jcastro, ack
<jam> jamespage: recommending juju-local means that by default you end up with a mongodb-server running on your local machine (even before "juju bootstrap") because of how the mongodb-server package works
<jam> which I *think* defaults to 3GB prealloc
<jamespage> jam: yep
<jamespage> ouch
<jamespage> OK - I won't do that
<jamespage> jcastro, that makes making local the default tricky
 * jcastro nods
<jam> jamespage: I'm not positive about the 3GB prealloc, but I am sure that you end up with mongodb running on a port nobody will connect to.
<jcastro> hey so could we do it so if you install juju by itself
<jcastro> it does what it does now
<jamespage> jam: that rings a bell - I had issues with the DEP-8 tests I wrote because it won't start on a 2GB root
<jcastro> but if you install juju-local we do the right thing to make it spin up local with no config other than installing the package?
<jam> jamespage: I know you can configure with or without prealloc, I'm just not sure what the .deb default is today.
<jamespage> realloc
<jamespage> prealloc rather
<jamespage> jcastro, you still get a mongodb-server running in the background that no-one is actually using...
 * jcastro nods
<jcastro> ah nuts ... :-/
<jamespage> jcastro, if we had thought about this a bit harder I'd have split the binary into a monogodb-server-common package
<jamespage> and then just install the init script in the mongodb-server package
<jcastro> jamespage: so it's probably better to leave that an explicit decision by the user then?
<jamespage> jcastro, I think so yes
<jcastro> jamespage: is that something we can do post-13.10 bute pre-14.04 you think?
<jamespage> yes
<jcastro> ok .... /me PUNTS the ball
<jam> jamespage: it would be nice that if you "apt-get install juju-local" you would end up with an environments.yaml that points to local
<jamespage> jam: that involves a package manipulating user data != no go
<jam> jcastro: I think there is a bug about switching to local by default because we know you have those creds. And if bootstrap doesn't work we could tell you about the apt-get juju-local package.
<jam> jamespage: I did say "would be nice" but even if "juju init" does that bit
<jcastro> I remember filing a bug with thumper @ IOM, but I haven't been able to find it all day
<jackweirdy> Hey all; I'm entering the charm championship and I'm having trouble with Juju - I'm running 13.04 on the stable juju ppa. I'm running kvm and I was wondering if I could configure an environment to spin up a new VM in KVM when I run juju deploy? I've found docs for stuff like OpenStack, but that's a bit heavyweight for what I want :)
<jackweirdy> (unless it's not? I'm new to all this so I may have the wrong end of the stick :) )
<jackweirdy> Googling suggests this isn't possible :s Can I add custom environment handlers?
<jam> jackweirdy: juju has support for LVM containers, we haven't yet implemented KVM support
<jam> you can install "juju-local" from the ppa, and then set up a "local" environment.
<jackweirdy> Ok; thanks anyhow :)
<jackweirdy> Does the local environment use lxc?
<sinzui> Hi charmers, login to manage.jujucharms.com is broken at the moment. Those already logged in can feature and QA charms. We expect a fix in a few hours
<adam_g> hazmat, darwin merged to lp:juju-deployer
<xnox> jam: LVM is a type of volume/disk storage, it's not a container....
<xnox> jackweirdy: yeap local environment uses lxc.
<thumper> morning
<bac> hi thumper
#juju 2013-09-04
<melmoth> with juju-core, with openstack environment, how can i set a constraints on a flavor when i deploy stuff ?
<melmoth> looks like i can use mem= to pick at least a given amount of ram (wich will end up with the flavor i want), but i m wondering if there are plan to have a proper flavor constraint.
<raywang> hello jamespage
<_mup_> Bug #1220625 was filed: juju unset command does not appear in help  <juju:New> <https://launchpad.net/bugs/1220625>
<hatch> Hey all - I'm trying to figure out the syntax and location of relation errors from juju-core, can anyone point me in the right direction?
<hatch> fwereade_, ^
<fwereade_> hatch, sorry, expand please? there's no relation-specific error state
<fwereade_> hatch, if a relation hook fails you shoul dbe able t see which hook failed in status
<hatch> fwereade_, sure thanks, I am attempting to implement relation errors in the GUI converting from PyJuju to core
<hatch> but I can't find where that is returned to the GUI or the format
<hatch> frankban, and I searched around the source for a while but came up empty :)
<frankban> fwereade_: do you mean the unit's StatusInfo?
<fwereade_> frankban, hatch, that's what is currently available
<hatch> fwereade_, so if there is a relation-hook failure will I only get a status "failed: hook-name-goes-here" ?
<fwereade_> hatch, yeah
<hatch> darn...
<hatch> fwereade_, ok thanks a lot for your help - will have to take a new approach
<fwereade_> hatch, I'm still in a meeting but I'd like to talk about this in 5 mins if that's ok?
<hatch> yeah definitely just ping and we can have a hangout - I'm on London time this week
<rs0man> hi
<rs0man> what happens here?
<arosales> Weekly Charm Sync starting in  few minutes.
<arosales> G+, if you would like to join us: https://plus.google.com/hangouts/_/94201cea7de4619525241af73102ba009b3d46f7?authuser=0&hl=en
<arosales> Notes are at: http://pad.ubuntu.com/7mf2jvKXNa
<marcoceppi> http://ubuntuonair.com
<mattyw> jcastro, have I missed the charmers hangout?
<evilnickveitch> mattyw, still going on
<evilnickveitch> https://plus.google.com/hangouts/_/94201cea7de4619525241af73102ba009b3d46f7?authuser=0&hl=en
<mattyw> evilnickveitch, ok cool, thanks
<m_3> jcastro: https://bugs.launchpad.net/juju-core/+bug/1220816
<_mup_> Bug #1220816: add bind-home options to local provider <juju-core:New> <https://launchpad.net/bugs/1220816>
<marcoceppi> arosales: https://jujucharms.com/~marcoceppi/precise/vanilla-HEAD/
<marcoceppi> mattyw: ^
<mattyw> marcoceppi, thanks
<X-warrior> does the configs are available to any hook?
<m_3> jcastro: hmmmm... `juju deploy --constraints "bind=/home/mmm:/home/ubuntu"` would rock if that would work
<m_3> X-warrior: yes, when using initial config
<m_3> X-warrior: the only hook called when you do a `juju set ...` is hooks/config-changed
<m_3> X-warrior: but any hooks called _after_ that will have the latest set of config
<arosales> mattyw, http://pad.ubuntu.com/7mf2jvKXNa
<X-warrior> does the set-config safe? I mean, could I randonly generate a password and save using set-config for later use?
<marcoceppi> X-warrior: you can't set-config from a charm
<marcoceppi> Charms can't set configuration, only read configuration
<X-warrior> ah ok
<marcoceppi> X-warrior: if you want to generate a password, just save it to $CHARM_DIR/.password or something
<marcoceppi> X-warrior: then you could `cat $CHARM_DIR/.password` at a later hook to read it in
<marcoceppi> then just tell users, if they need the password, where to get it
<X-warrior> ok
<X-warrior> :D
<X-warrior> ty
<jcastro> m_3: can you file that home mount as a bug and then CC me the bug #?
<arosales> marcoceppi, jcastro, m_3, evilnickveitch, utlemming: quick internal charm sync
<arosales> around netflix charming
<m_3> jcastro: in backchannel
<m_3> jcastro: https://bugs.launchpad.net/juju-core/+bug/1220816
<_mup_> Bug #1220816: add bind-home options to local provider <juju-core:New> <https://launchpad.net/bugs/1220816>
<kentb> I deployed the juju-gui charm to one of my machines.  It sort of works, but it's really slow to come up and ultimately I get a "Failed to load editorial content" error and I'm missing a lot of icons and no charms show up.  Any ideas on what to check?
<sidnei> benji: ^ maybe you can help?
 * benji reads.
<benji> kentb: are you running behind a firewall that does egress filtering?
<kentb> benji: yep. just found it...pointed to the proxy I needed to get to and all seems to work now.  Thanks!
<benji> cool
<X-warrior> my install hook failed, now I'm using juju resolved --retry service... and it says "error: cannot set resolved mode for unit "redis-test/0": already resolved" but juju status says the opposite. What could be wrong? I'm trying to start some python scripts on install using 'pyhton file.py &'
<X-warrior> or maybe I should move then to start...
<sidnei> X-warrior: uhm, i got into that state once but couldn't reproduce it, i wonder if it might be a bug
<sidnei> X-warrior: can you confirm from the logs that the previous run of install hook exited?
<sidnei> X-warrior: it might as well be stuck, eg if you apt-get install without DEB_FRONTEND=noninteractive set, waiting for input
<X-warrior> sidnei, nope... what I did was, execute python script.py (a script that doesn't finish) so it doesn't returned
<X-warrior> then I add a & on the end of command
<X-warrior> (this was inside install hook)
<X-warrior> and used resolved --retry
<X-warrior> and then it said it was already resolved...
<X-warrior> so I destroyed
<sarnold> do you need to nohup that thing? or does non-interactive shell do that for you?
<X-warrior> moved the python command to start hook
<X-warrior> with & option
<X-warrior> and it worked
<sidnei> X-warrior: ah, indeed. so the hook never finished, when you set resolved it gets recorded as such, but the retry is queued up waiting for the hook to finish.
<X-warrior> I guess so
<X-warrior> sarnold, moving it to start hook adding the & param, worked... ssh the machine still shows me the process running so I guess the non-interactive shell does that for me
<X-warrior> I need to move that service to upstart
<X-warrior> but while I don't... I'm just executing the script directly
<doc_> Trying to change my charm repo to a local repo in my environments.yaml file, but juju doesn't seem to pick it up
<doc_> Is this supported? As documented here: https://juju.ubuntu.com/docs/charms-deploying.html
<dalek49> doc_: did you make sure to add it under the correct distribution folder name?
<doc_> dalek49: I have my charms under ./charms/precise/
<doc_> in my environments.yaml file I have: repositories: - ./charms
<doc_> and I specify the charm name when I deploy as local:precise/<charm-name>
<doc_> Am I missing something?
<X-warrior> later guys
<X-warrior> thanks for the help
<doc_> any idea? Anybody?
<marcoceppi> doc_: add --repository with the path to the deploy line. not sure if environments. yaml works properly yet. you might also try the absolute path instead of ~/ inn env
<marcoceppi> .yaml
<doc_> using it on the command line definitely works, I'd rather have in my environments.yaml file though
<doc_> I've tried both absolute and relative path in environments.yaml
<doc_> no go for either
<marcoceppi> doc_: you'll want to file a bug then
<marcoceppi> like I said that should work, but I've not tested it
<doc_> marcoceppi: ok. thanks. do you know if it's documented anywhere besides here: https://juju.ubuntu.com/docs/charms-deploying.html
<marcoceppi> doc_: nope, not that I know of
<jackweirdy> Hey guys; me asking more annoying questions again :) I was wondering why juju expects mongo to run on port 37017 when the default is 27017? Is it to stop clashes with another instance that might be running on the same machine?
<thumper> jackweirdy: almost certainly
<jackweirdy> Awesome :) juju bootstrap is hanging on my machine, I'm running it with --debug, and the last thing it printed was this:
<jackweirdy> 2013-09-04 22:12:54 INFO juju open.go:69 state: opening state; mongo addresses: ["localhost:37017"]; entity ""
<jackweirdy> Been stuck there for a couple of minutes
<jackweirdy> I killed it earlier, ran destroy-environment and tried again
<jackweirdy> Any ideas as to what I should poke?
<jackweirdy> It looks like it's because mongo isn't configured for ssl
<jackweirdy> could someone dump a part of their mongo.conf ssl settings either here or in a gist so I could compare with mine please? :)
<jackweirdy> Maybe not; this shows up in mongo.log
<jackweirdy> Wed Sep  4 23:39:24 [initandlisten] connection accepted from 127.0.0.1:35616 #1 (1 connection now open)
#juju 2013-09-05
<jose> guys, how can I get a unit's name without the /#? Let's say, instead of returning wordpress/1, return just wordpress
<lifeless>  | sed -e '|/*||' ?
<raywang> hi just a quick question, anyone knows how do I know where can i get those EC2 variables from openstack env (horizon doesn't have that)?
<mattrae_> hi, with juju core i have a services and machines that are stuck in the dying state
<mattrae_> how do i get them to move along
<mattrae_> ?
<mattrae_> using 1.13.3
<mattrae_> or is there a better working version?
<raywang> mattrae_, I used 1.13.2, and had the same problem like you :)
<mattrae_> raywang: cool thanks for confirming :)
<raywang> mattrae_, I think jpds might report the block bug like that, Maybe he has findings :)
<gnuoy> Bug#1214651 looks similar
<_mup_> Bug #1214651: Machine stuck in 'pending' state cannot be terminated <juju-core:Triaged> <https://launchpad.net/bugs/1214651>
<raywang> mattrae_, or melmoth also run into the problem like that
<gnuoy> in that bug the agent-state is pending and  life: dying
<gnuoy> does anyone know when the python based openstack charms are likely to be replaced by the python-redux one ?
<gnuoy> urgh, I meant: does anyone know when the *bash* based openstack charms are likely to be replaced by the python-redux one ?
<mattrae_> raywang: great thanks for the bug. i'm trying to just redploy the charm with a different service name
<mattrae_> raywang: i'm just leaving the old charm there dying since i have a spare machine to use
<raywang> mattrae_, that's good :)
<mattrae_> hopefully it will work
<mattrae_> gnuoy: you might ask adam_g about when the python-redux charms will be available
<gnuoy> mattrae_, thanks, will do.
<mattrae_> does debug-hooks in 1.13 work for the install hook?
<mattrae_> i have an error on an install hook
<mattrae_> how do i debug?
<mattrae_> debug-hooks didn't take me to the install hook when i ran: juju resolved hook/0 --retry
<mattrae_> i mean juju resolved charm/0 --retry
<melmoth> raywang, indeed. There are a couple of similar bugs. The main thing i remember is: never destroy a unit before the end of the install hook
<melmoth> otherwise, your fskcp with the machine in a state you cannot change and cannot remove it neither, all is left is destroy env
<jamespage> gnuoy, re openstack redux charms - once they have had enought testing
<jamespage> we agreed a few general approach changes at vUDS that still need to be implemented
<jamespage> gnuoy, of course if you want todo some testing much appreciated!
<gnuoy> jamespage, I'll certainly take them out for a spin :-)
<jamespage> gnuoy, lovely
<mthaddon> anyone know what this means from the local provider on bootstrap (juju-core, 1.13.3-1~1737~ubuntu13.04.1): error: required environment variable not set for credentials attribute: URL
<mthaddon> also, I'm following https://juju.ubuntu.com/get-started/local/, but "juju init -w" gives "error: flag provided but not defined: -w"
<mthaddon> also, "juju init" creates a file that includes instructions to use -e to switch environments, but that fails with "error: flag provided but not defined: -e"
 * mthaddon files bugs
<_mup_> Bug #1221127 was filed: juju docs recommend "juju init -w" but that fails <juju:New> <https://launchpad.net/bugs/1221127>
<thumper> mthaddon: people coming to help RSN
<mthaddon> I've worked around it, as juju init does the right thing, just trying to help improve the docs
<mgz> I don't know what the local provider error issue is, it looks like that's not the local provider at all
<mgz> as it's an error we get from the openstack provider if you don't have an identity server url set in config or envvar
<TheMue> mthaddon: hmm, i've done it the doc way (to check what i wrote *smile*) and it worked
<mgz> mthaddon: double check you have "type: local" set, and are using the right env?
<TheMue> mthaddon: i've used a clean environment, no other juju installation before
<TheMue> mgz: +1
<TheMue> mgz: but that may be a good hint. when generating we default to amazon. and i didn't wrote about setting it to local.
<mthaddon> TheMue, mgz: I've fixed it by creating a new env (using juju init) but are you saying "juju init -w" works for you?
<TheMue> mgz: will add this
<_mup_> Bug #1221134 was filed: "juju init" creates a file that includes comments recommending -e to switch environments <juju:New> <https://launchpad.net/bugs/1221134>
<mgz> mthaddon: nope, the docs are just wrong on that (did it change at some point?) init only takes what --help says it does, which does not include  -w or -e
<mthaddon> mgz: ok, thanks - I guess those two bugs are valid then
<mgz> the second one I find slightly confusing...
<mgz> commands where having an environment makes sense should interpret -e
<mthaddon> mgz: how so?
<mthaddon> mthaddon@mallory:~$ juju -e amazon status
<mthaddon> error: flag provided but not defined: -e
<mgz> hm, maybe it's only registered as a normal flag now, after the plugin changes... I take it `juju status -e amazon` works?
<mthaddon> ah, yeah, it does, will update the bug report
<mgz> wallyworld_: ^was a deliberate change to how we parse -e in commands?
<wallyworld_> mgz: not for juju commands, only plugins
<mgz> hm, am sure that the before-the-command form used to work
<wallyworld_> mgz: InitCommand extends BaseCommand and not EnvironCommand, that is the issue if -e is required
<wallyworld_> but init should not need the -e option
<wallyworld_> mgz: i *think* -w was removed because init now writes by default
<wallyworld_> and --show is required just to dump the contents
<wallyworld_> mthaddon: it seems get-started/local is out of date
<mgz> wallyworld_: that makes sense for the -w removal... I guess we just update the docs
<wallyworld_> it's a doc issue rather than a juju bug
<mgz> wallyworld_: what I'm not sure about is if we've changed from accepting `juju -e amazon status` to only allowing `juju status -e amazon`
<mthaddon> wallyworld_: absolutely, I'm happy for it to be a doc bug rather than a juju bug
<wallyworld_> mgz: i think the -e may now need to come after the sub command, but not 100% sure
<wallyworld_> mgz: yes, it appears so
<wallyworld_> so if any docs say otherwise, they need to be changed too
<mthaddon> is juju-core lxc supposed to work these days? bootstrap node seems fine, but deployed machine is stuck in pending
<wallyworld_> mthaddon: it will be pending while it downloads the image
<wallyworld_> can take a while
<wallyworld_> i think we need a better status
<mgz> mthaddon: looking at juju.ubuntu.com and the branch, the local provider setup instructions say `juju generate-config` not `juju init -w` it seems
<wallyworld_> wow, generate-config is old
<TheMue> it's an alias
<mthaddon> mgz: is that different from https://juju.ubuntu.com/get-started/local/ ?
<mgz> ...yes
<mgz> hm, clicking on local configuration from the getting started link gets me to the right page, but not that one...
<TheMue> oh, just seen, we're inconsistent in our internal help texts. some times "init -w", some times "generate-config -w".
<mthaddon> ah, I see - if you navigate from the website you get to https://juju.ubuntu.com/docs/config-local.html
<mthaddon> I was following the link in the generated juju env file from "juju init"
<mthaddon> I'll note that in the bug report
<mgz> bah, I don't have the karma to edit the askubuntu response, so I'm not sure if that's directly linked or just copied
<mgz> ha, yes I do, and it is live updated
<mthaddon> sorry, which askubuntu question is this?
<mgz> so, -w is gone from that page now, hopefully people on older versions will now not be confused
<mgz> mthaddon: that page is generated from an askubuntu response
<mgz> if you click the byline at the top, it links there
 * mthaddon nods
<mgz> or, actually, the title, clicking jorge links to jorge
<mthaddon> mgz: so why do we have to pages for getting started with the local provider? should the juju init comment link to https://juju.ubuntu.com/docs/config-local.html ?
<mthaddon> er, why do we have *two* pages
<mgz> mthaddon: I think so
<TheMue> the config-local.html has been written during the doc sprint last week like those other config-foo for other providers.
<mgz> I think we just need to migrate properly to the lp:juju-core/docs stuff, askubuntu was a stopgap
<mthaddon> my env is still in pending... :(
<TheMue> mthaddon: which bandwidth? loading the images can last some time?
<mthaddon> TheMue: 20Mbits download - I guess it could still be working
<TheMue> mthaddon: still pending? after the image the software itself is downloaded and installed (e.g. worpress, mysql)
<TheMue> mthaddon: this may last longer on a private box than on fine ec2 instances ;)
<mthaddon> yep - http://paste.ubuntu.com/6066089/
<gnuoy> does the requirement to ufw disable still exist ?
 * gnuoy looks for the bug
<TheMue> mthaddon: a ps could show that there are some wgets running
<mthaddon> no wgets running
<gnuoy> Bug#998238
<_mup_> Bug #998238: local provider unit agents get stuck in pending state because of host firewall blocking communication <juju:Confirmed> <https://launchpad.net/bugs/998238>
<gnuoy> mthaddon, is ufw enabled ?
<mthaddon> gnuoy: it was, lemme destroy env, disable it and try again
<gnuoy> mthaddon, the other issue I had some time ago was a bad image in /var/cache/lxc/cloud-precise . I removed it and all was good, but I think the ufw problem is the most likely
<mthaddon>     agent-state: started <-- seems like it was ufw again...
 * mthaddon will comment on the bug report after confirming the instance boots to completion
<mthaddon> 2013-09-05 11:08:47 ERROR juju git.go:188 worker/uniter/charm: git command failed: exec: "git": executable file not found in $PATH
<mthaddon> this is from the unit log
<mthaddon> gnuoy: does that sounds like the bad image issue you had a while back? ^
<gnuoy> no, machines were stuck pending
<mthaddon> k, thanks
<marcoceppi> mgz: the -w isn't even needed anymore
<mgz> marcoceppi: do you know what the status of the old askubuntu pages is?
<marcoceppi> mgz: I don't know what you mean
<mgz> should we just make sure everything in those answers is also in the new configuring docs, then remove the links and pages?
<marcoceppi> mgz: we had a hybrid aproach planned for the new docs, embedding some questions in the docs, it's just been deferred
<marcoceppi> if something is out of date, anyone can edit and rectify the issue
<mgz> compare juju.ubuntu.com/get-started/local and juju.ubuntu.com/docs/config-local.html
<marcoceppi> mgz: we should probably just drop that get-started link and have it redirect to the docs
<marcoceppi> jcastro evilnickveitch: thoughts ^
<evilnickveitch> marcoceppi, mgz - i am not sure but I think those pages may be culled in the redesign happening later
<evilnickveitch> (the non docs ones)
<evilnickveitch> I think we should redirect to the docs for all the getting started stuff
<jcastro> I agree
<jcastro> however the AU pages get a bunch of google juice, so we need to make sure they are up to date so they act as an onramp to the docs
<mattyw> I can't seem to ssh into unit's I've deployed locally, anyone else seen this?
<marcoceppi> mattyw: how are you sshing?
<mattyw> marcoceppi, juju ssh
<mattyw> marcoceppi, I get permission denied public key
<marcoceppi> mattyw: are you using the machine number or the unit name?
<mattyw> marcoceppi, machine number
<marcoceppi> mattyw: that doesn't work with local provider, use unit name instead
<X-warrior> When you add postgresql service to bootstrap machine, the log goes into a loop and keep increasing forever
<X-warrior> is it a bug?
<mgz> X-warrior: file a bug with a complete description and steps how to reproduce it, easiest way to find out
<marcoceppi> X-warrior: I think this has been documented already
 * marcoceppi looks
<X-warrior> https://bugs.launchpad.net/juju-core/+bug/1218616
<_mup_> Bug #1218616: all-machines.log is oversized on juju node <juju-core> <juju-core:Triaged> <https://launchpad.net/bugs/1218616>
<X-warrior> how could I get juju/devel to work on mac ?
<mattyw> marcoceppi, ok thanks
<marcoceppi> X-warrior: You'll need to compile it, there are instructions on this
<marcoceppi> X-warrior: http://paste.ubuntu.com/6066656/
<marcoceppi> X-warrior: that will be in the docs soon, just a little bit behind
<marcoceppi> X-warrior: also, that will get you the tip of trunk, which should be fairly tested, but won't exactly be what's in the devel ppa
<mattyw> marcoceppi, is not being able to do juju ssh <machine-number> on the local provider a long term thing? or just a bug at the moment?
<marcoceppi> mattyw: core team is aware of it, not sure if it's a long term thing or not. AFAIK, there are two local provider caveats; no ssh to machine number and debug-log doesn't work
<mattyw> marcoceppi, ok cool, thanks again
<mgz> arosales: actually, I don't have the edit bit set for the juju status doc it seems
<arosales> mgz, sorry, please refresh and you should have edit access
<mgz> arosales: thanks!
<arosales> mgz, thnks for updating :-)
<X-warrior> marcoceppi: ty
<X-warrior> :D
<dalek49>  when trying to bootstrap my local environment, i get "TLS handshake failed: x509: certificate signed by unknown authority"
<dalek49> I also saw this bug report https://bugs.launchpad.net/juju-core/+bug/1178312
<_mup_> Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>
<dalek49> I'm not seeing any information on how to troubleshoot this
<diegonat> hi im using juju local but I cannot log in into lxc instances. What are the username and password??
<mgz> diegonat: you can't login, you need to ssh in, use `juju ssh UNIT`
<diegonat> Permission denied (publickey,password).
<diegonat> error: exit status 255
<mgz> diegonat: paste bit the juju status output and the exact command you ran to ssh in?
<mgz> !patebin
<mgz> !pastebin
<mgz> ;_;
<rick_h> I had this I think. You have to ssh manually with ubuntu@xxx when I tried it out
<mgz> that should be fine regardless, yeah (unless ~/.ssh/config is borked)
<diegonat> http://pastebin.com/i52qKLuD
<diegonat> mgz, any error?
<mgz> diegonat: you can't ssh to the machine number with local, you need to use the unit, eg mysql/0
<diegonat> ok
<mgz> ...oddly we don't seem to have a bug open for that
<diegonat> another question that i cannot find an answer online. How does juju work with AWS ? I mean, when I deploy a server, does it launch an instance automatically with the service without me configuring the instance?
<mgz> diegonat: yup, by default
<diegonat> going back to my test machine with lxc... I jujued wordpress and mysql. Is there any way that I can do the same but with wordpress and mysql already configured? For example with mysql user and pass set as I want ?
<mgz> yuo can pass configuration to the carms to customise them, but user/pass is really not something you want to put it, it's much better from a security perspective to autogenerate
<diegonat> ok, now for example... I have wordpress and mysql. How can I configure wordpress without knowing mysql user and pass?
<diegonat> where should i find them?
<mgz> you just add a relation between the two, and that information gets communicted across
<diegonat> ok thats nice
<diegonat> =)
<jcastro> yeah, the entire idea is for you to not have to care about doing that by hand
<diegonat> is it possible to install the web UI ?
<jcastro> yeah
<jcastro> juju deploy juju-gui
<jcastro> will deploy the web UI in the environment
<jcastro> https://jujucharms.com/precise/juju-gui-HEAD/#bws-readme has the instructions
<jcastro> rick_h: hey, can you guys stick the copyright of the gui README at the bottom or something?
<jcastro> that top thing pains me
<sarnold> I miss the older charm browser.. it was so much faster
<jcastro> http://manage.jujucharms.com/ still works!
<sarnold> don't get me wrong, I'm thrilled there's a juju gui demo around, and once it has listing code, I cna understand why you'd rather just maintain the one..
<sarnold> jcastro: oh thanks :) nice. near-instant response. hehe.
<jcastro> I think once the URLs are sorted and the load time is reduced it'll be fine
<jackweirdy> Don't suppose anyone could help me with my juju hanging on mongo problem? http://askubuntu.com/q/341845/61821
<AskUbuntu> juju hangs when connecting to mongo | http://askubuntu.com/q/341845
<jrwren> jackweirdy: are you doing something non-standard with a local environment?
<jrwren> jackweirdy: normally the bootstrap of the local environment creates a completely separate mongo db instance, so you wouldn't have a mongodb.conf like your question states.
<jackweirdy> I've followed the steps here to the letter
<jackweirdy> https://juju.ubuntu.com/docs/config-local.html
<jackweirdy> the only difference was that I had mongo already installed from the 10gen repo
<jackweirdy> so I had to purge that and remove it from sources.d
<jackweirdy> but after an update & autoclean everything seemed ok
<jrwren> right.
<jrwren> sounds like you edited the mongodb.conf to listen on the port which juju wants. don't do that.
<jackweirdy> I changed that because beforehand it was just failing
<jrwren> juju bootstrap will start a mongo instance with its db dir in .juju/  not the system mongo.
<jackweirdy> Ah I see;
<jrwren> it might not have been failing. it might have been REALLY SLOW. first connects would take 30sec for me sometimes.
<jackweirdy> In debug it was implying nothing was listening on that port
<jackweirdy> I'm getting lots of this when I juju bootstrap --debug
<jackweirdy> 2013-09-05 18:51:05 ERROR juju open.go:89 state: connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
<jackweirdy> 2013-09-05 18:51:05 ERROR juju open.go:89 state: connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
<jackweirdy> 2013-09-05 18:51:06 ERROR juju open.go:89 state: connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
<jackweirdy> oh, it's working now :)
<jackweirdy> I should be more patient :)
<jackweirdy> Thanks :)
<jcastro> jackweirdy: it should take about 30 seconds
<jcastro> anything longer than that is a problem
<jcastro> jackweirdy: is this the very first time you're bootstrapping?
<marcoceppi> jackweirdy: it depends on how fast your disks are, but it could take up 90 seconds until the bootstrap comes back. It does a bunch of stuff behind the scenes for the local provider
<jcastro> hazmat: around?
<jcastro> hazmat: hey so for the local instructions, we have the `lxc-local` convenience package so you don't need to install "mongodb-server", which I think is overkill anyway, isn't it mongodb-clients?
<hazmat> jcastro, local provider needs mongodb server
<hazmat> jcastro, the client lib is builtin-to the juju binary
<hazmat> its basically two extra packages though
<hazmat> which we made a new package to automate ;-)
<jcastro> oh, nm, I see mongodb-server is a depends on lxc-local
<jcastro> anyway, I was thinking we could slim down the install line on that page
<jcastro> to just `sudo apt-get install juju-local`
<jcastro> which pulls in lxc and mongo
<hazmat> yup
<jcastro> ok mind if I make the change?
<hazmat> fine by me
<kentb> where can I go if I want more info on whether or not I need the ext-port set on a quantum-gateway charm? I'm deploying grizzly on bare-metal using maas & juju and each server has multiple nics....just not sure when ext-port is appropriate.
<kentb> and is it wise / safe to put quantum-gateway on the same server as nova-cloud-controller, keystone, mysql, rabbitmq-server using juju-core?
<marcoceppi> jamespage adam_g ^
<mwhudson> davecheney: ping
<davecheney> mwhudson: ack
#juju 2013-09-06
<melmoth> anyone have deployed swift with tempauth ? I cannot use swift with "swift -U system:root -K testpass -A https://10.55.32.36:8080/v1/AUTH_system stat
<melmoth> "
<melmoth> no idea if i m doing something wrong or if the charm did. I never used tempauth before, but it look to me the charm created an admin user with 'testpass' as a password
<dalek49> I think there's an issue in the documentation
<dalek49> at https://juju.ubuntu.com/docs/getting-started.html, it says to run 'juju init'
<dalek49> and what it means is run 'juju init -w'
<sarnold> jcastro: what happened to the "report a bug on this page" footer?
<jcastro> it got dropped
<marcoceppi> dalek49: nope, juju init in versions of juju > 1.12 will create the file if it doesn't exist. The -w doesn't exist anymore
<jcastro> we filed a bug to put it back
<sarnold> jcastro: haha :)
<sarnold> jcastro: thanks
<marcoceppi> dalek49: http://paste.ubuntu.com/6068620/
<dalek49> marcoceppi: thanks
<dalek49> I've been trying to make juju work on a 12.04 desktop, and there have been many corners that have prevented me from getting it up and running.  I just got a micro instance from digital ocean (vps), and I was going to try to get local mode working on it (13.04).  It is also proving difficult.  What is the best way for testing deployments and experimenting?  I'm a poor college student (trying to get servers from
<dalek49> school)
<dalek49> I had 0.7 working before and then decided to upgrade
<sarnold> dalek49: if my memory serves me, you can get multiple free micro nodes from AWS to play with, so long as you don't leave them on continuously..
<sarnold> dalek49: the downside is micros are heavily penalized on io and setup can take forever :/
<dalek49> sarnold: i didn't know they had free micro instances.  Thanks!
<marcoceppi> sarnold: you get 700 hours of compute time from amazon a month using micros
<sarnold> marcoceppi: hah, so you could leave one on continuously in february? :)
<marcoceppi> sarnold: you get maybe it's 750 hours, but it works out to being a free micro a month
<marcoceppi> for up to one year
<sarnold> oh! I must be getting close to that year.
<sarnold> an important point :)
<dalek49> when I bootstrap, why is the ~/.juju directory owned by root?
<jcastro> It should be owned by your user
<marcoceppi> dalek49: how are you bootstraping?
<marcoceppi> dalek49: you should only ever use sudo juju bootstrap when using the local provider
<dalek49> marcoceppi: I'm using a local provider right now
<marcoceppi> dalek49: did you run sudo juju init ?
<dalek49> marcoceppi: yes, but I'm on 1.12.  Would that change things?
<marcoceppi> dalek49: You don't need to run sudo for any commands except bootstrap and destroy-environment with the local provider
<marcoceppi> all others are used without sudo
<marcoceppi> so you just would run juju init
<marcoceppi> that's why it's owned as root
<dalek49> ooooh.  I see
<jose> hey marcoceppi, still around?
<gnuoy> hi, I'm doing a fresh deploy and  I have charm stuck with "agent-state: pending" , the machine hosting the charm has agent-state: started and instance-state: ACTIVE. Looking at the log the following output is being reported to the charm log http://paste.ubuntu.com/6069918/ every few seconds. I'm deploying with juju-core 1.13.2-1~1670~precise1
<mthaddon> gnuoy: symlinks anywhere?
<gnuoy> ohh, interesting
<gnuoy> I see symlinks for various things in /var/lib/juju/tools
<gnuoy> but no to a charm dir
<mthaddon> yeah, I was meaning symlinks in the charm dir you're deploying from
<gnuoy> there are symlinks there, yes
<gnuoy> I shall purge and redeploy
<mthaddon> I think this is a juju-deployer issue rather than a juju issue - checking if there's a bug already
<marcoceppi> jose: I am now
<Fraber> Hi, where can I join the Ubuntu Juju Charm School?
<marcoceppi> Fraber: you'll find it in the channel here, we'll be broadcasting in about 4 hours
<jcastro> Fraber: we'll paste in the URL in here
<marcoceppi> Fraber: the recordings will also be available online afterwards
<Fraber> Thanks, and is there an option to participate right now?
<jcastro> feel free to ask questions in here and in askubuntu.com
<jcastro> the channel is always open for questions/discussion
<jcastro> marcoceppi: let's post the video on the upstream forum this morning! And ours as well!
<jcastro> I shared it on G+ last night
<marcoceppi> jcastro:
<marcoceppi> http://meta.discourse.org/t/all-the-options-to-deploy-discourse-with-their-relative-pros-and-cons/9631?u=marcoceppi
<jcastro> nice nice!
<jcastro> marcoceppi: should we put it in the existing juju topic we had from before?
<marcoceppi> jcastro: I want to create a new and improved Juju post
<marcoceppi> but I want it to be /the/ juju and discourse post
<marcoceppi> and just have it be a reply as new topic
<marcoceppi> to the old one
<marcoceppi> jcastro: I need to prep for the charm school, but after cs we can post it
<jcastro> ok
<jcastro> want me to do it?
<marcoceppi> jcastro: sure
<jcastro> marcoceppi: can you report that config bug to the GUI team?
<marcoceppi> jcastro: let me upgrade to the latest charm and verify
<marcoceppi> jcastro: that version of the gui is still last release
<jcastro> ok
<jcastro> marcoceppi: it can wait until after the CS
<jcastro> I just don't want to forget
<marcoceppi> jcastro: cool
<marcoceppi> jcastro: I'm going to make a video for just deploying discourse with juju (using the gui) so I'll verify it then
<jcastro> excellent
<mthaddon> bbcmicrocomputer: if I'm understanding the calendar right you're on review rotation at the moment. Can I bug you for a review of https://code.launchpad.net/~mthaddon/charms/precise/pgbouncer/package-holds/+merge/180533 ? It's relatively trivial and has been in the queue for a while
<kentb> I'm using juju-core 1.13 and (currently) the standard set of charms pulled in locally for raring using charm getall (i'm behind a firewall).  Is there another set of charms I should be using, primarily for OpenStack?  All of my maas-deployed machines are using 13.04 as the base OS.  I've read on jamespage's blog that "Not all of the OpenStack Charms are
<kentb> compatible with the latest version of Juju".
<marcoceppi> kentb: the maas machines should be running precise for the most part, not raring (13.04)
<marcoceppi> kentb: I think that's a safety statement, from what I've seen, the core charms (if not all of them) work with the latest version of juju
<kentb> marcoceppi: ok. thanks. yep. Raring is sort of a band-aid right now.  I'm behind a pretty restrictive firewall, which has so far prevented the 12.04-based images from pulling in the needed SSL-enabled mongodb packages.  From what I understand those are pulled in from a PPA and the lab firewall (from what I can tell) is preventing that ppa from getting added.
<marcoceppi> kentb: ah, gotchya
<marcoceppi> kentb: it might be worthwhile adding *.launchpad.net to the firewall, if you have that power
<bbcmicrocomputer> mthaddon: I am on review but I'm really pre-occupied with some other things that have to be done by EOD.. sorry :(
<mthaddon> ok, thanks anyway
<kentb> marcoceppi: It might be worth a shot...it's the corporate firewall for this company (big OEM) that's being the problem child, so, I don't know how lucky I'll get there :)  I might try and mirror the ppa and see if that works.
<X-warrior> If I'm working with postgresql/mysql, juju and amazon. Amazon instances are not persistent, so should I add the databases file to a persistent storage?
<timrc> SpamapS, wtf are they doing to you guys over at HP? Just saw this nice one of Cody... https://sphotos-a-dfw.xx.fbcdn.net/hphotos-ash4/998429_10151723100558686_1007083002_n.jpg
<jcastro> wow
<jcastro> marcoceppi: can you fire up the hangout 10 min beforehand so I can get ubuntuonair ready?
<marcoceppi> jcastro: yup
<jcastro> marcoceppi: also, kill your downloads. :)
<marcoceppi> jcastro: done and dead
<X-warrior> I think postgresql should have an option to add the directory that we want to create it
<X-warrior> or something like this, to be able to update database location file
<X-warrior> x)
<marcoceppi> X-warrior: patches welcome! :)
<X-warrior> marcoceppi: I can't think on a easy way to do it. I'm just used to amazon. but starting from that point... the
<X-warrior> ops
<X-warrior> the EBS (persistent storage) must be created on amazon and then attached to a machine... after that we need to mount it and then call a hook on postgresql sending the new directory... but to call a hook I need a add-relation... so I will need a charm to EBS storage... but that will start another instance
<X-warrior> maybe this 'volume' handling should be added to juju, but then... there is the differences between ec2, maas, openstac, hpcloud :S
<SpamapS> timrc: sensitivity training? I have no idea wtf that is. :)
<timrc> SpamapS, Whatever it was, it was compliments of Microsoft apparently...
<bloodearnest> heya all - if I have a gojuju lxc environment up, but I no longer have the correct details for that env in .juju/environments, how can I destry that environment?
<SpamapS> timrc: well I see our openstack community manager, mark atwood, in there holding a black flower.. the symbolism is mind blowing ;)
<mthaddon> X-warrior: see the volume-management stuff in config.yaml for the PG charm
<mthaddon> X-warrior: this is how postgresql (and other charms) deal with persistent storage until juju handles that somehow (means creating and attaching storage volumes outside of the charm)
 * X-warrior looking 
<marcoceppi> Charm School starting in about 10 mins
<jcastro> we'll be on http://ubuntuonair.com
<marcoceppi> Anyone want to join the hangout and ask questions, please do! https://plus.google.com/hangouts/_/79462401dbe333e26c19481815990e70360ee6d4?authuser=0&hl=en
<jcastro> ok we're broadcasting in about 30 seconds on http://ubuntuonair.com
<hazmat> woot! got an aws vpc default by request
<jcastro> m_3: hey what web server do we use in the node-app charm? the example one you wrote?
<m_3> jcastro: node directly
<m_3> jcastro: i.e., no web server other than the http node.js library listening on a port
 * jcastro nods
<arosales> any other questions on charm helpers in regards to the charm school?
<arosales> thanks marcoceppi. good info on charm helpers
<arosales> a lot easier to include than I had originally thought
<timrc> Hm.. "Auth GET failed: https://keystone.canonistack.canonical.com:443/v2.0/ 200 OK"... that seems a little confusing to me
<timrc> Seems like an odd choice of status code for a failure
<timrc> (this was in the swift client :))
<sinzui> I love the new http://juju.ubuntu.com
#juju 2013-09-07
<zradmin> Hi guys, trying to get juju 1.12 working properly, but I'm getting an error wehere the /var/log/all-machines.log just fills up the bootstraps whole drive. I'm on 12.03 currently and I have to remove the file and restart the bootstrap node to get new clients enlisted etc.
<hazmat> zradmin, there's bugs open to do rotation and limit the excess in the logs
<hazmat> zradmin, was there anything particular repetitious in the log ?
<mattrae_> let me know if i can help with details on this bug i'm hitting :) https://bugs.launchpad.net/juju-core/+bug/1219116
<_mup_> Bug #1219116: juju-deployer fails against juju-core: dial tcp 127.0.0.1:17070: connection refused <cts-cloud-review> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1219116>
<davecheney> mattrae_: i know that bug
<davecheney> the problem is the provisioning agent, which runs on the bootstrap node
<davecheney> keeps restarting
<davecheney> it'll get there eventually
<davecheney> but it currently slows down provisioning and juju access a lot
<diegonat> hi guys... I have juju and maas. However, although ive got two machines, when I bootstrap juju, it lists only one. Why? How can I add a machine after bootstrapping ??
<davecheney> diegonat: either deploy a service, juju deploy $CHARM
<davecheney> or add a machine, juju add-machine
<diegonat> i dont have the option add-machine
<diegonat> davecheney,
<davecheney> diegonat: which version are you using ?
<diegonat> 0.7
<davecheney> diegonat: then deploy a service
<davecheney> juju deploy $CHARM
<diegonat> yes but ive got 3 machines and only one is listed in juju status
<diegonat> i dont understand why
<davecheney> diegonat: juju defines what it calls an environment
<davecheney> an environment consumes a subset of the macines available to a provider
<davecheney> so int he case of maas
<davecheney> if you have three machines enrolled with maas master
<diegonat> yes i do
<davecheney> it is normal for a new juju environment to consume one machine
<davecheney> when you deploy a new service (a charm)
<davecheney> juju will request maas create a new machine to host that service
<diegonat> davecheney, what about the first node? as u said i deployed a service and a new machine started. however, can't i use the first node for services?
<davecheney> diegonat: not in juju 0.7
<davecheney> we call it the bootstrap node
<diegonat> ok
<davecheney> in later versions, 1.12 or later
<davecheney> you can use
<davecheney> juju deploy --to 0
<davecheney> to put a service on the bootstrap machine
<davecheney> HOWEVER
<davecheney> this is not recommended
<davecheney> as it distables all the safty guards
<diegonat> k
<diegonat> davecheney, juju: error: unrecognized arguments: --to
<davecheney> diegonat: sorry, that must only be available on the development branch
<davecheney> we're going to be doing a 1.14 release quite soon
<davecheney> it'll be available there
<diegonat> the problem is that whenever i add a service, it requires a new machine
<diegonat> :-/
<davecheney> diegonat: yes, currently
<davecheney> we're working on a solution to use lxc containers inside machines
<diegonat> that would be absolutely fantastic
<davecheney> but there are a number of networking issues to solve before that can happen
<diegonat> where can i find the logs of juju installation?
<diegonat> whatever i try to install i receive an error
<diegonat>         agent-state: install-error
<marcoceppi> diegonat: you can juju ssh to the unit and check /var/log/juju/unit-*.log
<marcoceppi> o/ davecheney
<diegonat> Hook error: /var/lib/juju/units/mysql-1/charm/hooks/install Error processing '/var/lib/juju/units/mysql-1/charm/hooks/install': exit code 1.
<marcoceppi> diegonat: go a few lines up, it should say why
<diegonat> 2013-09-07 15:31:35,441: hook.output@ERROR: There are problems and -y was used without --force-yes
<diegonat> WARNING: The following packages cannot be authenticated!
<diegonat> hook.output@ERROR: W: GPG error: http://ppa.launchpad.net precise Release: The following signatures couldn't be ve
<diegonat> rified because the public key is not available: NO_PUBKEY 0272AC9B468AFDED
<diegonat> inverse order =D
<marcoceppi> that's your problem
<marcoceppi> the gpg key error
<diegonat> how can i solve it?
<marcoceppi> diegonat: do you have limited network connectivity to thes machines? is this Maas and juju?
<diegonat> yep, maas and juju
<diegonat> ok i fixed
<diegonat> i downloaded the key
<diegonat> let's try now
<marcoceppi> diegonat: you can run juju resolved --retry
<marcoceppi> to have it try again
<diegonat> i destroyed the service
<diegonat> yeah, now it works
<diegonat> sweet
<marcoceppi> diegonat: cool
<diegonat> marcoceppi, r u italian?
<diegonat> im installing juju.gui
<diegonat> :)
<marcoceppi> diegonat: my family is, but I was born in the states
<diegonat> nice
<diegonat> how many machines would i need to set up a openstack environment with juju?
<marcoceppi> diegonat: I think the minimum is 7
<diegonat> i dont have enough power to try
<diegonat> sh*t! :D
<marcoceppi> diegonat: you can co locate a few services to cut that down
<diegonat> i absolutely love juju
<diegonat> ok ill try then
<diegonat> juju-gui is hanging on saying "connecting to the Juju environment"
<diegonat> :-/
<diegonat> marcoceppi, any idea why?
<marcoceppi> diegonat: nope. it should work after a few seconds
<diegonat> i cannot see anything from logs
<diegonat> help please!! :)
<mattrae_> diegonat: hey you can enlist vms into maas to use to deploy openstack if you need more machines.. http://askubuntu.com/questions/292061/how-to-configure-maas-to-be-able-to-boot-virtual-machines
<mattrae_> diegonat: i'm using only one physical server with vms on it to deploy openstack with juju + maas
<mattrae_> diegonat: also you can even juju deploy a hypervisor to a physical node, which will enlist vms into maas: http://javacruft.wordpress.com/2013/06/25/virtme/
<diegonat> mattrae coold
<diegonat> mattrae cool
<mattrae_> diegonat: i'd suggest testing with maas in raring or saucy though.. some issues with maas in precise
<diegonat> k
<diegonat> now im having problems with juju-gui
<diegonat> mattrae_, can u help me with juju-gui?
<mattrae_> hmm i haven't played with juju gui.. but maybe.. what's happening?
<diegonat> basically it hangs on when I open the webpage
<diegonat> connecting to the Juju environment
<diegonat> it hangs forever
<mattrae_> diegonat: hmm.. can you juju ssh juju-gui/0 and maybe there will be info in /var/log?
<diegonat> im in
<diegonat> but i cannot find anything
<diegonat> maybe im not looking in the right place
<mattrae_> hmm, yeah i might not be help.. i dont know where to look either
<mattrae_> diegonat: you could try sending an email to the juju mailing list.. the developers might not be online on irc right now
<diegonat> mattrae_, do u have any idea what "rapi running" could mean?
<mattrae_> diegonat: not sure.. but just guessing maybe rapi means remote-api?
<mattrae_> i dunno
<diegonat> in a chat log i found somebody saying that the error was due to rapi not running
<diegonat> :-/
<mattrae_> ahh.. that could make sense. maybe its trying to connect but the remote api is not running? just guessing though
<mattrae_> maybe it can't connect
<diegonat> remote api where?
<mattrae_> i would guess that the juju-gui wuild be connecting to the bootstrap node (machine 0)
<diegonat> ok on machine 0 there is no juju-api-agent service
<diegonat> installed
<diegonat> on the machine where juju-gui is installed, there is this service
<mattrae_> diegonat: hmm not sure then.. i believe the services are jujudb and jujud-machine-0
<jackweirdy> Can I deploy a natty machine with juju? I've tried juju add-machine --series=natty but get the error agent-state-info: "error: no matching tools available"
<jackweirdy> I know it's unsupported now but http://aichallenge.org depends on it
<jackweirdy> (the software that is; hosting it locally for a 1st year CS hack afternoon)
#juju 2014-09-01
<davecheney> thumper: State.StateServingInfo checks for a StateServingInfo doc
<davecheney> or more specifically a doc that will marshal into that type
<davecheney> then checks if doc.Port == 0 and takes that as a not found signal
<davecheney> it does this because state.Open inserts an empty document into that collection ...
<thumper> right ...
<davecheney> thumper: can you think of a reason not to change this to
<davecheney> not insert the doc if there is nothing to insert
<davecheney> then use ErrNotFound as the sentital for the document not being found ?
 * thumper looks at it now...
<thumper> I'm guessing because it is always expected to be there (for some value of there)
<thumper> makes it easy to set by just calling update
<thumper> isn't there an Upsert?
<thumper> davecheney: I think with a change to use upsert, I think the behaviour could be changed
<davecheney> fuk this nosql bullshit
<davecheney> ok, that'll have to stay as broken as it is today
<davecheney> func (st *State) SetStateServingInfo(info StateServingInfo) error {
<davecheney>         if info.StatePort == 0 || info.APIPort == 0 ||
<davecheney>                 info.Cert == "" || info.PrivateKey == "" {
<davecheney> ^ we only consider these four fields to be important
<davecheney> any others can be nil and are not consdiered 'empty'
<thumper> :)
<thumper> davecheney: perhaps #juju-dev a better channel... users probably don't care :-)
<davecheney> whoops
<davecheney> i'm in there wrong channel
<pitti> hello all
<pitti> did anyone succeed with using juju-local in utopic? it was my third attempt this morning, and now it fails to build containers
<pitti> I filed bug 1363832 this morning
<mup> Bug #1363832: [utopic] fails to build containers <amd64> <apport-bug> <utopic> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1363832>
<pitti> I wonder if it's generally broken, or something on my system is special
<bloodearnest> has any one else observed juju invoking config-changed at random on a deployed environment?
<bloodearnest> We only noticed because it fails as a configured auth token has expired
<pitti> did anyone succeed with using juju-local in utopic? it was my third attempt this morning, and now it fails to build containers
<pitti> I filed bug 1363832 this morning
<mup> Bug #1363832: [utopic] fails to build containers <amd64> <apport-bug> <utopic> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1363832>
<pitti> I wonder if it's generally broken, or something on my system is special
<html> juju? i cant even figure out how to get it to work-ish
<hazmat> bloodearnest, at random?.. it gets called in a  few places
<hazmat> bloodearnest, it called before start, and after upgrade, and whenever the config changes, and if the machine is rebooted.
<bloodearnest> hazmat: as in, after a long period of no juju activity, with no human stimulus
<hazmat> fwereade, ^
<bloodearnest> hazmat: havn't been able to reliably reproduce
<bloodearnest> hazmat: but I've seen it on local provider, and jjo's seen it a few times in prodstack
<hazmat> pitti, i haven't seen that.. i filed a separate issue about the default containers defaulting to trusty (or more specifically latest lts) instead of precise.
<hazmat> pitti, are there any other containers on the machine from juju? its hard to tell if its having issues starting the template container or the actual container
<pitti> hazmat: no, before there were only a few completely unrelated containers
<pitti> hazmat: it tried to create a juju-trusty-lxc-template but failed
<pitti> I lxc-destroy'ed that after each failed attempt
<hazmat> i should really polish up my juju lxc scripts.. simplifies the interaction much more (nothing on the host).
<hazmat> pitti, could you manually start the template container? ie lxc-start -d -n juju-trusty-lxc-template
<pitti> hazmat: well no, there is nothing in that container
<pitti> hazmat: it created a /var/log/juju/ (empty), and that's it
<hazmat> oh..
<hazmat> pitti, that's strange.. the cloud image template might have some cache issues as well, if it also fails if you manually do lxc-create -t ubuntu-cloud -- -r trusty .. i'd try to clearing out the appropriate series dir in /var/cache/lxc
<pitti> hazmat: there is no other juju related contianer
<hazmat> pitti, and re env settings.. you have juju get-env | grep lxc shows -> lxc-clone-aufs: false ?
<pitti> hazmat: so if juju deploy is supposed to merely clone an existing container, that would explain why it fails
<pitti> hazmat: but then bootstrap ought to have failed
<hazmat> pitti, yup.. it setups a template container, and clones for the actual unit
<pitti> (I pointed that out in the bug report -- bootstrap does *not* create any container)
<hazmat> if your on btrfs.. it uses a snapshot automatically if /var/lib/lxc is btrfs
<pitti> no, plain ext4
<hazmat> pitti, yeah.. bootstrap does nothing
<pitti> so where does the template container come from?
<pitti> if bootstrap doesn't create it, and deploy expects it?
<hazmat> pitti, its all async the first time a machine is requested needed
<hazmat> pitti, deploy will do it inline
<hazmat> this is a long standing issue imo cause it has to download.. a full image and its doing it without giving feedback
<hazmat> ie. at min we should be showing more info on status when its doing stuff in the background for the image dl
<pitti> well, a "full image" is something like 60 MB or so?
<pitti> at least that's the rough size of stgraber's pre-built LXC templates
<hazmat> bootstrap can't quite do it, cause we don't know what series will need to be created
<pitti> that should download in a minute; I waited > 10 mins
<pitti> hazmat: ok, thanks for explaining the workflow
<pitti> I suppose I'll set it up again and this time just let it sit there for really long
<pitti> but it showed a lot of error messages and there was no active process, it seemed quite dead/failed to me
<hazmat> pitti, no.. its bigger.. ~220mb
<pitti> uh, wow
<hazmat> pitti, its the image off cloud-images.ubuntu.com its downloading .. not the mystery images off linux-containers.org
<pitti> ah, that; but even that just takes 3 mins or so for me
<hazmat> pitti, you can see the image it downloads  @ /var/cache/lxc/cloud-$series per the ubuntu-cloud-template source
<hazmat> pitti, the actual error message is the failure to start the container, so i'm wondering if you manually create a container does it work
<hazmat> with the ubuntu-cloud lxc template
<pitti> ok, /scratch/juju set up again, bootstrap is done
<pitti> $ juju get-env | grep lxc
<pitti> container: lxc
<pitti> lxc-clone-aufs: false
<pitti> hazmat: ^ FTR
<hazmat> cool
<pitti> hazmat: I just changed root-dir and default-release, nothing else
<hazmat> if the manual creating an lxc with the cloud template doesn't work, that's the primary issue and i'd suggest wiping /var/cache/lxc/cloud* as a likely cause.
<pitti> so I don't have anything juju-ish in /scratch/lxc/ which
<pitti> just my unrelated other containers
<hazmat> k
 * pitti runs juju deploy juju-gui
<pitti> /var/cache/lxc/cloud-trusty/ubuntu-14.04-server-cloudimg-amd64-root.tar.gz
<pitti> that exists and doesn't change size (185 MB)
<pitti> /var/cache/lxc/cloud-precise/ubuntu-12.04-server-cloudimg-amd64-root.tar.gz also exists and doesn't change size (238 MB)
<fwereade> bloodearnest, we do call config-changed on somewhat slim pretexts, but not *at random*
<pitti> hazmat: tail -f /scratch/juju/log/* doesn't show anything either
<pitti> and ps aux no processses that are more recent than 2 hours ago
<pitti> so something in the template container creation goes pear-shaped
<hazmat> pitti, to sanity check can you manually create a container using the cloud template?
<pitti> hazmat: well, I'd need a cloud template container first :) (that's the very bug)
<pitti> how do I craete that?
<pitti> from /var/cache/lxc/cloud-trusty/ubuntu-14.04-server-cloudimg-amd64-root.tar.gz
<hazmat> sudo lxc-create -n myprecise -t ubuntu-cloud -- -r precise -S ~/.ssh/id_rsa.pub
<hazmat> sudo lxc-start -d -n myprecise
<pitti> hazmat: no, see above -- there *is* no ubuntu-cloud container -- creating that is the thing that fails
<hazmat> pitti, lxc has different templates for creating a container
<pitti> the only thing that was created in all this was the empty juju-trusty-lxc-template
<hazmat> pitti, per contents of /usr/share/lxc/templates/
<pitti> hazmat: ah sorry, ignore me
<pitti> create -t, not clone
<pitti> failed to get https://cloud-images.ubuntu.com/query/precise/server/daily-dl.current.txt
<pitti> There is no download available for release=precise, stream=daily, arch=amd64
<pitti> hazmat: that smells like something then
<hazmat> that's wierd that link resolves
<hazmat> and it should be defaulting to release stream not daily
<bloodearnest> fwereade: at random == our perception :)
<hazmat> oh.. i wonder if it goes to daily cause your on an unreleased.. smarts of some form
<hazmat> pitti, it sounds like the bug may apply to the lxc templates then if the underlying lxc tools aren't working
<bloodearnest> fwereade: other than after start/upgrade/reboot, or an actual honest-to-goodness config-change, are there any more scenarios that it might be?
<pitti> hazmat: reaading /usr/share/lxc/templates/lxc-ubuntu-cloud it seems to default to "tryreleased" and falls back to "daily" if that fails
<pitti> $ ubuntu-cloudimg-query trusty released amd64
<pitti> failed to get https://cloud-images.ubuntu.com/query/trusty/server/released-dl.current.txt
<pitti> hazmat: ^ that might explain it further
<hazmat> yeah
<pitti> so that fails, and it falls back to "daily"
<hazmat> pitti, that link resolves though..
<hazmat> pitti, that link works for me
<hazmat> pitti, as does the cli
<pitti> hazmat: yes, for me too (in the browser)
 * pitti adds a cloud-utils task then
<hazmat> cool
<pitti> hazmat: does wget work for you?
<pitti> hazmat: it fails because the certificate can't be checked
<pitti> and it's calling wget without --no-check-certificate (quite rightly so)
<fwereade> bloodearnest, I *think* those should be the only cases (plus agent restart, not quite a reboot necessarily)
<fwereade> bloodearnest, is it possible something's bouncing the agent?
<pitti> hazmat: ok, thanks muchly for your help! I'll go on prod our cloud folks
<bloodearnest> fwereade: that sounds a likely candidate, will try to check next time it happens
<pitti> hazmat: if wget works for you on that URL, it'd be interesting if you are running trusty or utopic
<pitti> hazmat: wget does work for me in trusty, but apparently got stricter in utopic
<bloodearnest> fwereade: what's the rationale behind running config-changed after reboot/restart?
<fwereade> bloodearnest, heh
<fwereade> bloodearnest, we don't track what version of the config you've seen
<bloodearnest> ahh
<fwereade> bloodearnest, I have no idea what inspired that approach
<fwereade> bloodearnest, but fixing it has not been especially high on my list
<hazmat> pitti, cert issues on trusty then?
<hazmat> or perhaps tls negotiation
<pitti> hazmat: or wget just simply didn't default to checking the cert for https:// on trusty yet
<pitti> which is more likely
<fwereade> bloodearnest, (and since we *do* run it on reboot I worry a bit that not doing so will subtly break some charms that have accidentally come to depend on it)
<pitti> hazmat: I pinged smoser about it in #u-devel
<bloodearnest> fwereade: ack, it was a bug in our charm that made us discover it, just wanted to know why it was happening
<pitti> hazmat: I hacked ubuntu-cloudimg-query and will now re-try juju
 * pitti also adds --no-check-certificate to the ubuntu-cloud LXC template and tries again
<pitti> hazmat: ah, now I have a juju-trusty-lxc-template, a running martin-local-machine-1, and we are as far as agent-state-info: 'hook failed: "install"'
<pitti> hazmat: that's a whole lot of progress :)
<hazmat> pitti, awesome
<pitti> apt-get install failed
<hazmat> pitti, ugh.. dns issues in container?
<hazmat> pitti, or are you getting checksum mismatch?
<pitti> I wish it would contain apt's error messages
<hazmat> pitti, lxc-attach -n your-container-name  && and apt-get install
<pitti> hazmat: yep, that's my next step
<hazmat> pitti, actually better alternative
<hazmat> is juju debug-hooks unit-name
<hazmat> and then juju resolved --retry
<hazmat> + unit-name
<pitti> aah
<hazmat> pitti, if you like your containers in clouds.. with across host networking.. this is something fun i put together over the weekend. http://bazaar.launchpad.net/~hazmat/charms/trusty/rudder/trunk/view/head:/readme.txt
<pitti> # cat /etc/apt/apt.conf.d/42-juju-proxy-settings
<pitti> Acquire::http::Proxy "http://127.0.0.1:3142";
<pitti> now, that wouldn't work, my dear juju
<hazmat> wtf
<hazmat> it should be pointing to the bridge address
<hazmat> 10.0.3.1
<hazmat> and now we're back to juju bugs ;-)
<pitti> hazmat: thanks for pointing out teh debug stuff
<hazmat> pitti, np
<pitti> hazmat: filed and updated bug 1364069
<mup> Bug #1364069: local provider must transform localhost in apt proxy address <amd64> <apport-bug> <utopic> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1364069>
<pitti> resolved --retry still fails, but I need to run now; more tomorrow :)
<hazmat> thats the one downside of using my own juju lxc scripts.. i don't get to experience the pain of local provider
<hazmat> pitti, cheers
#juju 2014-09-02
<natefinch> jcastro, marcoceppi:  man, there is so much missing from the charm writing docs
<jcastro> like what?
<marcoceppi> natefinch: yes, most of the effort was put in the user docs, the author docs are still, lacking
<natefinch> jcastro: like... what's the format of config.yaml?
<jcastro> I wasn't being faceitous, just want specifics, etc.
<jcastro> oh
<natefinch> jcastro: I'll make a list :)
<marcoceppi> natefinch: please do!
<aisrael> Examples using the Python charmhelpers. I think most of the examples use Bash.
<natefinch> marcoceppi: but to unblock me - what are the valid values for "type" in config.yaml?  Specifically I have an int and a list of strings (email addresses)
<marcoceppi> natefinch: no lists
<marcoceppi> you get boolean, int, and string
<natefinch> marcoceppi: bah
<marcoceppi> natefinch: you have the power to fix this :)
<marcoceppi> specifically, I would LOVE an ENUM field type
<marcoceppi> which would produce a drop down in the gui and allow validation outside of the hooks
<natefinch> marcoceppi: hmm yeah, that's a little more tricky than just a list....
<marcoceppi> well, its completely different than a list
<james_w`> another I had trouble finding was a list of the environment variables that each hook gets
<marcoceppi> typically people just do comma and space delimited lists as strings
<james_w`> turns out I just missed it though: https://juju.ubuntu.com/docs/authors-hook-environment.html
<natefinch> marcoceppi: is JUJU_HOOK_NAME always available when hook is running, or only during debug?  Docs seem to indicate only during debug: https://juju.ubuntu.com/docs/authors-hook-environment.html#environment-variables
<marcoceppi> natefinch: oh, I wasn't aware it was only debug
<natefinch> marcoceppi: I don't know, I was asking you :)  I would hope it was just always set.  I can check the code if you don't know
<jose> arosales: hey, do you know if we have a list of currently orphaned charms?
<dannf> marcoceppi: advice on whether or not this is a reasonable way to go? if so, i'll propose similar things for other charms. https://code.launchpad.net/~dannf/charms/precise/mediawiki/restrict-ppa-to-precise/+merge/233062
<marcoceppi> dannf: that looks fine to me
<arosales> jose: I think we should be able to find those by looking for charms that have a bug that states "maintainer needed"
<arosales> jose, but I don't have a readily available list that I could reference atm.
<natefinch> marcoceppi: btw, what I'm working on: https://github.com/natefinch/discourse
<jose> arosales: no worries. I will try and make one when possible
<marcoceppi> natefinch: ah, awesome, using the docker version of the discourse
<marcoceppi> natefinch: sweet
<natefinch> marcoceppi: yep
<natefinch> marcoceppi: and written in Go ;)
<marcoceppi> breakin all the walls!
<natefinch> marcoceppi: gotta keep things interesting.. if I don't make at least a few people mad every day, I'm not doing my job ;)
<arosales> jose: we have the data from charm world on proof failures, and I think we have a maintainer needed bug. So may just be a matter of quering
<jose> cool!
<arosales> jose: btw congrats on your successful application to the ~charmers team :-)
<jose> arosales: thanks! I really look forward to keep working with all you guys :)
<bloodearnest> Is there a specific reason why "unit-get public-address" returns the private address when there is no public address?
<marcoceppi> bloodearnest: that's what juju assumes is the public address?
<marcoceppi> which cloud?
<bloodearnest> marcoceppi: openstack
<bloodearnest> and local
<bloodearnest> marcoceppi: it means I need to compare the address against known private ranges, and even that is a guess
<marcoceppi> bloodearnest: well, local is technically correct
<marcoceppi> that's the public address.
<marcoceppi> Not sure about openstack, mihgt need to open a bug about that
<bloodearnest> marcoceppi: sure, it makes sense with local
<JoshStrobl> Hey lazyPower, got any more good mixes for me to listen to?
<kwmonroe> hey folks, default-series is empty in my local env config, and i'm running trusty.  when i charm get mongodb, it pulls from lp:~charmers/charms/precise/mongodb/trunk.  why does it grab from precise?
<kwmonroe> i can get trusty/mongodb if i add the namespace.. just wondering why it doesn't choose trusty by default (on a trusty host)
<marcoceppi> kwmonroe: charm isnt' tied to juju env
<marcoceppi> charm was created when there was only one default series, which was precise
<marcoceppi> so in order to support older workflows of just "charm get" it'll remain precise for sometime
<kwmonroe> ah, gotcha marcoceppi.  thanks!
<mbruzek> Hey #juju folks, I have a machine in "pending" because there are no matching tools for precise.
<mbruzek> agent-state-info: no matching tools available
<mbruzek> I tried bootstrapping thusly:
<mbruzek> $ juju bootstrap -v -e local --series precise,trusty --upload-tools
<mbruzek> Any ideas on what is wrong with my precise agent or how to fix?
<mbruzek> From all-machines.log ERROR juju.provisioner provisioner_task.go:418 cannot find tools for machine "1": no matching tools available
<mbruzek> I found an old bug that is fix released https://bugs.launchpad.net/juju-core/+bug/1309805
<mup> Bug #1309805: LXC / Local provider machines do not boot without default-series <config> <local-provider> <lxc> <juju-core:Fix Released by jose> <https://launchpad.net/bugs/1309805>
<mbruzek> 1.20.6-trusty-amd64
#juju 2014-09-03
<mbruzek> Good morning Juju.  Question.  Where does the bash function ch_get_file live?
<mbruzek> marcoceppi ^ ?
<marcoceppi> mbruzek: that's a name I've not heard in a long long time
<mbruzek> One of the lesser used charms is failing to find this function, I vaguely remember it.
<mbruzek> It uses wget and checks the hash value.
<marcoceppi> http://i.imgur.com/YO0lXro.gif
<mbruzek> marcoceppi, the charm liferay is FAILING to find it actually.
<marcoceppi> mbruzek: yeah, that's charmhelpers 1.0
<marcoceppi> the charm will likely need to add a PPA to continue to function on precise
<mbruzek> Does it no longer exist in the latest CH version?
<marcoceppi> no
<marcoceppi> current charmhelpers is only python
<marcoceppi> atm
<marcoceppi> this is when charmhelpers lived in charmtools
<marcoceppi> pre charm-tool 1.0.0
<mbruzek> Well it looks like it tries to install charm-helper-sh which can not be found.
<marcoceppi> right
<marcoceppi> the charm needs a ppa
<mbruzek> Add a ppa or change the code to use wget?
<marcoceppi> https://launchpad.net/~charmers/+archive/ubuntu/charm-helpers
<marcoceppi> add a ppa, this also does the verification
<marcoceppi> will only work on precise
<marcoceppi> the ppa is to enable those older charm to continue working
<mbruzek> Ok thanks.
<jcastro> marcoceppi, is today new queue day?
<marcoceppi> jcastro: open your eyes and seeee
<jcastro> I still see the old queue
<lazyPower> JoshStrobl: I do actually, i'll send it to you in a pm.
<jcastro> oh, should I get the gui guys to fix the URL?
<marcoceppi> jcastro: well, yeah
<marcoceppi> jcastro: http://review.juju.solutions/
<marcoceppi> jcastro: but not right now
<marcoceppi> there's still things to be sorted in new rev queue
<marcoceppi> well
* jcastro changed the topic of #juju to: Welcome to Juju! || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://review.juju.solutions || Unanswered Questions: http://goo.gl/dNj8CP || News and stuff: http://reddit.com/r/juju
<marcoceppi> do what you think is right
<jcastro> well, we're the only ones who use the link
<jcastro> so let's go all in
<marcoceppi> sounds good to me
<lazyPower> marcoceppi: looks sharp man! Nice work on applying the design bits
<jcastro> heya lazyPower
<jcastro> did we ever get logstash on trusty? I can't seem to find it
<lazyPower> it needed tests
<lazyPower> and i was having a big issue with amulet / sentries blocking the tests
<jcastro> ack
<lazyPower> but baseline - is no, its not in trusty yet.
<jcastro> which is the most current one
<jcastro> logstash-agent or logstash-indexer?
<jcastro> lazyPower, ^
<lazyPower> https://code.launchpad.net/~lazypower/charms/trusty/logstash/trunk
<lazyPower> this is a port of the indexer, feature 2 landing would be adding the agent - its a unified deliverable now
<lazyPower> ready for the kickass part? this woudl also include kibana with feature 2
<lazyPower> *an up to date kibana
<jcastro> ok I'll just link to your personal branch then
<jcastro> it's a subordinate right?
<lazyPower> Nope. its a stand alone charm
<lazyPower> ahhh so the agent would need to be a sub. ok - i follow where you're going with this.
<jcastro> I think one of the old ones was a sub
<lazyPower> yeah, the agent would have been a sub.
<lazyPower> bummer I wasn't thinking about that, but upgrading the sub will be fairly straight forward with the work that went into the agent.
<lazyPower> s/into the agent/into the indexer/
<kwmonroe> mbruzek, have you come across any charms with source behind a "free registration" wall?
<kwmonroe> i'm charming db2 express -- there's an older version in the partners ppa (which is super easy), but the latest version isn't very programatically accessible from ibm.com.
<mbruzek> kwmonroe no I have not but I could take a look
<kwmonroe> so i think the options are either update the partners ppa, or stash the tar.gz someplace more accessible (assuming the fine print says that's ok)
<mbruzek> kwmonroe, could you get the required info (I suspect email, name,etc) and send an HTTP PUT ?
<mbruzek> kwmonroe, can you link me to the wall?
<kwmonroe> mbruzek, here's the wall:  https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=swg-db2expressc&S_PKG=dllinux64
<mbruzek> kwmonroe, this one looks particularly hard with the user having to register.
<kwmonroe> yeah mbruzek - i'll take a look at the form behind "proceed without an ibmid" and see if i can PUT it.
<kwmonroe> but even so, that seems a fragile way to get the source :/
<mbruzek> kmonroe talk with arosales about getting it added to the partner ppa
<mbruzek> kwmonroe, that is likely the path of least resistance.
<kwmonroe> ack mbruzek - thx
<arosales> kwmonroe: adding to the partner PPA I think is a longer term solution that we should take a look at. For that we just need to go through the ubuntu dev process
<arosales> kwmonroe: ther other is putting the DB2 binary local to the charm
<arosales> kwmonroe: you need to have an EULA in the charm and a config set for the charm user to accept. mbruzek did this for the websphere liberty lite charm.
<arosales> kwmonroe: and the third option is building a .deb on lp in a custom PPA
<arosales> kwmonroe: putting the binary locally may be your fastest option with an EULA config set
<arosales> in parrallel we can work on updating the partner ppa
<arosales> locally to the charm that is.
<kwmonroe> gotcha arosales - thanks for the options.. i'm gonna put my legal cap on and make sure this is "free to deploy" like the marketing flyer says.
<arosales> kwmonroe: ping mbruzek and check out what he did for the websphere liberty charm
<mbruzek> arosales, IIRC the websphere charm downloaded the code, but yeah there was an "accept-ibm-license" configuration option in there.
<arosales> mbruzek: ya and I think the "accept-ibm-license" portion is the part kwmonroe is intersted in.
<arosales> mbruzek: given kwmonroe puts the db2 binary locally to the charm for now.
<kwmonroe> yeah, i'll take a look at liberty and bug mbruzek
<JoshStrobl> hey marcoceppi, loving the new review queue! great work man!
<hatch> is there a way to force destroy a machine on a local deployment? 1.20.6-trusty-amd64
<hatch> it appears to be stuck in pending
<hatch> help says to use --force but using it says that it's not defined
<hatch> oh well, hulk smashing :)
 * arosales geting some review queue time in.
<arosales> marcoceppi +1 JoshStrobl's comments on the review queue
<arosales> hatch: is there a service on the machine?
<marcoceppi> hatch: use terminate-machine with force
<marcoceppi> should work
<hatch> arosales: nope it was just hangin out in pending
<hatch> marcoceppi: ok I'll remember that for next time
<marcoceppi> destroy-unit and service don't have a force
<arosales> JoshStrobl taking a look at https://github.com/juju/docs/pull/156 now
<arosales> mbruzek: ^
<mbruzek> I will take a look
<arosales> mbruzek: you already commented. This is in regards to the Charm Review Process doc
<JoshStrobl> arosales, warming up some food now, will review after :P
<JoshStrobl> back
<JoshStrobl> arosales, oh, I misread
<arosales> JoshStrobl: no action from you atm. I was just stating I was going to review
<JoshStrobl> arosales, I thought you said "take a look"
<JoshStrobl> fail :D
<arosales> ah. My IRC grammer is horrible so I thought it may have been that
<arosales> and my message was kind of vague
<JoshStrobl> arosales, no no, I just misread, thats all
<arosales> in any case taking a look now
<JoshStrobl> seriously my fault
<JoshStrobl> alrighty
<jose> marcoceppi: congratulations on the new revq, looks awesome!
<JoshStrobl> mbruzek, sorry I haven't gotten around to working on the reference-reviewers doc yet, been busy with failing tests on some unrelated stuff today. will get around to it tomorrow morning and have something for you to review then.
<hatch> marcoceppi:  just fyi - I somehow ended up in the same state and terminate worked thanks
<mbruzek> No worries JoshStrobl I am up to my ears in work too.
<JoshStrobl> mbruzek, yea I imagine a lot of crunching even before the sprint!
 * mbruzek nods
<JoshStrobl> arosales, going to be afk to help the wife clean our newly rescued old cat, just fyi
<arosales>  JoshStrobl: ack, I'll post comment in the git pull request
<jcastro> marcoceppi, bah crap
<jcastro> we forgot something, where to report bugs on the new queue
<jcastro> want them on issues?
<JoshStrobl> arosales, has the storm ended? my email is finally quiet :P
<JoshStrobl> arosales, writing a lengthy response via the comment section in GH ;)
<marcoceppi> jcastro:  on gh
<arosales> JoshStrobl: storm ended :-)
<JoshStrobl> \o/
<JoshStrobl> Thanks for all the great feedback.
<arosales> JoshStrobl: np. I errored on being more verbose hopeully you filter mail ;-)
<JoshStrobl> arosales, yea, it all goes to a Juju folder in Thunderbird :P
#juju 2014-09-04
 * arosales finishing up review time
<fuzzy> Hi there I just build a juju deployment using the quick start and manual provisioning.  I'm using 12.04 and have the precise juju-gui installed, but when I do a juju status it says pending.  The machine is at 100% idle and it's been like 5 minutes.  Is there anyway to figure out what is holding it up?
<stub> Interesting... my agent died while in debug-hooks
<stub> lxc
<jam2> stub: seems surprising, anything interesting in the log file?
<stub> jam2: yeah, I seem to have a big arsed go panic in there
<stub> jam2: here we go. http://pastebin.ubuntu.com/8231693/
<aisrael> Which project contains the text of this page? Doesn't look like it's juju-docs. https://juju.ubuntu.com/
<tvansteenburgh> how does one test an upgrade-charm hook?
<tvansteenburgh> nevermind, `juju upgrade-charm -h` look helpful
<lazyPower> hey  marcoceppi, hazmat, jcastro, mbruzek did you see we had a community member working with linode contribue a quick start stack script for creating a juju jump-host on linode? https://www.linode.com/stackscripts/view/10193
<hazmat> lazyPower, i did
<jcastro> that is awesome
<jcastro> I'll send him a shirt
<hazmat> lazyPower, ideally it would be wrapped up into a plugin like the digitalocean provider using the api.. its pretty manual to use something like that
<hazmat> basically its restricted to a one node env without some work
<lazyPower> hazmat: well, I was working with fuzzy to achieve their goal of having a jump station for their trusted dev-staff to control deployments.
<hazmat> not sure if it really needs the host name set, or if could bootstrap localhost and be auto for the one node case
<jcastro> oh you're talking to them already?
<lazyPower> they didn't like the idea of porting ~/.juju - so they threw it up as a stack script, and thats effectively their manual jump host.
<lazyPower> jcastro: yeah - i've known fuzzy a little over a year. Fuz is working with our Meteor.js charm
<jcastro> oh ok
<jcastro> # Stephanie Sunshine <sms@ziphub.com>
<lazyPower> it started as "how can i gate deployments a-la capistrano style?" - to which I showed them Juju-strano
<lazyPower> Thats the one.
<jcastro> what about her? should I send her a  shirt or are there multiple ones?
<lazyPower> Stephanie Sunshine = Fuz
<jcastro> ack
<jcastro> I'll send along a link to the DO provider as well
<lazyPower> hazmat: I pinged the list with that stack script, any feedback for them on that thread would be awesome. I'll point fuz at it when she shows up later today.
<lazyPower> I was talking about a phaux provider like your DO plugin - but for PoC work that was overkill. I can see that being on the roadmap as a community contribution though - baby steps :)
<jcastro> yeah
<aisrael> jcastro: any idea where that page lives, project wise (see previous question)?
<jcastro> the website, it's a wordpress setup
<jcastro> there should be a l ink on where to report bugs at the bottom
<jcastro> ... or not
<jcastro> https://launchpad.net/juju-website
<aisrael> ack, thanks
<aisrael> jcastro: I assume content changes just need to have a bug filed against it?
<jcastro> yeah
<jcastro> if you want irc ping luca
<jcastro> he's just taken over the site and is doing a massive clean up/reorg
<aisrael> kk
<natefinch> marcoceppi, jcastro, anyone else:  do I have to do open_port 80 in my install hook if I declare my app to be http, or will juju expose do that for me?
<marcoceppi> natefinch: all port openings need to be explicit
<natefinch> marcoceppi: ok, that makes sense
<marcoceppi> port 80 isn't the only port an http server could run on
 * marcoceppi wanders off pondering tomcat
<jcastro> natefinch, the other half of that bug, which is annoying
<jcastro> is the whole directory structure for local charms
<jcastro> so like, juju expects:
<jcastro> <trusty>
<jcastro> -> <charmname>
<jcastro> and if you do `juju deploy --repository=foo local:blah`
<jcastro> if foo doesn't have a series/charm structure, it just bails
<natefinch> jcastro: you should read my latest email about writing a charm, I mentioned that specifically
<jcastro> yeah
<natefinch> jcastro: my suggestion is to make juju deploy --local=<path>  work if <path> points to a charm directory
<jcastro> yeah!
<jcastro> natefinch, is there a specific bug for that or is it just on your radar somewhere?
<natefinch> jcastro: on my radar, but we should make a bug
<natefinch> jcastro: my radar is notoriously unreliable ;)
<jcastro> ok I'll copy and paste your text and toss it in there
<natefinch> jcastro: awesome, thanks
<jcastro> https://bugs.launchpad.net/juju-core/+bug/1365542
<mup> Bug #1365542: Doesn't deploy a charm unless the repository directory has a specific directory structure <ui> <juju-core:New> <https://launchpad.net/bugs/1365542>
<natefinch> jcastro: great
<JoshStrobl> Hey arosales_ where do you think the Code Review section in the Charms Review Doc should be? Prior to the charmers team part so it doesn't break apart the absolutely essential parts of the review?
<JoshStrobl> Also, I was thinking about moving up the community review ending part to prior to the charmers team, that way the process of the charmers team can take up more room if necessary and not push down the community content.
<arosales_> JoshStrobl: hmm, it would live in the workflow your defined, perhaps before deploy/test.
<arosales_> JoshStrobl: or we could leave that specifically for the ~charmer section
<arosales_> your thoughts?
<JoshStrobl> hmm
<arosales_> I guess it comes back to if we think everyone will want/be able to do a code review.
<JoshStrobl> exactly
<JoshStrobl> I don't want to make it seem like it is only meant for the charmers team.
<arosales_> ya +1 to that
<JoshStrobl> but it is your call
<arosales_> I think this should be _the_ review process
<arosales_> we could put it out to the list for input too
<arosales_> ideally, the review process is transparent and anyone wanting to can do a full reivew.
<arosales_> but
<arosales_> perhaps folks just want a workflow that is straight forward and does not include code review
<JoshStrobl> marcoceppi, do you know if the "expanded sections" header thing (the Juju specific Markdown) works?
<JoshStrobl> arosales_, if the expanded sections part works, we could have it prior to the deployment section.
<JoshStrobl> arosales_, it could be unexpanded by default, marked optional, those that want or are required to dive into the code review can expand the section
<JoshStrobl> marcoceppi, what I am referring to -> https://github.com/juju/docs/wiki/Markdown#foldouts
<marcoceppi> JoshStrobl: yes, those all work
<marcoceppi> JoshStrobl: you can see it in action on this page:
<marcoceppi> https://juju.ubuntu.com/docs/reference-release-notes.html
<JoshStrobl> ah sweet, thanks
<JoshStrobl> arosales_, would that work?
<marcoceppi> JoshStrobl: if you need additional HTML elements that don't exist yet, Im happy to make more markdown plugins
<allomov> Hey, all.
<allomov> I will have short question about deploying to openstack.
<marcoceppi> allomov: feel free to ask your question
<allomov> I get following error trying to bootstrap openstack environment: https://gist.githubusercontent.com/allomov/188131c84fdbcbab5ea8/raw/b7192994bbab0f0c70d8e1a19f7dcb09cab3cb70/fail-juju.log
<allomov> here is a piece from my environment.yml file https://gist.githubusercontent.com/allomov/188131c84fdbcbab5ea8/raw/799c20a50083e82bf832cadb3e72ad7d2159c5a4/juju-env.yml
<marcoceppi> allomov: you need to create cloud image metadata for your openstack provider
<marcoceppi> allomov: https://juju.ubuntu.com/docs/howto-privatecloud.html
<arosales_> JoshStrobl: I am thinking if we just put out code review section in the ~charmer section but welcome anyone to also do that as part of their reivew . ..
<allomov> marcoceppi: cool, thank you for the source
<arosales_> JoshStrobl: but also try to keep this readable so folks don't think this is just for ~charmers
<marcoceppi> allomov: the first half of that doc is pretty heavy with details that might confuse at first. Make sure you read through once :)
<allomov> marcoceppi: that's the strange thing, because I didn't need to use my region name before. fog gem for instance doesn't need it
<marcoceppi> allomov: Juju does a bit more and things slightly differently than fog gem
<arosales_> JoshStrobl: my 2 cents, fwiw, lets put the code review section in the "general/community" review process. Cavet the code review is optional pending review comfort level.
<arosales_> inlucde some common things to look for that we can grow out so folks can grow their skill there if they want
 * arosales_ thinking out loud
<arosales_> JoshStrobl: as you mentioned this could also be folded in too
<JoshStrobl> arosales_, sounds good to me.
<JoshStrobl> arosales_, I'll make note of the existing code review contents you pointed out in the comments and it can be expanded up later if others come up with more stuff, sound good?
<arosales_> JoshStrobl: sounds good
<JoshStrobl> Fantastic. I'll get started on it now then!
 * arosales_ really liking this doc.
<arosales_> I will also be creating a complimentary charm author guidliens doc specifically to call out design consideration and common gotchas in reviews that we can take care of before review.
<arosales_> JoshStrobl: be good to get your input there if you have time given your a charm author
<JoshStrobl> arosales_, sounds good. do you want us to figure it out after your guys' sprint?
<arosales_> JoshStrobl: ya I have this slated to creat at the sprint next week.
<JoshStrobl> \o/
<arosales_> JoshStrobl: to conrim I read that correctly, re "figure it out after your guy's sprint" was that in regards to your charm review doc, or my charm author guidlines doc.
<JoshStrobl> arosales_, your charm author guidelines doc
<JoshStrobl> arosales_, we understand each other correctly?
<arosales_> JoshStrobl: we do :-)
<JoshStrobl> great :)
<JoshStrobl> arosales_, sorry to nag you again, was thinking about another thing to watch out for in the code review, you approve of the following? "Not using set -ex in bash scripts, which allows the bash script to more easily catch failed execution, thereby allowing Juju to more accurately detect a failed hook."
<arosales_> JoshStrobl: not nagging at all
<marcoceppi> JoshStrobl: yes, that should def be in there
<marcoceppi> JoshStrobl: well, only -e is needed
<marcoceppi> -x is xtrace
<JoshStrobl> marcoceppi, ah
<JoshStrobl> I'll remove the x part then :P
<marcoceppi> -eux should be in best practices though, (-u being that if a varaible is accessed before set it's an error)
<JoshStrobl> marcoceppi, so you think I should have it as -eux or something like "Not using set -e or set -eux[...]"
<marcoceppi> -e is the minimum for a review, -eux should be in the best practice section of the docs imo
 * marcoceppi may make a merge for that
<arosales_> JoshStrobl: +1 to marcoceppi comments on just making sure -e is there
<arosales_> +1 on recommending -eux though per marcoceppi's suggestions
<JoshStrobl> marcoceppi, request for the script that converts the GFM / Juju Markdown into HTML (you know, the make stuff), have a sha1sum of each file. Do an on-the-fly comparison between the sha1sum of the files in src/en/ and the existing sha1sums. If the file changed, THEN convert it. Otherwise don't bother. I think it'd speed up the converting time when using "make" since it'd only convert files that have changed.
<JoshStrobl> (does this with some of his custom "compilers")
<marcoceppi> JoshStrobl: sure, that's a great idea. Can you open an issue on GH
<marcoceppi> I'm collecting a list of things I can do "offline" the next time I'm flying
<JoshStrobl> yep, is the converter in juju/docs?
<marcoceppi> JoshStrobl: yup
<JoshStrobl> cool, I'll file an issue there then
<marcoceppi> you're talking about a hashsum of the compiled file, right?
<marcoceppi> rather
<JoshStrobl> no, a sha1sum of the src/en markdown files
<marcoceppi> if compiled file exists, and hashsum of the source hasn't changed, then skip
<marcoceppi> otherwise, you'd never get an initial copy of the compiled file
<JoshStrobl> if src/en/*.md sha1sum !== existing sha1sum of the file (stored in a .sha1sum file), compile, else skip
<JoshStrobl> right, if the sha1sum simply doesn't, go ahead and compile it anyways, since the file probably doesnt exist in htmldocs
<marcoceppi> JoshStrobl: yeah, i get teh concept. def open an issue, it's a great idea esp as the docs increase size
<marcoceppi> I was going to implement a file watcher
<marcoceppi> so as src/* files changed it would just recompile them
<JoshStrobl> that'd be great too, but I'd prefer to not have to compile every single markdown file into HTML whenever I make a change I want to test :P
<JoshStrobl> but yea, I'll file an issue in a bit
<marcoceppi> it would only compile the markdown file that changed, not all the files
<marcoceppi> but yeah
<JoshStrobl> You can sorta get an idea of how I do it by looking at the recursiveCompiling function at https://github.com/StroblIndustries/Metis/blob/master/build/compiler/metisCompiler and the fileChanged function at https://github.com/StroblIndustries/Metis/blob/master/build/compiler/compilerFunctions
<JoshStrobl> it is bash, I'm going to assume yours is in python, but the logic is essentially the same
<avoine> anyone got that error on a bootstrap?
<avoine> ERROR juju.cmd supercommand.go:323 cannot initiate replica set: cannot get replica set configuration: cannot get replset config: not authorized for query on local.system.replset
<JoshStrobl> arosales_, doc is now updated: https://github.com/JoshStrobl/docs/commit/bf62c234572b94ff61cec6709db3190654639433?diff=split
<marcoceppi> avoine: what version of juju are you using? `juju version`?
<avoine> 1.20.6-trusty-amd64 and juju-mongodb 2.4.9-0ubuntu3
<avoine> from http://ppa.launchpad.net/juju/stable/ubuntu
<avoine> and with an lxc local bootstrap
 * arosales_ loving the split in github
<arosales_> JoshStrobl: thanks taking a look
<JoshStrobl> marcoceppi, issue filed - https://github.com/juju/docs/issues/157
<marcoceppi> kirkland: using "run-one-constantly" in the new review queue, love these little helper scripts
<kirkland> marcoceppi: woot :-)
<kirkland> marcoceppi: btw, I just found, per dpb2, the timeout command, which is nice in conjunction with run-one*
<marcoceppi> nice
<dpb2> :)
<arosales_> marcoceppi: got a question for you
<arosales> any any yaml experts out there
<arosales> I am looking at the cassandra charm
<marcoceppi> arosales: what's the problem?
<arosales> and it is currently failing proff as it is missing defatult value for some of the keys
<arosales> I am looking for a recomendaton on what to put for a default
<arosales> is it simply, "default:"
<marcoceppi> arosales: just put the default key, but leave it blank
<arosales> or
<marcoceppi> yes, that one
<arosales> default: ""
<arosales> marcoceppi: ack on just the default key, but blank, ie "default:"
<arosales> marcoceppi: thanks.
<marcoceppi> to keep current behavior, you should use the former, if blank string is needed (intead of unset) then the latter
<arosales> marcoceppi: ack.
<marcoceppi> it's the difference between "" and NULL which most charms wont' care about, but some do
<arosales> I'll check that doesn't cause any issues on the charm deploy
<arosales> ya I was wondering if some charms check for any value to be set
<arosales> and take action on that even if it is blank
<arosales> or specifically look for a Null, and then key off that
<arosales> that was my main concern
<lazyPower> hatch: no. The mismatch in versions between deployed and what you have installed locally wouldn't cause that. (moving convo here)
<hatch> ahh ok, just noticed it, thought I'd point it out
<hatch> :)
<hatch> I'm really hoping you can reproduce this
<hatch> heh
<lazyPower> hatch: i found the issue though
<lazyPower> your source option is coming back as undefined. and it should be defaulting to true.
<hatch> so is this a GUI bug?
<lazyPower> i'm pointing a finger at the devel branch of the gui,  I'm testing with -stable now and pending a deployment.
<lazyPower> it appears so
<hatch> interesting....
<hatch> wow if it is, it's good we caught it now and not next week lol
<hatch> lazyPower:  I'll also try on stable
<lazyPower> tvansteenburgh: http://paste.ubuntu.com/8253401/
<lazyPower> i ran into a promulgate bug - any idea what i've snagged?
<lazyPower> wait, i found it. when i cloned it it was missing the push branch it was sniffing for. I overrode the lp resource to use the ~charmers route and it worked.
<wesleymason> So...I have a theory that in a certain situation the containerName passed to OpenstackStorage.Remove() can be blank (perhaps if a destroy-environment is called after a failed destroy due to an API timeout, not sure), which will result in a DELETE being sent to the swift account URL (and in v1.7.x of swift marks the account on swift as deleted, which is a total PITA to then fix as it involves either a) waiting for a cron'd script to really delete the DB, or
<wesleymason> b) manually removing the sqlite3 DB file for the user on the swift replicas - both of which then results in the account being recreated based on the keystone perns for the user on next access. Now I have an easy fix for that (check for the error condition specifically in func Remove(...)), but not a clue how to replicate the issue, other than the fact that this is the only explanation I have for how my swift account got screwed after a failed destroy-enviro
<wesleymason> nment followed by a successful one.
<wesleymason> Any thoughts?
<wesleymason> probably better off asked in #juju-dev, but more after ideas or reactions like "that sounds ridiculs, naaah"
<wesleymason> *ridiculous
<hatch> lazyPower: so I was able to deploy it just fine in an old version of the GUI
<hatch> you the same?
<hatch> source isn't even set when running the juju-run command
<hatch> er, it's not in the list
<dpb2> If I give an http:// url to image-metadata-url, it still downloads with 'https://' is that expected?
<dpb2> and by downloads, I mean, downloads the images
<lazyPower> dpb2:are  you referring to simple streams?
<lazyPower> hatch: correct, it worked fine using a -stable revision of the gui.
<lazyPower> er, whatever is provided by default.
<lazyPower> hatch: i'd re-target the bug against the GUI and point to this LP resource for all the aggregated details.
<dpb2> lazyPower: maybe, I'm referring to the images for lxc creation that get downloaded form cloud-images.ubuntu.com
<lazyPower> dpb2: ah, yeah it defaults to secure comms to avoid MITM attacks.
<dpb2> lazyPower: but I changed it to http?
<dpb2> no good?
<lazyPower> natefinch: are there any schenanigans with fetching of the cloud image url structure?
<lazyPower> dpb2: so, offtopic - i've noticed you've incremented by 1, level up?
<dpb2> lazyPower: perhaps... you never know with me
<hatch> lazyPower: definitely
<hatch> thanks so much for the help
<dpb2> lazyPower: I think freenode didn't like my identity. :)
<lazyPower> hatch: np :) I smelled some schenanigans once I saw the deploy configuration in the bug.
<lazyPower> dpb2:  Freenode, like camelot - is a silly place.
<hatch> lazyPower: I've also got help on getting apache2 going for ghost and which options I need so very close to finally piecing together a bundle :)
<lazyPower> hatch: awesome! I look forward to seeing your bundle submission
<dpb1> lazyPower: I'm back!
<lazyPower> dpb1: decrement
<mbruzek> arosales, Github will not let me merge your change as-is.
<JoshStrobl> mbruzek, what is the issue?
<arosales> mbruzek:ok let me get this conflict resolved
<arosales> https://github.com/juju/docs/pull/154 is in question
<mbruzek> I have no problem with the *change* I need you to run the commands to get your branch current (is my guess).
<mbruzek> JoshStrobl, I see the following message:   We canât automatically merge this pull request.
<mbruzek> to resolve conflicts before continuing.
<JoshStrobl> arosales, maybe your master branch of your fork isn't updated?
 * JoshStrobl checks
<JoshStrobl> yea it is 186 commits behind juju master
<fuzzy> Hi there, I got a new Juju installation going, but on the command and control node, my logs are being spammed pretty bad.  Could someone tell me what is going on and possibly how to fix it? https://clbin.com/XZ63i
<arosales> ya it appears so
<mbruzek> hi fuzzy I have not seen that before.
 * arosales working to update
<mbruzek> fuzzy, what version of Juju are you using?
<arosales> mbruzek: I think if I push to master it will hit master
<arosales> mbruzek: to confirm your review was a +1?
<mbruzek> arosales, Confirmed.  It looks great
<arosales> mbruzek: ok thanks
<fuzzy> Sorry my wifi card likes to forget it exists
<mbruzek> fuzzy, have not seen that error before what version of Juju are you using?
<fuzzy> the latest one for 12.04 as of last night
<fuzzy> I followed the quickstart for manual provisioning
<fuzzy> is there an easy way to get juju to spit out version info?
<mbruzek> fuzzy, juju version
<fuzzy> 1.20.7-precise-amd64
<mbruzek> hrmm... That *is* the latest.
<mbruzek> What command are you running that it gives you this log output?
<fuzzy> cat /var/log/syslog
<fuzzy> well tail -n 100 /var/log/syslog
 * JoshStrobl is going reset his fork of juju/docs. git sometimes doesn't like to fast-forward so I magically end up with extra commits that are then ahead of juju/docs.
<mbruzek> fuzzy, I have several messages like that in my syslog
<mbruzek> fuzzy, so I guess that is normal.
<mbruzek> fuzzy, You can go to #juju-dev and ask the developers about those logs, but I see them all over my syslog too.
<sarnold> wow that's noisy..
<mbruzek> fuzzy, I am about to end my day I have to get to dinner.
<lazyPower> fuzzy: that looks like the migrations weren't run against the collection setting roles
<lazyPower> and yes, thats very noisy.
<fuzzy> ty :)
<fuzzy> about 10mb in 24 hours of logs
#juju 2014-09-05
<hatch> can I deploy a precise charm to a trusty host somehow in the CLI? a --force option or the like?
<rick_h_> hatch: no, I don't think it's allowed. I know we added logic to block that in the GUI.
<marcoceppi> hatch: you can branch it locally.
<hatch> marcoceppi: yeah that's what I ended up doing
<lazyPower> mkdir ~/charms/trusty && cd ~/charms/trust && charm get cs:precise/charm
<lazyPower> deploy and cross fingers
<lazyPower> 4/5 of the time, it 'just works' - unless its got apache2 embedded in the charm. With the files being moved around as of the trusty release, some charms just plain go supernova on deploy
<hatch> haha nah I was playing around with different providers seeing how much I could run on a single machine
<hatch> digital ocean is leagues ahead of ec2 in terms of performance
<lazyPower> Those SSD backed SAN's they use make all teh difference
<lazyPower> a lot of the latency you see on AWS is the EBS IO latency
<hatch> identical setups and the digital ocean was anywhere from 50-100ms faster per request at 20 concurrent requests
<lazyPower> less infrastructure to manage at present too :)  But I agree, I <3 DigitalOcean
<hatch> heh yeah true
<lazyPower> My entire personal infrastructure is up on there, the remnants of my business, and pet projects all go on DO
<hatch> I recently found out about a Canadian host https://www.clouda.ca/
<lazyPower> Oh I've looked at them for a client project. They were super nice.
<hatch> more expensive but 100% Canadian and running openstack :)
<hatch> I'm too tired, tomorrow I'll do the same tests as I did on ec2 and DO today
<hatch> see how they stack up for that extra $ :)
<lazyPower> Yeah, i'm wrapping up today's todo list that got a bit hairy. I spent an obscene amount of time cycling over something silly
<hatch> yeah, that happens hah
<hatch> I was loadtesting the built in sqlite setup as well
<lazyPower> I'm one of those crazy peeps that runs his ghost setup on the sqlite db
<hatch> honestly it didn't seem like it was having any trouble at 20concurrent requests
<lazyPower> hatch: you using loader.io to test?
<hatch> atm I was just doing ab on a fast connection
<hatch> so it wasn't 'true' load testing
<hatch> but gave a reasonable idea watching the cpu on the vm and the reporting from ab
<hatch> on DO the requests are highly CPU bound
<hatch> 20 concurrent puts it at high 80's
<hatch> so using something like mod_cache would be recommended to get good hardware utilization
<hatch> anyways I think I'll get the apache2 charm set up for my url redirects then fire apache2 and ghost up on something small and see how it pans out without mysql
<hatch> will have to set something up to do backups
<hatch> though
<hatch> anyways I'm outa-here, have a good night lazyPower
<JoshStrobl> Morning everyone
<JoshStrobl> jcastro, I got the t-shirt man, it is awesome (you were right) and it is now the softest one I own. Gonna take some pics of it (and me wearing it, of course).
<mbruzek> Hey guys I just created a pull request to link the new charm-review-process document that JoshStrobl created in our docs. https://github.com/juju/docs/pull/158
<rcj> [Question] Having a problem with a relation_set(...) which is failing silently http://paste.ubuntu.com/8260194/
<mbruzek> lazyPower, marcoceppi, evilnickveitch, arosales ^
<rcj> I'm running a hook via juju-run from a cron job and in there is a relation_set to change a variable in a peer relationship.  That isn't happening but I'm not getting errors.
<rcj> Larger context is @ https://bazaar.launchpad.net/~rcj/charms/trusty/ubuntu-repository-cache/trunk/view/head:/hooks/hooks.py#L167
<marcoceppi> rcj: you don't sepcify a remote unit
<marcoceppi> you have to loop through all the units in that relationship_id
<marcoceppi> using relation_list (I believe)
<evilnickveitch> mbruzek, done
<mbruzek> Thanks Nick.
<rcj> marcoceppi, thanks.  I'll try that.
<rcj> marcoceppi, on that same line of questioning. Can I set a configuration value where the key isn't in the config.yaml?  http://paste.ubuntu.com/8260290 This changes the 'rsync-mintues' on each invocation.
<rcj> marcoceppi, for the relation_set I don't see how you'd specify unit in charmhelpers.core.hookenv.relation_set().  What am I missing?
<arosales> mbruzek: thanks for working on getting pull 158 linked into the docs.  I think it would be valuable to have that in the side bar under "Charm Store Policy" with the name of "Charm Review Process"
<tvansteenburgh> anyone know what might cause this, considering that i can manually bootstrap this environment just fine: http://pastebin.ubuntu.com/8260380/
<mbruzek> arosales, that is what I did.
<arosales> mbruzek:
<mbruzek> arosales, are you seeing something different ?
<arosales> mbruzek: no, just behind :-)
<arosales> mbruzek: thanks for working on that
<marcoceppi> tvansteenburgh: it's trying to conecct to the internal IP
<marcoceppi> tvansteenburgh: do you have sshuttle running?
<tvansteenburgh> marcoceppi: it tries the public dns name first though
<tvansteenburgh> marcoceppi: no sshuttle running
<marcoceppi> tvansteenburgh: I wonder if this is new in 1.20.6
<rcj> marcoceppi, looking at relation_set() I don't know what you mean by looping through all the units.  I don't see a way to set a unit and I thought that I would set for the local unit and that would fire the X-relation-changed hook for the relation?
<marcoceppi> rcj: I'm trying to figure out now, it was in here
<marcoceppi> it exists for relation_get
<rcj> marcoceppi, that would make sense for relation_get because I would want to get the dictionary for that unit, but you can't set things on remote units, only the local unit's relation, right?
<marcoceppi> rcj: you can set relation data for remote units
<rcj> Now this is running via juju-run, so it's not in a relation hook with any of the environment that would bring.
<marcoceppi> at least
<marcoceppi> it should be
<marcoceppi> if you can get info for a unit but can't set info for a unit
<marcoceppi> it's like an unmatched side, or so it seams
<marcoceppi> seems*
 * marcoceppi experiments
<marcoceppi> okay, maybe not
<marcoceppi> what makes you think it's silently failing?
<rcj> I can drop into debug-hooks and run the same thing and not see the relation change.  Then the other peers in the relation aren't seeing cluster-relation-changed hooks firing.
<rcj> and the return code from 'relaation-set' on the cmdline is 0 while it doesn't show up in 'relation-get' output
<marcoceppi> relation settings aren't sent until that hook context closes
<rcj> I understand, so after that experiment I exit hook and none of the peers see the change hooks fired
<rcj> But relation-get after relation-set in the same hook should see the new value, right?
<marcoceppi> let me spin up a peer, my juju run example worked
<marcoceppi> http://paste.ubuntu.com/8260557/
<rcj> is "juju run --unit <unitID <cmd>" the same as "juju-run <unitID> <cmd>"?
<marcoceppi> rcj: one is from the unit the other is from the client
<marcoceppi> juju run --unit is from the client side
<rcj> And does it need to run as root on the client or can it be another use I created?
<marcoceppi> so, client being your desktop
<marcoceppi> from the unit you can run it unprivildged
<rcj> great
<rcj> marcoceppi, I can't recreate
<marcoceppi> rcj: can't recreate which?
<rcj> marcoceppi, the relation-set issue at present.  It's not that it's working, I just am having other issues that prevent me from getting that far with the charm.
<marcoceppi> rcj: ah, well let me know what happens either way
<rcj> marcoceppi, how about the config setting question though.... http://paste.ubuntu.com/8260290/
<rcj> 'rsync-minutes' isn't part of config.yaml, can I set something in the config that isn't in that file?
<rcj> When that hook is run it set's a new value each time.
<marcoceppi> rcj: I guess not, I'm not very familiar with the config stuff, I think cory_fu wrote it actually
<marcoceppi> rcj: it seems you can, > Store arbitrary data for use in a later hook.
<rcj> I din't know if there was an obvious bug in that code
<cory_fu> marcoceppi, rcj: Actually, tvansteenburgh wrote it, but yes, you can set arbitrary values into the config dict and they will persist as long as you call config.save()
<cory_fu> rcj: That seems like it should work and only generate a value once.
<marcoceppi> rcj: is this being run via juju-run as well, or hook context?
<tvansteenburgh> cory_fu, rcj: you don't even have to call save if you using @hook or Services Framework
<rcj> marcoceppi, that's beeing run in hook context
<cory_fu> tvansteenburgh: Did you add config.save() to the services framework when I wasn't looking?  :)
<tvansteenburgh> cory_fu yes
<rcj> tvansteenburgh, https://bazaar.launchpad.net/~rcj/charms/trusty/ubuntu-repository-cache/trunk/view/head:/lib/ubuntu_repository_cache/util.py#L165
<cory_fu> tvansteenburgh: Awesome!
<rcj> it's always called from hook context
<rcj> tvansteenburgh, calling function is https://bazaar.launchpad.net/~rcj/charms/trusty/ubuntu-repository-cache/trunk/view/head:/hooks/hooks.py#L118
<cory_fu> rcj: I think he meant from a @hook decorated function.  But, you're manually saving it anyway, so it shouldn't matter
<tvansteenburgh> rcj: yeah, so you don't actually need the save(), it'll happen for you
<tvansteenburgh> rcj: as long as you have the latest charmhelpers
<cory_fu> tvansteenburgh: Any idea why that config.get() would end up being false, then, if it's already been generated?
<rcj> tvansteenburgh, the problem I'm having is that each time that code is called it sets a new value
<rcj> and charmhelpers in my charm is very fresh
<marcoceppi> rcj: do you see the .juju-presistent file in the charm?
<rcj> marcoceppi, yes, .juju-persistent-config is present and has the latest value
<tvansteenburgh> rcj: yeah, i think i need to override __getitem__ to make it work the way you expect
<tvansteenburgh> rcj: but for now you could do `if not config.previous(var)`
<cory_fu> tvansteenburgh: So, if you persist an arbitrary value, it will not show up in the current config but only in the previous?
<cory_fu> That does seem like a bug, since storing arbitrary values is explicitly listed as a feature
<tvansteenburgh> i'm gonna post a MP with a fix momentarily
<rcj> tvansteenburgh, so I need to get the value as config['rsync-minutes'] on the first invocation and then as config.previous('rsync-minutes') for all future runs?
<rcj> tvansteenburgh, ah, I'll wait for the MP and merge it into my tree instead
<tvansteenburgh> k
<rcj> tvansteenburgh, can you ping me with a patch when it's ready?
<tvansteenburgh> rcj: certainly
<rcj> tvansteenburgh, thanks
<tvansteenburgh> rcj: https://code.launchpad.net/~tvansteenburgh/charm-helpers/fix-config-lookups/+merge/233558
<tvansteenburgh> marcoceppi: got time for a quick review/merge of that? ^
<marcoceppi> tvansteenburgh: yeah
 * marcoceppi loks
<tvansteenburgh> marcoceppi:  hang on
<tvansteenburgh> marcoceppi: i want to change something
<marcoceppi> go on
<tvansteenburgh> marcoceppi: ok i'm done for real now
<marcoceppi> tvansteenburgh: you're lucky I'm lazy ;)
<tvansteenburgh> haha
<natefinch> arg, how can open port not be idempotent by default? :/
<natefinch> marcoceppi: ^^   I reran a failed install and got "cannot open ports 80-80/tcp on machine 5 due to conflict"  how am I supposed to handle that?
<rcj> marcoceppi, I can't recreate the issue with the relation_set() not propagating.  The problem, if there still is one, must be on my side.  Thanks for your help.
<rcj> tvansteenburgh, thanks
<rick_h_> marcoceppi: got a sec to chat an idea out loud?
<marcoceppi> rcj: I will in about 20 mins, otp
<marcoceppi> rick_h_: * ^
<rick_h_> marcoceppi: rgr ty
<marcoceppi> rick_h_: back
<rick_h_> marcoceppi: cool
<rick_h_> marcoceppi: invite otw
<allomov> hey, I have a problem with running juju on Openstack
<allomov> it seems that floating IPs are not set to instances
<allomov> I have set use-floating-ip to true in env yml
<allomov> the question for me now: what network uuid I need to pass to network option in env yml (private or public)
<marcoceppi> allomov: that's a good question, you'll want to pass the public one IIRC
<allomov> marcoceppi: thank you for answer.
<allomov> marcoceppi: unfortunately I still get this error https://gist.githubusercontent.com/allomov/188131c84fdbcbab5ea8/raw/4bdabe95471797c0d6aad4829557a23d43d4e30d/fail-juju.log
<allomov> here is my env file https://gist.githubusercontent.com/allomov/188131c84fdbcbab5ea8/raw/f4068e094ce52db43008e825b111645f28854381/juju.yml
<marcoceppi> allomov: 1.20.6 ?
<allomov> marcoceppi: how did you know )
<marcoceppi> lucky guess :)
<allomov> marcoceppi: yes, it is
<marcoceppi> (and my goldfish memory from yesterday hasn't worn off, glad you got the imagestream stuff sorted)
<allomov> hah
<allomov> yes, it's me
<allomov> I generated image metadata to ~/.juju/metadata with `juju generate-image` command.
<marcoceppi> whew, that would have been really embarassing if it wasn't you
<marcoceppi> allomov: well the bootstrap error I don't t hink is related to networking
<allomov> I even got it running, at least it started to bootstrap environment and cerated a node
<allomov> but since I pointed to the private network it couldn't ssh to bootstrap node
<marcoceppi> allomov: well that log shows a failure to bootstrap / find the tools/image data
<allomov> after that I removed jenv file (to apply new configuration)
<allomov> marcoceppi: so I need to point a tools url I guess ?
<marcoceppi> allomov: yeah, so after you generate teh metadata you need to host the images metadata and the tools somewhere (usually in the object store with a publically accessible bucket)
<marcoceppi> then set image-metadata-url and tools-metadata-url in your environments.yaml to that public location
<allomov> could it be a local file system ?
<marcoceppi> it needs to be accessible by the bootstrap node
<allomov> ok, will try to go this way
<allomov> thank you
<allomov> marcoceppi: thank you
<marcoceppi> allomov: sure, sorry you're hvaing such a rough go at it. If you get it running let me know where we can improve our documentation / workflow (or email the mailing list juju@lists.ubuntu.com)
<marcoceppi> you're certainly not the only one running a private openstack cloud
<marcoceppi> I'll also be around most of tomorrow/Sunday too if you need more help
<allomov> marcoceppi: bad news, still can't make it run.
<allomov> marcoceppi: bootstrap node is created, but I can't get access to it.
<marcoceppi> allomov: can you re-bootstrap with --debug flag?
<allomov> marcoceppi: sure
<marcoceppi> and paste the output (careful, some credentials might leak at the topofthe log
<allomov> marcoceppi: the point is I can't get access to created instance
<marcoceppi> sure, running --debug will give a very verbose output client side
<allomov> marcoceppi: here it is https://gist.githubusercontent.com/allomov/188131c84fdbcbab5ea8/raw/24a64a47a6cde78e66db830c57a2dfd57534289e/gistfile1.txt
<allomov> marcoceppi: deployment is stucked on ssh
<allomov> I can create node in the same network and with the same image (the image I pointed creating metadata) there and ssh to it
<allomov> marcoceppi: machine logs from openstack web console are different by the way for this two cases
<marcoceppi> allomov: I'm guessing 172.16.0.84 is not public ip
<allomov> it's a public network for me
<marcoceppi> so it looks like the floating ip is getting added?
<marcoceppi> that SSH prompt might go on for a while
<marcoceppi> allomov: it's basically a loop until the instance registers
<marcoceppi> > Attempting to connect to 172.16.0.84:22
<allomov> marcoceppi: it can't ssh for 10 m
<marcoceppi> shows that it's assigned that IP
<marcoceppi> or at least that's what it thinks the IP is
<marcoceppi> can you reach that IP now? is the instance up in horizon?
<allomov> marcoceppi: no, I can't
<allomov> marcoceppi: I tried to create new node with openstack web console with the same network and image, and I can ssh to it
<marcoceppi> allomov: bleh, that's lame
<marcoceppi> is the IP actually allocated and added to that instance in horizon?
<allomov> marcoceppi: I have different outputs for juju machine and for machine created manually
<marcoceppi> allomov: different how?
<allomov> marcoceppi: I mean logs in openstack web console
<allomov> marcoceppi: here is log for machine created with juju https://gist.githubusercontent.com/allomov/188131c84fdbcbab5ea8/raw/34140f9c803ff71a466c73e36b536bdc45fa95b9/machine-log-1
<allomov> marcoceppi: here is a log for machine created manually with the same image https://gist.githubusercontent.com/allomov/188131c84fdbcbab5ea8/raw/1efaaa681fd2a31fef4e12d23b8e40fcf1d758f5/machine-log-2
<marcoceppi> so, cloud init isn't running on the juju machine
<marcoceppi> allomov: are you using Ubuntu Server or Ubuntu Cloud images? I'm guessing the later?
<marcoceppi> latter*
<allomov> marcoceppi: I used ubuntu image that was already in openstack
<allomov> marcoceppi: could you tell how can I check it ?
<marcoceppi> Not entirely sure
<allomov> marcoceppi: do I need download and install other image ?
<marcoceppi> allomov: I'm nto sure, and I don't want to lead you in the wrong direction
<marcoceppi> I'm reaching the end of my knowledge with troubleshooting openstack clouds
<allomov> marcoceppi: ok, will stay on this stage for now. thank you for your help. see you.
<marcoceppi> You could try to add a new image, then you'd have to update the image-metadata, etc, but http://cloud-images.ubuntu.com/trusty/current/ is where we house all our cloud images which is the basis for all our cloud provided images (ec2, hp, azure, etc)
<marcoceppi> You should be able to add the amd64.root.tar.gz to openstack and try that if you exhaust other options
<marcoceppi> I really wish I had more to offer or insights
<dpb1> Trying to install the juju-gui charm: http://paste.ubuntu.com/8264500/
<dpb1> :(
<marcoceppi> dpb1: wat. What version Ubuntu is this?
<dpb1> trusty, up to date
<dpb1> I was just going to try it here
<dpb1> worked fine on an lxc here.. who knows
#juju 2014-09-06
<Ponyo> Hi there, I just tried to install a charm and I have an error.  How do I look at the details of the error? http://hastebin.com/apuzupizuf.sm
<sarnold> Ponyo: hmm, it seems odd to me that you're in /root but logged in as 'juju' -- are the configs in ~juju/.juju/ or ~root/.juju/ ?
<Ponyo> ~juju/.juju
<Ponyo> it's just me being lazy
<sarnold> ahokay :)
<Ponyo> notice juju@juju
<Ponyo> only root can read/write /root
<lazyPower> Ponyo: when a charme rrors, there's a few options
<lazyPower> 1) you can juju debug-log and see if the traceback is in there, but what i find really handy is launching a debug-hooks session.
<lazyPower> juju debug-hooks meteor/0
<lazyPower> this will open a tmux session attached to the charm - but wont be very interesting
<lazyPower> you'll need to open another terminal, and issue 'juju resolved -r meteor/0'
<lazyPower> that will tell juju to re-execute teh last failed hook on the service, which you'll notice gets trapped in your tmux session
<Ponyo> stby
<lazyPower> now you can run the hooks manually and debug the environment to see why it failed.
<lazyPower> Ponyo: https://juju.ubuntu.com/docs/authors-hook-debug.html  - as well as http://youtu.be/75gKKnv_ze8?t=16m8s
<lazyPower> that covers debug-hooks both in text, and another live example in a troubleshooting charm school
<JoshStrobl> hey marcoceppi, I noticed the https://juju.ubuntu.com/docs/charm-review-process.html doc isn't rendering "notes" markdown (!!! Note:). I compared it with the Juju wiki page for Markdown and noticed that it does in fact match. I checked out https://juju.ubuntu.com/docs/authors-charm-quality.html and it has a working Note, but using a patch I submitted a while back that changed it to **Note: **. Is !!! Note: broken, is there not
<JoshStrobl> meant to be a space between !!! and Note, etc.
<JoshStrobl> marcoceppi, I also noticed the patch that mbruzek did at https://github.com/juju/docs/pull/152/files (charms-working-with-units.md) and (howto-offline-charms) to revert some of my **Note: ** changes does break in the juju.ubuntu.com docs. would you be OK with me filing an issue about the broken !!! Note: and doing a temporary patch of the botched files until the issue is resolved?
<JoshStrobl> doc bug filed: https://github.com/juju/docs/issues/159
<tvansteenburgh> fuzzy: you are the fuzzy who emailed me about the meteor charm?
<fuzzy> ep
<fuzzy> yep
<tvansteenburgh> ok cool. i figured out the problem, just gotta get it reviewed and updated in the store
<fuzzy> np
<fuzzy> In the future would you prefer that as a github issue?
<tvansteenburgh> fuzzy: sure, that'd be great
#juju 2014-09-07
 * arosales reviewing https://code.launchpad.net/~charmers/charms/precise/jenkins/trunk
<tvansteenburgh> hey charmers, remove from queue: https://code.launchpad.net/~brad-marshall/charms/precise/squid-reverseproxy/http-port-config/+merge/185204
<bcsaller> marcoceppi:  done lp:~web-brandon/charms/precise/node-app/install-fix into lp:charms/node-app
<mbruzek> reviewing https://code.launchpad.net/~brad-marshall/charms/precise/squid-reverseproxy/fixed-ports-path/+merge/184023
 * lazyPower-sprint is reviewing https://code.launchpad.net/~mattyw/charms/precise/mongodb/auth_experiment/+merge/162887
 * kwmonroe is reviewing https://code.launchpad.net/~george-edison55/charms/precise/stackmobile/added-icon/+merge/183274
 * aisrael is reviewing https://bugs.launchpad.net/charms/+bug/1360205
<mup> Bug #1360205: Charming Hortonworks Apache Tez <Juju Charms Collection:New> <https://launchpad.net/bugs/1360205>
<bcsaller> marcoceppi: review  	lp:~hloeung/charms/precise/rsyslog/trunk into lp:charms/rsyslog
<cory_fu> Reviewing: https://code.launchpad.net/~crhrabal/charms/precise/nagios/trunk/+merge/195145
<cory_fu> https://code.launchpad.net/~crhrabal/charms/precise/nagios/trunk/+merge/195145 needs a charmer to merge.  It's already +1 twice and is trivial
<cory_fu> Reviewing: https://code.launchpad.net/~stub/charms/precise/postgresql/bug-1281600-log_temp_files/+merge/224250
<lazyPower-sprint> marcoceppi: done w/ MongoDB merge
<lazyPower-sprint> cory_fu: merging for you
<cory_fu> Thanks
<mbruzek> marcoceppi, done with squid-proxy/fixed-ports-path review
<bcsaller> review: https://code.launchpad.net/~cmars/charms/precise/haproxy/trunk/+merge/201458
<mbruzek> mbruzek reviewing https://code.launchpad.net/~hloeung/charms/precise/rsyslog/trunk/+merge/134024
<cory_fu> https://code.launchpad.net/~stub/charms/precise/postgresql/bug-1281600-log_temp_files/+merge/224250 needs a charmer to merge, with two +1's
<cory_fu> Reviewing: https://code.launchpad.net/~evarlast/charms/precise/hive/encoding/+merge/226540
<lazyPower-sprint> Done w/ cory_fu's nagios merge --- cory_fu the upstream readme had diverged and already had a fix.
<mbruzek> reviewing https://code.launchpad.net/~jose/charms/precise/nyancat/port-changing+amulet-tests/+merge/216352
<jcastro> low hanging fruit: https://code.launchpad.net/~moon127/charms/precise/storage/fstab-fix/+merge/232382
<marcoceppi> working on https://code.launchpad.net/~michael.nelson/charms/precise/nrpe/install-nagios-plugins-basic/+merge/206149
<jcastro> another easy one, I've +1ed, need a charmer to ACK/merge: https://code.launchpad.net/~dannf/charms/precise/mediawiki/restrict-ppa-to-precise/+merge/233062
<aisrael> marcoceppi: https://code.launchpad.net/~jacekn/charms/precise/haproxy/haproxy-stats-socket/+merge/207263
 * aisrael is reviewing https://code.launchpad.net/~jose/charms/precise/buildbot-master/1297558-fix/+merge/212751
<kwmonroe> mbruzek, por favor, put https://code.launchpad.net/~george-edison55/charms/precise/stackmobile/added-icon/+merge/183274 into work-in-progress.
<aisrael> Needs moving to work in progress: https://code.launchpad.net/~jose/charms/precise/buildbot-master/1297558-fix/+merge/212751
<mbruzek> kwmonroe, done.
<aisrael> Also needs moving to work in progress: https://code.launchpad.net/~jose/charms/precise/buildbot-slave/1297562-fix/+merge/212752
<aisrael> Needs moving to work in progress: https://code.launchpad.net/~james-sapara/charms/precise/redis-master/config-options/+merge/200732
<jcastro> https://code.launchpad.net/~dannf/charms/precise/mediawiki/restrict-ppa-to-precise/+merge/233062
<jcastro> aisrael, https://code.launchpad.net/~moon127/charms/precise/storage/fstab-fix/+merge/232382
<aisrael> ^^ got it
<jcastro> aisrael, https://code.launchpad.net/~paulgear/charms/precise/wordpress/fix-git-submodules/+merge/232962
<aisrael> marcoceppi: needs to be moved to work in progress: https://code.launchpad.net/~jose/charms/precise/joomla/fix-various/+merge/212895
<whit> jcastro, hit me
<aisrael> jcastro: feed me more
<jcastro> https://code.launchpad.net/~paulcz/charms/precise/logstash-agent/trunk/+merge/188241
<jcastro> aisrael, https://code.launchpad.net/~jose/charms/precise/joomla/fix-various/+merge/212895
<mbruzek> aisrael, done
<aisrael> jcastro: need another
<jcastro> https://code.launchpad.net/~chris-gondolin/charms/precise/nrpe-external-master/trunk/+merge/227530
<cory_fu> Reviewing: https://code.launchpad.net/~gandelman-a/charms/precise/jenkins/offline_install/+merge/189180
<lazyPower-sprint> Ok, ready for another
<lazyPower-sprint> jcastro: !
<jcastro> aisrael, https://code.launchpad.net/~evarlast/charms/trusty/mediawiki/trusty-port/+merge/226752
<mbruzek> reiewing https://bugs.launchpad.net/charms/+bug/1353197
<mup> Bug #1353197: hortonworks hdp2.1 zookeeper charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1353197>
<jcastro> https://code.launchpad.net/~xander-h/charms/precise/owncloud/ceph-support/+merge/212588
<jcastro> lazyPower-sprint, ^
<jcastro> lazyPower-sprint, https://code.launchpad.net/~moon127/charms/precise/storage/fstab-fix/+merge/232382
<jcastro> mbruzek, https://bugs.launchpad.net/charms/+bug/1325700
<mup> Bug #1325700: New Charm: Dell OpenManage Server Administrator (OMSA) <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1325700>
<whit> jcastro, hit me
<cory_fu> lazyPower-sprint, mbruzek or whomever: https://code.launchpad.net/~gandelman-a/charms/precise/jenkins/offline_install/+merge/189180 should be ok to merge (with conflict resolution), though it's been a long time since it was proposed.  Bug is still open, though, and it seems reasonable
<cory_fu> jcastro: hit me
<jcastro> cory_fu, https://code.launchpad.net/~moon127/charms/precise/storage/fstab-fix/+merge/232382
<whit> jcastro, HIT ME
<lazyPower-sprint> merged: https://code.launchpad.net/~moon127/charms/precise/storage/fstab-fix/+merge/232382
<lazyPower-sprint> jcastro: we doin 1 more?
<jcastro> lazyPower-sprint, https://code.launchpad.net/~gnuoy/charms/trusty/mysql/lp-1353135/+merge/230932
<jose> arosales, tvansteenburgh, bcsaller, mbruzek, lazyPower-sprint, kwmonroe, aisrael, cory_fu, jcastro: good work on triaging the queue, guys! /me gives all of you a cookie
<jose> and mup deserves a cookie too
<arosales> jose, ya the team is taking care of bizness at the sprint :-)
<jose> I noticed :)
<jose> I'm fixing my old broken MPs too
<mbruzek> jose,  thanks for noticing!
<kwmonroe> mbruzek, would you set this to Work in Progress too: https://code.launchpad.net/~gnuoy/charms/trusty/rabbitmq-server/lp-1355848/+merge/231528
<mbruzek> kwmonroe, there is a long history with rabbitmq
<mbruzek> and the default values.
<mbruzek> kwmonroe, we have to talk about this one.
<kwmonroe> ack - thx mbruzek
<jose> mbruzek: https://code.launchpad.net/~jose/charms/precise/joomla/fix-various/+merge/212895 is one you'll probably not nack :P
<mbruzek> jose on it.
<jose> thanks!
#juju 2015-08-31
<h0mer> hey can anyone help with me trying to SSH into a glance server (deployed using Cannonical openstack/juju)?  I dont know what key or username to use
<hazmat> h0mer: juju ssh glance/0  .. user is typically 'ubuntu' on the cloud images used by juju.
<h0mer> yep got it, but I had to ssh into the landscape server first (I'm using the cannonical openstack distro), which is what puzzled me
<h0mer> thanks
<h0mer> anyone know how I can restart the keystone component from juju?
<coreycb> h0mer, I'm not sure there's a direct way to just restart services, but you could toggle a config option on and then off to restart them.  gnuoy, do you know a better way?
<coreycb> h0mer, assuming verbose is already set to false.  juju set keystone verbose="true"; juju set keystone verbose="false".
<coreycb> h0mer, you could also juju ssh in to the units and manually restart services.  that should be fine.
<stub> Can I get a fresh run of http://reports.vapour.ws/all-bundle-and-charm-results/lp%3A%7Estub%252Fcharms%252Ftrusty%252Fpostgresql%252Frewrite ? I think the remaining rough edges are gone from the integration tests.
<jose> stub: sure, I'll kick the tests in a bit
<stub> jose: ta. whenever convenient - I won't be looking at any results tonight.
<jose> stub: they should start running soon. just clicked the butto
<jose> niedbalski: ping
<niedbalski> jose, hey :)
<jose> niedbalski: have a min for a quick PM?
<niedbalski> jose, sure.
<pmatulis> when destroying a juju environment, what is the point of the '-e <environment>' if you can specify the environment like this: juju destroy-environment <environment-name> ?
<ddellav> pmatulis, i'm not sure what the actual reason is but If i had to guess It's either 1 of 2 things. Either the -e or inline option are deprecated to maintain functionality with old scripts, OR the -e option allows you to specify multiple environments where the inline option does not.
<ddellav> again, just a guess.
<lazyPower> pmatulis: its a positional arg now, but hositorically it was not
<lazyPower> i beleive that is an artifact
<ddellav> right, deprecated option from early dev.
<ddellav> makes sense
<lazyPower> ddellav: watching this plumgrid deploy on bare metal is kinda mesmerizing... lots of services lots of scrolling text
<ddellav> you should deploy openstack sometime ;)
<lazyPower> ddellav: plumgrid contains openstack <3
<lazyPower> they are a bolt on SDN for carrier grade virtual network functions (NFV in teleco terms), you'll be seeing more of this after i finish my review(s) today
<ddellav> do I have a video review to look forward to?
<lazyPower> Possibly, but not in the immediate future. I'm routing through some internal cloudy type stuff that I Would have to capitalize on, and i'm pretty sure beisner has only let me the resources for the time being
<lazyPower> but with some coordination, sure
<lazyPower> https://insights.ubuntu.com/2015/04/15/plumgrid-joins-canonical-ubuntu-openstack-interoperability-lab/
<lazyPower> here's the press release when they signed up for CPP and their overview
<ddellav> nice
<pmatulis> ddellav, lazyPower: muchos
<lazyPower> denada
<pmatulis> lazyPower: is it 'destroy-service' or 'remove-service'? another deprecation?
<lazyPower> juju destroy-service is the perferred nomenclature i would think
<marcoceppi> pmatulis: neither are being deprecated?
<pmatulis> marcoceppi: why are there 2?
<marcoceppi> pmatulis: same reason there's juju init and juju generate-config
<marcoceppi> or juju terminate-machine and juju destroy-machine
<pmatulis> marcoceppi: which is?
<marcoceppi> aliases help improve discoverability and people probably couldn't decide on the best verbiage
<pmatulis> marcoceppi: from a user's point of view, and from the Doc team's POV, it's bad to have duplication of commands. i suggest standardizing
<marcoceppi> pmatulis: well that's not going to happen at all until juju 2.0 because we don't break backwards compatibility
<marcoceppi> pmatulis: I haven't heard any users complain
<pmatulis> marcoceppi: i'll follow up somehow. thanks for the info
<marcoceppi> pmatulis: What problem are you trying to solve?
<pmatulis> marcoceppi: globally, making juju easier to use. specifically, getting the documentation in shape. i don't want to have to write 'use this command or that command, they're the same' all over the place
<marcoceppi> pmatulis: then just pick one, that's what Nick's done in the past.
<marcoceppi> they're aliases, not slightly different invocations
<pmatulis> this is beyond my mandate on the official docs but i would *like to* avoid users following some online doc that uses one and then having them encountering another one, possibly the official ones, that use another. it's just confusing and, to me, leaves a bad taste in the mouth b/c i'm not sure whether they are equivalent or whether one is a different invocation. the commands.md file also uses 'destroy-service' and then ...
<pmatulis> ... underneath it uses 'remove-service'
<lazyPower> pmatulis: i'm +1 for having consistent verbiage used throughout our docs and help commands
<lazyPower> pmatulis: but i also think to marcoceppi's point, since we're maintaining backwords compat in the 1.x series the path forward today is to file bugs where appropriate to make it consistent, update the docs to use that same bit, and turn a blind eye to the aliases. We can address those as people ask
<pmatulis> lazyPower: i'm fine with waiting until 2.x but we should just decide at that time and then go forward
<ted> I heard a rumor on the street that Juju does some type of YAML validation.
<ted> Does it? How does it do that?
 * ted may have just ended up in the wrong part of town
<wolsen> skylerberg, ping
<lazyPower> ted: hey there o/
 * ted waves
<lazyPower> ted: when you say juju does yaml validation, can you expand on what you're expecting with that statement? as it seems pretty broad
<ted> lazyPower, Like has a schema and checks to see if the YAML conforms to that schema.
<lazyPower> ted: well it does some ridumentary things like check for sub keys of units, and it has a standardizd format for bundles
<lazyPower> but aside from that, the yaml validation is largely on trial/error with deployer and quickstart depending on your flavor of the moment
<ted> Okay, but there's no definition format that you're using.
<lazyPower> https://jujucharms.com/docs/stable/charms-bundles
<lazyPower> this is the overview of that format, and if i dig hard enough I may be able to surface an old bundles format doc
<lazyPower> we're currently changing that spec and work is underway (and may have been completed) to finalize teh bundle v4 spec. Whats on thta page is the bundle v3 spec
<lazyPower> but if you're looking for a pure schema document, I don't beleive one exists today
<lazyPower> but i could be wrong
<lazyPower> rick_h_: do you have anything to add here? we're talking bundles and specs ^
<ted> Ah, okay. I won't be able to steal anything then :-)
<lazyPower> ted: the other side of this is metadata/config in charms, and we do have schema validation on those baked into juju
<ted> That file is getting complex, you guys are gonna need XML soon.
<lazyPower> Ayyyyy
 * JoshStrobl throws up at XML
<lazyPower> ted: i doubt we'll convert to XML :)
<JoshStrobl> Oh wait...did I do that out loud?
<lazyPower> JoshStrobl: i would expect no less ;) o/ how are ya
<JoshStrobl> lazyPower, doing well, how are you?
<lazyPower> JoshStrobl: trying to complete my todo list so i can get into the audio lab
<lazyPower> so good :) but busy
<JoshStrobl> lazyPower, yea I caught the latest vibes you put up, loved it :)
<lazyPower> THe raw studio sessions?
<lazyPower> man those were terribad
<JoshStrobl> lazyPower, any pointers to where I can catch up on Juju stuff? Like actual Youtube content to grind through.
<lazyPower> new deck, new software, new everything... and hooooo i twas rough.
<JoshStrobl> lazyPower, nah it wasn't bad man
<lazyPower> JoshStrobl: yeah, the juju office hours for the last 3 months are a brilliant place to catch up
<JoshStrobl> lazyPower, figured as much :D
 * JoshStrobl has been out of the Juju loop for way too long and trying to catch up on the mailing list archive (still subscribed to juju mailing list) is like a needle in a haystack :D
<lazyPower> yes, yes it is
<lazyPower> we got chatty while you were away
<lazyPower> we're publishing the current state of the union more often, including review-q highlights et-al
<wolsen> skylerberg, I added a comment to your mp, ping me if you have questions on it/want to chat about it a bit
<JoshStrobl> lazyPower, yea I noticed as much (about the chattiness, changed to daily digests due to the activity - which is awesome because it is lively)
<lazyPower> :) that makes me happy
<lazyPower> if we're getting so chatty you went to digest vs the 12 emails a month it used to be
<JoshStrobl> It is also nice because I always know it is 1500, my phone chimes with the Juju daily digest :DD
<lazyPower> its the little things ;)
 * JoshStrobl begins watching playlist of Juju office hours to get up-to-speed
<JoshStrobl> That moment when you see Jorge pound the up key and enter...then 5 minutes later finally opting to use "watch" :DD
<JoshStrobl> Or was it Marco...
<JoshStrobl> Oh...it was Marco. Thanks non-intuitive Hangouts UX
<jcastro> JoshStrobl: plenty of time for the juju charm summit
<jcastro> see the list
<jcastro> lmk if you want to apply for sponsorship
<skylerberg> wolsen: I read your review. I think your approach makes sense, the only reservation I have is that it is more complex than my current approach.
<JoshStrobl> jcastro, no thanks :) doing this for my sanity mainly :D
<jcastro> ack
<wolsen> skylerberg, there's no doubt that it is slightly more complex and it results in having to make changes to more charms, but I do think its the right approach and provides the best overall user experience
<skylerberg> wolsen: Yeah, I agree. I will change the code and update the merge request.
<wolsen> skylerberg, if there's anything I can do to help, let me know
<skylerberg> wolsen: Will do. Thanks.
<wolsen> skylerberg, and sorry I wasn't on the same page with you before :(
<skylerberg> wolsen: No worries, man.
<rick_h_> lazyPower: sorry, sprinting and just now trying to catchbacklog
<rick_h_> lazyPower: ted the juju actions work uses a spec called "json schema" and that's used for a pure schema validation and it's on the todo to add that to the GUI, update juju config schema to use it down the road, etc. http://json-schema.org/ and https://github.com/juju/gojsonschema
<ted> rick_h_, Cool, thanks!
<lazyPower> thanks rick_h_ :) i knew you'd have the magic answer
<rick_h_> lazyPower: :)
<rick_h_> lazyPower: fyi, email reply inbound to the big thread I'd love to get your feedback on
<skylerberg> When a new relation is created does it trigger a relation-changed event after triggering relation-joined?
<JoshStrobl> skylerberg, I do believe it is ran after -joined.
<JoshStrobl> https://jujucharms.com/docs/stable/authors-charm-hooks#[name]-relation-changed
<lazyPower> skylerberg: it does
<lazyPower> skylerberg: the sequence is -joined, -changed (optionally run more than once depending on relation-set commands)
<skylerberg> JoshStrobl, lazyPower: Thanks
<lazyPower> inversely, -broken (runs when you remove relation, they still have communication established between the two), and -departed (no connectivity between the units. ship has sailed, adios)
<cholcombe> ok question time
<cholcombe> with relation_get am i supposed to return if i don't get the info i need in the hopes that the charm gets called again with more info?
<marcoceppi> cholcombe: yes
<cholcombe> marcoceppi, ok.  how do i know the difference in code between i didn't get a value and i'm never getting that value and i should fail?
<marcoceppi> cholcombe: you don't, that's why we have extended status
<marcoceppi> cholcombe: ie status-set waiting "waiting for x, y, z value to continue"
<marcoceppi> cholcombe: and as long as the other charm implements the relation protocol properly (and isn't in an error state) all should be swell
<JoshStrobl> oh lol. So catching up on Juju Office Hours. In the 30th July episode, when Jorge said "dog might wander in and out and talk about dev ops", literally lol'd. And suddenly makes me want to have some sort of Juju dog sweater...and I don't even have a dog.
<marcoceppi> JoshStrobl: if jcastro has anything to say about it, he will tell you to get a beagle
<JoshStrobl> :D
<cholcombe> marcoceppi, ok cool i'll set the status so that people know what's going on
<marcoceppi> cholcombe: +1 always use status all the time and everywhere
<cholcombe> :)
<marcoceppi> it's basically my drop in replacement for juju-log and it's amazing
<cholcombe> interesting
<cholcombe> that sounds like quite a good idea to me
<cholcombe> you can see at a glance with status what is goign on
<marcoceppi> cholcombe: yeah, and with juju-run you can have processes out of band of hooks set status :D
 * marcoceppi picks up all the lightbulbs falling off cholcombe's head
<cholcombe> marcoceppi, fancy :)
<cholcombe> haha
<cholcombe> marcoceppi, yeah this is giving me a lot of ideas of code i need to chance
<cholcombe> change*
<marcoceppi> cholcombe: as a protip, you can query the current status with status-get from the hook, as to prevent friendly "non-blocked" status from updating a blocked, waiting, or maintenance state `juju help-tool status-get`
<cholcombe> marcoceppi, nice tip!
<cholcombe> marcoceppi, i feel as though you just leveled me up haha
<marcoceppi> yeah, extended status is like the best kept secret in charming
<marcoceppi> I want to dedicate an entire summit session to "secrests in juju that shouldn't be secrets"
<cholcombe> yeah i like that idea
<marcoceppi> jcastro: ^
#juju 2015-09-01
<pmatulis> is there some trickery in specifying a public SSH key with 'juju authorised-keys add <key>' ?
<pmatulis> i'm seeing this: http://paste.ubuntu.com/12242048/
<beisner> fyi thedac, merge collision alert on rmq.  something landed, you'll need to rebase and resolve conflicts in your cluster wip.
<lazyPower> pmatulis: should be juju authorized-keys add `cat ~/.ssh/somekey.pub`
<lazyPower> the import should have worked w/ LP data as well considering its using ssh-import-id
<lazyPower> that broke for you? :-\
<lazyPower> pmatulis: do you see the key you attempted to add with juju authorized-keys list?
<pmatulis> lazyPower: yeah, lol, you have to paste the key at the terminal. just figured that out
<pmatulis> lazyPower: should really allow to point at a key file
<lazyPower> pmatulis: sounds like an excellent bit-sized bug
<beisner> thedac, commented @ bug 1486177.  just clarifying that today's rmq merge doesn't resolve the cluster race bug.   while it may resolve issues in some scenarios, not in ours.
<mup> Bug #1486177: 3-node native rabbitmq cluster race <amulet> <backport-potential> <openstack> <uosci> <rabbitmq-server (Juju Charms Collection):Confirmed for thedac> <https://launchpad.net/bugs/1486177>
<beisner> wolsen, niedbalski fyi ^
<wolsen> beisner, is this the one I did a review on earlier?
 * wolsen checks
<wolsen> beisner, yargh, I caused that merge conflict merging another change
<wolsen> beisner, the merge conflict isn't bad - I can take care of it in the merge
<wolsen> beisner, yep easy-peasy
<beisner> wolsen, actually i'd like to get thedac 's other cluster fixes rebased, as i'm syncing that into my amulet-test-refactor branch to confirm resolution before merge.  but yeah, the conflict doesn't look to bad.  but i'm a bit blocked until we do that <
<wolsen> beisner, heh
<wolsen> beisner, just pushed
<wolsen> :)
<beisner> or that!  :-D
 * beisner rebases
<wolsen> thedac ^^
<pmatulis> lazyPower: your request is my command: https://bugs.launchpad.net/juju-core/+bug/1490789
<mup> Bug #1490789: [juju authorised-keys add] cannot specify a key file <juju-core:New> <https://launchpad.net/bugs/1490789>
<lazyPower> pmatulis: <3
<beisner> ping wolsen
<beisner> wolsen, niedbalski, thedac - i'd recommend reverting rmq/next 107 and 108:  http://paste.ubuntu.com/12242485
<beisner> ie. rmq/next is completely bust atm
<beisner> whereas at r106, it was only ~50% bust, and only when clustering
<beisner> then i'd like to get thedac 's fixes landed, then rebase my amulet-test-refactor branch, get those landed so we can reliably test proposals, and go from there.
<beisner> ie. please revert and freeeeeeeze rmq/next, pending resolution of CRIT bug 1486177
<mup> Bug #1486177: 3-node native rabbitmq cluster race <amulet> <backport-potential> <openstack> <uosci> <rabbitmq-server (Juju Charms Collection):Confirmed for thedac> <https://launchpad.net/bugs/1486177>
<wolsen> beisner, done
<jamespage> gnuoy, landed the hugepages branch for nova-compute
<gnuoy> jamespage, fantastic, thanks
<gnuoy> cd -
<g3naro> To get the ID of an AMI that's configured to run as a NAT instance, use a command to describe images, and use filters to return results only for AMIs that are owned by Amazon, and that have the amzn-ami-vpc-nat string in their names. The following example uses the AWS CLI:
<beisner> wolsen, thx
<jcastro> marcoceppi: ok so do you want to run that session?
<marcoceppi> jcastro: sure
<beisner> dosaboy, fyi i flipped bug 1486177 back out of Fix Committed, see comment.
<mup> Bug #1486177: 3-node native rabbitmq cluster race <amulet> <backport-potential> <openstack> <sts> <uosci> <rabbitmq-server (Juju Charms Collection):Confirmed for thedac> <https://launchpad.net/bugs/1486177>
<dosaboy> beisner: ack, lets slip that log addition in
<beisner> dosaboy, the plan is to defer that name resolution fix until after the total-cluster-fail fix and associated tests have landed, so that reviewers have reliable tests to confer upon.   we need to unblock basic functionality first.
<thedac> beisner: my branch is updated  lp:~thedac/charms/trusty/rabbitmq-server/native-cluster-race-fixes including a hopeful (but untested fix for http://paste.ubuntu.com/12242485/) Before I create an MP we should run some tests
<beisner> thedac, thanks.  i'll merge that into my amulet-test-refactor branch.
<beisner> thedac, the errors in that paste should have disappeared as rmq/next was reverted.  are you still seeing those?
<thedac> no, but it looked like my change that originally caused it
<beisner> thedac, nope i believe it was r107, as that removed this:  if config('prefer-ipv6') and rdata.get('hostname'):
<thedac> oh?!!! ok
<beisner> and just ran ahead without the conditional
<thedac> agreeed
<beisner> thedac, but i'd say that your change to  rdata.get('private-address')   is safer anyway  ;-)
<thedac> yeah, it will do no harm
<thedac> dosaboy: gnuoy tells me you might be working on another rabbitmq issue. Is there a bug report for that?
<kwmonroe> hey folks, if i have a subordinate relationship between my tomcat war and tomcat (via the implicit juju-info interface), will there be a "juju-info-relation-departed" hook that fires if i destroy my subordinate service?
<rick_h_> lazyPower: marcoceppi can a subordinate get juju config data from the charm it's related to/on top of?
<lazyPower> rick_h_: only if its sent over the wire via relation-set
<rick_h_> lazyPower: ok, and if that config changes?
<rick_h_> lazyPower: they'd need to know to trigger something on the subordinate?
<lazyPower> it should be relation-set -r #relid foo=bar
<marcoceppi> rick_h_: nope
<rick_h_> ugh
<lazyPower> which will cause the relationship-changed sequence to cycle
 * marcoceppi ninja'd by lazyPower
<marcoceppi> rick_h_: well
<lazyPower> rick_h_: i have an example of this in docker / flannel-docker charms, where we send information out of context (or out of band)
<rick_h_> lazyPower: marcoceppi the idea being the subordinate wants to konw if the main charm is configured to pull from deb, source, etc
<marcoceppi> actually, envermind, juju-run doesn't work in a hook context
<rick_h_> lazyPower: marcoceppi and if that changes, the subordinate also needs to do some updating to keep in sync
<marcoceppi> rick_h_: gotta use the relationship wire
<lazyPower> rick_h_: thats possible to do
<lazyPower> you just have to proxy that information through the relationships
<rick_h_> lazyPower: ok cool ty
<lazyPower> rick_h_: lmk if you want examples, i have at least one that i'm aware of
<rick_h_> lazyPower: cool, jcsackett and bac will be interested
<bac> lazyPower: i may have missed it but if you have examples of the technique you explained to rick_h_, please let me know.
<lazyPower> bac: https://github.com/chuckbutler/flannel-docker-charm/blob/master/playbooks/network-relation-changed.yaml#L21
<bac> lazyPower: ty!
<lazyPower> bac: context being, the network relation is responsible for sending networking config data from flannel to the Docker daemon to configure SDN. flannel-docker should not modify the DOCKEROPTS file, hense we send it (potentially out of band) to docker to manage that files configuration
<lazyPower> bac: the receiving end is a little convoluted with ansible handlers, so if you need a full stack breakdown of how thats getting used feel free to ping and i'll try to explain it as best i can :)
<ntpttr> Hey everyone, I'm trying to configure my Juju and Maas to work behind a corporate proxy, and for some reason I'm getting "could not access file 'provider-state': get http://10.14.4.1/MAAS/api/1.0/file/provider-state/: http: error connecting to proxy http://http://myproxy:port: dial tcp: lookup http: no such host". The problem seems to be that http:// is showing up twice in the proxy URL, but in .juju/environments.yaml I configured http-proxy, https-proxy, ftp
<ntpttr> I rebooted my machine and my problem is different now, running 'juju --debug --show-log status' gives me "unable to connect to environment "maas"", and says it got service unavailable back from the server with the operation timing out
<ntpttr> I do have the IP of the MAAS server listed in my 'no-proxy' section of the environments.yaml file
<lazyPower> ntpttr: can you reach the state server normally?
<lazyPower> i mean via ping/ssh et-al
<ntpttr> yes I can ping it
<ntpttr> lazyPower: And it was working without any proxy when I was testing it at home
<lazyPower> Can you ssh to the node, and check if the jujud process is running, no UFW
<ntpttr> Right now there's no node to ssh to, I'm trying to bootstrap an environment to a node
<ntpttr> lazyPower: I'm using an Ubuntu Orange Box and am logged in to the controller node
<lazyPower> hmm, i haven't had much hands on with the orange box but i know it takes some special considerations
<lazyPower> so you're trying to check status on an environment that hasn't successfully bootstrapped?
<ntpttr> lazyPower: Yes, well in the default examples that come with the orangebox it has a bootstrap script that first checks if there's an existing deployment by calling status, and then runs bootstrap on a VM
<lazyPower> ntpttr: this leads me to believe there's  a stale .jenv in your control node that thinks the environment is bootstrapped, but th eenvironment is inconsistent with that.
<ntpttr> lazyPower: if there is, it isnt in ~/.juju/environments, is there another place it could be?
<lazyPower> is th eorange box using encrypted home?
<lazyPower> if so i think it maps to /var/juju or something similar.
<ntpttr> lazyPower: I don't think so, that directory isn't there
<lazyPower> ntpttr: this is the error you'll see when there's no .jenv and you attempt to run status on an environment
<lazyPower> http://paste.ubuntu.com/12246973/
<lazyPower> if you're seein gsomething else, there's a stale environment configuration somewhere on disk, and i'm sorry i'm not as familiar with the orangebox setup as I should be to help here.
<ntpttr> lazyPower: All right, running that command now - have to wait a bit for it to time out
<lazyPower> kwmonroe: do you have a second to lend your orange box experience here?
<lazyPower> kwmonroe: specifically, do you know what ntpttr is referring to about the setup scripts/examples on the OB?
<ntpttr> lazyPower: So I did get the first part of that error, saying it's unable to connect and that I should check credentials or use juju bootstrap, but in the erro rdetails I still get 'could not access file provider-state: gomaasapi: got error back from server: 503 Service Unavailable', and then a lot of HTML that says a communication error occurred: operation timed out
<lazyPower> can you pastebin that error output?
<ntpttr> looking at the code from the orangebox setup script, all it's doing is running juju status and then juju bootstrap
<lazyPower> it sounds like it attepted to contact maas and maas 503'd on you.
<ntpttr> sure one sec
<ntpttr> pastebin.com/pYzBvHwS
<ntpttr> http://pastebin.com/pYzBvHwS
<ntpttr> here's my environments.yaml http://pastebin.com/Xb0ejV4Y
<lazyPower> ntpttr: can you pull up the MAAS web ui?
<ntpttr> Yes, I've set the proxy and upstream DNS from there
<kwmonroe> lazyPower: i believe ntpttr is talking about this bootsrap script
<kwmonroe> http://bazaar.launchpad.net/~orange-box-examples/orange-box-examples/trunk/view/head:/bin/orange-box-bootstrap-juju
<kwmonroe> ntpttr: can you verify that node0vm0 is running (it's easy to see if you launch Virtual Manage Manager)
<lazyPower> ntpttr: i'm not sure why its giving you a 503 then. I'm out of my depth aside from checking basics like ensuring your api key hasn't changed (which should be a 401 response) and running destroy-environment --force -y before attempting a re-bootstrap
<kwmonroe> we've seen a problem where maas isn't correctly booting KVM instances (like node0vm0)
<lazyPower> kwmonroe: thanks for lending a hand :)
<kwmonroe> so you may just have to manually power that sucker on (if it's off)
<kwmonroe> alternatively ntpttr, you can alter line 31 of that o-b-bootstrap-juju script to "juju bootstrap --to nodeX.maas".  that'll try and bootstrap a physical machine instead of a VM.
<kwmonroe> (replace X with whatever number you want to be your bootstrap node)
<ntpttr> kwmonrow: node0mv0 is currently "ready", should I power it on before trying to bootstrap?
<kwmonroe> yeah ntpttr, give that a try
<kwmonroe> maas may report that it's sent the "power on" command, but you should fire up Virt Machine Manager and make sure it actually starts.
<ntpttr> kwmonroe: okay, thanks for the help! I'll let you know if that works and try bootstrapping to a physical node if not
<kwmonroe> np ntpttr, i'll keep fingers crossed for ya :)
<ntpttr> kwmonroe: Should I also comment out the 'juju status' check in orange-box-bootstrap-juju? It's timing out running that command and exiting
<ntpttr> kwmonroe: hmm it looks like it's still timing out on bootstrapping both to the powered on vm and a physical machine
<kwmonroe> ntpttr: you could.. or you could run "juju destroy-environment maas --force" (that'll just remove any maas.jenv file that may or may not exist -- dont' worry, it won't change your maas definition in environment.yaml)
<kwmonroe> hmm.. that's no good ntpttr.
<ntpttr> kwmonroe: do you think it could be my network settings in maas somehow? Maybe my upstream DNS?
<ntpttr> kwmonroe: It's even timing out on the juju destroy-environment command
<kwmonroe> ntpttr: i'm scratching my head now.. your proxy settings in the env.yaml look fine to me.  and i'm not sure what "destroy-environment --force" would be trying to do over the network at that point.
<sparkiegeek> drop the http:// from the value of the http_proxy
<kwmonroe> yeah sparkiegeek?  the docs show the prefix (https://jujucharms.com/docs/stable/howto-proxies), but i guess removing that is worth a shot.
<kwmonroe> ntpttr: will you pastebin the output of 'sudo virsh list --all'
<ntpttr> sparkiegeek kwmonroe: Yeah I have tried that, since the error I was getting before rebooting my machine was that it was trying to connect to http://http://myproxy:port, but after rebooting for some reason it's all changed and it's timing out instead. I just tried it again with the same result
<ntpttr> kwmonroe: Sure one second
<ntpttr> http://pastebin.com/mVWePqwM
<ntpttr> kwmonroe: Hold up I just restarted my computer again and it connected to maas when I ran bootstrap
<ntpttr> kwmonroe: I rebooted after removing my proxy settings from /etc/environment and ~/.bashrc, it seems like maybe that was causing an issue
<ntpttr> kwmonroe: I'll let you know if the bootstrap completes without any errors
<kwmonroe> interesting ntpttr -- so environments.yaml is now the only place the proxy info is being set?
<ntpttr> kwmonroe: There and in the network configuration portion of the Maas settings page. It's looking like the bootstrap is timing out connecting to streams.canonical.com now though
<kwmonroe> grrr
<ntpttr> Oh it's back to saying error connecting to 'http://http://myproxy:port', although I did remove http:// from my environments.yaml
<ntpttr> kwmonroe: The funny thing is it gives that error even if I comment the proxy settings out entirely
<kwmonroe> ntpttr: i think that means there's a .jenv that's overriding your environments.yaml.. see what you get with this: "grep -r proxy ~/.juju/environments*"
<ntpttr> kwmonroe: That command comes up blank, that folder is empty
<kwmonroe> hm.. lazyPower, is there some way to tell where juju would keep .jenvs if not in ~/.juju/environments?  i feel like ntpttr has a mysterious .jenv with proxy settings that are messing with us.
<lazyPower> kwmonroe: aside from mlocate's updatedb && locate maas.jenv
<lazyPower> i know encrypted home moves it somewhere, like /var/juju/$user
<lazyPower> but thats the only instance i can think of where it would do that
<kwmonroe> ntpttr: can you give that try (sudo updatedb && sudo locate maas.jenv)?
<ntpttr> kwmonroe: Sure
<ntpttr> kwmonroe: it came back blank
<lazyPower> kwmonroe: there are ENV vars it can read too right?
<lazyPower> kwmonroe: juju set-env (which i' mpretty sure requires a bootstrapped env), but i think there are also some environment vars juju reads that it may be colliding with
<kwmonroe> ntpttr: i know you removed the proxy bits from /etc/environment and .bashrc, but let's see if they're still around:  env | grep -i proxy
<ntpttr> kwmonroe: heey it looks like they are still around somewhere
<lazyPower> ntpttr: try unsetting the vars and re-bootstrapping
<lazyPower> then give it a go
<kwmonroe> ntpttr: unset http_proxy https_proxy no_proxy
<ntpttr> kwmonroe: Okay bootstrapping has started fingers crossed
<kwmonroe> alternatively ntpttr, you may be able to re-set them to the right value (http://myproxy:port vs http://http://myproxy:port) in /etc/environment or ~/.bashrc.. though i'm not sure where they're coming from at the moment..
<ntpttr> kwmonroe: I think they were still there because I had edited and env_keep line to /etc/sudoers
<ntpttr> kwmonroe: hmm it looks like bootstrapping is still timing out on connecting to streams.canonical.com :/
<ntpttr> kwmonroe: It seems like the env variables need to be set to connect there but they cant be set because it'll cause the double http:// problem
<kwmonroe> ntpttr: when you saw them set in the environment with "env | grep -i proxy", where they set to http://http://?
<ntpttr> kwmonroe: Oh wow it looks like they are... I have no idea how that happened I feel dumb right now hah
<kwmonroe> :)
<kwmonroe> so rather than unsetting them ntpttr, let's try setting them to the right values (single http prefix), then re-bootstrapping
<ntpttr> kwmonroe: Do you know if it's okay for them to have cidr prefixes in the env variables?
<ntpttr> kwmonroe: for no_proxy specifically
<kwmonroe> not sure ntpttr, everything i know about proxies is being learned by feverishly typing into google at this very moment.
<ntpttr> kwmonroe: uh oh now with the proxies set back the correct way I'm getting the timeout problem connecting to maas again
<ntpttr> kwmonroe: that's why I asked about CIDR, it seems like the no_proxy setting for the MAAS host isn't working maybe
<kwmonroe> ntpttr: looks like no cidr for no_proxy: http://unix.stackexchange.com/questions/23452/set-a-network-range-in-the-no-proxy-environment-variable
<kwmonroe> ntpttr: let's try something crazy.  on the orange box, there's a squid3 proxy (indepent of your external proxy) that serves content to the maas nodes.  let's see if that has crashed:  ps -ef | grep squid
<ntpttr> kwmonroe: I've been trying to add to the no proxy list the way it said in your link, and now running that command says that the argument list is too long, I think because there's so many values in no_proxy
<ntpttr> kwmonroe: i unset it, and running that command shows squid running
<kwmonroe> ntpttr: let's kick it anyway:  sudo service squid-deb-proxy stop; sudo service squid3 restart
<ntpttr> squid-deb-proxy is an unrecognized service, but squid3 restarted
<kwmonroe> hm, ok ntpttr.  retry the bootstrap
<ntpttr> kwmonroe: it got to the deploying stage, so that's good!
<kwmonroe> has it gotten that far before ntpttr?
<ntpttr> kwmonroe: No, it timed out on connecting to external hosts before
<kwmonroe> cool ntpttr!
<ntpttr> kwmonroe: Thank you a bunch for your time, you've been really helpful. You too lazyPower.
<lazyPower> np ntpttr
<lazyPower> sorry I didn't have better info for you :) but happy to help. If you run into any further problems, I suggest mailing the list - juju@lists.ubuntu.com with the problem scenario and someone in the EU timezones with more experience should be able to lend a hand.
<ntpttr> lazyPower: All right, thank you for the advice!
<kwmonroe> so ntpttr, while you're bootstrapping, here's what i think may have gone wrong.. the squid3 service that serves the maas nodes came up and read the invalid environment proxy vars (http://http://), and even though you unset/reset them later, that process was already using the bad values and couldn't serve the content needed to bootstrap to node0vm0.  restarting squid3 after the envars were corrected meant the maas proxy
<kwmonroe> could then correctly talk to your proxy.
<kwmonroe> and least that's what i'm hoping.  i'll feel better when your bootstrap succeeds!
<ntpttr> kwmonroe: okay, thank you! The bootstrap did succeed. Now going to node0vm0.maas is saying that DNS can't resolve the hostname, but it does say that juju gui is running there
<kwmonroe> ntpttr: do a "juju status juju-gui | grep address" and try to go to the IP directly
<kwmonroe> you might need a ",.mass" to your no_proxy var
<kwmonroe> sorry, ".maas", not ".mass"
<kwmonroe> ntpttr: the orange box knows how to resolve the .maas domain, so we probably just need to make sure requests for those URLs doesn't go through your proxy.
<ntpttr> kwmonroe: Okay, I added .maas to no_proxy but juju status now is giving me "error dialing wss://node0vm0.maas:17070: no route to host"
<ntpttr> kwmonroe: oh, it looks like after rebooting my machine again node0vm0 is saying no bootable device when it's trying to start up
<kwmonroe> eeegads ntpttr, we can't catch a break :/
<kwmonroe> unfortuantely ntpttr, i'm not sure how you'd get a "no bootable device" post bootstrap.. we can either try and debug that, or "juju destroy-environment maas" and try to re-bootstrap on a non-VM node (like nodeX.maas instead of node0vm0.maas)
<ntpttr> kwmonroe: hmm yeah this is a little frustrating haha. I re bootstrapped to the vm again (at home I was able to access the gui at node0vm0.maas), and it is saying that the public-address should be node0vm0.maas
<kwmonroe> ntpttr: i don't follow your last comment there -- what is saying the public-address should be node0vm0.maas?
<ntpttr> kwmonroe: That's the result when I run juju status juju-gui | grep address: 'public-address: node0vm0.maas', but it's not resolved by dns
<kwmonroe> ntpttr: can you 'juju ssh 0'?
<ntpttr> yep, that brings me into node0vm0
<kwmonroe> that might get you into the juju unit.. then 'sudo ifconfig' to find the ip
<ntpttr> kwmonroe: well the eth0 interface doesn't have an IP, and juju-bro is at 10.14.100.1
<kwmonroe> can you get to http://10.14.100.1?
<ntpttr> kwmonroe: no it times out
<kwmonroe> ntpttr: try 'export no_proxy=$no_proxy,10.14.100.1' and then hit the url again
<ntpttr> kwmonroe: I'm afraid I already had that in my no_proxy list
<kwmonroe> rats
<ntpttr> kwmonroe: It's odd, without the proxy stuff at home going to node0vm0.maas worked
<ntpttr> in juju status, under machines "0", it lists dns-name: node0vm0.maas, is that right?
<kwmonroe> yeah ntpttr, that looks right.  the OB should know how to get to .maas hosts.
<jose> marcoceppi: ping
<ntpttr> kwmonroe: So I'm not sure, but I think this could be the issue. In order to get the vm to resolve my proxy host and download packages, I configure the Maas upstream DNS to be a server in the same network as the proxy host is, and disable DNSSEC. That way the VM can boot up. But then my controller node in the orange box doesn't resolve node0vm0 because it has a different dns nameserver, 10.14.4.1, which is the gateway to the Orange Box's wireless. Is that poss
<kwmonroe> ntpttr:  i don't think that would cause a problem.. even if node0vm0 is using a different dns server, 10.14.4.1 should know how to resolve node0vm0.maas.
<kwmonroe> and 10.14.4.1 is the right dns server for the main orange box node -- it's the only one that knows what a .maas host is supposed to resolve to.
<ntpttr> kwmonroe: Hmm well for whatever reason I'm able to curl node0vm0.maas from inside the VM but not from the controller node
<kwmonroe> ntpttr: can you ping 10.14.100.1?
<kwmonroe> (from the controller node)
<ntpttr> kwmonroe: Yes I can
<kwmonroe> hmph
<kwmonroe> but you can't ping node0vm0, right?
<ntpttr> I can ping node0vm0.maas from the controller, yeah
<ntpttr> just can't curl or visit it with a browser
<kwmonroe> ntpttr: let's see what ports are listening on your bootstrap node: juju run --machine=0 'sudo netstat -ntlp'
<kwmonroe> ntpttr: are 80 and/or 443 listed?
<ntpttr> Yes, both are listed
<ntpttr> Should I add 'search maas' to /etc/resolv.conf?
<ntpttr> kwmonroe: right now it just lists my company's domain next to search
<kwmonroe> not sure about that ntpttr
<kwmonroe> can you 'curl --noproxy * http://10.14.100.1'?
<ntpttr> kwmonroe: no It says there's an error contacting the dns server
<ntpttr> kwmonroe: to me it looks like the big difference between the controller where it doesn't work and the VM were it does is the 'search maas' line in /etc/resolv.conf, but I'm not sure the correct way to put it there
<jose> tvansteenburgh: ping
<tvansteenburgh> jose: hey
<jose> tvansteenburgh: o/, I'm seeing a stuck test over here, mind taking a look?
<jose> http://juju-ci.vapour.ws/view/Juju%20Ecosystem/job/charm-bundle-test-lxc/482/
<tvansteenburgh> jose: i can kill it if you want
<jose> welp, just saying, it's completely stuck
<kwmonroe> ntpttr: you can try adding maas to the resolv.conf search line (add it before your company domain with a space separating the two)
<tvansteenburgh> jose: killed
<kwmonroe> ntpttr: but i think 'search' only comes into play when resolving short names (so 'ping node0vm0' would find 'node0vm0.maas').  i don't think that'll help us since we can't even curl the ip address, which should totally not care about dns.
<jose> tvansteenburgh: cool, thanks!
<ntpttr> kwmonroe: You're right, it didn't help
<kwmonroe> ntpttr: you can probably 'ping node0vm0' now from the controller, right?
<ntpttr> kwmonroe: yep
<kwmonroe> ntpttr: this is indeed frustrating.. let's make sure the juju-gui service is exposed (even though you shouldn't need to do this on an OB): juju expose juju-gui
<kwmonroe> and then try to curl with the shortname since we know you can ping it:  curl --noproxy * http://node0vm0
<kwmonroe> and if that doesn't work, try 'curl http://node0vm0' without the --noproxy option
<ntpttr> Yes it is exposed, here is my full juju status output http://pastebin.com/XK5NW4V9
<ntpttr> kwmonroe: still no luck with curl, it was exposed before as well as the last step of the orange box bootstrap
<marcoceppi> rick_h_: hey
<ntpttr> kwmonroe: Could it be that DNSSEC is disabled?
<rick_h_> marcoceppi: party?
<kwmonroe> i dunno ntpttr, but i feel like DNSSEC being disable should make our lives easier, not harder
<ntpttr> kwmonroe: Yeah, without it disabled the machine couldnt even get through the bootstrap
<ntpttr> kwmonroe: I just thought it might be related to the problem because it wasn't disabled when I did the same steps at home and it worked
<kwmonroe> ntpttr: it's worth a shot, but i'm not crossing my fingers for that one ;)
<kwmonroe> ntpttr: let's also try resetting the maas proxy: sudo orange-box-resetproxy
<kwmonroe> and then 'curl --noproxy * http://node0vm0 || curl http://node0vm0'
<marcoceppi> rick_h_: IM ALWAYS PARTYING!
<marcoceppi> rick_h_: I want to package python-jujubundlelib into the juju stable ppa, is that cool with you? (I'
<marcoceppi> (I'll do it in a way that won't conflict with future pacakges of the same version in archive if that every happens)
<rick_h_> marcoceppi: sure thing
<rick_h_> marcoceppi: Makyo and company can help test or anything you want there.
<marcoceppi> rick_h_: yes, thank you - we're using it for bundle proofing in charmtools
<ntpttr> kwmonroe: weird it will autocomplete orange-box-resetproxy but it says command not found
<marcoceppi> rick_h_: I'll make sure to reach out if I have any issues, but I don't forsee a problem
<ntpttr> kwmonroe: I had to become root with sudo -s and then run it for it to work but it did now
<rick_h_> marcoceppi: sounds good
<ntpttr> kwmonroe: unfortunately didn't fix the DNS problem though
<ntpttr> kwmonroe: Maybe the files in /etc/bind/maas? When I had it working before I was using maas 1.7.6 and now I'm on maas 1.8.0, which changed some of the files in that firectory
<kwmonroe> ntpttr: those files define how to resolve the .maas domain, which sounds like it's working -- you being able to ping node0vm0.maas and have it return 10.14.100.1 means the local dns server did it's job.
<ntpttr> kwmonroe: Then I'm sort of stumped here, I'm not sure which DNS it is that can't resolve node0vm0.maas
<kwmonroe> ntpttr: what happens when you just try to 'ssh ubuntu@node0vm0'?
<ntpttr> kwmonroe: It works
<kwmonroe> ok, so DNS is working.. it's just the http/https traffic that isn't coming over.
<kwmonroe> which has to mean one of our proxies isn't working
<kwmonroe> (i think)
<kwmonroe> or rather, the proxy is working too well.. it's like the request is being sent off to your myproxy:port even though we've told it no_proxy on 10.14.100.1
<ntpttr> kwmonroe: Hmm interesting, the proxies were resolved and were working during bootstrapping - update was able to resolve the ubuntu archives
<ntpttr> kwmonroe: Yeah the no_proxy might be it somehow
<ntpttr> kwmonroe: And there's still the thing where if I reboot the machine the VM cant boot back up because there's "no bootable device" >.<
<kwmonroe> right ntpttr, the proxies did their job to get external bits onto the node, but now it seems like the request to http://node0vm0 is being sent to the proxy (which of course can't resolve it because the internet doesn't know about node0vm0)
<kwmonroe> try this ntpttr, 'unset http_proxy https_proxy; curl http://node0vm0'
<ntpttr> kwmonroe: Okay one second while I bootstrap again because I restarted my computer
<kwmonroe> lol
<kwmonroe> i was hoping the "no bootable device" thing just kinda fixed itself ;)
<kwmonroe> i'm really not sure about that one
<kwmonroe> other than trying to bootstrap to nodeX.maas vs node0vm0.maas to see if it's a KVM thing or a bootstrap thing.
<kwmonroe> so the current plan ntpttr is to bootsrap with the proxies in place, then unset them and try to curl.  that'll tell us if the proxy is gobbling up the http request.
<ntpttr> kwmonroe: sounds good
<ntpttr> kwmonroe: So a possible lead on the 'no bootable device', it seems like if the VM is powered on the no bootable device thing happens, when I tried to bootstrap again while it was on just now I got the error, but then I released the node with Mass which shut it down, and now bootstrapping is working again
<kwmonroe> hey kirkland, have you seen an error on the OB where node0vm0 errors with 'no bootable device'? ^^
<ntpttr> kwmonroe: In the maas images tab it shows the image that I previously had added to it when setting up the orange box without a proxy, but it also says "Error: No boot sources provide Ubuntu images" above that
<kwmonroe> ntpttr: you're out of my maas knowledge with that one ^^ i'd recommend asking that in #maas
<ntpttr> kwmonroe: Well unsetting the proxy did in fact make curl work
<kwmonroe> awesome.. cya later!
<kwmonroe> (kidding, of course)
<ntpttr> kwmonroe: haha the juju gui still seems to be hanging connecting to the juju environment though >.<
<ntpttr> kwmonroe: wait there it goes it just took a good two minutes
<kwmonroe> that's a pretty long wait, but i'll take it if it finally worked :)
<ntpttr> kwmonroe: whew me too, hey it's a start
<ntpttr> kwmonroe: thanks again
<kwmonroe> so ntpttr, i think this points to no_proxy as the key here.
<kwmonroe> we've gotta make sure http and https traffic to 10.14.100.x doesn't get sent off to the proxy
<kwmonroe> ntpttr: i would have thought simply adding 10.14.100.1 to no_proxy would have been enough, so i'm stumped as to why unsetting both http_proxy and https_proxy was required.
<ntpttr> kwmonroe: Yeah it is odd...
<ntpttr> kwmonroe: well I have to get going for now, thank you for spending so much time with me on this I appreciate it
<kwmonroe> sure thing ntpttr - just ping here (or on  juju@lists.ubuntu.com) if you want to poke on this proxy stuff some more
<ntpttr> kwmonroe: Sounds good, I will :)
<marcoceppi> rick_h_ Makyo python-jujubundlelib and python3-jujubundlelib are now in the stable ppa, I'll throw the packaging branch up somewhere in a few mins. Happy to roll releases as they come out, we just added it to charm-tools for bundle v4 support/proofing
<marcoceppi> oy, nvm
<marcoceppi> I should talk with frankban tomorrow, his package may need some updates
<rick_h_> marcoceppi: which package?
<rick_h_> marcoceppi: these are new right? Or you mean the python package?
<marcoceppi> rick_h_: I just now noticed there's a jujubundlelib package in stable that frankban uploaded to the stable ppa
<marcoceppi> but it only provides jujubundlelib and not python-jujubundlelib python3-jujubundlelib as I expected it to
<rick_h_> marcoceppi: oh, ok
<marcoceppi> I have a new packaging branch that would fix that, but it conflicted when I went to upload it, so I'll have to chat wtih frankban tomorrow on it (unless he's on vacation?)
<rick_h_> marcoceppi: well he's here in the room so he'll join irc
<rick_h_> marcoceppi: and you guys can hash it out
<marcoceppi> oh, you guys sprinting?
<rick_h_> marcoceppi: I think the package is compatible with both
<rick_h_> marcoceppi: yea, in chicago this week
<marcoceppi> rick_h_: it's not, it doesn't install the python3 path properly
<rick_h_> marcoceppi: oh, I'm surprised.
<marcoceppi> not a big deal since charm-tools is only py2, but amulet is py2 + py3 and we'll see an update to that soon
<rick_h_> marcoceppi: ok, well asked frankban to join in and catch up
<marcoceppi> rick_h_: not frankban's fault, it's a problem with py2dsc which doesn't support py3 ootb
<rick_h_> marcoceppi: ah, ok we're all caught up now
<rick_h_> marcoceppi: so go ahead and we'll update quickstart to use the python2 package you've got
<rick_h_> marcoceppi: and deprecate/clean up the older bundlelib package that's not python ver. specific
<rick_h_> (well, not named specific)
<marcoceppi> rick_h_: okay, I'm happy to create a jujubundlib package target taht just aliases python-jujubundlelib so that it transitions cleanly
<rick_h_> marcoceppi: ok, will let you all coordinate it so that we make sure quickstart and the gui are kept happy
<firl> anyone able to help me understand how to use juju-deployer config constraint for a maas tag?
<firl> trying constraints: "tag=25net"
<wolsen> firl, try tags instead of tag
<firl> wolsen no dice âcould not find expected â:ââ
<wolsen> firl, are you using 'constraints: tags=25net'?
<wolsen> or?
<firl> http://pastebin.com/205weCSn
<firl>       constraints: "tag=25net"
<wolsen> firl, I think you should change the constraints from "tag=25net" to "tags=25net"
<firl> I tried that
<firl> http://pastebin.com/pPiNPzyR
<firl> ( same error )
<wolsen> firl, oh - you need a space between num_units: and 7
<wolsen> on the next line
<firl> le sigh
<firl> ty
<wolsen> np
<firl> itâs running now, maybe I should step away from the computer haha
<pmatulis> what is the difference between 'juju add-machine' and 'juju deploy ubuntu' ?
#juju 2015-09-02
<marcoceppi> pmatulis: the difference is how juju models it, juju deploy ubuntu will create a machine with the ubuntu charm on it and the service ubuntu in your topology, juju add-machine will simply provoison a machine with no services deployed to it making it available for services to be deployed to it.
<pmatulis> marcoceppi: yeah i'm starting to see it better now. thanks for the description
<firl> if anyone could help with my vivid-kilo, maas set up that would be awesome. I am running into a ceph issue http://askubuntu.com/questions/668320/ceph-cannot-reformat-because-disk-is-mounted
<coreycb> jamespage, looks like we need something like SWIFT_CODENAMES in charm-helpers for all the projects in liberty.  I can start on that if you haven't.
<jamespage> coreycb, that should already be covered I think
<jamespage> but maybe not
<coreycb> jamespage, I think get_os_version_codename() and openstack_upgrade_available() need some updates
<jamespage> beisner, are you ware of any trusty/kilo issues?  seeing a instance boot error on a mp I'm reviewing?
<beisner> hi jamespage - t-k next mojo spec from yesterday fired up and connected to a new instance ok.  http://paste.ubuntu.com/12253397/   or   http://10.245.162.77:8080/view/Dashboards/view/Mojo/job/mojo_runner/745/console
<jamespage> beisner, this is the MP - https://code.launchpad.net/~bbaqar/charms/trusty/nova-cloud-controller/next/+merge/269897
<beisner> jamespage, digging into the logs collected on that run, nova-compute log shows MessagingTimeout and nova conductor woes.  http://paste.ubuntu.com/12253431/
<beisner> jamespage, fyi Aug23:  n-c-c/next most recent time-triggered, successfully completed run.  (the Aug30 runs were sabotaged by undercloud storms.)
<beisner> jamespage, Aug23 for reference:  http://10.245.162.77:8080/view/Dashboards/view/Amulet/job/charm_amulet_test/5981/
<beisner> jamespage, i've re-triggered a new n-c-c/next amulet run now.
<lazyPower> beisner: did any of those MP's come in lastnight?
<lazyPower> beisner: i didn't get notice... or i did and they were filtered so i had no idea i had stuff to do
<jamespage> gnuoy, hey - could you give https://code.launchpad.net/~james-page/charm-helpers/plumgrid/+merge/269920 a quick +1 (its for the plumgrid SDN stuff - managed to miss they have not proposed to ch's)
<gnuoy> jamespage, sur
<gnuoy> * sure
<jamespage> ta
<beisner> hi lazyPower - apologies if i kept ya hanging - that train is delayed, but could be arriving soon.
<firl> any openstack charmers on?
<lazyPower> beisner: no stress. Just wanted to circle back and make sure I didn't leave you hangin lastnight :)
<marcoceppi> firl: do you have a question?
<firl> marcoceppi: Yeah, someone helped me get a config ready for vivid-kilo, and I am running into an issue with ceph, and wanted to know if it was me doing something wrong or something else
<firl> http://askubuntu.com/questions/668320/ceph-cannot-reformat-because-disk-is-mounted
<marcoceppi> beisner jamespage gnuoy coreycb ^ ?
<marcoceppi> firl: thanks for opening an Ask Ubuntu question on it
<firl> np, yeah it was early morning, and didnât know if it should be a bug or a question
<jamespage> firl, hmm
<marcoceppi> firl: question is always a good start, it allows a medium to track history and gives people who arent' always online the ability to readback from there it might be a bug or just a fix to your environment
<firl> marcoceppi: good to know, thanks
<jamespage> firl, is this a re-deployment?
<firl> nope
<jamespage> i.e. have you managed to deploy once, and you're now re-deploying on the same hardware?
<firl> I am redeploying on same hard ware
<firl> but I am using mass to juju destroy-environment
<firl> I thought that the osd-reformat would take care of the designation on the newly deployed os ( on the same old hardware )
<jamespage> firl: its possible that something systemd-ish is causing a race on the redeployed system
<jamespage> i.e. a udev rule fires and mounts the volume at about the same time this process is running
<firl> of where it is mounting the drive before ceph allocates it?
<jamespage> maybe - tricky to etll
<firl> gotcha
<jamespage> firl, ceph used udev rules to mount and start osd on reboot - its possible this is the cause
<jamespage> although I've not seen this one before
<firl> yeah
<firl> I have reproduced it 3 times
<jamespage> urgh
<firl> :)
<firl> I try to test before asking haha
<jamespage> firl, did you mean to deploy on vivid btw?
<jamespage> or was kilo the main requirement?
<firl> Kilo is the main
<firl> vivid-kilo was for LXD possibility
<jamespage> firl, ah!
<jamespage> I see
<firl> I can do trusty-kilo and see if it reproduces it
<jamespage> makes sense
<firl> :)
<firl> Makes me feel a little less crazy then haha
<jamespage> firl, I would probably bet its fine on trusty/kilo - that gets alot of redeployment exercise on hardware in test labs and at customer deployments
<jamespage> vivid - less so - so this type of thing can bite.
<firl> gotcha
<firl> so trusty/kilo is more along the lines of trusted / stable ?
<jamespage> firl: absolutely - but we don't provide LXD back to trusty ...
<jamespage> so I can see why vivid was making sense for you
<firl> yeah, yeah the LXD was just for fun testing
<firl> not an immediate need so to speak
<jamespage> firl, that said its probably worth highlighting that block device support is not yet implemented in LXD/nc-lxd
<jamespage> so cinder/ceph + LXD == ERRNOTSUPPORTED right not
<firl> ah that is good to know
<firl> yeah I use cinder/ceph so that makes sense
<firl> ok off to trusty-kilo
<jamespage> that is being worked on - but there are a number fo security concerns with work through in the kernel todo with fs integrity
<firl> very true
<firl> Do you know of any other customer type example config.yaml for the OS world to compare my set up against by any chance?
<jamespage> firl, it looks like you pulled yours from openstack-charm-testing right?
<firl> ya
<jamespage> firl, it you wanted something a little more concise to work from - https://jujucharms.com/openstack-base/
<jamespage> that uses charm-store rather than branches and could easily be adapted
<firl> thanks man, I appreciate it
<jamespage> firl, that also uses the new bundle format which expresses everything about the environment including the physical machines
<jamespage> gnuoy, sorry to nag on that review - pretty please :-)
<gnuoy> jamespage, sorry, it's just possible I got distracted by something shiny
<jamespage> ha
<lazyPower> shiny? where?!
<jamespage> ddellav, hey - I see you glance upgrade action stuff got landed - nice work
<jamespage> gnuoy, ta
<firl> jamespage, the format that I am using? or the openstack-base does?
<jamespage> firl, the openstack-base bundle uses the new format
<firl> gotcha, yeah I will convert over to the new format and try to specify it
<firl> thanks again
<jamespage> firl, its worth noting that by using the charm-store for the charms, you can fix charm revisions for repeatable deployments
<jamespage> firl, worth doing to avoid an unexpected re-deployment change
<jamespage> say a new feature or suchlike
<jamespage> lazyPower, plumgrid changes for openstack charms all landed now
<jamespage> lazyPower, well into next at least
<lazyPower> https://media.giphy.com/media/OJdyjK11k2fLi/giphy.gif
<lazyPower> awesome, I'll clean up the technical debt i left behind before EOW and cc you when i get the bundle corrected.
<lazyPower> thanks for the update jamespage
<jamespage> lazyPower, thanks for the final reviews whilst i was away - appreciated!
<lazyPower> jamespage: np, happy to see them land their charms. :)
<jamespage> indeed
<marcoceppi> rbasak: I've got a debian packaing question, you got a min?
<ddellav> jamespage, thanks :) I've also landed the cinder changes as well. Working on ceilometer now.
<ddellav> jamespage, https://code.launchpad.net/~ddellav/charms/trusty/cinder/upgrade-action/+merge/269247
<ddellav> feel free to take a look and comment.
<jamespage> ddellav, good-oh!
<rbasak> marcoceppi: sure. Also you just reminded me that I should have something on my todo for you I think. Do you remember what it is?
<marcoceppi> rbasak: I think I just found out what I did wrong, let me get back to you in a few mins
<marcoceppi> rbasak: so I cleaned up the charm-tools packaging. We left the discussion at "I need to do a 1.6.0 release so we can propose for archive)
<marcoceppi> "
<rbasak> marcoceppi: ah OK. So no action for me right now?
<marcoceppi> however, 1.6.0 added a bunch of deps not packaged that I just wrapped up packaging
<marcoceppi> rbasak: so I think after i finish testing/uploading to the PPA we should take another spin through the package to make sure everything is in place
<marcoceppi> I'll ping you tomorrow to chat more about
<rbasak> marcoceppi: OK. Let me know when you're ready.
<rbasak> ack, thanks
<marcoceppi> rbasak: okay, i actually do still have a packaging question
<rbasak> marcoceppi: shoot :)
 * rbasak EODs soon
<marcoceppi> rbasak: so there was a  source package, jujubundlelib and it installed jujubundlelib package. I wanted to create a python-jujubundlelib and python3-jujubundlelib package while making sure to maintain backwards compatibility with jujubundlelib package because others packages still depend on it
<marcoceppi> rbasak: so I created the following control file
<marcoceppi> https://github.com/juju/juju-bundlelib-packaging/blob/master/control
<marcoceppi> jujubundlelib depends on the python-jujubundlelib which replaces it, python-jujubundlelib breaks jujubundlelib 0.1.9-1 (this is now 0.1.9-2) and replaces jujubundlelib
<marcoceppi> however, if I isntall 0.1.9-1 and perform an upgrade I get this error
<marcoceppi> rbasak: http://paste.ubuntu.com/12254887/
<marcoceppi> I have to run sudo apt-get install -f after the upgrade to have the package install properly
<marcoceppi> so I figured it was because I was dong << I patched to do <= but the same error occurs
<rbasak> 0.1.9-1 > 0.1.9-1~
<marcoceppi> right so the control file is now
<marcoceppi> jujubundlelib (<= 0.1.9-1)
<marcoceppi> oh, so should i have done jujubundlelib (<< 0.1.9-2~) >
<marcoceppi> ?*
<rbasak> Yeah, jujubundlelib (<< 0.1.9-2~) is right
<marcoceppi> damnit, okay let me patch taht and try again
<marcoceppi> the ~ was throwing me off, I tried googling it but that's pretty ahrd
<rbasak> It's fixed in 0.1.9-2, so anything older than that is what it replaces. Suffixing ~ allows for backports and PPAs
<marcoceppi> cool
<marcoceppi> rbasak: thanks, I'll give this a go
<rbasak> Since if someone backports or PPAs 0.1.9-2 then it'll be in 0.1.9-2~, and that should also be treated as one where the transition has occurred.
<rbasak> No problem.
 * marcoceppi adds a little more packaging knowledge to the tree
<skylerberg> How do I make a failed hook as resolved? I am looking for an equivalent to `juju resolved` for a failed hook instead of a failed charm.
<lazyPower> skylerberg: juju resolved unit/# resolves just that hook
<lazyPower> if a follow up hook fails, the charm re-enters a failed state
<skylerberg> lazyPower: Thanks. I got it working a bit ago, but I had tried several things, so I still wasn't sure what actually fixed it.
<skylerberg> wolsen: I resubmitted my patch for nova-compute with the changes we discussed: https://code.launchpad.net/~sberg-l/charms/trusty/nova-compute/tintri-interface/+merge/269972.
<wolsen> skylerberg, ack - thanks - I'll take a look at it a bit later
<beisner> wolsen, ping-o
<wolsen> beisner, pong-o
<beisner> yo!
<wolsen> hey
<beisner> wolsen, just touching base re: email (1c-h + 4 charm) review
<beisner> wolsen, ah i think we left off with https://code.launchpad.net/~1chb1n/charm-helpers/amulet-svc-restart-race/+merge/269098  <-- rev pushed following review
<wolsen> beisner, yep I hadn't gotten back to your updated push on it
 * wolsen looks now
<beisner> wolsen, np.  we had to let the tests run for the charms that i sync'd it into to confirm.
<beisner> ie. those in your email consume these c-h changes
<wolsen> beisner, yep
<beisner> wolsen, thx man
<wolsen> beisner, approved - added yet another comment, but its more of a follow up todo action
<beisner> wolsen, replied fyi.  another great question.
<wolsen> beisner, oh hah - my comment was misstated - heh, its ambiguous if len(pid_list) > 1 not 0
<wolsen> beisner, but let me look at that method
<beisner> wolsen, yes indeed, we are ignoring cases where there are multiple pids (as did the ancestor).   which is a good to-do to further examine.
<wolsen> beisner, right - that was the crux of my comment - my mistake on the typo there - we both agree though ;)
<wolsen> beisner k, I don't have rights to merge that - but its got my blessing fwiw
<beisner> wolsen, ack & thank you sir
<wolsen> beisner, thank you!
 * wolsen turns towards ackk's proposal then to skylerberg's
<firl> anyone able to help me diagnose my bundle parse errors ?
<firl> nevermind, I needed to use âjuju quickstartâ instead of âjuju-deployer"
<marcoceppi> firl: huh, quickstart and deployer should both work, what were teh errors?
<firl> http://pastebin.com/vds8YYDh
<firl> http://pastebin.com/w9UckkRi
<firl> nevermind the quickstart just failed more gracefully
<firl> haha
<marcoceppi> firl: heh :D
<marcoceppi> what version of deployer do you have installed?
<marcoceppi> it seems to be an issue with parsing constraints
<firl> yeah, worked on my old bundle file
<marcoceppi> what changed in this bundle file?
<firl> switching from v3 to v4? I think? I mimicâed the openstack-base charm
<firl> and then added in my constraints
<marcoceppi> insteresting
<marcoceppi> let me check something
<firl> and the quick start might have worked? still waiting for the gui to come up
<marcoceppi> firl: it's possible
<marcoceppi> it seems that "cannon unmarshal string into Go value type []string" means that the API is expecting a list of strings and not just a string
<marcoceppi> firl: lets wait for quick start to succeed or fail
<marcoceppi> and go from there, I have some ideas
<firl> cool
<firl> https://api.jujucharms.com/charmstore/v4/bundle/openstack-base-36/archive/bundle.yaml
<firl> that constraints only has 1 as well
<marcoceppi> firl: yeah, I've not used the v4 bundle format as much as I should
<firl> or maybe itâs thinking tags=[âtag1â,âtag2â]
<marcoceppi> I don't think so, but it's possible
<marcoceppi> rick_h_: ^
<firl> juju gui timing out to install, I will blow away and re bootstrap with dragging the yaml file to the gui. I donât think the gui has a place for maas tags though
<marcoceppi> firl: it may not expose it explicitly, but it should respect it
<firl> cool
<marcoceppi> firl: for what it's worth juju will soon be gaining the ability to just do `juju deploy <bundle>` so it'll be a lot more cohesive and we can finally drop things like deployer and quickstart for bundles
<marcoceppi> that's why we're transitioning to the v4 bundle format
<firl> sweet; yeah Iâve really enjoyed everything I have encountered when it comes to juju
<firl> bringing a co worker with me to the summit too
<marcoceppi> firl: \o/ aweseome, see you there
<ntpttr> Hi, I'm having some trouble deploying juju-gui to my bootstrapped environment. I run "juju deploy --to 0 --repository=/srv/charmstore local:trusty/juju-gui" and then "juju expose juju-gui", and for a while the service-status is maintenance and the agent-status is running the install hook and the start hook, and then eventually the service-status changes to 'unknown' and the agent-status changes to 'idle', and even though the agent-state is started, going to the
<marcoceppi> ntpttr: hey, so since 1.24 juju introduced a new extended status. a service status of unknown and agent-state of idle is for charms not yet using extended status. So that means the juju-gui should be deployed
<marcoceppi> ntpttr: are you having issues loading it in your browser?
<ntpttr> marcoceppi: Yeah, the browser is showing a spinning wheel under "Connecting to the Juju environment"
<marcoceppi> ntpttr: hum, what provider are you using? local, maas, openstack?
<ntpttr> marcoceppi: maas
<ntpttr> marcoceppi: I have a corporate proxy I'm working behind, but I did configure that in environments.yaml
<marcoceppi> ntpttr: ah, that might be the issue
<marcoceppi> ntpttr: so the juju-gui uses websockets to communicate with the juju environment
<marcoceppi> ntpttr: what browser are you using?
<ntpttr> marcoceppi: Firefox
<marcoceppi> ntpttr: if you open the developers tool console in firefox and hard refresh the juju-gui I imagine you'll probably see a connection error pop up
<ntpttr> marcoceppi: Yeah it's saying can't establish a connection to the server at wss://node0vm0.maas/ws. It was working yesterday for me, but then I updated my juju by adding the stable ppa
<marcoceppi> ntpttr: so what version were you on before? 1.22?
<ntpttr> marcoceppi: It's also saying the connection was interrupted while the page was loading
<ntpttr> marcoceppi: I'm honestly not sure, whichever one comes with the orange box build
<marcoceppi> ntpttr: are you doing this on an orangebox right now?
<ntpttr> marcoceppi: yes
<marcoceppi> ntpttr: what does `env | grep "proxy"` produce on the machine you're trying to access the GUI from
<ntpttr> marcoceppi: It produces all of my proxy urls for http_proxy https_proxy ftp_proxy and no_proxy. Yesterday I was having a connection issue as well and I fixed it by adding ".maas,10.14.4.1" to no_proxy
<ntpttr> marcoceppi: Is there an easy way to downgrade juju to what I had before?
<marcoceppi> yeah, you're going to have to do that again
<marcoceppi> ntpttr: you could remove the stable ppa
<firl> marcoceppi: drag to juju-gui seems to work  so far.
<ntpttr> marcoceppi: and after I do that if I update it will downgrade?
<marcoceppi> ntpttr: you'll have to either apt-get remove juju-core and re-install or do `apt-get install juju-core=1.XX*` whatever the version is
<marcoceppi> ntpttr: I suggest the former
<marcoceppi> firl: nice! glad to hear the drag and drop is working so far
#juju 2015-09-03
<skylerberg> So I have a change pending review to merge into nova-compute to add an interface for my charm, but the review is awaiting my charm being available.
<skylerberg> However, I have a test in my charm that depends on the change in nova-compute.
<skylerberg> Would it be preferable to publish with a failing test for the interface or upload without the interface having any test?
<beisner> hi skylerberg - can you point us at the test you're referring to?
<skylerberg> beisner: I decided to just upload as is. I was working on a test in my charm that would use the tintri-nova interface, but I think I will wait to finish writing that test until after that interface is added to nova-compute.
<beisner> skylerberg, it may be worth looking at one of the existing openstack charm test dirs to see how we define and exercise the spectrum of release combos.  there are a lot of existing test helpers too, which may come in handy.
<beisner> ex.  http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/cinder-ceph/next/files/head:/tests/
<beisner> http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/cinder/next/files/head:/tests/
<beisner> skylerberg, fwiw - ppl have work-in-progress branches in lp all the time, i don't think that's an issue.
<skylerberg> beisner: Good to know and thanks for the pointers.
<skylerberg> I went ahead on pushed mine https://code.launchpad.net/~sberg-l/charms/trusty/cinder-tintri/trunk.
<beisner> skylerberg, cool - oh, probably an easier example is the Makefile and tests/ dir of the lp:charms/trusty/ubuntu charm
<jamespage> gnuoy, I think we're at the point where we can start testing liberty again; can we do a charm-helpers sync to ensure all charms have the new version detection code?
<jamespage> I can run that - but I know you have a process
<gnuoy> jamespage, sure, I'll do it, it'll help kick me to automate it :-)
<jamespage> gnuoy, +1
<jamespage> thanks
<jamespage> gnuoy, hold a sec
<jamespage> I think there is something up with my regex and unit tests
<gnuoy> ack
<jamespage> gnuoy, yeah my regex for digits is not greedy enough
<jamespage> I don't know why the unit test is actually passing
 * jamespage looks
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charm-helpers/fixup-detection/+merge/270016
<jamespage> gnuoy, basically the code only worked with single digit versions, and the dict for testing had multiple entries for nova-common
<jamespage> dohy
<gnuoy> jamespage, merged
<jamespage> gnuoy, ta - ok I think we can resync now then
<gnuoy> jamespage, I'll just let the mojo job run through with the previous version of charmhelpers then I'll sync
<gnuoy> jamespage, charm helpers sync'd
<jamespage> gnuoy, awesome - thanks
<jamespage> gnuoy, I have a few trivial updates to fixup other things - an number of charms where not using -common packages for version detection
<gnuoy> ok, sounds good
<gnuoy> jamespage, do you have a sec for a second opinion on https://code.launchpad.net/~thedac/charm-helpers/legacy_leadership_peer_retrieve_fix/+merge/269400
<gnuoy> not sure if I'm being paranoid
<sparkiegeek> hmm
<jamespage> gnuoy, hmm - I thought that a unit should always rely on what it set on the peer relation
<sparkiegeek> gnuoy: http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/swift-storage/next/revision/78 worries me
<sparkiegeek> in https://code.launchpad.net/~adam-collard/charms/trusty/swift-storage/fix-unconditional-service-restart/+merge/269744 there were failures with the fixed charm-helpers
<sparkiegeek> (see explanation on the MP)
<gnuoy> jamespage, that's what I thought. I need to understand why that change fixes rabbit
<gnuoy> sparkiegeek, I'm probably being slow but I don't quite follow what you are saying. The latest charm helper sync which isn't in your branch yet is causing a problem?
<sparkiegeek> gnuoy: nope :)
<sparkiegeek> lemme try and explain a bit better
<sparkiegeek> https://bugs.launchpad.net/charms/+source/swift-storage/+bug/1489770
<mup> Bug #1489770: openstack_upgrade_available incorrectly always returns True for swift charms <backport-potential> <landscape> <Charm Helpers:Fix Committed by adam-collard> <swift-storage (Juju Charms Collection):In Progress by adam-collard> <https://launchpad.net/bugs/1489770>
<sparkiegeek> ^ this got fixed in charm-helpers first, and then I made a branch for swift-storage
<sparkiegeek> the change to charm-helpers inadvertently caused amulet tests to fail in swift-storage (further digging shows that they were incorrect all along, and were essentially asserting that that bug exists)
<sparkiegeek> so I am worried that mojo passed those tests with the charmhelpers synced, because when I ran them, they failed
<sparkiegeek> (my MP for swift-storage fixes them)
<sparkiegeek> gnuoy: ^^ any clearer? :)
<gnuoy> sparkiegeek, the mojo charmhelper sync job doesn't run the amulet tests
<sparkiegeek> gnuoy: ah ha!
<gnuoy> sparkiegeek, although it should really
<sparkiegeek> ok, so I expect we'll now see OSCI throwing up when it runs the amulet tests
<sparkiegeek> unless some kind, generous sole in ~openstack-charmers reviews/merges my branch?
<gnuoy> kk
<sparkiegeek> *soul
<sparkiegeek> I mean, you might have nice feet too
<gnuoy> sparkiegeek, I shall don my review trousers
<sparkiegeek> then we can talk about backporting to stable :)
<sparkiegeek> za boog seems pretty important to me
<sparkiegeek> I expect other swift-* charms are broken too
<sparkiegeek> gnuoy: ^^ my focus is on swift-storage at the moment
<gnuoy> sparkiegeek, do you have time to propose it to stable? fwiw stable uses lp:~openstack-charmers/charm-helpers/stable
<sparkiegeek> gnuoy: the idea would be to cherry-pick the necessary change in to stable for both c-h and the charm?
<gnuoy> sparkiegeek, yep
<sparkiegeek> gnuoy: sure, will do
<gnuoy> ta
<apuimedo> late morning!
<sparkiegeek> gnuoy: https://code.launchpad.net/~adam-collard/charm-helpers/openstack-upgrade-available-swift-stable/+merge/270028
<sparkiegeek> gnuoy: and .. https://code.launchpad.net/~adam-collard/charms/trusty/swift-storage/conditional-service-restart-stable/+merge/270030
<gnuoy> sparkiegeek, ta
<coreycb> jamespage, I see you and gnuoy were looking at some liberty c-h bits.  I have this mp if you haven't already fixed things up.  https://code.launchpad.net/~corey.bryant/charm-helpers/liberty/+merge/269979
<coreycb> I should merge tip
<coreycb> tip merged
<pmatulis> what are these juju "tools" i keep reading about?
<lazyPower> pmatulis: charm tools maybe?
<lazyPower> pmatulis: or are you referring to the juju tools that are fetched from streams / built on bootstrap and live on the state server?
<pmatulis> lazyPower: the latter i think. i see it mentioned for bootstrap and for upgrade-juju
<pmatulis> i downloaded something [1] and there was a single file: 'jujud'
<pmatulis> [1]: https://streams.canonical.com/juju/tools/
<lazyPower> pmatulis: yep, those are the actual bins that empower juju
<lazyPower> the juju daemon, agent, et-al
<pmatulis> lazyPower: so each machine and unit have a jujud or is it just something that stays on the state server?
<lazyPower> As I understand it, yes. That's the agent component for every service
<hazmat> dimitern: did the network vpc support get merged?
<dimitern> hazmat, not yet, it turned out a bigger rat hole I imagined
<hazmat> dimitern: ack, bummer
<dimitern> hazmat, I have a working fix, but it will take some refactoring to merge it without breaking other stuff
<marcoceppi> hey rbasak, I've got another packaging question for you. So I've got a .install file that has this line "usr/lib/python2.*/dist-packages/stuf*/" because this python project, when built puts a tests directory in the dist-packages. However when I run the build I get  "dh_install: python-stuf missing files (usr/lib/python2.*/dist-packages/stuf*/), aborting"
<marcoceppi> not sure how to go about removing the tests directory
<natefinch> lazyPower, marcoceppi:  I'm deploying wordpress in a juju environment, like, for production.  I noticed that the max media upload size is 2 MB, and googling says the only way to modify that is to edit some .ini file manually...
<natefinch> lazyPower, marcoceppi: so, two questions:  1.) why is the default 2 MB?  That seems tiny.  2.) it seems like this is something we could help people adjust without having to go find some file to twiddle... e.g. juju set wordpress maxuploadsize=12mb
<lazyPower> natefinch: iirc that file is already under cheeta template control and that should be a pretty simple patch
<lazyPower> natefinch: can you file a bug and we'll try to circle back on it? thats a good point.
<lazyPower> I know we haven't taken a serious look at the wordpress charm in some time, there's probably some room for improvement there
<natefinch> lazyPower: cool
<mbruzek1> Someone wants to use relations to share files between charms in Juju. Can you help me brainstorm a solution?  It appears Juju only puts the public keys on the units so they can not scp with each other.  Is there another way?
<mbruzek1> I wrote a charm that serves the files via http.
<mbruzek1> but I am looking for other options.  Ideas?
<marcoceppi> mbruzek1: you could exchange directories and ssh-keys
<mbruzek1> via the relation data?
<marcoceppi> and use rsync/scp
<marcoceppi> rsync ftw, if you do go that route
<marcoceppi> mbruzek1: is this peer or provides/requires scenario?
<mbruzek1> relation-set private-key="binaryhexdatahere"
<marcoceppi> mbruzek1: basically, so you could do the exchange one of two ways
<mbruzek1> marcoceppi: provides/requires scenario.
<marcoceppi> mbruzek1: you could have the end that wants to connect send public-key it's safer that way, then the one serving the files simply adds taht key to authorized_users for the user that has the files on the system and sends back a path
<mbruzek1> Oh yeah
<marcoceppi> mbruzek1: or you could have the charm serving the files generate private-keys and send them out
<marcoceppi> that way it's a one-way communication, but it's a little more...hinky that way
<marcoceppi> either way I'd definitely make sure teh charm serving the files creates a non-priviledged user on the system to house the files and have all the other services use that user whena ccessing the server to minimize security risks
<Odd_Bloke> If someone has a minute to review https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/fix-cron-template/+merge/270083 it would be much appreciated.
<Odd_Bloke> We're trying to roll-out in-cloud mirrors in a few places and this is (hopefully) the one remaining blocker. :)
<lazyPower> @Odd_Bloke white space fix on a template?
<lazyPower> ah i see i the commit message the intention here
<lazyPower> @Odd_Bloke - I see a inked issue which currently has no resolution. Is this MP going to resolve the problem if you're still rendering w/ jinja2 from charm-helpers?
<Odd_Bloke> lazyPower: Yep, jinja2 essentially does "\n".join(rendered_template.split('\n')), and so only strips the _last_ newline (not all trailing newlines).
<lazyPower> i'm deploying now to verify, should have this merged shortly
<Odd_Bloke> lazyPower: Great, thanks!
<lazyPower> @Odd_Bloke merged.
<Odd_Bloke> lazyPower: Thanks!
<g3naro> joooooojooooooooooo
<ntpttr> Hi, I was here with this issue yesterday, but I'm still having some trouble today and I'm not getting the same error. I have the juju-gui charm deployed and exposed with
<ntpttr> a public address of node0vm0.maas, but when I go there in a browser it hangs on "connecting to the juju environment"
<ntpttr> I do have a proxy set up, but to my knowledge it's configured correctly
<lazyPower> ntpttr: which browser are you using?
<ntpttr> lazyPower: I've tried firefox and chrome - on firefox going to https://node0vm0.maas hangs on the connecting screen and on chrome it says ERR_CONNECTION_CLOSED
<lazyPower> rick_h_: ^
<lazyPower> ntpttr: I've seen some strange issues out of browsers like safari and self signed certificiates, it accepts for the http session but not the websocket connection. But w/ chrome you should be g2g
<ntpttr> lazyPower: If I curl the address here's what it gives me. Does it matter that it's 'moved permanently'? http://pastebin.com/wHwSkPR3
<rick_h_> ntpttr: it's redireceting port 80 to port 443 for ssl
<rick_h_> ntpttr: so both ports need to be open and reacahable via the proxy
<ntpttr> lazyPower: Because in chrome the details on the error say that it might have moved permanently, but not sure where
<rick_h_> ntpttr: if you open chrome dev toolbar there's a network tab where you can see the GUI reaching out (the spinning wheel part) to the juju state server
<rick_h_> ntpttr: and the proxy needs to be allowing a secure websocket
<rick_h_> ntpttr: wss://
<rick_h_> ntpttr: it sounds like there's a proxy issue.
<ntpttr> rick_h_: Hmm I thought I had my proxy configured this same way a few days ago when it was working...
<rick_h_> ntpttr: are there any details in the network tools?
<rick_h_> frankban: is there a way to 'curl' a wss connection to test it out from the cli or the like?
<ntpttr> rick_h_: The only thing in the network tab in chrome is saying failed to load resource: connection closed
<rick_h_> ntpttr: for what url?
<frankban> rick_h_: reading backscroll
<rick_h_> ntpttr: I'm guessing the proxy is closing things on your as 'not allowed'
<rick_h_> ntpttr: but it is a guess, apologies
<ntpttr> rick_h_: The URL is node0vm0.maas, it's what the orange box example bootstrap script sets up
<rick_h_> ntpttr: ok, so that's the url of the state server juju is running?
<ntpttr> rick_h_: I have '.maas' in my no_proxy list
<rick_h_> ntpttr: but the connection should be to the domain that the juju-gui charm is on?
<frankban> rick_h_: the easiest way is using the python websocket client, e.g. create_connectiion(url) and check that it works
<rick_h_> ntpttr: are they colocated on the same machine/network?
<frankban> rick_h_: url being wss://{GUI-ADDRESS}/ws
<ntpttr> rick_h_: the service is being run on a VM in the machine I'm trying to access the URL on
<rick_h_> ntpttr: right, but are they on the same DNS name then?
<rick_h_> ntpttr: e.g. are both http://node0vm0.maas/ ?
<ntpttr> rick_h_: Hmm I think so, I'm sorry I'm a little confused
<rick_h_> ntpttr: so 10.14.100.1 is the GUI, and it redirects to 10.14.100.1:443 and then it'll try to build a wss to 10.14.100.1.
<rick_h_> ntpttr: I'm wondering if there's a collision on that IP address from your point of view
<rick_h_> ntpttr: e.g. we think connecting to 10.14.100.1 is the GUI but really it's juju itself? or something else deployed?
<ntpttr> rick_h_: Oh I'm not sure, no other services are deployed
<rick_h_> ntpttr: how did you deploy the juju-gui?
<ntpttr> 'juju deploy --to 0 --repository=/srv/charmstore/ local:trusty/juju-gui' after bootstrapping node0vm0
<ntpttr> and then 'juju expose juju-gui'
<rick_h_> ntpttr: right, you deployed it to the same server juju itself is running on. Try changing the juju-gui port to something non-stnadard.
<rick_h_> ntpttr: https://jujucharms.com/juju-gui/#charm-config-port
<ntpttr> rick_h_: Okay I'll give that a shot
<rick_h_> frankban: what's the wss port by default? We don't normally collide with juju when colocated right?
 * rick_h_ is having sprint mental fatigue. 
<frankban> rick_h_: 443 by default
<ntpttr> rick_h_: The odd thing though is that it worked before with this setup, and this is the default way orange box does it
<frankban> rick_h_: or based on a gui charm option
<rick_h_> ntpttr: yea, sorry. I'm brain farting at the moment trying to think.
<frankban> ntpttr: does it work using incognito mode?
<ntpttr> frankban: No
<rick_h_> ntpttr: ok, so if you hit "ctrl-shift-j" you get the chrome dev tools. In there you get a nav and click "Network"
<rick_h_> ntpttr: then reload the page, and click the 'filter' icon that looks like a funnel and pick "WebSockets" from the list
<rick_h_> ntpttr: and can you screenshot what that looks like please?
<ntpttr> rick_h_: how should I share the screenshot? The screen is blank when I pick websockets
<rick_h_> ntpttr: after reload?
<rick_h_> ntpttr: I guess then it'd be interesting to see the list unfiltered then. The websocket should be there really early in the page load
<ntpttr> rick_h_: the only things showing up are data:image/png and 'node0vm0.maas     (failed)'
<rick_h_> ntpttr: on a fresh reload?
<ntpttr> rick_h_: yeah
<ntpttr> rick_h_: one second I'm uploading a screenshot
<ntpttr> rick_h_: http://postimg.org/image/sseqzhpy9
<rick_h_> ntpttr: so looking at that, there's something taking https://node0vm0.mas to https://node0vm0/:1 ?
<ntpttr> rick_h_: hmm I don't know what that would be about...
<rick_h_> ntpttr: me either :/
<lazyPower> rick_h_: i've not had the gui collide with the bootstrap server in my experience (late i know, but confirmation)
<rick_h_> lazyPower: yea
<rick_h_> lazyPower: but if there was a 'proxy' setup then I was wondering if things are nested/etc
<lazyPower> ah, yeah
<rick_h_> lazyPower: ntpttr I've got to run for a sec. Sorry, but just not sure what's up. ntpttr I'd like to see if you can curl the main index.html page and get that back as I can't tell the actual urls from your netowrk tab. It's cut off. But it looks like you're not getting a spinning circle, but no files are able to come through
<rick_h_> ntpttr: the one thing that you might check is that the gui is running (maybe it died?) by ssh'ing to the unit and checking of guiserver is in the ps output
<ntpttr> rick_h_: Okay I'll try that out thanks for the help
<skylerberg> Is there a way to retrigger uosci-testing-bot?
<pmatulis> for 'juju upgrade-juju', is the new software d/l'd to the client which then sends it to the state server which then distributes it to instances? or what?
<ntpttr> Are there logs for this IRC channel?
<wolsen> skylerberg, beisner can help you with that - or you can move the merge proposal into WIP for ~40 minutes then back to Ready for Review - OSCI bot runs on a timer for now and won't re-run against unchanged merge proposals
<skylerberg> ntpttr: Yes, http://irclogs.ubuntu.com/
<skylerberg> wolsen: Thanks. Going with the WIP solution.
<wolsen> skylerberg, ack
<natefinch> lazyPower: juju's wordpress seems to have a fairly critical bug - you can't upload pictures for your posts etc.   Is there some configuration I need to set up to enable that?
<marcoceppi> natefinch: what's tuning set to?
<natefinch> marcoceppi: the default, uh... single
<marcoceppi> you should be able to upload, what error are you getting?
<natefinch> marcoceppi: there's a panel on the right that says UPLOADING  and under it "foo.jpg    HTTP error"
<natefinch> marcoceppi: btw, can repro easily on local provider, but saw it first on a manually provisioned digital ocean machine
<natefinch> marcoceppi: I'm happy to look for log messages, but I couldn't figure out where WP was keeping logs (if it does)
<marcoceppi> natefinch: if you're using nginx as the engine, there's a php-fpm log either in /mnt or /var/log
<marcoceppi> the wordpress charm is...crufty
<natefinch> marcoceppi: lol... I'm figuring that out.
<natefinch> marcoceppi: ahh, nginx log has it in /var/log/nginx/error.log:
<natefinch> 2015/09/03 14:24:00 [error] 31196#0: *161 client intended to send too large body: 1326272 bytes, client: 10.0.3.1, server: _, request: "POST /wp-admin/async
<natefinch> -upload.php HTTP/1.1", host: "10.0.3.202", referrer: "http://10.0.3.202/wp-admin/customize.php?return=%2Fwp-admin%2F"
<natefinch> marcoceppi: so, some nginx configuration problem, given that wordpress says 2megs is ok, and I'm only sending 1.3megs
<natefinch> marcoceppi: https://bugs.launchpad.net/charms/+source/wordpress/+bug/1491995
<mup> Bug #1491995: Can't upload files to wordpress <wordpress (Juju Charms Collection):New> <https://launchpad.net/bugs/1491995>
<aisrael> Database relation question (using postgresql): I'm testing a charm, destroying and re-deploying it occasionally. What's the proper way to cleanup the database when the relation is broken, so that tables aren't left behind owned by the previous user? IOW, I have tables owned by db_1_foo so a new deploy assigned the user db_2_foo can't change said tables.
<aisrael> stub: ^^ might be a question for you
#juju 2015-09-04
<stokachu> anyone seen an error like this http://paste.ubuntu.com/12266891/, running on wily inside a wily container (as in juju bootstrap while inside the container)
<stokachu> and a custom juju_home /home/ubuntu/.cloud-install/juju/local
<stub> aisrael: With the new charm, you will get the same database if you recreate the service with the same service name. With the old charm, it deliberately won't clean up (because that would be dataloss).
<stub> aisrael: We could provide actions for some of these operations, for people uncomfortable with reaching in and dealing with PG directly.
<jamespage> coreycb, does https://bugs.launchpad.net/charms/+source/neutron-api/+bug/1456291 ring bells for you? I remember a fix for keystone token handling that you did but I can't find it
<mup> Bug #1456291: HA deploy: one neutron-api unit had wrong credentials in memory <landscape> <neutron-api (Juju Charms Collection):New> <https://launchpad.net/bugs/1456291>
<aisrael> stub: The problem I see with the new behavior is that the schema (tables and such) are owned by the previous user. Would it make sense to change ownership of those things when new credentials are handed out?
<ParsectiX> Hi guys. I find the idea of juju very interesting. I'm wondering about the H/W and what I need to lunch my own private juju service.
<ParsectiX> Can someone advice about physical deployments ?
<coreycb> jamespage, yes there was an sru to python-keystonemiddleware in (at least) utopic for that
<jamespage> coreycb, oh - right so for juno only  gotcha
<aisrael> stub: cleanup from the -broken relation doesn't work because the credentials are already removed from the database. I don't see a way for the charm author to deal with this.
<jamespage> beisner, coreycb, zul, gnuoy: liberty is deployable from trusty-liberty-proposed with next charms
<jamespage> basic boot and access worked OK
<beisner>  \o/
<gnuoy> tip top
<jamespage> I'm tempted to slam-dunk that straight into updates as well and bank it now
<beisner> jamespage, i queued up a deploy test w/ tempest etc in uosci
<jamespage> beisner, yeah - that's not working so well right now
<beisner> jamespage, ah but a point of reference "the beginning"  ;-)
<jamespage> indeed
<jamespage> beisner, lol - I just screwed up my tempest.conf that's all
<apuimedo> jamespage: ping
<jamespage> apuimedo, hey
<jamespage> coreycb, zul: b3 next week then :-)
<apuimedo> jamespage: just a question about the rendering
<apuimedo> of the templates in charmhelpers/openstack/templating.py
<apuimedo> what is creating the target directories for the the rendering?
<jamespage> apuimedo, directories are not created by the templating framework - normall they are overwriting configuration files provided in packaging
<jamespage> apuimedo, if not then charm-helpers provides a mkdir function that you can call before trying to render anything.
<jamespage> allowing you to secure things as required...
<apuimedo> jamespage: I see, thanks ;-)
<apuimedo> I did put the mkdir workaround but stupidly did it before neutron got installed so the user that I was using for ownership of the dir did not exist back then
<apuimedo> :P
<apuimedo> I was checking how nuage and calico deal with the lack of creation of the plugin dir
<apuimedo> but I could not find any mkdir that they issue for /etc/neutron/plugin/{nuage,calico} so I guess that their packages create those directories
<jamespage> apuimedo, normally yes
<apuimedo> jamespage: I'll file a bug agains midonet plugin packaging then to create the empty dir or maybe even with an example config :-)
<apuimedo> jamespage: thanks for the info ;-)
<jamespage> apuimedo, http://paste.ubuntu.com/12273645/
<jamespage> ok in distro
<apuimedo> jamespage: unfortunately those are outdated from back when the vendor plugins were in the neutron tree
<apuimedo> jamespage: we are moving to have a ppa
<apuimedo> and we want to move it inside cloud-archive
<lazyPower> apuimedo: I assume the service you're writing files for is not a subordinate service?
<apuimedo> no
<apuimedo> lazyPower: it is neutron-api
<lazyPower> ah hokay
<apuimedo> lazyPower: why, would that complicate matters?
<apuimedo> (well, ordering could)
<lazyPower> apuimedo: i was going to suggest that it could be easier :)
<apuimedo> lazyPower: well, I'm really looking forward to the neutron plugin configuration being based on subordinates
<apuimedo> I think it was jamespage who showed me the plans and they looked really nice
<lazyPower> apuimedo: http://bazaar.launchpad.net/~charmers/charms/trusty/neutron-api-plumgrid/trunk/view/head:/metadata.yaml - it can be today unless i'm missing something
<lazyPower> i just reviewed this stack earlier in the week
<lazyPower> yeah jamespage is a bit of a local folk hero 'round these parts :)
<lazyPower> apuimedo: is this ready for re-review and hasn't gotten any attention or are we just monitoring for progress at the moment? https://bugs.launchpad.net/charms/+bug/1453678
<mup> Bug #1453678: New charms: midonet-host-agent, midonet-repository, midonet-api <Juju Charms Collection:New> <https://launchpad.net/bugs/1453678>
<apuimedo> lazyPower: I was blocked due to other work
<apuimedo> lazyPower: this week I got back to it
<lazyPower> ack, just checking in, no pressure :) Wanted to make sure you weren't blocked on us.
<apuimedo> lazyPower: no, not yet
<apuimedo> thanks
<apuimedo> all ready for the Charmers Summit?
<lazyPower> not exactly - but getting there :)
<apuimedo> :-)
<lazyPower> apuimedo: so, we're going to have a couple sessions about rapid charming w/ layers to deliver app containers re-using components that mbruzek and I have built
<lazyPower> based on our last convo, might be applicable to your efforts
<apuimedo> lazyPower: sounds like it
 * mbruzek waves at apuimedo
<apuimedo> I'll have to make one last effort to get approval to join
<apuimedo> mbruzek: hey!
<mbruzek> hello apuimedo!
<jamespage> lazyPower, apuimedo: can't really take credit for that - gnuoy did the work :-=)
<apuimedo> gnuoy: good job on that ;-)
<jamespage> apuimedo, two of thos base layers should be 'neutron-api-subordinate' and 'neutron-edge-suboridate' - I need to flesh those out
<apuimedo> jamespage: will there be a session about that in the charmers summit?
<jamespage> apuimedo, hopefully
<apuimedo> :-)
<apuimedo> catbus1: nice nick
<catbus1> :)
<lazyPower> apuimedo: i'm going to mark 1453678 as in progress since you're working on it and its sitting in teh queue at 30 days, unreviewed, and its not ready for re-review.
<apuimedo> ok
<lazyPower> when you're ready, make sure you update that bug to fix-committed or new and it'll make its way back in
<apuimedo> lazyPower: ok, thanks!
<apuimedo> lazyPower: is there some way to change history in launchpad's bzr?
<lazyPower> apuimedo: in what context?
<lazyPower> as in force push your repository?
<jamespage> beisner, we'll need todo a general charm update for liberty to switch mysqldb -> pymysql
<beisner> jamespage, huh where?
<jamespage> beisner, all over
<jamespage> mysql:// -> mysql+pymysql://
<beisner> jamespage, in the db_uri in amulet tests?  or even broader?
<jamespage> beisner, for liberty configuration file templates - and I guess the amulet tests as well
<beisner> jamespage, gotcha.   kind of a weird db uri.  is that going to stick @ L?
<beisner> they must have some add'l uri parser foo in L
<jamespage> beisner, yeah - its in sqlalchemy
<jamespage> most of our charms continue to work as they use the mysqldb syntax and explicitly install the mysqldb package
<jamespage> but there are good reasons to switch to pymysql
<jamespage> py3, better aio
<jamespage> beisner, hmm - although I think that coreycb may have tried to fix this up in sqlalchemy
<beisner> jamespage, coreycb - trusty-liberty-proposed - basic deploy check ok, just 2 tempest fails;  http://10.245.162.77:8080/job/deploy_with_deployer/11245/consoleFull
<beisner> jamespage, can you review this nova-compute ppc64el MP?  i may also do a separate proposal later to make it smarter / more automagic, but needed to at least expose these controls to have a working bundle.  https://code.launchpad.net/~1chb1n/charms/trusty/nova-compute/cpu-mode/+merge/269952
<jamespage> beisner, one niggle
<jamespage> beisner, also does that context get used for nova.conf?
<beisner> jamespage, ack re: arch detection conditional;   yep, nova.conf.
<beisner> jamespage, on the topic of arch detection, should we go as far as to make the nova-compute charm just do those things when deployed on ppc64el, and indicate that in the config.yaml config descriptions?
<beisner> ie.  just work
<jamespage> beisner, yes
<jamespage> skip if its not ppc64el
<jamespage> no-op
<beisner> jamespage, and if user sets options explicitly, use those in all cases?
<beisner> except non ppc64el of course
<beisner> ie. explict trumps automagic
<beisner> explicit even
<benbc> Hello. What is the normal approach to installing different versions of software? Do users expect to see charms named for different versions (e.g. `juju deploy postgresql-9.3`)? Or are charms parameterized with the version number (e.g. `juju deploy --config config.yaml postgresql` with `version: 9.3` in config.yaml?) or do all charms in practice just install the latest version of the software?
<benbc> Or some other possibility that hasn't occured to me?
<jamespage> beisner, oh wait - I see what you're saying
<jamespage> beisner, ok - how about we reword that config option to be a boolean - as its on/off true/false
<jamespage> provide a suitable default, and only apply it on ppc64el
<beisner> jamespage, int is a valid value in that cmd
<beisner> on/off/int
<jamespage> oh
<jamespage> what does int do?
<beisner> there are smt modes, which can be set by ints
<jamespage> beisner, I need to eod - my brain is fried
<beisner> jamespage, np.  thx for the input.  i won't be doing much with that until next wk, no worries.
<jamespage> beisner, ok - it sounds like on/off/int is valid then but that might be better modelled as two config options - smt on/off
<jamespage> and then an optional 'int' value if its turned on?
<jamespage> does 'on' do a sane default?
<beisner> jamespage, or no config options and it all just works ;-)   jk, kind of.
<beisner> jamespage, no it would need to be off for nova-compute
<jamespage> beisner, we should provided an optionionate default for our experience, with knobs for experts
<jamespage> does that make sense
<jamespage> ?
<beisner> jamespage, yep, agree
<jamespage> and make sure that if someone tries this on amd64 - it no-op's
<jamespage> that's my guidance - I'll review again on monday if you want to update today :-)
<jamespage> ttfn
<beisner> jamespage, ack, will adjust next wk  or on my next ppc64el endeavor.
<jamespage> beisner, oh - btw - I've pushed proposed->updates for liberty
<jamespage> its OK for now
<beisner> woot
<jamespage> beisner, I've also switch the default mysql dialect in sqlalchemy to be pymysql
<jamespage> so that the existing mysql:// string dtrt
<beisner> ah nice
<skylerberg> beisner: I am getting CI failure's on my patch (https://code.launchpad.net/~sberg-l/charms/trusty/nova-compute/tintri-interface/+merge/269998).
<skylerberg> I think the issue is on the CI server's end, because it looks like a deployment is timing out and my commit shouldn't have any impact on that process really.
<beisner> o/  skylerberg, commented, re-queued the job.
<skylerberg> beisner: thanks!
<beisner> skylerberg, welcome
<DrewT> anyone here have experience deploying openstack using the postgresql charm? I can't get the keystone charm to populate the db after db_sync creates the schema
<marcoceppi> DrewT: I've not tried actually, I've always just kind of used mysql
<marcoceppi> beisner: do we have a test in OSCI for postgresql?
<beisner> hi marcoceppi - pgsql isn't watched by uosci
<marcoceppi> beisner: DrewT was having some issues with psql and keystone, was wondering if it was tested at all
<beisner> marcoceppi, we exercise mysql + keystone || percona xtradb + keystone, but not pgsql
<dbainbri> with the docker charm I can deploy docker and then use juju run to execute a container on the docker instance, but what I am looking for is a way to expose one or more servers running docker as a "machine" onto which I can "place" docker based charms. So that in the JuJu UI I can create configurations based on docker charms and then commit them to be placed at which point they will be deployed to those systems that are running docke
<beisner> thedac, ok, rabbits released to wolves @ https://code.launchpad.net/~1chb1n/charms/trusty/rabbitmq-server/amulet-refactor-1509b/+merge/270102    ...thanks!
<thedac> beisner: great, thanks
<marcoceppi> dbainbri: you should talk with mbruzek and lazyPower, they might be able to help you there
<dbainbri> marcoceppi: thx.
<mbruzek> dbainbri: There is a lot of docker in your question.  Let me ask a few questions.
<dbainbri> mbruzek: fire away
<mbruzek> dbainbri: How would the Juju UI create configurations ?
<mbruzek> One could certainly write a charm that installs docker, and as a configuration option lets you configure which docker image to pull and run.
<mbruzek> That configuration option could be changed via the UI (or command line).
<mbruzek> I don't think I understand your question correctly.
<dbainbri> mbruzek: i am a newbie wrt Juju so please bear with me. You mean configurations for the containers or for the docker instances?
<marcoceppi> mbruzek: it sounds like, and correct me if I'm wrong dbainbri, that you have a docker solution for something, but you want to wrap a charm around it so you can deploy it with docker, get density, but still use juju to manage it (relations, etc)
<dbainbri> I would like to point Juju at a bunch of docker instances (hosts running docker)
<mbruzek> dbainbri: I am not sure we can do that at the moment.  Juju would have to have deployed those docker instances to be able to orchestrate/manage them.
<dbainbri> mbruzek: I would like Juju to treat hosts running docker as a machine on which "docker" charms can be placed.
<mbruzek> ah
<mbruzek> dbainbri: That does not work at the moment, we do have a container technology called LXC that is very similar to Docker, but it models a machine container, rather than an application container.
<mbruzek> But since LXC is not Docker you can't run your favorite Docker image in LXC.
<dbainbri> mbruzek: is there a writeup of that somewhere?
<mbruzek> Juju can currently treat the Virtual Machines that you get from Amazon, GCE, OpenStack as LXC hosts and you can put many LXC images inside a VM.
<dbainbri> and those LXC images are "placed" much like a charm on a host in Juju?
<mbruzek> dbainbri: yes.
<mbruzek> dbainbri: I am looking for some documentation for you, the problem is LXC is also our "local" cloud story.
<dbainbri> that sounds like what I am looking for except I am looking for that on a local hosts in Juju and with docker
<mbruzek> Using LXC you can make your computer look like a cloud, so you can deploy multiple LXC images to your desktop or latop
<marcoceppi> the problem with this is that you still ahve to code up how to install the software onto the LXC container, the LXC image is just a base clodu image
<mbruzek> But that is not what you are looking for, unfortunately that is all I find in the search results.
<dbainbri> any desire / plan to add this same capability with docker or the open container work?
<marcoceppi> dbainbri: yes, we're actively working on something like this in juju though I'm not sure if it's exactly how you described it
<dbainbri> marcoceppi: where are my thoughts off from what is being worked on?
<marcoceppi> dbainbri: we're working to expose "workloads"/process running in juju, so you could deploy the docker charm, add workloads. Or deploy kubernetes, rocket, KVMs, and the charm would tell juju that it's running these items
<mbruzek> dbainbri: We don't have as good of integration with Docker as you want.  Even the current work I am not sure it will be what you are looking for.
<marcoceppi> dbainbri: it wouldn't directly allow you to configure it, but we have tools that will let you wrap docker in charms, so if you have a foo server in docker, you can easily build a charm around that, exposing configuration, etc, then deploy it and manage it with juju
<marcoceppi> mbruzek lazyPower do you guys ahve examples using the docker layer stuff?
<mbruzek> marcoceppi: we are writing that up now, it is very rough and not what dbainbri has described
<marcoceppi> mbruzek: right, but if you take the docker composer items, and use juju deploy --to
<mbruzek> That is writing a docker charm, he wants to deploy charms to a docker host
<dbainbri> marcoceppi: i thought i saw a docker-seed charm that could be expanded to run a single (or multiple) docker containers in a charm, but it really is just a wrapper to run a static set of containers
<mbruzek> dbainbri: That is where we are at at the moment
<mbruzek> dbainbri: https://jujucharms.com/docs/stable/charms-deploying#deploying-to-specific-machines-and-containers
<mbruzek> dbainbri: So when you deploy by default Juju gives you a new Virtual Machine.  You can use "--to <machine number>/lxc/1" to deploy the same charm to an LXC container
<mbruzek> I know that is not docker but that is how we use containers in Juju at the moment.
<dbainbri> mbruzek: i suppose the "docker-ssed" charm could take a config file that is a set of containers to start and how to connect them (a docker-compose file for example)
<mbruzek> The Juju GUI also has a tab called "machine view" where you can deploy to LXC containers within a VM as well.
<dbainbri> or use Juju to deploy a bunch of docker instances and then Kubernetes or or compose to layer containers on them.
<mbruzek> dbainbri: Yeah I think you are on to something there.
<mbruzek> dbainbri: We have kubernetes charms, but that creates a cluster for you and then you would have to deploy things to the cluster with kubectl
<dbainbri> does every charm map to a VM ?
<marcoceppi> almost always
<mbruzek> dbainbri: Except for the "subordinate" charms, which can share a VM with another charm.
<marcoceppi> mbruzek: and manual placement via --to
<marcoceppi> and containers which really aren't vms
<marcoceppi> and in the case of bare metal
<mbruzek> dbainbri: but yes almost always a VM.  And you can pack many LXC containers on one VM similar to Docker
<marcoceppi> I think "machine" may be more appropriate verbiage
<dbainbri> mbruzek: subordinate charms, sounds interesting. do subordinate charms show up in the UI as first class citizens?
<mbruzek> yes
<mbruzek> https://jujucharms.com/docs/1.24/authors-subordinate-services
<dbainbri> so could "docker container charms" be subordinate charms that you could dynamically relates to a docker charm?
<marcoceppi> dbainbri: yes
<mbruzek> Subordinates don't use container technology at all, they just share the filesystem with a VM.
<dbainbri> ah, ok
<marcoceppi> mbruzek: well, what he described could work
<dbainbri> so i couldn't make a subordinate charm that essentially did a "docker run"
<marcoceppi> mbruzek: docker base charm, that manages installing docker, subordiante that provides a relation that describes the container it's installing
<mbruzek> dbainbri: and one strategy could be to deploy a VM running Docker (via a docker charm) and then deploy a bunch of subordinates that know how to start up their own docker services.
<dbainbri> marcoceppi: yes something like that
<marcoceppi> okay, I think we're straying a bit in this conversation
<mbruzek> There you go
<marcoceppi> So, from a juju perspective you have services, units, and machines
<dbainbri> mbruzek: would agree we are straying. just looking at possibilities. would prefer that docker instances could be treated as "object on which docker based charms could be placed, but interested in what can be done now as well.
<marcoceppi> services are charms, units are the number of machines that are running in that service (think scale out), and machines are the resources in a cloud that are deployed
<marcoceppi> with that model, you could create a charm for each docker service you want to deploy, and then have juju provision one machine and force each unit of the charm to live on that single machine.
<marcoceppi> the second workflow is a subordinate workflow, but subordinates aren't first class citizens, they don't get assigned to machines (and machines are a full operating system so either bare metal, a cloud instance, or an LXC container)
<marcoceppi> instead they are attached to primary services, so think of things like monitoring agents or logging agents
<marcoceppi> it doesn't make sense to have them on their own machine, but instead on an existing workload
<marcoceppi> so you could use a subordinate model to drop workloads on a docker service
<dbainbri> marcoceppi: with respect to your first option. ultimately you could build out several units for "docker" and then the docker services are forced to one of those machines
<marcoceppi> dbainbri: So the first solution isn't the worst, i think for what you're describing it's the best course of action until juju grows app containers as a first class citizen
<dbainbri> marcoceppi: * nod *
<marcoceppi> dbainbri: if you force X primary services onto a single machine, you run the risk of collisions, so if the charm was clever enough (ie, is docker installed? no - install, other wise just docker run) and the containers didn't conflcit with resources
<marcoceppi> dbainbri: if you were to "scale out" any of those charms, they'd just get a fresh machine from the provider, where as you can't scale out a subordinate without scaling the base. So if you have foo and bar subordiantes, and you scale the docker primary service, you get an additional foo and bar container running
<marcoceppi> I feel like I'm not doing the explaination justice, it's a pretty niche scenario, we call it "hulk-smashing" and it typically ends up broken deployments. (ie, forcing mysql and mariadb to the same machine in juju will break because they'll stomp on each other)
<mbruzek> (use the same files)
<marcoceppi> this is why we have LXC support in juju, you can have one machine in juju, but juju can create LXC containers, full system containers, on this machine, so MySQL and MariaDB could be deployed to two LXC containers on one machine without conflicting
<marcoceppi> the charm has no idea, it just has root on an operating systema and runs as expected
<dbainbri> marcoceppi: with docker that conflict would likely be at exposing ports on the hosts.
<marcoceppi> dbainbri: exactly, so you'd have to make sure port was configurable in each image, and you'd have to make it a configuration option on each of the charms
<marcoceppi> dbainbri: so you could map each port yourself in the deployment
<marcoceppi> again, it's not the prettiest, and it's an edgecase, but there are ways to achieve what you've described
<marcoceppi> dbainbri: I'd be happy to write up a little example set of charms if you're interested
<marcoceppi> dbainbri: also, not sure where you are in the world, but we've got a juju charmer summit coming up in two weeks: http://insights.ubuntu.com/event/juju-charmer-summit-2015/ if you're interested in attending and chatting more about this
<dbainbri> marcoceppi: i am interested if you are willing to do the write up ;) i am on the left coast (US) so not near DC (used to live in Boston, but now in CA)
<marcoceppi> dbainbri: sure, I'll try to create a few real simple examples
<marcoceppi> dbainbri: I'm not really proficent in docker, but mbruzek and lazyPower have some great examples already
<dbainbri> i will start by playing with the docker-seed and expanding it, seeing what i can do there. but any info from those with more knowledge is more than appreciated.
<dbainbri> thx everyone, just for this chat, very helpful.
<mbruzek> welcome
#juju 2015-09-05
<h0mer> anyone here have experience with juju using the cannonical openstack deployment?
<bbaqar> Hey guys I have a deb package that creates a lxc but I need a way to make apparmor aware of this lxc. Currently I am just disabling the apprmor profile for libvirt to get the lxc started.
<frenda> Is JuJu sth like http://sandstorm.io ?
<frenda> I'm interesting in running a paid Sandbox host (where users can install any apps they want), But Sabdstorm.io selling system (called Blackrock) is not free
<frenda> Is there any plugin for JuJu to do that?
<frenda> Am I in a wrong channel? Is here for developer?
<frenda> Hey?
<frenda> !Juju
<frenda> I'm interesting in running a paid sandbox host (where users can install my app); Can JujU do it?
#juju 2016-09-05
<chigang_> Hi charmers,  I have a question about charm status. when I login https://code.launchpad.net/charms, I saw charms branches with different status,  such as merged,  mature, etc. But I can't understand what the "merged" branches are used for ?  Could you tell me more about  "merged" branches ? thank you
<hloeung> chigang_: this is more "Launchpad". Those with "merged" means the changes has made it into the main charm code branch
<hloeung> chigang_: https://help.launchpad.net/Code/Review?highlight=%28merged%29#The_flow_of_this_process
<chigang_> hloeung: It is a great help! I need some time to understand the launchpad code workflow , thank you
<huhaoran> hello,  I want to build a simple all-in-one with existed juju charms in LXD. Do anyone tried before?  Juju 1.5 or 2.0, which is better?  Trusty or Xenial, which is better? Thanks
<huhaoran> simple all-in-one openstack environment
<kjackal> Hello Juju World!
<blahdeblah> Hello Juju World!  If you use the NTP charms, please have a look here: https://docs.google.com/a/canonical.com/forms/d/e/1FAIpQLSfGCYyA1xPCMQ3DWKNVbHjN-DTW48uIlXurzZMyGt1i3FhBcw/viewform
<BlackDex> Hello... Is there an option to disable the jujud debuging option?
<BlackDex> so just normal logging and no debug
<kjackal> admcleod: hey mister are you there?
<magicaltrout> s/mister/baldy
<kjackal> hey magicaltrout you might also know
<magicaltrout> nope
<kjackal> have you noticed anything strange with charm publish?
<kjackal> for instane disapearance?
<magicaltrout> not in the last week or so that I can remember
<kjackal> I see, it must be something in my system then
<kjackal> thanks magicaltrout
<admcleod> kjackal: i am now
<admcleod> kjackal: i havent done charm publish for a while so no idea
<kjackal> admcleod: I think the verbe chaged to release
<kjackal> admcleod: I also didn't do a publice recently
<admcleod> kjackal: in 2.0 16?
<kjackal> charm version
<kjackal> charm 2.2.0-0ubuntu1~ubuntu16.04.1~ppa2
<kjackal> charm-tools 2.1.4
<admcleod> kjackal: im using 1.26 at the moment anyway
<admcleod> magicaltrout: remind me where in spain you're going?
<magicaltrout> depends what talks I find enough time submitting to :P
<magicaltrout> aiming for big data spain and apachecon
<magicaltrout> madrid and seville
<magicaltrout> but none of that is confirmed
<admcleod> ok, i will try for seville also
<admcleod> wanna share a room?
<magicaltrout> hehe
<magicaltrout> I'm okay thanks
<admcleod> :(
<admcleod> ccccccdubjcrittlinctevdhiulrrkjbgucknnbcfjuf
<admcleod> err...
<magicaltrout> you'll shave my head or something to exact revenge
<admcleod> that has nothing to do with my ubi key at all.
<admcleod> move along.
<magicaltrout> lol
<magicaltrout> rented a car for pasadena
<magicaltrout> wonder how many people i'll kill
<admcleod> man, shaving a head is not revenge. its sublime.
<magicaltrout> lol
<admcleod> when do you arrive? and what did you rent?
<magicaltrout> Saturday
<magicaltrout> "Ford Taurus LTD or similar"
<admcleod> crysler saturday?
<admcleod> ah
<admcleod> i hope they run out of taurus's's
<magicaltrout> considered a mustang convertable for a while
<admcleod> thats worse than a blue cheese chocolate sundae
<magicaltrout> my first trip to the states I delibereately tried to rent something compact, when I got there they'd run out so they get me a Nissan Altima
<magicaltrout> they aren't compact....
<admcleod> haha nope
<admcleod> i did a road trip from denver -> vegas -> denver, i intended to rent 300c or similar.. ended up with a mazda 3
<magicaltrout> hehe
<magicaltrout> yeah, I'm not sure i've ever got what I ordered
<magicaltrout> we'll see when I get to LA
<magicaltrout> but I have Thurs-Sun to drive around a lot and a commute to San Diego the next week as well
<magicaltrout> and its better than a train
<admcleod> yeah should be fun
<magicaltrout> missing my youngests 2nd birthday for the Summit so this week I'm mostly grovelling ;)
 * admcleod sudden flashback to every movie where that happens
<magicaltrout> yeah
<admcleod> "...and thats why i killed 20 people in a supermarket."
<magicaltrout> nearly missed the eldests first day at school as well
<magicaltrout> i'd have been shot for that
<admcleod> well, when daddy gets to the moon itll all be worth it
<magicaltrout> hehe
<admcleod> ill let you buy me a beer to help you get past it
<magicaltrout> i'll see if my expenses will reach that far
<magicaltrout> you have posh tastes
<admcleod> well, what with the emotional torment you caused me with the baldie comment... (can hardly type through the tears)
<admcleod> i can do cheap.
<magicaltrout> off to bletchley park tomorrow, i might not be allowed into the US if they find I've been learning about cryptography
<magicaltrout> even if it is WWII ;)
<admcleod> fingers crossed
<magicaltrout> pfft
<magicaltrout> you'd all miss my amazing talks
<admcleod> that they let you in!
<admcleod> what! you dont think...
<magicaltrout> I have no talk, no working software and a half working charm, better get it working before Monday
<admcleod> fingers still crossed
<PCdude> heeyy everybody :)
<PCdude> http://askubuntu.com/questions/820925/how-do-i-set-a-dns-server-in-maas-that-will-be-passed-on-to-the-nodes
<__szilard_cserey> ?
<PCdude> I get the following error
<PCdude> http://imgur.com/a/Z47K1
<PCdude> the log file does not show anything
<PCdude> any idea on how to solve it?
<marcoceppi> PCdude: what error? I don't see one in the picture
<pragsmike> hey marco, thanks for those articles on openstack with two servers.  they're a couple years old by now but it still helped me.  I hadn't known about NUCs.
<marcoceppi> pragsmike: hey, glad it helped you. they are ANCIENT!
<pragsmike> well I had been building a setup kinda like that but with old desktops, using an old APC masterswitch.  This week I found out that NUCs can be power-controlled via AMT, no masterswitch required.
<pragsmike> So yeah, I'm a couple years behind the curve.
<magicaltrout> i backed a kickstarter so I could build a poor mans orange box: http://www.udoo.org/udoo-x86/
<magicaltrout> shame they'll ship too late for the charmers summit
<pragsmike> ooh!
<marcoceppi> damn, the stats and size on those is nice
<magicaltrout> yeah
<magicaltrout> i have 4 on the way
<magicaltrout> and they upped the ram from 8gb to 32gb
<magicaltrout> so 4, 2.24gz intel boards with 32gb ram for $500
<magicaltrout> my brother studied industrial design at uni, so he can build me a nice enclosure ;)
<marcoceppi> that beats the pants off the NUC stats
<pragsmike> no nvme though
<pragsmike> but what you can fit in a lunchbox is getting insane
<pragsmike> Can you guys point me in the right direction to understand how Juju2/MAAS2 container networks are supposed to work?
<pragsmike> My containers always wind up on the lxdbr0 private network, and aren't managed by MAAS hence don't appear in DNS, and aren't reachable anyway
<marcoceppi> pragsmike: you on beta17 of juju?
<pragsmike> yes
<marcoceppi> pragsmike: huh, it should just work
<marcoceppi> and these are containers created by Juju, yeah?
<pragsmike> yes
<marcoceppi> (should just work, but I still have MAAS 1.9 and haven't managed to upgrade yet)
<magicaltrout> marcoceppi: if you still use virtualbox like your blog post... dont ;)
<pragsmike> Ok, well that's good info anyway, it tells be it's probably me doing something wrong
<marcoceppi> magicaltrout: haha, no, I've got an orangebox here actually ;)
<magicaltrout> booo
<marcoceppi> pragsmike: so, for my setup. I'm getting LXD machines drawing IP addresses from MAAS
<pragsmike> hmm, I still use virtualbox machines in MAAS for testing sometimes, is that bad?
<magicaltrout> not if it works for you pragsmike
<magicaltrout> i wasted 3 days on maas 2.0 and virtualbox, the virtual networking kept dropping off mid bootstrap
<pragsmike> marcoceppi: do you set up any spaces or anything non-default?
<marcoceppi> pragsmike: I think you have to setup the networkign side in maas to do that
<marcoceppi> pragsmike: spaces are setup
<pragsmike> I just let maas create the subnets, VLAN, spaces by default
<marcoceppi> pragsmike: the OrangeBox has some slightly special-ness
<magicaltrout> pragsmike: you got a dhcp reserved pool?
<pragsmike> it seems to DHCP/DNS the metal boxes ok
<pragsmike> yes I do, for my routers, masterswitch, etc.
<marcoceppi> pragsmike: do you lxd machines show up as devices at all?
<pragsmike> it's just the containers that get created end up on lxdbr
<pragsmike> No, they don't
<pragsmike> I looked for that, as the code looks like it might try to do that
<magicaltrout> i spent ages with the virtualbox stuff, then found that the machines weren't getting ip's because i didn't have a dhcp reserved pool for juju machines being commissioned by maas
<magicaltrout> in the end the virtualnet failed me, but that stumped me for about a day until i found a one liner in a doc somewhere
<marcoceppi> vbox was such a crazy work around. KVM is much better way to do MAAS testing
<marcoceppi> pragsmike: so I have two fabrics in one space (space-0) in maas
<marcoceppi> and my lxc machines get IP address in both fabrics
<magicaltrout> you should sponsor pragsmike to the juju summit marcoceppi so he can play with an orange box and figure it out ;)
<marcoceppi> :/ I don't see anything special in my model/controller config to map spaces
<marcoceppi> pragsmike: are you coming to the charmer summit?
<pragsmike> I did see a message in the machine log to the effect that it "failed to prepare, machine with this name already exists"... that's vague, let me find the exact message
<pragsmike> It's tempting...
<magicaltrout> get down there
<pragsmike> especially if I get an orange box
<pragsmike> :)
<marcoceppi> pragsmike: well, you can play with mine for as long as you'd like, I'll ahve it with me there
<marcoceppi> and we'll have a few others IIRC
<marcoceppi> at the very least I'll let you upgrade it to 2.0 maas ;)
<pragsmike> i'm not sure you want me to be the one to do that :/
<marcoceppi> pragsmike: nonsense
<magicaltrout> pragsmike: believe me, you're more qualified than i am
<pragsmike> also, is it normal for the machine logs to get spammed with "upgrader" manifold worker returned unexpected error: cannot set agent version: connection is shut down
<magicaltrout> and also more qualified than marcoceppi i suspect having watched him in ghent! ;)
<marcoceppi> pragsmike: I'm not familiar with that error, is that in the machine log or unit log?
<pragsmike> machine
<marcoceppi> pragsmike: might be worth opening a bug about that, beta18 is around the corner and an RC is looming
<pragsmike> there are zillions of them, in bursts, for pretty much every manifold worker
<marcoceppi> so if that's not supposed to be there, we should probably fix that
<pragsmike> ok, one suspicious message in machine log on the container host: WARNING juju.provisioner lxd-broker.go:62 failed to prepare container "0/lxd/0" network config: connection is shut down
<pragsmike> it's just a warning, and the code says that it doesn't matter if it doesn't get an address (yet)
<pragsmike> and the one I was looking for: WARNING juju.provisioner lxd-broker.go:62 failed to prepare container "0/lxd/0" network config: {"hostname": ["Node with this Hostname already exists."]}
<pragsmike> from later in that same log
<marcoceppi> pragsmike: so dimitern might be able to help you with the networking, he's from the Juju core team that implemented a lot of that, but he's not online right now
<marcoceppi> I am but a meat popsicle
<pragsmike> well in the meantime I'll stare at the code some more
<pragsmike> i must say this is the most fun i've had in a long time
<magicaltrout> get to the summit
<magicaltrout> it'll be bloody amaazing
<magicaltrout> or acceptable at least
<marcoceppi> yeah, over 200 Juju enthusisasts are signed up from across the community
<pragsmike> ooh, 6 days... california...
<marcoceppi> pragsmike: not sure how far you are from Pasadena, but it's next week :)
<magicaltrout> I'm  missing my 2nd borns 2nd birthday for it!
<magicaltrout> (I shouldn't brag about that fact...)
<magicaltrout> i didn't miss  my first borns first day at school though
<magicaltrout> which nearly happened
<pragsmike> priorities
<pragsmike> I'm in NoVA, near DC
<magicaltrout> indeed
<pragsmike> i just started using juju seriously this past week, it's already hooked me because of the attention to testing
<pragsmike> nothing else has that
<magicaltrout> this is true
<pragsmike> my current project is to build an openstack mitaka controller, and even with these network hiccups, it's still turning out easier to do with charms than the way I'd been doing it
<magicaltrout> and the charms that get to the top level namespace need them
<magicaltrout> so you (hopefully) know they're not rubbish
<pragsmike> anything reactive has the potential to misbehave spectacularly, and be fiendishly hard to test
 * magicaltrout has a bunch of stuff to finish before monday and between now and then has to go to bletchley park, work, have fake 2nd birthday for the child and fly to California
<magicaltrout> its gonna be a busy week
<marcoceppi> pragsmike: oy! I'm in NOVA too
<pragsmike> bletchley!  cool stuff
<pragsmike> Vienna/Oakton here
<marcoceppi> pragsmike: no. way. I'm in Vienna
<pragsmike> lol
<magicaltrout> okay so don't bother with Cali
<marcoceppi> off Beulah
<pragsmike> wanna come help me debug my problem :)
<magicaltrout> just swing round marco's house
<marcoceppi> pragsmike: haha, I totally would fly over, but I'm preparing for an early morning demo, then I fly out to CA to prepare for the summit tomorrow evening
<pragsmike> heh we should get together sometime anyway
<pragsmike> going to openstack meetup near dulles?
<marcoceppi> pragsmike: when is it?
<pragsmike> oops, guess not, it's sep 8
<marcoceppi> yeah, not this time around unfortunately
<marcoceppi> pragsmike: I get back next wednesday, if you wanted to meet up on Thursday evening. Shoot me an email: marco.ceppi@canonical.com
<marcoceppi> orrrrr, you could come out to CA ;)
<magicaltrout> which is a much better option
<magicaltrout> than marco's house
<pragsmike> CA is iffy, short notice and I'm kinda hobbling around on a broken foot
<pragsmike> but it's reaallly tempting
<magicaltrout> surely you just hobble to plane, hobble to hotel, hobble to room..... sit.... hobble to plane? ;)
<marcoceppi> we can just "roll out" the red carpet ;)
<magicaltrout> broken feet are for wimps
<magicaltrout> cut it off and walk on  the wound!
<pragsmike> well, maybe for an orange box
<magicaltrout> marcoceppi: how american are you going to be this time? do i need to pack any ant-nausea tablets? ;)
<marcoceppi> magicaltrout: that's an excellent question
<magicaltrout> lol
 * magicaltrout doubles down
<marcoceppi> hah, actually, I'm going to be super english this time
<magicaltrout> what, like kwmonroe 's attempt at mary poppins? or just a bit rude?
<marcoceppi> magicaltrout: the latter, I think kwmonroe was more texan at that point than anything else
<marcoceppi> man, I am in love with the colourized output in beta17
<magicaltrout> hehe. he does a better cockney accent than me which is shameful
<magicaltrout> alright, as  much as i'm trying to live on BST-9 already I have to get the child to school in 8 hours. pragsmike i'll see you in Pasadena... I arrive on Saturday night and have a car so if you need a lift let me know! ;)
<magicaltrout> s/night/late afternoon
<marcoceppi> cheers!
#juju 2016-09-06
<pragsmike> ok trout thanks!
<holocron> anyone here versed in MAAS? I have a hopefully simple problem here
<thumper> most maas folk are us/uk timezoes
<thumper> what's the problem?
<thumper> holocron: ^^^?
<holocron> @thumper thanks mate, well I'm hitting on https://bugs.launchpad.net/maas/+bug/1402861/comments/4 it seems
<mup> Bug #1402861: cloud-config-url ignored, install fails <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1402861>
<holocron> but after restarting my maas controller, the maas-dhcpd service will not come up
<holocron> so i'm trying to sort that out now
<thumper> what version of maas?
<holocron> 2.1.0 alpha2
<thumper> hmm
<thumper> that really is a question for the maas folks
<thumper> sorry
<thumper> can't be a help
<holocron> alright, thanks
<PCdude> I am installing openstack and during the install on a Ubuntu machine I get the following error log
<PCdude> http://pastebin.com/raw/A7qtJm4v
<PCdude> there is apparently an deployment timeout, but where can I see more information on why it did that or how can I solve it?
<marcoceppi> PCdude: that's a question for stokachu when he's around, I'm not sure why the cloud-installer is bailing like that.
<marcoceppi> PCdude: have you tried `conjure-up` instead?
<stokachu> PCdude, timeout usually means something isn't setup properly with MAAS
<stokachu> PCdude, are you able to deploy a node via maas web ui?
<pragsmike> morning folks
<jcastro> ok, 181 people have signed up for the summit as of today
<rick_h_> jcastro: sounds like a party
<jcastro> par-tay
<pragsmike> i'm looking forward to it
<pragsmike> right now I'm hoping someone can help me figure out why my LXC containers end up on the lxdbr0 bridge, rather than the one Juju creates for them
<pragsmike> I'm running MAAS 2.0, Juju 2 beta17
<marcoceppi> rick_h_: is there anyone who can help out with this ^^?
<rick_h_> pragsmike: sure thing, frobware can you help out pragsmike ^
<frobware> rick_h_: otp
<rick_h_> frobware: rgr, we'll be patient
<frobware> :)
<marcoceppi> rick_h_: I usually poke dimitern but I don't see him online ;)
<rick_h_> marcoceppi: yea, there's a public holiday on his end today
<marcoceppi> ah, cool, always good to get some time off
<pragsmike> juju status in http://pastebin.com/y0fsc6dc  The container's "dns-name" is on 10.0.0.x, which is lxdbr0's DHCP space, but the host machine is 192.168.57.x, where I think the container also ought to wind up
<rick_h_> pragsmike: in maas juju allows the containers to grab dns space so that they can have their own interfaces on the same address space so things like expose and the like work properly
<rick_h_> pragsmike: this prevents any routing issues between containers on different hosts
<rick_h_> pragsmike: actually, that's what you're saying...you expected the container to get a 192 address from the maas dhcp space vs a 10. from the lxd bridge?
<pragsmike> yes
<pragsmike> as an experiment I replaced the container interfaces with ones that bridged to the br-eno1 bridge on the host, and everything worked fine
<pragsmike> the apps could reach each other even if they were in containers on different hosts
<pragsmike> because they all got seen by MAAS, which DHCP'ed them and made them DNS-resolvable
<rick_h_> macgreagoir: can you please link your pr in the kanban card for your review item?
<rick_h_> frobware: voidspace +1 ^
<PCdude> stokachu: yes I am able to deploy a node from MAAS itself. I even checked ssh'ed in and checked that networking is fully functional. Everything is working like it should be.
<rick_h_> macgreagoir: voidspace natefinch ping for standup
<voidspace> rick_h_: crap, sorry - I thought we weren't having it today as everyone was out
<voidspace> rick_h_: forgot you were back :-)
<voidspace> rick_h_: I'm just off to fetch my girl from school, will ping you when I get back
<frobware> marcoceppi: ping; i scheduled a call to talk about hostnames for charms. would be better to punt this at corey?
<frobware> pragsmike: it's possible that you are running into bug #1566791
<mup> Bug #1566791: VLANs on an unconfigured parent device error with "cannot set link-layer device addresses of machine "0": invalid address <2.0> <4010> <cpec> <network> <juju:In Progress by dimitern> <https://launchpad.net/bugs/1566791>
<voidspace> rick_h_: back
<rick_h_> voidspace: howdy
<voidspace> rick_h_: the migration work is up for review and I'm back on my bug
<voidspace> rick_h_: hey, howdy
<voidspace> rick_h_: how was the trip?
<rick_h_> voidspace: k, can you ping menno for someone from migrations to do the review?
<rick_h_> voidspace: good stuff, naigara falls is impressive, and lots to do around there. The VA mountains are nice, and elevation = cooling which was welcome
<voidspace> rick_h_: will do
<rick_h_> voidspace: though 3k ft isn't exactly super high and such
<voidspace> rick_h_: I've seen the falls briefly (at night) but not the mountains
<voidspace> rick_h_: heh
<voidspace> rick_h_: about as high as we get in the UK...
<rick_h_> it's enough to privde a scenic backdrop while you sit at the winery and 'test' things out
<rick_h_> and for a few mile hikes for the family to go on and get some pictures
<voidspace> rick_h_: that's a funny US/UK difference - winery is a very American word. We only ever say vineyard.
<voidspace> rick_h_: I love walking out in nature, about my favourite thing to do.
<rick_h_> voidspace: oh heh yea that works as well I guess.
<voidspace> rick_h_: we had a great time in the Romanian mountains this summer
<rick_h_> voidspace: yea, had a nice mix of hiking some of the appalacian trail, kayak/canoe the james river, and drive through the skyline drive
<rick_h_> voidspace: very cool, dad enjoy it?
<voidspace> rick_h_: Dad? we went with my Dad to cornwall this year. Not many mountains there :-)
<voidspace> rick_h_: and it rained
<voidspace> rick_h_: which is why I don't go on holiday in the UK...
<rick_h_> oh, thought you took your dad to the mountains
<rick_h_> sorry, wrong holiday
<voidspace> no, unfortunately not
<voidspace> I'd love to, but he's a bit too frail now :-(
<voidspace> rick_h_: first day back at the coalface treating you ok?
<voidspace> rick_h_: everything slipped into chaos in your absence
<voidspace> rick_h_: fighting each other with sticks and rocks on IRC
<voidspace> proper lord of the flies stuff...
<rick_h_> voidspace: hah! so what you're saying is that everyone's much more engaged so I should go back into the mountains?
<voidspace> rick_h_: hehe, that wasn't quite what I meant...
 * rick_h_ has to try to twist it 
<voidspace> your descriptions are making me want to go back to mountains though :-/
<voidspace> ah well, next year
<rick_h_> no emails about calling the cops so can't be too bad
<voidspace> :-)
<marcoceppi> frobware: I'll be there shortly
<marcoceppi> frobware: call running late, but invite cory_fu as well :)
<frobware> marcoceppi: np
<pragsmike> guys I have to go onsite elsewhere for a few hours, I'll be off IRC meanwhile
<PCdude> stokachu: u there?
<bdx> mbruzek: sup
<narindergupta> #openstack-charms
<cholcombe> is it ok if a hook takes some long amount of time to complete?  like 10 mins or more?
<rick_h_> cholcombe: think so, no limit to the hook exec I know of tbh.
<cholcombe> rick_h_, ok cool
<rick_h_> cholcombe: the one thing I can think of is charm testing timing out because a hook took too long to complete
<cholcombe> rick_h_, yeah i'll have to hack something for the test
<hatch> is it normal that I ran remove-application and it also removed the subordinate?
<hatch> it was the only application related to that subordinate
<PCdude> I get the following error during "juju bootstrap": http://askubuntu.com/questions/717803/openstack-install-problem-with-juju-bootstrap/718820#718820
<rick_h_> hatch: sure, the subordinate can't live outside of the thing it's on
<hatch> rick_h_: understood, but removing it from the applications list? Does this mean that if it was related to other applications it would have stayed around?
<hatch> when a real application has 0 units does it also get removed from the list?
<hatch> I don't think so
<hatch> rick_h_: from the GUI when you remove an application it doesn't also remove the subordinate
<hatch> so the CLI and GUI have slightly different functionalities here
<rick_h_> hatch: :P ok we'll have to look into it and settle it out
<hatch> let the battle begin!
 * rick_h_ gets out his "rick is always right" stick bwuhahahaha!
<hatch> lol!
 * rick_h_ isn't sure which way to swing it though...for or against keeping it aroudn
<hatch> my preference is to keep it around - I understand why it does it, but because it keeps it around if it's related to another application
<hatch> it makes it a little inconsistent
<hatch> rick_h_: https://bugs.launchpad.net/juju/+bug/1620814 in case you want to weigh in
<mup> Bug #1620814: Removing application also removes related subordinate <juju:New> <https://launchpad.net/bugs/1620814>
<x58> Is there a channel to complain about Launchpad?
<x58> Specifically... git.launchpad.net is very unhappy when you have an ed25519 key that you offer it...
<pragsmike> is back
<magicaltrout>  /o\
<marcoceppi> x58: #launchpad ;)
<marcoceppi> pragsmike: o/ how's the maas + openstack going?
<pragsmike> still trying to understand how maas networks work
<pragsmike> i spotted some strangeness in the interfaces in the networks of the container I run the maas rack+regiond in
<pragsmike> i don't think it's the problem, but ...
#juju 2016-09-07
<lazyPower> https://code.launchpad.net/~lazypower/charm-helpers/add-workload-version/+merge/305062  -- if anyone has some spare cycles to look over a new feature for le charm-helpers for me
<pragsmike> After cleaning up my maas networks, I still have the same problem: containers end up on lxdbr0 with unreachable addresses
 * pragsmike hates computers
<pragsmike> UNIT       WORKLOAD     AGENT  MACHINE  PUBLIC-ADDRESS  PORTS   MESSAGE
<pragsmike> mariadb/0  unknown      idle   0/lxd/0  10.0.0.26
<pragsmike> vanilla/0  maintenance  idle   0        192.168.57.101  80/tcp  Starting Apache
<pragsmike> MACHINE  STATE    DNS             INS-ID               SERIES  AZ
<pragsmike> 0        started  192.168.57.101  tamdhn               trusty  default
<pragsmike> 0/lxd/0  started  10.0.0.26       juju-b78821-0-lxd-0  trusty
<pragsmike> vanilla will never be able to connect to mariadb
<magicaltrout> alrighty, NASA and the other company are having a big fat row... which leaves me a  nice gap to finish off my charms for next week \o/
<magicaltrout> alright 3 talks submitted to apachecon eu
<magicaltrout> better stop before they all get accepted like usual and I have a mountain of stuff to do
<rock> HI. Facing Issue while deploying juju-gui in internal openstack environment [ubuntu OpenStack Autopilot Setup]. Issue Pasted Info  http://paste.openstack.org/show/567387/. Please anyone provide me some solution for this issue.
<magicaltrout> well I have no idea how openstack works, but it looks like you need to define a pool of servers in a region called region1 :)
<rock> magicaltrout: OK. Thank you.
<rock> But I don't understand one thing. For adding a single juju charm to the existing ubuntu autopilot setup, we need to add servers to MAAS Server zone[cloud region] ?
<magicaltrout> rock: surely region1 is post openstack bootstrap
<magicaltrout> doesn't openstack have regions defined like AWS does?
<magicaltrout> can i test a charm locally that uses resources without pushing stuff to the charmstore?
<magicaltrout> ah juju attach it seems
<rick_h_> magicaltrout: yep
<magicaltrout> i assume we'll be seeing your well groomed facial hair in pasadena rick_h_ ?
<rick_h_> magicaltrout: hah probably
<rick_h_> i'll look for my pommade
<magicaltrout> lol
<magicaltrout> ooh my first working resource enabled charm
<magicaltrout> nice
<pragsmike> any insights would be appreciated, as to why my containers aren't reachable from any other machines:
<pragsmike> MACHINE  STATE    DNS             INS-ID               SERIES  AZ
<pragsmike> 0        started  192.168.57.101  tamdhn               trusty  default
<pragsmike> 0/lxd/0  started  10.0.0.26       juju-b78821-0-lxd-0  trusty
<pragsmike> isn't the container supposed to be on the same subnet as machine 0?
<magicaltrout> I like your style pragsmike you've exhausted the late in the day folks so now try the early risers? ;)
<pragsmike> well i'm pretty exhausted :/
<magicaltrout> well rick_h_ may be of use
<magicaltrout> pragsmike: I would also backup your irc questions by dumping them on the juju mailing list
<magicaltrout> its not as instant but you get a wider response base
<pragsmike> good point
<pragsmike> and it would keep me from spamming irc so much
<magicaltrout> doesn't hurt to spam every channel going ;)
<pragsmike> hey i've kept it off #maas
<magicaltrout> if i were in your shoes pragsmike i'd spam #juju the juju mailing list and askubuntu
<magicaltrout> until someone responds :)
<cargill> hi, is there an offline readable edition of the juju user/developer guides?
<rick_h_> pragsmike: the team's working on a few bugs around that atm. /me goes to look up bug #'s
<rick_h_> cargill: no, but it's it github so you can fork it and have a local copy. https://github.com/juju/docs
<cargill> rick_h_: brilliant, thanks
<magicaltrout> cory_fu: ping
<admcleod> pragsmike: is your lxd bridged to the host interface?
<admcleod> magicaltrout: its not quite 6am there yet
<pragsmike> no it isn't, that's the problem
<admcleod> pragsmike: tried this? https://insights.ubuntu.com/2016/04/07/lxd-networking-lxdbr0-explained/
<pragsmike> checking
<magicaltrout> admcleod: so?!
<rick_h_> frobware: didn't we have a bug for this yesterday? I'm not seeing which one it is ^
<admcleod> magicaltrout: just sayin
<rick_h_> frobware: where containers are getting internal private IPs vs ones on the host maas network via dhcp?
<pragsmike> that's a good description of the problem
<rick_h_> natefinch: morning, did you get a review of the bundle branch up? I'm not seeing it and would like to be able to ship that for the beta/before it gets out of sync with trunk again please
<pragsmike> I wonder if it's related to https://lists.ubuntu.com/archives/juju/2016-September/007801.html
<magicaltrout> you'll do though admcleod cause i just need some eyes to tell me what moronic thing I'm doing
<magicaltrout> https://github.com/buggtb/layer-drillbit/blob/master/metadata.yaml#L22 mysql relation
<magicaltrout> https://github.com/buggtb/layer-drillbit/blob/master/reactive/drillbit.py#L183 <- reactive code for the relation
<magicaltrout> why I juju deploy mysql and relate the charms
<magicaltrout> that method is never run
<admcleod> magicaltrout: well the mysql interface needs to set the available state
<pragsmike> magicaltrout thank you for pointing me at the mailing list, i think that message i linked is in fact my problem
<pragsmike> though i do have the interfaces assigned to subnets and it still doesn't work
<admcleod> magicaltrout: and you dont appear to be using the mysql interface
<magicaltrout> admcleod: yeah i get that but I look at the interface and that is set if there is a valid connection_string
<magicaltrout> https://github.com/johnsca/juju-relation-mysql/blob/master/requires.py#L43
<admcleod> magicaltrout: right...
<admcleod> magicaltrout: but mysql isnt in layer.yaml
<admcleod> magicaltrout: or does something else include it?
<magicaltrout> see
<magicaltrout> told you it was moronic
<magicaltrout> ta
<admcleod> cool, no worries
<frobware> rick_h_: didn't get to that - could be https://bugs.launchpad.net/juju/+bug/1566791
<mup> Bug #1566791: VLANs on an unconfigured parent device error with "cannot set link-layer device addresses of machine "0": invalid address <2.0> <4010> <cpec> <network> <juju:In Progress by dimitern> <https://launchpad.net/bugs/1566791>
<frobware> pragsmike: ^^
<frobware> pragsmike: could do with some quick context; this on MAAS?
<pragsmike> yes, juju2 beta17/maas2.1 latest alpha
<natefinch> rick_h_: I'm sorry, I totally flaked on that yesterday.  I'll look at it right now.
<frobware> pragsmike: on the machine hosting the container can you do: lxc config show <container-name>
<rick_h_> natefinch: ty
<pragsmike> config:
<pragsmike>   core.proxy_ignore_hosts: 127.0.0.1,192.168.57.100,::1
<pragsmike> doh
<frobware> pragsmike: that mail archive you posted to is the same bug I referenced
<rick_h_> pragsmike: ok, so we're working on getting that fixed up for the next beta hopefully.
<natefinch> rick_h_: do you have a link? I'm not sure where I'm supposed to be looking
<rick_h_> natefinch: look in the kanban card please
<pragsmike> http://pastebin.com/9LagVLyK
<rick_h_> natefinch: it's why I ask folks to make sure to link them up.
<pragsmike> cool, good to know
<natefinch> rick_h_: oh, right
<pragsmike> sorry i'm still new enough that i don't always recognize what i'm looking at
<rick_h_> frobware: call?
<rick_h_> pragsmike: all good, I'm not new and that mentioned vlans and such so I wasn't sure
<frobware> pragsmike: from the maas node, can you PB /etc/network/interfaces
<pragsmike> auto eth0
<pragsmike> iface eth0 inet dhcp
<pragsmike> besides the loopback, and that's in /etc/network/interfaces.d/50-cloud-init.cfg
<pragsmike> wait 'maas node' means maas controller, or the container host
<pragsmike> i'm guessing the latter is more interesting, standby
<pragsmike> http://pastebin.com/6pZuuXXS
<pragsmike> the container host's nic does get put on a br- bridge
<pragsmike> it's just that the containers still end up using the wrong bridge (lxdbr0)
<jacekn> hello. I am trying to get local provider up and running but it seems broken in juju 1.25: https://bugs.launchpad.net/juju-core/+bug/1618963 and also in 2.0: https://bugs.launchpad.net/juju/+bug/1618948 anybody knows workaround to get local provider up and running?
<mup> Bug #1618948: Can't bootstrap localhost cloud <juju:New> <https://launchpad.net/bugs/1618948>
<magicaltrout> jacekn: isn't your 2.0 install ancient?
<magicaltrout> ooh
<magicaltrout> tools is ancient
<jacekn> magicaltrout: it's the latest one in xenial: 2.0-beta15-xenial-amd64
<jacekn> yeah
<magicaltrout> can you sync-tools or something?
<magicaltrout> they've changed the term
<jacekn> nope that does not work http://pastebin.ubuntu.com/23145770/
<magicaltrout> i just tried the same jacekn on 2.0 and it bootstraps for me
<magicaltrout> yeah this is the thing I don't get
<magicaltrout> in the latest beta they removed --upload-tools
<magicaltrout> but then if you need to upload them to boot, how do you do it?
<magicaltrout> or maybe thats not required I never quite understood
<magicaltrout> anyway i'm on beta16
<magicaltrout> and it booted
<jacekn> magicaltrout: where did you get beta16 from? Xenial has beta15
<dimitern> pragsmike: if you grep for `failed to prepare container ".*" network config` in /var/log/juju/machine-0.log on the controller and find it, that will be the reason why you're seeing lxds coming up with a single NIC bridged to lxdbr0
<magicaltrout> ppa-dev or something
<dimitern> pragsmike: this is because we couldn't finish allocation for a multi-NIC config for the lxd and resorted to using a "fallback" config (eth0->lxdbr0, dhcp); that's also what we're fixing currently
<pragsmike> thanks dimitern!
<pragsmike> network config: {"hostname": ["Node with this Hostname already exists."]}
<pragsmike> actually two of them
<pragsmike> 2016-09-07 03:10:58 WARNING juju.provisioner lxd-broker.go:62 failed to prepare container "0/lxd/0" network config: connection is shut down
<pragsmike> 2016-09-07 03:12:22 WARNING juju.provisioner lxd-broker.go:62 failed to prepare container "0/lxd/0" network config: {"hostname": ["Node with this Hostname already exists."]}
<pragsmike> but the "connection is shut down" gets spammed in bursts throughout the log, mostly reporting about manifold workers
<pragsmike> gotta be afk for a few hours, thanks much for the help guys!
<pragsmike> i'll just manually bugger the container bridge for now, i just didn't want to have to do that every time i deploy
<dimitern> pragsmike: what are the versions of juju and maas?
<rick_h_> voidspace: call?
<pragsmike> juju 2.0-beta17-xenial-amd64
<voidspace> rick_h_: sorry, omw
<pragsmike> maas "version": "2.1.0", "subversion": "alpha2+bzr5321"
<dimitern> pragsmike: have you tried stable maas versions?
<dimitern> pragsmike: 2.1 is quite new and I personally haven't even tried it - might still have issues
<dimitern> pragsmike: but that 'node with this hostname already exists' is troubling - shouldn't happen unless it's a maas 2.1 api regression
<rock> Hi. I have a question. We have developed a JUJU Charm for configuring cinder to use one of our Storage array as the backend.   So How to redeploy the Charm to add more storage arrays to configure cinder without destroying/removing the current deployed charm. [For example, We don't want to remove the current configured storage arrays from the Cinder configuration.]
<frobware> dimitern: ping
<frobware> dimitern: based on pragsmike's PB (http://pastebin.com/6pZuuXXS) I'm not expecting this to be the unconfigured parent device issue
<rock> can we do this only using juju set-config and juju upgrade-charm ? Is there any other way to do?
<SimonKLB> what's the go-to smtp server charm (if anyone exist) ?
<rick_h_> rock: so if you change the code in the charm itself you'd upgrade-charm. If you want to change configuration it'd be up to how the charm handles that config
<rick_h_> rock: it could be accepting config as a resource, a config field entry, or something else
<magicaltrout> i don't believe there is one SimonKLB
<magicaltrout> but there should be!
<SimonKLB> magicaltrout: ah too bad, it would be great yea
<SimonKLB> magicaltrout: actually, just found https://jujucharms.com/postfix/ but it looks a bit outdated... :)
<magicaltrout> yeah it would be worth dragging that back out of retirement
<magicaltrout> I've had an ldap server on my backlog as well
<PCdude> magicaltrout heey :)
<magicaltrout> uh oh
<rock> rich_h_: Hi. I have a question. for example, we have two same kind of storage arrays. But those two arrays have unique parameter values like [san IP, san pass, san username....]. So Once our charm modified the cinder.config with the same storage backend, then cinder has to contact both storage arrays based on given credential values. How can I do this?
<rock> rick_h_: are you there?
<rick_h_> rock: I am, sorry in and out with meetings/etc so I might fade back/forth
<rick_h_> rock: so this is in reference to the current cinder charm you're specifying the different arrays?
<rock> rick_h_: assume that we deployed our charm with some configuration values. and added relation to cinder. Then again we want to redeploy the charm to append with the new configuration values. We don't want to destroy the existing changes.
<rock> rick_h_ : Yes. In reference to the current cinder charm we are specifying different arrays. We want to redeploy the charm again and again but Only new configuration values have to be appended.
<rick_h_> rock: so you don't typically redeploy a new charm again and again without running them with different config/etc. If you weant to update the config it's up to using the charm mechanisms to update that without a charm redeploy.
<rick_h_> rock: I guess I'll defer to folks that know cinder better. I'm not following the use case here very well.
<rock> rich_h_: OK. Thank you very much.
<magicaltrout> ah ha
<magicaltrout> got it
<magicaltrout> this is quite cool admcleod https://ibin.co/2uGe9AHrvXI9.png apache drill over mysql from the relation
<magicaltrout> so you could now hook up a combination or mongo, flat files, hdfs, mysql from juju into drill
<magicaltrout> and then plug drill into your favourite SQL client
<magicaltrout> and do cross datasource analysis
<magicaltrout> something like select * from mysql.jujudb, hdfs.jujucluster where x=y
<admcleod> magicaltrout: nice
<hatch> rock: as promised there is a new GUI release which resolves the issue you were seeing with subordinates. You can get it by downlading the bz2 here https://github.com/juju/juju-gui/releases/tag/2.1.11 and then running `juju upgrade-gui /path/to/bz2`
<PCdude> stokachu: http://askubuntu.com/questions/821804/openstack-with-landscape-install-fails
<PCdude> stokachu: JUJU can bootstrap and it succeeds to install ubuntu on all nodes after the bootstrap
<PCdude> stokachu: nodes are getting an IP and can go to the internet (DNS resolves works too)
<PCdude> what is going wrong? :) I am stuck...
<PCdude> I got ur name on recommendation of "kiko"
<cloudguru> Wondering if the charm ingestion service is known to be working / operations or if my charms pushed to personal namespace in launchpad have issues
<cloudguru> Charm proof results for : https://code.launchpad.net/~brianlbaird/charms/trusty/qslice/trunk
<cloudguru> I: metadata name (qslice) must match directory name (trunk) exactly for local deployment.
<cloudguru> I: all charms should provide at least one thing
<cloudguru> I: missing recommended hook install
<cloudguru> I: missing recommended hook start
<cloudguru> I: missing recommended hook stop
<cloudguru> I: missing recommended hook config-changed
<cloudguru> I'm using layer-docker so the hooks aren't needed as I understand as /reactive does heavy lifting
<lazyPower> cloudguru - the i's ar esafe to ignore. it also looks like you ran charm proof against a layer, not against the assembled charm.
<cloudguru> k
<cloudguru> I'll move up the directory path and push again
<lazyPower> cloudguru - well, hang on
 * lazyPower is looking
<cloudguru> standing by
<lazyPower> ok i see what happened here
<lazyPower> the charm is building in $PWD
<lazyPower> if you look in your layer, you'll see trusty/qslice/--all-the-charms-files-here--/
<cloudguru> agreed
<lazyPower> so really what you want ot do is charm push just the assembled charm to your namespace in the charm store, and you'll want to bzr push just the layer, so you're only VCS controlling the layer.
<cloudguru> that's the result of charm build
<lazyPower> one thing i do, is i export JUJU_REPOSITORY in my $HOME/.bashrc, so that charm build will by default place them in that path, instead of in $PWD
<marcoceppi> cloudguru: also, ingestion does not work anymore, you'll need to explicitly push it to the charm store
<cloudguru> good idea to keep them separated .  Saw the export is your super awesome tutorial
<lazyPower> cloudguru - also, wrt publishing - https://jujucharms.com/docs/stable/authors-charm-store   -- make sure you're familiar with the charm release model. (or charm publish, depending on which version of the charm command you have installed)
<cloudguru> ah man .. humans required ;-)
<marcoceppi> cloudguru: https://jujucharms.com/docs/stable/authors-charm-store
<cloudguru> thx guys.  trying this again and will check back here as needed.
<lazyPower> np, ping if you hit blockers cloudguru  :)
<jose> marcoceppi jcastro niemeyer is it possible to have +t here? there's a topic troll in Ubuntu channels
<marcoceppi> jose: what do you mean?
<jose> channel mode +t
<jose> there's a guy changing channel topics to... undesirable things
<marcoceppi> jose: sure
<jose> thanks :)
 * marcoceppi shrugs
<PCdude> marcoceppi: uhm, n00b question what does +t mean?
<jose> marcoceppi: it's modelocked with chanserv
<cloudguru> @lazypower: updated charms pushed for v1.25 on 14.04 trusty
<PCdude> lazyPower: http://askubuntu.com/questions/821804/openstack-with-landscape-install-fails
<PCdude> any idea? :)
<lutostag> any way to tell where we are in the agent-initialization process?
<lutostag> (seems to me my local lxd setup is stuck in that step deploying a charm)
<rick_h_> lutostag: check juju status --format yaml
<rick_h_> and see if theres an error on the machine there
<lutostag> rick_h_: no error, just pending
<lutostag> it seems like cloud-init/apt-get dist-upgrade may still be running but not doing anything actively
<lutostag> oh well at least the juju add-user and register is freaking awesome
<bdx> lutostag: totally, right
<bdx> marcoceppi: I was a bit tired last night when I filed that bug on interface-http .... I'm thinking it should be a feature request/bug with haproxy instead .... I'll close that bug now
<balloons> anastasiamac_, good morning
<lutostag> if anyone else runs into the same as me above... culprit is https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621229
<mup> Bug #1621229: snap upgrade to 2.14.2~16.04 in xenial lxc hangs <snapd (Ubuntu):New> <https://launchpad.net/bugs/1621229>
<lutostag> (but should only be until we get a new daily... or a fix... *shrug*)
 * pragsmike returns
<marcoceppi> balloons: I think it's actually a valid bug though
<anastasiamac_> balloons: \o/ 6.45am - how can i help? m in the process of sending brood to school
<magicaltrout> lazyPower: you're a man of immense debugging skills.....
<magicaltrout> 'PostgreSQLClient' object has no attribute 'host'
<magicaltrout> help me out here
<magicaltrout> https://git.launchpad.net/interface-pgsql/tree/requires.py
<magicaltrout> the stuff at the top even tells me it has hosts
<magicaltrout> https://github.com/buggtb/layer-drillbit/blob/master/reactive/drillbit.py#L206 yet that fails
<balloons> marcoceppi, what's a valid bug?
<marcoceppi> balloons: sorry, meant to ping bdx
<marcoceppi> bdx: I think it's actually a valid bug though
<balloons> anastasiamac_, just wanted to mention we need to triage ubuntu source juju bugs as well
<balloons> anastasiamac_, https://bugs.launchpad.net/ubuntu/+source/juju-core/+bugs?orderby=-datecreated&start=0
<bdx> marcoceppi: with interface-http, or haproxy?
<marcoceppi> bdx: interface-http
<bdx> marcoceppi, magicaltrout: so ..... iterating quite a few deploys over a few different charms this last week, all of which are making use of the pgsql interface ... I hit the same thing as magicaltrout probably 4 or 5 times
<magicaltrout> awww
<marcoceppi> interesting
<magicaltrout> i'm even robbing code from cmars
<marcoceppi> stub: ^?
<magicaltrout> and it doesn't work
<bdx> I would rip it all down, redeploy the same unchanged charms, and it would not hit the error
<bdx> magicaltrout: does yours error consistently?
<magicaltrout> i believe so
<magicaltrout> but i keep hacking stuff around when its broken, so maybe, maybe not :)
<marcoceppi> what's interesting is host isn't an autoaccessor
<magicaltrout> part of my hatrid of scripting languages... where's the stuff tell you its wrong before you hit the go button ;)
<marcoceppi> magicaltrout: can you try something like this instead
<marcoceppi> @when('pgsql.master.available')
<marcoceppi> and then
<marcoceppi> psql.master.host ?
<magicaltrout> yeah 2 secs
<marcoceppi> maybe actually psql.master().host
<anastasiamac_> balloons: awesome \o/ first time i hear about it :) where do these come from and can I re-target these to juju? oh.. i guess, it must b juju-core coz juju does not exist?...
<bdx> https://gist.github.com/jamesbeedy/2c179a7d0a71209f8ccd0183478db9d5
<balloons> anastasiamac_, launchpad.net/juju bugs are project bugs. those bugs are bugs found and filed by end users against the source package of juju for ubuntu. They might be issues with the packaging, or issues specific to the distro version.
<bdx> marcoceppi, magicaltrout: ^ is what I've been using .... seems to work 99% of the time .... that is the code I was randomly hitting that error on
<balloons> anastasiamac_, so typically those type of bugs might end up being pushed upstream and linked to an upstream bug, while tracking the ubuntu work. I would say feel free to add juju as affected to any of them you know juju-core needs to fix
<magicaltrout> this time around i get: Can't convert 'PostgreSQLClient' object to str implicitly
<anastasiamac_> balloons: sounds good ;)
<magicaltrout> for  log("marco and his amazing tweak:"+psql+master().host)
<balloons> anastasiamac_, and perhaps to make life simple, you could remove the link to the ubuntu source package then. There's not many bugs in there, so what's there can just be packaging or non-juju-core issues
<magicaltrout> okay so  lets try bdx's version
<magicaltrout> same output
<magicaltrout> oh
<magicaltrout> i might have ballsed that one up
<magicaltrout> . not +
<marcoceppi> I think the key is to use the psql.master object
<magicaltrout> yeah much improved
<marcoceppi> which is a ConnectionString class that has host
<magicaltrout> thanks chaps
<marcoceppi> cheers bruv
 * magicaltrout plonks marcoceppi in the east end of london
<PCdude> please can somebody help me with this problem, I tried everything I can think of :)
<PCdude> http://askubuntu.com/questions/821804/openstack-with-landscape-install-fails
<jcastro> dpb1: got someone handy who can help PCdude? ^^^
<PCdude> jcastro: great! :)
<magicaltrout> submitted a couple of semi juju related talks to apachecon eu today jcastro
<jcastro> excellente!
<thumper> o/ jcastro
<bdx> wierd issue #1000000 - http://paste.ubuntu.com/23147588/
<mup> Bug #1000000: For every bug on Launchpad, 67 iPads are sold. <Edubuntu:Triaged> <https://launchpad.net/bugs/1000000>
<bdx> weird*
<bdx> xenial containers never get a juju-agent :-(
<bdx> they just hang on Waiting for agent initialization to finish
<lutostag> magicaltrout: https://paste.ubuntu.com/23147602/
<bdx> trusty containers get the juju agent and start just fine
 * lutostag what happens when you don't scroll to the end of the conversation
<bdx> I can't get any xenial lxd containers to start on beta16, beta17, or tip
<lutostag> bdx: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621229
<mup> Bug #1621229: snap upgrade to 2.14.2~16.04 in xenial lxc hangs <snapd (Ubuntu):New> <https://launchpad.net/bugs/1621229>
<bdx> must not be a juju thing ... all of my logs are clean ... the last command successfully ran in my cloud-init.log is 'dist-upgrade' ...
<lutostag> not a juju thing
<bdx> lutostag: thanks ... you saved me from re-deploying failures for the next hour, staring at my screen feeling like I'm missing some rogue config :-)
<bdx> lutostag: http://paste.ubuntu.com/23147632/ - fixes
<lutostag> fun :), didn't know those
<magicaltrout> bdx: what day you getting into pasadena sunday night?
<magicaltrout> aww wtf i rejects the connection
<magicaltrout> s/i/it
<bdx> magicaltrout: ya mon! yourself?
<magicaltrout> saturday
<magicaltrout> got to de-jetlag
<magicaltrout> marcoceppi: i'm assuming I should be able to talk to postgres without changing the security in the postgres charm?
<bdx> magicaltrout: postgres only adds entries to pg_hba.conf for the ip(s) of your related units
<bdx> if you want to connect from another source you have to feed it the extra-pg-auth config
<magicaltrout> yeah i can see the entry in the config
<magicaltrout> which is weird
<bdx> what part?
<magicaltrout> so its adding my relation, even if i install postgres-client on the other end
<magicaltrout> that gets a rejected connection as well
<bdx> due to what?
<magicaltrout> FATAL:  pg_hba.conf rejects connection for host "172.31.4.210", user "juju_drillbit3", database "juju_drillbit3", SSL off
<bdx> what is in your pg_hba.conf
<bdx> oooh, I think I hit this the other day too ... are you requesting multiple dbs?
<magicaltrout> not that i'm aware of :)
<magicaltrout> http://pastebin.com/5rBMB1Nx
<magicaltrout> thats the pg_hba
<bdx> if you are, postgres charm will generate a new password for the juju_<service-name> user for each extra db you request
<bdx> leaving all_databases_requested[:-1] to have the wrong password
<magicaltrout> aah i see
<magicaltrout> specify a database and it works
<bdx> lol
<magicaltrout> doesn't work in jdbc world though
<magicaltrout> arse
<magicaltrout> oh postgres
<magicaltrout> some days you make me so sad
<magicaltrout> aaah lol
 * magicaltrout figured part of it out
<bdx> what was it
<bdx> I'm about to start using jdbc too
<magicaltrout> mostly a user caused weird zookeeper issue :)
<magicaltrout> but there may be an SSL issue as well, give me 5 mins and I'll let you know
<magicaltrout> ooh
<magicaltrout> i've just been asked to  demo some juju stuff for NASA and Darpa when I'm at JPL in a couple of weeks
<lazyPower> magicaltrout nice!
<magicaltrout> and other container orchestration tools."
<magicaltrout> paste fail
<magicaltrout> "I also here from Paul that you are 'juju charm' purveyor.  I've never used this but it certainly looks interesting.  I'd like to hear how juju compares to Docker compose and other container orchestration tools."
<magicaltrout> thats the brief ;)
<magicaltrout> it is... brief
<lazyPower> indeed
<lazyPower> and we're so not a "container orchestrator"
<magicaltrout> lol yeah
<lazyPower> its a byproduct of how awesome we are though
<lazyPower> so i can see why thats such a popular misconception
<magicaltrout> yup
#juju 2016-09-08
<marcoceppi> bdx: hey, you found a cloud init bug, do you have the link?
<lutostag> marcoceppi: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621229
<mup> Bug #1621229: snap upgrade to 2.14.2~16.04 in xenial lxc hangs <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1621229>
<marcoceppi> lutostag: this is actually a huge problem, do you know if it has an eta?
<lutostag> marcoceppi: no, its caused by the sru for snap, should be fixed with next daily though
<marcoceppi> lutostag: so, will the daily be what people normally get?
<marcoceppi> every juju deploy in a lxd container of xenial is broken right now, and we're 4 days away from a charmer summit
<lutostag> thats what I get with default juju commands -- and how I ran into it
<lutostag> bdx
<lutostag> 's workaround FTM: http://paste.ubuntu.com/23147632/
<marcoceppi> lutostag bdx that will only hold true until xenial refreshes it's image cache
<lutostag> but yes, workarounds for something supposed to be super stable is not a nice place to be so close to so many demos
<lutostag> lxd's or some other cache?
<marcoceppi> lxd's, every ~2 weeks or whatever, when our cloud team releases new images, LXD's image cache gets updated on all those who have network access and enabled it (enabled by default if you did `lxc launch ubuntu:16.04`
<lutostag> marcoceppi: ah, I usually pull from https://images.linuxcontainers.org not https://cloud-images.ubuntu.com/releases, so yeah more of an impact than I thought
<marcoceppi> Sept 1 was the last image update I got for Xenial
<lutostag> so yes, iiuc it will hit us as long as we have snap as an updating package w/ cloud-init (until update for xenial -- and I'm pulling from release NOT daily) which makes it a long-lasting one
<lutostag> Aug 30, 2016 at 12:00am was when it was updated simplestreams server-side
<lutostag> I believe smoser had a workaround in-mind cloud-init side before he EOD'd
<lutostag> looks like it got escalated correctly to mgmt -- but jgrimm is who you throw hell-fire at I believe to ensure timely fix
<marcoceppi> no need for hell fire, a bug like this with no "severity" concerns me
<lutostag> its parent has critical as of ~15mins ago
<marcoceppi> lutostag: yeah, I mean that was a recent change :)
<jcastro> o/ thumper-lunch
<jcastro> hey, this might seem like a dumb question, but why would the color in `juju status` not work when doing `watch juju status`?
<jrwren> jcastro: because the process detects if stdout has redirected or not and doesn't output color if it has. same as `watch ls -l`
<jrwren> jcastro: use watch -c and... hopefully juju status has a force color option?
<jrwren> jcastro: yeah, watch -c juju status --color=true should work
<jcastro> yep, got it, thanks
<jrwren> jcastro: once a decade i actually help you. ;]
<jrwren> jcastro: and it is always rather trivial.
<jcastro> yeah it's just that colors really help when doing workshops, so like, we should totally use that in Pasadena
<jcastro> jrwren: are you going to pasadena?
<marcoceppi> watch?
<marcoceppi> you all need to do this :)
<marcoceppi> http://paste.ubuntu.com/23148247/
<marcoceppi> jcastro: ^ ;)
<jrwren> jcastro: yes, I am going.
<thumper> jcastro: hey
<thumper> jcastro: do this `watch -c juju status --color`
<thumper> actually I see that jrwren has already sorted you out
<stub> magicaltrout, bdx :  http://interface-pgsql.readthedocs.io/en/stable/requires.html has some examples. I needed to break backwards compatibility with the example pgsql interface when I took it over, as it didn't support a lot of my real world deploys.
<rock> hatch: Thank you very much. We will try this.
<PCdude> I am stuck with the following problem
<PCdude> http://askubuntu.com/questions/821804/openstack-with-landscape-install-fails
<PCdude> stokachu: could u take a look at my question above? :)
<magicaltrout> boom
<magicaltrout> working apache drill with mysql and postgresql
<magicaltrout> excellent
<magicaltrout> https://ibin.co/2uMOTf29nfWf.png
<magicaltrout> https://ibin.co/2uMOYLOeKkkP.png
<magicaltrout> https://ibin.co/2uMOc5gdxZzh.png
<magicaltrout> this is pretty cool
<magicaltrout> juju charms hook up to drill
<magicaltrout> then  let me  run a query across  multiple charm  based data sources without hacking around
<babbageclunk> magicaltrout: that's awesome
<magicaltrout> thanks babbageclunk
<magicaltrout> part of my requirements to finally get some decent analytics tools other than Zeppelin running over the top the various data sources juju provides
<magicaltrout> but also allow reasonably easy data federation across a bunch of different sources for easier ETL etc
<marcoceppi> magicaltrout: sweee6
<magicaltrout> aye marcoceppi coming along
<magicaltrout> I've now gotta fix up my saiku charm and create a drill interface so they can talk and we'll be good
<magicaltrout> http://spicule.co.uk/2016/09/08/juju-drill-amazingness.html
<rock> Hi. We have developed a "cinder-storagedriver" charm with one of our storage array. Our charm will be similar to "cinder-ceph". Already our charm is in public charm store.  We want to integrate our charm to "OpenStack Base bundle" and then we want to push the bundle to Charm store.   So How can I integrate my charm to OpenStack Base bundle?
<rock> To push the bundle to charm store,  Can I follow the same procedure as we followed for pushing our charm to  store?.
<rock> And Once we have the Bundle in the public Charm store , before deploying the  bundle can we set configuration parameters externally using "juju deploy bundle-name set-config  key=value,......" command?    Because while integrating our charm with "OpenStack base bundle" we will provide default configuration values[Like San IP, San Password ,San user,....]  to our charm.
<rock> Please anyone provide me some solution for this.
<magicaltrout> rock: you'll need to deploy the openstack base bundle, add your stuff, and push that bundle back to the charm store as your own bundle
<magicaltrout> in the mean time, if you actually want your cham included in the open stack base bundle, you'll need to get some tests written for it and it into the review queue, reviewed by a charmer and promulgated I suspect
<SimonKLB> i hit this bug just now, not sure how to get around it though, tips? https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336
<mup> Bug #1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1621336>
<rock> magicaltrout: Hi. How can I integrate my charm in OpenStack base bundle?.
<magicaltrout> I just told you
<rock> magicaltrout: didn't get fully. I have one option. Tell me that is correct (or) not. I will download Openstack bundle and add our charm details in bundle.yaml file. Then I will push this bundle to store as our own bundle. And then I will try to deploy that bundle by taking from store.
<magicaltrout> correct
<rock> magicaltrout: Then i have a question. Once we have the Bundle in the public Charm store , before deploying the  bundle can we set configuration parameters externally using "juju deploy bundle-name set-config  key=value,......" command?    Because while integrating our charm with "OpenStack base bundle" we will provide default configuration values[Like San IP, San Password ,San user,....]  to our charm.
<magicaltrout> dunno
<magicaltrout> you can certainly do that in the GUI, I assume you can do it on the command line
<magicaltrout> never tried it though
<rick_h_> rock: no, there's not currently a way to override config in the cli
<magicaltrout> okay
<magicaltrout> i lied
<rick_h_> rock: magicaltrout it doens't have the idea of "uncomitted" that the GUI has at this time. It's something we're interested in looking into, but the cli is more direct and immediate without a "deploy" go button like the GUI
<magicaltrout> yeah i did wonder about the staging aspectr
<magicaltrout> -r
<rock> rick_h_:  we did this for changing the default config for our charm.1) $sudo juju deploy cs:~siva9296/kaminario-openstack-5 san1 2)$sudo juju set-config san1 san-ip=192.168.0.1 san-user=admin1 san-password=password1 storage-protocol=iscsi os-version=liberty 3)$sudo juju add-relation san1 cinder
<rock> rick_h_: It worked for our charm.
<rick_h_> rock: why do you need to use sudo?
<rick_h_> rock: agree that you can set the config after the fact ok
<rock> rick_h_: Actually we no need. While doing juju bundle setup we run all commands with sudo.
<magicaltrout> what rick_h_ you don't grant root perms to all your workforce? ;)
<rock> rick_h_: While integrating our charm to openstck base bundle , we will give default config values to my charm. When user want to deploy our bundle then he will set actual config parameters using set-config . This what we want to do.
<magicaltrout> so you can do that in the GUI rock, as explained, you can't do it on the commandline at bundle level
<magicaltrout> you'd have to deploy the bundle then set the config for the charm you need to configure after the bundle starts spinning up
<marcoceppi> rock: one thing you might want to do, is have the charm ship with empty values. Then in the charm code say "If I have no configuration for SAN, block the charm and warn the user I need that information before proceeding"
<marcoceppi> rock: that way the user will get the message after deployment, and the deploy won't break because of bad configuration
<magicaltrout> for the firs time in a while I'm actually excited about some Saiku stuff we're finishing off. The Juju connectivity and schema generation will make Analysis over various data sources so much more effective, and take next to no time to setup thanks to Juju
<marcoceppi> magicaltrout: sounds like you just signed up for a lightning talk ;)
<magicaltrout> funny that, there appears to be a BI related one with my name next to it...
<marcoceppi> oic
<magicaltrout> these are the missing bits for the lightning talk but also a driver to get me to finally get the next release over the line because it will make demo's and building these data platforms much easier
<magicaltrout> so I figured having an enforced deadline helps focus the mind ;)
<magicaltrout> but also from a juju point of view, having a user friendly tool to run over HDFS, MySQL, whatever is nice as well
<magicaltrout> I can't expect users to use Zeppelin, as nice as it is they don't know how to write queries
<rock> marcoceppi: Ok. thank you. Finally, I got the point like- If I integrate our charm to bundle and push that bundle to store as our own bundle, Then while deploying bundle using "juju deploy bundle-name" we can't set configration values right. Once after having the bundle deployment only we can set config parameter values right.
<marcoceppi> rock: exactly, after you type `juju deploy bundle-name` anyone can set configuration either via the GUi or CLI
<rock> marcoceppi: Thank you. I have one more question.
<rock> marcoceppi: This question related to basic charm creation. pasted issue info. http://paste.openstack.org/show/569211/
<rock> marcoceppi: For juju version 2.0-beta15-xenial-amd64, If I run the command "$charm create test"  Then it was creating basic charm template with "hooks folder". and "$juju charm create test' this command is unrecognized. followed  https://jujucharms.com/docs/2.0/authors-charm-writing
<rock> marcoceppi: sorry. $charm create test"  Then it was not creating basic charm template with "hooks folder".
<marcoceppi> rock: charm command and juju command are two separate tools
<marcoceppi> rock: odds are, in trusty, you're installing a very old version of the tool. Charm creation has changed a lot since 2014. One change is that `juju charm` is no longer a command, and it's just the `charm` command. The second change is a move to layered charms. This is where you write less code and use `charm build` to compile a charm (create the hooks directory, etc)
<marcoceppi> rock: this is the updated documentation for this: https://jujucharms.com/docs/stable/developer-getting-started
<marcoceppi> rock: you can install the latest charm command on trusty using this: https://jujucharms.com/docs/stable/tools-charm-tools
<rock> marcoceppi: OK. Thank you.
<marcoceppi> rock: very excited to see your charm coming together! Let us know if you have any other questions
<rock> marcoceppi: Thank you very much for your support. Right now I have cleared my questions. We will move forward now. If we stuck at any place. We will ask you. Thank you.
<Anita_> Anita
<Anita_> Hi Matt
<kwmonroe> aisrael: lazyPower:  here's cory_fu's jdo snippet: http://paste.ubuntu.com/23150665/
<aisrael> Very nice, thanks!
<lazyPower> gracias!
<cory_fu> kjackal: https://github.com/juju-solutions/interface-spark
<marcoceppi> kwmonroe cory_fu why not something like this? http://paste.ubuntu.com/23150892/
<marcoceppi> seamless integration ;)
<kwmonroe> nice marcoceppi
<marcoceppi> and a pager for juju status
<lazyPower> sweet snippet
<cory_fu> marcoceppi: I like the status helper.  Gonna have to add that.
<cory_fu> marcoceppi: What version of juju supports colored status?  I get a "flag not defined" error from beta16
<PCdude> http://askubuntu.com/questions/821804/openstack-with-landscape-install-fails
<PCdude> does someone has an idea?
<rick_h_> cory_fu: think it's 17
<lazyPower> PCdude - that seems odd, but i'll relay this AU question to the landscape dudes.
<lazyPower> s/dudes/team/
<jcastro> I tried to ping them yesterday
<jcastro> dpb1: any of you folks around? ^^^
<lazyPower> jcastro - looks more like a conjure issue when i look deeper at the Au question, i've pinged stokachu re ^
<jcastro> ack
<cory_fu> lazyPower, aisrael: This the thing?  https://www.amazon.com/Reusable-Rubber-eLander-Assorted-Colors/dp/B01ID1XXE2/ref=sr_1_9?s=electronics&ie=UTF8&qid=1473355654&sr=1-9&keywords=twists
<lazyPower> yep, same company/ties
<lazyPower> mine are the shorter ones, came in an 8 pack
<PCdude> lazyPower: I was disconnected for a moment, so I dont know if u wrote a reply :)
<lazyPower> PCdude  not as of yet, the primary author of that utility is afk. but we've pinged for some help for you
<PCdude> lazyPower: great! I will wait in this channel for the next couple of hours
<PCdude> lazyPower: not always behind PC, but online
<lazyPower> PCdude - that works, but i would monitor the AU question, as thats what we sent over.
<PCdude> lazyPower: ah ok, that a good idea. I will keep an eye on that one too
<stokachu> PCdude, ive posted a response, if you need more assistance beyond what the community can provide via askubuntu I urge you to look into Ubuntu Advantage
<PCdude> stokachu: thanks for ur reply. I tried that already with success. So the bootstrap and the the deployment succeed. I dont know if u have followed the discussion in the maas channel, but the problem is getting more clear
<stokachu> PCdude, no i haven't
<PCdude> what turns out that the problem is related to spinning up machines with LXC by JUJU. Apparently there goes something wrong
<PCdude> stokachu: I will give a short overview
<PCdude> http://pastebin.com/raw/Lh1uTDQt
<PCdude> that is the output of "sudo lxc-ls --fancy"
<stokachu> ok that doesn't really tell me anything
<PCdude> stokachu: http://pastebin.com/raw/AZY2ZHiV
<PCdude> there is output of "JUJU_HOME=~/.cloud-install/juju juju status"
<PCdude> JUJU can for some reason not spin up machines at it should be
<PCdude> on advice of other the creator of the "openstack-installer" for ubuntu, I should head over to the JUJU channel for more help
<rick_h_> PCdude: there's a known issue with bringing up instances today. There's a bug in a package update that causes instances to not get through apt-get update/upgrade properly when brought up.
<rick_h_> PCdude: that's being corrected, in the mean time you have to set the auto upgrade to false on juju models for now. Looks like you're on juju 1.25
<PCdude> rick_h_: yes indeed, I am using JUJU 1.25. Where can I set that option? which file? this would be great if it works :)
<rick_h_> PCdude: looking, I did it for 2.0 today so trying to remember how to set it in 1.25
<jrwren> PCdude: add enable-os-refresh-update: false and enable-os-upgrade: false to environments.yaml manually
<rick_h_> PCdude: check out https://lists.ubuntu.com/archives/juju/2016-September/007845.html for hte background and then add those keys to your juju config in environments.yaml
<rick_h_> what jrwren said
<jrwren> what rick_h_ said
<rick_h_> PCdude: and if that works to help those lxc containers come up the problem should be working itself out here shortly
<PCdude> rick_h_: just to be sure, I am not using xenial, but I am using trusty. That makes this solution still valid? just trying to be sure
<rick_h_> PCdude: oh, hmmm...good point, that's probably not true then.
<rick_h_> PCdude: have to check the lxc logs then and see what's up on them
<PCdude> rick_h_: I never used LXC so which log u wanna see (command would be handy too haha)
<rick_h_> PCdude: can you ssh/connect to the lxc containers and get /var/log/juju/* logs from there?
<PCdude> rick_h_: http://askubuntu.com/questions/821804/openstack-with-landscape-install-fails
<PCdude> that is mine question in total
<PCdude> the second block is the output of what u are asking on the node that runs the LXC containers
<PCdude> is that what u are looking for?
<PCdude> *my
<stokachu> ugh wait
<stokachu> are you running out of dhcp addresses?
<stokachu> what is your dhcp and static ranges defined in maas
<stokachu> PCdude, ^
<PCdude> stokachu: http://i.imgur.com/rg0JcaO.jpg
<PCdude> 50 for dynamic and 50 for static
<PCdude> I seriously hope that is enough :)
<stokachu> PCdude, well if you've run the installation several times in a short period
<PCdude> stokachu: good point, I have everything running in ESXI and heavily use the snapshot function. So, every install seems to be the first for the system
<stokachu> PCdude, no idea didnt realize you were running this all in vmware as that info was left out in the askubuntu question
<stokachu> PCdude, so you said you could juju bootstrap outside of running the installer?
<stokachu> did you deploy anything?
<stokachu> and did you deploy anything to a container within a machine?
<PCdude> stokachu: yes, I did the bootstrap and it succeeded also I deployed ubuntu with it. also that succeeded, as I could login and use the machine. I have not issued any other commands
<PCdude> stokachu:  no I did not deployed anything to a container within the machine
<stokachu> PCdude, you did a juju deploy ubuntu?
<PCdude> stokachu: correct
<stokachu> PCdude, do that again and then run juju deploy wordpress --to lxc:1
<stokachu> juju deploy mysql --to lxc:1
<PCdude> stokachu: ok, np. I have to set some things back and bootstrap again. So this can take some minutes
<PCdude> I will report back when I am done
<stokachu> k
<stokachu> dont tear it down if it fails
<PCdude> stokachu: I will try :) its bootstrapping rn
<bdx> have you guys heard about, or know about this -> https://postimg.org/image/qiaid5uo7/
<bdx> its been blocking me from launching any xenial ami for weeks now
<PCdude> stokachu: I have to issue that command on the controller not the node right?
<bdx> thought I would try again today, and it still exists
<PCdude> stokachu: the bootstrap and the deployment are both done and succeeded
<rick_h_> bdx: no, there's a know issue from last night to today, but nothing going on weeks we're aware of.
<rick_h_> bdx: have you reached out to gaughen and company on this?
<bdx> no, I just thought I would bring it up now
 * gaughen looks up
<Odd_Bloke> bdx: We haven't been seeing widespread issues launching 16.04 AMIs.
<rick_h_> bdx: gotcha, yea not aware ofthat little badge and looks like we've got gaughen's attention so hopefully she's got a better idea there.
<stokachu> PCdude, what commands did you run
<bdx> rick_h_: great, thx
<PCdude> "juju bootstrap" and "juju deploy ubuntu -n 1"
<PCdude> stokachu: thats correct right?
<stokachu> PCdude, now try juju deploy mysql --to lxc:1
<gaughen> bdx, do you have any more specific info?
<PCdude> stokachu: ok, I did that and it succeeded I think (at least it gave me no error and a new line in the CLI)
<bdx> gaughen: I have a report of the same thing happening with trusty images from a coworker all last week
<stokachu> PCdude, so you have a container with an IP?
<bdx> gaughen: trusty amis*
<Odd_Bloke> bdx: Ah, I didn't immediately recognise that as the OpsWorks dashboard.
<Odd_Bloke> bdx: There _are_ known issues there at the moment, but I don't believe that it's been going on for weeks.
<gaughen> bdx, there is a known issue (as of yesterday) for opworks where instances are hanging during boot
<PCdude> stokachu: uhm, I dont use LXD, what command should I use?
<gaughen> but it does not impact Trusty, and hasn't been an issue for weeks
<stokachu> PCdude, huh?
<stokachu> PCdude, the command is `juju deploy mysql --to lxc:1`
<PCdude> stokachu: to see containers with IP address, so I can reach them?
<PCdude> stokachu: yes I did that, but after it to check it worked
<stokachu> you can use the lxc-list --fancy
<stokachu> or juju status
<bdx> Odd_Bloke: it doesn't matter if its launched in opsworks ... between another dev and myself we probably launched 100 amis over 4 aws accounts in different regions, using different amis and they would immediately terminate on boot
<gaughen> bdx, would you file a bug here https://bugs.launchpad.net/cloud-images with as much detail as possible
<Odd_Bloke> bdx: There was an outage (unrelated to OpsWorks) on Friday for instance-store AMIs.
<bdx> but when in the opsworks console, you get that message
<gaughen> including steps for me to repro
<Odd_Bloke> bdx: But that was only an issue for a few hours before we recovered.
<PCdude> stokachu:  juju status: http://pastebin.com/raw/XdvKet93
<Odd_Bloke> bdx: So, yeah, as gaughen says, a bug with reproduction instructions (including AMI IDs) would be much appreciated. :)
<bdx> ahhh, now that I'm bitching, I just got a xenial ami to launch
<bdx> totally
<stokachu> PCdude, and what does sudo lxc-list --fancy show
<bdx> not through opsworks though
<bdx> by manual provisioning
<Odd_Bloke> Yeah, the OpsWorks issue is ongoing; the root cause is https://bugs.launchpad.net/cloud-init/+bug/1576692
<mup> Bug #1576692: fully support package installation in systemd <sts> <cloud-init:Confirmed> <cloud-init (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576692>
<bdx> I'll fire out a bug for this by eod
<bdx> ok, good to know
<PCdude> stokachu: WTF, command not find, let me triple check this. this cant be right!
<stokachu> PCdude, sorry lxc-ls --fancy
<PCdude> stokachu: ah ok, that has a result haha
<PCdude> stokachu: http://pastebin.com/raw/bxAaxwFN
<PCdude> stokachu: that seems ok right?
<stokachu> PCdude, no it's not getting an IP
<PCdude> stokachu: ah ok ,yes that should be there. At least we know for sure now, that its not landscape or anything else but just JUJU.
<stokachu> PCdude, well juju just calls out to lxc to create the container
<stokachu> this could be your MAAS server, try expanding the static IP range pool
<stokachu> but yes it isn't landscape, or the openstack-installer, and im pretty sure it isn't juju
<PCdude> stokachu: ah ok, well how big should I make it go from 50 to 100?
<stokachu> yea try 100
<stokachu> PCdude, once you do that in maas, try to deploy a new charm like, juju deploy wordpress --to lxc:1
<PCdude> stokachu: ok, it now has 100 IP addresses lets try again
<PCdude> stokachu: still no IP address...
<stokachu> PCdude, juju ssh 1; sudo pastebinit /var/log/juju/unit-wordpress-0.log
<stokachu> you can also lxc-attach to one of those containers
<stokachu> and look at /var/log/cloud-init
<PCdude> stokachu: wordpress-0.log does not exsists. I only got machine-1.log and unit-ubuntu-0.log
<stokachu> PCdude, pastebinit machine-1.log
<stokachu> PCdude, also try lxc-attach -n juju-machine-1-lxc-0
<stokachu> and paste /var/log/cloud-init*
<PCdude> http://paste.ubuntu.com/23151482/
<PCdude> ok that is /var/log/cloud-init.log
<PCdude> http://paste.ubuntu.com/23151485/
<PCdude> that is /var/log/juju/machine-1.log
<PCdude> I did lxc-attach -n juju-machine-1-lxc-0
<PCdude> it indeed has no IP
<stokachu> not sure what 2016-09-08 19:24:37 INFO juju.networker networker.go:163 networker is disabled - not starting on machine "machine-1" means
<stokachu> rick_h_, ^
<mhall119> jose: is your couchbase charm online somewhere i can look at it?
<PCdude> stokachu: it can ping 127.0.0.1 but thats it. thats of course the loop back, but still nothing is crippled to start with
 * mhall119 wonders if jcastro would mind if he converted jose from a charmer to a snapper at UbuConEU
<rick_h_> stokachu: not sure
<cory_fu> kjackal_, petevg, kwmonroe: https://github.com/juju-solutions/interface-zeppelin
<cory_fu> Please review
<stokachu> PCdude, is the 192.168.1.x a private network?
 * mhall119 is pretty sure that's a private network address block
<jose> mhall119: launchpad but i'm pushing another iteration soon
<stokachu> mhall119, thanks for taking over support
<mhall119> stokachu: darnit :(
<mhall119> jose: what project?
<jose> mhall119: lemme get a link for you, 1s
<PCdude> stokachu: yes 192.168.1.x/24 is private, 10.1.10.x/24 is
<PCdude> public
<stokachu> PCdude, and maas manages both dns/dhcp on 192.168.1.x?
<PCdude> stokachu: that is correct
<stokachu> PCdude, well im out of ideas, we know it's networking related
<jose> mhall119: https://code.launchpad.net/~jose/charms/trusty/couchbase/trunk the charm itself works perfectly, but automated testing is funky
<mhall119> thanks jose, I just want to read it
<jose> np, let me know if you have any questions
<stokachu> PCdude, im also inclined to say this is in maas territory
<mhall119> jose: just one question; "Do you want to learn how to make snaps?" :)
<jose> mhall119: maybe, I can give it a shot and if it's doable I can charm+snap
<PCdude> stokachu: yes network related and maybe LXD, I dont know. I have to say that both DNS and DHCP are working. I tried it both, by adding an random machine to it with linux already installed and tried to contact the internet
<jose> mhall119: live training in Europe? ;)
<stokachu> PCdude, well you can't deploy to containers on the machines
<PCdude> stokachu: ah ok, well at least we are a step closer to the solution
<stokachu> so i would say dhcp is not working
<mhall119> jose: dholbach will be doing a workshop, but we can do some bar-learning as well
<jose> mhall119: bar-learning sounds awesome, specially with a couple legal beers
<PCdude> stokachu: well if it is not working the nodes in the 192.168.1.x/24 domain should not even startup right? PXE is inherently connected to DHCP.
<mhall119> yay for legal beer! \o/
<stokachu> PCdude, that's why i think you're existing your dhcp pool, maybe expanding the range didn't take effect
<stokachu> i dont know what doing an esxi snapshot/restore entails
<mhall119> jose: http://packages.couchbase.com/ gives me an access denied error, is that expected?
<jose> hmm, not at all. I'll check when I get back home.  in class atm
<mhall119> oh, sorry to bother you in class (you should disconnect)
<jose> hehe no worries. it's just starting and things are getting set up, have a couple mins
<mhall119> looks like only partial URLs are being blocked, probably so you can't see a files list on the server, so no concern
<PCdude> stokachu: hmm maybe. I dont know about vmware, I think they just take a copy of the disk and put it back.
<rick_h_> beisner: ping
<PCdude> stokachu: I think that is not the problem, but I could start over from the start, but that would take to much time rn
<rick_h_> beisner: do you all deploy on kvm/nova on ppc64el?
<stokachu> PCdude, ok well you've got a good place to start debugging
<bdx> ~
<bdx> ~
<PCdude> stokachu: yeah indeed, at least I really wanna thank u! One step closer to an working openstack install :)
<magicaltrout> marcoceppi: out of interest
<magicaltrout> whats the process to get an interface listed on interfaces.juju.solutions
<marcoceppi> magicaltrout: yes?
<magicaltrout> i'm working on a drill one for jdbc connections etc so it would be good  to allow other stuff to use it
<marcoceppi> magicaltrout: log in with LP, then add then click the + next to interface or layer
<marcoceppi> fill out the form, and submit ;)
<magicaltrout> ah the tool i try and avoid
<magicaltrout> will do
<stokachu> rick_h_: marcoceppi what was that bug number about xenial and lxd failing to create containers?
<stokachu> with juju
<marcoceppi> stokachu: it's a cloud-init issue, i think
<marcoceppi> - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621229
<marcoceppi> - https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1576692
<mup> Bug #1621229: snap upgrade to 2.14.2~16.04 in xenial lxc hangs <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1621229>
<mup> Bug #1576692: fully support package installation in systemd <sts> <cloud-init:Confirmed> <cloud-init (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576692>
<rick_h_> stokachu: sec, it's in that juju list email. /me goes to look
<stokachu> thanks
<magicaltrout> lazyPower oh fountain of useful code snippets
<magicaltrout> i need to write an interface, that when a user connects to drill the interface then goes and returns the ip addresses of the zookeeper units it has attached
<magicaltrout> how do i find out the ZK units?
<magicaltrout> aww
<marcoceppi> magicaltrout: o/
<marcoceppi> Guess I'm not good enough?
<magicaltrout> you suffice marcoceppi
<magicaltrout> i just bug lazypower because he tends to have this stuff to hand ;)
<lazyPower> magicaltrout - sorry about that, flakey internet here at the sprint.
<magicaltrout> lol no probs i'm just looking for a pointer
<lazyPower> magicaltrout - as best as i can tell, you would need to coordinate with the consuming layer... cory_fu may know better, but from what i know, thats up to the implementation on which relation its scoped to, et-al.
<lazyPower> i dont think there's a more deterministic approach to take there off the top of my head
<magicaltrout> okay so in my main drillbit charm
<magicaltrout> i keep a data_changed function which is a list of zookeepers
<magicaltrout> can my interface hit that?
<lazyPower> so long as its your drillbit layer thats communicating to the interface, i think that keeps the levels of encapsulation
<magicaltrout> well i wrote the charm, now i'm  writing the  interface
<magicaltrout> so i think i'm good on those counts
<magicaltrout> i dont like interfaces they're like a blackhole of stuff i don't understand
#juju 2016-09-09
<magicaltrout> anyone around who can provide some interface writing support
<magicaltrout> or are you all in Pasadena?
<magicaltrout> babbageclunk: fancy explaining some interface stuff that is clearly very simple but my brain can't process?
<babbageclunk> um, I'll have a go! Not very familiar with those bits myself yet.
<magicaltrout> lol
<magicaltrout> well you're my only hope... no pressure
 * babbageclunk girds loins
<magicaltrout> anyway my idea is pretty simple... I want to create a generic JDBC interface because a bunch of services provide JDBC connections and apps like Saiku can consume JDBC connection info
<babbageclunk> ok
<magicaltrout> and all jdbc connections are basically the same, username, password, class and url
<babbageclunk> sure
<magicaltrout> so...
<magicaltrout> http://pastebin.com/Ewpg03nM ignore the fact this is mid munging from another interface I wrote
<magicaltrout> I want to write the provides side of the interface
<magicaltrout> and my idea is the charm, be it, mysql, drill, postgres etc would provide a connection string and other metadata
<magicaltrout> but where I'm struggling is in my understanding of charms <-> interfaces
<magicaltrout> how do I tell my interface to look up a variable from my providing charm?
<magicaltrout> the only interface stuff I've done so far has been to get unit info etc
<babbageclunk> Sorry, this is all new to me. So you'd subclass this to make a relation?
<magicaltrout> hehe, well my idea was (I don't know if this is possible which I guess is half the issue), charm x provides jdbc url, password, username etc
<magicaltrout> generic jdbc layer can look up those standard variables
<magicaltrout> sorry s/layer/interface
<magicaltrout> and pas them to implementing app to inject into a jdbc connection
<magicaltrout> that way, for a bunch of jdbc providing charms there could be one standard jdbc interface that all apps could consume without hacking around the data provided over the wire in the implementing charm itself
<babbageclunk> But is there a lifecycle step where an interface can get customised, or is it just looked up directly from some registry?
<magicaltrout> I don't think (feel free to prove me wrong) it needs much customisation.
<magicaltrout> so it would just look up stuff from the providing charm
<magicaltrout> i shall draw a picture! :)
 * magicaltrout cracks out google drawings
 * babbageclunk reads some docs - this is probably a good time to learn about interfaces.
<magicaltrout> here you go babbageclunk
<magicaltrout> https://ibin.co/2uSum2mXgYHo.png
<magicaltrout> currently most interfaces are specific to an app... interface:mysql etc
<magicaltrout> but why not make a generic one that passes over specific variables from the providing charm?
<magicaltrout> that way requiring charm developers don't need to look up loads of metadata or hop through chopping up unit information
<magicaltrout> because the providing charm (the folks that know what the jdbc stuff should look like) have done it for them
<magicaltrout> then "any jdbc compatible application" can then grok the incoming charm connection and use the metadata over the wire
<babbageclunk> That makes sense to me. How do the app-specific interfaces get the username/password/etc info they need to convey to the requires-side of the relation?
<babbageclunk> Wouldn't yours work in the same way?
<magicaltrout> hold on I'll show you what I currently do
<magicaltrout> https://gist.github.com/buggtb/7e04a90922673312ebc6ca62f57fe464
<magicaltrout> so thats on the jdbc application side
<magicaltrout> but this is basically where my knowledge falls down because in the mysql layer for example: https://github.com/johnsca/juju-relation-mysql/blob/master/requires.py
<magicaltrout> self.host() etc
<magicaltrout> https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py on the provides side coming from mysql
<magicaltrout> I dont' see how the host, port etc get set
<magicaltrout> which confuses the hell out of me :)
<babbageclunk> Reading...
<babbageclunk> So they get passed into provide_database - where does that get called?
<magicaltrout> exactly! :)
<babbageclunk> D'oh
<magicaltrout> well
<babbageclunk> Starting simply, it's easy to see how you could make one charm that could require all of mysql, psql, drill, etc.
<babbageclunk> And then provide generic jdbc
<babbageclunk> (Hmm, actually I might be confused about that but it seems possible, right?)
<magicaltrout> well my Saiku charm for example, could then require jdbc in metadata.yaml
<magicaltrout> which would then accept connections from jdbc providing charms
<magicaltrout> so yeah that seems like its possible
<magicaltrout> and on the consuming/requiring end it should reduce complexity and repetition
<magicaltrout> and people wonder why i get annoyed with interfaces, cory is like the bloody interface wizard, but it makes it hard for everyone else ;)
<babbageclunk> Right. Then the question would be could you do that in a layer so that any charm that provides one of them also privides jdbc?
<magicaltrout> okay to retort, why would I need a layer instead of an interface?
<babbageclunk> I think I mean an interface layer - is that a thing?
<magicaltrout> lol
<magicaltrout> interface or layer. Layers allow you to reuse existing layered charms
<magicaltrout> charm inheritance
<magicaltrout> interfaces are the stuff that allow the hooks to fire
<babbageclunk> Right, but I was reading this: https://jujucharms.com/docs/2.0/developer-layers-interfaces
<magicaltrout> so the question would be: could you do that in an *interface* so that any charm that provides the interface can support jdbc connections
<babbageclunk> Or rather, could you make a layer that would provide a generic interface so that the charm just provides a specific one, and includes the interface layer to magically support the generic one.
<magicaltrout> well you'd just upgrade the charms to provide interface:jdbc and set some stuff
<babbageclunk> Which was the bit you were asking. Sorry!
<magicaltrout> I write the Drill charm so my plan is to test it there then if it works, submit some PR's to mysql/postgres etc
<magicaltrout> I think its something to do with self.conversation()
<babbageclunk> Well, conversation is the bit that pushes the connection details to the requires side.
<babbageclunk> I think
<magicaltrout> https://github.com/johnsca/interface-mapred-slave/blob/master/provides.py here's another one of cory's
<magicaltrout> conv.get_local etc
<magicaltrout> sooo
<magicaltrout> how do I set something on the conversation I guess
<magicaltrout> or how does it magically appear
<babbageclunk> That's a weird one though - since it's a map reduce slave even though it's a provides interface it's getting data from the conversation and storing it. I think if you look at the requires side you'll see something equivalent to the provide_database call.
<magicaltrout> yeah so on the requires side I need a method like
<magicaltrout> def get_jdbc():
<magicaltrout> which does conv.get_remote()
<magicaltrout> or something
<babbageclunk> Hang on, just looking at the other DB relations
<magicaltrout> and thats part of the annoyance on that charm the only get_remote is getting the private-address
<magicaltrout> ta
<babbageclunk> Have you got a locally built version of the mysql charm?
<magicaltrout> i have a zip bundle download
<magicaltrout> its not reactive so I guess that counts
<babbageclunk> You should be able to find the place that calls provide_database in the code?
<magicaltrout> you'll like this
<magicaltrout> bugg@tom-laptop2:/tmp/charm$ grep -R provide_database .
<magicaltrout> bugg@tom-laptop2:/tmp/charm$
<babbageclunk> typical
<magicaltrout> lol
<magicaltrout> told you
<magicaltrout> this stuff cory writes is more often than not... magic
<babbageclunk> https://github.com/johnsca/juju-relation-mysql/blob/master/docs/source/provides.rst
<magicaltrout> ah
<magicaltrout> so.....
<magicaltrout> on the provides side in drill I need to decorate some method
<babbageclunk> If something's using that code to provide mysql, somewhere it's calling provide_database (with all the info you need to make the jdbc conn details).
<magicaltrout> to detect the connection and set the variables in a provides interface method call
<babbageclunk> Yeah
<magicaltrout> woop
<magicaltrout> babbageclunk: you code grepping genius
<babbageclunk> Sorry, I'm a bit slow today!
<magicaltrout> hehe, this stuff really messes with my head, then you think you're on to something and find some weird bash script at the other end etc
<magicaltrout> I don't write python well at the best of times, finding out how charms interact melts my mind
<babbageclunk> You're right it's confusing - the config information flow in the relations isn't always from provides to requires. But I think in the case of things like DB connections it will be.
<magicaltrout> marvelous... with this mystery half solved i'll try and implement something in drill and see what happens
<magicaltrout> i reckon an interface with, jdbcurl, username, password, class and a place for "extra stuff" to live
<magicaltrout> would offer enough genericisim hopefully the interface setup allows it to work how I imagine :)
<babbageclunk> That sounds neat
<babbageclunk> ok, great! Now I need to work out why DHCP is MIA in my MAAS
<magicaltrout> lol
<magicaltrout> unlucky
<magicaltrout> I did see some stuff when I was messing with virtualbox the other day where DHCP just refused to start if you didn't set a dynamic dhcp address pool
<magicaltrout> thats about the depth of my MAAS knowledge
<autonomouse> Hi, I was hoping for a bit of advice, if anyone is available. I have a reactive charm and an old-style charm, and I'd like to pass some information between them. e.g. url, username and apikey from a django service to something that needs to use that service. With the newer reactive charms, I believe I am supposed to set up an interface to do this. Can anyone tell me if the old-style charm can use this interface, and if
<autonomouse> not, what the best approach is for handling this please?
<mbruzek> bdx
<kwmonroe> admcleod: beisner:  https://jujucharms.com/hadoop-processing/  it takes 8 machines by default, but you can change num_units on "slave" from 3 to 1 to get it down to 6:  https://api.jujucharms.com/charmstore/v5/hadoop-processing/archive/bundle.yaml
<jose> jcastro: thought of using summit.ubuntu.com for the summit?
<marcoceppi> jose: no
<marcoceppi> the schedule is small, lightweight, and constantly in flux
<jose> gotcha, was available so thought of you
<kwmonroe> beisner: admcleod:  http://paste.ubuntu.com/23155869/
<admcleod> kwmonroe: thanks
<beisner> thx kwmonroe
<magicaltrout> nearly missed tomorrows flight..... lost passport....
<magicaltrout> lazyPower: good news.... I have a 2nd talk.... also about docker and juju
<magicaltrout> @jpl that is
<lazyPower> nice!
<lazyPower> magicaltrout - when is that?
<magicaltrout> the week after the summit
<lazyPower> oh wow, so soooooon :D
<lazyPower> we'll have to sync up, make sure we're up to snuff on the latest and greatest
<magicaltrout> yeah well,  i'm in town etc..
<lazyPower> about that, when do you arrive for the summit?
<magicaltrout> saturday afternoon
<lazyPower> nice, i'll be around
<lazyPower> i should shoot you my digits
<magicaltrout> i'll be sat in the bar very jetlagged ;)
<magicaltrout> ooh
<magicaltrout> thats tomorrow
<lazyPower> indeed
<magicaltrout> okay tomorrow afternoon
<magicaltrout> very jetlagged
<magicaltrout> i left my passport in the hotel i was in last week
<lazyPower> so sunday brunch/lunch then depending on when i roll my lazy bones out of bed
<magicaltrout> can you believe it?!
<lazyPower> doh
<magicaltrout> (yes)
<magicaltrout> need to pick it up on the way to LHR
<lazyPower> thats a nice distraction eh?
<magicaltrout> spent all afternoon trying to find it:)
<magicaltrout> i have an interface question if  you have 3  mins?
<magicaltrout> not technical,  theoretical
<babbageclunk> IT'S A TRAP
<magicaltrout> i saw you lurking
<magicaltrout> i  was trying to clear up our theory from this morning :P
<admcleod> magicaltrout: took me ~20 hours from BCN. i feel a bit weird.
<magicaltrout> like usual then admcleod ?
<lazyPower> magicaltrout - sure
<lazyPower> fire away
<babbageclunk> I mean, it's an interesting trap.
<babbageclunk> :)
<magicaltrout> sorry for the delay lazyPower
<magicaltrout> okay i have this idea
 * lazyPower listens intently
<magicaltrout> ideally there will be a bunch of apps that can consume JDBC connections
<lazyPower> for the clarification of kwmonroe - JDBC is just the java database adapter right? their pluggable abstraction?
<magicaltrout> soooo I had a plan to create a generic JDBC interface, that the providing charm  could populate with the stuff required by the consuming application
<magicaltrout> yeah, any java data app  speaks jdbc in some form
<lazyPower> yep, similar concepts in .net, go on
<magicaltrout> so all jdbc connections are basically the same just different details, and I'm sick as a consuming app figuring out the various interfaces and stuff you need to know to build 1 per database or data source
<magicaltrout> so I figured why not have mysql, postgres, drill etc all suppor the the jdbc interface
<magicaltrout> which clearly is doable
<magicaltrout> from a consuming standpoint, is  it possible and acceptable for 1 charm to consume the same interface from  multiple sources with different deets?
<jrwren> magicaltrout: you are going to be talking at JPL?  that is awesome!
<magicaltrout> my employers suggested it might be a good idea
<magicaltrout> not sure when a hacker speaking to a bunch of PhD's was a good idea
<magicaltrout> but we shall see
<admcleod> magicaltrout: usual would be usual. weird is different weird.
<magicaltrout> admcleod: a bit more like the i've been up for 24 hours, its 3pm so technically to early to drink but in reality i was drinking at 9am so wtf?
<magicaltrout> don't worry you can take the piss out of me tomorrow in the same state
<magicaltrout> after my drive from  LAX to the Sheraton
<admcleod> magicaltrout: yeah, but i didnt really feel jetlagged, had a great sleep, woke up fresh.. but just hit me now
<admcleod> magicaltrout: also i would never take the piss.
<magicaltrout> sleep?
<magicaltrout> you slept on the plane?
<magicaltrout> or post landing?
<magicaltrout> I once slept from Manchester to Toronto without waking once, the flight crew were pretty impressed
<rick_h_> magicaltrout: you all there already?
<rick_h_> magicaltrout: it's called ambien! only way I can sleep on planes
<magicaltrout> sadly the first homeless guy to talk to me in Tonronto was from Leeds where i'd just left
<magicaltrout> i fly tomorrow rick_h_
<admcleod> magicaltrout: no, landed last night
<rick_h_> magicaltrout: ah ok
 * rick_h_ doesn't leave until sunday
<magicaltrout> i need a day or so to get over the lag
<rick_h_> yea, always a good thing
<magicaltrout> admcleod: ah, yeah i know that one
<jrwren> i usually need a week, and then i go home and need another week to adjust.
<magicaltrout> although when i went to vancouver for apachecon the day i landed it smacked me  so hard i left the hotel bar without paying
<magicaltrout> had to grovel the next day ;)
<jrwren> magicaltrout: I look forward to meeting you.
<magicaltrout> jrwren: good job i'm there for 2 weeks then ;)
<magicaltrout> yeah jrwren it's gonna be a blast meeting more of the US folks and the expanding charmer team
<magicaltrout> also, its amazing how much  has changed and moved on since Ghent at the start of the year
<magicaltrout> i blame jcastro for my continued participation in this mess! ;)
<icey> does anybody know how to install `charms` in addition to `pycharms`, pycharms seems to overwrite charms and trusty won't install charm-tools anymore
<rick_h_> magicaltrout: we all blame jcastro :P
<rick_h_> icey: pycharms?
<magicaltrout> aye
<icey> yes (says cholcombe, he's the asker :) )
<magicaltrout> don't blame you
<rick_h_> icey: hmm, pycharm search only finds the editor
<icey> rick_h_: that's the one
<rick_h_> icey: so the charm command interferes with the editor install?
<icey> rick_h_: backwards, apparently the editor interferes with the charm install
<icey> he cannot install charm
<rick_h_> icey: hmm, and he's getting charm on trusty from the stable PPA?
<rick_h_> icey: or which PPA I guess?
<icey> yes
<icey> rick_h_:
<rick_h_> hmm, there's a few python deps like pytest and path.py that are in the PPA to support charm-tools and the like. I wonder if those are interfering
<rick_h_> icey: my short answer is try to to setup one of them in a lxc container or the like atm, I'm not sure what conflicts without figuring out where he's getting pycharm from (it's not listed in ubuntu) and so guessing there's conflicting PPA/repos stuff there
<icey> thanks rick_h_
<rick_h_> sorry
<lazyPower> magicaltrout - to circle back to your interface idea
<magicaltrout> i like the lag
<lazyPower> i think thats a fine idea. JDBC as a generic abstraction would be great, what would be even better, is if jdbc knew how to consume the existing relations, then its a one sided update. I'm wondering if you dont make a jdbc layer, that implements the known relations, and surfaces the details appropriately
<lazyPower> otherwise, you're facing adding JDBC interface to every [layer|charm] that needs to communicate to jdbc. I'm trying to noodle how i can save you work there
<lazyPower> but i dont think we have considered this as a use case
<magicaltrout> well i might upstream mysql and postgresql and hive
<magicaltrout> its not masses of effort and saves extra layers
<lazyPower> when you say upstream, you mean just add the - 'interface:jdbc' to those charms right?
<lazyPower> and whatever additional bits to utilize it in the layer
<magicaltrout> yeah and a connection  method call somewhere
<lazyPower> right, ok.  upstreaming is such an overloaded term anymore :)
<lazyPower> yeah, that works. I'm +1 to this, as its straight forward, and makes a ton of sense
<magicaltrout> you know me... trying to stay hip.. ;)
<magicaltrout> yeah, i started writing a drill interface, but then i realised apart from the values
<magicaltrout> the keys are identical to most  other jdbc interfaces
<magicaltrout> so the lovely babbageclunk helped me unmuddle my brain this morning and i stood up something basic in drill, but I think generic interface for regular connections, as long as in practice they work
<magicaltrout> would make life a lot easier for requring chamrer
<magicaltrout> charmers
<magicaltrout> saiku, pentaho, spago can certainly implement jdbc requires, so could drill and probably zeppelin somewhere
<marcoceppi> magicaltrout: yeah, but jdbc is a connection string format, and if you have an app that takes a JDBC connection for MySQL but won't work on cassandra, then a jdbc interface doesn't really help?
<magicaltrout> okay so lets assume some common sense on the end of the user
<magicaltrout> cassandra isn't a jdbc compliant database
<magicaltrout> whilst there are adapters for it
<magicaltrout> jdbc is a standard and if you can write SQL  you can 95% of the interrogate a database
<magicaltrout> of course there are exceptions
<magicaltrout> but in the scheme of things and also the charms you guys have available, those exceptions don't really count
<magicaltrout> also
<magicaltrout> its  not the law to implement it
<magicaltrout> you can still do what the hell you like :)
<marcoceppi> if you want to implement a jdbc interface and add it to mysql/maria/percona/postgresql (any others?) go for it :)
<marcoceppi> but I thin kit'd be work discussing next week
<magicaltrout> sure, i can always rename my test jdbc interface  drillbit and we're back to the same thing
<magicaltrout> i just think there should be a nice way for people trying to use the stuff provided by the resources instead of trying to find unit names etc because your providing charm requires a list of ZK nodes etc
<magicaltrout> i happen to be implementing the drill charm as well so it doesn't count as much. but I wouldn't envy someone trying to work out the jdbc url without charmers help
<magicaltrout> so why not try and genericise it
<marcoceppi> +1
#juju 2016-09-10
<cory_fu> petevg: https://github.com/juju-solutions/layer-apache-zeppelin/pull/13
<pragsmike> greets
<lazyPower> return greetings pragsmike
<pragsmike> beta18!
<rick_h_> on the way
<pragsmike> how long does it usually take before a release winds up in http://ppa.launchpad.net/juju/devel/ubuntu
<rick_h_> pragsmike: few hours for things like getting launchpad builds and such
<pragsmike> k
<rick_h_> streams sync/etc
<pragsmike> is there a picture somewhere of that process
<pragsmike> it sounds cool
<rick_h_> not that I've got handy unfortunately
<rick_h_> it's part magic heh
<lazyPower> rick_h_ - at some point, you should give a talk over our release pipeline for juju
<lazyPower> as a lightning talk :)
<rick_h_> lazyPower: hah, I see what you did there :P
<lazyPower> i do try :D
<pragsmike> It's not just you! http://streams.canonical.com looks down from here.
<hloeung> pragsmike: try now
<pragsmike> ok, that's reachable now, thanks
<pragsmike> sad to report that even with beta18 my containers still end up on the lxdbr0 bridge, and not on br-eno1
<pragsmike> i'm trying again, this time with MAAS 2.0.0+bzr5189-0ubuntu1 as Dimiter said he hadn't tested with MAAS 2.1.0 alpha yet
<pragsmike> MAAS 2.0 from stable won't even successfully deploy the machine to run the juju controller, curtin hangs forever on "install kernel"
<pragsmike> so i'm going back to MAAS 2.1
#juju 2016-09-11
<magicaltrout> woop
<magicaltrout> Pasadena... one is in you
<marcoceppi> magicaltrout: welcome!
<magicaltrout> and i didn't run anyone over
<marcoceppi> magicaltrout: oh no you rented a car?
<magicaltrout> indeed
<magicaltrout> i'm here for 2 weeks, so i need to leave the hotel at some point
<marcoceppi> magicaltrout: excellent
<magicaltrout> booking this summit at the start of the college and NFL football seasons is really going to hamper the likelyhood of me getting my stuff done tomorrow
<pragsmike> hi
<pragsmike> I am so ready to go to charm school
<lazyPower> pragsmike - almost time :)
<pragsmike> I arrive 5pm LAX
<pragsmike> no idea when I'll get to hotel
<marcoceppi> pragsmike: probably around 6-6:30
<magicaltrout> aww see pragsmike you should'a turned up today, i could have given you a lift!
<pragsmike> ok preparing for the trip, see you guys tonight
<magicaltrout> argh the jetlag
<Guest_94848> allah is doing
<Guest_94848> sun is not doing allah is doing
<Guest_94848> moon is not doing allah is doing
<Guest_94848> stars are not doing allah is doing
<Guest_94848> planets are not doing allah is doing
<Guest_94848> galaxies are not doing allah is doing
<Guest_94848> oceans are not doing allah is doing
<Guest_94848> mountains are not doing allah is doing
<Guest_94848> trees are not doing allah is doing
<Guest_94848> mom is not doing allah is doing
<Guest_94848> dad is not doing allah is doing
<Guest_94848> boss is not doing allah is doing
<Guest_94848> job is not doing allah is doing
<Guest_94848> dollar is not doing allah is doing
<Guest_94848> degree is not doing allah is doing
<Guest_94848> medicine is not doing allah is doing
<Guest_94848> customers are not doing allah is doing
<Guest_94848> you can not get a job without the permission of allah
<Guest_94848> you can not get married without the permission of allah
<Guest_94848> nobody can get angry at you without the permission of allah
<Guest_94848> light is not doing allah is doing
<Guest_94848> fan is not doing allah is doing
<Guest_94848> businessess are not doing allah is doing
<Guest_94848> america is not doing allah is doing
<lazyPower> this guy again?
<magicaltrout> hello Guest_94848
<magicaltrout> i've missed you!
<Guest_94848> fire can not burn without the permission of allah
<Guest_94848> knife can not cut without the permission of allah
<Guest_94848> rulers are not doing allah is doing
<lazyPower> and now, time for something completely different
<Guest_94848> governments are not doing allah is doing
<Guest_94848> sleep is not doing allah is doing
<magicaltrout> Guest_94848: do you happen to live in Pasadena?
<magicaltrout> We're at the Sheraton.... swing by
<magicaltrout> I'd love to know more
<lazyPower> i dont think they will make it to the summit now magicaltrout
<magicaltrout> :(
#juju 2017-09-05
<erik_lonroth_> Hello people! Anyone here that knows where to figure out what url:s/domains that is used by "snap" to install juju? Our firewall/proxy is not being nice to me when trying to "snap install juju". Any pointers?
<hloeung> erik_lonroth_: snaps are hosted on a CDN
<hloeung> erik_lonroth_: maybe '068ed04f23.site.internapcdn.net.' ?
<hloeung> that's from turning on query logging on my DNS resolver and running 'snap download juju'
<hloeung> it also hits api.snapcraft.io before the CDN
<magicaltrout> just won another local k8s contract, my ability to blag answers are second to none.....
<rick_h> magicaltrout: lol awesome and congrats.
<erik_lonroth_> hloeung: Thanx for trying to help out. I'm in the black here so I could use any help to compile a whitelist for the proxy.
<stub> proof: E: config.yaml: ca does not conform to naming pattern
<stub> Anyone know what that means?
<magicaltrout> er right
<magicaltrout> so I left my lovely k8s stack running last week
<magicaltrout> this week
<magicaltrout> I'm getting lots of this:
<magicaltrout> manifold worker returned unexpected error: leadership failure: lease manager stopped
<magicaltrout> on about 20 nodes
<magicaltrout> what have i missed?
<magicaltrout> https://paste.ubuntu.com/25473709/
<magicaltrout> 2017-09-03 21:59:25 ERROR juju.worker.uniter.context context.go:675 could not write settings from "update-status" to relation 26: cannot write settings: read tcp 127.0.0.1:37346->127.0.0.1:37017: i/o timeout
<magicaltrout> does juju really suffer such a meltdown if there is a network issue?
<tvansteenburgh> balloons, that mean anything to you? ^
<balloons> magicaltrout, what does juju status say/show?
<magicaltrout> i've rebooted the controller and the connections seem to be coming back
<magicaltrout> but its spent 2 days in that weird failed state
<magicaltrout> https://pastebin.com/ETBuBTS4
<magicaltrout> before the restart it said that balloons
<magicaltrout> back to green *phew* I don't like read
<magicaltrout> red
<balloons> yea, a bunch of failed workers.
<balloons> curious how it got that way
<magicaltrout> that said, the network was fine, I could ssh around from the controller to other nodes and stuff
<magicaltrout> so I dunno why it got so sad for 2 days straight
<magicaltrout> cicleci for juju builds is possibly the best thing I've ever found
<magicaltrout> and snap builds for that matter
<rick_h> magicaltrout: charming circleci? I was going to play with that at one point but it was missing something I needed. /me tries to remember...
<magicaltrout> https://github.com/spiculedata/circleci-juju i wrote a simple dockerfile for it rick_h
<magicaltrout> doesn't support resources yet
<rick_h> magicaltrout: nice
<magicaltrout> https://pastebin.com/1PrpjrP6
<magicaltrout> build files look like that
<magicaltrout> it can clearly be cleaned up and extended a bit, does the job nicely though for per commit builds of stuff
<bdx> can I specify a subnet to bootstrap to?
<bdx> for AWS
<bdx> I thought I saw that land
<bdx> rick_h: ^
<rick_h> bdx: yea should be able to in 2.2.2
<bdx> oh nice
<rick_h> Thought it was in there.
<bdx> yeah I thought so too
<bdx> jam: ^?
<bdx> found it https://bugs.launchpad.net/juju/+bug/1659640
<mup> Bug #1659640: Juju needs to support specifying subnets for controller <juju:Fix Released by jameinel> <https://launchpad.net/bugs/1659640>
<bdx> aweeeee it works too :)
<bdx> that is really exciting
<bdx> I've been cursing that bug for a long time
<bdx> very nice get deterministic bootstraps
<bdx> I feel so at peace
#juju 2017-09-06
<erik_lonroth_> Hello!
<erik_lonroth_> I'm encountering some problem with installing juju on ubuntu via "snap".  It fails to download and this is what I encounter. https://pastebin.com/LM6JGkDy - Is this something you have experienced too
<erik_lonroth_> I commented on this: https://bugs.launchpad.net/click-package-index/+bug/1688529?comments=all
<mup> Bug #1688529: X-Ubuntu-Series is required but not accepted <Click Package Index:New> <https://launchpad.net/bugs/1688529>
<gvseghbr> Hi, I've some problems with bootstrapping a controller on my VMware cluster. Everything seems to be okay, up to the point the bootstrapping process tries to contact the controller API (via WebSocket). I get this error â09:56:03 DEBUG juju.api apiclient.go:842 error dialing websocket: Forbiddenâ, something to do with the X509 certificate.
<gvseghbr> Here some more output: https://askubuntu.com/questions/953079/error-while-bootstrapping-on-vmware
<magicaltrout> erik_lonroth_:
<magicaltrout> i don't have an answer for you
<magicaltrout> but
<magicaltrout> if you provide X-Ubuntu-Series: 16
<magicaltrout> you do get a direct link to the download url
<magicaltrout> curl -H X-Ubuntu-Series:16 https://api.snapcraft.io/api/v1/snaps/details/juju
<rick_h> erik_lonroth_: interesting. seems like that might be a snap bug that will have to get looked into
<rick_h> oh, you filed it heh
<rick_h> or found one
<stormmore> o/
<bdx> hey, what is the supported graphite charm I should be using?
<rick_h> bdx: not sure, the community ones seem to be older from folks that aren't maintaining them.
<bdx> rick_h: you use the grafana + prometheus + collectd charms in your monitoring stack?
<bdx> rick_h: do you know what interface the collectd and prometheus charms relate on?
<rick_h> bdx: yea, telegraf, grafana, prometheus. https://jujucharms.com/u/prometheus-charmers/ is the IS folks that do most of that setup
<bdx> rick_h: how does collectd fit into the picture?
<rick_h> bdx: looking, looks like it's a subordinate like telegraf. Just uses juju-info to communicate like telegraf.
<bdx> ha
<bdx> so you would think
<rick_h> Most of those folks are offline (UK) or not yet on (AU/etc)
<bdx> rick_h: its cool man
<rick_h> bdx: but also might be worth an email to the juju list, I'm honestly not sure as I've not set it up :(
<bdx> ahh
<rick_h> bdx: ooh, did you know about charm set extra-info? https://github.com/juju/charmstore/issues/774#issuecomment-327590988
<bdx> rick_h: that is great
<bdx> man
<bdx> so many great things happening
<rick_h> bdx: can put any key/value in there for some fun stuff
<bdx> rick_h: thats great ... don't we have a similar thing for models now too?
<rick_h> bdx: for models? I mean there's annotations over the API but not sure what's on the CLI for it.
<rick_h> what's nice here is how it's right in the charm command. I know there was an extra-info api and could be hit up with a python client/etc, but awesome it's baked into the charm command cli for quick hacky foo like that
<bdx> yeah totally
<bdx> really cool
<bdx> I think I have a bunch of places where triggers will take over in my charms
<bdx> triggers use case: https://gist.github.com/jamesbeedy/e36b4bd4cf35d1f48682acc1605c373a
<bdx> rick_h: I've got this manual vs relations battle similar to ^
<bdx> going on in almost every charm
<bdx> I think triggers will really help clear a lot of that out
<bdx> https://gist.github.com/jamesbeedy/e36b4bd4cf35d1f48682acc1605c373a#file-data_api-py-L42
<bdx> rick_h: I found it!
<bdx> look
<bdx> lol
<bdx> from the collectd charm http://imgur.com/a/n9b6p
<bdx> ^ what I call a "hunt and slap"
<rick_h> bdx: lol
<rick_h> bdx: very sneaky
<bdx>  deadly
<bdx> rick_h: will you aid me in finding the elusive "aluria's PPA" ?
<bdx> the single PPA needed to make prometheus exporting work with the collectd charm
<rick_h> bdx: https://launchpad.net/~aluria/+archive/ubuntu/bootstack
<rick_h> bdx: that's the PPA referenced
<bdx> rick_h: awesome!
<bdx> rick_h: nice find
<bdx> rick_h: ok, bunch of cruft here
<bdx> rick_h: I am impressed with your ppa finding ability
<bdx> rick_h: still no excuse for the state of this collectd charm though
<rick_h> bdx: https://launchpad.net/ubuntu/+ppas
<bdx> so
<bdx> ahh
<bdx> nice
<bdx> lol
<bdx> so yeah
 * rick_h is a good typer in a search box :)
<bdx> collectd charm supports xenial and trusty, but the prometheus export functionality is only supported from aluria's ppa for trusty
<bdx> graphite_export functionality is currently broken
<bdx> soooo
<bdx> you can use the collectd charm with aluria's repo on trusty I'm assuming
<bdx> this totally suck
<bdx> s
<rick_h> bdx: so you can try to build it on a later series if it still works
<bdx> rick_h: the charm deploys on xenial fine
<rick_h> bdx: so you can head to https://launchpad.net/~aluria/+archive/ubuntu/bootstack/+packages and click "copy packages into your own PPA, and then you change the series when you copy them
<rick_h> bdx: I mean the package, if it works on the series or not
<bdx> oh really
<rick_h> yea
<rick_h> that's if the software package works as is across series, many will but not sure here.
<bdx> got it
<bdx> I'll give it a try
<bdx> rick_h: thx
<rick_h> then obviously change the PPA setting in the charm config to your own PPA and such
<rick_h> bdx: cool, let me know how it goes. Hopefully it'll work out.
<bdx> rick_h: so, making progress http://paste.ubuntu.com/25480346/
<bdx> I was able to copy over the packages to my own ppa, and build them for xenial
<bdx> they all built fine, and are in my "peopledatalabs" ppas
<bdx> ppa
<bdx> but I'm thinking I may need to do something to get a releases file
<bdx> I was getting the same error when using the bootstack ppa too
<bdx> hmm
<rick_h> bdx: yea, so looking at that error...it's because the ppa doesn't have anything for your series
<rick_h> bdx: so have to make sure the charm series matches your PPA and that in that PPA is a RELEASES file with content
<rick_h> bdx: could be caching/etc for something newly built
<rick_h> bdx: is the PPA private? I don't see it in the account
<rick_h> oh wait, I do see it my bad
<bdx> ahh, "in that PPA is a RELEASES file with content" can you give an example?
<bdx> here https://launchpad.net/~peopledatalabs/+archive/ubuntu/ppa
<rick_h> bdx: https://launchpad.net/~peopledatalabs/+archive/ubuntu/ppa/+packages so that shows pending
<rick_h> with a failure?
<bdx> where?
<bdx> ooh
<bdx> I see
<rick_h> bdx: and still shows no packages "Number of packages:
<rick_h> 0 source packages (471.0 MiB)
<rick_h> 0 binary packages (4.7 MiB)"
<rick_h> bdx: yea, have to poke around the PPA/package details bits there
<rick_h> bdx: once they run there should be PPA build logs if you had them rebuilt vs just copied binaries
<rick_h> bdx: so maybe they're in the build queue, might take a little bit depending on how busy they are
<bdx> I see
<bdx> totally
<bdx> yeah ... I had them rebuilt when I copied them over, thinking it would be good thing to do
<bdx> possibly I can also try with just copying for the heck of it
<rick_h> yea
<rick_h> so have to just be patient and wait for a PPA builder to come along and try to build it
<rick_h> bdx: ok hover over the green gear icon for the first package
<rick_h> bdx: "all builds were built successfully but not yet published"
<rick_h> bdx: so it's not even the builders to wait on, but just the publish process which will build that releases file and you'll be off to the races
<bdx> I see, I see
 * rick_h has to run but will check in later if I can. Good luck!
<bdx> kk, thx
<gvseghbr> Hi, is there somebody who can help with bootstrapping a VMware controller?
<gvseghbr> On my system it fails when the bootstrap process wants to connect to the API
<bdx> rick_h: yeah man ... my fears were realized ... it was packaged for upstart
<bdx> :(
<bdx> rick_h: where I ended up athttp://paste.ubuntu.com/25480507/
<bdx> http://paste.ubuntu.com/25480507/
<bdx> looks like the collectd-exporter-prometheus.conf made it to /etc/init
<bdx> but thats about it
#juju 2017-09-07
<gaurangt> what's the procedure to delete a network space in juju?
<gaurangt> or can we move the subnet from one space to other?
<xarses_> is there a useful way to get a log of the actions a unit may have been performing at a specific time from the juju cli?
<rick_h> xarses_: not from the CLI. I guess you could look for action results that occurred around the timeline? but you'd need to check the logs to get specific
<rick_h> xarses_: turning on the audit log would make it cleaner/easier a bit but it's still in a log
<xarses_> urgh, too many signals to just sift in every damned log
<xarses_> on a related subject, is there a way to disable the local haproxy in the openstack api charms?
<xarses_> something is raising 503's on me randomly, and that guy has like no log
<xarses_> and I have a balancer elsewhere
<rick_h> xarses_: do you know what action you're looking for? I'm curious what the log | grep action might be or the name of the action
<xarses_> nope, no clue what so ever
<xarses_> we run (openstack) rally against the cloud to detect failures, and have noticed recently that we are getting random failures on endpoints that are nearly always 503's
<rick_h> xarses_: so not sure what's actually erroring in the stack?
<xarses_> but calls prior and after, that in many even include said api pass
<xarses_> yep, no clue what's causing the errors
<xarses_> oh, the one I'm looking at currently isn't 503, its 502 (incomplete or invalid response)
<xarses_> bad gateway
<xarses_> argh, found it
<xarses_> this thing, it ruffles my feathers soo much
<xarses_> something like this happens https://gist.github.com/xarses/5a7beb4cc856588c3f91ce0b094b4f28
<xarses_> and then anything to look at is SIGTERM and restarted
<xarses_> apache, npre, the python wsgi's
<xarses_> memcache
<xarses_> ugrh, so the systemd thing is probably just annoying
<xarses_> there is a session into the host before that, and then a bunch of things related to the charm reload, I'd guess that its the culprit as I originally suspected
<xarses_> so I'm back to, something in the charm allows for concurrent modification of members and ends up causing an outage
<xarses_> so `juju debug-log` doesn't seem to work
<xarses_> among it not having any logs for the units I'm looking for
<xarses_> --lines isn't respected
<xarses_> > juju debug-log --no-tail --include unit-percona-cluster-0 --lines=1 --replay | wc -l
<xarses_> > 4489
<xarses_> and the example in --help has a `-T` flag which doesn't exist
<skay> I just ran in to a VersionConflict with requests when trying to create a new charm using charmtools. https://paste.ubuntu.com/25486709/
<skay> grar
<thumper> xarses: hey
<thumper> xarses: which juju version?
<thumper> xarses: also, thanks for pointing out the -T problem, we'll get that fixed
<thumper> xarses: are you able to file a bug? if not we could add one
<xarses> 2.2
<xarses> probably 2.2.2
<xarses> we where updating some of the controllers not sure which that was on
<xarses> for which -T or the lines not being respected, or nothing from the unit im looking for?
<thumper> xarses: we did update the include option so you should just be able to specify the unit like normal, so 'percona-cluster/0'
<thumper> -T doesn't appear to be an option in the code
<thumper> I'm kinda surprised it isn't complaining
<xarses> oh, it complains of the invalid option
<thumper> oh, good
<xarses> its just in --help long description of examples
<thumper> yeah, that needs to be fixed
<thumper> also the examples should just specify the machine ids and unit ids rather than the unit- and machine- strings
<xarses> I was looking initially for unit-neutron-0, which has one entry in the uncompressed log file, it never gave that back
<xarses> also tried neutron/0
<thumper> ok...
<thumper> it is possible that there are lines in the local file that never make it to the server
<xarses> only switched to percona-cluster because it was spewing warnings and not respecting --lines
<thumper> for debug-log to pick up
<thumper> the local log files are written as things happen
<xarses> no there is one line in the /var/lib/juju thingy on the controller
<thumper> but debug-log only works on the logs that ended up in the controller
<thumper> oh...
<thumper> hmm...
<xarses> that grep found
<thumper> if it made it into logsink.log then it should be in the db
<thumper> unless it was removed due to pruning
<xarses> ya that one
<xarses> so long story with debug-log aside
<xarses> shouldn't it have logged actions like applying charm updates and restarting services?
<xarses> they wheren't logged on either the controller or the unit
<xarses> they don't emit a syslog
<xarses> and are driving my troubleshooting crazy
<thumper> you mean the charm actions?
<thumper> as in the charm is restarting an openstack service
<thumper> ?
<thumper> or the restarting of juju agents?
<xarses> well as in freaking out and causing an outage on all of my neutron (api) servers at the same time during a charm upgrade
<xarses> I can only prove my issue is due to the charm upgrade, because less than a minute prior memcached is started for the first time ever
<xarses> there are no other logs that I can find that show that juju intended to or was actively taking actions on the unit
<thumper> what is the logging config set to?
<xarses> who's config?
<thumper> juju model-config logging-config
<thumper> for the model in question
<xarses> looks like a default of warning
<thumper> in which case, you will only get told of things not working
<thumper> juju model-config logging-config=juju=info
<xarses_> $ juju model-config logging-config
<xarses_> <root>=WARNING;unit=WARNING
<thumper> juju model-config "logging-config=juju=info;unit=warning"
<thumper> xarses: that would then tell you more about what juju is doing for that model
<xarses> le sigh, google didn't give me any information like this about levels
<thumper> we are trying to make sure that INFO level logging is useful and not too verbose
<xarses_> all I could ever find was https://jujucharms.com/docs/2.2/troubleshooting-logs
<thumper> xarses: I'll make sure that we get the docs updated to talk about the log levels
<thumper> xarses: I'm going to relocate back home, should be back online in ~20 minutes
<xarses> k
<xarses> thanks this was insightful
#juju 2017-09-08
<xarses> so the remaining issue, is that I don't understand how to determine if the charm knew better than to bounce both nodes at the same time or not
<xarses> so the remaining issue, is that I don't understand how to determine if the charm knew better than to bounce both nodes at the same time or not
<magicaltrout> afternoon
<magicaltrout> can someone explain the k8s loadbalancer to me? :)
<magicaltrout> cause i look at the microbots example and that uses the xip.io dns service but doesn't seem to use the loadbalancer, but I'm failing to see how services are routed through it
<magicaltrout> when i say "explain" i just mean point me to some docs that reflect what is implemented here :)
<magicaltrout> oooh thats only apiserver distribution on ingress
<magicaltrout> i should read better
<tvansteenburgh> magicaltrout: i'm listening but i'm not sure what you're asking :P
<magicaltrout> hahah
<magicaltrout> i'm trying to rather badly it seems, figure out external routing for k8s services :)
<magicaltrout> i thought the load balancer provided it but that seems to be api call balancing
<tvansteenburgh> magicaltrout: have you read https://kubernetes.io/docs/concepts/services-networking/service/
<Dwellr> I'm using iptables to forward traffic to a worker node ip (because my worker nodes are on an ip range that conjure-up selected, that isn't routable in my network)
<tvansteenburgh> magicaltrout: the LoadBalancer can do it if your cloud supports it
<magicaltrout> interesting
<stokachu> Dwellr: juju config flannel and set the cidr
<stokachu> Dwellr: we're adding support to conjure-up to allow you to configure subordinate charms
<Dwellr> stokachu: I don't really have a cidr..
<magicaltrout> my confusion lies for example, with the microbots setup, you get a dns endpoint that points to the ip of a worker
<stokachu> Dwellr: maybe Cynerva has some additional best practices around that
<Dwellr> stokachu: Im running conjure up inside virtualbox, the virtualbox vm has a bridged adapter onto my house lan, and I'm using iptables to forward from the bridged adapter to the worker node..
<tvansteenburgh> stokachu: that's really only relevant to the cluster network
<Dwellr> stokachu: that lets me hit say, microbot, from other pcs on my house lan (provided I pass the fake host header so ingress routes the request etc) .. but I'm very much still learning =) if there's a better/cleaner way.. I'm all ears
<stokachu> ah ok
<tvansteenburgh> magicaltrout: right, so you it only works if you can route to the node ip
<stokachu> Dwellr: i think iptables is the way to go
<magicaltrout> yeah tvansteenburgh but also, if you stuck a real DNS entry against the node ip, if you tore it down and the service ended up on a different worker
<magicaltrout> you'd have a stale DNS entry for your users, right?
<tvansteenburgh> that's why you don't want to point dns directly at a node ip
<tvansteenburgh> you point at a Service ip
<tvansteenburgh> which *can* be provided by a LoadBalancer, but it can also be configured manually
<magicaltrout> haha, minds melting, i've lived in mesos land for too long
<tvansteenburgh> Service type can take an externalIP
<tvansteenburgh> magicaltrout: read that doc page from beginning to end - i bet you'll understand fine after that
<magicaltrout> hehe yeah i'm running through it thanks tvansteenburgh
<Dwellr> is there anyway for me to see what juju run-action kubernetes-worker/0 microbot replicas=x does? It's great that it's automated etc, but I want to peek at what it did =)
<magicaltrout> https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-worker/templates/microbot-example.yaml
<Dwellr> thanks =) more than handy =)
<Dwellr> and.. what's the simplest way to get my worker nodes to pull from a custom docker repo? I figure I can run docker back on my vm host, and have the workers pull from that repo, (and mebbe enable docker tls so then I can push to the vm from outside too)
 * Dwellr trying to get toward 'kube in a box' ;p where I can spin up the vm, and develop and deploy apps to it from outside the vm
<skay> why is the charm snap throwing this exception about one of my local python packages https://paste.ubuntu.com/25486709/
<tvansteenburgh> Dwellr: there's a registry action on the worker nodes
<Dwellr> whats a registry action, and how does that relate to my current understanding of a docker repository that I push my images to ?
<tvansteenburgh> Dwellr: an action is a Juju thing - think of it as a script that you can run on a unit
<tvansteenburgh> like, microbot is an action
<Dwellr> okie, so what does a registry action do ?
<tvansteenburgh> Dwellr: https://jujucharms.com/u/containers/kubernetes-worker/52
<tvansteenburgh> search page for registry
<magicaltrout> thanks tvansteenburgh that page was indeed very useful ;)
<Dwellr> oooh.. thanks =)
<cory_fu> skay: That is an issue with the classic snap and the reason we worked on moving to strictly confining the snap.  In fact, we *just* released the strictly confined snap a little while ago, so if you `snap refresh charm` and try again, it should be fixed
<tvansteenburgh> Dwellr: if you'd rather use Helm, there's a chart for a private registry here: https://github.com/madeden/charts/tree/master/docker-registry
<Dwellr> I'm still learning.. using conjure up as a way to spin up a slightly more complex kube deployment than minikube will, so I can play with what it means to deploy and run apps on kube etc
<tvansteenburgh> Dwellr: cool, no prob :)
<Dwellr> so I think the juju action for the registry will work
<Dwellr> I'm slowly building up a vagrantfile that builds my kube in a box =)
<skay> cory_fu: sweet! worked
<skay> cory_fu: (actually, I unstalled it and installed it from scratch. at first it didn't find any update)
<Dwellr> so far it installs conjure-up, uses it to install kube to localhost (interestingly using 'conjure-up kubernetes-core localhost' produces no output in vagrant until the command completes, which takes like 10mins or so)..
<stokachu> Dwellr: is this from vagrant ssh into the machine and running conjure-up?
<Dwellr> and then it copies the kube config, rewrites it to update the server address to the external bridged ip for the vbox vm, adds insecure-skip-tls-verify, and copies the config to the vagrant shared dir.
<cory_fu> skay: Odd about the refresh.  Maybe it auto-refreshed before you tried it.  Either way, glad it's working!
<stokachu> Dwellr: you may be able to get around the no output from conjure-up using `ssh -t` option
<Dwellr> stokachu: I mean when I have config.vm.provision : shell, privileged: false, :inline => <<-EOT
<Dwellr> conjure-up kubernetes-core localhost
<Dwellr> EOT
<tvansteenburgh> Dwellr: that sounds like a neat setup - you should write a blog post about it
<stokachu> Dwellr: stil could be ssh option
<Dwellr> that, when I run `vagrant up` and it runs the provisioning steps.. there's no output from the command until it completes
<stokachu> Dwellr: it's inline but i think vagrant has to ssh first
<Dwellr> Hmm.. wonder if passing -t is possible in the provision flags
<stokachu> Dwellr: try config.ssh.pty= true
<stokachu> in config.vm.provider
<stokachu> http://blog.medyagh.com/2014/07/fix-vagrant-error-sudo-sorry-you-must.html
<Dwellr> the vagrant file then goes on to setup ip forwarding for all nodeports (and 80 & 443) to the first worker ip, and 6443 to the master node ip from the bridged interface
<Dwellr> stokachu: I'll try that in a mo =)
<stokachu> cool
<tvansteenburgh> please publish this awesomesauce
<tvansteenburgh> Dwellr ^
<Dwellr> hmm the docs for config.ssh.pty say that "When pty is enabled, it is important to note that command output will not be streamed to the UI. Instead, the output will be delievered in full to the UI once the command has completed."
<stokachu> Dwellr: ah that's opposite what i was going for
<Dwellr> and thats kinda what I'm already seeing with the conjure-up command ;p
<stokachu> yea hmm
<Dwellr> tvansteenburgh: it will be published =) .. I'm doing this as a side project to create a dev env in a box for gameontext.org
<stokachu> Dwellr: though it's odd b/c ive used this option in jenkins ci runs
<stokachu> to see the output as it happens
<stokachu> i ran into the same issue until adding that
<Dwellr> I can always try =)
<stokachu> sure :)
<Dwellr> was also figuring I could pipe it thru tee or sommat
<stokachu> ah yea that may be another way
<xarses_> Is this right? The only way to export a model to import as a bundle is via the gui? https://jujucharms.com/docs/2.2/charms-bundles
<tvansteenburgh> xarses_: i think that's right yeah
<xarses_> =(
<xarses_> I don't have gui's attached to most of my controllers
<tvansteenburgh> xarses_: just run `juju gui` and you'll have one :)
<tvansteenburgh> you can do that to get the initial bundle and then just edit by hand from there
<tvansteenburgh> i think that's what most ppl do
<xarses_> ya, we don't use the gui around here
<tvansteenburgh> neither do i
<xarses_> wow, all the icons are missing
<tvansteenburgh> from the gui?
<xarses_> ya, it's showing the missing image icon
<tvansteenburgh> i blame hurricane Irma
<tvansteenburgh> xarses_: which charms?
<xarses_> openstack*, percona, ceph, nagios
<tvansteenburgh> xarses_: can you see this https://api.jujucharms.com/charmstore/v5/ceph/icon.svg
<xarses_> yes, but shouldn't it download these things and keep them with the charm?
<xarses_> also, we don't use charms directly from the store
 * tvansteenburgh looks around for a gui dev
<xarses_> uh, export button doesn't work
 * hatch waves to tvansteenburgh 
<tvansteenburgh> hatch: xarses_ is having some trouble with his gui
<tvansteenburgh> missing icons, export button not working
<tvansteenburgh> rotfl
<tvansteenburgh> nice one hatch
<hatch> lol
<hatch> sorry wrong key
<tvansteenburgh> hatch: xarses_ is having some trouble with his gui
<hatch> got that
<hatch> export
<hatch> and icons
<tvansteenburgh> yep
<hatch> ok xarses can you click the ? in the top right and head for the keyboard shortcuts to find out what version of the GUI you're using
<hatch> also, browser, and version of Juju
<hatch> oops xarses_ ^
<cory_fu> bdx: What do you think of the soft-launched layer-index repo vs the old micro-site?
<bdx> cory_fu: I've been waiting on this for a while now .... super excited
<bdx> cory_fu: it will make it easier for me to run a private registry for use in my charm ci/cd
<cory_fu> bdx: Excellent.  I know the PR workflow adds a slight barrier to entry to getting new layers registered, but I think it's still reasonable.
<bdx> totally, reasonable for sure. It also gives a central place users can subscribe to and more easily track the addition of new layers
<bdx> like, I want to know when new interfaces/layers are added to the registry
<bdx> this make it easy, you just follow the repo
<magicaltrout> just like to say
<magicaltrout> the new status button in juju gui
<magicaltrout> is epic
<xarses_> hatch how does the keyboard shortcuts page show version?
<xarses_> juju version is 2.2.2, browser is chrome 60.0.3
<xarses_> cli from `juju gui` implies its 2.4.2
<xarses_> > GUI 2.4.2 for model
<rick_h> xarses_: can you run juju upgrade-gui ? That's quite old.
<rick_h> xarses_: it should be 2.9.2
<rick_h> hmm, 2.4.2 is Feb release
<xarses_> ya, thats about when the controller was originally deployed
<xarses_> does it not upgrade with the controller?
<xarses_> well, export works now
<xarses_> icons are still broken
<Dwellr> hmm.. tried doing   conjure-up kubernetes-core localhost > mylogfile.txt   and the log file stays at 0 bytes until conjure up is done too
<xarses_> I'm guessing because they are all local charms
<rick_h> xarses_: k, icons are pulled based on the charm urls so they might get blocked.
<rick_h> xarses_: ok, if they're all local charms they're supposed to be pulled from the controller itself.
<rick_h> xarses_: can you open the browser debug tool and see if you can get an error for the icon urls? I imagine they're getting a 404 or something
<rick_h> xarses_: and file a bug on github.com/juju/juju-gui with the details ?
<rick_h> xarses_: and no, the gui is out of sync with juju itself. There's usually a release every month or so. Since it's not effecting the actual workings of Juju but UX fixes/etc it's on the side.
<xarses_> ahh, here is the bug, its trying to resolve the admin user and my model name for icons on api,jujucharms.com/charmstore/...
<rick_h> xarses_: :(
<xarses_> lemme sanitize
<xarses_> yep, raises a similar 404 message
<xarses_> https://api.jujucharms.com/charmstore/v5/~my-local-admin-user/my-local-model-name/meta/any?include=bundle-metadata&include=bundle-machine-count&include=charm-config&include=charm-metadata&include=charm-metrics&include=common-info&include=extra-info&include=id-revision&include=manifest&include=owner&include=published&include=resources&include=revision-info&include=stats&include=supported-series&include=tags
<rick_h> xarses_: yea, that's a bug-a-boo to fix. Apologies on that.
<xarses_> https://gist.github.com/xarses/4b1bea1bcdf8012737dee5f4f57ee7f3 the charms in the model for reference
<stokachu> Dwellr: boo :(
<xarses_> Dwellr: I found that I had to capture stderr in my pipe to catch most of the information during bootstrap, pass --debug flags and pipe to tee to get a useful looking log (mind you this was just with juju bootstrap)
<xarses_> rick_h: file a bug on LP?
<Dwellr> I'm having partial success doing    conjure-up &  then tail -f --pid=$! Â¬
<Dwellr> I'm having partial success doing    conjure-up &  then tail -f --pid=$! ~/.cache/conjure-up/conjure-up.log
<stokachu> Dwellr: nice
<stokachu> Oh I wonder
<Dwellr> gets me a log that updates as far as 'Executing script ... steps/00_deploy-done'
<Dwellr> but then it stops while juju status is showing the master/worker etc are still init'ing
<stokachu> Yea those logs are in the spell steps dir
<stokachu> Like 00-deploy_done.err
<stokachu> cory_fu: any idea why the output from headless install only prints out when it's completed?
<stokachu> This is from running it via vagrant up and even in our Jenkins runs it would do that
<stokachu> Dwellr: did you try that try setting yet?
<stokachu> TTY
<Dwellr> not yet.. apparently it's pretty strongly recommended against.. so leaving that as last resort
<stokachu> Ik
<stokachu> Ok
<cory_fu> stokachu: No idea.  I don't use vagrant often.
<stokachu> Dwellr: the only other thing I can think of is that we use terminal colors for the output
<Dwellr> so does apt-get update/install and that outputs ok during vagrant
<stokachu> Ah ok
<xarses_> rick_h: https://bugs.launchpad.net/juju-gui/+bug/1716037
<mup> Bug #1716037: gui fails to render local:charm icons  <juju-gui:New> <https://launchpad.net/bugs/1716037>
<stokachu> Dwellr: could vagrant only be printing a certain fd?
<Dwellr> well.. it wouldn't explain why conjure-up kubernetes-core localhost > mylog.log doesn't write anything into mylog.log until the process finishes..
<Dwellr> that's nothing to do with vagrant
<xarses_> Dwellr: does `2>&1` help ?
<cory_fu> stokachu: Maybe we could try adding flush=True to print() and cprint() in send_msg: https://github.com/conjure-up/conjure-up/blob/master/conjureup/utils.py#L248-L257
<stokachu> cory_fu: good idea
<cory_fu> stokachu: (flush=True docs: https://docs.python.org/3/library/functions.html#print)
<Dwellr> could I patch that in locally after installing conjure-up ?
<cory_fu> AFAICT, cprint() passes through args to print(), so it should work on either
<Dwellr> (happy to test if possible)
<stokachu> Dwellr: so you would need to checkout the source
<cory_fu> Yeah, I don't think you could patch the code in the snap
<stokachu> Dwellr: if you clone https://github.com/conjure-up/conjure-up
<stokachu> Dwellr: then run `make sysdeps; make dev`
<Dwellr> heh.. was hoping being python the source would be on my system somewhere
<stokachu> then you can . conjure-dev/bin/activate
<stokachu> and try it there
<cory_fu> Dwellr: It is, but bundled into the snap filesystem.  The confinement of snaps would make it challenging to modify
<Dwellr> yeah.. I know nothing re snaps =)
<cory_fu> Dwellr: Well, they essentially are a way to package, confine, and apply security to an application to make it safer and easier to manage.
<cory_fu> I think you'd have to be root to unpack and modify the bundled file system image and even then I think the signing of the snap might prevent it
<Dwellr> root simple, signing not.
<Dwellr> just paste your private key here in the channel, and i'll resign it ;p
<stokachu> lol
<stokachu> dont forget cc# and security code
<cory_fu> You could manage it, but in the end it's just easier to use the source from GitHub and either run the dev venv as stokachu suggested, or build the snap from that and install with --dangerous
<Dwellr> I'll need your visa number, 4 digit pin, and 3 digit verification code
<stokachu> lol
<Dwellr> rofl.. jinx
<cory_fu> :)
<stokachu> Dwellr: yea the source is quicker, especially if you dont want to build a new snap
<Dwellr> lemme clone my vagrant file, and have it stop before it does all the badness =)
<cory_fu> stokachu: I wonder if we could test using the output redirection that Dwellr mentioned.
 * Dwellr rather glad all this is running on his new dumpster-server ;p 
<Dwellr> sold as 'would not power on', I bought it just for the case (3u chenbro with 8x hotswap sata) .. turns out it powers on just fine (after adding some ram) .. it's a twin xeon e5530 server, (now) with 24gb per cpu,
<cory_fu> Nice
<cory_fu> stokachu: I'm seeing the same thing with redirection to a file
<Dwellr> total price (excluding ram/drives).. just under 50$
<cory_fu> Dwellr, stokachu: Yep, adding flush=True works
<Dwellr> cool =) how long before that can make it into a proper build?
<cory_fu> stokachu: I noticed that redirecting the output to a file still generates colored output.  I think "elif syss.__stdin__.isatty():" should actually be testing stdout, no?
<cory_fu> Dwellr: I think we could get it in --edge today.  I'm about to put up a PR now
<Dwellr> is that a flag for snap install ?
<rick_h> Dwellr: yes, it looks at the edge channel of the snap to get pre-release stuff.
<Dwellr> okie.. I can add that to the vagrant script quickly enough later then to test.
<xarses_> ergh, rick_h two new problems can't logout from the store now that I linked my user, and since I linked my user there isn't a button to switch back to the models, you just have to stay on the user ui or go hack the url
<xarses_> actually, 3 the linking the user didn't go to the proper redirect and authorize oauth page, it just selected an account
<rick_h> xarses_: k, will check it out. I just got the latest release yesterday and haven't tried the account page thing.
<rick_h> huh?
<rick_h> linking the user?
 * rick_h is lost on what xarses_ is up to
<xarses_> yes linking the juju user in the gui to the charmstore
<rick_h> k, /me is bootstrapping to see i can see what you see
<stokachu> cory_fu: nice
<stokachu> Dwellr: so basically when it's ready you would run `sudo snap install conjure-up --classic --edge`
<stokachu> or if already installed run `sudo snap refresh conjure-up --egde`
<xarses_> it should have raised an oauth authorize page, it just accepted the context I was in, instead of the oauth page making me confirm the app
<rick_h> xarses_: it's an openid vs oauth thing. It should open in a new window you can close once you auth (and think it says you can close it now)
<xarses_> and its now logged in to the wrong user, and I don't see a unlink button
<cory_fu> stokachu: https://github.com/conjure-up/conjure-up/pull/1148
<stokachu> cory_fu: thanks, ill merge and push to edge soon as it's done with ci
<cory_fu> stokachu: +1
<rick_h> xarses_: ok, so I just tried to replicate it and I logged into the charmstore and it shows at the top my two models on my controller (controller and default) and the list of charms and bundles from my charmstore account. I then clicked on the default model, and clicked manage to get back to the GUI
<rick_h> xarses_: it shows my username as "admin" on my profile page. I'm not sure what "wrong name" so any screenshots/etc would be helpful in looking at what went off the rails for you.
<rick_h> xarses_: bugs are tracked on GH at github.com/juju-juju-gui/issues
<xarses_> ya working on those
<xarses_> rick_h: for the oauth, I expected a dialog like https://drive.google.com/open?id=0B_Hn-o0wEGNfZHdLZmt4VTdYV1E
<xarses_> I got https://drive.google.com/open?id=0B_Hn-o0wEGNfUVR6aVNGOGNVOUE as the first page
<rick_h> xarses_: hmm, I think because the GUI doesn't request any of the account details it doesn't have that dialog
<rick_h> xarses_: you only have to give approval if the application asks for the details so it can restore it locally for any reason
<xarses_> I'd still expect the ask, its now linked to the wrong account because it just used the first cookie it found
<xarses_> oauth is supposed to be explicit in this regard, the oauth host isn't supposed to allow the app if the user doesn't allow it
<xarses_> with regards to the other issue https://drive.google.com/open?id=0B_Hn-o0wEGNfQ0Y0cmVwRUhEbDg
<rick_h> xarses_: as for logging back out you're right there's not a box there. The work-around for the moment would be to wipe the cookies and local storage on the browser for the api.jujucharms.com domain from the browser :(
<rick_h> xarses_: understand, it's not oauth atm but good feedback.
<xarses_> rick_h: I haven't even authorized that account for jujucharms.com either
<rick_h> xarses_: right so from there if you click on the model name you can click on "manage"
<rick_h> xarses_: right, you're butting up against how ubuntu sso works
<xarses_> and that its super broken for multiple accounts?
<rick_h> xarses_: notice nothing through ubuntu sso has that setup. I think you can wipe https://login.ubuntu.com/+applications and remove the web login? I'm not sure
<stokachu> Dwellr: it's building now, you can see the status here https://code.launchpad.net/~conjure-up/+snap/conjure-up
<rick_h> xarses_: so the user/etc is the local juju account. The charmstore login is kind of on the side and doesn't effect the juju "admin" account you logged into the GUI in any way
<stokachu> looks like it'll be at least 40 minutes before it starts
<stokachu> usually takes about 5 minutes to build
<xarses_> rick_h: ya, I get that but I can't log it out now, as its on the wrong usso account
<rick_h> xarses_: right, so that's why I said that it's a valid bug to not have a logout of charmstore button there, so you'd have to remove the localstorage/cookies from your browser atm apologies
<xarses_> k
<xarses_> oh, those expand? thats totally not obvious
<rick_h> xarses_: +1, the team's working on an updated profile page that groups things into more logical buckets and reworks that UX
<xarses_> the grouping is fine
<rick_h> xarses_: I hate the expandy-two-click stuff and it's not middle click to open in new tab friendly heh
<xarses_> just the layout didn't imply that they could expand
<xarses_> +2 to the middle click
<xarses_> I have to have a 3-5 button mouse
<xarses_> Idk how people live with out them
<rick_h> lol
<rick_h> xarses_: I get your point though after tinkering with this stuff. It just uses your current sso account vs allowing you to pick when you login
<xarses_> oh, you don't get to "pick" with the oauth ask from openstack.org either, it just gives you a chance to logout and log back in with the account you want it to use
<rick_h> xarses_: right
<xarses_> lp and oauth askers seem to be cool with my two accounts
<xarses_> these usso ones just pick the first one
<xarses_> which was fine for the force portal
<rick_h> xarses_: I've got a bug filed on the lack of the logout button but yea, I think there's some limitation on working with the login.ubuntu.com stuff. Will see
<xarses_> but is annoying me with the charm store
<rick_h> gotcha, sorry I didn't grasp what you meant at first. Because I have 2-fa it always stops up for me to 2fa but if you didn't have that it'll just dump right in.
<magicaltrout> ya'll trying the Ceph PV stuff in the CDK readme
<magicaltrout> and i get timeout expired waiting for volumes to attach/mount for pod "default"/"web". list of unattached/unmounted volume
<magicaltrout> not having used Ceph before, what am i missing or where should I prod?
<tvansteenburgh> magicaltrout: what's the output of kubectl get pv
<tvansteenburgh> and kubectl get pvc
<tvansteenburgh> magicaltrout: i gotta run, feel free to post on the ML or file an issue on the cdk repo
<magicaltrout> no worries ex-tim
<kwmonroe> magicaltrout: i don't have experience with ceph either, but if i were you, i'd swap that for something lighter, like hdfs.
<magicaltrout>  hmmm kwmonroe its like deja-vu
<magicaltrout> you're right though, i did
<magicaltrout>  /tmp
#juju 2017-09-09
<magicaltrout> jaas is great
<magicaltrout> until stuff stops responding :)
<bdx> rick_h: looks like you can just set arbitrary key=val to the extra-info, see http://paste.ubuntu.com/25498974/
<bdx> but can you unset it/remove it?
<bdx> here is the output piped to jq http://paste.ubuntu.com/25498983/
<bdx> looks like only the extra-info works with the `charm show` cmd
<bdx> ahh nice, looks like its flushed each time the charm revs
<bdx> nice
#juju 2017-09-10
<lounge-user55> heckles1: welcome to #juju
<bdxbdxbdx> heckles1: you made it!
<heckles1> that i did
<ybaumy> moin
<ybaumy> DocScrutinizer05: join us at #opensuse-de-chat
<bdx> this may be a silly question, why can't JAAS support all the providers?
<bdx> if your maas or openstack had public endpoints that JAAS could talk to, it would theoretically be possible right?
<rick_h> bdx: in theory yes
<bdx> rick_h: it probably isn't the best idea to have the agents talking to the controller over the wan though ... or is it?
<rick_h> bdx: yea, not a good idea. Between networking/egress complexity, having every hook fire event going over the wan, etc.
<bdx> yeah
<bdx> thats what I was thinking
<bdx> rick_h: how come `juju users` doesn't work in JAAS?
<bdx> is there another way to get the users in my model?
<rick_h> bdx: because it's SSO backed and doesn't list all users in SSO
<rick_h> bdx: juju show-model xxx
<bdx> oh niceee
<bdx> rick_h: thx
<bdx> rick_h: https://gist.github.com/jamesbeedy/eaca40c935ffc8c2cfaf0ca7e0f33d4d
<fallenour_> So
<fallenour_> who do I scream at for trying to force me to use ubuntu username only when I could ssh in as root?
<fallenour_> because that jackass has locked me out of my entire juju environment, and cost me 8 days of work
<fallenour_> Oh, and wiped out about 40 non profits entire infrastructure
<fallenour_> So fuck you *insert name here*
<fallenour_> Other than that, juju is fucking stellar
<fallenour_> Also, how do I upload my custom build xenial openstack build out? Id like to share that with the community, thankfully I have most of my work in yamls, its just a bitch waiting for it all to build out
<rick_h> fallenour_: not sure on the first one what you mean there. The ubuntu images used in cloud/lxd deployments and such are ubuntu which by default uses sudo and no root login. I'm guessing that conflicts with something you were expecting?
<rick_h> and for the second one, upload your custom xenial openstack build out, is that the bundle? ... oic you want to snapshot the images themselves to use as the deployment. Because the charms allow things to be mutable and respond to events/their environment the tricks to use custom images takes a bit of hackery and aren't fully supported
<rick_h> bdx: nice with the plugin :)
<fallenour_> ughhh
<fallenour_> so sad :(
<fallenour_> anyone know how to create a permanent bundle for juju charms store?
<rick_h> fallenour_: the easy way is to use the juju-gui export button to export the yaml. The you use the charm command to upload to the store. Let me get the docs link for you
<fallenour_> I got the charm yaml ready, I just need the guide if one exists
<fallenour_> shweeet!
<rick_h> fallenour_: https://jujucharms.com/docs/2.0/charms-bundles
<fallenour_> HAZAAH!
<fallenour_> time to add a couple hundred charm bundles
<fallenour_> seriously guys
<fallenour_> whats the deal with juju
<fallenour_> why does it need a machine for maas
<fallenour_> a machine for juju
<fallenour_> and then ANOTHER MACHINE for ANOTHER JUJU controller, when I already have juju installed?
<fallenour_> why do I have to waste 3 servers for this shit?
<fallenour_> conjure-up is seriously driving me insane
<stokachu> Why
<fallenour_> Why indeed @stokachu
<fallenour_> why cant it all deploy and manage from a single server, and then the juju enable-ha simply clone itself via maas to another box, and build another regional maas and juju for HA?
<fallenour_> why waste so much hardware on something that uses next to no resources whatsoever?
<stokachu> Sorry I meant conjure-up
<fallenour_> dhcp and IPMI pretty much anything over lan eats next to no ram, no cpu, and little bandwidth
<fallenour_> yea conjure-up
<fallenour_> and then it proceeds to grab anothe rbox for juju, a second one
<fallenour_> for 3 wasted servers
<fallenour_> and heaven forbid you are intereste din landscape, because that eats a 4th
<stokachu> So there is a architect button that will let you combine apps on same machine
<fallenour_> you might as well buy a damn rack just to test the stack
<fallenour_> no
<fallenour_> unfortunately not
<fallenour_> at this rate, I might as well point my ukranian team at rebuilding all of canonical stack
<fallenour_> im half tempted to ask them on twitter if they hired Microsoft Teams after the lay offs with all the hardware they are wasting
<fallenour_> If I wanted to blow this much resources on wasted hardware, I would have installed vSphere from the get go with NetApp
<stokachu> Well it is Sunday here and I'm working on some no related canonical stuff but will be willing to help later today
<stokachu> Yea I get it you're upset
<stokachu> I'll try to help as best I can
<fallenour_> Its not that im upset, I can afford the wasted hardware
<fallenour_> My issue isnt me, my issue is non-profits, and other less well off individuals and companies
<fallenour_> they cant
<stokachu> Right well we don't want you wasti g hardware
<fallenour_> Is it possible to put maas and juju all on one system?
<fallenour_> I know the official guide says 2 systems
<stokachu> In a sense you can start a KVM instance on the maas machine
<stokachu> Use that as the juju controller
<fallenour_> but Ive monitored the resource util,a nd even on older Dell r610s, the util even with deploying an entire rack at a time is less than 50%
<fallenour_> yea I figured that much, but why cant I simply just do conjure-up --boostrap-to localhost ?
<fallenour_> and install conjure-up on maas?
<stokachu> Just the way juju works
<fallenour_> if its going to do a loopback to a local host, itll just hit itself at http://localhost:5240/MAAS instead
<fallenour_> I know thats how juju works that way, but why?
<stokachu> I can help you more later when I'm back in the office tonight
<stokachu> Just the way juju works
<fallenour_> was there ever an rfc done for it?
<stokachu> Don't think so
<fallenour_> shame. I wouldnt mind helping contribute code cycles to get it to work, I know it can, we all do, but I feel theres something else that wasnt released or noted thats the reason why. Do you have any ideas?
<stokachu> Sorry I don't, but if you give me a little time today I'll be back in the office to assist more
<fallenour_> I think i just hit the jackpot of all ideas
<fallenour_> o.o
<fallenour_> Ok so stay with me
<fallenour_> LXD container autodeployed with MAAS, with a juju container
<fallenour_> python installer to auto deploy a ha pair to another box via juju via maas, localhost > remote host
<fallenour_> it deploys HA, then builds out openstack standard via conjure-up + relevant options
<fallenour_> minimal changes to the config guides as well
#juju 2018-09-03
<veebers> anastasiamac: can do :-)
<veebers> anastasiamac: LGTM
<veebers> wallyworld: I'm seeing "agent lost, see 'juju show-status-log mariadb/0'" you mentioned this last week but I can't recall the context. Is this something that's new, I wasn't seeing it earlier (before I rebased develop onto my branch)
<wallyworld> veebers: the new presence implementation break k8s status. it's something i need to fix
<veebers> wallyworld: ack, ok that makes sense that I'm seeing it then :-) As long as I know the reason I'm comfortable that I'm sane (ish)
<veebers> wallyworld: in other news: https://pastebin.canonical.com/p/tWCjdgMCH7/ (re: units being terminated)
<wallyworld> veebers: good, so that means we don't need to explicitly set the status in the api facade
<veebers> indeed
<hloeung> is it safe to upgrade juju from 2.3.8 to 2.4.3?
<anastasiamac> wow, so provisioner unit tests now started failing as frequently as 1 out 4 times... working thru these
<anastasiamac> hloeung: fwiw, yes it should be safe. if u know otherwise, please let us know :)
<hloeung> ok, will let you know when I get to upgrading our CI environment. Thnaks
<thumper> hloeung: there are no known issues upgrading from 2.3.8 to 2.4.3
<hloeung> ack, thanks
<thumper> babbageclunk: is your recent fix for the sometimes timeout with the raft worker test?
<veebers> wallyworld: I'm confused, I'm trying to deploy cs:~wallyworld/caas-mariadb (without doing the 'juju trust aws-integrator' step to create an error). With "kubectl -n message log -f juju-operator-mariadb-744bb855-vtvbd" I see no complaints; with juju debug-log -m controller I see "ERROR juju.worker.dependency "caas-unit-provisioner" manifold worker returned unexpected error: resource name may not be empty" every
<veebers> 4 seconds. I must be missing something obvious
<wallyworld> veebers: did you use the --storage deply arg?
<wallyworld> the way it is erroring is a bug also
<veebers> wallyworld: aye, "ERROR juju.worker.dependency "caas-unit-provisioner" manifold worker returned unexpected error: resource name may not be empty"
<veebers> sorry, juju deploy cs:~wallyworld/mariadb-k8s --storage database=10M,k8s-ebs
<wallyworld> did you create the storage pool?
<wallyworld> juju create-storage-pool k8s-ebs kubernetes storage-class=juju-ebs storage-provisioner=kubernetes.io/aws-ebs parameters.type=gp2
<veebers> yep, as per discourse post
<wallyworld> maybe there's a bug if oeprator storage is missing
<wallyworld> juju create-storage-pool operator-storage kubernetes storage-class=juju-operator-storage storage-provisioner=kubernetes.io/aws-ebs parameters.type=gp2
<veebers> wallyworld: I'll run that now?
<wallyworld> yeah
 * veebers makes it so
<wallyworld> you may need to deploy a new app though
<veebers> ah, ack
<wallyworld> but i expect it should work
<wallyworld> it should bounce the worker and read the nre storage ppol info
<wallyworld> *new
<veebers> I'm trying a new deploy, was still sing the manifold errors in logs every 4sec
 * anastasiamac imagines veebers singing errors
<anastasiamac> like a snake charmer
<veebers> ugh, I'm seeing "Warning  FailedScheduling  6s (x8 over 1m)  default-scheduler  pod has unbound PersistentVolumeClaims" for the new deploy, but that's not reflected in juju status.  it's not getting pushed through the cloud container status properly it seems
<veebers> anastasiamac: hah ^_^
<thumper> anastasiamac: I'm looking at another intermittent test failure
<thumper> and I think I have worked out the race in that...
<thumper> it may be similar to yours...
<thumper> I'm thinking through a solution
<anastasiamac> thumper: which test and what race?
 * thumper dabbles
<anastasiamac> thumper: mine seems to be all in provisioner_task
<thumper> http://10.125.0.203:8080/view/Unit%20tests/job/RunUnittests-s390x/lastCompletedBuild/testReport/github/com_juju_juju_apiserver_facades_client_client/TestPackage/
<thumper> FAIL: client_test.go:762: clientSuite.TestClientWatchAllAdminPermission
<thumper> the fundamental problem is the test goes:
<thumper> do something
<thumper> do something
<thumper> start watcher
<thumper> expect X changes
<thumper> there is the expectation that the second do something had been processed before the watcher started
<thumper> so there is a race there
<anastasiamac> thumper: oh k... i hope it similar to mine...
<thumper> there is another bug... and a kinda bug one...
<anastasiamac> thumper: m owrking at the moment at "start controller machine, start another machine, remove 1 machine... oooh... both machines removed"...
<thumper> related to CMR
<anastasiamac> so mayb our failures are similar but mayb not...
<anastasiamac> ouch, cmr bugs are scary :)
<thumper> that I'm not sure whether it has real world impact or not
 * anastasiamac looks in directoin of FTP and wallyworld :D
<wallyworld> huh?
<anastasiamac> wallyworld: nothing
<anastasiamac> thumper and i are having fun with watcher intermittent test failures :D ignore me
<thumper> wallyworld: the multiwatcher interaction with CMR is questionable
<wallyworld> multiwatcher does report on reote apps
<thumper> yes, but it seems more by good luck
<thumper> wallyworld: did you want to chat about caas presence at some stage?
<wallyworld> nah, fixed it
<wallyworld> just testing
<veebers> sigh, I almost tried to put my glass of water in my pocket so I could carry my muesli bar back to the office :-|
<anastasiamac> veebers: it does get better... at least it was not a hot drink like coffee or tea
<veebers> hah ^_^ true that
<wallyworld> thumper: fyi, the prsence fix https://github.com/juju/juju/pull/9150
<anastasiamac> thumper: https://github.com/juju/juju/pull/9151 (one test fix) ... m chasing the 2nd one
<anastasiamac> turns out we r just way too efficient now sometimes
 * thumper looks at both
<thumper> I'm testing a fix for mine too
<thumper> anastasiamac: I think my fix would be more appropriate
<thumper> anastasiamac: I think yours is adjusting the timing by side-effect
<thumper> the start sync method doesn't do any syncing with the underlying txn watcher
 * thumper sighs
<thumper> mine just failed too
<thumper> FFS
<thumper> I made the race much smaller... but it is still there
 * thumper thinks some more
<thumper> testing async code is hard...
<anastasiamac> thumper: k, m chasing the 2nd failure... m sure that the 1st failure is not t=with code but with test setup..
<anastasiamac> thumper: hence, the sync felt appropriate
<thumper> the StartSync doesn't do anything for the JujuConnSuite
<thumper> except poking the presence worker
 * thumper thinks 
<thumper> and something else
 * thumper goes to look at the something else
<anastasiamac> thumper: k
<thumper> pingBatcher
<anastasiamac> thumper: what about it?
<thumper> that is the other thing StartSync pokes
<thumper> presenceWatcher and pingBatcher
<thumper> nothing to do with the normal watchers
<anastasiamac> thumper: right. so the first failure was becase we were creating a machine, setting harvest mode and removing in hopes that harvest mode will b respected... occasionally, and now more often, harvest mode was not set when we came to remove... hence we failed...
 * thumper nods
<anastasiamac> thumper: as soon as sync was addeed before removal, the failure disappeared
<thumper> but that was just due to a change in timing
<thumper> if you added sleep 10ms it would probably do the same
<thumper> we work really hard to have workers work asynchronously
<thumper> then want control in tests
<anastasiamac> thumper: k... can we ho?
<thumper> sure
<veebers> wallyworld, kelvinliu__ : any idea what might cause the error; pod has unbound PersistentVolumeClaims?
<wallyworld> if the underlying volume cannot be created
<veebers> wallyworld: ok, so I did create-storage-pool, is it likely something aws related? Perhaps previously storage bits wheren't cleaned up?
<wallyworld> new volumes are created on demand
<wallyworld> did you deploy the aws-integrator?
<wallyworld> and used juju trust?
<wallyworld> kubectl get all,pv,pvc
<wallyworld> will show status of volumes and claims
<kelvinliu__> veebers, Is the aws-integrator/0 in active status?
<veebers> wallyworld: ah hah right, no I didn't do the juju trust part. So this is the failure I was expecting to see right?
<wallyworld> yup
<wallyworld> that's what should be surfaced in juju status
<veebers> wallyworld: ok cool. I'm not seeing it surfaced, need to debug why
<wallyworld> veebers: fyi, "lost" status fix just landed
<veebers> wallyworld:  yay, thanks!
<veebers> gah, why is "Running machine config. script" taking so damn long in aws/ap-southeast-1. It would be quicker to deploy locally in lxd :-|
<veebers> wallyworld (sorry to pester) Am I reading this right in that the storage error is stopping the operator pod from being deployed and thus the updateStateUnits et. al won't be in operation? (https://pastebin.canonical.com/p/rQrDsx7KRM/)
<wallyworld> yes, that's right. but you should be able to deploy the operator without any storage unless there's a bug
<wallyworld> if there is a bug and the operator does need storage, you could always create the mariadb storage pool with a dud provisioner
<wallyworld> that should induce an error in deploying the mariadb unit
<veebers> wallyworld: hmm, so I had created both operator-storage and k8s-ebs before deploying mariadb (still without having run juju trust for the k8s cluster)
<wallyworld> when you run juju trust the storage will come good and thing will provision
<wallyworld> so you can create a new different storage pool with a dud provisioner
<veebers> wallyworld: right, but the intention is to be able to surface the fact that the storage is borked right?
<wallyworld> and deploy a new mariadb with an alias usng that dud pool
<veebers> ah shoot I also (somehow) misspelled the image path (caas-operator-image-path=veebers/caas-operator...) :-\
<wallyworld> that would explain things a bit
<wallyworld> you shouldn't need to create a storage ool for the operator
<wallyworld> hence you can leave off the trust step
<wallyworld> and the operator will deploy
<veebers> but, it's not trying to install that as far as I can tell. At anyrate I'll fix that and re-deploy
<wallyworld> and the app itself will fail;
<veebers> ack
<veebers> argh its still complaining about storage with the proper image url
<veebers> wallyworld: does that suggest a bug where juju is putting storage constraints on the operator pod that shouldn't be there?
<wallyworld> i'd have to see the error. but you can deploy the operator with storage and posion the app storage pool to get by
<veebers> wallyworld: deploy op with storage as in run 'juju trust aws-integrator'?
<wallyworld> yeah
<veebers> ack ok cheers
<wallyworld> just set up the mariadb storage pool with a typo in the provioner attribute
<veebers> ah right, ack will do
<veebers> I've just enabled trust, waiting for the scheduling to succeed
<stickupkid> jam: I just want to ammend some stuff in here, before we merge https://github.com/juju/juju/pull/9148#
<jam> stickupkid: sorry about that, I had 2 PR up, and accidentally submitted the wrong one
<stickupkid> jam: haha, you can merge away now :p
<manadart> Need a review: https://github.com/juju/juju/pull/9153
<manadart> Small change, with easy Q/A.
<stickupkid> manadart: looking
<manadart> stickupkid: Ta.
<stickupkid> manadart: done
<manadart> Cheers.
<manadart> stickupkid: As discussed - https://github.com/juju/juju/pull/9155
<stickupkid> manadart: nice, will have a look now
<wallyworld> babbageclunk: have you tried bootstrapping lately?
<babbageclunk> wallyworld: not todat
<babbageclunk> y
<babbageclunk> wallyworld: y?
<wallyworld> since late yesterday it's hung for m
<wallyworld> e
<wallyworld> just wondering if it's just me
<veebers> wallyworld: in aws I see "Running machine config. script" take *ages*
<wallyworld> for me on aws or lxd it just hangs at that point
<babbageclunk> wallyworld: ok, having a go myself after pushing this change.
<wallyworld> ok, let's see how it goes
<veebers> wallyworld, babbageclunk: I got a successful bootstrap, took almost 40 minutes
<babbageclunk> crazy
<wallyworld> there's got to be something that's changed. it could be slow apt get of image updates or mongo or something
<veebers> maybe cloud-init taking a while when it's apt installing?
<veebers> heh
<thumper> wallyworld: I've worked out this bug, but would like to talk to if you have a chance
<wallyworld> sure, give me 5
<wallyworld> otp
<thumper> ack
<thumper> wallyworld: actually, never mind
<wallyworld> thumper: sorry, still in 1:1
<babbageclunk> wallyworld: bootstrap was about normal speed for me
<wallyworld> damn ok
<veebers> babbageclunk: where were you bootstrapping to?
<veebers> into? at? into probably
<babbageclunk> veebers: localhost.
<babbageclunk> I'll try aws
<babbageclunk> ooh, meeting
<thumper> wallyworld: this one is for you https://github.com/juju/juju/pull/9156
<wallyworld> ok, will look after standup
<veebers> babbageclunk: which region did you bootstrap aws? I'm using ap-southeast-1
<babbageclunk> I used ap-southeast-2
<wallyworld> thumper: lgtm, nice pickup
<thumper> wallyworld: took me a while because I had the assumption that the initial state was wrong and we weren't waiting
<wallyworld> seems obvious now
<thumper> but it was initial state was right, and subsequent update fubared it
<wallyworld> alays is after the fact
<thumper> sure is
#juju 2018-09-04
<veebers> wallyworld: any joy finding what's making bootstrap suck atm?
<wallyworld> it's getting hung setting up the agent config, not sure why yet
<veebers> ugh, hopefully it'll become apparent
<wallyworld> veebers: ah, in my case it was my own fault. i had introduced a lock conflict, hence the hang
<veebers> wallyworld: oh, so no idea why mines taking *ages*. might try a different region for now
<wallyworld> it's probaby the apt updates
<anastasiamac> veebers: unless it true style this is the case of 'great minds think alike'...
<anastasiamac> in*
<thumper> veebers: ping
<veebers> thumper: pong, what's the haps?
<thumper> veebers: http://ci.jujucharms.com/job/github-merge-juju/1072/consoleFull
 * veebers looks
<thumper> veebers: last two jobs have been killed from the outside
<veebers> thumper: it says it was aborted by user 'developer'
<thumper> ah
<thumper> I love this test failure line:
<thumper>     c.Assert(sInfo.Since, gc.NotNil) // TODO(dfc) WTF does this check do ? separation of concerns much
<thumper> mine failed with that
<thumper> I thought I had fixed the intermittent all watcher tests already
<veebers> thumper: when you say "yours failed with that" you mean the 2 jobs you linked me just now?
<thumper> no, the one I linked was anastasiamac's
<thumper> mine was the job after that
<thumper> I saw that failure in someone else's merge job too
<thumper> I'll look at it after this interview
<veebers> ah ok, it's possibly that anastasiamac aborted those 2 jobs on purpose (well, I hope so otherwise someone else is doing it)
<anastasiamac> yes, i have aborted on purpose coz i saw failures
<babbageclunk> thumper: have you got a moment?
<thumper> babbageclunk: yeah, but I may lose power soon briefly
<thumper> electrician in the power box
<thumper> whazzup?
<babbageclunk> in 1:1?
<thumper> sure
<veebers> huh, I saw this locally, perhaps it's not connectivity in the labs: grouped write of manifest, lock and vendor: error while writing out vendor tree: failed to write dep tree: failed to export golang.org/x/time: unable to deduce repository and source type for "golang.org/x/time": unable to read metadata: go-import metadata not found
<veebers> wallyworld: if I deploy cs:~wallyworld/mariadb-k8s without any --storage args, should it succeed? (without any storage bits etc.) At the mom I'm getting a manifold worker error complaining about not being able to create persistent storage
<wallyworld> veebers: no
<wallyworld> the charm declares it needs storage in its metadata.yaml
<veebers> wallyworld: ok, if failure is expected that is ok. How do I fix the deploy if I missed the --storage bit off the original deploy command?
<veebers> oh, should it have errored at the deploy command stage?
<wallyworld> delete the app and start again
<wallyworld> it depends if the metadata said 1+
<wallyworld> if the metadata didn't say one or more then juju won't count that as an error
<wallyworld> without storage args you may have expected it to work, just with ephemeral storage. that should probably be fixed. but it really makes no sense to allow that for prod
<veebers> wallyworld: ack ok, thanks for clarifying
<wallyworld> it's a bit rough atm
<wallyworld> needs polish
<veebers> wallyworld: ack, we'll get it polished!
<thumper> babbageclunk: fixed one, broke 20
<thumper> well 5
<thumper> FFS
 * thumper calls it a day
<Ablu> Hi, does anyone have an idea regarding my question from the weekend?:
<Ablu> I try to create a "manual" cloud and then add a machine which actually is a docker container. However, after the add-machine exits the machine is stuck in pending and I also do not see any process running within the docker container... Are there any specific requirements regarding how the machine which is about to be added needs to be configured? (https://docs.jujucharms.com/2.4/en/clouds-manual does not help a lot as soon things
<Ablu> go wrong unfortunately)
<stickupkid> Ablu: what's running in the docker container?
<Ablu> stickupkid: only sshd and the shell i use for inspection after the add was successful
<manadart> Ablu: Juju needs to run agents in the machine.  It assumes there is an init system running. Any reason not to use LXD?
<stickupkid> You could run ubuntu image, but then you'd have to wonder how you could keep it not from restarting, because it's not got any INIT running and the container will "exit"
<Ablu> manadart: I want to set specific networking and resource limiting on the container (it is part of a larger emulation framework) and I am looking for ways to do this with juju charms which are used in the software which should be "emulated". But the init system is a good hint. Thanks for that.
<Ablu> stickupkid: I currently use a ubuntu + SSHD, but it probably lacks an init system, thus the restart maybe fails.
<Ablu> While on it: If you have better suggestions how I might be able to set IP namespaces with custom links, resource restrictions on juju maintained machines (ideally before any code is executed in the machine) feel free to tell me :). The framework I use can already do this for Docker, so if I can get juju to use "machines" which I already started "manually" with the right configuration I could do all that :)
<manadart> Ablu: You might be interested in the CAAS support (Kubernetes) that is maturing in edge, see https://discourse.jujucharms.com/t/getting-started/152 and other posts in the category.
<Ablu> manadart: hm, that looks like it would start the services in a k8s cluster. Where would I be able to set my own constraints before the container actually goes live?
<manadart> Ablu: The ones actively working on the feature can shed more light on that than I.
<manadart> They are Australian east coast, so EoD. I suggest asking a question on Discourse. They will attend to it smartly if not around here.
<Ablu> manadart: Ok. Thanks for the info! I will try to explain my problem in a bit greater detail and do a post.
<manadart> Ablu: Sure thing.
<jam> stickupkid: should a negative size be capped at 0 or just treated as error ?
<jam> stickupkid: I'm now thinking Error
<stickupkid> jam: I would agree, a silent 0 could mask more issues
<stickupkid> hml: any chance of a HO?
<hml> stickupkid: sure, standup?
<hml> stickupkid: if itâs free
<stickupkid> yeap
<manadart> externalreality_: Pushed the mods we discussed to https://github.com/juju/juju/pull/9157 .
<externalreality_> manadart, ack
<externalreality_> will take a look, give me 15 to make my way to the buss
<manadart> externalreality_: No rush on my account. Wrapping it up for the day.
<externalreality_> manadart, ack
<hml> anyone up for a 1 char PR?  :-D  https://github.com/juju/juju/pull/9160
<veebers> Morning o/
#juju 2018-09-05
<veebers> wallyworld: so for mariadb (and probably mysql, maybe gitlab?) we're proposing the charm does this instead: http://paste.ubuntu.com/p/NBrGSTyMxy/ (re: cloud container status)
<wallyworld> pretty much except the message is wrong
<veebers> wallyworld: oh oops, got lazy. Yeah will update message too
<veebers> heh 'got' lazy, more like remained lazt
<wallyworld> but yeah, i think that will work
<thumper> wallyworld, veebers, kelvinliu__: http://10.125.0.203:8080/view/Unit%20tests/job/RunUnittests-amd64/859/console
<thumper> not sure what is causing that issue
<wallyworld> thumper: the jenkins job needs to have a make arg ste to not do the dep thing twice
<kelvinliu_> veebers, is it related with warning: unable to access '/home/ubuntu/.config/git/ignore': Permission denied
<kelvinliu_>  ?
<wallyworld> i fixed it last week but seems it got reverted
<thumper> wallyworld: I think this is different isn't it?
<wallyworld> it's running make build followed by make check
<wallyworld> both do the dep thing
<wallyworld> only the first one needs to
<wallyworld> I previously added JUJU_SKIP_DEP=true along wit the VERBOSE=1 arg to malke
 * veebers looking
<veebers> thumper, wallyworld, kelvinliu_ this rings a bell. I'm sure I put a fix in for this; let me double check (to do with "make lxd-setup" on an empty system)
<wallyworld> veebers: i just edited the job
<wallyworld> the RUnUnitTests job itself
<veebers> wallyworld: ack, what change?
<wallyworld> the same one i added last week
<wallyworld> JUJU_SKIP_DEP=true
<veebers> wallyworld: ah, you didn't add that to the yaml config so it'll survive a redeploy?
<wallyworld> the make check coommand needed that dded
<wallyworld> that i didn't know about
<wallyworld> i edited several job yamls whichj looked similar but were not the same
<wallyworld> so i didn't realise we had a template
<veebers> wallyworld: all jenkins jobs are configured via jenkins job builder, no changes made via the web ui are guaranteed to last at all (any redploy will overwrite)
<veebers> wallyworld: I see your change, I have that stuff open and setup, I'll make the change in the yaml now so it persists
<wallyworld> tyvm
<veebers> wallyworld: FYI all RunUnittests-* job has been updated to skip deps on check
<wallyworld> gr8
<anastasiamac> wallyworld: do u have another min? i *think* i know what m seeing but m not sure i know the solution
<wallyworld> ok
<anastasiamac> and m sure someone (probably u) have come up with solution
<anastasiamac> mobile k?
<wallyworld> ok
<veebers> sigh, my test error is because I said one thing out loud but typed the opposite
<wallyworld> kelvinliu_: sadly, ebs volumes do not support ReadWriteMany, so the idea of sharing a single PV for each operator can't easily work
<kelvinliu_> wallyworld, that's annoying!
<wallyworld> yeah, back to square one
<kelvinliu_> wallyworld, how about DaemonSet
<wallyworld> not sure, will have to look
<wallyworld> veebers: btw, i just confirmed you can deploy an operator without storage so no idea why you had issues yesterday
<veebers> wallyworld: ugh :-| I'll try again later, but it's not blocking me right now. Perhaps I'm doing something different/unexpected (doubt it though)
<wallyworld> no rush
<wallyworld> kelvinliu_: i think AWS EFS is worth looking at instead
<veebers> wallyworld: you have a couple moments?
<wallyworld> ok
<veebers> wallyworld: HO ok? would be quicker
<wallyworld> ok
<veebers> see you in standup
<veebers> wallyworld: Pushed updates to https://github.com/juju/juju/pull/9081 for when you have a moment
<wallyworld> ok, almost done in meeting
<wallyworld> veebers: there's still an outstanding todo item to not ignore getting container status
<veebers> wallyworld: err, is that in state/unit.go? /me checks for todo
<wallyworld> state/status.go
<wallyworld> and also a blocvk of code to be deleted
<veebers> wallyworld: I'm not following with that todo comment, something from your previous review?
<wallyworld> yeah, there's comments that have not been addressed
<veebers> wallyworld: oh wow, yeah I didn't see those comments until I went to the /files url, I just saw what was on the root page for the PR. taking a look now, sorry
<wallyworld> no worries
<wallyworld> veebers: sorry, a left a few more also
<veebers> wallyworld: if I 'resolve conversation' do you get an email?
<wallyworld> maybe, but reviews emails are filtered so i may miss them sometimes
<veebers> ack, no I was hoping you wouldn't so I could tick them off without spamming you
<wallyworld> :-) hence the fil;ter
<veebers> wallyworld: should I add a SetCloudContainerStatus(...) and CloudContainerStatus() to Unit? Set.. instead of update ops, and CloudContainerStatus() so I can check the status (I take it TestCloudContainerStatus doesn't cover what you expected)
<wallyworld> veebers: i think we have a SetAgentStatus already?
<veebers> wallyworld: but that doesn't set the cloud container status?
<wallyworld> sure, was just wanting to see what we had
<veebers> ah, aye
<wallyworld> veebers: we have this func (u *UnitAgent) SetStatus
<wallyworld> so we'd needsomething similar for cloud container i would think
<veebers> wallyworld: ack, I can make that happen
<wallyworld> veebers: there is a StatusSetting and StatusGetter interface which are used in places; that's why the status methods exist like that
<stickupkid> question: when we deploy, do we know before hand what the provider is in the deploy stage?
<stickupkid> jam: you may know?
<jam> stickupkid: we generally want to not couple what you can deploy with what the provider is, so we *might* but I would be hesitant to expose that.
<jam> stickupkid: its Juju's job to abstract the provider, so the charms don't have to know about everywhere they might be deployed.
<stickupkid> jam: I'm looking at the lxd profile stuff, with the idea of having a lxd profile for the charm, but I don't want to validate the profile if it's not hitting lxd
<stickupkid> jam: my only option then is to validate when deploying via the agent (if that's the right terminology?)
<stickupkid> jam: offically we want to validate early so we can tell users early on, but then to do so we break abstraction rules - which 100% agree with by the way
<jam> stickupkid: lxd profile isn't about the lxd provider
<jam> stickupkid: it is actually about "juju deploy charm --to lxd:1"
<jam> stickupkid: so it applies to all providers
<stickupkid> jam: quick HO?
<jam> give me a sec to make coffee, and sure
<jam> stickupkid: I'm joining the guild ho now
<rick_h_> manadart: heads up, had the call with the openstack folks last night and had more promising test results. The updates with the agent work was helpful with things post-reboot so <3
<hml> anyone know why juju uses two version of charmrepo?
<stickupkid> hml: I didn't have a look properly yesterday either, but that's one of my questions as well
<hml> stickupkid: it looks like by v3 and v4 are both being updatedâ¦ and juju uses v2 and v3.  :-)
<hml> stickupkid: maybe weâre not using v2, just didnât take it out of the deps?
<stickupkid> hml: looks like it
<hml> stickupkid: iâm looking at removing it
<stickupkid> hml: sounds good to me
<cory_fu> rick_h_: Do you know if there's a way for a charm to determine what region it's running in, specifically on OpenStack?
<rick_h_> cory_fu: not that I know of.
<cory_fu> rick_h_: Though ideally in a cloud-agnostic way.  I know there's JUJU_AVAILABILITY_ZONE, but that's different from the region (though it might contain it, in some fashion)
<cory_fu> rick_h_: Hrm.  That's annoying.  Why do we have JUJU_A_Z but not JUJU_REGION?
<rick_h_> cory_fu: so I think that we want units to be able to make sure they're spread across the AZ in a region
<rick_h_> cory_fu: but not sure on what the charm would do different based on a region since it's agnostic
<rick_h_> cory_fu: and you can't deploy the same app across regions and have any logic around that
<rick_h_> cory_fu: what are you trying to do?
<cory_fu> rick_h_: This is specifically for the integrator charm, and one of the things that k8s needs from it is to know what region it's running in.
<cory_fu> rick_h_: If it comes down to it, the integrator charm could query it from the OpenStack API, but that adds back in a lot of complexity that we had removed for other reasons
<rick_h_> cory_fu: looking, is there a method to find it given the current info on the instance it's running on?
<rick_h_> cory_fu: understand
<cory_fu> rick_h_: I don't think OpenStack has something like the metadata service that most clouds support that would allow it to be queried easily, or else k8s wouldn't need us to provide it
<rick_h_> cory_fu: I see
<rick_h_> cory_fu: have you dumped out the env in the hook context?
<cory_fu> Yeah.  it's not there
<cory_fu> rick_h_: Oh, I'm wrong: https://docs.openstack.org/nova/latest/user/metadata-service.html
<rick_h_> cory_fu: k, yea I see some stuff with OS_REGION_NAME but it's on the client side for setting up your credentials
<rick_h_> cory_fu: I'd be curious if there's any region related info in the credentials you get via trust
<rick_h_> cory_fu: but it might be a list...still looking
<cory_fu> rick_h_: There might be region info in the trust creds, but the charm also supports creds via config.  But you said on OpenStack there's actually an OS_REGION_NAME?  I could probably use that
<rick_h_> cory_fu: so I see that showing up in the credential adding code such that if you have that env var set juju reads it in, does some detection, etc.
<rick_h_> cory_fu: so it might end up as part of the creds data but possibly not all the time
<cory_fu> rick_h_: But if it's in the env for Juju to pick up, then I could pick that up in the charm as well, presumably.  I don't have an OpenStack instance that I can test this on.   I should get that resolved so I can see what's on the actual system.
<rick_h_> cory_fu: yea, I was just looking I had a bastion at one point but can't recall where I put the creds lol
<rick_h_> cory_fu: have a sec for a hangout?
<cory_fu> rick_h_: Sorry, chatting about this with David in another channel.  Might be resolved
<rick_h_> cory_fu: k
<cory_fu> It sounds like OS_REGION_NAME is reliable
<rick_h_> cory_fu: even if there's > 1 region?
<cory_fu> rick_h_: Can an instance be in more than one region?
<rick_h_> cory_fu: no, but there can be > 1 region in the openstack and so we'd have to find which region that instance is in?
<cory_fu> rick_h_: Is this value getting accessed by Juju on the instance, or on the client?
<rick_h_> cory_fu: because region is part of the credential data vs the juju instance
<rick_h_> cory_fu: the client
<cory_fu> Oh, that's not useful.  I need it from the instance
<rick_h_> cory_fu: right, that's what I'm saying
<rick_h_> cory_fu: so if you get the credentials via trust and OS_REGION_NAME is singular you have the answer there, but if > 1 region there I'm not sure if there's another path
<rick_h_> cory_fu: I guess that leads into the API calls you noted against the metadata service? Can you easily get the instance info you need to call that api?
<rick_h_> cory_fu: I've got to run for few, biab
<cory_fu> rick_h_: Ok.  The metadata service is easy to use, but I'm not sure if it includes the region.
<rick_h_> hml: do you know if there's any secret way to get the OS region out from an instance that's running?
<hml> rick_h_: with juju or any tool?
<rick_h_> hml: bonus points with Juju from the running instance, secondary points for any tool that the charm can be updated to leverage
<hml> rick_h_:  it could be that the controller region is all youâll get.  iâm not sure there is a way to change the region once the controller is bootstrapped??
<rick_h_> hml: no, but how would you get the controller region from within an instance in a charm?
<hml> rick_h_: the openstack commands apply to one Region - that you define in the environment variables or running the command
<hml> rick_h_: checking something
<hml> rick_h_: out of curiousity, why would a charm need to know?
<rick_h_> hml: seems that the openstack integrator charm needs to know the region of the instance for something in k8s.
<rick_h_> hml: I'm still wondering then if the info out of juju trust (the credentials) will be limited to the one region that the model is in or if it'll provide a list of an answer if there's > 1 region on the cloud.
<hml> rick_h_: i think itâd have to beâ¦ creds only allow for 1 region
<rick_h_> hml: ok, I couldn't find a way to confirm that. In looking at the discoverregions code I saw it could get a list.
<hml> rick_h_: but i âm wrong
<hml> rick_h_: creds donât include a region
<rick_h_> hml: oh? is it the cloud that's reading the OS_REGION_NAME then?
<hml> rick_h_: yes
<rick_h_> hml: gotcha, ugh
<hml> rick_h_: so far the only place i found it was in the bootstrap-params on the controller
<hml> but any charm wouldnât have access
<magicaltrout> rick_h_: yolo
<rick_h_> magicaltrout: doing dad stuff. What's up?
<magicaltrout> doesn't matter, just looking for some advice on the Openstack LXD conjure-up stuff
<rick_h_> magicaltrout: how so?
<rick_h_> magicaltrout: the nova-lxd stuff?
<magicaltrout> sorry yeah rick_h_
<magicaltrout> whatever I do
<magicaltrout> nova-compute moans about image not found
<babbageclunk> thumper: have space for a review? https://github.com/juju/juju/pull/9161
<rick_h_> magicaltrout: oh hmm. Yea not sure on that. Might have to get with the openstack folks.
<babbageclunk> Ooh, wallyworld, can I get a review? https://github.com/juju/juju/pull/9161
<wallyworld> sure
<babbageclunk> thanks
<wallyworld> babbageclunk: done
<babbageclunk> wallyworld: awesome, thanks
<veebers> wallyworld: I added a type UnitCloudContainer to cloudcontainer.go cribbing off UnitAgent (as per convo from last night), I didn't think adding State to cloudContainer would be ideal when it's only needed for status bits, not the provider/address/ports etc.
<veebers> ah shoot, the other car still has a dead battery. Being stuck at home sucks. /me puts it on charge
#juju 2018-09-06
<wallyworld> veebers: adding State to cloudContainer would have been the wrong choice - we deliberately are not adding State anywhere else new as it was wrong to do it that way way back when
<wallyworld> veebers: i am not 100% on adding a new method to Unit though - that is bloating the Unit entity. we are in state package, can do stuff without needed to add that method to Unit itself
<wallyworld> the general design principal is to keep the domain entities small and use the onion modelto extend their functionality
<veebers> wallyworld: it's not a new method on Unit, it's a new type, func newUnitCloudContainer(st *State, name string) *UnitCloudContainer. It has set/get status
<wallyworld> ah right, that's great then :-)
<babbageclunk> anastasiamac: is this another instance of the intermittent failure you're working on? http://ci.jujucharms.com/job/github-check-merge-juju/3328/testReport/junit/github/com_juju_juju_worker_provisioner/TestPackage/
 * anastasiamac looking
<babbageclunk> thanks
<anastasiamac> babbageclunk: it was arecently added one... i'll add it to my today's list.. thnx, babbageclunk :D
<veebers> wallyworld: when you have a moment, pushed updates to https://github.com/juju/juju/pull/9081. Just need to add tests for UnitCloudContainer, a little apprehensive to add another ConnSuite suite though :-P
<wallyworld> it's only another test to an existing suite i would think
<veebers> wallyworld: yeah should be able to wrangle it in. Partly tested by side effect of being used in other tests too
<babbageclunk> anastasiamac: ok, thanks!
<wallyworld> veebers: there's still one of these fmt.Sprintf("unable to get events for PVC")
<wallyworld> in an errors.Annotate
<veebers> wallyworld: argh no way sorry
<veebers> sigh, visiting that buffer that's where my cursor was; must have been distracted before I could fix it and then moved to something else
<wallyworld> all good
 * anastasiamac is impressed that veebers has more than one buffer... i only have one buffer and one cursor
<veebers> I have a big screen that I fill with many frames. Means I don't have to remember anything, its all there to see :-P I need a meat-memory upgrade
<anastasiamac> ah babbageclunk, that issue is the same one i described in standup - my test is killing worker whenever it wants... i have a fix to do it in more controllled manner... i'll pr and will probably ask u or wallyworld to review...
<babbageclunk> anastasiamac: ok, thanks for taking a look.
<wallyworld> veebers: got time to jump in HO?
<Doctor_Nick> is there an ide that provides autocomplete for charm writing?
<wallyworld> Doctor_Nick: you mean for writing Python hooks etc? so auto complete for charm helper and reactive libray functions? any good Pythin IDE will do that
<wallyworld> like PyCharm etc
<babbageclunk> wallyworld: that other PR I mentioned? https://github.com/juju/juju/pull/9164
<wallyworld> ok
<babbageclunk> thanks!
<wallyworld> babbageclunk: why can't we remove the core store's ExpireLease method?
<babbageclunk> wallyworld: It's part of the lease.Store interface, and the mongo store needs it, since it can't respond to the time updates in the same way.
<babbageclunk> (sorry, was grabbing a lunch)
<wallyworld> babbageclunk: ah right ok. i guess invalid err is ok, although we do tend to use NotSupported in these cases I think
<babbageclunk> wallyworld: I figured invalid is best here since the lease manager is explicitly expecting that.
<veebers> wallyworld: I do now, back from lunch
<wallyworld> ok, i guess the raft side never calls it anyway
<wallyworld> veebers: ok, see you in HO
<pmatulis> a credentials file for google cloud is giving me grief. i need key 'client-id' but when i include it i get the following with add-credential:
<pmatulis> ERROR parsing credentials file: credentials.google.juju-gce-sa.client-id: expected string, got float64(2.0651723337507478e+20)
<pmatulis> the line looks like this:
<pmatulis> client-id: 206517233375074786882
<pmatulis> when i use interactive method and point to my yaml file it works fine. any ideas?
<veebers> pmatulis: you need quotes around it
<veebers> client-id: "203..."
<babbageclunk> pmatulis: weird - you could try putting quotes around the value. Not sure why it would work in one context and not the other though
<babbageclunk> oops
<thumper> anastasiamac: the gce/azure/aws invalid credential detection, is that 2.4 or 2.5?
<thumper> wallyworld: ^^ do you know?
<wallyworld> 2.5 i think
<wallyworld> some of the work landed in 2.4
<wallyworld> but only really functional in 2.5
<thumper> ok, ta
<pmatulis> veebers, babbageclunk, ok, that seemed to be it. in the cloud-city configs this key's value is not quoted...
<veebers> pmatulis: hmm, interesting. Perhaps jujupy does the quoting when it reads then regurgitates that data into the pre-primed JUJU_DATA
<pmatulis> dunno
<babbageclunk> wallyworld: PR for s390x unit test failure: https://github.com/juju/juju/pull/9165
<wallyworld> gr8 looking
<babbageclunk> That one's against develop - it needs to be fixed in 2.4 too, but the test data's been moved, so I'll do a separate PR for it.
<wallyworld> babbageclunk: ty, thought it would be simple like that :-)
<babbageclunk> :)
<veebers> babbageclunk: nice!
<babbageclunk> anastasiamac: Did your fix for the not-a-valid-zip-file failure land?
<babbageclunk> I've just seen it on a test run
<babbageclunk> http://ci.jujucharms.com/job/github-merge-juju/1087/testReport/junit/github/com_juju_juju_api/TestAll/
<anastasiamac> babbageclunk: wasn't a fix but improvemnt.. i'll take another look.. wasnt easy to repro locally
<veebers> anastasiamac: where you able to repro locally at all?
<babbageclunk> oh, right
<babbageclunk> anastasiamac: the bug probably shouldn't be fix-committed then, should it? https://bugs.launchpad.net/juju/+bug/1788401
<mup> Bug #1788401: Intermittent test failure: cannot upload charm ... not a valid zip file <intermittent-failure> <juju:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1788401>
<anastasiamac> veebers: no
<anastasiamac> babbageclunk: no
<veebers> ack
<anastasiamac> babbageclunk: especially if we now have a new accourence :(
<babbageclunk> sorry :(
<anastasiamac> babbageclunk: ?
<anastasiamac> no need to be sorry, especially if we can figure repro steps \o/
<veebers> wallyworld: I don't think Im' being blind, I can't see a way to ignore the status collection in the migration export tests. I see a feature flag for StrictMigration; but that changes the test as a whole
<veebers> babbageclunk: perhaps you know? Is there a way in the migration export tests to ignore a collection that gets left behind?
<wallyworld> veebers: sorry, was caffinateing
<wallyworld> let me check
<veebers> no worries, that's always important!
<wallyworld> oh just thinking about it - the test would be expecting some status items to be exported, but we are adding extra ones
<wallyworld> so we can't ignore the entire collection right?
<wallyworld> we may need to check in th test that all is done except for container status values
<wallyworld> which test is it?
<wallyworld> i'm just hand waving atm
<veebers> wallyworld: all the MigrationExportSuite tests (well 11, not sure if that's all)
<babbageclunk> veebers: what do you mean a collection that gets left behind?
<veebers> no, thats just some of the 49-ish tests
<veebers> babbageclunk: as in we're not (yet) doing anything with the cloud container status collection (that's newly been added).
<veebers> I handwaved over it by doing the extract but doing nothing with the data, but that seems a bit iffy
<babbageclunk> veebers: so you export it but don't import it yet?
<wallyworld> veebers: can you pastebin a failure
<veebers> wallyworld: https://pastebin.canonical.com/p/zrXypw6XtW/
<babbageclunk> oh, just reminding myself about the StrictMigration flag.
<veebers> babbageclunk: this is what I had proposed: https://github.com/juju/juju/pull/9081/files/#diff-d02499513782195ec1b9d18198275e62
<babbageclunk> veebers: right, so there are status entries for this new entity which are being read when the exporter reads status, but that you're not using in the export yet.
<wallyworld> veebers: so for now, i think you could consume the container status values but not add to the juju/description/model
<wallyworld> with a big todo
<veebers> babbageclunk:note the test is failing as I removed that change per PR comments
<babbageclunk> I don't think there's any kind of "these ones are alright" ignore-list at the moment.
<wallyworld> i guess that's what you were doing before
<veebers> wallyworld: so add back what was there
<wallyworld> sorry yeah
<veebers> wallyworld: heh cool, I'm on the same page. no worries
<wallyworld> i didn't realise we needed to do that
<wallyworld> i thought we had the mechanism to cope with it
<veebers> aye, I'm sure for other migration stuff there is a whitelist/ignore list so was expecting the same here
<wallyworld> but we don't for this scenario
<wallyworld> yeah, we ignore whole collections or entity attrs
<babbageclunk> consuming them with a todo sounds like the best bet - we have exclude lists for new collections, but these are status records, so they're always loaded.
<veebers> I suspect it'll need a bigger todo than // TODO(caas) - Actually use the exported cloud container details.
<babbageclunk> wallyworld: Is this failure the caasfirewaller one you and thumper were looking at? http://ci.jujucharms.com/job/github-check-merge-juju/3331/testReport/junit/github/com_juju_juju_worker_caasfirewaller/TestAll/
<babbageclunk> veebers: how big a TODO have you got?
<veebers> babbageclunk: just what I posted just now ^_^
<wallyworld> babbageclunk: not that one specifically IIANM. it would be watcher related though. how often is it failing?
<veebers> In a nutshell, is this grabbing collection data from a source unit and populating the new target unit with this data?
<veebers> as part of an application migration stage
<babbageclunk> veebers: https://pastebin.ubuntu.com/p/qZzcJQVn99/
<veebers> babbageclunk: hahahah I *love* it
<wallyworld> it's grabbing the status data from the mgo model and populating an in memory description
<wallyworld> someone has too much time on their hands
<babbageclunk> wallyworld: seems to be failing after about 5 runs under stress-race
<wallyworld> sigh ok
<babbageclunk> wallyworld: I just used artist-mode - more emacs magic!
<babbageclunk> wallyworld: I'll have a go if no-one's already working on it.
<wallyworld> how did i know it would be %#!W#!$W emacs
<wallyworld> if you want that would be gr8
<veebers> babbageclunk: there is also TÌÍÌ OÌµÍDÍOÌ¸:Ì³
<veebers> (as per the Zalgo thing you showed me the other day)
<babbageclunk> lol
<veebers> Perhaps we should run all our comments through the zalgo generator
<veebers> wallyworld: I'm just doing some manual functional testing now of those changes
<wallyworld> sounds good
<veebers> wallyworld: will show-status-log ever show the current status or must it be status leading up to but not including current status
<wallyworld> i thought it ahows the current status
<veebers> wallyworld: oh ok, I'll double check
<babbageclunk> wallyworld: super-quick one: https://github.com/juju/juju/pull/9167
<wallyworld> sure
<babbageclunk> wallyworld: Thanks! I've made it against 2.4, is someone going to do a merge from 2.4 to develop sometime soon?
<wallyworld> babbageclunk: nice. but is there still arace?
<wallyworld> we normally merge about once a week
<babbageclunk> wallyworld: I don't think there's still a race?
<babbageclunk> Oh, but I was only running that one test, maybe elsewhere in the suite?
<wallyworld> babbageclunk: oh nevermind, i think it's ok. the test sends 2 app change events, and we match those with 2 errors right?
<babbageclunk> yeah, that's right
<wallyworld> i think that;s ok
<babbageclunk> It should be - the stub's all locky
<anastasiamac> wallyworld: babbageclunk: PTAL https://github.com/juju/juju/pull/9168 - promised provisioner tests
<wallyworld> ok, just finishing off something, then will llook
<anastasiamac> nws
<wallyworld> anastasiamac: i had a question about the test coverage i left in the PR
<anastasiamac> wallyworld: what coverage do you think is missing?
<wallyworld> that which is in the deleted test
<wallyworld> checks that only transient errors cause retriesl that retries are not done for non transient errors etc
<wallyworld> i couldn't see where the delete test code was replaced
<anastasiamac> wallyworld: whether the errors are transient or not is not determined by the task. it's deterimned in apiserver layer
<anastasiamac> it has never been covered in this test.
<wallyworld> Data:    map[string]interface{}{"transient": true},
<wallyworld> that line from the deleted test
<wallyworld> set up an error as being transient
<wallyworld> and the test checked that m3, m4 etc were done properly
<anastasiamac> wallyworld: that's in setting machine status in JujuCOnnSuite which is read by apiserver not provisioner task in worker package
<wallyworld> right but the test is deletd and there's no replacement test cover is there?
<anastasiamac> again, this is a functinality that needs to be covered in apiserver not in worker
<wallyworld> right but it's not
<anastasiamac> lemme check if it exists there
<wallyworld> so we are not covered
<wallyworld> unless i can't find it
<wallyworld> maybe i just had a boy look
<anastasiamac> wallyworld: https://github.com/juju/juju/blob/develop/apiserver/facades/agent/provisioner/provisioner_test.go#L434
<anastasiamac> etc...
<anastasiamac> and even as expected there is one to test with permission at line 489
<anastasiamac> whether the status.error is transient or not was never a concern of worker.provisioner_task but of apisever
<anastasiamac> we had to set up the status with error in previous test because we were driving through the whole stack with jujuconnsuite and this was the only way to get machines with transient errors into the task
<anastasiamac> so, exisitng coverage is still there
<wallyworld> anastasiamac: makes sense, ty. sorry i was blind freddy. in tnhe newer code, we use MachinesWithTransientErrors() result and check that retires happen on those results i think then?
<anastasiamac> wallyworld: yes :)
<anastasiamac> in fact, i've run cover against clean develop in this package (78.5% of stmts covered) and against my branch (78.5%) and m happy with the result :)
<stickupkid> is there any documentation around updating aws instance types?
<stickupkid> running "go generate ." inside cloud yeilds no changes
<stickupkid> s/yeilds/yields
<stickupkid> yay - found it
<stickupkid> I'll write a discourse about this
<externalreality> manadart, can you explain breifly why the worker keeps state for both `completedUnits` and `preparedUnits` in your open PR?
<externalreality> manadart, I thought we had combined the two concepts... And not knowing any better I thought I'd ask before you EOD
<manadart> externalreality: It is a symptom of how we designed the API - rather copying state locally, we ask questions. Two of those are: what units are in the
<manadart> "prepare completed" state? and what units are in the "completed" state?
<manadart> In practice, the workflow means that only one should ever actually data in it.
<manadart> *have data in it.
<manadart> externalreality: We *could* use a single collection and output it in the report with a different key based on the machine status. That might be better.
<externalreality> manadart, ah, I see so you are just sorting them rather than having to attach the status and check it each time. Roger.
<manadart> Ja.
<hml> stickupkid: pr 9172 is reviewed/approved.  just had a question in the tests.
<stickupkid> hml: i responded with a question
<hml> stickupkid: unfortunately i havenât played with ec2 image types either.  perhaps a bug to look into this later? to get more data.  or address this now?
<stickupkid> hml: this is going to land on 2.3.9 so I'd rather address now maybe?
<stickupkid> jam: do you have any time to CR this PR - https://github.com/juju/juju/pull/9172
<hml> stickupkid: i was on the fence, mostly because itâs been this way for a while.  but fixing while weâre here is best
<jam> looking
<stickupkid> jam: i'm concerned our default instance is changing too much
<stickupkid> hence why I'm a bit suspect on landing this one
<jam> stickupkid: heh. that was my comment as well
<stickupkid> jam: ha
<stickupkid> jam: what's the best course of action do you think?
<jam> stickupkid: understand why the default is changing. I thought we looked up the default based off of its specs, but that doesn't seem to be true.
<stickupkid> jam: "At the time of writing, this will choose the cheapest non-burstable instance available in the account/region."
<jam> stickupkid: also checking what the price schedule is, and what the tradeoffs are
<stickupkid> jam: https://pastebin.canonical.com/p/Nf2SFXSC99/
<stickupkid> jam: interestingly, the m3.medium is deprecated
<jam> stickupkid: isn't it t3 not m3 ?
<stickupkid> jam: so the m3 was the default (the bottom one) and not the t3 has become the default (the top one)
<jam> stickupkid: t2.medium was the old default, I'm pretty sure
<jam> stickupkid: line 1694 of your diff is -t2 + t3
<stickupkid> jam: ah sorry, you're right
<stickupkid> jam: my bad
<jam> stickupkid: it seems they released a new series of 't' types, and I would be curious to know what the various stats are
<stickupkid> jam: the t series just reduced the cost and that was the winner
<jam> stickupkid: so 't' are all 'burst' types, so you get a number of credits, and that allows your CPU to go fast, until you run out of credits, but they are a lot cheaper.
<jam> but it is a reasonable tradeoff for Juju controllers that aren't heavily loaded.
<jam> but t2 vs t3, I don't know the differences.
<stickupkid> jam: memory seems like a large tradeoff
<stickupkid> jam: do we know what the average controller usage is for a default controller?
<stickupkid> ^ in terms of memory
<jam> stickupkid: so I'm out of time to work on this tonight, but gathering the information of what is available and sending a discourse/email is probably the way forward
<stickupkid> jam: sure, sounds like a plan
<veebers> Morning all o/
<babbageclunk> morning veebers!
<veebers> hey babbageclunk o/ How's thing?
<veebers> things even
<babbageclunk> Oh I only have the one, it's good.
<veebers> excellent!
<babbageclunk> Singing in a concert tomorrow
<veebers> babbageclunk: oh wow awesome! Which concert?
<thumper> morning
<babbageclunk> veebers: https://www.orchestrawellington.co.nz/events/requiem
<thumper> babbageclunk: nice, good luck
<babbageclunk> cheers"
<babbageclunk> !
<thumper> I found a nice choir, but have no time
<thumper> so... not doing it
<babbageclunk> And they have no tim
<thumper> babbageclunk: hey, you'll find this amusing, I have a new song I'm doing
<thumper> babbageclunk: You're welcome
<babbageclunk> I think radionz is broadcasting it while we're performing
<babbageclunk> thumper: oh awesome!
<babbageclunk> Such a good song
<thumper> yeah, it is
<thumper> although I'm singing it at the top of my range, so it isn't comfortable yet
<babbageclunk> Yeah I guess those high bits are pretty high
<veebers> babbageclunk: you're on fire this morning :-)
<veebers> babbageclunk: awesome, all the best for the concert!
<babbageclunk> B)
<thumper> rick_h_, wallyworld: was talking with jam last night about the windows CI failures on develop
<wallyworld> the path length?
<thumper> it looks like the vendoring broke the windows builds due to the path length
<thumper> yeah
<thumper> go 1.11 fixes this
<thumper> so...
<wallyworld> let's move!
<thumper> should we move everything?
<wallyworld> yeah, task for sprint
<thumper> would be a good time to coordinate
<wallyworld> +1
<thumper> rick_h_, externalreality_: was thinking a bit more about the all watcher and the series upgrade stuff
<thumper> if we want the GUI to be able to respond and show the events it needs to be in the all watcher
<thumper> and I do think a new delta type probably makes sense there
<rick_h_> thumper: wallyworld so I talked to hml about using her CI day tomorrow to see what does or doesn't compile with 1.11 so we'll have a list to start from next week
<wallyworld> i think it's just windows right?
<thumper> sweet
<wallyworld> oh, 1.11 you said
<wallyworld> nevermind
<wallyworld> babbageclunk: remind me, what's the bootstrap syntax for specifiying the lgacy lease feature flag?
#juju 2018-09-07
<babbageclunk> --config="features=[legacy-leases]"
<babbageclunk> wallyworld: ^
<babbageclunk> uh-oh, why?
<babbageclunk> found a bug?
<wallyworld> babbageclunk: in k8s bootstrap testing, the initialisation is getting lease errors and we want to rule out a raft issue in the docker image
<babbageclunk> cool
<thumper> wallyworld: got 5 minutes?
<wallyworld> thumper: sure, just talking to kelvin, give me a minute
<thumper> wallyworld: I'll jump into our 1:1, come when you're ready
<babbageclunk> wallyworld: what size did you suggest to use as a minimum for downloading the agent binaries again?
<wallyworld> i think they are approx 80MB but we should allow for unpacking temp space etc
<wallyworld> so say 250MB to be safe?
<babbageclunk> heh, that's the same as in upgrades/preupgradesteps.go
<babbageclunk> It's checking after the binaries are downloaded/unpacked and the agent has restart, though, so not quite the same.
<babbageclunk> *restarted
<wallyworld> kelvinliu_: no rush, would love a review on this today sometime https://github.com/juju/juju/pull/9174
<kelvinliu_> wallyworld, it's a big one! looking now.
<wallyworld> kelvinliu_: yeah - a lot of it is shifting code from one facade to another
<wallyworld> no hurry
<kelvinliu_> wallyworld, yup
<kelvinliu_> wallyworld, wondering if it's easy to change the APIAddresses to [juju-controller-service-internal-endpoint]
<wallyworld> kelvinliu_: i don't quite understand? can you explain?
<kelvinliu_> for example, juju-controller[.juju-namespace]:17070
<kelvinliu_> wallyworld, not for this PR, just thinking it for juju k8s version
<wallyworld> i'm sure we can discuss that
 * wallyworld goes to buy coffee, bbiab
<veebers> oh man, search command history I should be more careful. delete and describe namespace both start with de but do very different things
<kelvinliu_>  - -!!
<wallyworld> veebers: only just saw that comment. i shouldn't laugh but i can't help it :-D
<veebers> hah, it's ok it was an *almost* mistake, I caught it in time
<veebers> wallyworld: we're still expecting caas charms to set Active after setting pod spec right?
<wallyworld> i think so for now; but they only really need to if they have set "maintenance". if the unit status remains "waiting for container" we will override that
<veebers> wallyworld: ack, sweet that matches my expectation. I did a run through but using the not updated charm so didn't work quite as expected; watch this space, just waiting for the bootstrap to complete
<wallyworld> yeah, demo charms will need updating
<veebers> wallyworld: re: this comment https://github.com/juju/juju/pull/9081/files/#r215465303, the tests added to state/caasmodel_test.go should cover the caas model and tests in state/status_model_test.go should cover IAAS models
<veebers> actually state/status_model_test.go might not show up on that diff as I've modifed my changes to it etc.
<wallyworld> ok, so long as we have coverage. i can check the final PR
<wallyworld> kelvinliu_: you ask a good question - i have answered in the PR, but basically I am allowing for future if we want to only use a single config map for all apllications
<wallyworld> does that make sense?
<kelvinliu_> wallyworld, yeah, it makes sense. LGTM, thanks
<wallyworld> tyvm
<veebers> anastasiamac: tough question, have we ever seen the 'local charm archive' test fail in merge, or just the check-merge jobs?
<veebers> wallyworld: FYI: https://pastebin.canonical.com/p/vFjmPhPrJc/
<veebers> Note the "Instantiting pod." is poor messaging from me
<wallyworld> veebers: also though, tyhe active status for workload is premature
<wallyworld> since the pod has still not come up
<wallyworld> i think at that stage the container status is "wating" ?
<veebers> wallyworld: didn't we discuss having the charm set active after it sets pod spec?
<wallyworld> yes
<wallyworld> but
<veebers> (I'm with you that it seems dishonest to have it set active then)(
<wallyworld> we said that would be overridden from container status if the container is not running
<wallyworld> ie if container status is blocked, that take precendence
<veebers> wallyworld: I'm pretty sure the container was never in the blocked stage (or that we polled at least), it was a happy deploy so we set pod spec and the pod came up real quick
<wallyworld> the container status message would be the reason why iot is blocked
<veebers> I'm happy to confirm this though
<wallyworld> it had to be blocked because the pvc failed
<wallyworld> the k8s pod status would have been Unschedulable
<veebers> ah right, yeah that did happen, then after the trust addition the pod came up happy
<wallyworld> yup
<wallyworld> so until trust is run, the unit needs to show blocked
<wallyworld> which it gets from container status
<veebers> it did show that, but it went from active -> blocked (as the charm did 'set spec', set active) so we saw 'active -> then blocked once k8s realised the pod was unschedable
<wallyworld> the container stataus would not have been "running" yet though?
<wallyworld> i think unless the container status is running, we should not show the unit status as active
<anastasiamac> veebers: let me check...
<anastasiamac> veebers: the one babbageclunk linked yesterday was in merge not hte check...
<anastasiamac> why?
<veebers> wallyworld: (unless I have the whole charm should set to active when doing the podspec) then there will be a gap, charm sets pod spec then sets active, k8s/pod will spin up then find out that it's blocked but by then juju has seen the 'active' status from the charm
<veebers> (it's too late, it's seen everything)
<veebers> anastasiamac: ah ok, I'm thinking that the way the pr check job is there is a bit of space for interruption from other jobs or jenkins. Really wanting to get my reshuffle of that stuff sorted and proposed
<wallyworld> yeah right. we are stuck because the charm cannot see the workload
<anastasiamac> veebers: and fwiw, m not seeing it at all locally... more thn 24hr running under stress...
<wallyworld> veebers: but at that stage, there will no no container status right?
<veebers> anastasiamac: aye, this is why I thnk it's how it's run in jenkins
<wallyworld> so we could also say if container status is not found, don't go to active
<veebers> wallyworld: right becuase the mechanisms that does that is only just kicked off
<wallyworld> treat it as container is still allocating
<veebers> wallyworld: ok, will look at adding that into it too :-)
<wallyworld> ty
<wallyworld> so close
<anastasiamac> veebers: i think it's test data setup time when run in parallel... i think just waiting for charm to be setup will solve the issue...
<veebers> wallyworld: feels like we're shoring it up with toothpicks and ducttape though ^_^
<veebers> anastasiamac: hopefully so
<wallyworld> a bit but there's not much else we can do yet
<veebers> aye
<babbageclunk> veebers, wallyworld, thumper: who knows about statfs?
<veebers> babbageclunk: what is statfs?
<babbageclunk> or anastasiamac, kelvinliu_
<veebers> (I guess that answers for me .  . .)
<wallyworld> what's the question?
<babbageclunk> It's a syscall to get filesystem stats
<veebers> ah /me googles
<anastasiamac>  the same as veebers 'wot's statfs'?
<anastasiamac> babbageclunk: why do u need it? what's is wrong?
<babbageclunk> I'm trying to test my check-space change, but having a bit of a mare.
<anastasiamac> try stallion?
<anastasiamac> but srsly.... what kind of nightmare?
<babbageclunk> wallyworld: I'm trying to understand the difference between the Bfree and Bavail fields (and how they interact with fallocate, which is how I'm filling up the disk)
<wallyworld> hmmm, shrug, sorry :-(
<wallyworld> you can always test with a number > than your current free disk space
<wallyworld> just to see
<wallyworld> without having to fill the disk
<babbageclunk> Yeah, I found that in your tests. :)
<wallyworld> *my* tests?
<babbageclunk> I'm doing a manual test.
<wallyworld> what a clver hack that was :-)
<kelvinliu_> not very sure what's the difference.. sry
<wallyworld> right, so a manual test, just compile a jujud with a bogus free space requirment
<babbageclunk> wallyworld: https://github.com/juju/juju/commit/47b2bf184636b31076de11979429304ecd8a78a9
<babbageclunk> wallyworld: well, the other way is to really fill up the disk using fallocate, which is what I'm doing (on someone else's computer)
<anastasiamac> babbageclunk: that was 2015!! another era...
<babbageclunk> Ian had long hair
<wallyworld> it is, but if it's too hard to do, is there a real benefit?
<wallyworld> s/long hair/hair
 * wallyworld sobs quietly
<babbageclunk> It's not that it's hard to do, it's that my code doesn't seem to be working...
<wallyworld> thanks for mentioning it :-(
<babbageclunk> :)
<wallyworld> so you can't just code it to require 100000000000000000000000000000GB of free space and watch it fail?
<babbageclunk> And the code I cribbed from you (in that commit) uses Free, which from my testing still returns a big number even though df -h says I only have 68M available.
<anastasiamac> i like the idea of asking for unrealistic number.. this could be codified...
<babbageclunk> I can, but I'd rather test the real code or understand why it doesn't work
<babbageclunk> Yes, I'm doing that in tests, but without really testing it it's not obvious that the code is actually right.
<anastasiamac> babbageclunk:  ur very dedicated if u want to fill up someone's else machine just to test space check...(or u have exceptional friends!!)
<wallyworld> babbageclunk: why what doesn't work? if the bogus number fails in "prod" with a special jujud, that seems ok right?
<babbageclunk> I mean, it's Jeff Bezos' machine, we're not super close.
<babbageclunk> I have a machine with only 68M available space. Upgrading on it doesn't fail, I'd like to understand why.
<wallyworld> ah i see, so it does fail in prod
<wallyworld> yeah that seems like a bug
<babbageclunk> I'm worried that setting the number to a huge one (like I do in the tests) will work, even though it would still not prevent downloading the agent if it was the real value.
<wallyworld> can you debug it on your machinr with only 68M
<babbageclunk> yes
<babbageclunk> That's what I'm doing
<babbageclunk> I'm trying to find out if anyone understands what the difference is between Bfree and Bavail, which seems to be the problem
<wallyworld> NFI sorry
<anastasiamac> babbageclunk: the best i could find - https://community.hpe.com/t5/System-Administration/vxfs-jfs-bavail-vs-bfree/td-p/3786809
<anastasiamac> babbageclunk: diff seems to b user based?...
<anastasiamac> babbageclunk: "bavail normally means blocks available to a non-superuser "
<babbageclunk> yeah. That's what I've found in the docs too.
<babbageclunk> https://linux.die.net/man/2/statfs
<anastasiamac> babbageclunk: yes, was reading this one too
<babbageclunk> ok, that gives me an idea
<anastasiamac> \o/
<anastasiamac> on a side note, isn't it funny that the manual was my last reference? i went to forums first :)
<babbageclunk> The manual is not very useful in this case - I've been trying to find more info for ages.
<veebers> wallyworld: can you think of a better place than Unit SetStatus to do the 'if no container status and active ignore it' check? doing it there feels a bit off
<wallyworld> yeah, we normally don't want to mess with the raw data model
<wallyworld> it should be done in the apiserver layer
<wallyworld> (or ideally a separate business logic layer we don't have yet)
<veebers> ack, thanks
<wallyworld> but unless we storage the raw data, thing will still mess up
<wallyworld> so that's not really the answer either - it really is a prsentation issue
<wallyworld> we need to store the raw unit and container status as set
<wallyworld> and transform when we hand off to status or when storing history
<wallyworld> hence we talked yesterday about that helper method
<wallyworld> so in the Done() of the unit ops
<wallyworld> it would use the same helper as FullStatus() does
<veebers> wallyworld: aye, that's in place at the moment, but I have the charm setting active and that's done outside of the caas provisioner updateUnit ops bits
<wallyworld> that's fine - we need to store the raw info
<veebers> If I remove that part of the charm it should work, I think, but that does mean that if anyone sets active in their charm it'll be displayed wrong
<wallyworld> why? we transform in FullStatus()
<wallyworld> we need to store the raw data as set by the various actors and transform as necessary to present
<wallyworld> unit SetStatus() does call out to update history so we'll need to use the helper method there too
<wallyworld> but only for caas models
<veebers> wallyworld: Unit.SetStatus will update history, we're not doing anything there
<veebers> hah right, being a bit slow at typing
<wallyworld> :-)
<veebers> wallyworld: so we need to tweak our helper function logic even more, if charm sets active then sets podspec, unit status is no longer active w/ default message. So unless the pod encounters an error it won't overwrite the unit status.
<wallyworld> if the pod spec is updated, the deployment controller will do a rolling update; we should get events for that and can update the data model accordingly
<wallyworld> we can do that in another PR
<stickupkid> manadart: structs vs closures - do you mean pass back a struct or pass an argument as a struct
<stickupkid> re: comment from #9163
<manadart> Pass on struct instead of the 3 mock pointers.
<manadart> s/on/one
<stickupkid> fair
<pmatulis> how does one know what zones are available to the juju client? for instance, 'juju bootstrap --to zone=eu-west-2 aws' doesn't work from north america
<externalreality> pmatulis, does juju clouds list zones
<externalreality> `juju clouds`
<externalreality> pmatulis, well I guess it lists the default zone
<externalreality> `juju regions` maybe
<externalreality> zone == region correct
<externalreality> or is zone is generalization of region?
<pmatulis> externalreality, i originally tried 'juju show-cloud aws'
<externalreality> pmatulis, juju regions aws
<pmatulis> yeah, that gives the same as show-cloud except with less detail
<pmatulis> it would be very useful if the client could somehow know what zones are available
<pmatulis> seems it should be able to query AWS
<pmatulis> funny. i can't get *any* zones to work. even the one that gets used by default successfully
<externalreality> pmatulis, is what `juju regions` lists not compatible with the "zone" placement directive?
<rick_h_> pmatulis: honestly we don't want folks knowing/dealing with zones
<rick_h_> pmatulis: Juju automatically attempts to spread units across zones to make worklaods resilient to outages
<pmatulis> rick_h_, well we shouldn't say it works then
<rick_h_> pmatulis: and having users custom-load them is a sign of a bad install or doing too heavy custom/snowflake stuff that's not portable across clouds
<pmatulis> 'cause it fails fast and hard
<rick_h_> pmatulis: it can/does work but we don't go out of the way to put it in normal user commands like clouds/etc
<rick_h_> externalreality: zone != region
<rick_h_> externalreality: each region has several zones typically
<rick_h_> externalreality: so when you deploy to us-east1 you can get units in various zones in that region
<rick_h_> externalreality: think of zones as racks in a room, for instance
<externalreality> rick_h_, ack, I see, I just found this which was written by Andrew Wilkins https://awilkins.id.au/post/blogger/availability-zones-in-juju/
<rick_h_> externalreality: cool, yea been a while.
<externalreality> rick_h_, pmatulis - I am with pmatulis in that how do you use the directive "zone" if you are unaware of any acceptable parameters
<externalreality> I guess juju does want to make it easy for users to do the wrong thing - Ack - just make it possible.
<rick_h_> externalreality: understand, and maybe we can document something but if you're going to use it you need to understand the cloud you're on, the region you're in (different regions ahve different zones) and what it means to manually place
<rick_h_> externalreality: exactly
<rick_h_> so I'm definitely -1 on making it "easy"
<pmatulis> rick_h_, what's the point in showing the regions? in 2 commands even. is it for something else?
<rick_h_> pmatulis: ? every time you create a model you have to know what region it's in. It could be in the US, in EU, in APAC. The region is very important to performance and geo-spreading workloads across the world.
<rick_h_> pmatulis: I'm not sure what you mean in 2 commands?
<pmatulis> commands 'regions' and 'show-cloud'
 * pmatulis didn't even know about the 'regions' command
<rick_h_> pmatulis: ah, ok. Well the regions available are part of cloud details but folks thought that list-regions made since once you bootstrapped since you can only add-model to regions of the same cloud
<rick_h_> pmatulis: so basically show-cloud is pre-bootstrap useful and list-regions is post-bootstrap (add-model) useful
<pmatulis> but just listing regions doesn't tell you what you're model is in. the show-model command does though
<rick_h_> pmatulis: right, it's meant to help you pick the right region names available for add-model
<rick_h_> pmatulis: once the model is added you're right, what region the model is in is about the model
<rick_h_> pmatulis: so list-regions is more about what you can do given the controller you're on
<rick_h_> pmatulis: if you switch controllers from aws, gce, openstack and run list-regions you'd get different answers
<pmatulis> rick_h_, ok
<hml> small pr for review: https://github.com/juju/juju/pull/9178
<hml> fixes to errors.Annotatef() with go test (using go 1.11)
<hml> build failures
<hml> crackers, must be friday afternoon - need to check that the tests still pass. :-)
<rick_h_> hml: ^ heads up
<rick_h_> sorry, never mind
<rick_h_> lol, somehow I read that hatch was submitting the pr
<hml> rick_h_: happy friday afternoon
<hml> :-)
 * rick_h_ tries to halt checkout procedures
#juju 2018-09-09
<bdx> from a charm's perspective, what is the best way to inquire about the # of units that exist for the type of application that you are? - e.g. how many of myself are there?
<bdx> pretty sure there is an all_units floating around somewhere
<bdx> thought I would run it by the pros
<Doctor_Nick> what are some good autoscalers to use with juju?
<bdx> Doctor_Nick: depends on the cloud substrate
<bdx> Doctor_Nick: https://jujucharms.com/charmscaler/
<Doctor_Nick> bdx: aws, gcloud
<Doctor_Nick> I had looked at that, but it's not free software
<babbageclunk> wallyworld: here's that PR I was telling you about: https://github.com/juju/juju/pull/9180
<wallyworld> babbageclunk: already looking :-)
<babbageclunk> sweet
<wallyworld> babbageclunk: returning an  error from the worker will just restart the worker every 3 seconds and spam the logs. maybe the restart delay needs to be longer in this case?
<babbageclunk> wallyworld: yeah, I was wondering about that - how do I do a longer delay, return a specific error type?
<wallyworld> not sure that we can - i know there's a RetryDelay we can set for the worker itself but I'm not sure off hand how to change that for a specific error
<wallyworld> we'll have to look at the worker code
<babbageclunk> ok, I'll take a look
<babbageclunk> wallyworld: I could just change the worker loop so that it doesn't crash with that error, just logs it and sets retry to something bigger than the default 5 seconds - say 1 minute?
<wallyworld> babbageclunk: i think that works - you mean provide an IsFatal()
#juju 2019-09-02
<hpidcock> a quickee https://github.com/juju/juju/pull/10582
 * thumper looks
<thumper> lgtm hpidcock
<hpidcock> difficult one wasn't it
 * thumper nods
<timClicks> thumper: https://github.com/juju/juju/pull/10534
<thumper> ta
<thumper> timClicks: looks like you've lost a heading now
<timClicks> thumper: fixed
<wallyworld> anastasiamac: small review PP? https://github.com/juju/names/pull/97
 * anastasiamac looking
<anastasiamac> wallyworld: lgtm with some pondering :)
<wallyworld> ty
<timClicks> shiny new project README: scroll down to the bottom of https://github.com/juju/juju/
#juju 2019-09-03
<anastasiamac> wallyworld: btw, PTAL https://github.com/juju/juju/pull/10586 :)
<anastasiamac> wallyworld: i've requested u as reviewer on github when I proposed but obviously it's way too subtle :)
<wallyworld> ok
<wallyworld> didn't see it
<anastasiamac> all good
<wallyworld> most gh email is filtered as it's too noisy
<anastasiamac> :)
<wallyworld> anastasiamac: see comment/question about the txn logic
<anastasiamac> wallyworld: k
<anastasiamac> wallyworld: i'd rather keep docxists assert but will add buildttxn loop and the test
<wallyworld> in that case, also add assert for $ne Dead
<anastasiamac> wallyworld: k
<wallyworld> to match initial query
<anastasiamac> wallyworld: funny but this code was almost verbatum from upgrade permissions... i wonder then if there'd b a problem there too..
<wallyworld> upgrade steps you are talking about" upgrades don't need to deal with concurrent access to db
<wallyworld> s/"/?
<anastasiamac> altho mayb just rmoving assert is fine... u r right, we don't care if we cannot clear cred on a gone model..
<wallyworld> i think in this case it may be ok to not care so much
<anastasiamac> wallyworld: meh.. alreay pushed tansactionality and buildtxn ... want to look?
<manadart> Can I get a tick on a forward-merge? https://github.com/juju/juju/pull/10590
<manadart> jam: Ta.
<wallyworld> anastasiamac: sure, looking now
<wallyworld> anastasiamac: still lgtm
<anastasiamac> wallyworld: \o/
<anastasiamac> ah manadart if only that merge was a couple of hours late :)
<anastasiamac> i'll just cherry-pcik my change into develop tomorrow :D
<manadart> anastasiamac: If the merge fails, I'll add yours :)
<anastasiamac> manadart: mine just went for landing now...
<anastasiamac> into 2.6 that is..
<anastasiamac> wallyworld: and the cherry-pick for develop PTAL https://github.com/juju/juju/pull/10591
<anastasiamac> manadart: mayb u could a +1? srsly just cherry picking :)
<manadart> anastasiamac: Tick!
<anastasiamac> manadart: \o/
<stickupkid> achilleasa, any chance of a CR, this is the changes I talked about last week https://github.com/juju/bundlechanges/pull/57
<stickupkid> achilleasa, fixing the tests took a lot longer than i hoped :\
<achilleasa> stickupkid: sure thing. looking in a few min
<stickupkid> achilleasa, it's a shame GUIArgs has to live on, as it's not a very efficient way to transport information... i.e. you need empty values for all options, even if they're empty
<achilleasa> stickupkid: that's only being used for the GUI bits right? We could kindly ask them to switch to the map version instead ;-)
<stickupkid> achilleasa, yes, i agree
<achilleasa> stickupkid: approved. Yeah, I remember updating the tests to include the empty channel in the GUIArgs output was a pain too
<parlos> anybody experienced "twd4f3: Unable to allocate static IP due to address exhaustion", and have a fix (not sure what network is exhausted, and from the maas there are plenty of IPs in all networks)...
<parlos> (ignore twd4f3 its just the MAAS id)
<hml> manadart:  can or should 1 subnet be in 2 spaces?
<manadart> hml: No.
<hml> manadart:  thatâs what i thought.  juju may be broken there.  stumbled on it while updating RelationUnitSuite.TestNetworksForRelationWithSpaces
<hml> for space-3
<hml> hoping was a copy paste error in the test setup
<hml> look like we never check
<hml> found the checkâ¦ up in the apiserver code.  but that doesnât prevent state tests from doing interesting things.
<stickupkid> rick_h, i've updated to pylibjuju PR, I want to now add more unit tests around the type classes, as it should be much easier to do so. Can you look to see if you've got any concerns
<stickupkid> rick_h, https://github.com/juju/python-libjuju/pull/350
<rick_h> stickupkid:  rgr, otp but will look in a few
<rick_h> stickupkid:  feedback in, looks much sweeter!
<stickupkid> rick_h, the nice thing is, we can use mocks to test the run methods now!
<rick_h> stickupkid:  exactly
<stickupkid> rick_h, yarp, just adding some tests
<rick_h> stickupkid:  sorry to create the work but I think it's on a nicer path for sure
<stickupkid> rick_h, i'd rather have it right, 100% agree
<yan0s> Hi all!
<yan0s> has anyone used openstack as a cloud provider in Juju?
<yan0s> I'm getting this error: ERROR juju.cmd.juju.commands bootstrap.go:697 failed to bootstrap model: no image metadata found
<yan0s> also: skipping index "http://my_ip:8080/simplestreams/images/streams/v1/index.json" because of missing information: index file has no data for cloud {Louros https://mykeystoneurl:5000/v3} not found
<yan0s> same steps have been working about a year ago..
<hml> yan0s:  check the index.json to see if the exact url is given:  https://mykeystoneurl:5000/v3
<hml> yan0s:  iâve seen where itâs https://mykeystoneurl:5000/v3 vs https://xx.xx.xx.xx:5000/v3 where technically they are the same, but it fails.
<hml> itâs a straight string match, no lookup
<yan0s> hml: it is the same in index.json
<hml> yan0s: which version of juju?
<hml> yan0s:  any possibility of a link to or pastebin of the the index.json file?  and the full bootstrap âdebug output please?
<yan0s> 2.6.8-bionic-amd64
<yan0s> https://pastebin.com/mrfzRMi3
<yan0s> actually here is my simplestream uploaded http://62.217.82.41:8080/simplestreams/images/streams/v1/
<hml> yan0s: there was a mistype in creating the simplestream filesâ¦ âhttps:///keystoâ  3 slashes instead of 2.
<yan0s> oh god..
<yan0s> I'm so sorry for wasting your time
<hml> yan0s:  no problem.  another set of eyes can be a good thing
<hml> :-)
<timClicks> yan0s: great to hear that this was an easy fix :)
<timClicks> yan0s: do let us know if you have any further problems, we will be delighted to help
<magicaltrout> https://discourse.jujucharms.com/t/square-brackets-in-env-vars/2024 if anyone knows what goes on under the hood and what I have to escape to get this working, that would be very nice indeed! :)
<thumper> some more intermittent test failure fixes https://github.com/juju/juju/pull/10594
<thumper> wallyworld: you may have commentary for magicaltrout on that post
<thumper> magicaltrout: I'm guessing that it is being parsed as a yaml array
 * thumper thinks
<thumper> magicaltrout: now I read it a bit more, it does seem very strange
<thumper> magicaltrout: you can use yaml type forcing
<thumper> I'd expect
<thumper> magicaltrout: also, what is dc4?
<thumper> magicaltrout: you also don't mention where you are putting it in juju
<thumper> wallyworld: I think I know what is going on though
<thumper> wallyworld: I bet if you take a string like '["hello"]' and parse it as yaml, then write it out as yaml you get ["hello"]
<wallyworld> thumper: sorry, was otp
<thumper> which the second parser deeper is treating as a list
#juju 2019-09-04
<wallyworld> magicaltrout: are you trying to add your square brackets to an attribute in the "config:" section of the charm podspec yaml? can you post to the discourse topic the yaml or a suitable snippet so we can reproduce any issue? is this with juju 2.6?
<thumper> anyone? https://github.com/juju/juju/pull/10594
<babbageclunk> thumper: looking - trade you: https://github.com/juju/juju/pull/10588
<thumper> ,e ;ppls
 * thumper looks
<babbageclunk> types without putting his fingers on home
<thumper> :)
<thumper> babbageclunk: why the two line test?
<thumper> if you are outputting the same thing
<thumper> aren't those to the same?
<babbageclunk> You mean in the Makefile? No, they're subtly different - the old one includes the full list of packages which is super long
<thumper> so what does it output now?
<babbageclunk> The same command but with $PROJECT_PACKAGES instead of the actual packages
<babbageclunk> thumper: It's the same thing we do in go-install
<babbageclunk> It just means you don't get spammed with a huge list of packages when running `make test`
 * babbageclunk finds an example...
 * babbageclunk gets 2FA'd
<thumper> I see it now
<thumper> babbageclunk: I have a makefile change coming too
<thumper> and it overlaps with yours
<thumper> but let's get it reviewed, and I'll deal with the conflicts
<babbageclunk> :)
<babbageclunk> thanks
<anastasiamac> wallyworld: PTAL https://github.com/juju/juju/pull/10595
<wallyworld> ok, give me 5
<anastasiamac> nw \o/ thnx :)
<thumper> babbageclunk: https://github.com/juju/juju/pull/10596
<thumper> wallyworld: what is the best, most current, guide to follow to create k8s charms?
<wallyworld> there's an (oldish) discourse post
<wallyworld> i can find it
<thumper> grr...
<thumper> some of our tests don't honour tmpdir
 * thumper digs
<wallyworld> thumper: https://discourse.jujucharms.com/t/writing-a-kubernetes-charm
<thumper> wallyworld: ta
 * thumper wonders how to isolate which package is writing to /tmp...
<babbageclunk> Put some logging into the stdlib
 * babbageclunk half-winks
<thumper> babbageclunk: with the simple TMPDIR change, we catch most of the /tmp files
<thumper> definitely all the go-build and go-link ones
<thumper> and the check- and the mgo ones
<thumper> but there are a few store-lock ones left
<thumper> based on timestamps, I think it is just two packages
<wallyworld> anastasiamac: lgtm
<anastasiamac> wallyworld: \i/
<anastasiamac> \o/ even :)
 * thumper decides to go one package at a time while doing emails
<wallyworld> kelvinliu: here's that actions PR https://github.com/juju/juju/pull/10597
 * thumper thinks there has to be a better way to do this
 * thumper thinks of bashisms
<wallyworld> thumper: when you are free, a huge PR https://github.com/juju/juju/pull/10598
<anastasiamac> haha if thumper is going to run tests pkg by pkg, he is not likely to b free this century...
<thumper> wallyworld: done
<wallyworld> ta
<thumper> anastasiamac: for i in $(ls -d */); do echo ${i%%/}; touch /tmp/latest; cd $i; TMPDIR=/tmp/fake go test ./...; cd ..; find /tmp -path /tmp/juju-store-lock-\* -newer /tmp/latest 2> /dev/null; done
<thumper> that is what I came up with to keep my sanity
<thumper> anastasiamac: and it tells me it is /api/backups
<thumper> just like that
<anastasiamac> thumper: m very impressed :) we do prefer it if u could do everything in ur power to keep ur sanity
<anastasiamac> and backups need some attention (not just the tests of course)
 * anastasiamac honestly does not know what's with this new trend of keeping leaders sane... 
<thumper> yeah, I know
<anastasiamac> but m kind of happy that it's backups and not something more recently developed :)
<kelvinliu> wallyworld: just back home, looking soon
<wallyworld> no worries
<wallyworld> hpidcock: here's a PR which adds a new hook command that you may find interesting to look at. no rush. https://github.com/juju/juju/pull/10599
<hpidcock> alright
<parlos> Good Morning Juju!
<yan0s> I'm trying to setup juju with an OpenStack provider and I get the following error
<yan0s> caused by: failed executing the request https://ncc_url:8774/v2.1/servers
<yan0s> caused by: Post https://ncc_url:8774/v2.1/servers: EOF
<yan0s> I saw this related bug: https://bugs.launchpad.net/juju/+bug/1655716
<mup> Bug #1655716: retry failed API calls <eda> <landscape> <Autopilot Log Analyser:Fix Committed by fginther> <juju:Triaged> <https://launchpad.net/bugs/1655716>
<danboid> I want to set up a juju controller. Is it as simple as installing the juju snap?
<danboid> Will that create the database for me too?
<danboid> I'm looking at https://jaas.ai/docs/installing and it doesn't give any pointers as to what the next step is after having installed the snap
<danboid> I had a look into setting this up a while back and I seem to remember the controller needs a DB
<danboid> I ran out of time and didn't get it running but can't remember how far I got
<stickupkid> danboid, to run it locally you should be able to do https://gist.github.com/SimonRichardson/1609d6f93dcfdfbd97771afa7c1b38f0
<danboid> stickupkid, Thanks! `juju bootstrap lxd test` will do what exactly?
<stickupkid> danboid, bootstrap to a local lxd provider.
<stickupkid> danboid, so this will setup a juju controller for you on a lxd provider, is what I should of said
<danboid> That will create a juju controller called test? I presume it will use lxd on localhost? If lxd isn't installed on the local machine, how does it know where to look for one?
<stickupkid> danboid, you are correct, it will attempt to use the one on localhost. If lxd isn't installed, it will fail to bootstrap.
<danboid> OK, sounds easy enough
<stickupkid> danboid, let me know how your adventures go
<danboid> stickupkid, I will. Thanks!
<danboid> I presume it is advised to run the juju controller on a separate machine to your maas controller? It is possible for them to run on the same machine tho too right?
<stickupkid> the latter is the way to go when first setting up, but yes you can run your controller somewhere else if you so desire
<parlos> anybody got any idea how to handle "Unable to allocate static IP due to address exhaustion"...
<stickupkid> parlos, you got any more info?
<parlos> not really, my maas has lots of IP addresses available in all the networks juju may want to use...
<parlos> stickupkid not really, my maas has lots of IP addresses available in all the networks juju may want to use...
<stickupkid> parlos, i'm assuming you've filed a bug, so we can track it... that way i can point people in the right location
<parlos> stickupkid nope, no bug filed.. Assumed that it was user error :( Not sure if its a juju or maas bug...
<yan0s> Any thoughts on "juju bootstrap" resulting in:
<stickupkid> parlos, one way to find out :D
<yan0s> caused by: failed executing the request https://ncc_url:8774/v2.1/servers
<stickupkid> parlos, https://bugs.launchpad.net/juju/+filebug
<yan0s> caused by: Post https://ncc_url:8774/v2.1/servers: EOF
<stickupkid> yan0s, what's the provider you're bootstrapping to (lxd, manual, MAAS)?
<yan0s> openstack
<yan0s> rocky release
<danboid> stickupkid, I'm running lxd init on my maas controller. I said yes to "Would you like to connect to a MAAS server" now it is asking for an API key. Should I create a new MAAS user just for lxd or use my personal API key or...
<parlos> anyway to 'replace' a machine that failed in a deployment. Without destroying the model and redeploying it?
<danboid> stickupkid, I suppose the idea would be that every maas user would have their own juju controller/API key?
<danboid> stickupkid, So is it not possible for multiple maas users to share a juju controller?
<parlos> danboid, afaik no...
<stickupkid> danboid, so you would allow juju to manage maas and allow juju manage the users...
<stickupkid> danboid, see `juju users --help`
<stickupkid> parlos, remove-machine?
<parlos> danboid; In my setup, I've got one juju controller on it i deploy models from different different maas users/keys. So, enables me to track (on Maas) what nodes are ued by what user.. (would be nice to push tags from juju to maas during deployment)
<parlos> stickupkid, would remove-machine trigger a redeployment of the apps that were destined for that machine?
<stickupkid> parlos, nope, you'd have to use `--to` directive
<stickupkid> when deploying
<danboid> parlos, That sounds like a setup I want to try. So when you were configuring lxd, which API key did you give it?
<parlos> stickupkid, so the work around would be to allocate a new machine, move the units to that machine and then remove the machine that failed...
<stickupkid> parlos, rick_h would know more tbh
<danboid> parlos, I'm configuring lxd on my maas controller, gonna run a juju controller on there too
<stickupkid> he comes online soon
<parlos> stickupkid, ok. Will submit bug, and hang around.
<danboid> lxd init failed: `Couldn't find the specified machine`. When it asked "What's the name of this host in MAAS` I just gave the hostname of the MAAS controller which was the default but there is obvs some more, missing config
<danboid> Hmm. No. Under MAAS General, MAAS name the controller has a name which is the same as the hostname so I dunno why lxd init failed
<danboid> Maybe I can get away with skipping the MAAS options in lxd init if it is running on the same machine?
<danboid> maybe it'll let me get away with using 127.0.0.1 for the controller name?
<danboid> So I suppose my most important question is, does lxd need to be configured to access/use MAAS at all?
<danboid> So long as juju can use lxd fine, is there any need to link lxd and MAAS?
<danboid> I suppose I'll just have to try without and see how far I get
<danboid> There seems to be a clash between bind running on my MAAS controller and lxd init wanting to create lxdbr0
<danboid> So I either install lxd and juju ob a different machine or...
<danboid> Not sure there is an or
<danboid> unless MAAS doesn't need to use bind/named
<danboid> I suppose the other option is to create the bridge interface myself then get lxd init to use that
<rick_h> parlos:  no, it won't auto redeploy. Recovery is up to the operator because we don't know what restrictions the operator is expecting. "don't autodeploy to that machine, I'm keeping X and Y on different hosts..." or the like
<rick_h> parlos:  so you'd in theory use add-unit for anything running with any constraints/placement notes
<rick_h> parlos:  and then yes, remove the machine with the units on it when you were happy to deal with it
<magicaltrout> https://discourse.jujucharms.com/t/square-brackets-in-env-vars/2024/2 rick_h !!! any ideas?! :)
<parlos> rick_h; would have been nice with replace-machine, that would just deploy a new machine with the same specs as the one that failed...
<danboid> Yay! I have a juju controller on my MAAS box now! :)
<danboid> No idea what to do with it now :)
<stickupkid> danboid, congrats
<stickupkid> danboid, juju deploy :D
<danboid> stickupkid, Thanks! :)
<danboid> This is to start playing with openstack
<danboid> juju deploy openstack ?
<danboid> I'm sure there will be a guide online somewhere, I'm just being a bit overly lax :)
<pmatulis> danboid, https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/install-openstack.html#deploy-openstack
<danboid> pmatulis, Thanks!
<pmatulis> danboid, kindly open doc bugs if needed --> https://bugs.launchpad.net/charm-deployment-guide/+filebug
<danboid> pmatulis, Yeah. I think the juju install page could do with a bit of tweaking too
<pmatulis> danboid, that guide will take you through deploying OpenStack by individual service. you can also try a bundle
<pmatulis> it all depends what you want to do/learn
<pmatulis> https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/install-openstack-bundle.html
<danboid> pmatulis, Thanks!
<pmatulis> danboid, how many MAAS nodes do you have? and what resources do they have? it's typical to require multiple disks and network cards
<danboid> pmatulis, I have 1 MAAS controller with 5 nodes attached. They are Xeons, 3 have 64 GB RAM and 2 have 256 GB. They've all got at least 1 TB of disk space and multiple NICs
<danboid> Before I run juju deploy, is it something I need to run under screen/tmux or will it background itself?
<stickupkid> achilleasa, when we deploy a bundle, the overlay is merged on to the base bundle yaml, so I can upload that to the server to get the changes?
<danboid> I'd imagine there is a bit more config before I can deploy the bundle. I'll need to tell it which nodes to use at least right?
<danboid> or does it automaticaly use all available nodes?
<pmatulis> danboid, it sounds like you should do some experimenting with stuff that is lighter than openstack
<pmatulis> just to get the basics. did you look at the documentation yet?
<pmatulis> https://jaas.ai/docs
<danboid> Nope. I've been playing with MAAS for a while but not in-depth. I haven't touched juju yet
<danboid> The problem is those docs seem to be JAAS centric, rather than focusing on a on-prem juju setup
<stickupkid> jam, what happens if you want the BestFacadeVersion, but the facade doesn't exist on old controllers?
<danboid> or at least thats the case for the Getting Started guide
<pmatulis> danboid, nope. jaas is just one tiny thing in the docs. url notwithstanding
<danboid> What would you suggest I try putting together before attempting openstack?
<pmatulis> danboid, just go through the main topics in the docs. there are a couple of beginner tutorials
<achilleasa> stickupkid: any overlays are sequentially merged to the base bundle. What do you mean by "upload to the server"?
<stickupkid> achilleasa, ho?
<achilleasa> omw
<magicaltrout> hello fine people... if anyone in the US has any clue about https://discourse.jujucharms.com/t/square-brackets-in-env-vars/2024/2 that  would be very useful indeed! ;)
<magicaltrout> like, does anyone know if there is something I can do to get GO to parse some YAML read by some Python? or do I need to chop up the upstream container to make it happen?
<rick_h> magicaltrout:  was looking...stop breaking things! :P
<rick_h> magicaltrout:  I think we'll have to create some test cases and get back to you unfortunately. Honestly it's probably better as a bug
<magicaltrout> fair enough. Yeah I dunno what I can try cause I don't know how the yaml -> python -> go handoff works
<magicaltrout> so i gave up at that point
<magicaltrout> I'll file it and mash up the container for now
<magicaltrout> want to get this demo stack done for ApacheCon next week
<magicaltrout> https://bugs.launchpad.net/juju/+bug/1842691
<magicaltrout> done
<mup> Bug #1842691: Array in YAML causes Kubernetes charm failed deployment <juju:New> <https://launchpad.net/bugs/1842691>
<stickupkid> achilleasa, i ejected - it would take to long, but my PR for exposing the method on the API server is solid - can you give a CR, i'll start on bringing this into pylib https://github.com/juju/juju/pull/10601
<achilleasa> stickupkid: sure, let me check
<stickupkid> rick_h, merge master into 2.7 branch, for pylibjuju https://github.com/juju/python-libjuju/pull/353
#juju 2019-09-05
<wallyworld> kelvinliu: here's a small PR to fix the pod spec parsing issue https://github.com/juju/juju/pull/10603
<kelvinliu> wallyworld: yep looking now
<kelvinliu> lgtm thanks
<anastasiamac> wallyworld: ask-or-tell add-credential PTAL https://github.com/juju/juju/pull/10604
<thumper> https://github.com/juju/juju/pull/10605
<thumper> jam ^^
<wallyworld> hpidcock: did you need a review of your draft PR?
<hpidcock> wallyworld: if you want, I think that would be good seeing as I'm still writing tests, so if something needs to change I'd rather do it now
<wallyworld> ok
<wallyworld> for tomorrow, i have the next actions PR up
<kelvinliu> wallyworld: got 2mins HO? wanna confirm one thing about rbac.
<wallyworld> sure
<wallyworld> kelvinliu: in standup
<kelvinliu> wallyworld: me2. in different room?
<wallyworld> hpidcock: got to go AFK until team meeting, will look at PR after that
<hpidcock> np no rush at all
<stickupkid> achilleasa, CR https://github.com/juju/python-libjuju/pull/355 ?
<stickupkid> achilleasa, yeah good shout, i'll fix that
<stickupkid> achilleasa i updated and fixed
<Parlos> Im deploying Openstack using the bundle (61), all looks fine in 'juju status'. But when I try to upload an image, I get "Error finding address for... Broken pipe". Found a bug report,https://bugs.launchpad.net/glance/+bug/1833009. which seemed to have a similar problem. It was however solved, so Im wondering if the issue in the 'bug' has been addre
<Parlos> ssed in the current bundle, and/or this could be something else...
<mup> Bug #1833009:  openstack image create fails with [Errno 32] Broken pipe  for openstack rocky and stein <glance> <juju> <openstack> <Glance:New> <https://launchpad.net/bugs/1833009>
<magicaltrout> i'm not sure whats more broken
<magicaltrout> the uk political system
<magicaltrout> or my attempts to test juju on k8s
<magicaltrout> https://discourse.jujucharms.com/t/cant-bootstrap-internal-k8s/2032/3
<magicaltrout> if anyone has any ideas
<magicaltrout> (we all know the correct answer is the uk political system)
<stickupkid> magicaltrout,  the uk political system <- this
<danboid> What happened to juju-gui / juju-quickstart? Is it dead?
<magicaltrout> juju gui is still juju gui
<rick_h> danboid:  basically, the gui is in maintenance mode while they do a new gui tool for management
<magicaltrout> juju-quickstart is conjure-up now
<magicaltrout> ish
<magicaltrout> or whatever rick_h says... he clearly knows
<danboid> After having a quick look at the conjure-up site, I don't think it is a (web) UI to juju, more like a wrapper of some sort?
<danboid> It obvs depends on juju
<rick_h> yea
<magicaltrout> well juju gui exists if you've got a bootstrapped controller
<magicaltrout> you just run
<magicaltrout> juju gui
<magicaltrout> its just not getting love from the devs
<danboid> When you run 'juju register' what does it do? ie why is it taking multiple minutes on my i7 w/ 16GB RAM, gigE etc to register
<danboid> I expected it would've been instantanous? Maybe its gone wrong?
<danboid> It asked me for a password and the controller name but that was a good few minutes ago
<rick_h> danboid:  it's trying to reach out to the controller and login
<danboid> rick_h, Seems it failed. What port needs to be open on the controller?
<danboid> ERROR Provided registration token may have been expired.
<danboid> but it took several  minutes to show that
<danboid> 17017 ?
<rick_h> danboid:  the normal 17017 yea
<stickupkid> rick_h, another merge forward of changes pylib https://github.com/juju/python-libjuju/pull/356
<rick_h> stickupkid:  +1
<stickupkid> rick_h, ta
<jhobbs> rick_h: we're seeing this when attempting to bootstrap juju against openstack; any ideas? http://paste.ubuntu.com/p/FbVmmJv8xX/
<rick_h> jhobbs:  looking
<jhobbs> i'm not sure how key management with juju and openstack works; openstack doens't show any keypairs associated with the instance
<rick_h> jhobbs:  have you tried to clear the ssh key in known_hosts for 10.244.32.187 on the client?
<rick_h> jhobbs:  quick glance it looks like the VM comes up, gets an IP, and the client attempts to connect to the controller over the IP and fails due to an existing (different key) for the controller IP
<jhobbs> yeah so it's using that tmp file for keys
<jhobbs> which juju owns
<jhobbs> /tmp/juju-known-hosts764870299:1
<jhobbs> if i remove the key with the command it suggests, I get this instead:
<jhobbs> 15:55:34 DEBUG juju.provider.common bootstrap.go:576 connection attempt for 10.244.32.187 failed: No RSA host key is known for 10.244.32.187 and you have requested strict checking.
<jhobbs> Host key verification failed.
<rick_h> jhobbs:  oic, hmmm not seen anything with that to date.
<rick_h> jhobbs:  is there an entry in that file?
<rick_h> jhobbs:  in /tmp/juju-known-hosts764870299 ?
<jhobbs> let me see
<jhobbs> 10.244.32.187 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzZr0m8iigEmkMoZva1pdaJ7U9eC61yg+wwq1isIbZPokHnBBGSKq74KojG8MJOVYSO2eeAharfGIXxfdHtqy6/5DFOF0SfL2IhVz3rDvBBGmuL1OrNO9vcZn/SNRK2ZaJm82r3BsA2M6kcJFxeq+PZ8gukcaqYAGq269Pz5+QWueVKHbiIQEPaLhuhDI+AnaqoGtmldz38xohvAglRfDTJtSfrHZzyley/3wLjZ+kC7IGeoWhGQ5pG6Sl+jjGoYom4GANDUFUDFIXxMfE/w0TCZbR6YeOliEjZJshzO4fM9fOgbxPZHkgOcj7k4jtNeJeOez7x4cKTB7G/ZN9N9E7 juju-bootstrap
<jhobbs> maybe juju prepopulates that file with the key for the instance? maybe it gets it from the openstack api?
<hml> jhobbs: thereâs an ssh key in the cloud init used to create the instance.
<hml> no keys via the openstack api directly
<jhobbs> ok
<jhobbs> so maybe it's not getting that cloud-init
<hml> jhobbs:  bootstrapping to checkout a few things
<hml> jhobbs:  there is a key created to use during bootstrap.
<jhobbs> ok
<jhobbs> I think the instance isn't getting the metadata for some reason
<jhobbs> the cloud-init userdata from the metadata server
<hml> then another key once itâs up for system
<stickupkid> rick_h, achilleasa, the last pylibjuju commit around bundle changes https://github.com/juju/python-libjuju/pull/357
<rick_h> hml:  thanks for helping out, I've got to get ready to go to that family thing and will be afk for a bit
<hml> jhobbs: whatâs odd too, is that the tmp file is created, used and removed during bootstrap
<jhobbs> hml: right
<jhobbs> hml: i think the instance is generating its own ssh server key because it's not getting the one from metadata
<jhobbs> hml: so it's getting a mismatch
<hml> jhobbs:  are you using the edge snap?
<jhobbs> no hml, 2.6.8
<hml> jhobbs:  i canât reprod myself with openstack  ; but i do get it trying to directly ssh to the controller instance.
<hml> though juju ssh worksâ¦ itâs using a different keyâ¦ so there are 3 over the process of bootstrap and configuring a machine.
<hml> jhobbs: whatâs configured via the model_defaults.yaml  ?
<achilleasa> stickupkid: approved; on a sidenote, the relevant juju PR enountered CI errors on merge
<stickupkid> achilleasa, :(
<stickupkid> achilleasa it was an intermittent failure
<wallyworld> babbageclunk: can you jump in standup HO?
<babbageclunk> sure sure
#juju 2019-09-06
<wallyworld> kelvinliu: is your PR ready to review? I'll look after i finish harry's. plus I have 2 small ones up as well
<kelvinliu> wallyworld: not yet, will ping u when it's ready
<wallyworld> ok
<hpidcock> wallyworld: PRs look good, exit code one just needs to update Gopkg.lock
<wallyworld> oh right yeah, for the k8s dep
<wallyworld> got sucked back into this verizon thing, so still not done with yours sorry
<hpidcock> np
<wallyworld> hpidcock: i left a few more comments - wouldn't mind a chat perhaps once you read them
<hpidcock> hpidcock: not needed, I think I understand them all
<wallyworld> ok
<wallyworld> hpidcock: i'll do another pass once changes pushed. operator flle needed for juju-run since that is invoked from the workload pod by a cron script or whatever and not via an exec call made by juju where the env vars can all be set in place to commuicate socket info etc
<wallyworld> so where we do have env vars available, we should continue to use that pattern
<hpidcock> wallyworld: seems pretty heavy to send the ca cert for every call
<wallyworld> yeah, true that
<wallyworld> we could write that to the /var/lib/juju directory
<kelvinliu> wallyworld: wanna have a discuss testing podspecv2, ru free now?
<wallyworld> hpidcock:  so i guess the operator file in some form might be reasonable after all
<hpidcock> wallyworld: I agree that we should probably keep the env vars consistent for hooks, but I think the compromise is a ca.crt file, and a JUJU_CA_CERT=<path-to-ca.crt>
<wallyworld> hpidcock: or maybe just the cert and private key a seperatae files on disk under /var/lib/juju like we do for other things
<wallyworld> yup, works for me
<hpidcock> ^
<hpidcock> ok
<wallyworld> kelvinliu: sure, free now
<wallyworld> kelvinliu: for later when you are free, this brings the pod spec parsing from from yesterday in 2.6 to the develop branch https://github.com/juju/juju/pull/10611
<kelvinliu> wallyworld: lgtm thx
<wallyworld> ty
<cjwatson> I'm trying to use the feature described in https://jaas.ai/docs/lxd-cloud-advanced#heading--charms-and-lxd-profiles as having been added in Juju 2.5.0.  I have https://paste.ubuntu.com/p/jBydGSKdHS/ as lxd-profile.yaml at the top level of my charm.  Client version 2.6.8, controller version 2.5.8.  It seems to have exactly no effect: "lxc config show --expanded" on the relevant container ...
<cjwatson> ... doesn't show the configuration I've tried to set, and I can't find any log entries related to it.  What am I missing?
<cjwatson> Oh, never mind.  I think my controller upgrade hadn't quite finished at the point when I did the deployment
<cjwatson> Nice nice, this is there now
<hml> cjwatson: glad that was resolved.  definately recomment juju 2.6.8 for using lxdprofiles over 2.5.x
<pepperhead> o/
<pepperhead> Is it normal for, when adding credentials, the pasted API key doesnt print to screen? My juju is all messed up.
<pmatulis> pepperhead, yes, that sounds right
<pmatulis> pepperhead, messed up how?
<pepperhead> I enter "juju status" and get "ERROR no API addresses"
<pmatulis> it sounds like you cannot contact the controller
<pepperhead> Is there any way to uninstall juju and start fresh?
<pmatulis> do you have anything deployed?
<pepperhead> I tried "sudo apt-get remove juju", then "sudo apt-get purge juju". then reinstalled with "sudo apt install juju". I get the same
<pmatulis> what i meant was, did you deploy anything with juju (ex: juju deploy <something>)
<pepperhead> Well I think that may be the problem: I had maas running, and moved it into a lab, and it got borked. I uninstalled maas and reinstalled maas. It HAD the controller deployed previously. Could it be still thinking it is alive?
<pepperhead> The only thing successfully deployed previously was the controller
<pmatulis> yes, juju cannot see the new maas
<pepperhead> So do I have to wipe the system and start from scratch?
<pmatulis> you can do a few things. uninstall completely or just tell juju to forget about the controller
<pepperhead> Whats weird is I tried to deploy the controller, and it deployed Ubuntu to the node and hiot a wall.
<pmatulis> does 'juju clouds --local' show your maas cloud?
<pepperhead> Can I do both? How can I tell juju to forget the controller, AND uninstall to ensure I am clean?
<pmatulis> uninstalling will include forgetting the controller
<pmatulis> did you install juju by deb package or by snap?
<pepperhead> I get "mymaas                0                   maas        Metal As A Service"
<pepperhead> deb
<pmatulis> we usually encourage snaps these days
<pepperhead> I am cool with switching, if that is possible
<pmatulis> ok
<pepperhead> New to Snaps, and juju, and maas :(
<pmatulis> 'sudo apt purge juju'
<pepperhead> done
<pmatulis> and remove ~/.local/share/juju if it's still there
<pepperhead> it was there, removed
<pmatulis> now 'sudo snap install juju --classic'
<pepperhead> "juju 2.6.8 from Canonicalâ installed"
<pepperhead> I need to research Snap
<pmatulis> perfect. now add your MAAS. you've done that before right?
<pmatulis> (add-cloud command)
<pepperhead> Unsure what that means, maas is running already
<pmatulis> yes, but you need to tell juju about it
<pmatulis> (how did you get a maas before? you said it showed up with 'juju clouds --local')
<pepperhead> "juju add-cloud mymaas"?
<pmatulis> https://jaas.ai/docs/maas-cloud
<pepperhead> I was following "https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/rocky/install-juju.html"
<pmatulis> oh, interesting
<pmatulis> well, that should be equivalent
<pmatulis> but you're prolly using a more updated juju version. there may be differences
<pmatulis> but i think you're well on your way. good luck
<pepperhead> So start the interactive with "juju add-cloud --local"
<pmatulis> that will work, yes
<pepperhead> Thanx! Was just confused by "add maas", thought it might mean removing and readding maas itself :)
<pmatulis> ohh :)
<pepperhead> So should I run that with sudo?
<pmatulis> no
<pepperhead> So you are probably well versed in maas, so let me ask a stupid question: Should the node machines be set to boot first from drive, or PXE after commissioning?
<pmatulis> *always* PXE
<pepperhead> You rock!
<pepperhead> So Ubuntu is deploying to the juju node now
<roadmr> pmatulis does rock :)
<pepperhead> and you solved the chicke or the egg question I have been mulling over since this started
<roadmr> ð¥  ð
<pepperhead> Trying to get OpenStack deployed as a POC, taking me down a lot of new roads
<pepperhead> to make matters worse, I am given a stack of Intel NUC's to do the project.
<pepperhead> Does juju have a web interface, as does maas, to see whats going on, or is it all cli?
<pmatulis> it does
<pmatulis> it gets installed with the juju controller
<pepperhead> is that the "juju gui"?
<pmatulis> https://jaas.ai/docs/gui
<pepperhead> I need to read the docs this weekend, as well as maas docs
<pmatulis> yep
<pmatulis> you can discuss stuff in the docs via a forum. there is a link at the bottom of each page that will bring you there
<pepperhead> Maybe this node is bad, I got booted from tyhe maas box (ssh'd in). maas is still saying "Deploying Ubuntu 18...)
<pmatulis> you will need to wait
<pmatulis> until the node is deployed
<pepperhead> I ssh'd back in
<pmatulis> you mean you tried to ssh into the node?
<pepperhead> no, back into the maas box
<pepperhead> unsure how to see where juju is in the process now
<pmatulis> what did you actually tell juju to do? 'juju bootstrap'?
<pepperhead> patience padawan
<pepperhead> yes
<pepperhead> with constraint to "juju" tag
<pepperhead> It    picked up the correct node and started deploying the OS
<pmatulis> ok, so juju told maas to deploy ubuntu onto a node and then juju will install controller stuff onto it
<pepperhead> the maas gui shows it still deploying
<pepperhead> this juju is very cool.
<pepperhead> I think the issue is the NUC's.
<pepperhead> Or this one in particular. If it doesnt complete I will try one of the larger NUC's, this is the smallest of the stack
<pepperhead> Until juju gets the controller installed, no way to get a status I would think
<pepperhead> 2 core/ 4g RAM
<pepperhead> I assume that since it issued the command to maas, and maas began the process, the API creds are correct.
<pepperhead> I wonder if the node will have to reboot after the OS is deployed?
<pmatulis> if you fear things have gone pear-shaped you may need to go purely maas and test powering on/off and deploying. so no juju. just work within the maas gui
<pepperhead> If I want to cancel the bootstrap, and try another node that is bigger, is there a way to do that?
<pmatulis> maas has logs that are viewable via the gui. you can also view logs on the maas server. i would look at the logs before ctrl-c on juju
<pmatulis> maas gui event logs are per the node being deployed
<pepperhead> I took a look at the node, it is stuck at a reboot with a "boot:" prompt
<pepperhead> Event "Installation complete - Node disabled netboot"
<pmatulis> yeah, i sounds like your MAAS:NUC combo may need some study. i suggest asking in the maas forum: https://discourse.maas.io/
<pepperhead> If a tag another node as "juju" will it grab it, or do I need to remove this job first?
<pmatulis> i would try a ctrl-c on the bootstrap command
<pepperhead> I got thrown out of my ssh session, so I assume the bootstrap command died at that time?
<pepperhead> update: confirmed on a second node. maas lays the OS down, performs a reboot, pxe grabs it and trys to hand off for a local boot and dies with a "boot:" prompt.
<pepperhead> Thanks for the helpand time, looks like a dead project.
<pepperhead> oddly if I ctrrl-alt-del reboot and catch it and select to start from the drive, the system comes up. juju controller never gets installed.
#juju 2019-09-07
<atdprhs> Hello everyone, I am trying to bootstrap a test controller and this is what I get >> ERROR failed to bootstrap model: cannot start bootstrap instance: unexpected: ServerError: 400 Bad Request ({"network": ["Node must be configured to use a network"]})
<atdprhs> do anyone know where i could get more loggings for this error?
<atdprhs> I am experiencing the same issue as this https://bugs.launchpad.net/maas/+bug/1596683 , this is my network config for both `interfaces` and `virsh net-edit default` https://paste.ubuntu.com/p/wYCDBD4g2J/
<mup> Bug #1596683: [2.0b8] node network settings revert after failed bootstrap <MAAS:Invalid> <https://launchpad.net/bugs/1596683>
#juju 2019-09-08
<atdprhs> Hello everyone, I have managed to successfully setup k8s environment using juju, however I am trying to setup storage but it's working as expected, can anyone please see https://askubuntu.com/questions/1171639/how-can-i-setup-ceph-osd-on-ubuntu-server-with-maas-kvm-pod
<atdprhs> hello everyone, can anyone please help about this >> https://askubuntu.com/questions/1171639/how-can-i-setup-ceph-osd-on-ubuntu-server-with-maas-kvm-pod ?
#juju 2020-08-31
<kelvinliu> hpidcock: or wallyworld got this pr for the application stuff, could u take a look thanks https://github.com/juju/juju/pull/11935
<hpidcock> looking
<wallyworld> kelvinliu: hpidcock: i have an issue with an aspect of the above PR, happy to discuss
<hpidcock> @wallyworld I answered your concerns, they will be addressed once we have charm metadata sorted
<wallyworld> hpidcock: all good, ty
<kelvinliu> wallyworld: ty4rv, just commented those exported vars, are you happy for me to land it now?
<wallyworld> sure, ty, harry gave +1. thabks for asking
<kelvinliu> ty
<hpidcock> @kelvinliu https://github.com/juju/juju/pull/11949 or
<hpidcock> @wallyworld
<kelvinliu> looking
 * wallyworld is in a meeting
<kelvinliu> hpidcock: lgtm ty
<qthepirate> Any word on JUJU and IPv6 for containers?
#juju 2020-09-01
<wallyworld> qthepirate: there's no offical testing if ipv6 but as far as i'm aware, juju does not explicitly not support ipv6. there was a time when it complained if lxd was set up with ipv6 but i think that may no longer be the case. but as i said, it's no tsomething that is officially tested or supported yet
<qthepirate> right
<qthepirate> I know it works perfectly fine with standard hosts, just not LXC's
<qthepirate_> Damn! I'm sick of being logged out automatically. Is there a way i can stop that?
<wallyworld> not sure sorry
<wallyworld> maybe ipv6 with lxd on juju is a simple tweak. lxd itself supports ipv6 just fine
<qthepirate_> its probably just an implementation thing then.
<qthepirate_> theres a bunch of charms that have "prefer ipv6" built into them already
