#juju 2011-10-31
<ttt> anybody know how change password trough command line for ochestra web browser interface?
<hazmat> ttt, hmm.. no idea.. perhaps in the config, most of the folks here are out sprinting
<hazmat> er. at uds
<hazmat> at least a critical mass of the core
<shang> hi all, I was trying to deploy juju locally on Ubuntu, but I got the error: error: Environments configuration error: /home/shang/.juju/environments.yaml: environments: expected dict, got None
<shang> here is my environment.yaml file: http://paste.ubuntu.com/724173/
<shang> any idea would be really appreciated!
<shang> did anyone seen hit this issue before? https://bugs.launchpad.net/orchestra/+bug/884133
<_mup_> Bug #884133: Bad archive mirror using juju.preceed file <Orchestra:New> < https://launchpad.net/bugs/884133 >
<SpamapS> http://video.ubuntu.com/live/ ... sabdfl talking about juju right now :)
<ejat> SpamapS:  :)
<ejat> catch up with u later after this ..
<SpamapS> ejat: as he said, I'll be there tomorrow. :)
<ejat> hmmm ...
<ejat> will u be here tomorrow ?
<ejat> :p
<ejat> let me pokes jcastro beside me and ask .. :p
<jcastro> SpamapS: charm session is on wednesday
<SpamapS> jcastro: :)
<ejat> noted .. :)
<_mup_> Bug #884324 was filed: juju bootstrap fails to use default-ami specified in environments config file <juju:New> < https://launchpad.net/bugs/884324 >
<SpamapS> Has anybody noticed that trunk fails tests right now?
<SpamapS> ./test juju.environment fails
<SpamapS> http://video.ubuntu.com/live/ <-- negronjl and iamfuzz demoing juju + cloudfoundry
<ejat> $ juju bootstrap
<ejat> error: Environments configuration error: /home/fenris/.juju/environments.yaml: environments.sample.default-series: required value not found
<SpamapS> yes you have to add 'default-series: oneiric' to environments.yaml
<_mup_> juju/expose-refactor r420 committed by jim.baker@canonical.com
<_mup_> Removed debugging
<lynxman> oh in case you guys want to have a look, the juju macport is in a bzr branch (on m_3 request) at lp:~lynxman/+junk/juju-macports
<noodles775> Hi people. Should I need to fiddle with my networking (default after install) to use juju with lxc? http://paste.ubuntu.com/724681/
<m_3> lynxman: thanks man
 * noodles775 reads about the need to reboot :/ at http://irclogs.ubuntu.com/2011/10/05/%23juju.txt
<noodles775> So the reboot worked, I can now deploy locally, but (1) the units seem to remain with state==null, and (2) only the first machine is listed: http://paste.ubuntu.com/724709/
<noodles775> It looks close - loving the ability to deploy to lxc (well, almost!) :-)
<noodles775> Whoohoo, local deploy works perfectly... thankyou to all who worked on that :)
#juju 2011-11-01
<marcoceppi> o/
<ejat> environments.sample.default-series: required value not found ???
<uksysadmin> anyone familiar with openstack and juju?
<uksysadmin> I've a physical 2 node cluster which I can successfully launch instances. juju fails though with "nomorenetwork" error
<uksysadmin> any pointers appreciated
<noodles775> uksysadmin: I hadn't heard that juju supported openstack yet... let me check the faq.
<uksysadmin> yeah was using it last week under vbox - moved to a v small multi node set up on my desk
<uksysadmin> only difference was that my vbox environment was painfully slow but it bootstrapped ok and launched other stuff no problem
<uksysadmin> I've a feeling its a specific openstack issue - but I can allocate floating ips to my instances
<noodles775> uksysadmin: have you tried using lxc instead? (I just tried it yesterday and it was pretty fast, even on my netbook... I just followed the example with 2 wordpress app servers and a mysql server)
<uksysadmin> its not so much me wanting juju, openstack demos are my primary goal.
<uksysadmin> just handy that I got wordpress going running openstack under vbox and all I've done is moved to some physical machines
<noodles775> I see.
<statik> hola
<statik> Is there a way to have multiple environments defined in juju and specify on the CLI which one to use? I was trying to add an lxc environment to my juju config and am getting an error
<statik> ERROR There are multiple environments and no explicit default (set one explicitly?): /home/emurphy/.juju/environments.yaml
<statik> I haven't been able to find instructions in the docs on how to set a default or select an environment
<robbiew> bcsaller: ^?
<bcsaller> statik: most juju commands take a -e environment argument or you can add a default: env_name at the top level of the ~/.juju/environments.yaml file
<statik> bcsaller, thanks!
<noodles775> statik: I saw you've already got your answere, but just came across this too http://askubuntu.com/questions/65364/how-can-i-configure-multiple-deployment-environments-for-juju
<statik> noodles775, thanks! I didn't think to look on askubuntu
<zematynnad> hello - I'm going through the tutorial at https://juju.ubuntu.com/docs/write-charm.html .   I've gotten to the point where I've fixed the intentional error in my localfile and update the revision number.  But for some reason when I run the command $ juju upgrade-charm --repository=examples/ drupal, I get the following error: http://paste.kde.org/140630/
<zematynnad> has anyone run into this already? or know if the docs need to be updated perhaps?
 * ejat pokes SpamapS
#juju 2011-11-02
<SpamapS> ejat: hey are you still here in Orlando?
<ejat> SpamapS: yeah ... im still here ...
<ejat> hopefully will see ya in the juju session this evening
<lynxman> hazmat: ping
<ejat> lynxman & hazmat : u guys at UDS ?
<lynxman> ejat: yes :)
<ejat> hopefully can meet ya ! :P
<lynxman> ejat: so... how do you look like? ;)
<ejat> hmm .... specky with jeans short pan for today ..
<ejat> im in bonaire2 now ... maybe see ya in juju session this evening
<lynxman> ejat: oh definitely :)
<ejat> a lot of thing need to be learn from u guys ..
<lynxman> ejat: we're around in case you need anything, I'm in a blue polo with a black jacket :)
<lynxman> ejat: right now in bonaire 7, next in bonaire 4 for a session I'm leading
<ejat> ill be at ya session after this ..
<lynxman> ejat: cool :)
<hazmat> lynxman, pong
 * ejat pokes SpamapS
<SpamapS> juju session on config management right now at uds http://summit.ubuntu.com/uds-p/meeting/19431/servercloud-p-cfjuju/ join #ubuntu-uds-bonaire4
<ejat-> 0/
<marcoceppi> Weird issue with Juju deploy
<marcoceppi> http://paste.ubuntu.com/726691/
<marcoceppi> This command was working yesterday, but stopped working this morning after adding a config.yaml
<marcoceppi> Similar to what zematman was having
<zematynnad> marcoceppi:  what was the error you were getting?
<marcoceppi> Charm 'local:oneiric/tf2' not found in repository /home/marco/Projects/juju/charms
<marcoceppi> zematynnad: Similar to the one you were getting, only this is during a deploy
<zematynnad> marcoceppi: the problem I had may not be the same as yours but here's what fixed mine...
<marcoceppi> I'm all ears
<marcoceppi> or eyes
<zematynnad> marcoceppi: I got rid of revision in the yaml file and put the revision in a revision file
<marcoceppi> Hum, I don't have a revision in the yaml file
<zematynnad> marcoceppi: the revision number has to be a regular integer 1, 2, 3 instead of 1.1 or something like that
<marcoceppi> Right, the revision number in revision is 3 currently
<marcoceppi> Maybe I did something wrong in the config.yaml file?
<zematynnad> I'm not sure but probably what' happening is that the error message is a bit generic and there's some syntax error or typo somewhere that needs to be fixed
<marcoceppi> Probably a syntax error in config.yaml
<marcoceppi> I was just asking m_3 that
<marcoceppi> Thanks zematynnad I'll take a look at the config
<zematynnad> marcoceppi: good luck!
<m_3> marcoceppi: is it a good time to work on steam?
#juju 2011-11-03
<marcoceppi> m_3: This charm is getting real close to completion
<pindonga> hi, i'm trying out juju with the local provider. I managed to get it running but I think i found a bug, and wanted to discuss it with someone to see if I should file one
<pindonga> when bootstrapping, juju tries to start dnsmasq, but I'm already running dnsmasq as a caching dns server
<pindonga> so juju fails to start it again, and (I think) therefore fails to start zookeeper (as this one is not running either)
<pindonga> when I stop dnsmasq things start to work
<hazmat> pindonga, ping
<pindonga> hey hazmat
<pindonga> so I found these 2 problems (they may be related)
<pindonga> 1. zookeeper not running after I reboot
<pindonga> the only way I could get it to start was by removing the whole environment
<pindonga> and starting from scratch
<pindonga> 2. I  *think* dnsmasq may be getting in the way but I 'm not sure
<hazmat> pindonga, at the moment local environments do not survive reboot or ... even hibernation
<pindonga> hazmat, is there anything we can do to work around that?
<hazmat> the reboot issue is a little more interesting, we're working on the hibernation one
<hazmat> pindonga, we could probably right an upstart job to capture the restart of the containers and lxc for reboot
<hazmat> worth a bug report for the reboot scenario
<hazmat> pindonga, regarding the networking .. indeed libvirt does drive a dnsmasq that is needed for getting the containers networked properly
<hazmat> pindonga, its not clear to me that an existing dnsmasq is nesc fatal to that
<hazmat> since the libvirt dnsmasq is binding the the bridge address
<hazmat> worth some investigation to see what the conflict there might be
<hazmat> pindonga, could you elaborate on the usage of the existing dnsmasq server
<hazmat> just a local caching dns server bound to ?
<pindonga> hazmat, I'm not sure it's conflicting, it may just be the zookeeper issue
<pindonga> hazmat, but I'll try to reproduce and let you know
<_mup_> Bug #885701 was filed: juju fails to bootstrap when dnsmasq already running <juju:New> < https://launchpad.net/bugs/885701 >
<pindonga> hazmat, this is the dnsmasq bug: https://bugs.launchpad.net/juju/+bug/885701
<_mup_> Bug #885701: juju fails to bootstrap when dnsmasq already running <juju:New> < https://launchpad.net/bugs/885701 >
<hazmat> pindonga, thanks
<pindonga> hazmat, I just tried to deploy a basic charm (one that does nothing) to get access to a bare lxc instance
<pindonga> when doing ssh to it it takes forever
<hazmat> pindonga, are you at uds?
<pindonga> do you know how I can debug this? to figure out what it's doing?
<pindonga> yes
<pindonga> you're here too? I can meet you
<hazmat> pindonga, i'm sitting near the entrance the four chairs around the big red leather square
<pindonga> k, I'll be there in a few minutes
<hazmat> in the conference building
<pindonga> thx
<hazmat> pindonga, np
<hazmat> pindonga, i have the blue hat on
<_mup_> juju/local-repo-log-broken-charm r412 committed by kapil.thangavelu@canonical.com
<_mup_> local repo warns about broken charms
<pindonga> hazmat, ping again (sorry).. I think I messed something up now... I reinstalled lxc, and now I get an error about lxc-ubuntu not being found
<pindonga> so I guess I have the wrong version of lxc (but I installed it via apt-get, so it should have gotten the right one, right?)
<pindonga> hazmat, ping again (sorry).. I think I messed something up now... I reinstalled lxc, and now I get an error about lxc-ubuntu not being found
<jimbaker> juju roadmap discussion now in #ubuntu-uds-bonaire7
<mpl> so I don't suppose there would be some EC2s and S3s available somewhere so that one can play around with juju and test it?
<noodles775> mpl: you can actually test locally without EC2... have you seen the following section of the documentation?
<noodles775> https://juju.ubuntu.com/docs/provider-configuration-local.html
<mpl> noodles775: yeah I have. it failed for me.
<noodles775> mpl: at what point? There were a few teething issues when I tried it, but got it working...
 * noodles775 looks for the email summary.
<mpl> mpl@yggdrasil:~$ juju bootstrap
<mpl> 2011-11-03 18:44:09,642 INFO Bootstrapping environment 'local' (type: local)...
<mpl> 2011-11-03 18:44:09,643 INFO Checking for required packages...
<mpl> 2011-11-03 18:44:09,848 INFO Starting networking...
<mpl> 'module' object has no attribute 'check_output'
<mpl> 2011-11-03 18:44:09,849 ERROR 'module' object has no attribute 'check_output'
<noodles775> mpl: and that's using juju from the PPA on Ubuntu oneiric? (if so, it's different to the issue I had - but the juju team should be back from lunch in a while)
<noodles775> mpl: here's a summary of the small issues and workarounds I had, in case it helps: https://lists.ubuntu.com/archives/juju/2011-October/000901.html
<mpl> noodles775: ppa
<mpl> yeah I suspected 1) could be an issue. I haven't rebooted. and don't intend to right now.
<therve> heya
<therve> I'm getting DNS error on store.juju.ubuntu.com when trying to use juju deploy, any idea?
<noodles775> therve: yeah, I'm guessing you haven't specified the --repository correctly (or haven't prefixed with local:charmname) as per the docs.
<noodles775> (and therefore it tries to use an as-yet non-existent online repository.
<therve> noodles775, ok, that sounds like a good idea
<therve> noodles775, but then it can't find the local charms somehow
<noodles775> therve: I'm not sure if the docs are out of date, but you need to have your charm under a distroseries (oneiric).
<noodles775> as in /home/therve/charms/oneiric/mycharm/hooks etc. (from memory)
<therve> noodles775, ah, thanks! I was specifying the oneric/ as repository indeed
<noodles775> Great.
<mgw> still having trouble getting my VMs up and connected to cobblerâ¦ anybody have a minute to help?
<_mup_> Bug #885905 was filed: Obsolete metadata warning doesn't indicate the charm <juju:New> < https://launchpad.net/bugs/885905 >
<_mup_> Bug #885906 was filed: "Try it yourself" on wiki front page doesn't give next action <juju:New> < https://launchpad.net/bugs/885906 >
<mgw> is there a way to bootstrap an existing vm into cobbler/juju, rather than doing a fresh install of ubuntu for every system?
#juju 2011-11-04
<mgw> Heyâ¦ anybody know how to run juju.preseed on an already deployed server?
 * PandorBox dropped juju for plain cloud-init yesterday
<marcoceppi> PandorBox that's a shame
<PandorBox> marcoceppi: it's a really nice concept, but was getting in the way of deploying stuff... something for later I suppose
<_mup_> Bug #886188 was filed: No feedback when creating master container <juju:New> < https://launchpad.net/bugs/886188 >
<_mup_> Bug #886195 was filed: Crash in update_state <juju:New> < https://launchpad.net/bugs/886195 >
<_mup_> Bug #886207 was filed: juju-log messages not showing up in debug-log <juju:New> < https://launchpad.net/bugs/886207 >
<_mup_> Bug #886210 was filed: update https://juju.ubuntu.com/docs/write-charm.html to reference juju  <juju:New> < https://launchpad.net/bugs/886210 >
<_mup_> Bug #886215 was filed: scaffolding like tooling for writing charms <juju:New> < https://launchpad.net/bugs/886215 >
<_mup_> Bug #886216 was filed: doc bug: explain metadata and hooks before getting into "writing a formula" in the docs <juju:New> < https://launchpad.net/bugs/886216 >
<_mup_> Bug #886232 was filed: Backtrace in juju debug-log when destroying a service <juju:New> < https://launchpad.net/bugs/886232 >
<_mup_> Bug #886364 was filed: default-series ignored in environments.yaml <juju:New> < https://launchpad.net/bugs/886364 >
<mgw> heyâ¦ any experienced juju users here?
#juju 2011-11-06
<rog> yo
 * rog likes free wi-fi in airports. +1 to Orlando.
<SpamapS> Indeed, the free wifi was cool, though it seemed to trigger some bug in the wifi drivers on my air
<SpamapS> lots of crashing
<SpamapS> iphone worked fine :p
 * SpamapS always feels giddy on inflight wifi
<ejat> morning ..
<ejat> alo ..
#juju 2013-10-28
<rick_h_> marcoceppi: when you get time want to chat packaging/use charmhelpers. since it's using distutils no setup.py develop command and it's merged back to setuptools anyway so not sure if there's a reason to keep it distutils.
<rick_h_> bah, and doesn't have any install_requires
<marcoceppi> rick_h_: I haven't had a chance to look at the project for several weeks. Given emerging requirements to include multiple languages I imagine re-organizing the code base and having one source package build several language specific (including a generic charm-helpers package)
<marcoceppi> rick_h_: I'm not sure if just a setup.py will cut it for packaging
<rick_h_> marcoceppi: gotcha, well let me know if you get there and want a test/second set of eyes on making it installable easy enough
<marcoceppi> rick_h_: I'm open to opinions even before I get there :)
<rick_h_> marcoceppi: yea, not sure. I'm more a python packager. I did it once, but I live in pypi land
<rick_h_> (did a .deb once)
<rick_h_> but trying to get it installed, wanted to try out the 'template a new charm' stuff but the readme isn't helpful atm and wasn't sure how best to install it. Figured I'd pull down the source and install into a virtualenv, but the python package doesn't do deps, etc
<marcoceppi> rick_h_: I'll likely create a python-charmhelpers package for just the python specific bits
<marcoceppi> rick_h_: oh, haha, that's because you don't install it
<rick_h_> https://juju.ubuntu.com/docs/authors-charm-writing.html doesn't use it from what I can tell
<marcoceppi> it's just "embedded" in charms ATM
<marcoceppi> and by charms, I mean Python charms
<rick_h_> marcoceppi: so I thought there was a 'create a new charm from a sample tepmlate' command?
<marcoceppi> rick_h_: yeah, `juju charm create <name>`
<rick_h_> or is that somewhere else then before you get to the charm/python helpers in there
<marcoceppi> but that's only one template
<marcoceppi> rick_h_: charm-tools
<marcoceppi> that's packaged and should be in saucy/juju stable ppa
<rick_h_> marcoceppi: ah, /me didn't realize there was charm-tools and charm-helpers
<marcoceppi> rick_h_: but it's only one template, and it's a very light weight bash template
<rick_h_> they kind of blurred into one on me
<marcoceppi> rick_h_: charm-tools is for stuff outside of charms, charm-helpers is for stuff inside of charms
<rick_h_> marcoceppi: ok, well I guess if you wanted me to test out writing a new charm from scratch, where should I be starting to test what we tell everyone to do?
<rick_h_> marcoceppi: ok, I'll try to see if I can at least pull some readme updates that make that more clear.
<marcoceppi> rick_h_: Follow the docs, though I don't think it has charm-tools syntax in it yet, evilnick should be adding that soon. Basically, what I tell people during charm schools is: "Add ppa:juju/stable, apt-get install charm tools, run juju charm create <name>"
<marcoceppi> rick_h_: https://juju.ubuntu.com/docs/tools-charm-tools.html
<rick_h_> marcoceppi: yea, that's not in the doc on charm-writing ^^
<marcoceppi> rick_h_: right, evilnick has a task to fix that
<rick_h_> ok cool
<marcoceppi> I can ping you once it's updated if you want to give it a go?
<marcoceppi> s/\?//
<rick_h_> marcoceppi: ok, we'll see.
<rick_h_> marcoceppi: so does charm-helpers have a doc listing the api bits it provides for charm writing?
<marcoceppi> rick_h_: not that I know of. It's pretty much read the source.
<rick_h_> marcoceppi: ok can do
<marcoceppi> rick_h_: we did an intro charm school about it. Part of packaging it will be to document it
<marcoceppi> rick_h_: let me know any and all feedback on the process. It's rough right now so outside opinions on the process are so very welcomed1
<rick_h_> marcoceppi: yea, will do. It's been a while since I tried to charm up my app so starting over vs updating the old code and will go through the process
<marcoceppi> rick_h_: you going to write the charm in Python?
<rick_h_> marcoceppi: that's the plan
<rick_h_> marcoceppi: for https://github.com/mitechie/bookie
<marcoceppi> rick_h_: cool, the code in "core" package of charm-helpers will likely help you the most
<marcoceppi> rick_h_: you might also want to watch the charm-helpers charm school, it goes over some of the more commonly used charm-helpers
<rick_h_> marcoceppi: k, so charm-tools isn't in the dev ppa? I've got 0.3 from there, but looks like 1.0 is out?
<marcoceppi> rick_h_: charm-tools is in ppa:juju/stable (and should be in saucy)
<marcoceppi> let me check saucy
<marcoceppi> yeah, it's in saucy
<rick_h_> marcoceppi: ok, this is a raring desktop I'm running on atm. Haven't updated the desktop, only laptop yet. It's running the juju/devel ppa
<marcoceppi> rick_h_: ah, yeah all the tools for juju are in ppa:juju/stable
<rick_h_> marcoceppi: ok, looks like I've got bigger fish to fry to get going then.
<marcoceppi> rick_h_: it's save to have that and devel ppa on your machine, you'll always get latest juju
<marcoceppi> safe*
<rick_h_> marcoceppi: ah ok
<marcoceppi> Yeah, we're making a commitment to have packages of tools in the charm ecosystem in distro, liek charm-tools, amulet, charm-helpers (eventually), deployer, etc
<marcoceppi> charm-tools just never got updated for raring
<rick_h_> marcoceppi: yea, understand. My fault.
<marcoceppi> np np!
<marcoceppi> this will definitely be a better trusty story, but it's good to document this in the charm-authors guide. If you're getting tripped up by it others will
<rick_h_> README.ex?
<routelastresort> is there a good doc w/current info on what I can change to ppa/settings-wise to get all of the latest fixes on saucy??
<rick_h_> marcoceppi: well just did bash since I had bash instructions, but http://ec2-54-205-26-172.compute-1.amazonaws.com:6543/ walks through my make commands ok at least it seems
<Preytell> I ask this question in the maas channel but maybe it should be here.
<Preytell> Morning all, I have a question about maas. I am attempting to put maas regional controller on a machine that how two nics, and I am deploying to hardware that is on a switch with the second nic on the controller.  But when I boot strap it will get to a point where it attempts to wget the tools and it tries to get them from the first nics address and not the nic that it just pxe booted from... Which of course fails.
<Preytell> it really juju that is doing this part.
<Preytell> it's
<rick_h_> jcsackett: around today?
<AskUbuntu> JuJu bootstrap error | http://askubuntu.com/q/367340
<zradmin> Azendale: Quantum had to be renamed because of a trademark dispute apparently. I am also working on an HA deployment and Neutron doesn't seem to be registering properly as I can't run any commands against the API
#juju 2013-10-29
<Kyle> Hmm, is the manual provisioning supposed to be as buggy as it is?
<sarnold> Kyle: you mean the ssh "null" provider? (have they come up with a better name for it yet?)
<Kyle> sarnold: Yeah
<Kyle> I just can't get it to bootstrap period
<sarnold> Kyle: .. if so, probably -- the ssh support is very new, and because the machine doesn't start with a blank slate (as the other providers do), the risk for existing configuration on the systems conflicting with charms is a lot higher..
<sarnold> hrm. I'd expect bootstrapping to work. :)
<Kyle> 2013-10-29 00:23:15 ERROR juju supercommand.go:282 Get sftp://kyle@192.168.1.15//var/lib/juju/storage/tools/releases/juju-1.16.0-precise-amd64.tgz: unsupported protocol scheme "sftp" -- mmm
<Kyle> and based on that, it was "fixed" 15 or so days back
<AskUbuntu> not able to upgrade maas to 1.4? | http://askubuntu.com/q/367734
<AskUbuntu> Juju bootstrap fails for Windows Azure | http://askubuntu.com/q/367778
<ahasenack> hi guys, where can I find some documentation about peer relations?
<ahasenack> a search on juju.ubuntu.com isn't helping much
<ahasenack> ah, this has something: https://juju.ubuntu.com/docs/authors-charm-metadata.html
<rick_h_> ahasenack: and mysql I know has one if that helps with an example http://bazaar.launchpad.net/~charmers/charms/precise/mysql/trunk/view/head:/metadata.yaml
<ahasenack> rick_h_: ah, thanks
<marcoceppi> ahasenack: I saw your email, I don't think a peer relation is what you want.
<marcoceppi> ahasenack: Are you trying to share db relations between units?
<ahasenack> marcoceppi: no, I need a way for the /1 unit to get the db password that the /0 unit set
<ahasenack> marcoceppi: it would be like wordpress, except we used the db admin credentials to create another user, unprivileged, that the app will use
<ahasenack> marcoceppi: and we don't relate via just db, because we need the admin user for certain tasks
<marcoceppi> ahasenack: Okay, so /0 gets db-admin creds, then creates an unpriviledged user that it and other units will use?
<ahasenack> marcoceppi: right
<marcoceppi> ahasenack: cool, then peer is def what you'll want
<ahasenack> marcoceppi: thanks :)
<marcoceppi> ahasenack: just don't make any unit number assumptions. If you deploy with --num-units 3 and unit/1 comes up first it should do the creation/sharing. In other words becareful with idempotency and leader election
<ahasenack> marcoceppi: sure
<ahasenack> marcoceppi: I'm wrapping my head around that now, considering those scenarios
<marcoceppi> ahasenack: cool
<ahasenack> marcoceppi: maybe I'll decide it will be easier to get an extension on the db-admin relation to create additional users, but I want to explore this peer relation first
<marcoceppi> ahasenack: please don't change the definition of the db-admin relation
<ahasenack> what I meant with "get an extension" is to start a discussion
<marcoceppi> I'm still recovering from our sprint conversations about the http releation
<marcoceppi> ahasenack: whew, okay
<ahasenack> not just put up innocent-looking MPs that change it :)
<marcoceppi> ahasenack: I'm working on a charm helper to assist with sane peer election, as a few of my charms require it
<ahasenack> marcoceppi: cool
<ahasenack> marcoceppi: are peer relations established automatically, or do I need to explicitly add-relation them?
<ahasenack> I think the latter
<marcoceppi> ahasenack: automatically
<ahasenack> oh, really
<ahasenack> ok
<ahasenack> marcoceppi: thanks
<olafura> I'm wondering what UserData does in the control instance, I see a lot of commands, are they run right away?
<thumper> olafura: I'm not sure what you mean
<thumper> also though
<thumper> heading to the gym now
<thumper> feel free to leave questions
<thumper> and if no one has answered, I'll look when I get back
<olafura> cool, it's in the command RunInstance and UserData is the parameter it's when you bootstrap
<olafura> I think I got my answer it runs a script on the instance and the tool is cloud-config
<marcoceppi> olafura: I believe that passes data to cloud-init
<marcoceppi> olafura: so that juju can get the machine provisioned at boot
<olafura> marcoceppi: Thank you I'm very close to making GreenQloud working with the old python version of juju ( it's easier test things out in it ). I'm just talking with them now about providing the Ubuntu Cloud images which have the cloud-config
<marcoceppi> olafura: I don't mean to be a downer, but the python version is no longer used and has been deprecated. All efforts, updates, and merges should be going in to the new juju-core
<olafura> marcoceppi: That's my intent but it's much easier finding out what they are doing differently with it then having to recompile the go version over and over
<marcoceppi> olafura: well, it's fast to recompile ;) but just wanted to make sure you knew about it ahead of time
<marcoceppi> olafura: do you work over at GreenQloud?
<marcoceppi> thumper: did you find out why that one guy was having issues with local provider and bootstrapping at the sprint? (ecryptfs/weird timeout issues)?
<olafura> marcoceppi: no I'm just going to be using their services, I needed a cloud provider in Iceland and they are the only game in town
<marcoceppi> olafura: very cool, thanks for putting the work in to do so!
<marcoceppi> olafura: there's a #juju-dev room where the juju-core go developers hang out, if you have questions about moving your changes to golang you're free to ask here of course, but you might get a more targeted response in ther
<marcoceppi> jcastro arosales ^^
<olafura> marcoceppi: Thanks, I will probably try hanging out there. I'm will probably have to iron out some things, in python before I move to go. I got somethings working in go before I moved, mostly s3 based stuff. Are you still on Soup or have you moved to rest?
 * marcoceppi is not a core developer, just a charmer
<marcoceppi> olafura: I have no idea
<marcoceppi> olafura: is greenqloud openstack?
<marcoceppi> Or did they make their own "compute" stuff?
<olafura> marcoceppi: It's CloudStack but it's basically ec2 api, but with enough warts to cause a problem
<marcoceppi> olafura: gotchya
<olafura> There are some CloudStack providers now so many I need a general class for them
<marcoceppi> olafura: writing a generic cloudstack provider would be great if you could generalize them enough
<arosales> olafura, good to hear you are working on a provider
<olafura> marcoceppi: The only problem with all of this is that everything get's compiled into one binary so I can't just provide an plugin
<arosales> olafura, as marcoceppi said #juju-dev is a good resource
<olafura> arosales: yes I opened I new tab with it. I will probably ask more detailed questions there
<marcoceppi> olafura: providers are "plugin"-ish, they're seperated in core by directories, but this is a provider we'd love to have merged in core.
<marcoceppi> olafura: when I do compilations of core, it takes less than a second (after I've fetched the dependencies once) so it shouldn't be too much more tedious to rev
<olafura> marcoceppi I'm also new to Go so it's easier to get going, the old code also had a configurable option of the urls which helped
<marcoceppi> olafura: I believe a lot of those options were  moved over, but I'd have to hunt through the code to confirm
<olafura> marcoceppi: and there was an other developer that already gave up on testing it out in Go
<olafura> marcoceppi: I will probably use a similar approach because I don't know all the url of the providers
<marcoceppi> olafura: well, best of luck! Please feel free to ping me/the room if you get stuck of have questions. We're happy to help out
<olafura> maroceppi: thanks for the help, I'll probably get stuck on something else :)
<sarnold> roughly how much effort is it to create a new provider? the digitalocean api looks very easy, and i've heard good things about them.. https://www.digitalocean.com/api/
<marcoceppi> sarnold: from my understanding, it's not too complicated, but thumper could probably answer level of difficulty. You just need to code how to launch instances, where to store user data, firewall stuff, and maybe a few other odd bits and bobs
<sarnold> marcoceppi: hrm. maybe digitalocean is too simplistic. :)
<olafura> sarnold: I'm not a developer on Juju but what I've seen of the code it uses a storage like s3 to manage some of the things so you need something that replaces that. I'm working on some thing that is very close to e2 and s3 apis so I don't have to do as much work but it's probably a week or two of coding from scratch. I also don't see at first glance that they have a way to upload you own image which would probably be needed or talk
<olafura>  to them about storing the Ubuntu cloud images.
<olafura> sarold: There are also no security groups, so I don't know about firewall configuration
<olafura> sarold: ok they provide a way to do that with domains
<sarnold> olafura: oh I thought the domains were just DNS stuff..
<olafura> security groups
<olafura> sarnold: yes I think your right
<marcoceppi> olafura: sarnold so, right now we need an object store to place stuff, I think they're working on a way to get around this for providers that don't have it. Also, firewalling isn't required, it'd just mean that your isntances are exposed by default. Not something we would want but I'm nto sure if it's a deal breaker. Again, not a core dev can't speak to that
<sarnold> marcoceppi,olafura, thanks :)
#juju 2013-10-30
<thumper> marcoceppi: no, I don't recall and answer
<thumper> marcoceppi: just weirdness
<thumper> marcoceppi, sarnold: we have on our roadmap the ability to use juju where there is no storage api
<thumper> but it is down the line, closer to feb/mar next year at least
<sarnold> thumper: cool :)
<marcoceppi> thumper: for juju-plugins is the -e flag parsed in core or are all flags now passed to the plugin? (and is JUJU_ENV set by juju-core anymore)?
<BrianH> Hey guys, I'm really new to this and I'm running into a problem.  I have a MAAS server setup, and when I try to bootstrap juju, it keeps erroring with "ERROR could not access file 'provider-state': Get http://[old ip]/MAAS/api/1.0/files/provider-state/: dial tcp [old ip]:80: no route to host.
<thumper> marcoceppi: not sure, someone has "tweaked it"
<BrianH> The juju yaml file was changed to the new IP, but it's wanting to look at the old IP for some reason.  Thoughts?
<marcoceppi> BrianH: what version of juju?
<BrianH> marcoceppi: 3.2
<marcoceppi> BrianH: that version of juju does not exist, what does `juju version` say?
<BrianH> Oooh, sorry, 1.16.0-saucy-amd64
<BrianH> Setting up a Zentyal 3.2 server at the same time :P
<marcoceppi> BrianH: no worries! :)
<marcoceppi> BrianH: have you run `juju destroy-environment` ?
<marcoceppi> rather, try running that again
<marcoceppi> then bootstrap with --debug flag
<BrianH> Same error, but with the debug spam.
<BrianH> I'd have to switch my IRC client to the machine to pastebin the results.
<marcoceppi> BrianH: run destroy again, then tell me what the contents of ~/.juju/environments/ directory looks like
<BrianH> it has a maas.jenv file
<marcoceppi> BrianH: that's where it's getting the settings from. thumper shouldn't destroy-environment delete that? BrianH, delete that jenv file then bootstrap again
<thumper> yes destroy-environment should delete the jenv file
<marcoceppi> also, thumper, if I should bother someone else let me know. You're just an easy nick to remember ;)
<thumper> :)
 * thumper is just writing emails ATM
<BrianH> It's not deleting it.  Looks like it's filled with tons of old info in there (catted the file before deleting).  1 sec ...
<sarnold> BrianH: btw, the pastebinit package and program is really helpful :)
<BrianH> it attempted to retrieve tools, then errors out "ERROR cannot start  bootstrap instance: cannot run instances: somaasapi: got error back from server: 409 CONFLICT"
<BrianH> err, gomaasapi*, not somaasapi
<thumper> hah
<thumper> BrianH: we know what you meant
<marcoceppi> 409 conflict can mean a ton of things, likely it means there are no instances available for your user
<BrianH> instances on the MAAS?
<marcoceppi> BrianH: yes
<marcoceppi> BrianH: make sure you've got nodes enlisted and available for your user in the dashboard. Make sure you have your ssh keys, user authentication, etc all configured. Run destroy environment again (for good measure) make sure the jenv is deleted (if it's not we'll need to talk about getting that filed as a bug), bootstrap again with --debug and pipe it to pastebinit (which can be installed on all ubuntu distros)
<BrianH> I've done plenty of virtualization before (KVM, etc.) but this cloud stuff is so confusing, haha.
<marcoceppi> BrianH: the maas stuff can be a bit dodgy to get up and running at first
<BrianH> I haven't setup any nodes on the MAAS yet.  Do I need to do that first?
<marcoceppi> BrianH: yeah
<marcoceppi> BrianH: so, the way this works with MAAS+Juju is it's not like EC2 or openstack where juju will tell the provider to create a machine
<marcoceppi> BrianH: maas is designed to solve the problem "I have all this hardware and I want to use juju to drive it"
<marcoceppi> BrianH: so you must tell maas about your hardware/machines first, then juju will use the pool of available machines to deploy stuff to it
<BrianH> Ah, gotcha.
<BrianH> It's so hard to find "for dummies" tutorials on this stuff. :)
<marcoceppi> bootstraping requires a machine in the provider to do the orchestration. So if you don't have a machine inlisted you'll get a conflict from the maas api, aka "YOU ASKED ME TO DO SOMETHING AND I CAN'T"
<marcoceppi> BrianH: yeah, maas still has a bit of a learning curve to it unfortuantely
<hazmat> marcoceppi, how'd the reboot debug turn out?
<hazmat>  marcoceppi there's a bug in the last release re plugins not recieving JUJU_ENV
<marcoceppi> hazmat: I just realized that I have 1.15 bootstrapped, the log is basically empty
<hazmat> atm its a four layer lookup  (cli, env var, home env, env file default)
<hazmat> that gets duplicated in every plugin
<marcoceppi> hazmat: yeah, I was about to start writing a python plugin helper
<marcoceppi> that you can call to inherit an argparse that has the same stuff that the juju cli does, but I wanted to make sure that was expected behavior now and not a regression
<hazmat> olafura, if you need some guidance let me know.. but in truth things would probably be easier with a core plugin, pyjuju dev is basically dead, and support is questionable, but either way i'd be happy to help get you started.
<hazmat> marcoceppi, its a documented regression
<hazmat> marcoceppi, future plan versions should get JUJU_ENV var passed
<marcoceppi> hazmat: awesome
<BrianH> Hmm, the node is stuck "Commissioning".  Does this usually take a while?
<marcoceppi> BrianH: it can take a bit of time, IIRC this is maas doing some pxe booting stuff
<hazmat> marcoceppi, although they also need to support -e in that context,  core isn't parsing their args for them
<marcoceppi> hazmat: well it'd be easier to just write an argparse that read -e and default value was os.environ['JUJU_ENV']
<hazmat> marcoceppi, definitely
<hazmat> marcoceppi, didn't see a bug just filed 1246156 to ref the issue
<marcoceppi> hazmat: bug?
<marcoceppi> hazmat: awesome
<AskUbuntu> Need help configuing juju on Windows 8 | http://askubuntu.com/q/368232
<olafura> hazmat:  thank you for that, pyjuju is great for debugging at least for me. I want to get it into core plugin when I have worked out the kinds. I think a fork of goamz with Cloud Stack specific quirks and a juju provider with some ec2_uri and s3_uri configuration options is the best way to go.
<olafura> hazmat: I might commit some in logging functions through out juju-core so I can better see whats going wrong.
<marcoceppi> olafura: I think that's what --debug and --show-log are for
<BrianH> marcoceppi: I changed the IP address of my MAAS server and the web interface is barfing with an Internal Server error.  Any way I can fix this?
<BrianH> I tried restarting avahi-daemon, but still the same.
<marcoceppi> BrianH: uh, it's a django application, there's a configuration for it somewhere. It's been a wee bit of time since I've used maas
<marcoceppi> BrianH: you can try to run `sudo dpkg-reconfigure mass-cluster-controller`
<marcoceppi> BrianH: that should allow you to re-enter the settings
<olafura> maroceppi: I know  and they are very helpful, I was just warning that if I find somewhere it's missing and would help then I would commit. It looks like the Go code might have a better debugging code then the python version.
<marcoceppi> BrianH: err, maybe just run dpkg-reconfigure maas
<BrianH> Hmm, I ran the first one, entered the IP, still same error.
<BrianH> Same after dpkg-reconfigure maas
<marcoceppi> BrianH: what about dpkg-reconfigure python-django-maas
<BrianH> Same.
<BrianH> I'll try rebooting it.
<marcoceppi> BrianH: is there an /etc/maas* file/directory?
<BrianH> Yes
<marcoceppi> You managed to catch me just a few days before trying to build my own small maas cluster :\
<marcoceppi> BrianH: try searching through those files for the old IP and replace with the new ip
<BrianH> marcoceppi: Will do. I appreciate all the help. :)
<sarnold> heh, I'm lazy enough I'd aim for dpkg --purge and just start with a clean slate, hehe
<marcoceppi> sarnold: thought about that, but didn't want to bork anything he's got enlisted
<marcoceppi> sarnold: not sure how maas would handle that, though I guess it would just re-enlist it
<BrianH> marcoceppi: I don't have anything enlisted at the moment.  It's all virtualized, so it's easy to setup something too
<sarnold> marcoceppi: yeah, that'd be painful if much were using it.. but I figured renumbering the maas contrller wouldn't happen after it'd been in use for a while :)
<marcoceppi> BrianH: if that doesn't resolve it, then sarnold's suggestion of purge and start again might not be a bad idea
<BrianH> Cool beans.  I might just do that. :)
<marcoceppi> BrianH: also, what distro is the maas-master? precise?
<sarnold> marcoceppi: your approach has the benefit of -learning- how it works. :)
<marcoceppi> s/distro/release/
<BrianH> No, it's on saucy
<marcoceppi> BrianH: cool, saucy has a "better" version of maas
<BrianH> Ah, good to know. :)
<BrianH> I read there were lots of improvements from the LTS release, so I figured I'd try getting it running with Saucy first.
<hazmat> olafura, sounds good
<marcoceppi> BrianH: you can use the cloud-tools archive to get the most recent version of maas/juju on precise, but if you're on saucy that's fine (for now)
<BrianH> I'm just a poor college student trying to learn all this cool, amazing cloud stuff, haha.
<mhall119> is there any easy trick to make something run only on the first time a db-relation-joined happens for a particular database?
<marcoceppi> BrianH: ah, in which case, saucy will do fine for you
<hazmat> olafura, there's a sample bare-bones skeleton provider for core in https://code.launchpad.net/~fwereade/juju-core/provider-skeleton/+merge/189638
<mhall119> so that if I remove-relation and then add-relation again, it doesn't run again
<mhall119> this is for populating a database with initial data, but not over-writing existing data if it happens to rejoin
<hazmat> mhall119, store local state
<mhall119> or adding another unit
<marcoceppi> mhall119: you can use files in the $CHARM_DIR to indicate this, for instance after doing the operations `touch .db-populated` then have a check in for that file
<olafura> hazmat: Thank you I'll look at that
<BrianH> I probably have the most high tech home networks in my entire town (probably better than most small business around here too).
<hazmat> mhall119, ie. store some local state the first time x happens, and check if state before doing x again.
<mhall119> ok, so that's the usual way of doing it?
<mhall119> and what's the hook that is called when remove-relation happens?
<hazmat> mhall119, general case yes, specifics vary based on problem at hand.
<mhall119> dp-relation-removed?
<marcoceppi> mhall119: it gets a little trickier in a multi-unit layout. You'll probably need to devise a way to check the database if that's done
<hazmat> mhall119, db-relation-broken
<mhall119> thanks
<mhall119> marcoceppi: yeah, I have at least 2 instances of the django app connecting to one instance of the db
<hazmat> mhall119, what marcoceppi is key.. ie check the db as source of truth / sync between multiple units.
<marcoceppi> mhall119: I had this problem in the discourse charm, I ended up just having the charm run a query against postgresql to see if it had done the seed or not
<mhall119> only one set to be an admin node though, and only admin nodes setup the database, so that should be okay
<marcoceppi> mhall119: ah, then just touching a file to track state should suffice
<mhall119> marcoceppi: I can do that, write a custom django management command that checks the db and updates it if needed
<marcoceppi> mhall119: that'd be the fool proof, multi-peer, way of doing it
<marcoceppi> but if you design the charm to only have one admin node ever, then local state should suffice
<mhall119> it's designed to *expect* one admin node ever
<marcoceppi> the more I think about it, the more I want to recommend you write a task. What if you want to HA your admin nodes?
<mhall119> if somebody were to make two, it would behave in undefined buy very likely undesirable ways
<marcoceppi> mhall119: okay, well that parts up to you then, if admin isn't design to scale there's probably bigger issues to worry about
<mhall119> marcoceppi: If I understand the webops correctly, the admin node doesn't actually get exposed to the outside world, so it would never need HA
<marcoceppi> mhall119: well, it might want HA if the instance were to go away, then you'd possibly want failover so the nodes can talk to a new admin. But I'm just speculating, you know the service better than me (want to make sure you ahve all the info to make an informed descision)
<mhall119> marcoceppi: the code is the same, the only thing that makes the admin node the admin node is juju set admin_node=True that tells the charm to run syndb, migrate, and other DB setup commands
<mhall119> the non-admin doesn't talk to the admin, or vice-versa
<marcoceppi> mhall119: cool
<marcoceppi> mhall119: gotchya
<mhall119> so a state file should suffice for now
<marcoceppi> sounds like it
<BrianH> marcoceppi: heh, I just scratched the VMs for my server and node and rebuilding it from scratch.  I'll set the static IP from the getgo so this doesn't happen again.
<BrianH> marcoceppi: Btw, while setting up this new server, I discovered it's dpkg-reconfigure maas-region-controller for address changes.
<sarnold> :)
<marcoceppi> BrianH: awesome! good to know
<marcoceppi> BrianH: I know you mentioned a complicated home networking setup, so you may already know that maas will basically try to own it's own network and does addressing for nodes via dhcp
<BrianH> marcoceppi: Yep, I have my dhcp server running on a Zentyal server.
<marcoceppi> BrianH: right, but maas runs its own and assumes it is the controller of the network
<hazmat> maas can use an external dhcp server
<marcoceppi> hazmat: oh, cool. I wasn't sure
<hazmat> marcoceppi, afaicr its just don't install maas-dhcp and configure next-server for dhcp to point to maas or use avahi
<BrianH> marcoceppi: Ok, I have a new server and node setup.  It's still saying "Commissioning" under the status, but the node won't fire up (It's a VirtualBox VM, so I imaging I need to start it manually?).  When I start it and it attempts to PXE boot, I get an error about "Nothing to boot: No such file or directory"
<marcoceppi> BrianH: yeah, VirtualBox and maas don't play together because VirtualBox doesn't pxe boot
<BrianH> It sees the Next server and gets it's own IP.
<marcoceppi> BrianH: I tried this over a year ago with poor results: http://marcoceppi.com/2012/05/juju-maas-virtualbox/
<BrianH> Isn't there a VirtualBox PXE boot image?  I think it was iPXE?
<BrianH> I'm using that tutorial.
<marcoceppi> BrianH: right, it has PXE boot but not WOL
<marcoceppi> got those two mixed up
<BrianH> Ah, gotcha.
<marcoceppi> It's getting late over here, brain is slowing down
<marcoceppi> BrianH: I need to update this article with how to use vMAAS instead. Since MAAS has better virtual support build in (KVM/libvirt support)
<BrianH> marcoceppi: Nice, I'll keep an eye on it then.  I gotta crash for the evening (early day of classes tomorrow).  I appreciate all the help you've given.  Thank you. :)
<marcoceppi> BrianH: o/ have a good one
<sodre> Hi, I am trying to get juju to bootstrap on a fresh private OpenStack. I am having issues at the bootstrap level .
<marcoceppi> sodre: what version of juju are you using? `juju version`
<hazmat> sodre, could you pastebin your juju bootstrap -v --debug
<hazmat> output
<sodre> one sec.... its uploading ...
<sodre> http://pastebin.com/t0H8DVVG
<sodre> hazmat, the pastbin link is up.
<hazmat> sodre, thanks
<sodre> marcoceppi, it is 1.16
<sodre> I am running on saucy and trying to bootstrap a precise image.
<hazmat> sodre, and you have a precise image loaded into glance?
<sodre> I've used smoser's scripts to load up images into open stack.
<sodre> It created a bucket called simplestreams
<sodre> and yes, a bunch of images on glance.
<sodre> from oneiric to saucy. Both daily and released images.
<hazmat> sodre, can you try running $ juju sync-tools
<sodre> it failed, can I paste the error here ?
<hazmat> sodre, sorry could you re-run with -v  --debug and pastebin it
<hazmat> unless its a one liner.. its generally nicer to pastebin blocks
<sodre> okay. it goes in pastebin then.
<sodre> http://pastebin.com/BJJUrasS
<hazmat> sodre, so basically juju needs to find two pieces of info.. tools which it uploads and an image to run them on
<marcoceppi> sodre: there's a command pastebinit that you can install and pipe output to
<hazmat> both are located in a file format called simpelstreams
<hazmat> hmm
<hazmat> there's two commands .. one to generate tools simple streams, and another to generate the image simple stream.
<sodre> let me install pastebininit...
<sodre> okay.
<sodre> how do these two commands work ?
<hazmat> sodre, they basically stick a file into ostack swift with contents from either the upload or listing of tools (in the case of tools) or the an explictly passed in image id in the case of the image command
<hazmat> the image command is done as a plugin.. juju metadata -h
<hazmat> but... holding off on that for a moment
<sodre> okay.
<hazmat> sodre, the inability to list the bucket looks suspect in the last pastebin
<hazmat> sodre, how'd you install openstack?
<sodre> agreed . I can list them using swift without problems.
<sodre> I installed using JUJU/MAAS
<hazmat> hmm
<sodre> the only difference is that I am using radosgw
<hazmat> sodre, so from the first pastebin the issue is the need for cloud images for juju to find
<sodre> I agree, I can post the output of glance list-images.
<hazmat> the fact that its uploading tools again on bootstrap is suspect imo, but i think is just because of the lack of simplestreams metadata for the tools, but its not the fatal issue just annoying
<sodre> yes. I faced the same issue when bootstrapping MAAS
<sodre> glace image-list > http://paste.ubuntu.com/6327950/
<hazmat> sodre, try this (precise amd64 image) juju metadata generate-image -i 907ca55d-a2e4-47c5-b26b-4be12bd78ecc -r http://m1basic-05.vm.draco.metal.as:5000/v2.0
<sodre> okay
<sodre> boilerplace image metadata written to .juju...
<sodre> what is my "public" bucket ?
<hazmat> sodre, 'juju-dist' bucket
<sodre> okay.
<hazmat> sodre, from the first pastebin it looks like its looking here.. http://m1basic-04.vm.draco.metal.as:80/swift/v1/admin-juju/streams/v1/index.json
<sodre> that was the control-bucket
<sodre> I can create a juju-dist
<hazmat> sodre, it doesn't look like your public-bucket is setup correctly.. i believe juju is introspecting keystone metadata here.. the url its getting back is.. sodre, let's try that first
<hazmat> er.. is
<hazmat> swift://simplestreams/data/streams/v1/index.json
<hazmat> which isn't valid, so its not really  looking in juju-dist in this case
<sodre> okay..
<hazmat> sodre, we can try and fix that later, but first we can just drop the simplestreams data into your control-bucket at that location
<wallyworld_> hazmat: that genetate image command above is wrong
<wallyworld_> -r is region
<wallyworld_> -u is endpoint
<wallyworld_> looks like -r was being used with an endpoint url
<sodre> :) should i start again ?
<hazmat> wallyworld_, cool, maybe we should document it ;-)
<hazmat> wallyworld_, so -r RegionOne and -u http://m1basic-05.vm.draco.metal.as:5000/v2.0
<wallyworld_> hazmat: the doco is currently in the command when you do help, but real doco is a wip
<wallyworld_> yes
<hazmat> wallyworld_, cli help output sadly isn't an example of what a user needs to do.
<wallyworld_> yeah i know. doco is on the todo list
<hazmat> i'm way past EOD so i'm going to wander into the night.. sodre your in good hands with wallyworld_
<sodre> okay. Thanks hazmat!
<sodre> wallyworld_ : I am in the process of rerunning juju bootstrap. After that I'll upload the generated image metadata.
<wallyworld_> bootstrap won't work without the correct image metadata
<wallyworld_> both tools and image metadata needs to be in place for bootstrap to work
<sodre> correct. That is what hazmat was trying to fix for me.
<sodre> do you have a different way to go about it ?
<wallyworld_> tl;dr; you need to generate image metadata and upload to your private storage. tools will be synced automatically if not present and bootstrap should run
<wallyworld_> or you could upload the tools yourself, but best to let juju do it. i assume you are running 1.16?
<sodre> correct.
<sodre> I have a bucket called simplestreams
<wallyworld_> cool. so "juju metadata generate-images -i xxxxx -r region -u endpoint"
<wallyworld_> no
<wallyworld_> upload streams/v1/* to private storage
<sodre> any bucket in particular ?
<wallyworld_> the dir structure is analogoues to cloud-images.canonical.com
<wallyworld_> the root of the private storage i *think* from memorty
<wallyworld_> so when you run generate, you will have a streams/v1 dir somewhere
<wallyworld_> upload that tree to private storage
<sodre> it just gave out the .json files directly
<wallyworld_> then use validate-image command to ensure it is correct
<sodre> but I know what you mean now.
<wallyworld_> it has changed in recent builds so i might be misremembering exactly what 1.16 does
<wallyworld_> use validate-images before you bootstrap to make sure it is all ok, save wasting time
<sodre> it came back with an error.
<sodre> ERROR index file has no data for cloud {RegionOne http://m1basic-05.vm.draco.metal.as:5000/v2.0} not found
<sodre> ERROR exit status 1
<wallyworld_> is that from juju metadata validate-images?
<sodre> yes
<wallyworld_> can you paste your index file?
<hazmat> power2_mine.
<wallyworld_> also run with --debug
<wallyworld_> so i can see where it is trying to look
<hazmat>  power2_mine.
<sodre> okay
<hazmat> whoops
<hazmat> sorry
<wallyworld_> what's power2_mine?
<hazmat> atm its an old password ;-)
<sodre> index.json > http://paste.ubuntu.com/6328011/
<wallyworld_> lol
<hazmat> screen saver and multi-monitor fail
<wallyworld_> hazmat: i need to validate your account details and current password, can you send to me :-P
<wallyworld_> sodre: that index file looks ok, so it seems it is not being uploaded to the right place
<wallyworld_> sodre: can you run validate-images with --debug?
<sodre> validate-images --debug > http://paste.ubuntu.com/6328025/
<wallyworld_> sodre: where did swift://simplestreams.... come from? that's not right
<sodre> yeah.. good point.
<sodre> maybe I should clean my env again.
<hazmat> wallyworld_, that's probably from keystone as a default unconfigured value
<sodre> ahhhhh
<sodre> I had an old openstack.jenv laying around.
<wallyworld_> oh ok. keystone should not be returning anything for product-streams endpoint else juju will use it
<wallyworld_> yeah, those jenv files are a bit of a trap
<sodre> yeap.
<hazmat> wallyworld_, it looks like he could upload directly to the control-bucket 'admin-juju' not optimal but functional
<hazmat> ugh.. stale jenvs..
<wallyworld_> hazmat: yeah, right now, you do need to upload to control bucket
<sodre> alright. should I just get rid of the image-metadata-url from .jenv ?
<wallyworld_> yep
<jam> wallyworld_: sodre: wallyworld_: sodre: https://bugs.launchpad.net/goose/+bug/1209003
<_mup_> Bug #1209003: juju bootstrap fails with openstack provider (failed unmarshaling the response body) <openstack> <Go OpenStack Exchange:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1209003>
<jam> I'm off for a sec, but will be back in ~ 1 hr
<wallyworld_> jam: right now it's a simplestreams config issue. hopefully goose bug won't matter once that gets sorted
<sodre> jam: that  looks like some of the errors I am seeing as well.
<sodre> alright. Let me try again with a clean jenv.
<sodre> it looks like I posted it to the wrong place...
<wallyworld_> sodre: you only need image-metadata-url if you want to get tools from a place other than 1) your private cloud storage, 2) the configured endpoint in keystone
<sodre> latest validate-images --debug http://paste.ubuntu.com/6328061/
<sodre> Ideally I would like to host it internally. But right now I just want it to work :)
<wallyworld_> sodre: so, it looks like it can find the index file now. but there's a mismtach on region/endpoint. looks like endpoint in the json is http:// . are you sure it should not be https://
<sodre> I don't think the default install used https
<wallyworld_> it should be the same as your auth_url
<sodre> let me double check.
<sodre> it is http
<wallyworld_> hmmm. can you paste the whole output without the truncation?
<sodre> as per keystone catalog
<wallyworld_> it is expecting to match what is in your env file
<wallyworld_> are you using auth-url setting in env file?
<sodre> Okay. do you want the output of export ?
<sodre> or the output from openstackrc.sh ?
<wallyworld_> just the --debug when running the validate-images
<sodre> that was the whole output, 17 lines.
<wallyworld_> btw, the generate-images command in 1.16 was a prototype tool for developers, it wasn't intended for end users. but there's no easy way to do private clouds without it. it's much better in next release
<wallyworld_> sodre: looks like the log is truncated on the right edge though
<wallyworld_> oh wait
<wallyworld_> i missed the scrol bar
<wallyworld_> doh
<sodre> :)
<wallyworld_> sodre: so just to check, can you paste the content of http://m1basic-04.vm.draco.metal.as:80/swift/v1/admin-juju/streams/v1/index.json for me?
<sodre> this is the output after calling swift download admin-juju ....  > http://paste.ubuntu.com/6328095/
<wallyworld_> sodre: can you see the problem?
<wallyworld_> i can :-)
<sodre> ohhh
<sodre> :)
<sodre> Region region region :)
<wallyworld_> yeah :-)
<sodre> that's strange..
<wallyworld_> looks like that file was from the earlier wrong command
<sodre> argh...
<wallyworld_> where -r <endpoint> was used
<sodre> alright... getting better
<sodre> odre@ubuntu:~/.juju$ juju metadata validate-images
<sodre> matching image ids for region "RegionOne":
<sodre> 907ca55d-a2e4-47c5-b26b-4be12bd78ecc
<sodre> yay
<wallyworld_> yay \o/
<sodre> so, should I bootstrap now ?
<wallyworld_> why not. i can't recall if 1.16 had the tools syncing stuff in it
<wallyworld_> cause you could get the tools set up first
<wallyworld_> save the upload
<wallyworld_> i think it did
<sodre> it has some in there.
<wallyworld_> so, you can get the tarball you want
<wallyworld_> save locally to <dir>/tools/releases
<wallyworld_> juju sync-tools --source=<dir> --destination=<dir>
<wallyworld_> then upload <dir> tree to private storage
<wallyworld_> so private storage will have a tools dir in it
<wallyworld_> or you could just bootstrap with --upload-tools :-)
<sodre> I think it has one from the left-over bootstrap we did earlier
<wallyworld_> you could run validate-tools then
<wallyworld_> to see if juju can find them
<sodre> validated :)
<wallyworld_> \o/
<wallyworld_> so bootstrap should work hopefully
<wallyworld_> unless that goose bug gets in the way
<sodre> alright...
<sodre> I forgot to run with debug
<wallyworld_> oh, did it fail?
<sodre> well..
<sodre> it tried to start it with a m1.tiny.
<sodre> and that gave an error.
<sodre> but we had a lot of progress.
<wallyworld_> yeah, there's a potential bug selecting a large enough instance type. use a constraint
<wallyworld_> --constraint mem=1024 for example
<wallyworld_> add that to bootstrap command
<sodre> okay, if I control-c  bootstrap how do I get it to run again ?
<wallyworld_> bootstrap should return quite quickly
<wallyworld_> you could juju destroy-environment, BUT that will also delete tools and image metadata
<wallyworld_> what i would do is
<wallyworld_> kill the bootstrap machine manually using nova cli
<wallyworld_> then remove the provider-state file which juju put in private storage
<wallyworld_> that will allow you run run bootstrap again
<hazmat> sodre, wallyworld_, and kill the  jenv again
<sodre> okay.
<wallyworld_> the jenv can stay i think?
<hazmat> wallyworld_, it refs the old instance id i think
<wallyworld_> cause it has cached the env stuff, no need to delete it
<wallyworld_> ok, won't hurt
<sodre> jenv gone.
<wallyworld_> in the past, i haven't needed to delete it i don't think, but better be safe
<hazmat> wallyworld_, your right, its fine for this provider type
<sodre> how is juju handling neutron networks? Does it create one by default ?
<wallyworld_> ok. so many gotchas to keep track of :-)
<hazmat> wallyworld_, manual provider was the one it caused issues with for me in this same context.
<wallyworld_> sodre: we haven't done anything to support neutron yet afaik. it's a work in progress
<wallyworld_> unless i'm misunderstanding the current state of play
<hazmat> sodre, its not really doing anything with them atm, it assumes a private network for the instances to talk among, and a public net (or floating ips)..
<sodre> okay. so every instance will connect directly to the ext-net
<hazmat> we've got plans to address for 14.04 with first class network support (vpc, neutron, vlan, etc)
<lifeless> nova can be setup so that neutron is transparent
<lifeless> should keep things working for people
<wallyworld_> lifeless: !
<hazmat> lifeless, long time :-)
<wallyworld_> hi
<lifeless> wallyworld_: hazmat: o/
<hazmat> lifeless, see you next week :-)
<lifeless> hazmat: most excellent
<sodre> i guess my setup is not that way yet.  the instance only got a floating ip
<wallyworld_> what openstack release supports neutron transparently?
<lifeless> sodre: no internal address ?
<lifeless> wallyworld_: Grizzly and Havana and Icehouse
<wallyworld_> excellent, thanks
<lifeless> wallyworld_: it's a config issue though
<lifeless> wallyworld_: see the default_floating_pool nova setting
<sodre> lifeless: yes,
<wallyworld_> yeah, in the past we've had to assume lcd
<lifeless> if thats wrong, and the default value is 'nova' but the example used in the all the admin guides for neutron calls it 'ext-net', then nova will refuse to do floating ip operations
<lifeless> wallyworld_: separately there is a nova setting to auto-allocate floating ips to instances
<lifeless> that defaults off
<wallyworld_> ok
<lifeless> without that instances by default end up with no floating/public ip
<sodre> here is the pastebin http://paste.ubuntu.com/6328157/
<wallyworld_> sodre: i've not seen that error before. openstack networking is not my strong point
<wallyworld_> sodre: you could try use-floating-ip=false
<wallyworld_> in juju env config
<sodre> yeah, let me try again.
<lifeless> No nw_info cache associated with instance <- thats a new one
<lifeless> it's being thrown from the nova virt rpcapi manager
<lifeless> [or near tere, I haven't grepped for it yet]
<sodre> I just needed to have a local network setup before calling bootstrap
<sodre> Guys, Thank you so much.
<sodre> I would not have been able to figure all this out on my own .
<sodre> I am having issues with the image booting up but I think they are all on my end
<wallyworld_> sodre: no problem. the tooling and doco associated with setting up a private cloud is very much a work in progress. it works if done correctly, but the doco is not finished yet. next release will be better
<sodre> wallyworld_: Thanks a lot. Is there a place where the wip document is located?
<wallyworld_> sodre: right now, wip = no doc except for "juju help <foo>" sorry
<sodre> np.
<wallyworld_> so the commands have help but there's no end user task oriented doc
<sodre> ic... well .. thanks again !
<wallyworld_> anytime
<sodre> about moving the tools and and streams to their own dedicated buckets...
<sodre> once that is done, it is just a matter of changing tools-url and image-metadata-url , right ?
<wallyworld_> yeah
<sodre> is there an easy script to mirror the s4 juju-dist bucket ?
<wallyworld_> set up a publicly readable bucket
<sodre> s/s4/s3/
<wallyworld_> that is going away real soon, and streams.canonical.com will take its place
<wallyworld_> and mirroing will just be an rsync
<sodre> nice.
<wallyworld_> if you can hang on a week or so.....
<wallyworld_> not sure the exact time, but rsn
<wallyworld_> it will coincide with release of juju 1.18
<sodre> when is 1.17 coming out ?
<melmoth> hola juju crowd.. I have a problem with 1.14.0-0ubuntu1~ubuntu12.04.1~juju1. I need to set a config-flag for the nova-cloud-controller charm.
<wallyworld_> soon. we will release that as a 1.18 beta if you like
<melmoth> i try: juju set nova-cloud-controller config-flags="scheduler_default_filters=AggregateInstanceExtraSpecsFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter"
<melmoth> but nova.conf on the machine end up with only scheduler_default_filters=AggregateInstanceExtraSpecsFilter
<wallyworld_> try using "" around the filters value?
<wallyworld_> just a guess
<melmoth> i first try \, , and this was a disaster
<sodre> wallyworld_: have a good rest of day back in your TZ.
<wallyworld_> sodre: will do :-) let us know if you need anything else
<melmoth> there are 2 nova-cloud-controller (haclustercharm subordinate), and one unit ended up with config error that i could not sovled (no realtion id error each time i try a new juju set)
<sodre> thanks I'll stop by again.
<melmoth> i had to destroy the unit and redeploy it again.
<wallyworld_> melmoth: i'm not sure of the answer to your question. marcoceppi  are you around to help out?
<melmoth> marcoceppi, if you are around this is with some folk you already met (remember the land of the rising sun ? :-) )
<smoser> sodre, wallyworld hazmat, fwiw, the 'example-sync' that sodre ran specifically creates metadata in swift bucket.
<smoser> so that juju should just need to be pointed at that.
<smoser> (or the target 'swift' output  made to match)
<smoser> also an option is to register that endpoint in keystone (swift path) and then juju will find it there.
<smoser> that is how canonistack works.
<adeuring> sinzui: https://code.launchpad.net/~adeuring/charmworld/more-heartbeat-info/+merge/193248
<sinzui> thank you adam_g
<sinzui> thank you adeuring
<smoser> so in ceph charm, where does 'charm' command come from (in Makefile).
<ehw> racedo:/win 27
<smoser> jamespage, ^ ?
<ehw> doh
<jamespage> smoser, oh
<jamespage> smoser, charm-helpers itself - that bit sucks alot right now
<jamespage> smoser, no
<jamespage> sorry
<jamespage> charm-tools
<jamespage> charm proof right?
<freephile> I have a "local" environment but I can't connect to it - and I think it's because I ran out of disk space.  How can I clean up if I can't connect?
<freephile> provider-state: dial tcp 10.0.3.1:8040: connection refused
<marcoceppi> smoser: the charm command is from charm-tools
<marcoceppi> freephile: that means that the API service or db service isn't running, what does `initctl list | grep juju` show?
<smoser> marcoceppi, so install that from archive ?
<marcoceppi> smoser: in saucy it's good, otherwise install from ppa:juju/stable
<freephile> marcoceppi: juju-db-root-local stop/waiting juju-agent-root-local start/running, process 1145
<smoser> saucy... pfft.
<smoser> trusty man.
<marcoceppi> smoser: trusty is good too :)
<rick_h__> lol smoser
<marcoceppi> smoser: basically you want charm-tools > 1.0
<smoser> charm tools depends on juju core ?
<marcoceppi> smoser: recommends, I believe
<smoser> ah. probably.
<marcoceppi> since it's also a juju plugin, via `juju charm`
<smoser> recommends == depends for all practical purposes
 * marcoceppi nods
<freephile> marcoceppi: do I start with (as root) 'service juju-db-root-local start'
<marcoceppi> freephile: sorry, yes sudo start juju-db-root-local
<marcoceppi> then run juju status again
<marcoceppi> or whatever command failed
<freephile> if I start the db service, it immediately stops (because I'm out of disk space).
<freephile> I tried 'start juju-db-root-local && juju ssh opengrok/0 initctl stop opengrok-index'
<freephile> to no avail
<marcoceppi> freephile: ohh, you're going to need to free up some disk space
<marcoceppi> freephile: if you can't trim files (say, zeroing out ~/.juju/local/log/*.log files) etc, you can just destroy the opengrok unit with lxc commands
<sinzui> adeuring, r=me. coordinate your change to Approved with bac. he is giving trunk to juju-gui-bot now
<sinzui> adeuring, I had some suggestions for a follow branch
<adeuring> sinzui: thanks
<jcastro> evilnickveitch, hey, apparently you got a submission on bundles for the docs?
<freephile> marcoceppi: thanks, I zeroed out the log files (was wondering about that) but it wasn't enough apparently to get the db to stay up.  I'll check into lxc commands
<marcoceppi> freephile: you'll want `sudo lxc-ls --fancy`, then `sudo lxc-destroy -n <name from ls command>`
<adeuring> sinzui: featured is already covered by "API(2|3) interesting", I think
<marcoceppi> freephile: after you clear up disk space, start the juju db then run juju destroy-environment to get the rest of the deployment cleaned up
<evilnickveitch> jcastro, i do, yes
<sinzui> adeuring, it is not
<jcastro> evilnickveitch, do you have it anywhere I can look at it? branch or something?
<adeuring> sinzui: so, you think it should get its own status? Or am I missing something else?
<sinzui> adeuring, API2/3 can fail for 3 or more reasons. Knowing specifically that featured is empty on staging is fast fix.
<evilnickveitch> jcastro, i have a google doc
<bac> adeuring: please do not land to charmworld right now.
<adeuring> bac: ok, tell me hwen i can land it
<sinzui> adeuring, juju-gui (staging and production) needs to fail when those collections are empty. We we setup a new env, charmworld is still in a bad state after the first ingest because we are often missing human created data
<freephile> marcoceppi: Success!!! `lxc-ls -l; lxc-stop -n root-local-machine-2; lxc-destroy -n root-local-machine-2; start juju-db-root-local; juju status;`
<marcoceppi> freephile: cool, you'll find that opengrok service is in a down state (obviously, as you destroyed it) but you should be able to destroy the environment and recreate it
<marcoceppi> etc
<bac> adeuring: go ahead and land charmworld as before.  then hold off any more.
<adeuring> bac: ok, thanks
<adeuring> bac: done
<smoser> hey.
<smoser> so i just manually manage 'revision' file ?
<marcoceppi> smoser: no
<marcoceppi> revision file is only used for local deployments, and it should be incremented automatically by juju
<marcoceppi> smoser: infact you can add it to .bzrignore
<marcoceppi> jcastro: CHARM SYNC
<marcoceppi> o/
<jcastro> yep
<jcastro> firing it up
<jcastro> wanna seed the pad?
<marcoceppi> woo who
<marcoceppi> jcastro: yup
<mthaddon> evilnickveitch: https://juju.ubuntu.com/docs/authors-charm-writing.html "The README is a good place to make nots about how the charm works" <-- should I file a bug about that, or is it okay to have just mentioned it here?
<jcastro> evilnickveitch, misfire, one sec.
<jcastro> https://plus.google.com/hangouts/_/7acpicbshl5mtk1tqjntg4g30k?authuser=0&hl=en
<jcastro> evilnickveitch, arosales ^^
<marcoceppi> jcastro: http://pad.ubuntu.com/7mf2jvKXNa
<smoser> marcoceppi, i asked about 'revision' because 'charm proof' complained 'ERROR' in its absense.
<mhall119> halp!
<mhall119> mhall@mhall-thinkpad:~$ juju status
<mhall119> ERROR Unable to connect to environment "local".
<mhall119> Please check your credentials or use 'juju bootstrap' to create a new environment.
<mhall119> Error details:
<mhall119> Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused
<adam_g> sinzui, are there PPA builds of 1.16.1 somewhere?
<mhall119> mhall@mhall-thinkpad:~$ sudo juju bootstrap
<mhall119> Swipe your right index finger across the fingerprint reader
<mhall119> ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused
<sinzui> adam_g, they are not yet. We are looking into an azure issue that first blocked the test, and now looks like a fix is needed for 1.16.1
<sinzui> adam_g, I am off to lunch. I can arrange a package for you if you need one today
<mhall119> jcastro: juju is broken
<jcastro> what's up?
<mhall119> see my errors above
<mhall119> I can't even bootstrap a local env
<jcastro> can you pastebin the `sudo juju --debug bootstrap`?
<jcastro> mhall119, you're in luck, marco and I are working on a troubleshooting the local provider document
<jcastro> and by luck I mean "haha".
<mgz> mhall119: a good first step is to delete any misc .jenv files in ~/.juju/environments and try again
<mhall119> mgz: \o/ that seems to have done the trick
<jcastro> \o/
 * mhall119 tries deploying again
<marcoceppi> smoser: that's been fixed in 1.1 which should be released tomorrow
<marcoceppi> mhall119: jcastro: https://bugs.launchpad.net/juju-core/+bug/1246429
<_mup_> Bug #1246429: destroy-environment no longer removes .jenv <juju-core:New> <https://launchpad.net/bugs/1246429>
<mhall119> thanks marcoceppi
<marcoceppi> I was about to say "Hey I can't replicate this!" But then I realized I'm on 1.15.1 :)
<sodre> smoser: can I talk to you about simplestreams
<smoser> sodre, i've got a few minutes.
<smoser> whats up?
<sodre> I was trying to run your script last night. The found an issue with the integration with radosgw
<sodre> s/The/I
<smoser> hm.. ok.
<sodre> my question: is there a particular issue whey you call _strip_version?
<sodre> s/whey/why/
<sodre> this is on line openstack.py:98
<smoser> sodre, that is copied from other clients that do it.
<smoser> what is the problem with doing that ?
<sodre> It does not work with the default ( juju deployed ) ceph-radosgw charm.
<sodre> If I don't strip the version, then your code works fine.
<smoser> hm..
<sodre> smoser: still thinking ?
<smoser> sodre, sorry. on a call now.
<sodre> alright np.
<sodre> let me know when we can chat about that bug.
<mhall119> jcastro: is there any easy way to condense 'juju status' to just the really useful details?
<mhall119> I want to 'watch "juju status"' to see things changing, but it's more than will fit on my terminal
<sodre> mhall119: same problem here ....
<marcoceppi> mhall119: sounds like you want to write a plugin
<marcoceppi> mhall119: like what, you just want a list of units and their status?
<mhall119> yeah
<marcoceppi> mhall119: hold up, let me try something
<sodre> have you tried watch 'juju status | grep state' ?
<sodre> the quotes are important.
<mhall119> sodre: that doesn't give me the unit though
<sodre> yeah, we need a better 'grep' '
<marcoceppi> mhall119: sodre: it's time to introduce you to plugins, give me just a few more mins I'll have a working example
<sodre> :) nice
<jcastro> mhall119, I do `juju status wordpress` or whatever to get each one
<jcastro> I have long wanted
<jcastro> juju top
<jcastro> with an htop looking view of stuff
<mhall119> +1
<marcoceppi> mhall119 jcastro sodre drop this in a directory in your path: http://paste.ubuntu.com/6331880/
<marcoceppi> once it's in path, juju prettyprint will produce that, you should be able to watch it from there
<marcoceppi> come onnnnnnn pastebin
<marcoceppi> mhall119: sodre https://gist.github.com/marcoceppi/7238964
<marcoceppi> With more time you could easily make a juju top command which could poll the API and present useful data about services, units and machines much like htop
<jcastro> yeah, it's just a manpower issue
<jcastro> no one's going to drop working on HA to work on juju top, heh
<marcoceppi> exactly. So I have just empowered two users to use and abuse plugins
<jcastro> It'd be a nice low hanging fruit for a new person though
<marcoceppi> now we just need to wait for mhall119 to submit his juju top plugin :)
<marcoceppi> (python-jujuclient exists as a pyton library for talking to the API, hint hint wink wink)
<jcastro> stealing client people won't happen either, I've already tried that
 * marcoceppi twiddles thumbs
<sodre> I like it :)
<sodre> it crashes at first since I have nothing on open-ports. but I got the gist.
<marcoceppi> sodre: ahh, yeah public-address will mess it up too. You'd just have to add sanity checks in there
 * marcoceppi does the quick and dirty script
<marcoceppi> "use at your own risk"
<sodre> thanks for pointing out how I can put it together.
<marcoceppi> sodre: yeah, you can run `juju help plugins` to get an idea of plugins you have installed and what not
<marcoceppi> they're an under publicised feature of juju
<sodre> ahhh
<sodre> that's where the metadata and deployer show up.
<marcoceppi> sodre: same with charm-tools if you have that installed `juju charm`, etc
<marcoceppi> really it's basically juju-<subcommand> if it doesn't exist in core but that binary exists, juju core just passes everything on to it
<marcoceppi> exactly like git and bazaar plugins
<sodre> ic
<arosales> jcastro, so to double confirm on charm bundles
<marcoceppi> so bundles are pretty cool
<jcastro> ok so I have .... 5 bundles right now
<jcastro> liferay
<arosales> while policy is properly defined bundles will be "featured" in the gui but just under your name space. Is my understanding correct?
<arosales> jcastro, ^
<jcastro> "scalable jenkins" which is one jenkins with 3 slaves
<jcastro> scalable mediawiki with a load balancer
<jcastro> a simple mediawiki
<jcastro> and wordpress
<jcastro> arosales, yes, I'm about to push the first one
<jcastro> and then we'll see how it gets indexed
<arosales> jcastro, cool thanks for confirming on that
<marcoceppi> jcastro: will you be able to promote non "promulgated" bundles?
<jcastro> I am asking bac that now
<marcoceppi> jcastro: dude, can you test charm-tools 1.1 for me?
<marcoceppi> and just `charm proof --bundle` each of the bundles you're writing?
<jcastro> oh, yeah!
<jcastro> PPA?
<marcoceppi> jcastro: because you're definitely doing it wrong
<marcoceppi> jcastro: it'll be a manual install, let me update the URL and I'll give you a link
<jcastro> ok guys, so featuring a bundle will be the same as a charm
<jcastro> we go into manage.jujucharms.com and check the box
<jcastro> it'll ingest the first bundle in ~15 or so, then we can mess with it
<jcastro> marcoceppi, hey so bac tells me that we'll also need to promulgate the bundles
<jcastro> so we'll need charm tools updated
<marcoceppi> it has promulgate support
<marcoceppi> <3
<jcastro> for bundles?
<jcastro> <3
<marcoceppi> yes
<bac> sweet
<jcastro> oh, you mentioned it during the status call, I remember now
<jcastro> marcoceppi, ok so I'll test your proof tool
<jcastro> then push
<jcastro> we'll wait 15 for them to seed in the store
<jcastro> then you can promulgate?
<marcoceppi> yes
<marcoceppi> jcastro:
<jcastro> I'll push my discourse one up too, but not promulgate it
<marcoceppi> bzr branch lp:~marcoceppi/charm-tools/bundle-support charm-tools; cd charm-tools; python setup.py install
<marcoceppi> err
<marcoceppi> bzr branch lp:~marcoceppi/charm-tools/bundle-support charm-tools; cd charm-tools; sudo python setup.py install
<marcoceppi> jcastro: then you should be able to juju charm proof --bundle /path/to/bundle/directory
<marcoceppi> well, you can ommit the --bundle flag, it'll detect a bundle automatically
<rick_h__> and then the fury of the proof'er will come down upon you!
<marcoceppi> rick_h__: I was looking over his branch, saying to myself "yeah, this is a great test case for proof"
<rick_h__> lol
<rick_h__> marcoceppi: so heads up, we're actually going to work on pulling in the deployer to do bundle proofing. Share the same exact bits as much as possible. So heads up that new stuff should pop up even though you don't update the charm-tools
<marcoceppi> rick_h__: that's fine and perfect
<jcastro> marcoceppi, http://pastebin.ubuntu.com/6331983/
<jcastro> I tried different permutations
<rick_h__> lol
<marcoceppi> rick_h__: the only thing I'm really checking for in the deployer file is annotations
<marcoceppi> jcastro: because it's not a valid bundle
<rick_h__> marcoceppi: rgr, just more an FYI because people will fail proof and probably come chat with you/this channel
<marcoceppi> the error message isn't clear though, it looks for "bundle.json or bundle.yaml"
<marcoceppi> which are the only two files supported
<marcoceppi> rick_h__: I'll make sure it displays warnings as well
<marcoceppi> from the api
<rick_h__> marcoceppi: cool
<jcastro> so is that a bug in the tool or are we expecting everyone to name things bundle.yaml
<marcoceppi> jcastro: I'll update so that when you use --bundle flag and it detects not a bundle it'll say "Not a bundle because no bundle file (.json or .yaml) found"
<rick_h__> jcastro: expecting them to name it bundle.yaml
<marcoceppi> jcastro: the GUI expects bundle.*
<marcoceppi> it's a bug in that the message to the user is misleading (and ugly exception traceback)
<jcastro> same errors when I rename it to bundle.yaml
<jcastro> also, daddy needs autocompletion!
<marcoceppi> jcastro: well daddy can submit a merge req :)
<marcoceppi> jcastro: one second, let me branch your branch
<jcastro> I hope the bundle is valid, because I got it from the gui
<jcastro> if not, we have other problems, heh
<marcoceppi> jcastro: where is your branch?
<rick_h__> jcastro: no, we've got chances to excel :)
<rick_h__> jcastro: rename the envExport to 'wordpress' as well please
<marcoceppi> rick_h__: yeah, I was hoping proof would pick that up
<rick_h__> jcastro: we've got a bug to change that to ask you for a name on export, but must not have made it yet
<marcoceppi> jcastro: please don't name it wordpress
<rick_h__> marcoceppi: we don't, it's valid
<marcoceppi> rick_h__: my proof will
<rick_h__> marcoceppi: but yea, we want to fix the gui export to not keep reusing the same name
<rick_h__> marcoceppi: oh, cool then.
<jcastro> https://code.launchpad.net/~jorge/charms/bundles/wordpress/bundle
<jcastro> branch is here
<jcastro> sorry it's so convoluted. I miss _one lousy_ session
<jcastro> and this is what you come up with rick
<jcastro> might as well add some plusses and whitespace to the url
<rick_h__> lmao, to which url? the LP branches?
<jcastro> yeah, seriously, who is going to remember this url?
<jcastro> this is bws-readme all over again
<marcoceppi> jcastro: it needs be called bundles.yaml
<marcoceppi> rick_h__: correct?
<jcastro> bundles with an s?
<marcoceppi> what's the file name plurarl or singular?
<marcoceppi> I'm currently looking for pluarl
<marcoceppi> I'm also looking for a new spell checker
<jcastro> plural doesn't work either
<rick_h__> marcoceppi: bundles.yaml
<rick_h__> is that we're looking for
<rick_h__> in ingest
<rick_h__> jcastro: user's should never see the url tbh
<marcoceppi> jcastro: it works for me but I get a weird error from remote proof
<jcastro> ok so what will the final cli command look like for deploying a bundle?
<rick_h__> jcastro: they go to the gui and either get a UI to pick the one, or they get a bundle:~jcastro/wordpress/5/wordpress url
<jcastro> also, if not wordpress, what do I name envExport?
<marcoceppi> jcastro: something more descriptive than wordpress, you're creating a solution
<marcoceppi> jcastro: so if it's just wordpress + msyql and default config you've created a solution not many people would want imo
<marcoceppi> wordpress-simple is a good start
<jcastro> got it
<jcastro> rick_h__, but the gui doesn't support colocation yet
<marcoceppi> the name should describe what you've solved
<jcastro> so for a bunch of these one shot bundles they'll need to CLI
<rick_h__> jcastro: not showing it no, but it should 'work'
<jcastro> marcoceppi, got it
<jcastro> marcoceppi, that's what I was naming the yaml files
<jcastro> like simple-wordpress.yaml
<marcoceppi> jcastro: yeah
<marcoceppi> this is what I was talking about
<marcoceppi> that bundles.yaml file can have MULTIPLE bundles in it
<jcastro> rick_h__, is there a way I can do `juju deploy bundle:~jorge/wordpress` without all the other stuff?
<marcoceppi> so you can have a wordpress branch, with a bundles.yaml that has simple-wordpress, scaled-out-wordpress, etc
<jcastro> oh!
<rick_h__> jcastro: yes, that's what quickstart is for
<rick_h__> juju quickstart bundle:~jcastro/...
<jcastro> but I can't make that in the GUI, I'd have to make them individually and them combine them into one file
<rick_h__> jcastro: right
<jcastro> rick_h__, right, so when does that land in relation to bundles?
<rick_h__> jcastro: the gui only handles one at a time
<rick_h__> jcastro: along-side-ish? I'm not 100% sure. It's almost working now
<jcastro> ok so what happens as of today if I drag a multiple environment yaml file into the GUI?
<rick_h__> jcastro: it tries to deploy them
<rick_h__> until they collide "You've already got a wordpress installed" and then dies
<bcsaller> no, it fails if there is more than one target in the file
<bcsaller> it can ask for a named target, but there is no UI around that now
<jcastro> ok so for now they'll have to be individual bundles
<rick_h__> bcsaller: oh, right. I was thinking if you did multiple drags
<jcastro> simple-wordpress, HA-wordpress, and so on?
<rick_h__> jcastro: yes
<marcoceppi> jcastro: fixed charm-tools, bzr pull, run install again
<jcastro> marcoceppi, got it
<jcastro> W: No readme file found
<jcastro> E: envExport is the default export name. Please use a unique name
<jcastro> E: envExport: Could not find charm: wordpress
<jcastro> E: envExport: Could not find charm: mysql
<jcastro> Yeah!
<jcastro> now we're getting somewhere
<marcoceppi> jcastro: I'm working with rick_h__ on why it says can not find charm
<marcoceppi> the first two are valid issues
<jcastro> on it
<jcastro> rick_h__, man, if at some point today I have to add a -HEAD to the end of one of these commands .... *eyes narrow*
<smoser> ok.
<smoser> stupid person here.
<smoser> $ bzr push lp:~smoser/charms/precise/maas-region
<smoser> bzr: ERROR: Permission denied: "~smoser/charms/precise/maas-region/": : Cannot create branch at '/~smoser/charms/precise/maas-region'
<rick_h__> jcastro: not at all
<smoser> what shoudl that be ?
<marcoceppi> smoser: add /trunk to the end of it
<rick_h__> jcastro: it's a new feature, bug is in there.
<smoser> ah.
<smoser> gracias
<marcoceppi> it's user/project/series/package/branch
<jcastro> ok wordpress is done, hopping on a call with kirkland, and I'll finish up the rest.
 * kirkland high fives jcastro 
<jcastro> rick_h__, what url can I monitor to see when the bundle gets ingested?
<rick_h__> jcastro: http://manage.jujucharms.com/search?search_text=jcastro&op=
<rick_h__> jcastro: right now it will have failed due to the file name
<jcastro> rick_h__, sorry for being annoying, you know how near and dear simple URLs are to my heart.
<jcastro> I just commited a fix with the rename
<rick_h__> jcastro: so a push up with that fixed should get it ingested
<rick_h__> jcastro: cool
 * jcastro nods
<rick_h__> jcastro: I'm with you, but the urls for branches in the series and crap is waaaay out of my hands.
<jcastro> yeah I get it
<marcoceppi> thumper: is there a short flag for --debug?
<marcoceppi> or is it only in long form?
<thumper> only long at this stage
<marcoceppi> ack
<rick_h__> jcastro: the versionless cs: urls are breaking it atm. We *want* to support it so will have to update charmworld
<rick_h__> jcastro: if you put the versions back in it'll work ok and proof. I'm starting a branch to figure out a way around the versionless issue now
<rick_h__> marcoceppi: ^
<marcoceppi> rick_h__: ack, thanks!
<rick_h__> marcoceppi: have a fix, Will get it reviewed and landed tomorrow. Can verify on staging sometime then
<marcoceppi> rick_h__: cool cool, I'll release charm-tools regardless after I iron out a few things here
<marcoceppi> since that's all remote proof
<rick_h__> marcoceppi: +1 appreciate it
<jcastro> rick_h__, ok so is it ok if I push versionless now?
<rick_h__> jcastro: yea, we're not proofing, just it'll continue to fail marcoceppi's proof tool until this lands on production
<jcastro> that's fine
<jcastro> hmm, no ingestion yet?
<mramm> thumper's blog post about his logging library for Go is now up on hacker news: https://news.ycombinator.com/item?id=6643805
<marcoceppi> hazmat: How does juju-deployer determine the bootstrap IP addresses for using the jujuclient?
<hazmat> marcoceppi, its going to move to api-endpoints in the future
<hazmat> marcoceppi, atm its using juju status
<marcoceppi> hazmat: ah, gotchya
<hazmat> marcoceppi, you trying to use the api direct?
<hazmat> er jujuclient direct
<marcoceppi> hazmat: yeah, was going to try to
<hazmat> marcoceppi, cool
<marcoceppi> hazmat: but I don't know how to find the bootstrap IP address without first running juju status
<marcoceppi> is it in the jenv file?
<hazmat> marcoceppi, juju api-endpoints
<marcoceppi> magic
<marcoceppi> hazmat: thank you!
<hazmat> marcoceppi, i added that for explicitly this purpose ...
<hazmat> np
<marcoceppi> <3
<sodre> guys, I am facing an issue with juju bootstrap  not setting up my password
<hazmat> sodre, you mean your ssh key?
<sodre> yes
<sodre> I can paste the vm boot-log
<sodre> http://paste.ubuntu.com/6332775/
<hazmat> sodre, that's a nice one..
<sodre> yeah :)
<hazmat> sodre, that's a go panic trying to set the mongodb password. its basically your admin-secret from the environments.yaml
<sodre> ahhh
<sodre> it needs to be complicated, right ?
<hazmat> sodre, well not really, it needs to be sized under 30 characters i think
<sarnold> (note there's a "-----BEGIN RSA PRIVATE KEY-----" in that paste, I hope it's ephemeral data...)
<hazmat> its just a random string in this mostly..
<hazmat> sarnold, it is.. if the environment is.
<sodre> yes, the environment was random
<sarnold> yay :)
<sodre> sarnold: thanks for pointing it out.
<hazmat> its part of the auto generated ca and server cert juju setups for th enev
<hazmat> sodre, i'd re-try with a random 10 digit string
<sodre> yeap. I am doing that right now. I think I had read about that ''feature'' before.
<hazmat> sodre, i thought it was size validated.. but maybe not..
<sodre> Most people don't see this issue because the environment is generated.
<sodre> I wrote mine by hand, so that is why it happened.
<sodre> humm... same error
<hazmat> sodre, hmm
<sodre> let me do a generate
<sodre> and try again.
<hazmat> sodre, its get stored in jenv
<hazmat> if your yanking
<hazmat> destroy-env clears that though
<sodre> I deleted that by hand, I think
<sodre> hazmat: same issue even with a random long password
<wallyworld__> sodre: maybe you can update the bug with any additional info?
<sodre> will do
<sodre> what would you need ?
#juju 2013-10-31
<ekacnet> is juju none and juju local supported in saucy
<ekacnet> I have the feeling it's hasn't been really tested
<sarnold> probably the ppa is better tested; 'none' is quite new, 'local' is better tested..
<ekacnet> ok doing the opposite local -> "null" works much better
<ekacnet> stupid question, can I install charms on the boostrap machine ?
<sarnold> ekacnet: using 'local', yes; probably 'null' can do it, but I've not tried that
<Azendale> can someone explain to me what functions the bootstrap juju machines does? It seems like the VM image comes from the cloud system (like MaaS). Does the bootstrap machine serve configs? Help setup relations between charms or something?
<ekacnet> 2013-10-31 06:29:22 ERROR juju.tools list.go:113 cannot match tools.Filter{Released:false, Number:version.Number{Major:0, Minor:0, Patch:0, Build:0}, Series:"saucy", Arch:"amd64"}
<ekacnet> bootstraping "null" didn't seems to work too well
<jcastro> evilnickveitch, I found broken local examples
<jcastro> MP incoming
<smoser> ok. stupid question.
<smoser> juju deploy --repository... local:my-charm
<smoser> charm sucked. want to undeploy and try again.
<smoser> can i delete ?
<smoser> (other than with juju destroy-environment)
<hazmat> smoser, juju destroy-service my-charm
<hazmat> smoser, juju terminate-machine whatever-machine-it-was-on
<smoser> $ juju destroy-service maas-region
<smoser> $ echo $?
<smoser> 0
<smoser> but juju status still shows the service
<hazmat> smoser, it takes a while to die, juju gives the charm a chance to clean up.. notice in status the lifecycle: dying
<hazmat> smoser, a while normally being a minute or less
<smoser> yeah, you're right.
<smoser> k
<hazmat> smoser, juju-deployer -T automates this a bit, but terminating all services, units, machines, clearing error states waiting etc.
<hazmat> but its whole hog atm rather than targeted
<smoser> right. thanks hazmat
<smoser> hazmat, in
<smoser> juju deploy  --repository ~/charms/ local:maas-region
<smoser> why do i have to say "local:" ?
<smoser> i would have thought that was defined with --repository=
<hazmat> smoser, i had that argument once upon a time..
<hazmat> with the same perspective..
<hazmat> but the notion was you could also define --repository via JUJU_REPOSITORY
<hazmat> and then its rather innocous what you might end up getting .. or define an alias with --repository
<smoser> oh well.
<hazmat> ie.  charm store as default, and local as explicit, since repository acquisition isn't always clear.
<smoser> is debug-log known broken with local provider ?
<smoser> or is it just me
<smoser> $ juju debug-log
<smoser> tail: cannot open `/var/log/juju/all-machines.log' for reading: No such file or directory
<smoser> Connection to 10.0.3.1 closed.
<smoser> ERROR exit status 1
<hazmat> smoser, its broken
<hazmat> smoser, there's a couple of other places files for local provider can be found .. typically in $JUJU_HOME/$ENV_NAME/log
<hazmat> smoser, container/console.log go to /var/lib/juju/containers/$container-name
<hazmat> the jhome log files are for the agent
<marcoceppi> smoser: also, when you type juju deploy mysql juju-core is actually expanding that to "cs:precise/mysql" so when you don't explicitly list the protocol it'll be expanded to use the charm store URL
<smoser> marcoceppi, yeah, that is weird behavior.
<smoser> but i dont care to argue
<hazmat> marcoceppi, right.. but that expansion could just as easily switch when specifying a repo..
<smoser> (lots of times i *do* care to argue, but not now)
<hazmat> :-)
<hazmat> smoser, i'd liked how solomon put it yesterday ... keep scott happy.
<marcoceppi> hazmat: it could, but I feel it's a rather small point. Juju could actually warn about ambiguous source
<marcoceppi> juju deploy --repository=. (or JUJU_REPOSITORY is set) mysql
<marcoceppi> Ambiguous deploy statement, did you means local:mysql?
<hazmat> marcoceppi, its just feels rendundant to double specify repo... i know the reasons why its not that way though.
<hazmat> er.. local charm
<marcoceppi> hazmat: right, it does seem a bit redundant
<hazmat> but  is more consistent the way it is
<hazmat> ^it
<marcoceppi> hazmat: maybe we should just drop the notion of protocol-less deploy statments though, just `juju deploy cs:mysql`
<hazmat> marcoceppi, given a sane default, no real reason to
<marcoceppi> hazmat: also, with this bug, it could cause a lot more confusion when not specifying local
<marcoceppi> hazmat: https://bugs.launchpad.net/juju-core/+bug/906008
<_mup_> Bug #906008: way to set default charm repository <feature> <juju-core:Triaged> <https://launchpad.net/bugs/906008>
<marcoceppi> we had that in the docs for a while before we realized that doesn't actually work
<hazmat> marcoceppi, interesting
<hazmat> marcoceppi, JUJU_REPOSITORY is the only way to do that.. not sure how that came about otherwise..
 * hazmat contemplates bzr blame
<marcoceppi> hazmat: I think evilnickveitch tracked it back to jorge putting that in there
<marcoceppi> but that could have just been from information he got from someone else
<hazmat> indeed
<marcoceppi> I got all excited, and thought I could use it to run my own charmstore. I was sadly mistaken
<hazmat> i forget how much i dislike html docs till i try to write some
<marcoceppi> hazmat: I think you just made nick rage quit ;)
<jcastro> marcoceppi, hah, the scalable mediawiki bundle I just made needs a minimum of 5 nodes
<jcastro> go big or go home!
<smoser> ok. another question.
<smoser> i really suck, and i keep making stupid mistakes.
<smoser> and juju deploy .... service
<smoser> then install fails
<smoser> how do i iterate that quickly?
<smoser> juju destroy-service maas-region && juju terminate-machine 1
<smoser> is quite a slow iteration
<smoser> and it wont let me deploy the service again until its out of 'dying'
<jcastro> https://juju.ubuntu.com/docs/authors-hook-debug.html
<smoser> juju please-die
<jcastro> that helps you find the error
<jcastro> and then you can rerun the hook right from tmux
<sinzui> marcoceppi, I want to document the lxc-no-network-because-of-stale-cloud-init problem. Do I add a troubleshooting section to https://juju.ubuntu.com/docs/config-local.html
<marcoceppi> sinzui: I've got that recorded and I'm sending the notes over to jcastro to make a comprehensive local troubleshooting guide as that's one of many things that have fouled up local provider users
<marcoceppi> sinzui: not sure where it will live
<smoser> thanks jcastro
<jcastro> I usually just try to rerun the install hook again
<jcastro> and see what errors out
<marcoceppi> smoser: yeah, typically I open juju debug-hooks in one terminal window, wait until tmux pops up, then run juju resolved --retry <unit> in another terminal, that'll cat the hook that failed and you can run `hook/<hook-name>` in the tmux 1 window over and over, make edits to the hooks live, go nuts until its fixed
<marcoceppi> smoser: Just make sure to copy your changes to your local machine/repo
<smoser> marcoceppi, so charmhelpers/core/hookenv.py
<smoser> wants juju-log
<smoser> command
<smoser> but not found ?
<smoser> my PATH doesn't seem set up. is that something i missed ?
<marcoceppi> smoser: that's...odd, juju-log should definitely be a command
<smoser> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
<smoser> doesn't contain
<smoser> /var/lib/juju/tools/1.16.0.1-precise-amd64/
<marcoceppi> smoser: wait, what window in the tmux session are you right now?
<smoser> ah. main one.
<marcoceppi> smoser: yeah, that doesn't have hook envionment vars
<smoser> marcoceppi, thanks.
<smoser> all. thanks.
<marcoceppi> jcastro: local provider troubleshooting guide draft I had: http://paste.ubuntu.com/6336111/
<jcastro> ON IT
<jcastro> hey
<jcastro> are you done with it?
<jcastro> I was thinking getting it up and marked up asap
<jcastro> and then iterating fast, but in the docs themselves
<jcastro> instead of pads and pastebins
<jcastro> https://code.launchpad.net/~jorge/juju-core/troubleshooting-local-provider-docs/+merge/193444
<jcastro> marcoceppi, I added mgz's tip from yesterday on blowing away those .jenv files
<marcoceppi> jcastro: right, hopefully that bug will be fixed soon
<marcoceppi> jcastro: but good point
<mramm> hey all: thumper's blog post about his logging library for Go is now up on hacker news: https://news.ycombinator.com/item?id=6643805 please upvote it if you think it is interesting, and feel free to comment on hacker news if you think you have something to add.
<adeuring> sinzui: https://code.launchpad.net/~adeuring/charmworld/more-heartbeat-info-2/+merge/193454
<sinzui> thank you adeuring
<sinzui> marcoceppi, Do you want charms to have a saucy series so that bigjools can publish his tarmac charm
<sinzui> marcoceppi, Do we want to create a trusty series this week?
<marcoceppi> sinzui: yeah, I was under the impression that we had a series for each release so far
<marcoceppi> sinzui: please open both
<adam_g> using a custom built juju/jujud binary set to bootstrap a new environment, is there some way of confirming the resulting env is using the correct version?  is it normal for to fetch tools from s3 if using the local binary set?
<marcoceppi> sinzui: as well, if future releases could have trusty tools, I'd like to start doing some light charm testing for the trusty series
<sinzui> marcoceppi, okay, I wont promise them today as I want 1.16.2 behind me
<marcoceppi> sinzui: understood, but we should start taking steps to open the series up now
<marcoceppi> thanks!
<ekacnet> 2013-10-31 06:29:22 ERROR juju.tools list.go:113 cannot match tools.Filter{Released:false, Number:version.Number{Major:0, Minor:0, Patch:0, Build:0}, Series:"saucy", Arch:"amd64"}
<ekacnet> should I file a bug in launchpad for this ?
<ekacnet> when my juju version is obviously not 0.0.0
<marcoceppi> ekacnet: are you trying to bootstrap the null provider and the remove machine is a saucy machine?
<marcoceppi> s/remove/remote/
<mhall119> jcastro: marcoceppi: where is my LXC instance getting http://ubuntu-cloud.archive.canonical.com/ubuntu/  precise-updates/cloud-tools/main i386 Packages
<mhall119> from?
<marcoceppi> mhall119: cloud-init probably
<mhall119> it's pulling in django 1.5, where vanilla precise only has django 1.3
<mhall119> is that going to always be there when I juju deploy, even to Canonical's internal clouds?
<jcastro> ugh
<jcastro> that's something that shouldn't happen
<jcastro> jamespage, we probably need django for ... maas?
<ehw> https://bugs.launchpad.net/cloud-archive/+bug/1240667
<_mup_> Bug #1240667: Version of django in cloud-tools conflicts with horizon:grizzly <ubuntu-cloud-archive:Confirmed> <juju-core:Triaged> <https://launchpad.net/bugs/1240667>
<ehw> jcastro: ^^
<ehw> probably same issue
<jcastro> yep
<jcastro> sinzui, how do I nominate that bug for a backport fix?
<jcastro> I mean, once it's fixed how do I say "we should have that in the stable release please' vs. 1.17+ only
<sinzui> jcastro, does the bug have a nominate for series link for you?
<sinzui> I guess not because the project doesn't have a bug supervisor
<sinzui> jcastro, which bug? and can the fix wait 2-3 weeks for 1.18
<jcastro> are we backporting 1.18 to saucy and friends?
<jcastro> https://bugs.launchpad.net/cloud-archive/+bug/1240667
<_mup_> Bug #1240667: Version of django in cloud-tools conflicts with horizon:grizzly <ubuntu-cloud-archive:Confirmed> <juju-core:Triaged> <https://launchpad.net/bugs/1240667>
<jcastro> so in mhall's case, he's deploying django internally, and pulling in non-precise django sucks.
<sinzui> jcastro, well backport is the wrong word...Ubuntu only makes dev packages. no one is using trusty. The juju project makes all packages to supported ubuntu series
<sinzui> Oh that fucking bug
<jcastro> yeah so I don't care about trusty
<jcastro> I care about people inadvertantly deploying django from the cloud archive on 12.04 instead of what they expect
<sinzui> It's hard to suppress my visceral disdain for that bug. It is not possible to deploy charmworld without some really arcane hacking
<sinzui> jcastro, the good news is that bug will be fixed for everyone about the same time.
<sinzui> I targeted it to 17 because we need to fix the regression for everyone
<sinzui> jcastro, I think the intermediate fix will be to build mongodb without libv8 or statically link it. That will prove we can create juju-db
<sarnold> "build mongodb without libv8" -- what would be left?
<mhall119> jcastro: sinzui: so what are my options here?
<mhall119> I *think* my staging and production deployments arne't getting this, tiaz tells me they both have django 1.3.something installed
<mhall119> but I have a change that needs to be made if I have 1.5, that will cause a breakage if I have 1.3
<sinzui> mhall119, for my charmworld deploy, I had to ssh to the machine, add a file to pin the priority, then manually run install: https://bugs.launchpad.net/cloud-archive/+bug/1240667/comments/9
<_mup_> Bug #1240667: Version of django in cloud-tools conflicts with horizon:grizzly <charms> <packaging> <regression> <ubuntu-cloud-archive:Confirmed> <juju-core:Triaged> <https://launchpad.net/bugs/1240667>
<sinzui> mhall119, I don't know a graceful fix
<mhall119> sinzui: unfortunately that's not an option for me, I need to give IS a charm that "just works" without additional manual intervention
<sinzui> mhall119, you can fork the charm and add a step during install that adds the file described in jamespage's comment
<sinzui> mhall119, IS always forks its charms, so it is not a blocker, but it is more work
<ehw> customers don't fork, though; it really looks like maas needs to separated out from cloud-tools
<mhall119> well this is my charm, so I can easily do it, I'll try jamespage's fix
<sinzui> mhall119, IS never deploys from the juju-store. they deploys the versions that they know
<mhall119> sinzui: I know
<sinzui> private clouds do fork because they have not vetted upstream changes. the require repeatability with every deploy
<ehw> sinzui: yes and no; they stage, but they expect upstream fixes to be applied as they come, and don't like carrying deltas
<sinzui> mhall119, My own charm is affect by this bug. jujucharms.com cannot be setup in production without gross hacks. Lets hope it doesn't fall over
<mhall119> jcastro: I have a confession, I am starting to like juju
<marcoceppi> mhall119: that's how we get you. We make you got through trials and tribulations so that when you come out on top after weeks of grueling pain and tears, you develop stockholm syndrome and grow to love the tool you once despised
<marcoceppi> ;)
<mhall119> lol
<mhall119> "If I still hated it, all of these weeks of work would be for nothing, so I better love it"
<marcoceppi> mhall119: but seriously, any feedback you've got about the problems you ran into, confusing things, mail jorge about them (or me, or the list). We'd love to make the developer experience wayyy better
<mhall119> I think it's all been bugs you already know about, or else things specific to IS's requirements
<mhall119> stuff like LXC containers not being cleaned up on destroy-environment seems to be fixed now
<mhall119> I've had to delete ~/.juju/environments/* a couple of times
<mhall119> not sure what the cause was or if there's a bug for that
<marcoceppi> mhall119: yeah, that's a recent bug that's been reported now
<jcastro> I've got that stuff in the LXC troubleshooting page
<jcastro> it's in the doc MP queue if you wanna review and commit and can't wait for nick to get to it
<marcoceppi> mhall119: any ideas on how to make writing a charm easier would be cool too
<mhall119> I'd file a bug that I need more RAM and an SSD on my laptop, but I think that'll be won't-fix'ed
<mhall119> marcoceppi: unfortunately I had to base my charm of an existing IS django charm because of their way or doing things, instead of using the juju tools
<marcoceppi> mhall119: gotchya
<marcoceppi> cool
<marcoceppi> jcastro: I'll review and merge the troubleshooting when I get back from lunch
<mhall119> marcoceppi: having a safe, easy way to say "call this other hook" from within a hook would be really useful
<mhall119> since I find myself having very small hook scripts that call very large functions in common.sh
<marcoceppi> mhall119: what's wrong with just calling "hooks/<hook-name>" from the hook? Or are you referring to being able to call relation hooks out of band?
<mhall119> yeah
<mhall119> so initially I was wanting to re-generate my db credentials file whenever I put a new bzr branch of my code on the instance
<mhall119> rather than keeping the file in a common space and symlinking it in to new code directories
<mhall119> which meant I needed to run the same code in db-relation-joined/changed in my config-changed or upgrade-charm hooks
<mhall119> maybe it just needs to push the idea of putting all of the code that does stuff into common files, and having light-weight hook files that just call into it
<marcoceppi> mhall119: I'd instead put the code in config-changed, have the db-relation hook be a very small file that records the data it needs to like .db-creds then have it call config-changed which has logic to look for a .db-creds file and build the config
<marcoceppi> mhall119: that's actually a best practice for charms
<marcoceppi> mhall119: to have hooks that are just essentially stubs that call out to shared/common functions. Then you can like unit-test those functions to add a level of sanity checking to charms
<mhall119> marcoceppi: anything you guys can do to make that more obvious and easier would be nice
<marcoceppi> mhall119: which, subbing hooks or centralized logic?
<mhall119> well they kind of go hand-in-hand
<marcoceppi> mhall119: the next version of charm-tools will generate a more opinionated template that includes that idea in it
<mhall119> marcoceppi: providing tools that let you say something like "/srv/db.conf is the source for ${variablepath}/db.conf, so whenever variablepath changes automatically copy/symlink from the source to the new path"
<mhall119> but that'll make juju a lot more complicated, I think
<mhall119> marcoceppi: is there any way to make a custom hook?
<mhall119> like "juju restart-gunicorn api-website"?
<marcoceppi> mhall119: you can make whatever you want in the hooks/ directory. However, there's no way to trigger unless from another hook
<marcoceppi> mhall119: there's work for a `juju run` command which might allow you to do that
<mhall119> that would be nice
<mhall119> so I broke down and wrote an "initdb" command for api-website that can be safely run over and over, since trying to make things work with just a .db_initialized state file wasn't cutting it due to django limitations
<mhall119> sinzui: jamespage's apt preferences hack did the trick
<sinzui> mhall119, did you fork the charm?
<mhall119> sinzui: no, it's my own charm
<sinzui> okay. I think we need to blog about this. I was lucky that jamespage was in the room when my charm broke
<mhall119> the IS branch is the only branch
<b1001> hmm.. I set up apache2 with juju, and I get Error 403: forbidden even from the apache2 charm "machine" and my localhost. (local juju instance)
<b1001> it is not possible to halt/stop or shutdown juju on a local ?
<marcoceppi> b1001: describe?
<b1001> well i got it running on a laptop.. and i reckon running mysql, hadoop and other charms will tear on my battery.
<marcoceppi> b1001: you can destroy the environment
<b1001>  i would have to rebuilt it then :(
<thumper> b1001: not automatically
<thumper> b1001: but manually, yes
<marcoceppi> thumper: this smells like a plugin
<thumper> heh
<marcoceppi> thumper: care to elaborate? or is it just lxc-stop ?
<thumper> use lxc-stop -n <machine name>
<thumper> they will auto start when the machine is rebooted
<thumper> or using lxc-start -n <machine name>
<marcoceppi> thumper: /me consisers juju local-suspend, juju local-wakeup
<thumper> although I did see a bug fly past where containers were not auto starting
<marcoceppi> \o/
<thumper> local-resume?
<marcoceppi> oh, yeah, that's logical
<thumper> known bug with fix coming through proposed
<jamespage> sinzui, that workaround needs to not be a workaround for to much longer
<b1001> thumper: what do you mean?
<thumper> b1001: the machines of the local provider are lxc containers
<thumper> you can use the lxc commands to stop and start the machines
<stokachu> any documentation laying around for utilizing bundles?
<sinzui> jamespage, \o/
<jamespage> sinzui, OK - I'll push it to trusty first
<jamespage> and then do the PPA's
<sinzui> thank you!
<b1001> thumper: nice thanks.. didnt think of that.. seems to lower the load
<marcoceppi> sinzui: mhall119 what hack is this? sounds like it's a good docs candidate
<marcoceppi> stokachu: not yet, we have some drafts that will land when bundle support lands
<context> trying to use the juju manual-provision, and its trying to connect to what looks to be mongo on 37017 but mongo is running on port 27017
<sinzui> marcoceppi, add a file to pin the priority of the cloud-archive when the charm is installed: https://bugs.launchpad.net/cloud-archive/+bug/1240667/comments/9
<_mup_> Bug #1240667: Version of django in cloud-tools conflicts with horizon:grizzly <charms> <packaging> <regression> <ubuntu-cloud-archive:Confirmed> <juju-core:Triaged> <https://launchpad.net/bugs/1240667>
<marcoceppi> sinzui: if jamespage has a fix landing soon, I think it'll be okay?
<marcoceppi> context: mongodb setup by juju should be spun up on it's own port as to not collide with existing default mongo installs
<context> then bootstrap failed to do its job :x
<context> this is a fresh brand new ubuntu 12.04 server
<context> and now juju bootstrap thinks the machine is already provisioned
<marcoceppi> context: maybe not, what does `initctl list | grep juju` show on the server?
<context> how do i get it back to a non-provisioned state
<context> juju-db stop/waiting
<marcoceppi> context: can you pastebin /var/log/upstart/juju-db.log ?
<marcoceppi> context: I think you're getting the wrong version of mongodb, which shouldn't happen, but that's what it smells like
<context> error command line: unknown option sslOnNormalPorts
<marcoceppi> context: you have the wrong mongodb version, thumper I thought manual provisioning added the cloud archive as part of cloud-init?
<marcoceppi> thumper: or rather, who should I bug about manual provisioning?
<marcoceppi> context: what version of juju are you running?
<thumper> marcoceppi: there is a bug for it
<thumper> I think it may even be fix committed
<thumper> and axwalk
<thumper> axw
<context> one sec
<marcoceppi> thumper: awsome, so if context manually adds the cloud-tools archive prior to attempting bootstrap it should be peachy axwalk?
<marcoceppi> oh, he's not in the room right now
<thumper> no
<thumper> yes it should be fine
<marcoceppi> cool
<context> ?
 * thumper crosses fingers
<marcoceppi> thumper: he'll need to run destroy-environment to have it listed as "not bootstrapped" right?
<context> juju command not on server
<thumper> heh
 * marcoceppi fears hulk smashing everything
<thumper> that doesn't work
<marcoceppi> \o/
<thumper> there's a bug for that too
<context> install juju on server before bootstrap ?
<context> ERROR null provider destruction is not implemented yet
<context> haha
<marcoceppi> context: no, but you'll need a newer version of mongodb than what's in precise
<thumper> marcoceppi: I'm pretty sure that destroy-environment for manually bootstrapped ones should be fine
<marcoceppi> haha, fantastic
<thumper> you have to manually remove the upstart jobs
<thumper> I think that is all it really looks for
<marcoceppi> thumper: cool
<thumper> /etc/init/juju*
<marcoceppi> context: okay, here's what I'm going to have you try
<thumper> marcoceppi: so... document this?
<marcoceppi> thumper: well, for destruction, yes. For bootstraping and the cloud-tools archive if there's a fix committed it should be landing soon
 * thumper looks for the bug
<marcoceppi> thumper: we explicitly state manual provisioning is crazy beta at the top
<thumper> :)(
<context> oh. didnt see that
<marcoceppi> https://juju.ubuntu.com/docs/config-manual.html
<context> yeah i see the Note now
<marcoceppi> we should make that like a hero unit or something
<context> yeah
<marcoceppi> with flashing sierns and lights
<context> <blink> tag
<marcoceppi> context: sorry we lured you in to a trap
<marcoceppi> <marquee>
<context> that was my next suggestion ;)
<context> haha
<marcoceppi> thumper: we list the bug on the docs! https://bugs.launchpad.net/juju-core/+bug/1238934
<_mup_> Bug #1238934: manual provider doesn't install mongo from the cloud archive <cloud-archive> <ssh-provider> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1238934>
<marcoceppi> context: well if you're still game to try this out, we can try a few things
<context> im game
<marcoceppi> awesome! so log in to the machine, sudo rm -f /etc/init/juju-*
<context> im guessing if i just updated to 13.10 it would fix crap
<context> done
<marcoceppi> context: welllllllllll, I think there's a bug with manual provisioning a bootstrap that's not precise as well
<marcoceppi> again, still under development
<context> yeah
<context> i stopped mongodb
<context> as well
<marcoceppi> okay, you'll need the cloud archive next, so sudo apt-get remove mongodb-server
<marcoceppi> sudo apt-get install -y ubuntu-cloud-keyring
<marcoceppi> sudo add-apt-repository cloud-archive:tools
<marcoceppi> sudo apt-get update
<marcoceppi> now you should be able to bootstrap the machine
 * marcoceppi crosses fingers
<jamespage> marcoceppi, the add-apt-repository call will install the keyring package btw
<marcoceppi> jamespage: ah, probably should update https://wiki.ubuntu.com/ServerTeam/CloudToolsArchive
<context> kk attempting bootstrap
<context> now will i need to do this on machines in order to add-machine them? or should only need to be on the 'controller'
<marcoceppi> context: only for the bootstrap, juju add-machine should work without needing to do this
<context> kk
<marcoceppi> context: since it's only the mongodb that needs updating. The juju tools themselves are kept independantly of the ubuntu archive
<context> yeah
<jamespage> marcoceppi, updated
<context> i /think/ it worked. command ended happily. waiting for juju-status
<context> jujud running, juju-status just sitting there
<marcoceppi> context: it'll take a few mins to get setup
<marcoceppi> context: /var/log/juju/machine-0.log should illumante what's going on
<context> kk
<context> whats juju written in
<marcoceppi> golang
<context> oh yeah :x i remember that
<context> all im seeing in log is Pinger:Ping
<marcoceppi> context: what does initctl list | grep juju show?
<context> db and machine-0 running
<marcoceppi> that's a good sign
<context> nothing happening really cpu wise
<marcoceppi> juju status still hanging?
<context> yeah
<context> maybe try restarting machine for giggles ?
<marcoceppi> Â¯\_(ã)_/Â¯
<context> haha
<marcoceppi> context: nothing else fruitful in machine-0?
<thumper> context: can you pastebin the entire machine-0 logfile?
<thumper> I can have a quick look and see if anything leaps out
<context> sec
<context> http://pastebin.com/4BWB3ghR
<context> i do see something regarding storage-auth-key
<context> i do have storage-auth-key in my environments.yaml locally
<thumper> hmm...
<thumper> ah fark...
<thumper> this is exactly the same problem that bit me with maas and lxc
 * thumper double checks
<context> also i noticed bootstrap-user doesn't work. i tried setting it as root and didnt work
<thumper> yep that's it
<thumper> grr!!!!
<thumper> context: this isn't going to work until we fix this bug...
<thumper> sorry about that
 * thumper goes to crack a whip
<thumper> context: can you file a bug for this?
<thumper> or marcoceppi?
<context> nothing i can do for now at least?
<marcoceppi> thumper: what's the problem?
<context> i can, im not exactly sure what it should say though
<thumper> context: say "status for manual provider hangs"
<bic2k> first charm submitted for review today, woot!
<thumper> that is your symptom
<thumper> marcoceppi: the storage-auth-key is being stripped out at the api level
<thumper> so the thing that needs it doesn't get it
<thumper> bit of a fail there
<thumper> just miscommunication between devs, and lack of a functional test suite to catch
<thumper> we are working on the test suite
<thumper> but it's not there yet
<context> kk filing bug now
<marcoceppi> thumper: thanks for the info context: thanks for playing along!
<thumper> context: ta
<context> ;) anytime
<marcoceppi> I haven't seen the release notes, but I think there were some approvments in 1.16.2 for manual provider
<context> thumper, marcoceppi: https://bugs.launchpad.net/juju-core/+bug/1246905
<_mup_> Bug #1246905: status for manual provider hangs <juju-core:New> <https://launchpad.net/bugs/1246905>
<jamespage> marcoceppi, this is the list for 1.16.2  - https://launchpad.net/juju-core/1.16/1.16.2
<thumper> ta
<context> wasn't sure if i should have put any of that log output in there but i figured you could update the ticket with more detail on what you found
<marcoceppi> jamespage: thanks!
 * marcoceppi wonders what happened to 1.16.1
<thumper> marcoceppi: superseeded by 1.16.2
<marcoceppi> ah
<context> thumper: any idea when there will be a release that fixes it
<marcoceppi> 1.17.0 looks awesome
<context> i know im a little antsy ;)
<thumper> context: real soon nowâ¢
<context> :D
<marcoceppi> context: if you're not already, subscribe to the mailing list. We put the release notes for all the juju related release there as well as more indepth project discussion
<context> kk, url ? :x
<marcoceppi> context: DUH! sorry: https://lists.ubuntu.com/mailman/listinfo/juju
<context> kk will sign up for that in a bit.  heading out for margaritas
<marcoceppi> context: enjoy your evening o/
<adam_g> sinzui, ping
#juju 2013-11-01
<stokachu> marcoceppi: re: bundles, ok thanks
<sinzui> hi adam_g
<adam_g> sinzui, are 1.16.2 tools expected to be getting pulled when bootstrapping 1.16.2?
<sinzui> adam_g, they will be...do you have 1.16.2 client?
<adam_g> sinzui, yes
<adam_g> sinzui, for now i am --upload-tools
<sinzui> adam_g, I am constructing the tools now. you have got the client in during that awkward window of tools being built
<adam_g> sinzui, ok, np. just curious
<sinzui> adam_g, I think I will have the tools in place in 1h and that is not the cider talking
<marcoceppi> sinzui: you have to build tools post ppa build?
<marcoceppi> Oh, is this why you guys want to use a staging ppa?
<sinzui> marcoceppi, yes, out builders make all the series packages, I pull every one down and extract the jujud then publish them to every cpc
<sinzui> yep
<marcoceppi> sinzui: gotchya
<marcoceppi> that is a bit awkward
<sinzui> but I don't control trusty which has been in the wild for a few hours
<sinzui> yes indeed
<marcoceppi> thumper-afk: is there documentation on changing the logging level?
<sarnold> marcoceppi: how about this? https://lists.ubuntu.com/archives/juju/2013-September/002998.html
<marcoceppi> ah, there it is, we need to document that in the docs. I couldn't find it in any of the juju help topics
<thumper> marcoceppi: 'juju set-env logging-config="<root>=INFO;juju=DEBUG;juju.provisioner=TRACE"'
<thumper> marcoceppi: but really it is for devs,
<thumper> I have a plan for more user related stuff
<marcoceppi> thumper: oh, okay
 * marcoceppi nods
<marcoceppi> ugh, I'm stuck in lxc-console and Ctrl+a q is not working
<marcoceppi> how do I close console?
<marcoceppi> thumper, maybe you know?
<thumper> um...
 * thumper looks
<thumper> marcoceppi: nope
<thumper> kill the terminal
<thumper> and then run
<thumper> that's what I'd do
<marcoceppi> arg, I don't want to lose this window. Curse you -d flag! Why are you not a default
<ekacnet> marcoceppi: yes
<ekacnet> (with some delay in the answer)
<marcoceppi> ekacnet: yes to what?
<marcoceppi> ekacnet: Oh, saucy manual provider
<marcoceppi> ekacnet: you've hitting this bug: https://bugs.launchpad.net/juju-core/+bug/1246336
<_mup_> Bug #1246336: Manual provider fails when trying to bootstrap a Saucy machine <landscape> <juju-core:Confirmed> <https://launchpad.net/bugs/1246336>
<ekacnet> marcoceppi: thanks
<MiteshShah> ERROR cannot start bootstrap instance: cannot run instances: gomaasapi: got error back from server: 409 CONFLICT
<MiteshShah> Juju need a maas installed server or normal ubuntu server
<MiteshShah> any one help me
<sodre> I have a question on how Juju sets the hostname in OpenStack
<marcoceppi> sodre: I'm pretty sure it doesn't, I think that's what openstack does.
<sodre> in particular, after booting up I end with a /etc/hosts that does not include the machine name at 127.0.1.1
 * marcoceppi checks
<sodre> marcoceppi: thanks for checking. As a work-around, do you know how I can force a /etc/hosts file to be written during cloud-init ? In particular for the instances brought up by juju ?
<marcoceppi> sodre: so yeah, it looks like the provider sets the hostname for openstack. I'm still trying to figure it out for sure. rogpeppe could you confirm?
<context> marcoceppi, thumper: 'might' have found my issue
<sodre> marcoceppi: provider == openstack, right ?
<marcoceppi> sodre: yes, the provider in this story is openstack
<marcoceppi> sodre: so on HP cloud, it works properly
<marcoceppi> context: oh, what was it?
<context> 2013-11-01 13:55:18 INFO juju.state open.go:68 opening state; mongo addresses: ["c1210-1595.cloudatcost.com.:37017"];
<sodre> marcoceppi: okay. I'm running with Havana & neutron. Do you have any deployments along those lines ?
<context> well, my genius host, has ip reverse to that hostname
<context> but that hostname resolves to a totally different ip
<marcoceppi> context: oh, that's a good idea
<context> updated reverse now waiting
<marcoceppi> sodre: so, digging a little deeper, the hostname isn't placed in /etc/hosts but is set in the openstack's dns server (or whatever)
<context> 68.7.219.162.in-addr.arpa domain name pointer c1210-1595.cloudatcost.com.
<context> c1210-1595.cloudatcost.com.countrystone.com has address 198.40.237.19
<context> YEY !
<marcoceppi> sodre: http://paste.ubuntu.com/6341412/
<context> where does juju/jujud store config stuff
<sodre> marcoceppi: is novalocal at HPCloud or Havana+Neutron ?
<marcoceppi> sodre: that's HP Cloud
<marcoceppi> I don't have a havana neutron setup
<sodre> okay, I think they might havana must have bug.
<sodre> blarg... : I think havana might have a bug in that area.
<sodre> I'll dig more in that direction.
<marcoceppi> sodre: try just spinning up a machine outside of juju
<marcoceppi> sodre: see if the hostname it recieves is set up properly
<sodre> yeah, it is the same issue. A plain cirros image also gets messed up.
<sodre> marcoceppi: I take that back. the cirrOS image is always called cirros and it ahs a 127.0.1.1. Let me try a saucy image.
<context> ok maybe that was not the problem
<rogpeppe> marcoceppi: i'm afraid i don't know about openstack hostname magic
<marcoceppi> rogpeppe: any idea who i could bug
<rogpeppe> marcoceppi: mgz or jam might be good there
<marcoceppi> I'm secretly creating a spreadsheet of who to ping in core when something goes wrong
<sodre> marcoceppi: it does not setup the hostname properly . Unfortunately DNSMASQ only sets up hostname in the form host-<ip address>.openstacklocal
<sinzui> jcastro, marcoceppi do you have permission to upload the new juju installer to ubuntu.com?
<mgz> we shouldn't be using hostnames at all with openstack
<sodre> ohoh...
<mgz> as it's historically been all suck
<jcastro> sinzui, no, that needs to be done through the web team
<jcastro> #webops I think?
<sodre> brb
<sinzui> jcastro, no, they don't have access.
<sinzui> I will contact the members of ~canonical-website-editors
<marcoceppi> sinzui: why not just upload it to launchpad?
<sinzui> I can upload it to 1.16.2, but don't we need it on juju.ubuntu.com
 * sinzui added it to the release because that is just the right thing to do
<marcoceppi> sinzui: Well, we have to edit the website with the new URL
<marcoceppi> might as well just have it point to the LP direct download link
<marcoceppi> sinzui: we can update the docs, and then we'll have to ping the design team to update the website
<sinzui> rock.
 * marcoceppi updates the docs
<marcoceppi> sinzui: where is the msi? I can't seem to find it on https://launchpad.net/juju-core/1.16/1.16.2
<jcastro> oh
<marcoceppi> ugh, there it is
<jcastro> to edit the website?
<marcoceppi> jcastro: yeah
<jcastro> sinzui, you need to send a mail to peter mahnke
<sinzui> marcoceppi, I just added it to https://launchpad.net/juju-core/1.16/1.16.2
<jcastro> his team is the only one that can edit the website as of now
<jcastro> they're working on fixing that
<sinzui> marcoceppi, thank you for fixing the version file errors in proof
<marcoceppi> sinzui: it was long overdue
<marcoceppi> and it was a two line fix :\
<context> Error: 'cloud-archive:tools' invalid
<context> did i spell it wrong ?
<sanman_> hello everyone
<marcoceppi> sanman_: hello
<marcoceppi> context: that's werid, it's what the wiki says: https://wiki.ubuntu.com/ServerTeam/CloudToolsArchive
<sanman_> does anyone know if juju is able to deploy RPM based distros like Red Hat or CenOS? I saw some work on the old python version that made this possible, but it seems that with the new go version that it might not be possible anymore
<marcoceppi> sanman_: not at this time
<sanman_> ok, is that something that is planned for the future?
<context> hmm. i did an apt-get upgrade then tried adding the repo and it worked
<context> ignore me
<marcoceppi> sanman_: it's on the roadmap
<context> ERROR invalid series "trusty"
<context> i get some weird ass errors
<marcoceppi> context: could you explain how you got this error?
<context> ERROR Get sftp://162.219.7.68//var/lib/juju/storage/tools/releases/juju-1.16.2-precise-amd64.tgz: unsupported protocol scheme "sftp"
<context> marcoceppi: i re-imaged server, and did bootstrap again
<marcoceppi> context: is it precise?
<context> yeah
<context> apparently IsValidSeries() just compares name to a regexp and i see no reason why it would not pass that regex
<marcoceppi> context: I got some weird trusty errors yesterday during packaging, it might be that trusty series isn't actually open yet?
<context> im guessing so? trusty IS in the seriesVersions map :-/ not sure why they'd put it in if it doesn't exist yet
<context> which if anything is more weird cause bootstrap worked yesterday and now not this morning
<marcoceppi> yeah, more oddities
<context> although i guess yesterday i installed juju from apt-get and didn't let bootstrap install it
<context> kk. looks like simplestreams is trying to use http to fetch sftp://
<context> and fix already committed i guess. will have to wait for 1.17
<jcastro> marcoceppi, have you tried quickstart yet?
<marcoceppi> jcastro: I installed and poked at it, not actually used it yet
<jcastro> hey, so proof is failing on my discourse bundle
<jcastro> but doesn't tell me why
<jcastro> bzr branch lp:~jorge/charms/bundles/discourse/bundle
<jcastro> has the bundle
<marcoceppi> jcastro: which proof, my proof or stor proof?
 * marcoceppi needs to install charm-tools again
<marcoceppi> marco@home:/tmp$ juju bundle proof discourse
<marcoceppi> I: discourse-single-unit: No series defined
<marcoceppi> E: discourse-single-unit: Could not find charm: discourse
<marcoceppi> jcastro: this is the verion thing
<jcastro> I didn't get that output at all
<marcoceppi> rick_h_: is updating the "remote" proof to fix that
<marcoceppi> jcastro: wat
<jcastro> jorge@jilldactyl:~/src/bundles/discourse$ juju bundle proof bundles.yaml
<jcastro> Traceback (most recent call last):
<jcastro>   File "/usr/bin/charm-proof", line 9, in <module>
<jcastro>     load_entry_point('charmtools==1.1.0', 'console_scripts', 'charm-proof')()
<jcastro>   File "/usr/lib/python2.7/dist-packages/charmtools/proof.py", line 56, in main
<jcastro>     print e.msg
<jcastro> AttributeError: 'exceptions.Exception' object has no attribute 'msg'
<marcoceppi> jcastro: dude
<rick_h_> jcastro: pastebin the bundle, if it's something not covered I"ll add a note to add the missing thing as well
<rick_h_> oh, isn't it juju proof --bundle
<rick_h_> marcoceppi: ^
<marcoceppi> rick_h_: juju bundle proof is juju charm --bundle proof
<rick_h_> marcoceppi: ah k
<marcoceppi> jcastro: you need to proof the bundle, not the deployer file
<marcoceppi> jcastro: but that's another bug you're hitting
<jcastro> marcoceppi, also, my charm tools was out of date
<rick_h_> huh? I thought the point was to give it he deployer file
<jcastro> also I got mixed up, charm tools wants a bundle
<jcastro> quickstart wants a deployer file
<marcoceppi> jcastro: you're basically proofing the metadata.yaml file and not the entire charm_dir
 * rick_h_ is confused
<rick_h_> marcoceppi: oh, you point it at the dir?
<marcoceppi> rick_h_: yes. Otherwise how will it know to check for a readme?
<rick_h_> marcoceppi: gotcha, duh
<jcastro> yeah, but quickstart doesn't
<jcastro> (I filed a bug)
<marcoceppi> it expects "CHARM_DIR" in the help output
<jcastro> and I am switching back and forth between the tools
<jcastro> so I got mixed up
<marcoceppi> jcastro: well, that's quickstarts problem ;) I can update it to allow proofing a yaml file
<jcastro> yeah, I filed bugs
<jcastro> see my post to the list
<jcastro> has a link to the bugs I'm filing
<marcoceppi> jcastro: ack
<jcastro> ugh
<jcastro> now I broke something
<rick_h_> lol
<jcastro> now quickstart finishes and doesn't deploy the bundles
<jcastro> just the gui and bootstrap
<rick_h_> and it proof's cleanly?
<marcoceppi> rick_h_: technically, no
<jcastro> ugh
<jcastro> I am getting errors I didn't get yesterday on proof
<rick_h_> jcastro: possible, there was a deploy yesterday
<Azendale1> Could anyone more experienced with juju stuff give me some input on this bug? I'm trying to decide if it is a bug or a PEBKAC problem, and if it is a bug, where you change the defaults for the charm (in which case I could submit a patch) https://bugs.launchpad.net/charms/+bug/1245095
<_mup_> Bug #1245095: rabbitmq-server charm ha-bindiface default breaks rabbitmq-hacluster subordinate charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1245095>
<jcastro> http://pastebin.ubuntu.com/6342620/
<rick_h_> jcastro: does it set config values/ There's a bug in that I've got a branch for now to fix
<jcastro> looks like it?
<rick_h_> jcastro: yea, that's my fault. Branch is in progress to fix
<jcastro> ack
<rick_h_> but deployer doesn't use proof atm so just ignore them and it's seperate from it not deploying
<marcoceppi> rick_h_: does this also drop the version requirement for parsing the charm?
<jcastro> rick_h_, deployer isn't any returning errors
<marcoceppi> at least for non-promulgated charms?
<rick_h_> marcoceppi: no, that's on proof right?
<jcastro> deploying the bundle wordpress-simple with the following services: wordpress, mysql
<jcastro> done!
<marcoceppi> rick_h_: ah, thought were were talking about proof
<jcastro> but they don't show up in the gui view nor status
<rick_h_> marcoceppi: yea, the type checking is a bug in the remote proof bits
<rick_h_> marcoceppi: what I get for having every failing test case covered but no passing test case :/
<jcastro> I: discourse-single-unit: No series defined
<jcastro> what does the I: mean?
<marcoceppi> Informational
<jcastro> is this just a warning?
<jcastro> ok
<marcoceppi> I, W, E
<jcastro> E: discourse-single-unit: Could not find charm: discourse is weirder
<rick_h_> jcastro: yea, that's an error then.
<marcoceppi> jcastro: known issue, since you didn't provide a -# in the charm name
<jcastro> I am pulling from ~marcoceppi/blah
<rick_h_> that'll cause it to fail
<jcastro> aha!
<jcastro> ok trying
<rick_h_> jcastro: paste the yaml
<jcastro> marco got it
<rick_h_> cool
<jcastro> missing the -#
<jcastro> rick_h_, would your bug stop wordpress from deploying?
<jcastro> or is it just spamming the console?
<rick_h_> jcastro: no, it's just going to spam proof results
<jcastro> ok
<jcastro> ok
<jcastro> I can confirm I can't deploy either wordpress or discourse
<jcastro> no errors
<jcastro> deploying the bundle discourse-simple with the following services: discourse, postgresql
<jcastro> done!
<jcastro> takes me to the gui
<jcastro> everything looks right other than discourse and postgres not deploying
<jcastro> same with wordpress, similar non-error
<Azendale1> where are the default settings for a charm set?
<sarnold> in the charm source; hopefully the charm's README describes the settings that you can change. If it doesn't describe the available settings, I'd suggest filing a bug agsint the charm..
<marcoceppi> Azendale1: they're defined in the charm under config.yaml
<Azendale1> sarnold: It does mention the setting the the docs, it's just what it is set to by default that I would like to make a patch for. It looks like the default breaks the High Availability subordinate charm
<jcastro> marcoceppi, rick_h_: if either you have time to try either discourse or wordpress and see if it's just me that would be <3
<marcoceppi> jcastro: otp
<Azendale1> marcoceppi: Where it says something like "default: <value_here>"
<marcoceppi> Azendale1: yes, config.yaml defines the configuraiton and the default values using the default key
<Azendale1> marcoceppi: I tried that but it didn't seem to change it. I guess I have some digging to do to make sure it deployed from my changed version. Thanks for the help!
<marcoceppi> Azendale1: are  you doing a local deployment?
<marcoceppi> Azendale1: https://juju.ubuntu.com/docs/charms-deploying.html#local
<Azendale1> marcoceppi: Originally, it was from the charm store, but then I branched the BZR branch and made changes when I figured out what was breaking. I'm thinking I have some homework to do to make sure it is actually deploying from the local repository. I'll look at the link and see
<jcastro> I bet it's caching
<jcastro> this happened to me
<Azendale1> jcastro: I assume I can just delete ~/.juju/charmcache and that should fix it if it is caching?
<Azendale1> jcastro: Because I know I specifically tested the bug still happened with the bzr version, then put my change in, and the bug still happened. So I could definitely see how it would cache that, as its the same thing coming from the same location
<jcastro> yeah I think that should be enough
<Azendale1> jcastro: ok, thanks, I'll try that
<jcastro> lmk what happens
<jcastro> that'd be a good tip to document!
<Azendale1> jcastro: Ok, will do. I probably won't have time today but will probably get it over the weekend
<jcastro> no worries!
<jcastro> thanks for using Juju!
<kentb> is there a juju-gui for saucy yet (or will there be one)?
<marcoceppi> kentb: probably not, though you can force gui to deploy to saucy
<kentb> marcoceppi: ah, ok. I see. thanks!
<sodre> devs: Is there a direct way to force a particular script to run on new-machines controlled by juju ?
<marcoceppi> sodre: could you expand a bit?
<sodre> sure.
<sodre> Current OpenStack+Havana+Neutron does not assign proper hostnames to nodes.
<marcoceppi> sodre: what you're asking about doing can be done with a subordinate
<sodre> I would like to add a script in the beginning to add 127.0.1.1 <hostname> to /etc/hosts file.
<marcoceppi> sodre: or, you can use `juju ssh` and a script too loop over all the machines and do this change
<sodre> so... instead of just calling juju deploy hadoop
<sodre> I would juju add-machine -n 10
<sodre> juju ssh  change hosts
<sodre> and juju deploy hadoop --to <machine id>
<marcoceppi> that's really clunky. What's breaking with the hostname?
<marcoceppi> Have you filed this as a bug in core?
<sodre> it is not an issue with juju
<marcoceppi> sodre: while it might not be a juju issue, it's a problem that could be solved by juju during machine provisioning
<sodre> it is more of an issue with OpenStack+Neutron not serving DNS properly.
<sodre> I see.
<marcoceppi> actually, it probably wouldn't be addressed well in core
<marcoceppi> too many things to go wrong
<sodre> yeah.
<marcoceppi> back to my original question, what actually breaks because of this?
<marcoceppi> depending on what/where it breaks you might be able to get around it
<sodre> okay: The final issue is Java handling of hostnames and the Hadoop charm dependency on hostname.
<sodre> if you checkout the hadoop charm and look at the install hook, you'll see what I mean.
<marcoceppi> sodre: Okay, well one way is to just fork the hadoop charm, change the install hook to add that line to /etc/hosts at the top of the hook then use juju deploy from your local copy of the charm
<marcoceppi> not pretty, but it's far better than having to juju deploy with pre-allocated machines
<sodre> true true...
<sodre> let me ask another question: Is there any harm (from juju's perspective) to change the hostname of the instance after it has been brought up ?
<marcoceppi> sodre: nope, shouldn't be
<sodre> okay.  let me try that route then.
<sodre> marcoceppi: do you anything about Canonical's private cloud installation ($9000 option),  e.g.  what do they actually install and deliver ?
<jcastro> I don't know much about it
<jcastro> you mean the Kickstart?
<jcastro> I didn't know we did those anymore
<sodre> yes.
<sodre> http://www.ubuntu.com/cloud/tools/jumpstart
<jcastro> so you mean other than what's listed in the "what the engineer will do?" part?
<sodre> :)
<jcastro> I don't really know, but if you have specific questions you can jet me an email and I can get you a response asap from someone who knows
<sodre> it much better explained than in the past
<sodre> i got most of the answers now.
<jcastro> oh ok, whew. :)
<jcastro> bcsaller, here's that bundle I couldn't get launched: https://code.launchpad.net/~jorge/charms/bundles/wordpress/bundle
<jcastro> bcsaller, the PPA with the quickstart is mentioned on the list by Gary
<jcastro> basically it fires off the bootstrap, the gui all fine, then says "deploying wordpress and mysql" and then returns a prompt
<jcastro> but the services themselves aren't launched
<bcsaller> jcastro: I'll take a look
<bcsaller> jcastro: I see the same thing as you on ec2
<jcastro> whew!
<bcsaller> digging into the logs a little bit, so far I don't see deployer being triggered in a way I'd expect
<bjf> what does this mean?: ERROR cannot start bootstrap instance: cannot run instances: gomaasapi: got error back from server: 409 CONFLICT
<bjf> and if i run "juju bootstrap" again it says "ERROR environgment is already bootstrapped"
<bjf> juju status says: ERROR Unable to connect to environment "".
<bjf> so which is it? do i have an environment or not and how do i recover from wherever i am
#juju 2013-11-02
<marcoceppi> bjf: 409 means there's no available instances in MAAS
<marcoceppi> bjf: if bootstrap encounters an error during bootstrap it still records it's state as boostrapped
<marcoceppi> You'll need to juju destroy-environment then try to bootstrap again
<marcoceppi> bjf: However, as for the original problem, make sure you have nodes in maas enlisted and ready to use before bootstrapping
<bjf> marcoceppi, how can i tell that i have nodes enlisted ? i commissioned a node. it's status is "Allocated to admin"
<bjf> marcoceppi, the node is up and i can ssh into it
<marcoceppi> bjf: if it's allocated it's not ready
<marcoceppi> if allocated it's being used
<bjf> marcoceppi, ok, i understand it not being ready. how do i make it ready?
<marcoceppi> bjf: you need to unallocate the machine
<marcoceppi> bjf: you're also going to need at least two machines to use juju and maas
<marcoceppi> bjf: if you're just "trying out" juju, there's an LXC provider that you can use on any Ubuntu desktop to spin up a cloud on your computer
<bjf> marcoceppi, i have 2 machines. one is my maas server the second is the first node in what will become an openstack cluster (i have 9 other systems)
<bjf> marcoceppi, when you say "unallocate" do you mean i need to delte the node and then go through discovery and commissioning again ?
<marcoceppi> bjf: I'm not sure, it's been a while since I've used maas
<bjf> marcoceppi, so it's pretty new to me (obviously) and i'm using the saucy version. i feel like i'm just missing the last little bit of info so that i can start using this node.
<bjf> i'm going to go through the process on another node and see if that behaves differently
<sodre> hi, if any dev is online... can someone explain how Juju discovers the `public' IP address of machine when floating-ips is set to true? this is on a private openstack install.
#juju 2013-11-03
<rick_h_> hm, so my charm installs build-essential but failing today with #1247299 so wondering if others hit this and wondering if this then makes it a juju issue since lxc doesn't consider it one?
<_mup_> Bug #1247299: apparmor blocks cgroup-lite from mounting <cgroup-lite (Ubuntu):Invalid> <https://launchpad.net/bugs/1247299>
<Azendale> So, I'm trying to "juju ssh" to a LXC container, but it is just trying to connect to the host computer (which doesn't have the ubuntu user, and therefore the key is rejected). Is there a way around this problem?
<Azendale> juju version is 1.16.2-saucy-amd64
<Azendale> https://bugs.launchpad.net/charms/+bug/1247636 would someone be able to look at this bug and tell me if my fix to it is a good/bad idea? Should that function even be being called?
<_mup_> Bug #1247636: etherpad lite fails to deploy, install hook running get relation <Juju Charms Collection:New> <https://launchpad.net/bugs/1247636>
<marcoceppi> Azendale: you can use juju ssh <unit> btw, juju ssh <machine> doesn't work with LXC
<marcoceppi> Azendale: also, charmhelpers is part of lp:charmhelpers so you might want to consider patching that there instead
<Azendale> marcoceppi: Thanks. (I'm trying to remember what I asked, but I think I was having trouble with getting LXC machines to start. But I got LXC to work eventually, and it was really nice. Fast, too, compared to installing an OS in a VM).
<Azendale> marcoceppi: The change I made on the bug I filed was just to get it to work. But I'm really new to charm stuff (but used to python), so I don't know exactly what is the bug.
<marcoceppi> Azendale: well, you can't (and shouldn't) be able to call relation-get from install hook
<Azendale> marcoceppi: I'm not sure if that function should not be called in the first place in an install hook, or if the function should just return None
<marcoceppi> so it seems the charm is doing something wrong
<marcoceppi> Azendale: but there's nothing wrong with building in guards. So charmhelpers is a set of scripts designed to solve common problems that charm authors have. One problem is making writing charms in python easier. So that's why you have decorators and methods in python that streamline communication to juju commands
<Azendale> marcoceppi: So, you're saying maybe fix the bug in two places, and then it's less likely to come up again in some other charm
<marcoceppi> Azendale: the real problem is in the install hook, it shouldn't be calling that, and if it is, it needs to guard when results aren't available
<marcoceppi> Azendale: the change to charmhelpers is a nice addition, not really a bug fix per se
<marcoceppi> Azendale: but still
<marcoceppi> Azendale: actually, having it fail like this when a relation_id isn't found is probably a good thing. Silently continuing when the method is called out of place could lead to weird results
<Azendale> marcoceppi: ok, thanks for the advice. I'll probably see what I can find as far as a proper fix then (sorry I'm so non-committal, I'm just not sure when/if I'll have time to try to understand the charm hook and see where to disable getting the relation)
<marcoceppi> Azendale: that's fine, I'm happy to help get you on the path to committing!
<Azendale> marcoceppi: Thanks, I appreciate it
#juju 2014-10-27
<Fig> huh
<Fig> More poeple than I expected here
<jcastro> marcoceppi, if you could chime in on the elasticsearch-charmers issue on the list that would be <3
<jcastro> marcoceppi, also, how can I get this to show up in the queue? https://bugs.launchpad.net/charms/+bug/1384290
<mup> Bug #1384290: [New charm] Forgerock <Juju Charms Collection:New> <https://launchpad.net/bugs/1384290>
<marcoceppi> jcastro: currently you have to have code attached to show up in the queue
<marcoceppi> that's not going to work here, I'll update ingestion rules
<jcastro> oh, the code is in github, that's why
<marcoceppi> right
<marcoceppi> jcastro: new rule is in place, ingest is running now
<jcastro> <3
<jcastro> gaughen, did you ever figure out which list to support the openstack charms on? I have someone that mailed me a question.
<marcoceppi> Sorry not sorry about the review queue. More changes to rules were made
<jcastro> no worries, thanks
<jcastro> does anyone have time this morning for forgerock review round two?
<jcastro> https://bugs.launchpad.net/charms/+bug/1384290
<mup> Bug #1384290: [New charm] Forgerock <Juju Charms Collection:New> <https://launchpad.net/bugs/1384290>
<marcoceppi> UGH, jcastro, this is crap
<marcoceppi> the review queue is filed with all the stuff that we created years ago
<marcoceppi> for charm needed
<marcoceppi> I knew the code filter was there for a reason
<jcastro> marcoceppi, idea
<jcastro> alternative idea I mean
<jcastro> put a bug # input field on the review queue, so we can just add individual ones by hand?
<marcoceppi> sure
<marcoceppi> that works
<marcoceppi> got to figure out how to get rid of all these guys
<jcastro> or maybe filter by date?
<jcastro> anything before the last few months ignore?
<lazyPower> marcoceppi: seems like tagging manually would be acceptable, or if there is a github repository link present - but that adds overhead to the workers since they have to parse the message body.. not sure how you feel about that.
<marcoceppi> this method just sucks in general
<lazyPower> there are definately drawbacks to it
<lazyPower> would be nice if we had a way to do something like charm publish --review, that sniffs the repo and ships a review request directly to the rev queue
<lazyPower> its api powered, and doesn't solve for the existing stuff we have open, but would be a nice feature post charm publish.
<marcoceppi> that is what will happen
<marcoceppi> but publish deson't exist yet
<rbasak> sinzui: what's libgo5 (>= 4.9.1-0ubuntu1) [!amd64 !i386 !armhf]? I've not seen it before.
<rbasak> While we're on the topic actually, where's your packaging branch? We've diverged a little bit, and I'd like to send you MPs.
<sinzui> ah!
<sinzui> sorry rbasak I sould have notified you of the change. That dep is to ensure arm and ppc getting get the lib we know golang needs with gcc builds
<sinzui> rbasak, the dep is inresponse to IBM setting up new trusty machine and not accepting updates. They put new juju on it and it panicked. trusty shipped with an old version of libgo
<rbasak> sinzui: OK, thanks. Is there a bug on this?
 * sinzui finds it
<rbasak> The process for the SRU isn't clear on whether I need a specific bug with independent verification for packaging fixes or not.
<rbasak> (since Juju upstream has an exception - it's not clear to me whether that applies to packaging)
<gaughen> jcastro, I'd use the the ubuntu-server list
<sinzui> rbasak, https://bugs.launchpad.net/juju-core/+bug/1377325
<mup> Bug #1377325: The ppc64/arm versions of Juju should depend on a more recent version of libgo5 <arm64> <packaging> <ppc64el> <juju-core:Fix Released by sinzui> <https://launchpad.net/bugs/1377325>
<rbasak> sinzui: thanks! And do you have a packaging branch somewhere?
<sinzui> rbasak, the issue would never been discovered if the machines were accepting updates
<marcoceppi> Okay, most of the review-queue is cleaned up
<sinzui> rbasak, https://code.launchpad.net/~juju-qa/juju-release-tools/packaging-juju-core-default
<rbasak> Great. Thank you! I'll send you some MPs soon.
<mbruzek> Hello juju people. Is there any reason that the Juju PPA is still named "Ensemble"?
<mbruzek> gpg: key C8068B11: public key "Launchpad Ensemble PPA" imported
<marcoceppi> mbruzek: that's the gpg key
<mbruzek> sudo add-apt-repository -y ppa:juju/stable
<marcoceppi> not the ppa
<mbruzek> marcoceppi: OK, should we update that or no?
<marcoceppi> The key is generated on LP at the time of creation and when the stable ppa was created it was Ensemble
<marcoceppi> not really, it's a minor thing
<mbruzek> ack
<mbruzek> just noticed that
<mbruzek> thought I would bring it up
<marcoceppi> cool, good eye
<marcoceppi> Okay, review queue is reset
<marcoceppi> Adding a submit button
<mbruzek> marcoceppi: why do the "ubuntu" charm not show up in this listing? http://manage.jujucharms.com/charms/trusty
<mbruzek> I am trying to get a list of all the trusty charms.
<mbruzek> I can issue charm get cs:trusty/ubuntu but I do not see it in the above listing.
<jcastro> hey jose
<jcastro> jose, any reason you haven't pushed owncloud to trusty?
<marcoceppi> tvansteenburgh: 1.8.1-0ubuntu2 was just uploaded to the ppa, should resove that missing dep
<tvansteenburgh> marcoceppi: tyvm!
<mhall119> jcastro marcoceppi gaughen arosales are you all going to be UOS track leads for Cloud & DevOps this cycle?
<gaughen> mhall119, sure
<marcoceppi> mhall119: I'm at re:Invent during UOS
<arosales> mhall119: as will jcastro
<mhall119> marcoceppi: can you help recruit and schedule sessions leading up to UOS week?
<arosales> mhall119: please let myself, perhaps also include randall. I'll confirm to have someone else from the Juju side
<marcoceppi> mhall119: I can help, surely
<mhall119> ah yes, we have rrnwexec now
<mhall119> can you all mark youselves as attending on https://launchpad.net/sprints/uos-1411 so you're added to summit.u.c
<mhall119> rrnwexec: want to be a track lead?
<marcoceppi> mhall119: registered
<mhall119> thanks everyone
<rrnwexec> mhall119: if that's ok with Antonio, sure. my domain is IBM/Power though, so jorge may be a better lead
 * mhall119 notices that jcastro is the only one who didn't reply, slacker
#juju 2014-10-28
<jose> jcastro: still need to refactor test, they were failing with nonsense errors
<schkovich> hi guys, is it valid to have a charm that is subordinate of a charm that already has subordinate relation? Lets say that java charm subordinates to puppet charm while solr charm subordinates to java charm?
<schkovich> while java charm would be installed as soon as relation to puppet charm is defined, solr charm (subordinated to java charm) would never get installed
<schkovich> http://pastebin.com/Fyvq8D91
<schkovich> metadata: http://pastebin.com/XXHXs1TE
<X-warrior> what is the latest juju version available to mac os?
<jcastro> marcoceppi, can we sort out ~elasticsearch-charmers? They need to get a fix in for a demo.
<jcastro> https://code.launchpad.net/~s-matyukevich/charms/trusty/elasticsearch/elasticsearch-dns-bug-fix/+merge/239547
<jcastro> need to get this one in
<lazyPower> jcastro: i'll take a look
<lazyPower> noodles775: ping
<rick_h_> lazyPower: marcoceppi we need to move the elasticsearch bundle to a new name for the release. We have the flat namespace and no charm/bundle can share the same name in the user space.
<rick_h_> lazyPower: marcoceppi what's the best way to file that/get it updated?
<marcoceppi> rick_h_: open a merge request and rename the bundle?
<rick_h_> marcoceppi: rgr ok will do
<rick_h_> marcoceppi: but it needs a new bzr path/etc
<marcoceppi> rick_h_: oh, it needs a bzr path? I thought just the name in the bundle needed to be fixed
<rick_h_> but I'll create a mp into that new space and then get it promulgated I guess.
<lazyPower> that will work for creating the new path, but we'll need to follow behind you and clean up the existing path.
<lazyPower> i would imagine this will affect a few other bundles as well...
<rick_h_> lazyPower: yes, right now the one that jumped out to us, as it's highlighted on some marketing pages is the ES one
<rick_h_> lazyPower: we'll be working to get a list of all collisions and working on updating them
<lazyPower> rick_h_: sounds good. if you could share the spreadsheet with us that would be muy bueno.
<rick_h_> lazyPower: will do
<rick_h_> kadams54: hatch ping, where are we at with the added services stuff feature?
<hatch> rick_h_: kadams54 is finishing up the database updates from the browser handlers
<hatch> the canvas renderer update code is done but breaks the gui without that branch
<hatch> well - breaks the added services thing
<hatch> so it's holding until his lands
<hatch> then i'll likely have to do some merging and it'll be gtg
<kadams54> hatch and I talked some yesterday about how to handle related services
<rick_h_> kadams54: ok, are we on track to land today then or is this going to go on into this week?
<kadams54> And I think (hatch, correct me if I'm wrong) we landed on me handling those related services, as far as updating their hide/fade/highlight properties correctly.
<kadams54> On track to land today, but it'll probably be right at EOD.
<rick_h_> honestly, added services bar is now entering wk4 and we either need to finish it up or we need to figure out what's wrong and rethink it. We need to move on to help with the other release.
<rick_h_> kadams54: ok, if that changes please let me know.
<kadams54> Will do.
<X-warrior> Who can I add a mysql relation to more then one service without creating new databases? I would like to use the same database to multiple 'services'. Is it possible?
<X-warrior> How*
<lazyPower> X-warrior: i may be incorrect, but as I understand it, the mysql charm reads teh service name and will create a DB for each different service. To support that style of deployment the charm would have to be extended with another relationship type, such as shared-db.
<X-warrior> lazyPower: I guess so, I just started using shared-db to check if it solves this problem :D
<lazyPower> X-warrior: that looks like it will do it
<lazyPower> as the dbname is part of the relationship. just checked the source of shared-db-relation-changed
<lazyPower> marcoceppi: ^ can you confirm this is the proper route for sharing db's among multiple services?
<marcoceppi> X-warrior: MySQL already supports this
<X-warrior> should I add something special to use shared-db? Or all relations that are using shared-db for a mysql will have the same credentials?
<marcoceppi> X-warrior: you just need to tell MySQl the database name you wish to us
<marcoceppi> it'll create unique creds per instance that connects
<X-warrior> how can I set this database name?
<marcoceppi> you do a relation-set in the database-relation-joined hook of your charm for the "database" iirc
<X-warrior> shared-database-relation-joined probably
<marcoceppi> X-warrior: well you can name the relation whatever you want
<marcoceppi> so you can create a database relation with the mysql-shared interface
<X-warrior> marcoceppi: doesn't a shared relation uses password?
<marcoceppi> X-warrior: no, I'm pretty sure it creates a unique user/pass per unit just like the regular mysql interface
<marcoceppi> only it's sharing a database name between each service
<X-warrior> marcoceppi: So I guess I'm not getting it. Do I need to have a shared-db and a database? Because the relation-changed from shared-db is not receiving any user/password on relation-get
<marcoceppi> X-warrior: the relation name is irrelevant
<marcoceppi> it's the interface you're implementing
<X-warrior> I'm implementing mysql-shared, but the relation-get doesn't return username/password.
<marcoceppi> X-warrior: it should
<X-warrior> I was using mysql interface then I noticed I had this particular case, on mysql interface the relation-get were working. On shared it doesn't seem to.
<mbruzek> Is there someone out there that knows why my machines are pending and can not start?
<mbruzek> http://pastebin.ubuntu.com/8722347/
<mbruzek> hey marcoceppi I think this has something to do with the setting up juju local to work with different accounts.  Do you have a moment to take a look ?
<mbruzek> aisrael, tvansteenburgh, kwmonroe ^
<tvansteenburgh> mbruzek: can you paste the relevant bits of your environments.yaml?
 * tvansteenburgh really has nfc
<mbruzek> tvansteenburgh: I googled the error I am seeing in that log and found this https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1290920
<mup> Bug #1290920: non-default lxc-dir breaks local provider <cts> <local> <lxc> <regression> <juju-core:Triaged by niedbalski> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1290920>
<mbruzek> tvansteenburgh: http://pastebin.ubuntu.com/8722467/
<rbasak> sinzui: I've uploaded 1.20.11 to Trusty (waiting SRU team approval) and Vivid (built and available in vivid-proposed).
<mbruzek> tvansteenburgh: From reading that bug, I am thinking it could be related to multiple people trying to use juju local on the same system.
<rbasak> sinzui: I'm off for a week now though. Once the SRU team accept the package into trusty-proposed, please could you verify it?
<rbasak> sinzui: the tracking bug is bug 1386144
<mup> Bug #1386144: juju-core 1.20.11 is not packaged in Ubuntu <block-proposed> <update-software-version> <juju-core (Ubuntu):Triaged by ubuntu-server> <juju-core (Ubuntu Trusty):Triaged by ubuntu-server> <https://launchpad.net/bugs/1386144>
<rbasak> (I mean verify the pieces you normally would - nothing extra)
<rbasak> Then you can use the results of that in your release decision.
<sinzui> rbasak, already on my list to do :)
<rbasak> Great - thanks :)
<mbruzek> aisrael, kwmonroe, can we try destroying your envrionments and see if the regular local works?  I am thinking each environment is trying to log to the same place
<kwmonroe> i'm fine with that mbruzek
<aisrael> ^^ destroy away
<mbruzek> aisrael, kwmonroe, negative on my theory... $ ls -d juju-*
<mbruzek> juju-ubuntu-local  juju-ubuntu-local-aisrael  juju-ubuntu-local-kwmonroe
<mbruzek> They are all in different directories, but I am going to destroy the environments to see if the regular one starts working
<tvansteenburgh> if/when we figure this out let's remember to update https://juju.ubuntu.com/docs/config-LXC.html#configuration
<kwmonroe> ack
<mbruzek> aisrael, kwmonroe, no good, I still get an error in status:  agent-state-info: container "ubuntu-local-machine-1" is already created
<mbruzek> marcoceppi, aisrael, kwmonroe I am still stuck with this local system, no machines start
<aisrael> mbruzek: what about creating a local-mbruzek environment and seeing if that works?
<mbruzek> aisrael: Yes I *just* started off a deployment in local-mbruzek
<marcoceppi> mbruzek: I was lunching
<marcoceppi> still broken?
<mbruzek> marcoceppi: I can deploy with local-mbruzek environment but not the "local" environment.
<mbruzek> kwmonroe, aisrael ^
<marcoceppi> mbruzek: that sucks, lets talk after 3 EST
<mbruzek> marcoceppi: http://pastebin.ubuntu.com/8722885/
<mbruzek> marcoceppi: I was able to deploy ubuntu, but when I tried to run a test I get all containers fail to start, different error than the "local" environment.
<tvansteenburgh> this when i just hit it with the juju-clean hammer and start over
<mbruzek> yes let me try that
<mbruzek> tvansteenburgh: the hammer did not work, now I am getting the same error as the "local" environment
<tvansteenburgh> :(
<jcastro> jose, around?
<noodles775> lazyPower: hey there. I'll work on a fix for the ec2 es bug today. The branch that's currently proposed will work, but (a) we can't merge it as is, and (b) I'm hoping we don't have to use sockets but am not sure yet. You mentioned sockets failing in other scenarious, was it being used for the same reason (trying to find an ip for a private dns)?
<lazyPower> noodles775: the issue was with socket failing, socket wraps hostname, which issues a call on our openstack deployments that fails
<lazyPower> noodles775: i'm not convinced it will fail until i get a result back from our SETeam that someone has tried it and life is good... but initially i have a gut feeling this is going to cause more headaches than we're anticipating
<aisrael> lazyPower: question about this commit: https://bazaar.launchpad.net/~charmers/charms/trusty/haproxy/trunk/revision/85
<aisrael> It's introducing a new lint error:
<aisrael>  /home/ubuntu/aisrael/trusty/haproxy/hooks/hooks.py:972:80: E501 line too long (80 > 79 characters)
<aisrael> but removing the spaces you introduced don't seem to throw a lint error?
<lazyPower> aisrael: http://paste.ubuntu.com/8723402/
<Beret> who can I bug to get a charm to show up in the store that's been pushed?
<lazyPower> aisrael: i think its a discrepancy between linter configs between my laptop and my desktop
<lazyPower> Beret: how long ago did you push it?
<Beret> 10 mins
<lazyPower> Beret: takes up to 30 minutes
<Beret> can we manually kick it
<Beret> ?
<lazyPower> store ingest happens on a 15 minute cycle, so depending on when it was pushed
<lazyPower> hatch: do you guys do requests?
<hatch> like for the next juju song? ;)
<dpb1> ah, ok
<lazyPower> hatch: more like for kicking off a store ingest, mr store dj
<hatch> lol, *wiki wiki reeeiiinnngggessstttt*
<hatch> lazyPower: best to ping rick_h_ for that
<lazyPower> hatch: with him being out, request denied by default right?
<aisrael> lazyPower: Yeah, that's what I'm seeing. If I revert your patch, lint passes clean
<Beret> rick_h_, hi :)
<lazyPower> aisrael: punt
<hatch> lazyPower: heh tbh I don't have access to do it so I can't,
<hatch> I probably should get on that though, sorry
<lazyPower> hatch: you're good. just looking to get an answer ;)
<marcoceppi> noodles775 bloodearnest you guys now own the elasticsearch and gunicorn charms
<marcoceppi> jcastro: ^
<lazyPower> marcoceppi: did they move namespaces?
<marcoceppi> yeah
<marcoceppi> onlineservices-charmers
<lazyPower> ack. typically i get emails about that
<lazyPower> lp email must be backed up
<marcoceppi> elasticsearch trusty/precise and gunicorn precise
<noodles775> marcoceppi: Thanks. I don't have anything to do with the precise elasticsearch - if it's no issue, it'd be better to leave that under ~charmers. I've only worked on the trusty one (which was a rewrite).
<bloodearnest> marcoceppi: hmm, we are using a (currently unmodified) branch of gunicorn fine on trusty. What do I do to add a trusty version?
<marcoceppi> bloodearnest: push it to the trusty name space and let one of us know
#juju 2014-10-29
<noodles775> marcoceppi: hrm, it looks like moving the elasticsearch branches is causing jujucharms.com to error: https://jujucharms.com/trusty/elasticsearch-6/
<noodles775> marcoceppi: that is, I see a notification in the GUI: Charm API error of type: no_such_charm
<jose> jcastro: around now. what's up?
<sebas5384> hey guys! o/
<sebas5384> somebody know news about the vagrant flow?
<jujuFig> hello
<thumper> o/
<jujuFig> hey, life! Last time I has here it was silence the whole time
<jujuFig> I don't suppose anyone feels like helping me with a DNS related issue, would they?
<thumper> what sort of issue?
<thumper> the juju hackers idle here too, but don't always answer idle pings
<jujuFig> I'm running juju under vagrant. That was fine, but I have a charm that needs FQDNs for it to work properly (no ips). I I;m trying to setup a DNS server on my Vagrant box, but I have no idea how to get the juju charms (vms in themselves) to pick up on it
<thumper> hmm...
<thumper> wouldn't it be easier just to set a FQN for the machine?
<thumper> isn't that faster than setting up a DNS server?
<jujuFig> Well, yeah, haha, probably. But I'm trying to augment a charm, and I want to have it do some slick horizontal scaling... Except it really won't work with IPs. If i hacked around and ste the FQDNs manually and played in the /etc/hosts file its not very slick
<jujuFig> I
<jujuFig> I guess this is the price I pay for not having physicaly DNS servers at my house, hehe
<thumper> what is it that you are trying to scale?
<jujuFig> It's a web application running on tomcat actually (but it's more complicated than that)
 * thumper thinks who might be able to help
<thumper> it is late for jcastro and marcoceppi
<thumper> they probably aren't around
 * thumper can't think of anyone else of the top of his head
<rick_h_> jujuFig: https://jujucharms.com/~lazypower/precise/dns-3/?text=dns#readme might be worth a look?
<jujuFig> I'll check back sometime tomorrow and see if I can find someone!
<jujuFig> Oh, thanks rick, I'll take a look at that too
<rick_h_> jujuFig: but basically this works in MAAS because you setup and run a dns server + dhcp server configured to use it. I'm not sure how you'd do this without doing that work aside from some sort of subordinate that you tack onto each service to try to configure dns stuff onto them
<rick_h_> jujuFig: I'd check out what others do for vagrant and dns: https://inuits.eu/blog/dns-ubuntu-lxc for instance and http://goo.gl/ZHSwGo
 * rick_h_ is up past his bed time and runs away 
<jujuFig> Thanks again!
<rick_h_> np, good luck
<rick_h_> I look forward to a blog post on how you got it all working :)
<jujuFig> Almost certainly :)
<lazyPower> tvansteenburgh: meteorjs just went 1.0 yesterday
<tvansteenburgh> lazyPower: thanks for the heads-up
<lazyPower> np o/
<sebas5384> hey! o/
<sebas5384> i was wondering if I still need swift in openstack in order to bootstrap an openstack environment
<fuzzy> tvansteenburgh: Are you planning on moving the meteor charm to trusty anytime soon?
<tvansteenburgh> fuzzy: it's not high on my priority list, but i imagine i'd get around to it eventually
<tvansteenburgh> fuzzy: although honestly i guess it would be quick and easy, assuming the tests pass
<tvansteenburgh> fuzzy: i can try to squeeze that in later this afternoon
<fuzzy> Ok np, it's just the only thing in my Juju stack that is not trusty so I thought I would ask. :)
<tvansteenburgh> ah cool, i'll do it!
<fuzzy> Thank you!
<tvansteenburgh> sure thing
<fuzzy> If you pm me a paypal email to send you beer money I'll happily send ya a tip :)
<tvansteenburgh> wow, incentive indeed
<tvansteenburgh> not necessary though :) if we ever meet in person you can buy me a beer
<fuzzy> Fair enough but I don't get out much and it's easier for me just to push buttons :)
<noodles775> marcoceppi, tvansteenburgh : What does a charm MP need to have the auto tests run? I'm trying to fix the testing for the elasticsearch charm, but aren't triggering the tests: https://code.launchpad.net/~michael.nelson/charms/trusty/elasticsearch/use-new-charmhelpers/+merge/239935
<marcoceppi> noodles775: it's not quite automatic yet
<marcoceppi> the indicators are clickable
<marcoceppi> noodles775: I don't see your merge proposal in here http://review.juju.solutions/
<marcoceppi> ah, because charmers doesn't own the branch anymore
<marcoceppi> that's something that will be landing in the next release of the review queue
<marcoceppi> but if it's not a charmers branch it doesn't show up in the review queue
<marcoceppi> next week you'll have an onlineservices-charmers queue with your items in there and the testing associated with it
<noodles775> marcoceppi: yeah, i don't want it reviewed yet anyway, but do want to run the auto tests on hp/ec2 etc. So that's not possible at the moment?
<marcoceppi> noodles775: not exactly, I can help you with that offline tomorrow
<marcoceppi> it's EOD here
<marcoceppi> there are ways around that
<noodles775> marcoceppi: ok, enjoy your evening. Thanks for jumping in and replying :)
#juju 2014-10-30
<gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/nova-compute/resurrect-peer-relation/+merge/239964 if you have a sec
<jamespage> gnuoy, +1
<gnuoy> ta
<gnuoy> jamespage, are you prepared to extend that +1 to https://code.launchpad.net/~gnuoy/charms/trusty/nova-compute/resurrect-peer-relation/+merge/240093 ?
<gnuoy> (stable rather than next)
<jamespage> gnuoy, +1 and please use publish to ensure precise/trusty stay in sync
<gnuoy> ta
<X-warrior> I'm not able to get username/password on mysql-shared interface. But If I change it to mysql, I'm able to get the username/password. Ideas on what could be wrong?
<noodles775> marcoceppi, tvansteenburgh: Are either of you able to wrangle my MP so that it gets submitted for the auto-tests? (I'd like to know that it fixes the issue and works on ec2 + hp before merging): https://code.launchpad.net/~michael.nelson/charms/trusty/elasticsearch/use-new-charmhelpers/+merge/239935
<tvansteenburgh> noodles775:  i can one sec
<lazyPower> noodles775: awesome!
<tvansteenburgh> noodles775: well here it is, but it's not exactly useful http://reports.vapour.ws/charm-tests/charm-bundle-test-1389-results
<tvansteenburgh> noodles775: we've got some problems on the jenkins slave right now apparently
<marcoceppi> Welcome to charmers tvansteenburgh and Tribaal!
<Tribaal> thanks marcoceppi !
<tvansteenburgh> marcoceppi: thanks!
 * Tribaal feels infused with the ~charmers halo
<lazyPower> Congrats!
<mbruzek> marcoceppi: did you finally kick me out of charmers?
<mbruzek> marcoceppi: I can not initiate builds on the review queue.
<marcoceppi> yes
<marcoceppi> again
<marcoceppi> broken
<marcoceppi> been broken for a while
<marcoceppi> will be fixed next week
<mbruzek> marcoceppi:  OK
<fuzzy> tvansteenburgh: Did you have any luck with moving Meteor to trusty?
<tvansteenburgh> fuzzy: i've been waiting for you to show up so i could confess that i ran out of time yesterday afternoon
<fuzzy> <3 no worries
<tvansteenburgh> fuzzy: i'm firefighting right now, but meteor is next on my list, i promise!
<fuzzy> No worries
 * fuzzy offers a firehose
<noodles775> tvansteenburgh: Thanks! At least I can see from that that the first functional test (00-create-index) passes on ec2, but yes, we really need all results to be confident to merge. When will the jenkins slave be fixed, any ideas?
<tvansteenburgh> noodles775: i'm about to update it and try again, will keep you posted
<tvansteenburgh> noodles775: in my local testing, everything passes on lxc, but something is timing out on ec2
<tvansteenburgh> noodles775: unfortunately there's an uncaught SIGALRM somewhere, so i'm having a hard time figuring out where the timeout is happening
<tvansteenburgh> noodles775: jenkins updating now, i'll kick off the build of your MP and we'll see where we're at
<noodles775> Great, thanks tvansteenburgh
<balloons> marcoceppi, how much do you love drupal?
<marcoceppi> balloons: I love it as much as I love WordPress
<balloons> marcoceppi, I ask because I'm curious about what it would take to charm *.qa.ubuntu.com. It's drupal7 plus a few modules
<balloons> and I won't ask how much you love wordpress :-)
<marcoceppi> balloons: you should totally talk to sebas, who isn't currently on, but he's a part of the Drupal community and has been working on a Drupal charm
<balloons> marcoceppi, mm, thank you for the lead
<marcoceppi> tvansteenburgh: thanks!
<marcoceppi> balloons: if you'd like I can link you two up via email, he's Sebastian on the mailing list
<balloons> marcoceppi, that would be lovely as it will make sure I followup
#juju 2014-10-31
<noodles775> tvansteenburgh: Hi there. Let me know if you managed to sort out the auto-test issues. I've got a branch I'd love to land for elasticsearch (I've tested it locally, as well as manually upgrading some deployment scenarios): https://code.launchpad.net/~michael.nelson/charms/trusty/elasticsearch/firewall_optional/+merge/240211 (it's got a prereq branch which is also approved)
<skay> hi, new here. need to write a charm to deploy a django stack (apache, postgres, gunicorn) and would like to look at an existing charm for this as an example to emulate. I'm using python-django for the django part. the postgres part seems straightforward. the apache2 (and I wnat to do haproxy at some point, but small steps) is not at all as obvious to me
<lazyPower> skay: we actually use bundles for that purpose
<lazyPower> skay: if you have juju-gui deployed, you acn visit your gui instance and build the bundle in your env, or you can model a deployment on jujucharms.com at zero cost to you (kind of a drafting tool really) then export the bundle and deploy to your provider.
<skay> lazyPower: oh, ok. I'll play around with that and look at the code it generates.
<lazyPower> skay: http://paste.ubuntu.com/8761147/
<lazyPower> skay: thats just drag n drop stuff - you can get more detailed with the deployment like placing your django and postgres instances in lxc/kvm containers on a single host to cut down on costs, and deploy haproxy to the host machine handling your web routing - thus effectively placing your entire stack in a single machine.
<skay> lazyPower: thanks
<lazyPower> skay: stay tuned, early next week i'll have a video tutorial published about a new charm hazmat has in the works to do software defined networking to do cross-host container communication so you can do density with your deployments in lxc and scale out.
<kwmonroe> skay: you may also want to look at https://jujucharms.com/bundle/django/2/example-single/ -- fair warning: i've never deployed this bundle, but it at least looks close to what you want..
<skay> kwmonroe: thanks. I did find that one and download it just now (searched for bundles and it popped right up)
<skay> thanks both!
<lazyPower> kwmonroe: nice follow up
<kwmonroe> thanks lazyPower.  nice initial outreach.  let's see if we can pat each other's backs all day long.
<lazyPower> kwmonroe: hit me with your best shot :D
<kwmonroe> i'm over it
<lazyPower> someone's feeling spunky today
<kwmonroe> caffeine is a helluva drug
<khuss> my maas nodes are stuck in "commissioning" state. Looks like the node is not able to update packages. Any ideas on debugging this problem?
<lazyPower> khuss: is your mass-controller node able to reach the internet?
<khuss> lazyPower: the maas controller is able to reach the internet
<lazyPower> khuss: ok, i ask because there is a curtain proxy on all nodes that routes through your controller.
<lazyPower> khuss: have any logs we can look at?
<khuss> lazyPower: i tried by making the controller both DHCP and DNS
<khuss> lazyPower: also by making it just the DHCP server
<khuss> lazyPower: which log files?
<khuss> lazyPower: i suspect it could be the proxying issue. but not sure how to debug it
<lazyPower> khuss: is this a VMAAS setup with KVM machines or are you running bare metal?
<khuss> lazyPower: bare metal on Dell PowerEdge
<khuss> lazyPower: when the commissioning fails, the nodes gets powered down
<lazyPower> hmm i'm not sure, i'm poking around in my maas logging directory for the logs we'd be interested in
<lazyPower> 1 moment
<tvansteenburgh> noodles775: jenkins is still fubar
<lazyPower> i'm far from a maas expert, but i've got some experience in troubleshooting a vmaas setup (ie: my own)
<khuss> lazyPower:  thanks
<tvansteenburgh> noodles775: fwiw your tests all pass for me on lxc
<tvansteenburgh> noodles775: i can't even bootstrap on ec2 atm
<lazyPower> khuss: maybe ask in #maas as well
<lazyPower> khuss: yeah i forget where the logs are located :( sorry i wasn't much help.
<khuss> lazyPower: ok.. tx for trying
<lazyPower> skay: the bundle i linked is subject to a bug i just discovered -it exported "null" and .nan in the keys for postgres - which will fail a deployment for you
<lazyPower> i've got people looking into it, but treat that as the worst case example - the bundle you fetched from teh store will not have this behavior.
<skay> lazyPower: *nod*
<kwmonroe> mbruzek: can you point me to docs or a test.py that does something besides assert that deployment worked?  i want budnletester to twiddle config, but am not sure of the syntax.
<mbruzek> kwmonroe: sure.
<mbruzek> I always point people to my lamp tests
<mbruzek> http://bazaar.launchpad.net/~ibm-demo/charms/trusty/lamp/trunk/view/head:/tests/10-deploy-test.py
<mbruzek> kwmonroe: ^
<kwmonroe> cool mbruzek - thanks!
<mbruzek> Documented like it should be
<kwmonroe> i see that.  but you got a thing against whitespace?
 * tvansteenburgh chuckles
<mbruzek> There is whitespace in there
<mbruzek> Just not very much
<kwmonroe> :)  just giving you grief.  it's probably faster this way.
<mbruzek> this test does not go into config, sorry kwmonroe
<mbruzek> kwmonroe: Here is another example
<mbruzek> http://bazaar.launchpad.net/~charmers/charms/precise/tomcat/trunk/view/head:/tests/10-configured-deploy.py
<mbruzek> kwmonroe: line 124 where the code calls unit.file_contents
<kwmonroe> nice mbruzek - those help alot
<wwitzel3> is there a good way to force a charm in to an error state? or do we have a testing charm that fails for certain hooks?
<natefinch> wwitzel3: edit the charm and throw in a line that errors out
<natefinch> wwitzel3: pretty trivial to write a test charm to use
<wwitzel3> natefinch: yeah, I was just chekcing to make sure there want something like fail-install-charm .. before i went and tweaked one to do that
<aisrael> Is there a way to file a bug against a PPA in launchpad?
<lazyPower> aisrael: just the project unfortunately.
<aisrael> lazyPower: Thanks!
<jrwren> Can anyone using mongodb charm and relating it to other charms via database relation, please ping me.?
<lazyWeekend> jrwren: ping
<fuzzy> tvansteenburgh: <3
<tvansteenburgh> fuzzy: :(
<fuzzy> It's ok, I still love ya :)
<fuzzy> Happy Halloween
<jrwren> lazyWeekend: !
<tvansteenburgh> you must think i'm blowing you off by this point, but i'm really not. it's been a really bad week
<fuzzy> Not at all
<fuzzy> I can only assume you are as busy as me
<tvansteenburgh> if that's the case then i feel sorry for you :)
<fuzzy> it won't always be like this
#juju 2014-11-01
<tvansteenburgh> i was overdue for a week of pain, too much productivity and smooth sailing lately
<fuzzy> shhhhhh
<fuzzy> Don't let next week get any ideas
#juju 2015-10-26
<sh__> hi team
<sh__> i have a requirement where i have to change my charm name in the store , for example , form platform lsf to ibm platform lsf.I have changed my charm folder name ,metadata file
<sh__> But still its not getting reflected in the store.My stream name is launchpad is : lp:~ibmcharmers/charms/trusty/platform-lsf/trunk ,I dont want to create a new stream with name as ibm-platform-lsf.Can i edit my existing stream , is there any option in launchpad ?
<sh__> Can you please help me out here
<Prabu> Hello Tea,
<Prabu> Hello Team, I am testing my charm in amazon webservice and my charm is supported on Ubuntu Power PPC64LE machine.. while deploying my charm in AWS it is failing due to unspported platform.. Please advise how to change OS/Architecture in Amazon webservice.
<stub> Does anyone recall why the mock library is pinned in charmhelpers?
<stub> Hmm... despite pip installing old-mock into the venv, new mock is being imported from the system because it is newer
<Icey> any updates on https://bugs.launchpad.net/juju-core/+bug/1385276
<Icey> ?
<mup> Bug #1385276: juju leaves security groups behind in aws <destroy-environment> <ec2-provider> <repeatability> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1385276>
<Icey> I just hit my 100 Security Group limit in AWS with 0 instances deployed
<Icey> juju has been destroyed in the environment
<lazypower> Icey there's a script int he CI repo to cleanup your sec groups
<lazypower> 1 sec, i'll see if i can fish it up
<lazypower> Icey http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/clean_resources.py
<lazypower> wait thats probably not it...
<lazypower> disregard... thats not the clean sec groups
<sh__> Hi Team, I have a charm pushed into the store with name platform-lsf , I want to change it to ibm-platform-lsf.To do so , I have modified my charm name and metadata file.Can someone help me how I can edit my existing trunk branch.
<mgz_> lazypower: CI really does have one though, lp:juju-ci-tools clean_resources.py depends on boto and an env that has your creds
<sh__> Currently its : lp:~ibmcharmers/charms/trusty/platform-lsf/trunk ,I want to change it to trusty/ibm-platform-lsf
<Icey> it's not hard to do manually just annoying that it isn't handled when spinning / tearing down a lot
<Icey> lazypower,
<nottrobin> hello juju folks
<nottrobin> does anyone know if there's a way for me to get juju to tell me the currently deployed charm version for a service?
<mgz_> cherylj, maybe add your new special tag to bug 1385276 for Icey?
<mup> Bug #1385276: juju leaves security groups behind in aws <destroy-environment> <ec2-provider> <repeatability> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1385276>
<nottrobin> I want to automatically run "juju upgrade-charm" only if there's a new version available
<mgz_> nottrobin: status has that info, under service charm: and can-upgrade-to:
<cherylj> mgz_: sure, I can add it
<mgz_> sh__: you can just push --remember to the name you want
<mgz_> sh__: or edit branch details in the web interface
<nottrobin> mgz_: I don't see a "can-upgrade-to". "services -> {service-name} -> charm" says things like "local:trusty/haproxy-0" - but I don't know how to use that to tell which charm revision is deployed
<mgz_> nottrobin: you need to deploy from the charmstore to have the nice upgrade bits
<nottrobin> mgz_: hmm. We can't do that in production environments :(.
<sh__> I pushed my charm name ie ibm-platform-lsf to my trunk branch lp:~ibmcharmers/charms/trusty/platform-lsf/trunk , but still its showing platform-lsf in charm store instead of ibm-platform-lsf
<mgz_> sh__: right, you didn't actually rename the branch on lp
<sh__> Also in web interface , not able to find an option to edit this branch name from /trusty/platform-lsf/trunk to /trusty/ibm-platform-lsf
<mgz_> nottrobin: I don't see why not, no routing to the internet from prod I guess?
<sh__> I dont want to create a new branch , just want to rename my existin lp branch , but in web ui ,not getting it to edit
<mgz_> sh__: not on charms/+source/your_charm?
<mgz_> that may need someone special
<mgz_> but pushing up under a new name should just work.
<sh__> when i go to my charms/trusty/platform-lsf/trunk branch ,i see edit option , its not listing me option to modify the charm name.
<mgz_> yeah, the branch page lacks it as charms are a bit magic, like distro
<sh__> Yes , i thought changing charm name and metadata file , i can see new name in store , but still reflecting old name
<nottrobin> mgz_: I think we have access to launchpad, which is presumably all it needs for the charmstore, but the reason we download the charms locally and deploy from there is 'cos we hack them in place before deploying
<sh__> then the only solution is to create new branch and tag my existing bug there ?But then i have to delete old lp branch
<sh__> is there any other way out ?
<mgz_> sh__: no, a rename should be possible, not sure who we need for it though
<sh__> ok
<mgz_> nottrobin: well, that doesn't sound ideal. would be nice to not hack things.
<lazypower> mgz_ ah! ta.
 * lazypower was off at lunch
<lazypower> wwitzel3 ping
<lazypower> I'm talking with cory_fu about payload management, one question came up that I dont have an answer to
<lazypower> as the payload classes are not predefined, what is that field intended to represent?
<lazypower> I've been stuffing my own context at it, in terms of 'monitoring', 'servicebot', etc.
<lazypower> which are meaningful only to me, as someone looking @ the data that launched it and has some context as to what its purpose is.
<cory_fu> My reading of the spec makes me think that it was intended to indicate which service (docker, kvm, etc) is running the payload
<lazypower> right
<lazypower> that to me is less interesting than the job its performing, so i may be using it incorrectly if there are future plans for that data field
<lazypower> i suppose tags would give me that as well
<wwitzel3> the intention was for a classification of the payloads, which maybe of many types
<wwitzel3> so the usage like servicebot or monitoring is the intended use
<nottrobin> mgz_: so what could be the dangers of "juju upgrade-charm" ing too often?
<cory_fu> wwitzel3: Is the payload-class just for informational purposes, or are we expecting the charm to use that info somehow?
<mgz_> nottrobin: mostly just that we store full copies of each version
<mgz_> so, that adds up for fat charms
<mgz_> it used to be a git branch, which performed terribly with fat charms and binary blobs
<mgz_> now it's stuffed in mongo
<mgz_> which has better worst-case performance, but can mean a lot of storage used
<nottrobin> mgz_: oh so it does literally store every version
<nottrobin> hmm
<mgz_> nottrobin: really you want to store some per charm, or per env for a mojo spec, metadata that holds the extra info your deployment needs to know about whether it needs upgrading
<wwitzel3> cory_fu: informational
<nottrobin> mgz_: except that it will hopefully be redundant quite soon :(
<wwitzel3> cory_fu: purely to provide the operator context
<mgz_> sure, but it's also a path towards the data you'll want anyway for resources
<nottrobin> well I'm thinking all I'd want to store is the "bzr revno" of the local charm before it's deployed
<nottrobin> which will be unnecessary when we deploy from store, because juju will track it
<mgz_> well, it depends if you also care about doing an update when you have a new blob that needs pickling into the charm
<mgz_> but just taking the cs revno and stashing it for comparison is fine, there's not much to wrap up there and it would be easy too yank out later
<mgz_> nottrobin: you could write a trivial seperate upgrade script,
<mgz_> that takes a juju env name and mojo spec
<mgz_> if the env has a magic var set, pull the rev info out of that, otherwise use the values from the spec
<Prabakaran> Hello Team, I am testing my charm in amazon webservice and my charm is supported on Ubuntu Power PPC64LE machine.. while deploying my charm in AWS it is failing due to unspported platform.. Please advise how to change OS/Architecture in Amazon webservice.
<mgz_> and upgrade everything that has a newer version in the store
<mgz_> Prabakaran: does aws actualyl have any ppc64el machines?
<mgz_> presumably not, which is your problem
<lazypower> Correct, afaik AWS is only x86 machines
<Prabakaran> i am new to AWS testing .. my charm is only supported on Ubuntu Power machine... is it possible for me to test my charm in AWS?
<lazypower> Prabakaran it is not at present.
<mbruzek> Prabakaran: AWS does not have the power machine architecture
<mgz_> well, maybe with manual deployment and a ppc64 guest on intel, if that works
<mgz_> but that's not better than testing locally with a container
<mgz_> I do not think any public clouds offer ppc64
<mgz_> be
<mgz_> best I've found is a link from debian, a br university has some machines you can request access to :)
<mbruzek> Prabakaran: You could check into siteox they have a ppc64le cloud
<mgz_> ah, forgot about that one
<mbruzek> Prabakaran: You have access to a ppc64le local environment right?
<Prabakaran> can u pls share debian link? so that i can explore and request for the same
<Prabakaran> ya i do have local environment access
<mbruzek> Prabakaran: I would test that it works with x86 on amazon, and ppc64le on the local environment
<mbruzek> That should cover all the architectures
<mgz_> Prabakaran: I was just reading wiki.debian.org/ppc64el - was hoping someone would have an openstack, so actually test the interfaces, but seems not
<Prabakaran> my charm is working perfectly in local ppcle machine.. but even though i wanted to test my charm in AWS cloud.. tat is y i was looking for the saame
<mbruzek> Prabakaran: Understood, but the public clouds just don't have power architectures available
<Prabakaran> I just wanted make sure my charm works not only in local.. anyway thank u all for ur support...lol
<bdx> whats going on everyone? I have a few questions regarding package imports in charm-helpers..... I was under the impression that charm-helpers modules shouldn't include other charm-helpers modules as dependencies....is this correct?
<bdx> or should I say shouldn't import other charm-helpers modules so as they become dependent on them
<bdx> I am primarily refering to http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/openstack/amulet/utils.py#L34
<bdx> I went ahead and modified the charm-helpers-hooks.yaml in each charm that pins "contrib.openstack|inc=*" so that OpenStackAmuletUtils(AmuletUtils) would be able to inherit AmuletUtils.....this fixed the issues I was seeing, but I'm not sure if what I did goes against charm-helpers best practices or not.....
<bdx> ^^*modified each charm's charm-helpers-hooks.yaml to include contrib.amulet
<bdx> Following^, I then synced charmhelpers to pull in contrib.amulet, push each to a personal branch and made a MR for each charm.....
<bdx> I feel like I have errored in the sense that, well this issue should be delt with differently....possibly by moving OpenStackAmuletUtils(AmuletUtils) into amulet.utils.....errrrr :-/ ...???
<bdx> core, dev, charmers, openstack-charmers: ^^^^
<lazypower> bdx : i know that the OpenStack CharmHelpers are a bit of a different case as they live under contrib
<lazypower> they're ovveriding behavior of the tooling to fit the openstack use case, which is why you see it implemented as such
<lazypower> they don't necessarily fit directly into the core of charm-helpers, and moving forward there's a discussion thats lost steam on the list about breaking apart charm-helpers.contrib into their own python packages so they can have proper dependency declarations when pip installing
<bdx> lazypower: great...so then pinning "contrib.amulet" in charm-helpers-hooks.yaml is the correct path to remedy issue?
<bdx> correct modifcation*
<bdx> lazypower:^?
<lazypower> I suppose
<lazypower> I would follow up with a post to the list asking the ~openstack-charmers if thats their recommended fix
<lazypower> but if it works, it sounds reasonable.
<lazypower> bdx sorry i'm a bit split brain today, really focused on resolving some k8's issues
<bdx> lazypower: no worries, thanks for responding!
<Odd_Bloke> So I'm trying to deploy a simple Jenkins setup (one jenkins and one jenkins-slave) to GCE.
<Odd_Bloke> And I'm hitting an error where the master can't contact the slave on port 8080.
<Odd_Bloke> I'm guessing that this is because port 8080 isn't open by default.
<Odd_Bloke> Do I have to go in manually to fix this, or am I missing some juju magic that could handle it for me?
<lazypower> Odd_Bloke i hope its not reading public address, you can try 'juju expose' on the slave, and juju resolved -r that unit in error
<lazypower> if it works, the relation is coded to listen / consume a network that may be firewalled by default
<lazypower> but thats difficult to say without looking @ the charm source
<lazypower> Odd_Bloke link to the slave?
<Odd_Bloke> lazypower: Oh, no, I have misdiagnosed this problem.
<Odd_Bloke> lazypower: It looks like the charm tries to connect to the master using HTTP.
<Odd_Bloke> And Jenkins has segfault'd. /o\
<lazypower> surprise!
<Odd_Bloke> I'm guessing I need to add a memory constraint.
<bdx> thedac: possibly you are not seeing it
<bdx> thedac: return OPENSTACK_CODENAMES[vers]
<bdx> thedac: and vers = '12.0.0'
<bdx> ....
<bdx> it would need to be return PACKAGE_CODENAMES[package][vers]
<bdx> I modified the MR to reflect that
<thedac> bdx: I'll take another look
<thedac> bdx: same issue we are looking at two different kinds of version strings. See for example http://pastebin.ubuntu.com/12975192/
<thedac> If we get paste the else in line 249 we are looking for version strings like 2015.2 not 12.0.0 and therefore use OPENSTACK_CODENAMES[vers]
<thedac> s/paste/past
<bdx> thedac: yeah, but vers = '12.0.0'
<bdx> so OPENSTACK_CODENAMES[vers]
<bdx> is not cool man
<thedac> bdx: see my last comment on the bug. If the version is 12.0.0 we will not get to that code
<thedac> That code is for version strings of the form year.point_release
<thedac> and if we do ... then the exeption is correct
<bdx> thedac: Oooooh ...the only reason I was hitting that and vers = '12.0.0' is because 'nova-compute' is not in PACKAGE_CODENAMES
<thedac> bingo
<bdx> thedac: I see. Nice. Soo the only way that can happen is if a package gets passed in that is not in PACKAGE_CODENAMES
<thedac> right. Which you fixed with your nova-compute MP.
<bdx> totally
<bdx> makes total sense now.....I was negleting to realize the only way vers == '12.0.0' is when package not in PACKAGE_CODENAMES is passed in. Thanks for hammering that out with me.
<thedac> no problem
#juju 2015-10-27
<blahdeblah> hi all - I'm trying to get my local provider working with juju and getting an unusual error: http://pastebin.ubuntu.com/12978319/
<blahdeblah> Google seems to be remarkably silent on this error message - any clues?
<Odd_Bloke> lazypower: Hey, so my problem with the Jenkins charm is actually more interesting; OpenJDK 7 has a bug where it segfaults if the fully-qualified hostname is greater than 64 characters.
<Odd_Bloke> lazypower: On GCE Juju, the fully-qualified hostname is 'juju-<UUID>-machine-<machine number>.c.<project name>.internal', which is almost always going to be over that.
<blahdeblah> hmmm - OK.  I manually created lxcbr0 and manually gave it the IP address 10.0.3.1/24 and it seems happy-ish.
<Odd_Bloke> blahdeblah: On what release?
<blahdeblah> laptop is wily; juju stable ppa; juju 1.24.7
<Odd_Bloke> blahdeblah: OK, there are known issues with lxc in wily release; what version of lxc do you have installed?
<blahdeblah> the one that comes with wily, whatever that is
 * blahdeblah checks version
<blahdeblah> 1.1.4-0ubuntu1.1
<Odd_Bloke> blahdeblah: Right, so you should have the fix; is the lxc service running?
<blahdeblah> I ran service lxc restart earlier; it didn't seem to start anything called lxc, though...
<blahdeblah> However, creating the bridge & IP manually seems to have enabled it to bootstrap
<blahdeblah> Trying a juju deploy cs:ubuntu now
<Odd_Bloke> blahdeblah: What does `service lxc-net status` show?
<blahdeblah> Odd_Bloke: http://pastebin.ubuntu.com/12978355/
<blahdeblah> Getting lots of this in juju debug-log output: machine-0: 2015-10-27 09:48:49 WARNING juju.apiserver.client status.go:653 error fetching public address: "public no address"
<Odd_Bloke> Interesting, I get http://paste.ubuntu.com/12978367/
<blahdeblah> I haven't rebooted since I installed lxc; is that necessary/recommended?
<Odd_Bloke> blahdeblah: I don't think so.
<blahdeblah> My feeling is that whatever it tried to do on install with networking setup failed
<blahdeblah> Nothing much seems to be happening with my cs:ubuntu deploy; just sitting there with status "Waiting for agent initialization to finish"
<Odd_Bloke> blahdeblah: Do you have anything that looks relevant in /etc/default/lxc-net?
<Odd_Bloke> blahdeblah: That step can take a while.
<blahdeblah> It has USE_LXC_BRIDGE="false" - not sure why; is that the default?
<Odd_Bloke> blahdeblah: I'm not sure, but I think that's what you need to adjust.
<blahdeblah> That's my thinking, too. :-)
<blahdeblah> status looks a bit different now :-)
 * blahdeblah rebootstraps & redeploys cs:ubuntu
<blahdeblah> still much the same result, even though it got a DHCP address and added a lxcbr0 port: Oct 27 19:58:33 peleg kernel: [44383.575124] lxcbr0: port 1(vethR77403) entered forwarding state
<Odd_Bloke> blahdeblah: "much the same result" being?
<blahdeblah> lots of machine-0: 2015-10-27 09:59:14 WARNING juju.apiserver.client status.go:653 error fetching public address: "public no address"
<blahdeblah> Oooh - hang on; firewall denies on lxcbr0; that's progress
 * blahdeblah fixes that
<blahdeblah> \o/ that's better
<blahdeblah> thanks for the help, Odd_Bloke
<blahdeblah> juju ssh ubuntu/0 working
<Odd_Bloke> blahdeblah: Happy to help. :)
<blahdeblah> I don't suppose there's a way to get them using a different mirror by default?
<blahdeblah> .au is a bit of a bandwidth backwater...
<Odd_Bloke> blahdeblah: There are ways to do it if you're creating a container from the command-line; I'll have to defer to someone Juju specific for Juju-started containers.
<blahdeblah> Looks like it: https://jujucharms.com/docs/stable/config-general
<Odd_Bloke> blahdeblah: Yeah, that looks promising. :)
<ezobn> Hi All ;-) Trying to upgrade to Liberty OpenStack release via Juju charms ;-) all works good, instead of nova-manage db sync - says that I have to run `nova-manage db migrate_flavor_data' first. But there no such option in nova-manage :-(
<Odd_Bloke> jamespage: ^ Sounds like one for you.
<blahdeblah> thanks very much for the help, Odd_Bloke
<Odd_Bloke> ezobn: It is the OpenStack Summit ATM, so helpful people are less likely to be on IRC. :)
<Odd_Bloke> blahdeblah: :)
<ezobn> Odd_Bloke: sure, but why not to try ?  ;-)
<blahdeblah> sweet - that apt-mirror seems to work
<Odd_Bloke> lazypower: I've filed https://bugs.launchpad.net/charms/+source/jenkins/+bug/1510450 for the problem.
<mup> Bug #1510450: Cannot install in GCE <jenkins (Juju Charms Collection):New> <https://launchpad.net/bugs/1510450>
<gennadiy> hi all, i have question about expose service in bundle. i added expose: true to my bundle but when i import this bundle to juju-gui my services are not exposed
<gennadiy> http://bazaar.launchpad.net/~tads2015dataart/charms/bundles/tads2015-demo/bundle/view/head:/bundles.yaml
<Icey> is it possible to tell Juju to not spread instances over different AZs with AWS?
<pmatulis> Icey: there is a way to target specific AZs
<pmatulis> juju machine add zone=us-east-1a
<marcoceppi> Icey: any reason you'd not want resilliance and best practices?
<Icey> ceph
<Icey> it tends to expect low latency (within one DC) rather than spread out over datacenters many (but not region) miles apart
<Icey> we can discuss more later, i'm off to lunch
<bbcmicrocomputer> marcoceppi: hey, I have multiple new charms that I want to write tests for.  What are the best practices for using 'juju test' with amulet framework and being able to write tests that deploy/relate these charms when they're not currently in the charm store?  Is there an environment variable that can be used which determines whether a charm is sourced from local disk or the charm store depending on current test environment?
<bbcmicrocomputer> I'd like to avoid hacking the actual test code to do this
<bbcmicrocomputer> I couldn't find anything in the docs
<jose> kwmonroe: ping
<lazypower> bbcmicrocomputer: really good questions. with a few answers
<kwmonroe> yo jose!
<lazypower> bbcmicrocomputer 1) there's a project we used called 'bundletester' - and this is by far the defacto method to use when testing your charms. http://github.com/juju-solutions/bundletester  for more information. this is pip installable via `pip install bundletester` - i highly recommend using a venv to islolate.
<kwmonroe> jose: i see you're a lawyer now ;)
<lazypower> bbcmicrocomputer: furthermore, to test local charms, you can `export JUJU_REPOSITORY=/path/to/charmdir` - so long as that points at your dirtree root for the charm repository. EG if your charms are in $HOME/charms, thats your JUJU_REPOSITORY, preserving the trusty/mysql dirpath for the strings you'll place in a bundle. Additionally, this lends itself nicely to amulet
<lazypower> bbcmicrocomputer: if you're not using a bundle to define a deployment leveraging multiple services, you can test each charm in isolation by declaring it inline on the deployment, for example, d = amulet.deployment,   d.add('mycharm') -- assuming mycharm is your charm name -- amulet will sense you're testing the charm that you're currently in, and thus deploy local:trusty/mycharm - so you're executing off the local charm.
<jose> kwmonroe: lol, was that what you were asking for? I kinda tried to get an answer but not sure if that was what you were looking for
<kwmonroe> jose: that was a mighty fine answer -- charm copyright covers charm source and not payloads.  the followup question about license requirements for redistributing binary packages on an external host is still a bit hazy, but that's not a typical charm author issue.  i think i'll call out the licenses in the readme like you suggested, and then maybe dig into requirements for re-distribution for repo maintainers.
<jose> kwmonroe: that's what the IBM people did for their charms, and they added a config option called 'accept-software-license' or something similar that defaulted to no. if people wanted to install, they would have to set that config option to 'yes' and only then it'd install
<jose> and that could get even easier by setting an error message on status saying 'you need to accept the license, see readme'
<lazypower> cmars - I'm pretty sure this is getting resolved with an incoming release?
<lazypower> cmars - terms will settle a lot of this, out of band of the charm code correct? ^
<lazypower> i'm calling attention to this so we dont waste cycles implementing something thats going to have to be gutted in a future rev of juju
<kwmonroe> yeah jose, i could go that route.. but ibm had their own special license.  my stuff is gpl licensed.  if we used a config option every time somebody needed to accept the gpl, we'd have a bunch of lameness :)  i'm cool with a callout in the readme and think that makes the most sense.  thanks!
<lazypower> AIUI its on the schedule for 1.26
<jose> hehe
<lazypower> or perhaps after 1.26....
<bbcmicrocomputer> lazypower: thanks for the detailed answers!
<lazypower> bbcmicrocomputer np, sorry it wasn't in the docs, we'll be cycling over them in the next week - bugs for that would be quite helpful
<lazypower> github.com/juju/docs - anything you find missing, misleading, et-al will help us nail down a tighter story for docs when we do the planning for the update
<lazypower> starting w/ the getting started guide, so there's plenty to pick from :)
<bbcmicrocomputer> lazypower: nice
<lazypower> bbcmicrocomputer have you taken a look at charming 2.0 these days?
<lazypower> using layers + reactive pattern to write skinny charms leveraging existing work to not only assemble your charm logic, but to plug into other services using interfaces written by others?
<bbcmicrocomputer> lazypower: I read the docs/presentations but not played around with it yet
<lazypower> bbcmicrocomputer : i'll have a developer perspective video for next week from stokachu and his contribution of the nodejs layer
<lazypower> informative video to be sure, if you'r eon the mailing list - it will be syndicated there
<bbcmicrocomputer> nice
<bbcmicrocomputer> I'll look out for it
<bbcmicrocomputer> lazypower: I think I'm a little confused, as Juju docs seem to say you should never code 'juju deploy local:mycharm', only 'juju deploy mycharm' - test runner will determine where to fetch the real charm (presumably from some environment variable or switch), but then amulet seems to have lots of logic for accepting different charm urls
<bbcmicrocomputer> so my main question is where does the logic live for selecting whether we're testing local disk charms on this test or we're pulling from the charm store because the charm store CI is running?
<bbcmicrocomputer> is it something the charm author is meant to bake into their tests, is it something only the test runner should know about?
<lazypower> bbcmicrocomputer: nah. just write tests for 'mycharm'
<lazypower> the fact you export JUJU_REPOSITORY will satisfy it finding th elocal charm. if you implicitly need to test the CS version of a charm, say an extant dependency. 1 of 2 this has occurred
<lazypower> 1) you should be placing your tests in a bundle
<lazypower> 2) You add that in your test d.deploy('cs:trusty/mysql')   which will always pull the latest mysql charm, and add it to your testing bundle.
<lazypower> but if you're doing that level of testing in amulet, say its a requirement, you really should have a bundle to deploy the suite of charms, and embed the tests there. then in which case, JUJU_REPOSITORY again to the rescue
<bbcmicrocomputer> lazypower: cool, thanks for the clarification
<lazypower> NP, there are edge cases in there i'm sure
<lazypower> and if you run into them feel free to ping bbcmicrocomputer
<bbcmicrocomputer> thanks
<bbcmicrocomputer> lazypower: sorry, being a pita..
<bbcmicrocomputer> lazypower: a grep over bundletester and amulet for 'JUJU_REPOSITORY' doesn't seem to reveal any special logic that takes place unless I specify 'local:mycharm' as opposed to 'mycharm'
<bbcmicrocomputer> it's possible I've misunderstood everything at this stage
<bbcmicrocomputer> I guess this also raises another Q that if I have new charms, where each's tests deploy the others to relate, how does that go into the Charm Store in stages without charm urls being incomplete?
<bbcmicrocomputer> for charm A to pass its tests (and be reviewed successfully), how does the test runner know to pull charm B (yet in the Charm Store) from my local LP account (without me explicitly saying - which I shouldn't :) )
<bbcmicrocomputer> like I say, I may possibly have completely misunderstood something key
#juju 2015-10-28
<thumper> stub: hey there
<stub> thumper: yo
<thumper> stub: had an issue with the postgresql charm the other day
<thumper> I have an old one in use cs:trusty/postgresql-10
<stub> You using the rewrite or the cs: one?
<stub> k
<thumper> and I tried to upgrade to -28
<thumper> only one unit
<thumper> but it said "can't as it would break replication relation"
<thumper> seems to have a peer relation with itself
<thumper> or something
<thumper> how do I upgrade it?
<stub> I do not recall such an error message :-/
<thumper> --force only mentions units in error state
<thumper> that error message probably came from juju itself
<thumper> I think the charm upgrade expects endpoints to be the same ...
<thumper> FSVO the same
<stub> oh... that is a juju error message? Right. So probably because some relations got renamed and I didn't realize it would be a problem?
<thumper> yeah...
<thumper> that makes sense
<thumper> what does the replication relation do if there is only one unit?
<thumper> anything?
<stub> or the name of the interface changed
<stub> nothing
 * thumper guesses interface changed name
<thumper> hmm...
<thumper> I wonder what the nice way is to say "just upgrade, ..."
<thumper> I should try it locally first I guess :)
<stub> So lp:~stub/charms/trusty/postgresql/rewrite is what I recommend and actually has a test to upgrade from r127 (no idea of the cs: revno). But you are earlier than that.
<stub> thumper: Is this modern juju, or haven't you updated that bit?
<thumper> I deployed this last year around July
<thumper> and that charm hasn't been upgraded since:)
<stub> thumper: upgrade-charm --force will push the new charm everywhere without running hooks.
<thumper> really? --force won't run hooks?
<thumper> that seems fcuked
<stub> I'd test upgrading to 1.24 then upgrading to the rewrite branch (again, recommended but not landed for review/beurocratic reasons)
<stub> thumper: It is the only way to fix a charm that errored in its upgrade-charm hook.
<thumper> I have my env running 1.24.5
<thumper> right, but it hasn't errored
<thumper> it just said "won't upgrade"
<thumper> still on -10
<thumper> marcoceppi: I see you are around
<stub> Yeah, but that is why we love upgrade-charm --force.
<thumper> marcoceppi: quick charm upgrade question
<marcoceppi> thumper: yes, I am in your timezone
<thumper> I have cs:trusty/postgresql-10 and I want to upgrade to cs:trusty/postgresql-28
<thumper> but an interface got renamed (or something)
<thumper> and juju says "nah"
<thumper> what will --force do?
<marcoceppi> thumper: so force will, at the next idle point in the agent, unpack the charm files without queuing an upgrade-charm hook
<marcoceppi> thumper: not sure if thta fixes your missing interface/relation problem or not, but it's how I develop
<thumper> so I should manually run the hooks?
<thumper> this seems flakey to me...
<thumper> marcoceppi: also, stub has upgrade tests from r127 of the charm, any idea how we can work out what charm version that is?
<stub> thumper: Not so much flaky, but a necessary back door to get you out of this snafu. The real problem is way back then I changed a name and nobody at that time realized it was a problem.
<marcoceppi> thumper: like right now, I've got a broken hook. So I patch the charm layer, charm build, then upgrade-charm --force, exit 1 in the debug hooks so I can keep that hook, then do a juju resolved --retry on the unit to recaputre that hook
<marcoceppi> thumper: no, you should avoid using --force
<marcoceppi> thumper: the way to fix this is to break the relation, upgrade-charm, attach the new relation
<marcoceppi> whoa, I'm really lagged
<stub> thumper: just doing a 'juju set' on it after the upgrade-charm --force will kick off a hook, and one hook is all that is needed with the rewrite charm. Not sure about cs:28.
<thumper> marcoceppi: the relation is a peer relation
<marcoceppi> thumper: oh bother
<stub> marcoceppi: a single unit with a peer relation to boot ;)
<marcoceppi> thumper: well then you're fun
 * thumper taps...
<marcoceppi> thumper: well --force upgrade will get you the new payload
<marcoceppi> thumper: not sure if it'll queue the upgrade-charm hook or not tbh
<thumper> stub: why is your new rewrite not promulgated (or however you spell that damn word)
<marcoceppi> i just know it'll drop the new charm payload
 * thumper goes to look at the code...
<marcoceppi> syn
<stub> thumper: its in the review queue. It got looked at about a month ago, when it was pointed out some tests were failing on the ci system. I got that down to one failing test, which is still better than the existing charm with its tests disabled.
<thumper> so... disable the failing test like a real developer :-)
<thumper> heh
<stub> I've been poking at it to get it fixed, but the ci system gets rather constipated recently and there is still a good chance of failures due to cloud timeouts and such.
<stub> Ohh... someone gave it an enema. I got a fresh run coming up in an hour or three.
<stub> lxc green already, just need to wait for the real clouds
<stub> thumper: where is my lxd provider?
<thumper> stub: coming
<stub> thumper: will an environment be able to span multiple lxd servers?
<thumper> not initially
<stub> thumper: will that be a juju task, or an lxd task do you know?
<stub> My evil plan needs juju talking to multiple lxds, or a virtual lxd server that abstracts a collection of lxds.
<stub> (maybe the latter is better, providing a ha end point to a cluster of lxds and automatic failover of containers etc.)
<thumper> the aim is to be able to have the lxd provider be able to point to a remote lxd endpoint
<thumper> as well as the default of "localhost"
<stub> I guess the manual provider is quite happy deploying a unit to an lxd container somewhere, so it wouldn't be a blocker to anyone. Just trickier to wire up.
<stub> marcoceppi: would stopping people making incompatible metadata.yaml changes be a job for charm proof or the charm store? It would need to be able to discover the previous revision of the charm.
<marcoceppi> stub: so, juju does this already with relations
<marcoceppi> it just makes you remove relation
<marcoceppi> but I don't think anyone considered the peer corner case
<stub> oh, so this is just an edge case with the peer relation
<stub> right
<marcoceppi> juju should just allow you to upgrade regardless of the peer interface change
<marcoceppi> a bug would be in order
<stub> Maybe for juju 2.0 peer relations are considered more special. Currently I think you can have multiple peer relations with all sorts of names and interfaces defined, which isn't really useful afaict.
<stub> thumper: are you filing a bug?
<thumper> sorry, wasn't following, on a call
<thumper> I can file a bug
<thumper> stub: bug 1510787
<mup> Bug #1510787: juju upgrade-charm errors when it shouldn't <juju-core:Triaged> <https://launchpad.net/bugs/1510787>
<stub> So I now need to have two branches for my charm, one containing my work and layers.yaml and another one containing the built charm?
<stub> My first attempt was 'charm build -o .' to keep everything together in an easy to develop with place, but that just builds to ./trusty/charmname
<stub> If two branches, do we have a official location for the 'source' branch, which is the target branch for reviews, with the current trunk remaining for the generated output to be ingested into the charmstore?
<Icey> stub what I've been working on is having them be 2 separate repos, one with the layers.yaml and such, one that is the deployable charm
<stub> Icey: Yeah, that seems to be the way it needs to work. And I see I can specify a LAYER_PATH environment variable, so I can split out things into multiple layers when developing.
<stub> The review process is going to be more interesting
<Icey> yeah, almost like the layers repo isn't going to be reviewed, just the final output?
<stub> One of the reasons composer exists is to avoid all the boilerplate that ends up in reviews from things like charmhelpers. I think the layers will need to be reviewed, not the final output.
<Icey> hopefully :)
<Icey> ideally we get to the point where each layer is independently reviewed, and we can just review the stuff that the charm author is writing
<stub> tarmac or something should be able to to the build, commit and push automatically for the CI system to ingest.
<gennadiy> hi i still have question about expose services in bundle. i use expose: true in my bundle but after deploring services are not exported
<cory_fu> gennadiy: And the services in question have open ports listed in `juju status`?  The `expose: true` should work, if that's the case.  :/
<cory_fu> Are you deploying the bundle with `juju quickstart` or `juju deployer`?
<gennadiy> i deployed bundle from juju-gui
<cory_fu> Oh yes, that, too.  And the services have open ports listed?
<gennadiy> but i think i have found problem i use bundles.yaml but in juju store i see bundle.yaml which doesn't contain expose
<gennadiy> my bundle name is - tads2015-demo
<rick_h__> urulama_: ^ does the expose stuff not get translated perhaps?
<urulama_> rick_h__, gennadiy: it might be a bug, yes. we'll investigate.
<gennadiy> constraints field is absent too
<gennadiy> sorry. constraints presents in result bundle
<gennadiy> do i have possibility to create bundle.yaml directly now?
<gennadiy> as i understood my original bundles.yaml was converted to bundle.yaml. am i right?
<urulama_> gennadiy: yes, you can. use the same format as you see the results.
<rick_h__> gennadiy: yes, though be careful. The old system looks for a bundles.yaml so you need both to ingest properly
<gennadiy> can i add expose field?
<gennadiy> * can i use expose field in bundle.yaml?
<rick_h__> gennadiy: yes definitely
<urulama_> gennadiy: you should.
<gennadiy> ok. i will try
<rick_h__> gennadiy: download the bundle and leave both files when you update it.
<gennadiy> can i setup name of bundle in bundle.yaml?
<gennadiy> because when i try to use bundle and config w/o name config is not applied
<gennadiy> i use the following script
<gennadiy> juju-deployer -e $JUJU_CUR_ENV -c tads2015-demo/bundle.yaml -c config-demo.yaml tads2015-demo/bundle.yaml
<urulama_> gennadiy: unfortunately, we currently don't handle expose.
<urulama_> (in new bundle format)
<gennadiy> now i use bundle instead of bundles and expose works
<gennadiy> but now i have question about juju-deployer it has ability to merge yaml files.
<gennadiy> so if i don't use bundle name for inside bundle file it doens't work correctly
<frankban> gennadiy: in new bundle format there is no top level namespace with the bundle name
<gennadiy> i see, but how to use juju-deployer now?
<gennadiy> seem it doesn't work correctly w/o bundle name
<frankban> gennadiy: how to use a config yaml file?
<gennadiy> am i right?
<frankban> gennadiy: don't know, checking sources, could be a juju-deployer bug
<frankban> gennadiy: what's the problem with new bundle format? overriding values with multiple yaml files? if so, have you tried passing yaml overrides not including the top level bundle name?
<rick_h__> gennadiy: what version of the deployer. You need a fairly recent one to support the newer format where the bundle name is not at the root of the file.
<Icey> is there a way to specify machine arguments when deploying?
<Icey> in essence, I want to use `juju deploy ceph` but specify a machine add constraint to restrict the service to us-east-1a
<Icey> or am I just going to have to use a bundle to get that kind of effect?
<vila> mgz_: ping
<Icey> is 1.25 out yet :'(
<mgz_> vila: hey
<vila> mgz_: hey ! See PM ?
<lazypower> Icey its in -proposed
<lazypower> Icey add-apt-repository ppa:juju/proposed
<lazypower> install juju-core and profit from having 1.25
<lazypower> you get payload management, update-status hooks, and a whole slew of other nice things
<lazypower> but its /proposed, ymmv :)
<mgz_> vila: with 1.24.7 you may benefit from bug 1435283 fix
<mup> Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment <addressability> <bug-squad> <network> <openstack-provider>
<mup> <juju-core:Fix Released by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Released by mfoord> <https://launchpad.net/bugs/1435283>
<vila> ack
<Icey> lazypower I'm riding proposed now ;-)
<aisrael_> lazypower: Layers question for you. I renamed my composer.yaml to layers.yaml by mistake, and charm build complained so I renamed it to layer.yaml. I'm getting this error trying to build now, though: http://pastebin.ubuntu.com/12991002/
<aisrael_> lazypower: I suspect something's cached, but not sure where. deps/ looks like it just has the interface I pulled in.
<lazypower> ouch
<lazypower> that stack trace not really clear with what it duped on
<lazypower> but i think i know whatshappening here
<aisrael_> lazypower: I can dig deeper if needed.
<lazypower> if you ls $JUJU_REPOSITORY/trusty/mything
<lazypower> does mything have a compose.yaml?
<lazypower> if so, charm build is notifying you that files exist out of band, and you should only continue building if its OK to have this file present. (Eg: local modifications to the charm not the layer)
<aisrael_> oh, it has a layers.yaml
<lazypower> --force will allow you to override that and get past it, but its erring on the side of caution for you
<lazypower> i'm referring to the constructed charm
<lazypower> the artifact
<aisrael_> lazypower: removing that fixed it. Should I open a bug?
 * lazypower is doing a terrible job of explaining htis
<lazypower> nah its intended behavior
<lazypower> if you run with -l DEBUG
<lazypower> it tells you what its matching on i think
<aisrael_> lazypower: Right, the previous build left the layers.yaml in $JUJU_REPOSITORY/trusty/mycharm. Bad artifact.
<lazypower> :)
<aisrael_> lazypower: so a build copies over the charm, rather than replacing or rsyncing, right?
<lazypower> the one thing build doesn't do, is take care of removal
<lazypower> say you remove an interface from layer.yaml, then re-run build - you need to implicitly rm -rf the built charm and then build, otherwise that interface will linger
<lazypower> aisrael_ correct, there are different strategies at play
<aisrael_> lazypower: ack. I can see an argument for doing that cleanup automatically, even if it's an extra flag
<lazypower> like config.yaml, metadata.yaml get merged
<lazypower> other files have a default policy of highest layer that has this file wins.
<aisrael_> i.e, if I'm writing a charm in layers/, I'd expect that to be authoritative
<lazypower> so whatever your top layer is, will override files below it, save for a handfull of special files. and your local layer takes precedence over the interfaces.juju.solutions api yes but only if you have LAYER_PATH set
<lazypower> same with INTERFACE_PATH
<aisrael_> like the charm equivalent to make clean
<lazypower> yeah
<aisrael_> Caffeinated ramblings. Thanks for the help unblocking me!
<lazypower> seems like charm build --clean should just nuke the compiled dir if exists then build.
<lazypower> NP thanks for the questions :)
<Icey> how hard would it be to change the AMIs used by Juju to be something that's EBS optimized?
<aisrael_> lazypower: I am now a layer convert (not that I wasn't a fan before).
<lazypower> :)
<aisrael_> well, layer + reactive
<lazypower> Layer + reactive is a powerful tool
<lazypower> aisrael_ : https://github.com/mbruzek/layer-k8s/pull/5
<aisrael_> Niiiiice
<lazypower> working on a feature branch with matt for the last 2 days, working independently there have been zero merge conflicts - putting complexity in its place :)
<lazypower> and the change sets are getting smaller
<aisrael_> lazypower: lxc now builds for os x, so if we can run lxd in a container... we might be closer to having a working local provider.
<lazypower> nice!
<aisrael_> I'll poke around at it tonight when I'm back home.
<marcoceppi> lazypower: +1 to a --clean flag where it removes the previous build
<marcoceppi> helpful when heavily devving
<lazypower> I'll feature rq it
<lazypower> https://github.com/juju/charm-tools/issues/33
<cholcombe> can you combine all your juju actions code into one file and symlink it just like the hooks?
<marcoceppi> cholcombe: yes
<cholcombe> marcoceppi, nice :)
<cholcombe> so i do the usual @hooks.hook business
<marcoceppi> cholcombe: welllll
<marcoceppi> cholcombe: no one has tried that, they're not hooks, they're actions, so it's hard to say if that code will respect that
<marcoceppi> cholcombe: for now it's probably better to just make a python module and then stub the import/execute of that module/methods in each file
<cholcombe> marcoceppi, if i remember right at the code i looked at it just calls the hook with the matching filename that it was called with
<marcoceppi> cholcombe: sure, but actions are not in the hooks directory
<cholcombe> oh i know
<marcoceppi> so if there's any attempt to parse out hook related file paths
<marcoceppi> it'll fail
<cholcombe> hmm yeah
 * cholcombe goes back to splitting them up 
#juju 2015-10-29
<vila> mgz_: ping
<vila_> mgz_: ping
<sharan> Hi
<sharan> If i have deployed for example abc/0,abc/1,abc/2,abc/3 and abc/4
<sharan> in relation-changed hook is it possible for me to get abc/4  unit directly instead of using relation-list
<vila_> mgz_: ping :-}
<sharan> Hi i have abc/0,abc/1,abc/2,abc/3 and abc/4 units, Is it possible for me to get the highest number unit in this case like abc/4 in relation-changed hook directly without using relation-list
<sharan> Hi i have abc/0,abc/1,abc/2,abc/3 and abc/4 units, Is it possible for me to get the highest number unit in this case like abc/4 in relation-changed hook directly without using relation-list
<vila_> mgz_: Ping
<cory_fu> jose: Hey, you have ethercalc locked on the RQ.  Are you currently looking at that, or should I take a look?
<aatchison> Hello. I am having difficulties while bootstrapping JuJu. After node aquisition and deployment on our MaaS cluster, I get this error: Attempt 1 to download tools from https://streams.canonical.com/juju/tools/releases/juju-1.24.7-trusty-amd64.tgz...
<aatchison> curl: (7) Failed to connect to streams.canonical.com port 443: Connection timed out
<aatchison> tools from https://streams.canonical.com/juju/tools/releases/juju-1.24.7-trusty-amd64.tgz downloaded: HTTP 000; time 126.855s; size 0 bytes; speed 0.000 bytes/s Download failed..... wait 15s
<aatchison> I can curl to that address and get the file, any ideas?
<aatchison> I am using ppa:juju/stable and ppa:maas/stable on 14.04.
<aatchison> Sorry, I timed out. I donât know if anyone responded or not :/
<pmatulis> nope
<alexisb> aatchison, if you are still around, could this potentially be your issue: http://askubuntu.com/questions/465508/juju-bootstrap-debug-failed-to-connect-https-streams-canonical-com
<aatchison> ahh, thank you
<aatchison> checking that out
<moqq> anyone have any idea what i should do if one of the jujud agents out of nowhere refuses to start up with this error: âpanic: runtime error: invalid memory address or nil pointer dereferenceâ
<moqq> full logs: http://paste.ubuntu.com/13002509/
<moqq> was thinking it might be related to https://bugs.launchpad.net/juju-core/+bug/1496188 but iâm not really sure
<mup> Bug #1496188: panic in juju worker <panic> <juju-core:Triaged> <https://launchpad.net/bugs/1496188>
<moqq> if i have an agent with message âmessage: agent is not communicating with the server"
<moqq> i just want to delete that unit
<moqq> but remove-unit does nothing
<moqq> (WHY?!?!)
#juju 2015-10-30
<gennadiy> hi all, i have question about removing aws security groups: seems juju doesn't remove security group when machine is removed. am i right? and today i have got exception: security groups number limit is reached
<gennadiy> do we need to remove security group manually? do you have some specific config field to reuse security groups?
<lazypower> gennadiy Juju does have a habit of leaving security groups behind. I use a python script to reset my SEC Groups - https://gist.github.com/chuckbutler/d8a62945ca35b77a8d96
<lazypower> gennadiy - however this wipes all sec groups ^
<lazypower> so use with caution
<ionutbalutoiu> @thedac - Updated both MP that you reviewed earlier. (https://code.launchpad.net/~ionutbalutoiu/charms/trusty/swift-proxy/next/+merge/276218 and https://code.launchpad.net/~ionutbalutoiu/charms/trusty/glance/next/+merge/276285).
<thedac> ionutbalutoiu: great. I'll take a look shortly
<ionutbalutoiu> @thedac: cool, thanks
<thedac> ionutbalutoiu: fyi, we'll have to wait for the automatic testing. Which means I'll be looking at this Monday.
<ionutbalutoiu> @thedac: Of course. Thanks and have a great week-end.
<thedac> You too
#juju 2015-10-31
<supastuff> hi everyone, I'm trying to setup openstack using juju for the first time, but unfortunately juju bootstrap of nodes is failing, with apparently a dns/resolve problem, can anyone give me some pointers on what it may be?
<Fuzai1> Is there a way to tell juju which security group in aws to create a service with?
#juju 2016-10-31
<BlackDex> cholcombe: Sorry for my late reply. The launchpad id is "fairbanks". Thx :)
<kjackal> Good morinig Juju world!
<kjackal> magicaltrout: Saiku is referenced here: https://dzone.com/articles/olap-for-big-data :) Nice!
<magicaltrout> ooh
<magicaltrout> thanks for the spot kjackal
<kjackal> magicaltrout: Got the link from the hadoop weekly mailing list
<vmorris> i keep ending up with odd ssh fingerprint changed messages when trying to "juju ssh unit/#" -- odd because the message indicates that the offending key is in some file in /tmp that doesn't actually exist. Any advice?
<lazyPower> rick_h___ - MRW  https://media.giphy.com/media/mQG644PY8O7rG/giphy.gif  http://paste.ubuntu.com/23408187/
<rick_h___> lazyPower: huh?
<lazyPower> rick_h___ - native osx bin working
<rick_h___> lazyPower nice
<lazyPower> sorry its late and you're in bucharest
<lazyPower> <3
<rick_h___> All good
<lazyPower> preciate all you people and what you do to make that happen
 * rick_h___ likes happy stuff
#juju 2016-11-01
<kjackal> Good morning Juju world!
<kjackal> Does anyone know if there is  a REST api for Juju?
<deanman> Hi, is there a way to use `juju scp` to retrieve something from an LXD container and from a path where elevated access is required? I get `Permission denied` errors
<jhobbs> deanman: my usual approach is a juju ssh sudo cp and then a juju scp
<jhobbs> or juju sudo chown or chmod, depending on circumstances
<jhobbs> *juju ssh sudo chown
<deanman> jhobbs: Ok thanks I'll try that
<deanman> jhobbs: So first you ssh to that machine, you change owner of the file that you want to copy and then exit and run again juju scp, right?
<lutostag> I can't seem to get juju plugins working... juju help plugins just says "ERROR unknown command or topic for plugins"
<lutostag> (I'm not on the juju snap version)
<jhobbs> deanman: i use juju ssh to run the sudo command
<jhobbs> deanman: or juju run maybe it is :)
<jhobbs> deanman: so i'm never at a shell, i just use juju to issues the sudo commands to get permissions right before using juju to scp
<deanman> jhobbs: ok and i was wondering why juju help ssh doesn't show that you could run command ;-)
 * D4RKS1D3 hi to everyone :)
<aisrael> o/
<skay_> hi all, I'm using python-logstash and logstash-formatter and would like to send logs directly vs. going through a file. I've only found logstash-forwarder and filebeat charms. Is the only opion for now to write to a file?
<skay_> I'm using python-logstash like so, https://github.com/vklochan/python-logstash#using-with-django
<bryan_att> hi all, help on an issue is appreciated. This was reported by narindergupta for OPNFV - "pkg_resources.DistributionNotFound: The 'pip>=7.1.2' distribution was not found and is required by charm-tools" and is affecting all our deployments for OPNFV. Any ETA on a fix ?
<bryan_att> The deploy log is at https://build.opnfv.org/ci/view/joid/job/joid-deploy-baremetal-daily-colorado/502/console and I can also provide similar console logs from my deploys.
<aisrael> bryan_att: does the machine have external network access?
<bryan_att> aisrael: yes
<bryan_att> aisrael: is that a symptom (no net access)? In our cases we have stable net access.
<aisrael> bryan_att: It can be, but I'm not sure that's the case. Reading through your logs now
<aisrael> bryan_att: Can you verify if python-pip is installed on that machine?
<bryan_att> https://www.irccloud.com/pastebin/rLUuHLuR/
<aisrael> Oh wow, that's an old version.
<aisrael> What's the OS/version of the machine?
<bryan_att> Ubuntu 14.04
<aisrael> That should be fine. Are all the packages up to date?
<bryan_att> I just installed and updated it a week or so ago.
<bryan_att> in the case of the OPNFV jumphosts I'm pretty sure they keep them up to date. But I can do a apt-get update / upgrade as a test if needed
<bryan_att> also pip install --upgrade pip if needed
<bryan_att> should I do that?
<aisrael> The later should fix it. It looks like the pip packaged in 14.04 is much older.
<aisrael> ^^ tvansteenburgh cory_fu
<bryan_att> later meaning the pip upgrade command?
<aisrael> bryan_att: Yep
<bryan_att> OK let me try that and I'll let you know how it goes
<deanman> Where is the proper place to file a potential bug for juju, under github.com or somewhere else?
<aisrael> bryan_att: One other question: have you added the juju/stable ppa on this machine?
<aisrael> deanman: https://bugs.launchpad.net/juju-core
<bryan_att> aisrael: I believe it's added by the OPNFV JOID installer (MAAS/JuJu) but I can check with narindergupta. How do I check via the shell if it's added?
<narindergupta> aisrael, yes we have stable version of juju and we have CI for deployment. And it started breaking today. Till yesterday it was working, so may be charm-ttols got updated yesterday and does not work with old version of pip
<tvansteenburgh> marcoceppi: ^
<aisrael> narindergupta: That does look to be the case. Apologies for the trouble! We're looking into it now.
<marcoceppi> narinder`: I'm patching now
<marcoceppi> narinder`: sorry about that
<bryan_att> aisrael: I did a pip install --upgrade pip after apt-get update/upgrade and it looks like it's getting farther now, but I have no idea why... the pip upgrade ended with the same version installed (1.5.4) and the message "Not uninstalling pip at /usr/lib/python2.7/dist-packages, owned by OS" ???
<aisrael> bryan_att: It turns out there is an issue with the latest release of charm-tools. It's being patched right now.
<bryan_att> aisrael: thanks, appreciated!
<jcastro> hey bdx
<jcastro> how's this working? https://github.com/jamesbeedy/charm-datadog-agent
<bdx> @jcastro it works great
<bdx> jcastro: I need to build out the integrations functionality ... its a bit daunting though, as there are quite a few of them
<bdx> jcastro: https://github.com/jamesbeedy/charm-datadog-agent  currently only installs the agent
<junaidali> Hi everyone, what will 'network-get --primary-address <binding>' return if we haven't deployed the charm with bind options.
<junaidali> is private-address is the expected output?
<bdx> jcastro: I reverse engineered the curl -> sudo bash deal they have going on for their suggested install -> https://s18.postimg.org/t9pp3j6xl/Screen_Shot_2016_11_01_at_9_57_19_AM.png
<bdx> jcastro: the layer does better ::
<bdx> :-)
<bdx> team: I have a few general questions regarding juju <-> jenkins setup and integration. I'm currently building out the CI pipeline for our juju deployed apps, and was hoping to get some insight on how this might work at a high level
<bdx> jcastro: possible topic for the summit ^
<bdx> juju <-> jenkins integration track
<jcastro> bdx: yeah marco's been working on a datadog one too, I just got off the phone with him, he's going to sync up with you
<bdx> jcastro: cool cool
<bdx> jcastro: is there a platform I should use to make a formal track topic request, or just tell you?
<jcastro> you need to cfp as part of config management camp
<jcastro> and make sure the box is checked for "juju"
<jcastro> https://lists.ubuntu.com/archives/juju/2016-October/008087.html
<bdx> thx
<marcoceppi> bdx: yo, sorry about that
<marcoceppi> I use the layer for thesilphroad, but haven't gotten around to finishing is
<bdx> marcoceppi: huh, wha?
<bdx> marcoceppi: https://thesilphroad.com/ ?
<bdx> https://thesilphroad.com/ is juju deployed?
<bdx> and you use datadog to monitor it?
<bdx> and you also have a datadog layer
<bdx> which you use on that deploy?
<marcoceppi> bdx: were you not at the charmer summit :)
<marcoceppi> bdx: https://p.datadoghq.com/sb/a42d80f38-e1f5b6fc5e?tv_mode=true
<marcoceppi> http://blog.silph.io/
<bdx> wtf .... SICK
<bdx> lol
<bdx> oh man
<jrwren> its my favorite small-software juju story ever. marcoceppi tells a great story.
<bdx> how did I miss this?
<marcoceppi> bdx: it was a lightning talk
<pragsmike> You weren't at the charmers summit.
<marcoceppi> bdx: lets chat later this afternoon, I'd like to coordinate, because I can use your help and datadog is interested in giving us a repository up stream
<bdx> marcoceppi: I plan on making good use of datadog ... I'd like to get some primary integrations dialed in before I even start deploying it at all
<bdx> marcoceppi: sounds good
<pragsmike> hey can anyone point me to docs about how juju decides which IP addresses to use in MAAS?
<marcoceppi> bdx: yeah, i got some feedback from ilian about how we can make this stupid simple in the charm
<bdx> marcoceppi: the integrations?
<marcoceppi> pragsmike: it's kind of a crap shoot, atm, juju 2.1 and 2.2 will make that WAY nicer
<marcoceppi> bdx: totally, instead of writing glue code for every intergration
<marcoceppi> bdx: we just write one method that does all glue code
<marcoceppi> pragsmike: how's it going, btw??
<bdx> totally
<pragsmike> well, more is working than before :)
<bdx> marcoceppi: I unraveled the curl sudo bashing of their install process to be more pragmatic in the layer
<bdx> I assume you probably did something similar
<pragsmike> using juju 2.0 and maas 2.1, the networking story is much nicer
<marcoceppi> pragsmike: yeah, juju 2.1 (and 2.2) will totally catch up
<marcoceppi> bdx: yeah, that ball of crap was unacceptable :)
<bdx> right, I love finding those actually
<marcoceppi> bdx: I just used the apt layer: https://github.com/silph-io/layer-datadog/blob/master/reactive/datadog.py and https://github.com/silph-io/layer-datadog/blob/master/config.yaml
<pragsmike> currently trying to understand how storage is supposed to work
<bdx> marcoceppi: https://github.com/jamesbeedy/charm-datadog-agent/blob/master/reactive/datadog_agent.py
<marcoceppi> bdx: haha, great minds :)
<marcoceppi> pragsmike: with juju + maas?
<pragsmike> marcoceppi: yes
<marcoceppi> pragsmike: for ceph, or another charm?
<pragsmike> ceph in particular
<pragsmike> right now i just list the device names and hope
<marcoceppi> pragsmike: yeah, so there's a config option for device names
<marcoceppi> pragsmike: on clouds, with juju, you can run `juju add-storage`, I don't think that quite works in MAAS yet though
<pragsmike> I currently set ceph-osd's osd-devices to list the names it should try, it works for now
<marcoceppi> pragsmike: yeah, but that's a bit flaky
<marcoceppi> it's a work around
<pragsmike> but that's good to know that storage isn't all there yet
<jcastro> rick_h___: balloons: can confirm 2.0.1 worked awesome this morning for me in us-east-2
<marcoceppi> in the future, you will do like `juju add-storage` for ceph-osd/0, for example, and MAAS will tell that machine, if it has an additional disk, that ceph can consume it now
<marcoceppi> pragsmike: I'd expect seeing that pop up in the next few months
<pragsmike> nice
<marcoceppi> pragsmike: it might be good to mail the juju mailing list, for more specifics of `juju add-storage` on maas
<pragsmike> ok
<pragsmike> i just found mbruzek's message about that in fact
<mbruzek> pragsmike: What did I do?
<pragsmike> heh, i was just asking about juju storage with maas provider
<pragsmike> hoping to use it for the ceph charm
<pragsmike> i found https://lists.ubuntu.com/archives/juju/2016-October/008046.html
<mbruzek> Good find.
<balloons> jcastro, :-)
<pragsmike> that'll keep me busy for a bit
<mbruzek> pragsmike: Just checked my email, I got no further information from anyone else on that thread.
<pragsmike> k, thanks for looking
<alexisb> jcastro, thank you
<pragsmike> I have a workaround, but always looking for a better way
<mbruzek> pragsmike: Are you interested in NFS? https://lists.ubuntu.com/archives/maas-devel/2016-October/002312.html
<pragsmike> mbruzek: NFS, not so much
<mbruzek> I understand
<bdx> how do you guys feel about not hardcoding the charmstore api version into bundletester?
<bdx> https://github.com/juju-solutions/bundletester/blob/master/bundletester/fetchers.py#L225
<stokachu> can a resource have dynamically generated filename?
<stokachu> like http://paste.ubuntu.com/23413581/
#juju 2016-11-02
<bdx> lazyPower, mbruzek: just browsing around and found this interesting pertaining to kub + lets encrypt https://github.com/kelseyhightower/kubernetes-letsencrypt-tutorial
<bdx> that guy is a bad ass, check out some of his other work too if you have a minute .... super cool
<bdx> https://github.com/kelseyhightower/vault-controller
<bdx> xenial+reactive+python3 jenkins refactor -> https://github.com/jamesbeedy/juju-charm-jenkins
<bdx> jamespage: ^
<bdx> boom https://jujucharms.com/u/creativedrive/jenkins/4
<jamespage> bdx, oh nice
<jamespage> beisner, ^^
<jamespage> bdx has been busy
<kjackal> Good morning Juju world
<marcoceppi> bdx: I feel like I'm constantly the bearer of bad news
<marcoceppi> bdx: https://github.com/jenkinsci/jenkins-charm
<marcoceppi> bdx: in the future, I think we should start pushing a policy of people announcing what they're working on, we're (me) are terrible at this
<kjackal> magicaltrout: you should setup a ci it is supper easy (took me one evening). You just chekin something and your work is pushed to the store automagically. I have only good words to say!
<magicaltrout> I have CI kjackal just not for charms, I'm lazy :P
<magicaltrout> that said, its not like I code charms for a living, so I suspect our priorities differ ;)
<kjackal> magicaltrout: true!
<magicaltrout> got knocked back by the apache mesos folk when asking about LXC support, silly people, they're missing a trick
<magicaltrout> looks like I'll have to learn C
<kjackal> magicaltrout: I hope someone from juju-qa will step up and say "kjackal you are doing this all wrong! We have this jenkins plugin that will make your life super easy!"
<kjackal> Ahhh C! Best language ever!
<kjackal> magicaltrout: not joking ^
<magicaltrout> I don't believe you
<kjackal> magicaltrout: Everything you do with C is like DIY! Always wear protective gear and never try this at home!
<magicaltrout> lol
<magicaltrout> I tried extending mesos for LXC a few weeks ago, it was very much trial and more error
<magicaltrout> it was funny they asked me what use case they were missing.....
<magicaltrout> why people think application containers are the best way forward I have no clue
<kjackal> developers build these things to protect themselves from thierselves
<magicaltrout> like Go?! ;)
<kjackal> I think the story goes like this: In begining there was C. Then developers got annoyed by junior developers that were clumsy with C and they created Java for the Junior devs to play with. But then Java became too popular and quantity beat quality: It was better to have more Java junior devs that few quality C devs. One C dev said I will reboot C and add some of the features I am missing so we have Go. While most C devs are
<kjackal> boosting C
<kjackal> magicaltrout: ^
<magicaltrout> lol
<magicaltrout> yeah, i suspect you're not too wide of the mark kjackal
<rock> Hi all. we pushed our juju charm to public charm store using launchpad juju account. when we pushed it is giving like  cs:~hareeshk/kaminario-cinder-10 . It was pushing with account username "hareeshk".  Can we push our charm by hiding "username". Please provide me information.
<magicaltrout> rock: to do that you have to get it signed off and "recommended" by some of the charmers
<magicaltrout> so you need to ensure it has tests, tests pass, a decent README etc
<magicaltrout> then it will need to enter the review queue
<rock> magicaltrout: Hi. Oh. For that it requires the certification right.
<magicaltrout> well its not certification, they just check to make sure your charm is sane
<kjackal> rock: https://jujucharms.com/docs/2.0/charm-review-process
<magicaltrout> doesn't seem to explain how to get it in the review queue though kjackal
<rock> Kjackal/magicaltrout :  Thanks.
<marcoceppi> rock kjackal http://review.jujucharms.com
<rock> marcoceppi: Thanks. How much time it will take to review?
<marcoceppi> rock: we're a little behind, but we'll try to take a look quickly
<rock> marcoceppi: OK. Thanks.
<bdx> marcoceppi: yeah ... this is really defeating .... the jenkins you posted doesn't even show up in the charm store ... is in not published for some reason?
<marcoceppi> bdx: it just landed
<marcoceppi> I'm really sorry man
<bdx> jesus
<marcoceppi> we're not going to cock this up again
<marcoceppi> you can expect us announcing the charms and layers we're working on, from the entire company, much earlier
<bdx> entirely
<bdx> possibly we could make an addition to charm build where on every build it would post the charm name and author name/email to and endpoint somewhere
<bdx> or something of that fashion
<bdx> marcoceppi: why not target xenial on that?
<marcoceppi> bdx: we are
<marcoceppi> we will target xenial only for that charm, I'm building and uploading now
<marcoceppi> bdx: I feel soo bad, but I should check now - what other charms/layers you got in the works? I want to make sure we don't curb stomp your dreams
<bdx> marcoceppi: no worries, practice makes perfect
<bdx> marcoceppi: zuul, gitlab, documize, etherpad-lite, mailman3
<bdx> marcoceppi: I've yet to start on zuul
<marcoceppi> bdx: yeah, I'm interested as well in gitlab, and I know Tom Barber has a start of that somewhere
<bdx> marcoceppi: documize, etherpad-lite, mailman3 are done minus tests
<marcoceppi> otherwise, i'm not awayre of any of those in flight
<bdx> ok
<bdx> I only have a start on gitlab too
<jhobbs> beisner: do you'll have anything around zuul?
<bdx> I should the trout about that for sure
<bdx> magicaltrout:^
<bdx> marcoceppi: I have a reactive rewrite of kibana I've been deploying .... but I'm guessing the whole elastic stack should be consuming a base layer of some sort eh?
<beisner> jhobbs, only via integration with upstream gerrit + zuul.  we don't have our own zuul deployed though.
<marcoceppi> bdx: dude, that's awesome! we were jsut about to start moving elasticsearch to 5.0.0 and layered!
<marcoceppi> bdx: where's your kibana?
<bdx> https://github.com/jamesbeedy/layer-kibana
<marcoceppi> \m/
<marcoceppi> lazyPower: ^^
<lazyPower> thats great news \o/
<bdx> here are another few layers I've hacked up recently
<bdx> https://github.com/jamesbeedy/layer-nginx-passenger
<bdx> https://github.com/jamesbeedy/layer-postfix
<bdx> https://github.com/jamesbeedy/layer-git-deploy
<bdx> https://github.com/jamesbeedy/layer-apache2
<bdx> https://github.com/jamesbeedy/layer-phalcon
<bdx> https://github.com/jamesbeedy/layer-consul-base
<lazyPower> bdx - we should seriously, sync and divvy up the work on the elastic stack
<lazyPower> bdx - the goalpost got moved on me, and its not coming as soon as I was hoping. I'm wiling to put in some time if you are to split that work up and deliver the 5.0 elastic stack
<bdx> lazyPower: fully down man .... I've been training up a two man charming team at work ... few hours a day ... its been great all around
<bdx> we would be interested in teaming up on that
<bdx> for sure
<lazyPower> word, calendar sync on thursday then to meet/greet and figure out what we need to do?
<lazyPower> i have some early planning docs that i need to fish up and dust of
<bdx> totally .... I'm in palm springs till sunday and wont be around much, lets shoot for next week sometime
<bdx> monday?
<lazyPower> that sounds even better
<lazyPower> i may need to resched due to having team members at kubecon, i'll be running support for them
<lazyPower> but tentatively that sounds great to me
<bdx> sweet!
<lazyPower> excellent :)
<lazyPower> bdx preferred time?
<bdx> 9am my time
<bdx> so like an hour from now
<bdx> does that work for you?
<bdx> want me to send you a calendar invite?
<lazyPower> bdx  you've got mail
<bdxbdx> Marcoceppi: do you also have a Jenkins-slave going on?
<bdxbdx> marcoceppi: having Jenkins and Jenkins slave on xenial will be huge .... Lxd local provider + juju 2.0 can't really happen
<bdxbdx> On any other series
<bdxbdx> For Jenkins <-> juju ci pipelines I'm thinking it will be crucial to have this
<lazyPower> bdx - there's an open jenkins layer review we could use your eyeballs on
<lazyPower> ooo and to my surprise its already landed
<bdx> lazyPower, marcoceppi: not sure I can accept the invite -> https://s12.postimg.org/8lcvygobx/Screen_Shot_2016_11_02_at_9_10_36_AM.png
<bdx> its on my calendar though
<bdx> nm, git it,  accepted
<lazyPower> solid
<lazyPower> bdx - should we make this a hangout on air and invite the community at large?
<lazyPower> i can also reach out to my contacts at elastic to see if they are interested in participating from a curious onlooker position. They might be able to lend a body for planning and insights.
<bdx> lazyPower: totally
<bdx> lazyPower: my guys over here want to be part of this too
<lazyPower> bdx ok, let me see what i can do when jcastro surfaces. He's got all this down to a science
<lazyPower> thanks for agreeing to help chair this effort :)
<lazyPower> magicaltrout - if you're interested, you're invited toooooo
<jcastro> who needs help?
<magicaltrout> i'm always interested in taking on yet more unpaid work! ;)
<jcastro> lazyPower: hangouts on air went away, the tldr is you'd do it on youtube like how with gaming.youtube
<jcastro> there's a little panel for livestreaming, etc.
<lazyPower> ahhh
<lazyPower> magicaltrout - well i didn't mean it like that, but i appreciate the sentiment :D <3
<magicaltrout> lol
<magicaltrout> whatever :P
<lazyPower> magicaltrout - i was just thinking you likely have a stake in this as its solving little data problems too
<magicaltrout> this is true
<magicaltrout> i've been abusing people at work recently over elastic stuff
<jcastro> man this new kibana looks so sweet though
<lazyPower> i'm
<lazyPower> sayin
<lazyPower> they did a bang up job on the 5.0 release
<jcastro> it's like, I don't even want to use the old one at all anymore
<bdx> jcastroyeah, we all want it
<lazyPower> sorry they kept teasing me with getting to work on that stack :\
<lazyPower> we had other bigger ticket items
<admcleod1> dont forget fast data
<lazyPower> soooo free time it is :D
<lazyPower> admcleod1 - que?
<admcleod1> big, little and fast data
<magicaltrout> fast big data?
<lazyPower> is there a slow data too?
<magicaltrout> absoutely
<lazyPower> what about obtuse data vs acute data? now we just sound classist.
<magicaltrout> have you ever been introduced to Map Reduce?
<admcleod1> irc is pretty slow data
<lazyPower> once
<lazyPower> it was horrible
<magicaltrout> MapR is about as admcleod1 on a good day
<lazyPower> ooooo
<jrwren> databased on filesystems backed by remote block devices over gigabit is slow data.
<admcleod1> he's such a snuggly bunny
<magicaltrout> currently i'm dealing with TB's of data... on NFS
<magicaltrout> now that is slow data
<lazyPower> magicaltrout - did you use glusterfs-nfs or just plain ole nfs?
<magicaltrout> oh, pretty much what jrwren said :)
<magicaltrout> lazyPower: not my call, plain NFS
 * lazyPower nods
<magicaltrout> either way, if you want fast data, don't store it on NFS
 * lazyPower pins that message to the channel
<magicaltrout> well the other day I got someone complaining that copying 100GB of data on an NFS cluster on EC2 took 1 1/2 hours
<jrwren> 4.9 kernel adds supoprt for NFS4.2 COPY... so you can look forward to that speed up ;]
<magicaltrout> this is correct! then doing it on a machine locally took a few seconds
* lazyPower changed the topic of #juju to: Welcome to Juju! || Docs: http://jujucharms.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://review.juju.solutions || Unanswered Questions:  http://goo.gl/dNj8CP || Youtube: https://www.youtube.com/c/jujucharms || Juju 2.0 release notes: https://jujucharms.com/docs/stable/reference-release-notes
<lazyPower> evilnickveitch - did we get 2.0.1 release notes? i thought i saw a merge email fly by on friday but i cant seem to find it
<jrwren> magicaltrout: was it EBS backed? EBS can be very slow sometimes.
<magicaltrout> yeah jrwren
<admcleod1> magicaltrout: have you tried fastnfs?
<magicaltrout> my Sys Admin guy is putting his eggs into the Amazon EFS basket and waiting to migrate to that
<magicaltrout> you making up words again admcleod1 ?
<bdx> he is
<magicaltrout> thanks
<admcleod1> yes, yes i am
<bdx> made me look
<bdx> jerk
<magicaltrout> hehe
<evilnickveitch> lazyPower, not any that made their way to docs - I think it was just an email to the list. i will check into that
<lazyPower> ok thanks, i must have conflated the mail to the list with a doc pr. :) my b
<evilnickveitch> lazyPower, there was a doc PR to update the sources for the new release, but no notes, so your brain isn't that wonky
<lazyPower> evilnickveitch - how much longer before i've earned the 'mad scientist' badge?
<lazyPower> s/before/until/
<evilnickveitch> I think you are halfway there
<lazyPower> \m/,  yesssss
<admcleod> halfway to zeno maybe
<jcastro> stokachu: battlemidget!
<jcastro> have you tried doing conjure-up, juju, and lxd all from snaps?
<stokachu> jcastro: yea it doens't work
<stokachu> not easily anyway
<stokachu> jcastro: https://github.com/conjure-up/conjure-up/tree/master/snapcraft thats our snap build stuff
<stokachu> havent ran it in a bit though
<jcastro> yeah, the one I'm using is also trying to launch observable kubernetes
<deanman> Is docker charms supported with localhost LXD setup? I've tried both the 'observable-swarm' and 'swarm
<lazyPower> deanman - those bundles are old, but in short, that configuration is not supported today
<lazyPower> deanman - there is work being done to make running docker containers in lxd a better story, right now you can even pilot some of that manually with lxd profiles (the lxd docker profile is available in newer lxd packages) but you'll still find a lot of limitations there
<deanman> lazyPower: Can you suggest a working charm to test docker locally using Juju or only safe bet is using some cloud infrastructure?
<lazyPower> deanman - the only way you can achieve a layer-docker based charm working locally today is to use a VM backed substrate like KVM or VirtualBox (both on the manual provider, RIP KVM provider) so a majority of the work on those charm are performed in the cloud on aws/gce/azure
<deanman> lazyPower: Thanks for the hints!
#juju 2016-11-03
<kjackal> Good morning Juju world!
<D4RKS1D3> good morning kjackal :)
<kjackal> The darkside (D4RKS1D3) of #juju said good morning back to me. A hint to take the day of?!
<D4RKS1D3> Probably is a good option! hahaha, can I take the day off too?
 * magicaltrout never gets a day off....
<magicaltrout> oh yeah i'm paid by the hour
<magicaltrout> never mind then
<kjackal> Got a question for you people, how do you ensure that you can reproduce your build out put binaries?
<kjackal> magicaltrout: D4RKS1D3 ^
<magicaltrout> ie, they are always the same?
<kjackal> magicaltrout: you can reproduce the binary you build 10 minutes ago
<kjackal> do you have a fork of the layers you are using?
<magicaltrout> nope... i can't :)
<kjackal> Because if you are building using remote layers, someone might go and change what is in the remote repo...
<magicaltrout> i did think about that a while ago, it would be cool to tag layers
<magicaltrout> there's no reason why you couldn't create a `maven central` of layers
<kjackal> yeap, agreed. We should have a solution to this request
<kjackal> magicaltrout: I am going to ask this in the list, we might get some more tracktion
<SimonKLB> kjackal: if you want to make sure that the layers doesn't change, why not clone them and build your charm using local layers?
<SimonKLB> good thing about having them all under version control is that you can checkout which ever revision you want and build locally
<kjackal> SimonKLB: Yes, this is what I was hinting by saying "forking the layers used and getting them locally before charm build"
<kjackal> SimonKLB:  You need to have a fork of the layers involved, because someone might go and change the commit history
<SimonKLB> ah yea, but thats just bad manners :)
<kjackal> SimonKLB: Aslo, checking out specific versions does not solve your problem, you will also need to take a note of "for charm revision 123 layer-xyz was on commit 1234521AE .... "
<kjackal> SimonKLB: Github is a crazy world, repositories get missing all the time :)
<SimonKLB> you mean if you want to build an older version of your charm?
<kjackal> SimonKLB: Yes, lets say you realise you introduced a bug and you need to do a binary search on the release binaries to find out when was that introduced
<SimonKLB> yea thats more tricky! would actually be nice if the build process would tag up each layer at which revision they were on
<kjackal> Or another example, you want to push an emergency fix (you have a client on the phone) and you realise the charm is currently failing tests. How would you go back to a working version and patch just your own layer. It is just akward.
<kjackal> And I am wondering what the community is doing
<kjackal> SimonKLB: perhapse add a build.explain in the build output so you can later track what got in the build
<kjackal> SimonKLB: We could/should have done this discussion on the list
<SimonKLB> ill let the folks with more indepth knowledge of the build system give a proper response on the list, i just think its an interesting topic to discuss
<SimonKLB> reverting a version in the charmstore isnt problematic though, is it? or are you talking about going back to a working version in your own CI?
<SimonKLB> because i do agree with you that its not easy to roll back your charm to an earlier state by re-building all the layers etc
<kjackal> SimonKLB: From the charmstore you can get the build revision number of the charm. I am not aware of a way to pinpoint the commit hash of each layer used based on the charm's revision number.
<SimonKLB> no thats correct, i just mean you can revert to a working version if you accedentally push a buggy one
<SimonKLB> but rerolling it trying to get back to the different layer versions might be tricky
<SimonKLB> it would be really neat if it created some kind of manifest during the build that stated "layer repo commithash"
<D4RKS1D3> kjackal, how about your the off? xD
<kjackal> In terms of productivity you can consider this day as good as off! :)
<magicaltrout> the norm then
<kjackal> But D4RKS1D3, I have some of hours left so I will make up for the lost time.
<magicaltrout> just been quoted Â£20k for a new bathroom kjackal
<magicaltrout> is that more than a tesla?
<magicaltrout> should i get a new bathroom, or go second hand? ;)
<kjackal> magicaltrout: New bathroom I hear! In LA I assume?
<magicaltrout> lol
<magicaltrout> i wish
<kjackal> London, 20k for a bathroom. Sounds about right!
<magicaltrout> aye
<kjackal> Renting it... of course!
<magicaltrout> rent my bathroom
<aisrael> 884157
<magicaltrout> aisrael: I'm sure this isn't the first time you posted pin numbers into IRC
<magicaltrout> you should watch that bad habit one day someone will steal your money :P
<tvansteenburgh> i think that was his bank account balance actually
<magicaltrout> tvansteenburgh: he's been hanging out with you too much then
<magicaltrout> .. or maybe not enough
<magicaltrout> i'll check with cory_fu
<aisrael> magicaltrout: too true :/
<feral> yo, the django bundle, the one with python-django, postgresql and gunicorn in it doesen't seem to be working. if i access the public ip of the exposed python-django, it spits out <h1>Internal Server Error</h1>. I set the mediawiki site with haproxy and mariadb from the tutorials and that one works... it's all on my localhost. what do yall think?
<feral> is there configuration, prior to exposing to be made? i just heard about juju last night, so i don't really know much
<deanman> feral: What exactly URL are you using? I've noticed from personal experience that some bundles although expose HTTP you have to also append a valid path to work, e.g. http://10.0.3.1/wiki
<feral> deanman: aham, i'm using http://10.215.180.29:8080/ it
<feral> deanman: it's automatically generated by lxd init
<feral> deanman: if i don't put the port at the end of it, it gives me "Unable to connect", classic firefox
<feral> deanman: that's how django works if i set it up locally, it works out of the box with ip:port as url
<deanman> feral: How's your `juju status --color` looking? All green ? :-)
<feral> deanman: nah, at the App/Status column, all: gunicorn, django and postgress are "unknown" and the same at the Unit/Workload, the Unit/Agent-s are "idle" and the Machine/State-s are "started"
<feral> deanman: mostly yellow...
<feral> deanman: it's kinda the same picture at the mediawiki model, but mediawiki still works
<deanman> Can you paste your juju status on paste.ubuntu.com ?
<feral> deanman: yup, here it is: https://paste.ubuntu.com/23420917/
<deanman> feral: You could try `juju debug-log` on a second session and try hit that URL again, maybe something interesting pop-out
<deanman> feral: that status looks ok to me, I'm also new to juju !!
<icey> should the new metrics stuff be backwards compatible with juju 1 or is it a juju 2 only feature?
<mattyw> icey, juju 2 only
<feral> deanman: yeah... it should be fine, i still think it's something wrong with the python-django charm, what do you mean by "on a second session"?
<icey> mattyw: unfortunate
<icey> mattyw: it seems that you can
<icey> 't even deploy a charm that has them setup on 1?
<deanman> feral: A new shell, in case you want to monitor juju logs continuously. At least this is what i usually do...
<feral> deanman: oh, yeah, but "watch" ommits the colors : ))
<lazyPower> feral - watch -c juju status --color
<deanman> feral: no watch on debug-logs
<lazyPower> ^ the magic incantation to keep color under watch
<deanman> lazyPower: Any idea when 2.1.0-beta2 is due? Got a really annoying bug filled which limits me from having a juju workshop inside our company :(
<feral> lazyPower: thanks : )
<lazyPower> deanman - we just release 2.0.1 stable last week
<lazyPower> not sure where you found reference to a 2.1.0-beta2?
<deanman> lazyPower: It was triaged by Anastia (https://bugs.launchpad.net/juju/+bug/1638322)
<mup> Bug #1638322: Able to bootstrap but not deploy any charm behind corporate network with proxy <lxd> <proxy> <juju:Triaged by rharding> <https://launchpad.net/bugs/1638322>
<lazyPower> deanman - ah, ok. I dont have an ETA on that release, sorry
<tvansteenburgh> lazyPower: are you using charmbox with juju2?
<lazyPower> tvansteenburgh yep
<tvansteenburgh> lazyPower: :latest or :devel?
<lazyPower> :devel
<lazyPower> sorry we're late to make the tag rollover :(
<tvansteenburgh> lazyPower: do you have a wrapper script that mounts ~/.local/share/juju or something? i don't see that in charmbox itself
<lazyPower> tvansteenburgh - worse, i have a gnarly alias :)
<tvansteenburgh> haha
<lazyPower> http://paste.ubuntu.com/23421138/
<lazyPower> theres my alias, as i said its gnarly. lots of stuff specific to my shell setup too
<tvansteenburgh> lazyPower: np, turns out i just needed :devel instead of :latest
<lazyPower> awesome :) happy to help
<shruthima> hi kevin, when we are making use of  ibm-im layer(from http://interfaces.juju.solutions/layer/ibm-im/ )as base layer  in the other charms we observed reactive file and resources of ibm-im layer are  not geting updates. Can u please suggest ?
<shruthima> http://paste.ubuntu.com/23421259/
<shruthima> updated*
<kwmonroe> shruthima: could you paste the output from "charm build --no-local-layers -r" in the layer-ibm-http directory?
<kwmonroe> shruthima: i'm guessing you might have a local copy of ibm-im that does not include the resources
<shruthima> kwmonroe: when we use ibm-im layer from locally  resources r getting updated
<shruthima> kwmonroe: output of charm build --no-local-layers -r http://paste.ubuntu.com/23421387/
<kwmonroe> yup shruthima, i just verified that on my machine too.  it looks like the resources and terms metadata keys are not being merged during charm build.  instead, they are being overwritten.
<shruthima> ya , how to resolve this ?
<shruthima> reactive file of im is also not getting merged
<kwmonroe> shruthima: just verified the other thing you said works for me too.. if i charm build *without* --no-local-layers, it works as expected
<shruthima> ya kevin locally it is working fine
<shruthima> any issue with the http://interfaces.juju.solutions/layer/ibm-im/?
<kwmonroe> oooohhh.. i know what's happening shruthima
<kwmonroe> shruthima: do an "ls ~/charms/deps/layer"
<kwmonroe> i bet you see a "trunk" subdirectory there
<shruthima> ya trunk dir is there
<kwmonroe> so, when 'charm build' tries to fetch layers stored in bzr, it does a 'bzr branch lp:~foo/trunk" in the ~/charms/deps/layer directory.  This is bad because it would branch "ibm-im" to the ./trunk directory first, and the it will branch "ibm-base" to the ./trunk directory when it goes to process the base layer.
<kwmonroe> shruthima: i'm 99% sure cory_fu has a fix for this
<kwmonroe> and kjackal, i think you've seen it too (when charm build extracts layer deps to the same 'trunk' directory)
<shruthima> ohh
<kwmonroe> shruthima: original issue was opened by kjackal here:  https://github.com/juju/charm-tools/issues/268
<kwmonroe> shruthima: and the fix was merged by cory_fu here:  https://github.com/juju/charm-tools/pull/269
<shruthima> oh k
<shruthima> kwmonroe: so do we need to change anything in http://interfaces.juju.solutions/layer/ibm-im/?
<kwmonroe> no shruthima: there is nothing to do for your layers.  any charm that includes 2 layers from bzr will be affected.   i just checked the latest charm-tools package (2.1.5), and the fix has not landed there yet.
<kwmonroe> shruthima: for now, the best workaround you can do is the one you've been doing -- build your charms with local layers
<cory_fu> kwmonroe, shruthima: marcoceppi said he will make a release with that fix in today
<kwmonroe> oh cool cory_fu.  thx marcoceppi!
<kwmonroe> shruthima: you may not have to use the local layer workaround for long...
<shruthima> oh great thank you
<shruthima> so we have to update charm tools
<cory_fu> He is going to a meet up now, though, so it will probably be a couple of hours, unfortunately
<shruthima> no worries thanks for the updates
<kwmonroe> yup shruthima, i can send you an email when the updated charm-tools package is available.
<shruthima> ok kwmonroe thanku :)
<kwmonroe> np
<bloodearnest> using the new charm-tools 2.1.5, charm build is broken for me on trusty, complaining about needing pip>=7.1.2
<bloodearnest> did I miss something?
<aisrael> bloodearnest: That's a bug in the new release. Did you just apt-get update and upgrade? I think this was fixed yesterday
<bloodearnest> aisrael, I just did in a different trusty box, problem persists for me.
<aisrael> marcoceppi: ^^
<aisrael> bloodearnest: Hopefully that fix will be uploaded soon.
<bloodearnest> aisrael, thanks
<aisrael> Sorry about that!
<bloodearnest> aisrael, nw, it happens
<petevg> bcsaller, cory_fu: PR for you. It's been rebased from master: https://github.com/juju-solutions/matrix/pull/11
<petevg> bcsaller, cory_fu: the one outstanding issue is that the new changes from master break tests/glitch/test_glitch (complains about waitname being referenced before assignment). Glitch works fine in the other tests, though.
<bcsaller> petevg: thanks, I'll check it out
<MrDanDan> hi, juju set-config changed?
<MrDanDan> it's just config now, got it
#juju 2016-11-04
<kjackal> Good morning Juju world!
<BlackDex> Hello there, is there still an option to force the usage of LXC instead of LXD with juju 2.0?
<marcoceppi> BlackDex: lxd is lxc, you mean lxc 1.0 instead of 2.0?
<BlackDex> yes.. i think i mean that...
<BlackDex> Am i correct that LXD an KVM/QEMU can't run together
<BlackDex> Because of the CPU VT-D usage?
<rockstar> BlackDex: LXD and KVM can absolutely be used together. I'm doing it on my machine right now.
<rockstar> BlackDex: I can't imagine a reason why LXD would be using VT at all. It's not a virtualized environment.
<BlackDex> Ah oke
<BlackDex> So, if i want to deploy openstack using juju 2.0 and run some services on a compute node that can be done withing LXD :)
<marcoceppi> BlackDex: yeah, you should check out: https://github.com/openstack-charmers/openstack-on-lxd
<rockstar> BlackDex: absolutely.
<rockstar> BlackDex: in fact, I do the development of nova-lxd inside a lxd instance, so my devstack compute nodes are straight-up lxdception.
<BlackDex> rockstar: So you have  a Host, which has an LXD container, which has nova-lxd in it?
<rockstar> BlackDex: yes.
<BlackDex> Wow
<BlackDex> nice
<rockstar> And I've also booted KVM instances inside of my nova-lxd container.
<rockstar> BlackDex: it's changed a bit since this, but if you're interested: http://iamtherockstar.com/devstack-in-a-lxd-container.html
<BlackDex> including VT?
<rockstar> BlackDex: yes.
<BlackDex> Oke, nice
<BlackDex> thx for the info! and the website
<rockstar> BlackDex: LXD shares the kernel with the host, so as long as the kernel has support for it, the LXD gets them too.
<BlackDex> oke, that is good to know.
<BlackDex> Do you also know if it is possible to have static ip's for LXD/LXC containers via JuJu/Maas?
<BlackDex> Can't seem to find anything on this. It all seems to do DHCP
<anrah> Hi! I upgraded my OpenStack and during the update I enabled HTTPS on my public APIs
<anrah> now I get error: http://paste.ubuntu.com/23424696/
<anrah> the instance gets created but apparentely the bootstrapped machine needs the ca-file to the machine if it wants to talk to openstack
<anrah> ca-cert-path config option should do the trick, but that is not available on juju 2.0 ?
<marcoceppi> anrah: it might be best to check in #openstack-charms
<rockstar> BlackDex: that'd be a question for #lxcontainers
<BlackDex> rockstar: Thx i will check over there
<caribou> Hi, is there a way to prevent amulet from destroying the environment after tests (juju 1.25) ?
<caribou> for some reason rsync refuses to get my tests logs; I get permission denied
<anrah> marcoceppi: I am not deploying openstack, but rather definining openstack as a cloud which juju should use
<kjackal> caribou: are you using bundletester to run your tests?
<caribou> kjackal: no, just "juju test" from the charm's directory
<kjackal> caribou: could you try the reset: false flag inside the test.yaml?
<kjackal> caribou: I am not sure if that will be honored. Have a loog at the description of the flag here: https://github.com/juju-solutions/bundletester
<caribou> kjackal: test.yaml ? don't have one of those, just the test scripts
<caribou> kjackal: ok, I'll look at it
<caribou> kjackal: thanks!
<cory_fu> kjackal: Can you give me a review on https://github.com/juju-solutions/cloud-weather-report/pull/81
<kjackal> cory_fu: I am on it!
<cory_fu> Thanks!
<kjackal> cory_fu: Looks good! Let me know if you want me to merge it. Should we wait for the 200 amulet return?
<cory_fu> kjackal: Were you able to run it and confirm the HTML fix?
<kjackal> Oh, you need a full use then! Ok, that will take some more time. I just run the unit test. I will ping you again
<kjackal> cory_fu: ^
<cory_fu> Please do.  Thank you
<cory_fu> kjackal: Heading to lunch now.  bbiab
<kjackal> cory_fu: run the testplan (git) exmaple on lxd. No problems in the HTML, looks fine!
<cory_fu> kjackal: great, thanks
<petevg> bcsaller, cory_fu: I just pushed an update to https://github.com/juju-solutions/matrix/pull/11, which fixes the issues that I was seeing in test_glitch. You may need to rebuild your .tox environment, as it incorporates a matching fix to python-libjuju
<BlackDex> can i mix series within a bundle file?
<aisrael> blackboxsw: Yes
<BlackDex> like almost everything is xenial, but some stuff is trusty, and that will be in an lxc?
<BlackDex> the default series can be xenial, and then a charm just trusty/something, and that will work?
<aisrael> blackboxsw: here's an example: http://pastebin.ubuntu.com/23426074/
<aisrael> You can set a per-machine series
<blackboxsw> BlackDex, that was for you ;)
<aisrael> err, yes, sorry!
<BlackDex> :)
<aisrael> silly tab completion
<BlackDex> hehe, but i figured :)
<BlackDex> oke thx, ill go and try that
<jjohnston> Happy Friday, I have a question about juju 2.0 and ipv6 if anyone here can assist?  My question is how to I prevent lxd instances from taking ipv6 addresses during a juju deploy?
<jrwren> jjohnston: using the local lxd provider?
<jjohnston> no, deploying to remote nodes via maas
<jjohnston> maas managed nodes rather
<jjohnston> i don't have any ipv6 networks in maas and the bare-metal hosts take ipv4 addresses as expected, but the lxd instances, including the api endpoint for ceph (in this case) are taking ipv6 addresses
<marcoceppi> jjohnston: thta's really odd, I htink there's a model config to disable ipv6
 * marcoceppi checks
<jjohnston> that would be nice, I'm green with juju, but i've not been able to find such a parameter after extensive googling
<marcoceppi> jjohnston: I don't have a MAAS model available to me atm, but does juju model-config yield anything exciting?
<rock> Hi all. To push our charm to charm public store we created an charm account using https://login.ubuntu.com/xbX4GvuWSuVkirqs/+decide. I pushed charm to store using that account from JUJU CLI. Now  I deleted my charm account permanently. Bur account user name is still there.
<rock> How can I remove that account username
<marcoceppi> rock: which account username?
<rock> marcoceppi: Hi. ubuntu SSO account username.
<marcoceppi> rock: right, what is your username you want to delete? :)
<rock> marcoceppi: "kaminario"
<rock> When I was trying to create another account using same username "kaminario". It was showing username "kaminario" already in use.
<marcoceppi> rock: I will take a look
<rock> marcoceppi: Thank you.
<jjohnston> @marcoceppi the only thing of remote interest that I can see is the ignore-machin-addresses and that's only because I can't even guess what that does
<jjohnston> i don't see anything regarding protocol preferences as previous versions of juju apparently had
<marcoceppi> jjohnston: this might be a better topic for juju@lists.ubuntu.com and juju-dev@lists.ubuntu.com, I don't have a good answer for you
<pragsmike> anyone else having trouble rabbitmq charm rev 56 to run in openstack-base?
<pragsmike> all the openstack charms, mysql, ntp started ok, just rabbitmq says error, hook failed: "config-changed"
<pragsmike> deploying using maas 2.1
<marcoceppi> pragsmike: are you putting rabbit in a lxd machine?
<jjohnston> @marcoceppi: Thanks, I'm going to redploy juju ensuring there are no references to ipv6 prior to the bootstrap
<marcoceppi> jjohnston: cool, if maas isn't configuring ipv6, it really shouldn't get addresses at the contiainer level
<marcoceppi> fwiw, I haven't encountered that yet
<pragsmike> marcoceppi: yes, I'm using the openstack-base bundle (except I tweaked constraints on the machines section)
<pragsmike> marcoceppi: and that bundle does specify that rabbitmq be in lxc
<marcoceppi> pragsmike: right, I wonder if there's a fix out
<pragsmike> is that what the problem is?
<marcoceppi> nope, that's the lastest
<marcoceppi> beisner: have you come across this ^
<marcoceppi> coreycb: ^
<pragsmike> I did change the bundle to use rabbitmq rev 56, where it was 54
<pragsmike> but i did that because it was failing the same way before
<marcoceppi> pragsmike: ah, excellent. I know rabbitmq-server freaks out when things like DNS don't work
<marcoceppi> you're on maas 2.0 or 2.1?
<pragsmike> maas 2.1
<marcoceppi> pragsmike: also, can you pastebin the /var/log/juju/unit-rabbitmq-server*.log file
<pragsmike> marcoceppi: http://pastebin.com/v2XYtbzM
<pragsmike> that just seems to be the rabbitmq client failing to connect to the server, doesn't say why the server didn't start
<pragsmike> also I'm not sure if it's ok that it thinks the host name is "eth3".  maas has decided that address has the name eth3.juju-8566c3-0-lxd-2
<pragsmike> I have a bunch of networks set up per Dimiter's instructions, but I haven't tried to make anything use them yet.  juju just decided to use the 10.100 network for everything, which ought to be ok to start.
<pragsmike> rabbitmq doesn't use ceph, does it?
<kwmonroe> petevg: would you mind taking a look? https://github.com/juju-solutions/layer-apache-bigtop-base/pull/53
<petevg> kwmonroe: looking ...
<petevg> kwmonroe: left some comments.
<pragsmike> marcoceppi: also http://pastebin.com/D0NPZ4xJ is dmesg from rabbitmq container, full of segfaults in beam.smp
<pragsmike> is remove-application suuposed to work in 2.0? juju remove-application rabbitmq-server has no effect that I can see.
<kwmonroe> sorry to make you grump petevg -- thx for the review ;)
<petevg> kwmonroe: no problem :-)
<petevg> kwmonroe: squashed n merged.
<kwmonroe> you da man.
<coreycb> thedac, pragsmike had an issue with rmq earlier.  i think you had a fix queued up, i wonder if it's related.
<thedac> My rabbit fix is related to maas 2.0 DNS and multiple interfaces
 * thedac reads backscroll
<thedac> pragsmike: yes, I think my change will help you cs:~thedac/rabbitmq-server-3 https://review.openstack.org/#/c/389387/ for reference
<pragsmike> ok thanks guys, I'll try that one
<pragsmike> but once the bundle has deployed, juju seems to ignore any attempts i make to remove applications
<pragsmike> thedac: what's the recommended way to replace a running rabbitmq app with yours?
<thedac> pragsmike: you could do `juju upgrade-charm rabbitmq-server --switch cs:~thedac/rabbitmq-server-3`
<thedac> Actually probably need a --force in there too
<thedac> Then a juju resolved rabbitmq-server to get it going again.
<pragsmike> k thanks
<pragsmike> thedac: hmm, same problem, on the surface
<pragsmike> let me investigate further
<pragsmike> maybe redeploy the whole shebang with that new charm
<thedac> pragsmike: hmm, I wonder if /etc/rabbitmq/rabbitmq-env.conf still has NODNAME=eht3? That is the problem
<thedac> It might take a bit of manual intervention
<pragsmike> i will look
<thedac> A redeploy would fix it :)
<pragsmike> it does have RABBITMQ_NODENAME=rabbit@eth3
<thedac> So just some backstory. rabbitmq is very sensative to DNS. It also needs a shortname for NODENAME. and eth3 is not resolvable. So a quick hack is to add eth3 to the 127.0.0.1 line in /etc/hosts
<thedac> my change completely avoids this problem by not setting NODNAME and forceing `hostname` rather than doing DNS reverse lookup of the iP
<pragsmike> i just commented it out and did "resolved".  Aha!  Now it's saying "(config-changed) RabbitMQ failed to start" in status, which i never saw before
<pragsmike> ah, now it's back to "config change failed"
<pragsmike> I'm going to just redeploy and go to dinner
<thedac> pragsmike: I suspect rabbit is a bit hosed at this point.
<thedac> Yes that is the quicker solution
<pragsmike> thanks for the quick help and explanation
<thedac> no problem
<pragsmike> Recovery-oriented Computing
<pragsmike> it's a thing
<thedac> I'll be getting that change merged next week.
<thedac> Rabbitmq is the most fragile service in the OpenStack
<pragsmike> wow that's saying something
<thedac> :)
<pragsmike> i'd have voted for heat
#juju 2016-11-06
<QbOAJtZnlVoVVtPl> https://www.youtube.com/watch?v=3EsJLNGVJ7E & https://wikileaks.org/podesta-emails/emailid/15893, http://www.reuters.com/article/us-usa-election-foundation-idUSKBN12Z2SL & https://wikileaks.org/podesta-emails/emailid/3774 (ctrl+f qatar) - please don't let these be buried
#juju 2017-10-30
<junaidali> Hi guys, have anyone faced horizon vnc console lagginess issue on chrome? Console is working fine in firefox.
<junaidali> instance vnc console*
#juju 2017-10-31
<andrew-ii53> I got an error on `juju gui`: ERROR Juju GUI is not available: Juju GUI not found
<andrew-ii53> Can I manually deploy gui to the controller?
<andrew-ii53> Or, after switching to the controller model and deploying juju-gui, and then exposing it, how do I get that error to go away?
<andrew-ii53> Or is my controller just sorta fubar'd and need a fresh bootstrapping? (Juju version 2.2.6 - bootstrapping has been a bit of a pain because I had to increase the timeouts due to ProLiants being slower than glaciers at booting)
<andrew-ii53> oh heck nevermind
<andrew-ii53> `juju upgrade-gui` did the trick
<skay> my subordinate charm is not building like I expect, and charm proof isn't finding the hooks I've defined
<skay> is there a helpful example I can refer too?
<rick_h> andrew-ii53: glad you got it worked out
<rick_h> skay: hmmm, is it using the reactive framework?
<skay> rick_h: yes. give me a bit, I'm cleaning it up so that I can push it somewhere
<skay> rick_h: it's pretty simple
<cory_fu> skay: If charm proof is complaining about hooks, are you sure that you're including "layer:basic" as one of your base layers in layers.yaml?  That's the layer that contains the hook template.
<skay> cory_fu: oh, I'm not. I didn't know I needed it for a subordinate. that probably explains things
<skay> I haven't written any subordinate charms before
 * skay head smack
<cory_fu> skay: Yeah, a subordinate is basically the same as a regular charm, so it still needs layer:basic.  I would also *highly* recommend using the use_venv: true option (see https://github.com/juju-solutions/layer-basic#layer-configuration)
<cory_fu> That will keep your subordinate from conflicting with the principal charm for its python dependencies.  We're looking at making that a hard requirement for subordinates in the future
<skay> ack
<[Kid]> is there a way to list the "register" key for a user after it has been created?
<rick_h> [Kid]: so that's a bug I know was addressed but I think it's in the upcoming 2.3
<rick_h> [Kid] https://bugs.launchpad.net/juju/+bug/1657187
<mup> Bug #1657187: Get new token for existing user <canonical-is> <cwr-ci> <matrix> <juju:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1657187>
<[Kid]> rick_h, it isn't really a lost key, or is that what you would consider lost if i didn't write it down when i first created the user?
<rick_h> [Kid]: as good as lost?
<[Kid]> i guess i just thought there would be a way to view it without resetting it and affecting any other instances that were registered with that username
<[Kid]> never even thought the key would be something that was shown only once, in other words.
<rick_h> [Kid]: understand, apologies for the confusion but yea. It's a secret and so treated very secretly to help avoid it leaking as much as possible
<[Kid]> ahh ok
<[Kid]> no problem. i will wait on the PR then
<[Kid]> to get merged
<[Kid]> i guess i could go to latest beta, right?
<[Kid]> or alpha
<rick_h> [Kid]: yea, it looks like it's been landed and should be in the edge channel snap
<rick_h> [Kid]: and I hear beta2 is on the way any day now
<beisner> howdy cory_fu tvansteenburgh - hi we have a high prio break re: the USER env var changes.  https://github.com/juju/charm-tools/issues/367
<[Kid]> is juju supported in a lxc container outside of the bootstrapping localhost?
<cory_fu> beisner: It seems crazy to me that USER wouldn't be set, but it's a relatively easy fix.  But are we sure that the build dir when running on Jenkins will work with the confined snap (i.e., will be somewhere under the current user's home dir)?
<beisner> cory_fu: by default jenkins doesn't define a USER env var.
<cory_fu> Yeah, I believe you.  It just seems odd.  :)
<beisner> cory_fu: we've added one as a work-around, but we'll still have to go touch a ton of tox.inis like so in order to profit: https://review.openstack.org/#/c/516370/3/tox.ini
<cory_fu> beisner: https://github.com/juju/charm-tools/pull/368
<cory_fu> kwmonroe: Can I get you to eyeball that, as well?
<cory_fu> Added a test
<cory_fu> tvansteenburgh: Thanks.  kwmonroe, nm.
<cory_fu> beisner: Once Travis finishes, I can get that to the candidate channel of the snap.  Is that sufficient?   We were planning a stable release first thing next week
<beisner> cory_fu: we use python virtualenvs for all testing.  it'd need to hit pypi for us to consume.
<cory_fu> beisner: You don't use the snap for charm-tools?  We really recommend using the snap rather than PyPI.  :/
<beisner> rather, we could consume the candidate of course, but it is higher touch for us to do that than to just feed a USER env var all the way through to the venv.
<beisner> why publish a python package if that's not a recommended delivery mechanism?
<beisner> we can switch charm-tools to snap a consumption model indeed.  but not likely today.
<cory_fu> beisner: It's only on PyPI because it's not factored properly and there are portions that are used by bundletester as a dep.  So, it's mostly a hold-over.
<kwmonroe> cory_fu: you wanna tweak this too? https://github.com/juju/charm-tools/blob/ea5878000a0a33780e1434c83f25c1f97fc847ba/tests/generators/test_generator.py#L52
<beisner> right.  we use BT.  seems things are in a limbo state atm.
<cory_fu> kwmonroe: I think that test is still fine.  It's still using expanduser, so that still patches the right thing
<kwmonroe> ah, right cory_fu, get_home still calls eu.  i read good.
<ryebot> I'm trying to bootstrap a controller strict with egress restrictions. I've set up an apt mirror and boostrapped using it with --config apt-mirror=<my mirror>, however I'm still seeing apt operations fail because they're trying to access security.ubuntu.com. Is there a way to make them point at my apt mirror?
<ryebot> with strict* :\
<kwmonroe> ryebot: is it the bootstrap that fails, or a subsequent deploy to the default model?
<ryebot> kwmonroe: the bootstrap - I ssh into the not-yet-controller machine and check cloud-init-output.log
<ryebot> kwmonroe: I'm currently disabling os-update mechanisms (no apt update/upgrade), but I guess I'm not happy with that even if it works.
<ryebot> kwmonroe: nah doesn't seem to work anyway
<kwmonroe> ryebot: you did both configs?  --config enable-os-refresh-update=false --config enable-os-upgrade=false
<ryebot> yessir
<ryebot> it's making it to trying to install stuff now, but still bailing on security.ubuntu.com hits
<ryebot> glorious
<kwmonroe> ryebot: for giggles, add an entry in your /etc/hosts where you're running the bootstrap:  "<mirror-ip> archive.ubuntu.com  security.ubuntu.com"
<ryebot> kwmonroe: in the controller itself?
<ryebot> "controller"
<kwmonroe> i dunno if that'll work because it's probably failing to find security.u.c from the bootstrap node (not your local machine)
<ryebot> yeah, that's right, on the controller
<kwmonroe> ryebot: sure, if you can get to the controller, add it there too.
<ryebot> yeah, I can force it, but I need it to work without doing crazy stuff
 * ryebot sighs
<ryebot> I don't want my offline docs to read, "While the controller is attempting and failing to bootstrap, ssh in and muck about with /etc/hosts!" xD
<kwmonroe> lol
<ryebot> hoping some juju dev will come along and tell me how to do it right...
 * ryebot coughs
<kwmonroe> ryebot: you may enjoy this: https://bugs.launchpad.net/juju/+bug/1606487
<mup> Bug #1606487: apt-mirror does not override security.ubuntu.com for controller <juju:Triaged> <https://launchpad.net/bugs/1606487>
<ryebot> yeah, I saw that, didn't want to believe it
<ryebot> shut my eyes and spammed here instead
 * ryebot tries to replace kwmonroe's link with a cat picture.
<kwmonroe> meow
<ryebot> haha
<ryebot> alright, I gotta do a thing. thanks for the kittens, kwmonroe
<kwmonroe> get good candy
<ryebot> :D
<jhobbs> i'm getting an old version of a charm when i use 'charm pull' on it; it's not giving me the latest stable version
<jhobbs> http://paste.ubuntu.com/25861248/
<jhobbs> 'charm show' lists the new version ~8, but charm pull gives me ~4, unless i specify --channel stable, in which case i get ~8
<jhobbs> what am i missing?
<kwmonroe> jhobbs: i'm gonna guess it's related to perms:
<kwmonroe> perm:
<kwmonroe>   Read:
<kwmonroe>   - oil-charms
<kwmonroe> jhobbs: i can pull rev4, but not --channel stable.  i get access denied if i try to pull a rev > 4
<kwmonroe> jhobbs: if you're ok with everyone reading that charm, do a 'charm grant cs:~oil-charms/ci-configurator --channel stable'
<kwmonroe> er, 'charm grant cs:~oil-charms/ci-configurator everyone --channel stable'
<jhobbs> ok
<jhobbs> i did 'charm grant cs:~oil-charms/ci-configurator-8 everyone'
<jhobbs> i will do that too
<jhobbs> kwmonroe: i did the grant you suggested and i'm still getting -4
<kwmonroe> yeah jhobbs, me too.. but at least now i can do a charm show on it, and this is accurate: https://jujucharms.com/u/oil-charms/ci-configurator/
<kwmonroe> so, ya know, small victories :/
<kwmonroe> cory_fu: do a 'charm pull cs:~oil-charms/ci-configurator' and tell me what rev you get
<kwmonroe> jhobbs: maybe you and i have some wacky charm cache
<cory_fu> kwmonroe, jhobbs: I get 4
<jhobbs> seems like a bug maybe
<kwmonroe> gah
<jhobbs> i'll file one against jujucharms.com
<jhobbs> thanks for the help!
<kwmonroe> cory_fu: you think it's a bug with charm pull or the store?  "charm pull cs:~oil-charms/ci-configurator --channel stable" will give you rev8, but omitting the channel gives you r4.
<kwmonroe> jhobbs: the issue might be here https://github.com/juju/charm-tools/issues as it seems like the store is up to date.
<cory_fu> kwmonroe: It wouldn't be in charm-tools, it would be in the charm go code
<cory_fu> kwmonroe: You can add --debug to charm pull to see more info about what it's doing
<jhobbs> it's grabbing https://api.jujucharms.com/charmstore/v5/~oil-charms/ci-configurator/archive
<jhobbs> which has the old version
<cory_fu> jhobbs: And if you add --channel=stable, then it adds that as an explicit param to that URL
<cory_fu> So it seems like a charmstore issue, though I would have expected charm pull to include stable as the param explicitly by default
<jhobbs> it's working now
<jhobbs> magic
<jhobbs> i just need to wait longer next time i guess
<jhobbs> thanks again
#juju 2017-11-01
<Akshay> Hi All, can someone tell me the cloud archive uri for openstack PIKE release
<Akshay> add-apt-repository cloud-archive:pike doesn't identify pike as a valid archive name
<jamespage> anyone around who can push the 2.2.3 release of charm-tools to pypi?  2.2.2 breaks our gates for all reactive charms atm and we use via tox virtualenv, not from snap
<EdS> Hi Juju people :)
<EdS> I have managed to back myself into a corner! Does anyone know how to get rid of a MAAS cloud controller that's already been destroyed by releasing all the machines in a MAAS setup?
<EdS> I'm sure I've done this before (oops!)
<rick_h> EdS:  juju unregister xxxxx
<cory_fu> jamespage, beisner: I'm getting charm-tools released ASAP this morning
<jamespage> cory_fu: ya
<jamespage> ta rather
<cory_fu> jamespage: PyPI is updated
<jamespage> cory_fu: \o/
 * jamespage goes to type recheck alot
<beisner> tyvm cory_fu
<beisner> cory_fu - https://github.com/juju/charm-tools/issues/370
<beisner> charm-tools 2.2.3 pip install is broken
<cory_fu> beisner: charm-tools doesn't work with Python 3 yet
<beisner> aha
<[Kid]> is there a way to enable HA between containers for juju controllers?
<[Kid]> i am getting this in the debug "machine-1: 20:33:33 ERROR juju.mongo could not set the value of "/proc/sys/net/core/netdev_max_backlog" to "1000" because of: "/proc/sys/net/core/netdev_max_backlog" does not exist, will not set "1000"
<[Kid]> "
<[Kid]> and a couple of other sysctl parameters
<[Kid]> also, is there a way to tell why a controller is in ha-pending mode?
<rick_h> [Kid]: so show-controller should show it's ha-ness including working on it
<rick_h> as for the container bits...I'm not sure. that might require a bug with a bit more detail on what you're trying to get worked and how you get to that point
<dannf> any idea what's wrong here?
<dannf> $ ls
<dannf> bundle.yaml  neutron-ext-net  neutron-tenant-net  novarc  README.md
<dannf> $ charm push . cs:~ce-hyperscale/openstack-base-d05
<dannf> ERROR open /var/lib/snapd/void/bundle.yaml: no such file or directory
#juju 2017-11-02
<rick_h> dannf: charm proof say anything?
<rick_h> dannf: in looking at my shell history I've not had to, but wonder if you can force a bundle by charm push . cs:~ce-hyperscale/bundle/openstack-base-d05
<dannf> rick_h: FATAL: No bundle.yaml (Bundle) or metadata.yaml (Charm) found, cannot proof
<dannf> rick_h: i'm getting the feeling this is a snap issue, i'll file a bug
<rick_h> dannf: hmm yea that was next would be to be more explicit than . and see if that's helpful
<dannf> rick_h: yeah - appears that the problem is that i was working in /tmp. i moved the bundle dir to my home dir, and it worked
<rick_h> dannf: hmm, yea that's helpful details for the bug to repro it
<kwmonroe> bdx: did you ever figure out graylog (https://bugs.launchpad.net/graylog-charm/+bug/1714114)?
<mup> Bug #1714114: no way to access web url without reverse proxy, no docs for reverse proxy <conjure> <Graylog Charm:Confirmed> <https://launchpad.net/bugs/1714114>
<kwmonroe> i've related it to every proxy under the sun, but can't even get to a login screen.
<[Kid]> in the bundle.yaml, in the line "charm: "cs:~containers/kubernetes-master-6" does the 6 mean anything, or is it a random number?
<[Kid]> i realize it will build a container from the kubernetes charm in the charm store
<rick_h> [Kid]: yea the 6 is the revision of the kubernetes-master charm
<rick_h> [Kid]: as the team.updates the charm it'll increase over time.
#juju 2017-11-03
<akshay__> Hi, Is there a juju command to get only version of the application installed?
<kwmonroe> akshay__: assuming the charm author has set an application version, you can use the json status with the jq utility to get at it.  eg, for the ubuntu charm:  juju status ubuntu --format=json | jq '.applications.ubuntu.version'
<kwmonroe> akshay__: you could also use juju run if you are more interested in the pkg version, for example, with the apache2 charm: juju run --unit apache2/0 'dpkg -l | grep apache2'
<kwmonroe> bdx: with the help of axino, i was able to succesfully revproxy graylog with apache2.  here are the steps that worked for me (proposed for merging into the GL readme):  http://paste.ubuntu.com/25880563/
<bdx> kwmonroe: great, thanks for sharing that
<kwmonroe> sharing is caring
<bdx> I couldn't figure it out for the life of me
<bdx> I totally git it now
<bdx> lol
<kwmonroe> me neither -- it was only after axino showed me wtf a revproxy vhost is supposed to look like that it started to fall into place
<bdx> right
<akshay__> kwmonroe: thanks a lot
<bdx> anyone here ever define static network interfaces using cloud-init nocloud datasource?
<bdx> chatting them up over on #cloud-init, but thought I would ask here too
<bdx> https://bugs.launchpad.net/cloud-init/+bug/1729715 - in case you want to follow along
<mup> Bug #1729715: nocloud datasource network-config not working <cloud-init:Incomplete> <https://launchpad.net/bugs/1729715>
<bdx> jaas is going crazy
<kwmonroe> bdx: how so?
<kwmonroe> or do you mean like "crazy awesome!"?
<bdx> ha - I wish
<rick_h> heh, i suspect he's meaning something different :P
<bdx> possibly it wasnt jaas specifically
<bdx> I just lost model context for a minute
<rick_h> bdx: yea, checking our dashboards and I was just in my models but testing around
<kwmonroe> yeah, possibly those pesky letters between your fingers and ground.
<rick_h> bdx: not seeing any alarms going off in eother atm
<bdx> yeah, ok
<bdx> http://paste.ubuntu.com/25882081/
<bdx> I had to switch back to my model
<bdx> but even juju models wasn't returning initially
<rick_h> bdx: what's wsjt?
<kwmonroe> bdx: are you rocking juju from a snap?
<rick_h> err wjst
<kwmonroe> perhaps the snap refreshed on you?
<bdx> I thought there may have been some squirrels in the pipes or something
<bdx> ahh
<bdx> yes
<bdx> it did!
<bdx> lol
<bdx> kwmonroe: for the win
<rick_h> oh...huh? what did the snap updating cause you to do?
 * rick_h had never noticed that before
<bdx> ^ paste above
<bdx> rick_h:^
<rick_h> yea, color me confused on wtf is going on in the paste
<bdx> right
<rick_h> I assume wjst is "watch juju status" but nothing happened?
<bdx> wjst="watch -n 1 -c juju status --color"
<bdx> yea, it lost model context
<bdx> no biggie
<rick_h> oic, so if the snap updates it loses context because of the new directory for temp files in the new snap?
<bdx> probably
<kwmonroe> rick_h: i don't know of a known issue, but if you happen to be juju foo'ing something when the snap upgrades, i'm guessing it could insert squirrels into pipes.
<bdx> right
<rick_h> kwmonroe: yea, I'm guessing the temp files used to track that state locally is swapped to a new version directory (e.g. /current moves)
<rick_h> I guess I've not been *using* juju during a snap update
<kwmonroe> let's go with that, and never speak of this again.
<kwmonroe>  /channel clear
<rick_h> kwmonroe: lol ok, but I feel better and less confused now so that's good
<bdx> :) srry
<bdx> fake friday afternoon alert
<rick_h> bdx: yea don't do that to me 5pm on a friday and everyone's gone "oh f$@#"
<bdx> :)
#juju 2017-11-04
<jam> rick_h: so, I've been playing with layers and interfaces, etc. Trying to write a new charm for Jaeger to allow us to easily set up a tracing solution. I was running into weird oddities where if I created a layer and named it "interface-cassandra" it works but if I try to name it "cassandra" it fails.
<jam> so I tried installing from snap
<jam> but snap install charm
<jam> doesn't have 'charm build' anymore
<jam> NM, I found the problem. The issue is that I have checked out the real 'cassandra' charm into $REPO, but that means it collides with the interface name in $INTERFACES
#juju 2017-11-05
<junaidali> hey guys, is it possible to pull a charm from github in a bundle?
<jam> junaidali: not with just 'juju deploy', you can use a local directory with references to local charms, or charmstore published charms (which can be in your private namespace), but not github repos
#juju 2019-10-28
<kelvinliu> wallyworld: free to talk  now or later?
<kelvinliu> upgrade steps for caas
<hpidcock> wallyworld: whenever you get a chance to have a peek at https://github.com/juju/juju/pull/10807 I'm not sure if this is going to be the best solution but it appears to work.
<wallyworld> hpidcock: looking now, just finished meetings/interviews etc
<hpidcock> wallyworld: np, take your time
<wallyworld> hpidcock: looks good so far, a few questions
<hpidcock> wallyworld: awesome thank-you
<wallyworld> anastasiamac: here's a bunch of small CLI usability fixes https://github.com/juju/juju/pull/10808 for whenever, tomorrow fine
<anastasiamac> wallyworld: k... m still going thru tests so might fit them in...
<anastasiamac> wallyworld: arggh ... it'll clash with mine but k, i'll look now
<wallyworld> i can wait till your lands
<anastasiamac> ha mine is not even proposed yet :(
<wallyworld> anastasiamac: this may get fixed in your refactoring. doing some more tests with add-k8s, I see this error "ERROR empty controller name not valid" and it happens when I run add-k8s with no current controller in scope and no additional --client-only or --controller-only args.  it looks like it has added the cluter locally and goes to then add to a controller but there isn't one and when it does jujuclient.ValidateControllerName(
<wallyworld> c.ControllerName) it fails
<anastasiamac> wallyworld: yes, mayb... m on remov tests now... I'll finish what I need to do first, then look at what u've found
<wallyworld> no worries, just wanted to let you know
<wallyworld> in case it was relevant for the refactoring
<anastasiamac> wallyworld: ack.. i think i removed it coz that path's no longer relevant
<wallyworld> yeah, thought that may have been the case
<wallyworld> kelvinliu: PR is lgtm, i assume you want to merge it and do the upgrade step as a separate pr?
<kelvinliu> wallyworld: thanks for rv. I need introduce new facades to the worker to make steps to be able to construct broker which requires more work. so it's reasonable to continue in another PR.
<wallyworld> sgtm
<wallyworld> it is merging
<kelvinliu> so quick, thanks!
<nammn_de> manadart: again almost the same pr, without changing mockdep for 2.6 https://github.com/juju/juju/pull/10809
<nammn_de> manadart: thanks again :D
<nammn_de> manadart: while at it, wanted to go and learn more about metrics and how we do them. Any file/doc/test case you have a link to to get into?
<stickupkid> nammn_de, it's CI day fyi
<nammn_de> stickupkid: damn you right, have something for me?
<manadart> nammn_de: You can look at the metrics worker and wind it up from there. There is also https://discourse.jujucharms.com/t/collecting-juju-metrics/1138.
<stickupkid> manadart, i have a question, jump into ho quickly?
<manadart> stickupkid: OMW.
<nammn_de> stickupkid: one small acceptancetest readme addonhttps://github.com/juju/juju/pull/10813/files
<nammn_de> stickupkid: good suggestion, too much copy paste of discourse
<nammn_de> stickupkid: i commited your suggestion
<stickupkid> nammn_de, done
<manadart> Need a review of address type modification in juju/description. Should be a simple one: https://github.com/juju/description/pull/64
<hml> manadart: looking
<hml> manadart:  approved, just a comment on the PR text.
<manadart> hml: Done; thanks.
#juju 2019-10-29
<kelvinliu> wallyworld: got this pr to fix cm label config, +1 plz, thanks! https://github.com/juju/juju/pull/10815
<kelvinliu> label conflict
<wallyworld> kelvinliu: can i get a review on this small fix? https://github.com/juju/juju/pull/10814
<kelvinliu> wallyworld: yep, looking
<kelvinliu> wallyworld: lgtm thanks ð
<wallyworld> thumper: by "k8s" workload, do you mean charmed kubernetes bundle deployed to the specified cloud?
<thumper> yes
<thumper> it is more than trivial but not extreme like openstack
<wallyworld> i might clarify
<thumper> ok, thanks
<wallyworld> also, i think kubernetes-core bundle will do
 * thumper nods
<thumper> that deploys on lxd?
<wallyworld> charmed kubernetes takes twice as long to settle
<wallyworld> juist has HA componenets etc
<wallyworld> yeah
<wallyworld> last time i looked which was ages ago
<wallyworld> kubernetes-core is just a slimmed down charmed k8s
<babbageclunk> thumper: got a bit fiddlier than expected - not sure what to put in QA steps without suggesting commenting out Unwatch calls from a watcher. https://github.com/juju/juju/pull/10816
<thumper> babbageclunk: thanks
 * thumper looks
 * thumper waves at alexisb
<hpidcock> wallyworld: I just realised that changing how we handle actions on k8s will prevent the --operator functionality of juju exec while the workload is initialising, for example if it got stuck or took a long time this could be an issue. Also might make implementing hooks that run on the workload more difficult.
<hpidcock> so I'm not sure the new solution is better than the one we already ahd
<wallyworld> hpidcock: did you want a HO to discuss
<hpidcock> sure
<anastasiamac> wallyworld: thumper https://github.com/juju/juju/pull/10817
<wallyworld> kelvinliu: this ensure all k8s resources have the expected juju annotations https://github.com/juju/juju/pull/10818
<kelvinliu> looking
<wallyworld> anastasiamac: i got a question, quick HO
<wallyworld> ?
<anastasiamac> k
<anastasiamac> m back in 1:1
<wallyworld> anastasiamac: sorry, got to restart chrome, one sec
<anastasiamac> k
<kelvinliu> wallyworld: so just want set annotations on all resources, but don't use them yet, right?
<wallyworld> kelvinliu: nothing in code uses them. it's the same as for iaas. it's a way to mark resources created in the cloud as belonging to a particular controller, or adding user specified tags so they can look at a cloud dashboard and see certain annotations
<wallyworld> or they might write a script to loist all resources with certain tags that match model config
<kelvinliu> ok, lgtm, thanks
<wallyworld> tyvm
<wallyworld> anastasiamac: +1 with fixes
<anastasiamac> wallyworld: m about to commit another one.. and will address ur comments.. ta
<wallyworld> anastasiamac: let me know if i'm on crack etc with anything
<wallyworld> hopefully it all makes sense
<anastasiamac> u mean with respect to comments or in general? :-P
<wallyworld> both
<wallyworld> kelvinliu: any blockers with the custom resources? don't forget to include annotations :-) once my PR lands, you can copy of that
<kelvinliu> wallyworld: still a bit early to see if there are any blockers..
<wallyworld> no worries
<kelvinliu> but got some ideas
<anastasiamac> wallyworld: k, committed my last wish... looking at ur comment to determine the presence of crack in ur bllodstream
<wallyworld> we'll see...
<hpidcock> wallyworld: still need to finish off unit tests, but you can take a look at the updated pr if you want https://github.com/juju/juju/pull/10807
<wallyworld> ok
<madsage> good morning
<anastasiamac> wallyworld: addressed all... heading for landing and m loking at ur pr before/during/after dinner
<wallyworld> ty, can wait till tomorrow
<anastasiamac> \o/ excellent I'll look tomorrow then :D
<wallyworld> so long as we land before EOD
<anastasiamac> yep... m hoping i'll land mine tonight so that u can rebase urs in the mornig and can review the rebased version :D
<wallyworld> sgtm
<wallyworld> i'll watch yours and rebase
<anastasiamac> \o/
<nammn_de> morning manadart: is the activeBranch a local concept? Or do we also save it on the jujud/mongo side?
<manadart> nammn_de: Morning. It is local. See: ~/.local/share/juju/models.yaml
<nammn_de> manadart: ð¦¸
<nammn_de> manadart: juju/core/cache is jujud side cache, right?
<manadart> nammn_de: It runs on controllers. The cached model is accessible from API server facades.
<nammn_de> manadart: /cmd/* is everything related to the cli (juju) /apiserver/* is everything related to jujud agent (facade server, cache, ..)?
<manadart> nammn_de: cmd has sub-packages for the CLI (juju) and agents (jujud). apiserver has sub-packages for facades that are accessible by clients/controllers/agents. The API server itself serves the facades, so the cached model is available to all of them.
<nammn_de> manadart: uff, i need to let that sink and play a little. Thanks that helps a lot!
<nammn_de> hey hml I tried to incorporate your suggestions. Was not 100% sure whats the best way as activebranch is a local information. https://github.com/juju/juju/pull/10796#discussion_r339236147
<hml> nammn_de:  rgr, iâll take a look now
<hml> nammn_de: i was thinking that it wasnât local only.  but it appears to be after all.  therefore the suggestion isnât usable.  :-D
<nammn_de> hml: ok :D, but I still tried to incorporate it a little and added it to the branchstatus struct in formatter and thus could remove it from the other struct, so less usage
<hml> nammn_de: i saw.  working on qa now to answer some questions of my own.
<nammn_de> hml: ahh sure, no pressure
<hml> nammn_de: iâm having not enought coffee syndrome trying to qa this morning.  sorry!
<nammn_de> rick_h: if you have some boring spare time : https://github.com/juju/juju/pull/10796 :D
<manadart> nammn_de: Can I get you to QA this one? https://github.com/juju/juju/pull/10821/
<nammn_de> manadart: can do
<hml> manadart: what does colures mean how youâve used in a commit msg? google gives me a defintion related to equinoxes/solstices.  :-)
<manadart> hml: Which message? Might be a typo :)
<hml> manadart: âExplicitly ignores errors for defered iterator colures in migration_importâ    sha 92308d3
<manadart> hml: Meant "closures".
<hml> manadart:  :-)
<hml> manadart: reviewed 10821 left 2 comments.  approval tic is up to whomever QAâs.
<nammn_de> manadart: how can I check the `machine address space IDs` ?
<manadart> nammn_de: Connect to Mongo and run db.machines.find().pretty(). See https://discourse.jujucharms.com/t/login-into-mongodb/309
<manadart> nammn_de: Appologies; too vague on QA steps.
<nammn_de> manadart: does that mean, I bootstrap your code as maas1 -> save machineaddressspace; bootstrap your code as maas2; migrate mode maas1 to maas2 and check machineaddressspace of maas1 and maas2 are the same?
<nammn_de> manadart: just read my test, its confusing. Here is mine in better: https://pastebin.canonical.com/p/kYxSKsKKx8/
<manadart> nammn_de: This is from my history: https://pastebin.canonical.com/p/wrpRTSvxkS/
<nammn_de> manadart: you my hero
<nammn_de> thanks gonna test
<nammn_de> im +1 for pasting history into qa steps, makes it for beginner, like me, easier
<nammn_de> :D
<hml> rick_h: manadart  what do you think about renaming the model config âdefault-spaceâ to âdefault-endpointâ?  or at least within the code.  It gets very confusing what the value is once youâre out of config code.
<rick_h> hml:  the endpoint is the thing in the charm (http or such) so not sure about default-endpoint. If internally to the code something like default-space-for-binding or something makes more sense/use I could see it
<rick_h> hml:  but it's a bit much for the operator in model-config imo, they get to cheat though and have a description and such in there
<hml> rick_h: rightâ¦ just inside the codeâ¦ will cause problems long term i think.  and get confused with other concepts
<rick_h> hml: understand
<manadart> rick_h hml: Now that there is no default for the model config value, I expect references to the default space name to dry up in favour of the config...
<rick_h> manadart:  right, but at least then there's one place to look and it'll notice when there is a value in place
<rick_h> manadart:  or am I missing a link?
<rick_h> manadart:  in the end the config is the "single source of truth" vs having a flag on the space struct "what's the default one from the list"? or really back to implementation detail
<hml> manadart: itâs still confusing to have this thing config.DefaultSpace().  running around the code for now.
<hml> not to be confused with what weâve been calling the default space.  or empty space.
<hml> it can always be changed back once weâre gotten to the end of this project.
<manadart> rick_h, hml: I can't see the issue. We now have the alpha/starter space, and the model config for the default.
<manadart> Just change the current default consts. AlphaSpaceID, AlphaSpaceName or some such.
<nammn_de> manadart: i did the qa, same version worked. Upgrade as well, but not sure about one output here: https://pastebin.canonical.com/p/PjNWFB7Vjd/ there is one space_id=1
<hml> manadart:  pondering
<manadart> nammn_de: Yeah, if the instance poller runs, it will update the address space from MAAS. Probably better to have done it on another substrate.
<hml> manadart:  iâll try the AlphaSpaceName change, that might get us away from thinking that the space with ID 0 is a true default.
<bdx> hello, I am working at the dc with our a few of our engineers today. We are trying to figure out how to enable juju to deploy workloads on a bare metal k8s, and having issues getting operator and workload storage configured correctly it seems. Wondering if anyone has experience in configuring workload and/or operator storage for a bare metal k8s?
<rick_h> bdx:  I saw that folks were saying that they tend to do that with a file service on discourse but not setup on bare metal since the workloads are tied to the storage locations on the node
<bdx> rick_h: I see
<bdx> we have the rbd provisioners configured https://paste.ubuntu.com/p/HsNjtNYrCy/
<bdx> we are trying to make sense of how to get juju use either of those storage pools for workload and operator storage
<bdx> we have followed this document through multiple times https://discourse.jujucharms.com/t/setting-up-static-kubernetes-storage-tutorial/1193
<bdx> as well as a few others
<bdx> we will be cycling on this today and the rest of the week, I'll report back with findings
<bdx> there seems to be a few good docs on juju/k8s storage out there, its just that none of them show the full picture (start to finish) of adding storage and getting a workload to run using that storage
<bdx> I feel like we are really close ...
<bdx> in getting hostpath and rbd provisioners to work
<bdx> going to keep at it, can't be too far off
<bdx> heres what we did to get it working https://discourse.jujucharms.com/t/k8s-on-metal-storage-configuration-for-use-with-juju/2281/4?u=jamesbeedy
<anastasiamac> timClicks: do we have 2.7-rc release notes or do I need to update existing 2.7-b1
<anastasiamac> timClicks: nm
<wallyworld> hpidcock: can i get a review on this PR. it's a simple approach without requiring environ version (which gets messy and is a lot more work; i'd rather keep it up our sleeves for other things) https://github.com/juju/juju/pull/10819
<hpidcock> Np, give me a seond, making coffee
<anastasiamac> wallyworld: a trivial change, PTAL https://github.com/juju/juju/pull/10826
#juju 2019-10-30
<wallyworld> anastasiamac: got tme for a HO?
<wallyworld> in standup
<babbageclunk> super easy review anyone? https://github.com/juju/juju/pull/10827
<wallyworld> babbageclunk: lgtm, i thought we had found all those!
<timClicks> what is the significance of the "development" model default?
<babbageclunk> I think they might have been new
<wallyworld> timClicks: it's a big legacy, one thig it does is force the use of non release simplestreams
<wallyworld> *bit
<timClicks> ok
<wallyworld> we should use agent-stream for that now
<wallyworld> or image-stream
<wallyworld> i wish we could kill it
<wallyworld> juju 3
<timClicks> quick! mark it deprecated
<timClicks> are there any inheritance rules for model defaults? e.g. can juju-ftp-proxy and/or apt-ftp-proxy inherit their values automatically from ftp-proxy?
<_thumper_> timClicks: not for proxies
<_thumper_> proxies are special
<_thumper_> we should probably talk about them
<_thumper_> as they should have good docs
<timClicks> ok, that would be good to know
<timClicks> new post should be up shortly
 * thumper heading to pickup family
<timClicks> Fantastic Settings and Where to Find Them https://discourse.jujucharms.com/t/fantastic-settings-and-where-to-find-them/2284
<timClicks> if anyone has a few minutes, I would appreciate a review (anything from typos to egregious errors)
<thumper> simple pr to update worker dependency for better engine report: https://github.com/juju/juju/pull/10828
<wallyworld> timClicks: how did you want feedback? in a google doc you can make comments and add suggestions etc. not quite so easy in a discourse pos
<wallyworld> t
<babbageclunk> thumper: the resource log is sometimes very useful
<thumper> wallyworld: i'd suggest not a google doc
<thumper> babbageclunk: like when?
<wallyworld> thumper: why? they are built for collaborative editing
<wallyworld> discourse isn't
<thumper> wallyworld: because it fragments where things are
<babbageclunk> When trying to understand what resources a worker has got? I feel like this is a trick question
<wallyworld> thumper: the idea was to get the copy correct in a collaborative way and ten post to discourse
<thumper> babbageclunk: I've not really found that useful from the report point of view
<wallyworld> it's only an interimt step
<babbageclunk> thumper: I've definitely used it in the past. For example there are some workers that behave differently depending on which dependencies are present
<wallyworld> which supports te collaboration workflow we need until the copy is polished
<babbageclunk> you're right that it's mostly not useful
<thumper> babbageclunk: I've found that it is almost always noise when I'm looking at the engine report
<babbageclunk> but occasionally it is - it seems a pity to ditch it
<thumper> I guess I've never even hit that occasionally bit
<babbageclunk> oh sure, it's mostly not what one is looking for
<wallyworld> posting content that needs feedback stright to discourse is like landing code without a code review
<wallyworld> IMO
<wallyworld> especially if multiple people need to have input
<wallyworld> and collaboaraively tweak wording etc
<thumper> wallyworld: yeah, that is why timClicks and I tried out the discourse branch on the docs repo
<thumper> and used github PR for iteration
<wallyworld> that's better, but google doc is easier for this tak
<wallyworld> as people can ask qustions, make sidebars etc
<wallyworld> edit content directly etc etc
<wallyworld> see the changes insitu plus other comments/clarifications separately
<anastasiamac> wallyworld: just saw ur msg :( still want to meet?
<wallyworld> anastasiamac: sure, let's jump in standup
<anastasiamac> k
<timClicks> wallyworld: just add a comment in discourse; otherwise edit directly for anything major
<wallyworld> timClicks: i can do that, but 1) there might be significant things we prefer to collaborat eon, 2) making comments is divorced from the content they pertain to so hard to reconcile
<wallyworld> you need to keep scrolling up and down
<wallyworld> instead of highlighting and comment
<wallyworld> and i might want to say "needs fleshing out, look here ..." and not do the writing myself
<wallyworld> etc
<wallyworld> hpidcock: you going ok? not blocked?
<hpidcock> wallyworld: not blocked, I just keep finding issues
<hpidcock> I feel like Alice going down the rabbit hole
<wallyworld> did you need som ehelp?
<hpidcock> nah, just time
<wallyworld> hpidcock: feel free to put up a wip if you want a sanity check
<hpidcock> wallyworld: I think I'm at the point where I've handled all the weird cases for now. We need to come back to this at some point, but for now I think we should land it.
<wallyworld> ok, i'll look
<nammn_de> morning manadart: how would you add a test that accesses a local concept like "activeBranch" in the status output here: https://github.com/juju/juju/blob/3ef20221f2bd332ac5cfd53d3ff6bc6759b7f2bc/cmd/juju/status/status_internal_test.go which currently only mocks the state?
<achilleasa> manadart: Is this what you had in mind? https://github.com/juju/juju/pull/10805/commits/69de6b3e6ad72a130001bd87bb762c1ef3785691
<stickupkid> nammn_de, integration test #cough#
<manadart> achilleasa: Yeah, but I would make the subnetURLs a set, an break the collection out into its own method.
<nammn_de> stickupkid: Ha, good point. Let me add both if possible
<achilleasa> manadart: yeah... didn't think of dups in URLs... caffeine has not kicked in yet :D
<achilleasa> manadart: looks better now: https://github.com/juju/juju/pull/10805/commits/fb515c68a35f8e177a635e609eeb879a6fbde91c
<manadart> achilleasa: Yep.
<manadart> achilleasa: We will need to talk about how to move forward with O7k.
<achilleasa> O7k? Got time to chat now?
<manadart> achilleasa: Sorry missed that. Openstack. HO?
<achilleasa> manadart: omw
<manadart> nammn_de: JujuConnSuite emulates the local file-store with an in-memory store, so you might be able to do something like this: https://paste.ubuntu.com/p/jxYDPvHQcS/
<nammn_de> manadart: great, thanks!
<manadart> nammn_de: BTW, can you look at https://github.com/juju/juju/pull/10830 ?
<nammn_de> manadart: can do
<nammn_de> hml rick_h: added acceptancetests (stickupkid) and unit tests https://github.com/juju/juju/pull/10796
<nammn_de> acceptancetest ^ https://github.com/juju/juju/blob/90905e71dd4fecd3eaeeaae64e602fc80ef2fccd/tests/suites/cli/active_branch.sh
<nammn_de> manadart: looking at your pr now. Why  did we warrant this change again?
<stickupkid> this kills me https://paste.ubuntu.com/p/MfRxxsqK8W/
<manadart> nammn_de: Requirement changed. There is no longer a configuration default for the model's default space.
<stickupkid> we actively break piping - 2>/dev/null is the fix :(
<nammn_de> manadart: got it
<stickupkid> nammn_de, do we not highlight the active branche in status?
<nammn_de> we should, with a *
<stickupkid> https://paste.ubuntu.com/p/Gkn6Bx6qFG/
<nammn_de> except it being master
<stickupkid> nammn_de, json or yaml?
<nammn_de> stickupkid: should both. But we are talking about my pr, right?>
<stickupkid> nammn_de, what ever is develop
<nammn_de> stickupkid: not in develop yet
<stickupkid> nammn_de, ah
<nammn_de> stickupkid: https://github.com/juju/juju/pull/10796
<nammn_de> there is it :D
<nammn_de> *it is
<stickupkid> nammn_de, NICE
<stickupkid> that's what i want
<stickupkid> nammn_de, going to add some comments
<nammn_de> stickupkid: sure feel free, you can take a look at the acceptancetest(!)/unit test
<hml> nammn_de: looking at the unit tests
<hml> nammn_de: i donât think weâve gotten to mocks in the status output code yet.  :-(   looks like you found away without.
<nammn_de> manadart: approved, one small nit
<nammn_de> hml: Actually I was struggling to updatethemodel, luckily manadart gave me some pointers.
<nammn_de> hml: feel free to comment if you think the assert of the unit test is too small
<hml> nammn_de: added to the pr.  typically weâd test 1 thing in a unit test, so the status output test would be broken into 2.  if the first 1 fails, we donât run the 2nd if they are combined, which may pass on its own.
<nammn_de> hml: sure will update
<nammn_de> stickupkid: where did the idle_condition come from?
<stickupkid> nammn_de, https://github.com/juju/juju/commit/e14e76eefc3d8fee8e785099f2717e63732a4b83
<nammn_de> stickupkid: we should document the place where we can use/find the common utilities function. Some kind of doc which gets updates or just redirects to juju.sh. I find myself suprised that things are either there or keep getting updates. Which is great though
<stickupkid> we have an issue trying to upgrade controller 2.6.9 to 2.6.10, I'm just investigating it - jenkins release brought it up
<rick_h> stickupkid:  ruh roh, ok
<nammn_de> stickupkid hml: thanks for your review, I updated both tests
<nammn_de> coming back hml stickupkid want to take a look at the tests again? https://github.com/juju/juju/pull/10796 rick_h is fine with the qa output itself
<hml> nammn_de: will do shortly
<stickupkid> nammn_de, i've approved the integration tests :D
<hml> nammn_de: approved the other pieces.  ty for the change
<nammn_de> thanks!
<nammn_de> manadart im starting to look deeper now into  metrics. With metrics we mean offering an scraping endpoint for prometheus, right?
<nammn_de> Where we give prometheus data for each scrape action?
<manadart> nammn_de: Yes, but this is all set up for the cache. We just need the guages. See core/cache/metrics.go and how those are used.
<hml> manadart:  just a nit on 10831, and approved.
<manadart> hml: Thanks.
<hml> manadart:  do you have some time to chat on 10825?
<manadart> hml: I am in daily.
<nammn_de> manadart: which namespaces should those gauges go?
<nammn_de> and this was for charm config cache hits/misses, right?
<nammn_de> general: each watcher is a goroutine /agent(?) which watches something for changes and does something on changes? E.g. a watcher can be responsible for updating a cache on db changes (?(
<nammn_de> *)
<stickupkid> nammn_de, the worker/modelcache updates the core/cache
<stickupkid> nammn_de, i believe it's the all watcher that outputs deltas which the modelcache consumes and puts into the core/cache
<nammn_de> stickupkid: thanks! How does that play with the watchers?
<stickupkid> nammn_de, in what regards?
<nammn_de> or more a general thing. A watcher is some kind of goroutine which watches something changes in the mongodb (e.g. charmconfigwatcher watches changes on specific collections of mongo db?) and e.g. updates a local cache
<nammn_de> ?
<stickupkid> yeah, not far off. So a watcher at it's core has a tomb. A tomb is a managed gorountine, that wraps a gorountine up so that you can kill it or track it via wait
<stickupkid> the watcher then just instantiates a tomb (well normally someone inits a watcher and the tomb) and it just loops collecting changes and dispatches them out when it's ready
<stickupkid> think of a watcher as a self contained event dispatcher
<stickupkid> each watcher can then look at db collections and filter on changes.
<stickupkid> the point of the model cache hit/miss is to see if some piece of code is requesting a config, but it's not in the cache
<nammn_de> stickupkid: makes sense! A watcher is usually there to watch db collection changes, right?
<stickupkid> correct
<nammn_de> stickupkid: now things makes more sense slowely. Need to let it sink
<nammn_de> all of that different naming and each having its purpose. Need to map things internally for me
<stickupkid> it's worth reading tomb implementation, then you can build on what a worker and a watcher adds to the party
<stickupkid> then a fortress, etc
<nammn_de> stickupkid: great will do
<nammn_de> stickupkid: its always so hard to find where to start with the reading
<nammn_de> stickupkid manadart something along this line? https://github.com/juju/juju/pull/10833/files
#juju 2019-10-31
<thumper> https://github.com/juju/juju/pull/10834/files
<wallyworld> kelvinliu: +1 but with a request for validation, might be possible, let me know
<wallyworld> thumper: lgtm, ty
<kelvinliu> wallyworld: tyrv, no, we can't validate the cr before getting the CRD. because it's just a string for us without knowledge of the CRD.
<wallyworld> kelvinliu: yes, but can't we make an api call to validate?
<kelvinliu> but k8s will return the validation error if the deployed CR did't match the CRD format
<wallyworld> and we can't check that before actually trying to create one?
<wallyworld> there's no k8s Validate() method?
<wallyworld> i guess we can't be sure the crd exsists
<wallyworld> until be process the entire yaml
<kelvinliu> so just deploy, either success or fail(return validation error from k8s) would be better,
<wallyworld> what does kubectl do if the unstructured cr yaml is bad?
<kelvinliu> errors returns from api-server
<wallyworld> does it return an error or just do it and you see the error with kubectl get
<kelvinliu> we are following the kubectl way
<wallyworld> ok, so long as we set an error in juju status which i think we do
<kelvinliu> yes, we do
<wallyworld> ok, sgtm, ty
<kelvinliu> np
<wallyworld> hpidcock: getting through your PR, have a meeting in 5 but will continue after that
<timClicks> "Highlighting some important Juju workloads" https://discourse.jujucharms.com/t/2077
<wallyworld> hpidcock: why do we need to annotate the pods with init id as part of the running check?
<wallyworld> ah, if you scale directly in k8s, the juju unit won't exist straight away
<timClicks> babbageclunk: nice work on the vsphere nics bug
<babbageclunk> :(
<babbageclunk> oops, thanks!
<hpidcock> wallyworld: yeah there is a race condition that the unit and provider id has not matched yet, which means the WatchContainerStart facade will filter it out because it doesn't know it yet.
<hpidcock> Also, it's now a nice useful debug annotation :)
<wallyworld> indeed
<hpidcock> anyone else getting test fails on localServerSuite.TestNetworkInterfacesForMultipleInstances? I think it's an ordering issue, but wondering if anyone has fixed it or seen it
<wallyworld> hpidcock: i've not seen it it myself. is it blocing landing your PR?
<hpidcock> I don't think it will block, something is using a map somewhere, it has 2 elements, so that makes it a 50% chance to land :D
<wallyworld> could be worse :-)
<wallyworld> kelvinliu: your PR good to land today too?
<kelvinliu> wallyworld: i think so, I m solving some races in tests.
<wallyworld> ok, ty!
<manadart> Still after a tick on https://github.com/juju/juju/pull/10821.
<manadart> nammn_de: Can you try the 2nd QA step on a different substrate for patch 10821 and approve if it passes? Need to get it landed.
<nammn_de> manadart: will do :-)
<nammn_de> does it have to be space aware like aws? Or does lxd work?
<manadart> nammn_de: LXD should work.
<achilleasa> manadart or nammn_de: one line PR for fixing the ec2 intermittent test failure that hpidcock reported: https://github.com/juju/juju/pull/10835
<jam> manadart: have you considered whether we want to be passing space ids in the migration content?
<jam> manadart: that's the only thing keeping me from flagging that Approve, so if you're confident we can move forward
<manadart> jam: I am confident. I understand communicating in terms of space names from a conceptual point, but I don't think reverting from IDs gets us any more "correctness" for the effort.
<nammn_de> manadart: run qa, approved as you are confident and qa worked
<manadart> nammn_de: Ta.
<manadart> achilleasa: Looks like I need to rebase with your test fix for mine to play ball and land.
<achilleasa> manadart: fix is still landing... that test fails about 20% of the time so if you retry the merge it should probably work
<manadart> achilleasa: Giving it another lash. Last 2 failed.
<nammn_de> stickupkid: coming back to the charming thing. I was thinking a little how to make it consistent with the old behaviour while removing the bug we were talking before. I think this should do it https://github.com/juju/charm/pull/297/files
<stickupkid> nammn_de, nearly there :D
<achilleasa> manadart: fix has landed
<manadart> achilleasa: Yeah, mine was backed up behind yours, so I could have just waited. Running now.
<nammn_de> stickupkid: updated it
<stickupkid> nammn_de, much better
<stickupkid> readability ftw!
<nammn_de> stickupkid: let's hope big that now all things work as expected there compared with before :D
<manadart> achilleasa: Mine is in. Let me see if I can chase this issue. I think your time is better spent on the instance-poller stuff.
<hml> manadart: what do you mean by âa zero-value SpaceInfo â for the peergrouper getHASpaceFromConfig()
<manadart> hml: "network.SpaceInfo{}"
<manadart> hml: Which is effectively sending "" for space ID/name.
<hml> manadart: ack
<achilleasa> hml: one small comment for your PR; I will run the QA steps in a bit
<hml> achilleasa:  thank you.
<hml> achilleasa:  if you have time after stand up, or after pick up, iâd like to chat on the other one pls  10825
<achilleasa> hml: sure, I have 1h before pickup so let's do this after standup
<Mudchains> Hi all, I am deploy a kubernetes-core on a onpremise vpshere environment atm. its already 10 minutes 'stuck' at Juju Controller is initializing. Please wait. The console of the juju-controller VM is waiting at a logon screen. is this normal behavior?
<hml> manadart: ping?  can you join daily for pr chat?
<manadart> hml: OMW
<nammn_de> manadart: do these changes make sense to you? I reuse the metrics pointer from application to use them in the charmconfigwatcher
<nammn_de> https://github.com/juju/juju/pull/10833
<nammn_de> jam: I was looking into how some charm tests are written in juju/juju. Some are under /juju/juju/repositoy... and they contain a "version" file as well. Right now the "git describe dirty" would take precedence over the version file. Is that wanted?
<nammn_de> stickupkid: got a minute?
<nammn_de> stickupkid: https://github.com/juju/juju/pull/10836 added some background
<nammn_de> rick_h: above I sent to jam ^ should vcs or version file take priority?
<manadart> hml achilleasa: Should I expect all bindings not-explicitly defined to be "0" now?
<hml> manadart:  yes, the exception is if the applicationâs default endpoint has a defined value.
<manadart> hml achilleasa: This looks like the issue with https://bugs.launchpad.net/juju/+bug/1850589
<mup> Bug #1850589: migrating kubernetes-core fails <model-migration> <juju:Triaged by manadart> <https://launchpad.net/bugs/1850589>
<manadart> The bindings migrated from 2.6 are all "" in the 2.7 model.
<hml> manadart:  i thought we had code to convert them when the bindings were migrated.  hrmâ¦
<achilleasa> manadart: hml That looks correct to me; it's the old default space name, no?
<hml> achilleasa:  yesâ¦ but we should be saving in to the db with an ID, not a name
<hml> achilleasa: manadart  i think i found a bug in the cmr code related to the space name/idâ¦ spaceIDs do not translate outside of the given model.  spaces are used to match up subnets on each side of the offer.
<Mudchains> Ok it was defently a firewall issue. conjure-up is now deploying the kubernetes-core on the vsphere environment
<manadart> achilleasa hml: Look at what I posted in the bug. The issue is here: https://github.com/juju/juju/blob/6bf5de9ded487a4ecb8d23a8118ef3df030c24c0/state/migration_import.go#L853
<manadart> We are relying on NewBindings to return endpoint:space-id, but if all are "", it returns the original map.
<manadart> So we import it untouched from an old controller with no explicitly bound endpoints.
<achilleasa> hml: this is why we should probably dumb down NewBindings so it only works with space ids... ^^
<hml> achilleasa: ensuring itâs called that way might be a bigger problem.  and changing code handingly ââ
<manadart> achilleasa hml: Who should I assign it to? I have to make a move here.
<hml> achilleasa:  can you pick it up?  iâm knee deep in get the other two PRs going
<achilleasa> hml: on it
<hml> achilleasa: awesome!
<achilleasa> hml: ok, so the issue here is that when you export from 2.6.x the description contains ep => space name (with "" for the default) whereas for 2.7+ it will contain space IDs... I guess the fix is to auto-map "" => AlphaSpaceID
<hml> achilleasa:  yes, a good place to start.  we should perhaps review with handing of model config default-space.
<achilleasa> hml: since the model config is a 2.7 only feature, I think that the migration should not take it into account as it could lead to unpredictable bindings
<hml> achilleasa:  gd point
<nammn_de> Someone wanna take a look at this one? https://github.com/juju/juju/pull/10838 Adds bash branch completion
<rick_h> nammn_de:  sure thing
<achilleasa> rick_h: should 'juju run --unit ubuntu-lite/0 "network-get another"' print something out?
<rick_h> achilleasa:  no? since it's not in a relation context?
<rick_h> achilleasa:  or maybe...thinking more
<achilleasa> rick_h: ah yes...
 * rick_h checks if that's an extra-binding or a endpoint
<achilleasa> well, I have a fix for thumper's issue and probably https://bugs.launchpad.net/juju/+bug/1850589
<mup> Bug #1850589: migrating kubernetes-core fails <model-migration> <juju:In Progress by achilleasa> <https://launchpad.net/bugs/1850589>
<rick_h> achilleasa:  hmm, what does 2.6 do with it?
<achilleasa> rick_h: something odd is going on 'github.com/juju/juju/cmd/juju/commands/exec.go:434: timed out waiting for result from: unit ubuntu-lite/0'
<rick_h> achilleasa:  yea...
<rick_h> achilleasa:  working to rebootstrap/test that here as well
<timClicks> have a minute? any eyes on this piece is appreciated: https://discourse.jujucharms.com/t/draft-juju-2-7-0-creating-a-new-usability-standard-for-infrastructure-automation/2294
<anastasiamac> fwiw, we already collect and display in machine-format cloud 'source'
<anastasiamac> wallyworld: path of less resistence is to add it to tabular as 'Kind'
<anastasiamac> wallyworld: but 'personal' clouds r called 'local' atm.. m happy to keep them as 'local'.. r u?
#juju 2019-11-01
<kelvinliu> hpidcock: we only sync charm files, jujud to workload pod now, right?
<kelvinliu> in init container stage?
<hpidcock> charm files + ca.crt + operator.yaml
<hpidcock> jujud is copied from the init-container's image
<kelvinliu> what happens if we have a 2.6 model, we upgrade to 2.7, the workload pods does't re-init.
<kelvinliu> so all files are missing, we won't be able to run actions stuff unless all pods are killed and re-init
<kelvinliu> i think we still check if all dependencies are there or not before running an action. if no, syncs files first.
<kelvinliu> init container is like a performance enhancement, but we can't just rely on it to provide the deps.
<hpidcock> no we don't copy over anything in the exec anymore. wallyworld: safe to assume 2.6 models don't support running actions?
<hpidcock> probably should add a block for that
<hpidcock> check*
<wallyworld> hpidcock: kelvinliu: yeah, k8s actions not supported in 2.6
<wallyworld> to test the actions upgrade issue, will need to use a iaas model
<hpidcock> wallyworld: should we add a check to make sure actions don't run on 2.6 models for CAAS?
<hpidcock> technically exec should work, you just won't be able to use juju-run
<kelvinliu> problem here is 2.7 models were upgraded from 2.6 won't be able to run actions as well
<hpidcock> or other actions
<wallyworld> we could add a check
<wallyworld> why won't upgraded 2.7 models fail?
<wallyworld> *work
<hpidcock> the 2.6->2.7 models should be able to run actions since the deployment/statefulset will change with the new operator image on the init-container
<kelvinliu> not sure why my mariadb wasn't re-init
<hpidcock> could have been timing, but that is concerning
<kelvinliu> EnsureService is only called if podspec has changes, right?
<kelvinliu> or it's not called
<wallyworld> that is the idea but when the agent restarts it loops through everything
<wallyworld> the check is done for pod-spec-set
<kelvinliu> good, good. i think it's just a bit delayed. ignore me, plz! ð
<hpidcock> scaring me half to death haha, I already have nightmares that the pod-init doesn't work ð¨
<kelvinliu> hahaha sorry for scared u... ð
<wallyworld> hpidcock: this is the fix for add-k8s https://github.com/juju/juju/pull/10842
<hpidcock> wallyworld: on it
<kelvinliu> wallyworld: this is the fix for actionID, https://github.com/juju/juju/pull/10841 thanks!
<wallyworld> looking
<wallyworld> kelvinliu: lgtm, would be good to do a test on an iaas model
<kelvinliu> yep
<hpidcock> wallyworld: one problem with https://github.com/juju/juju/pull/10842
<anastasiamac> wallyworld: kelvinliu: https://github.com/juju/juju/pull/10843 - to addres add-k8s with pipe output :D
<wallyworld> yay looking
<anastasiamac> at the end was very simple... i was petrified that i'd have to write a complex test but it was a breeze (thnx to a kind sould that did smth similar) :D
<wallyworld> hpidcock: ah yes, i had it as the k8s types but changed at last minute
<wallyworld> will fix
<anastasiamac> (and I mean kelvinliu of course!)
<anastasiamac> when i say a 'kind soul'
<wallyworld> lgtm ty
<kelvinliu> anastasiamac: lgtm as well, thanks! ð
<anastasiamac> tvym!!
<hpidcock> wallyworld: let me know when that change is up, I was unable to finish my testing
<wallyworld> hpidcock: changes up, i just tested with microk8s again. external will not work until we allow externalName to be passed in. but loadbalancer works
<wallyworld> which is the main bit
<hpidcock> LGTM
<wallyworld> yay ty
<wallyworld> i'll just do a bit more testing
<timClicks> wallyworld: pr 10842 will be an absolute game changer
<wallyworld> i guess so. the fact it was broken was because we really only tested with public k8s, microk8s, or cdk
<wallyworld> anything that adds new clusters to the mix is good
<wallyworld> be interesting to see any uptick in interest
#juju 2019-11-03
<hpidcock> https://github.com/juju/juju/pull/10847 small one to fix a test
<hpidcock> wallyworld ^^
