[08:24] <apuimedo> jamespage: I got the MEM manager charm working yesterday with ha and all. I'll be adding tests and unit tests and I'll pass it along for review
[08:24] <apuimedo> I was also checking the reactive layers
[08:24] <apuimedo> It's quite an interesting concept
[08:24] <apuimedo> and the interfaces possibly even more
[08:25] <apuimedo> but by God will it be a piece of work to move the openstack charms to that
[08:38] <jamespage> apuimedo, a large bit of work to re-factor all 23 existing charms to reactive/layers/interfaces :-)
[08:39] <apuimedo> yeah
[08:39] <jamespage> apuimedo, good morning btw
[08:39] <apuimedo> I saw somebody started working on the keystone interface
[08:39] <apuimedo> jamespage: good morning indeed ;-)
[08:39] <jamespage> apuimedo, yah - let me give you a few pointers as to work we've done
[08:39] <jamespage> apuimedo, https://code.launchpad.net/~openstack-charmers/+git
[08:40] <apuimedo> I added a Midonet API interface yesterday
[08:40] <apuimedo> the only thing I don't quite see well is that in most interfaces I don't see any place for unit tests
[08:40] <apuimedo> so it feels a bit magical
[10:09] <deanman> Hello, I'm trying to bootstrap an AWS compatible cloud environment (eucalyptus) and can't seem to figure what's the configuration parameter to define the endpoint URL on environments.yam. Any hints?
[10:15] <mgz> deanman: there isn't one, you'll need to make some source changes
[10:16] <mgz> deanman: but that's likely less of an issue than getting an image etc working
[10:16] <mgz> deanman: you're probably better off using the manual provider
[10:17] <deanman> mgz: There a couple google hits where people discussed about deploying on eucalyptus and some even said they succeeded but couldn't find any reference for the endpoint url while checking the docs. Ok most probably you are right, i should check with manual provider
[11:39] <tinwood> ls
[14:08] <tvansteenburgh> I was just reading about Binding Service Endpoints to Spaces in the juju-core 2.0beta1 release notes. Does anyone know how to define an endpoint in a charm? I don't remember seeing anything about that.
[14:12] <tvansteenburgh> Never mind, this explains it: http://juju-sapphire.github.io/MAAS%20Spaces%20Demo/
[14:57] <icey> does upgrade_charm kick off config changed? and do defaults (that are left as defaults) update if changed in an upgrade_charm?
[15:16] <cory_fu> icey: I'm fairly certain that the only hook that runs during a `juju upgrade-charm` is the upgrade-charm hook
[15:17] <icey> thanks cory_fu, do you know if it will update the config if defaults change (and were still defaults at upgrade time)?
[15:17] <cory_fu> icey: Oh, you mean if the new version has different defaults?  I don't know, but my guess would be not
[15:17] <icey> ok, thanks cory_fu!
[15:18] <cory_fu> But that's just a WAG, so you should really test it.  I'm curious to what the result is if you do
[15:19] <jamespage> icey, config-changed will always run after upgrade-charm
[15:20] <icey> jamespage: but do the values (that were still defaults) change to new defaults as well?
[15:20] <jamespage> yes
[15:20] <jamespage> juju records if a non-default value was provided
[15:20] <jamespage> if it's not been changes, the default will change
[15:21] <icey> awesome, thanks jamespage!
[15:49] <neiljerram> afternoon all - Can I ask a question about Neutron-related charmhelpers?
[15:50] <neiljerram> I'm working on charm integration for a networking backend called calico. We've actually had charm support for a while, but now I'm just adding in Liberty support
[16:21] <jcastro> magicaltrout: ping! You were the guy looking at doing gitlab right?
[16:22] <pmatulis> anyone use rackspace with juju 2.0 ?
[16:23] <jose> pmatulis: afaik there's no provider, so I use manual
[16:24] <pmatulis> yes, the provider exists, i just can't get it to work
[16:24] <jose> oh... let me double check here
[16:24] <jose> ah, I'm stuck in 1.26
[16:52] <neiljerram> how can I clear the charm cache on the bootstrap machine?
[16:53] <neiljerram> On the bootstrap machine, I see this, and I think it's causing the deploy not to fetch my latest code from launchpad:
[16:53] <neiljerram> lp:~project-calico/charms/trusty/nova-cloud-controller/liberty
[16:53] <neiljerram> root@calico-vm07:/var/log/juju# find / -name "*nova-cloud-controller*"
[16:53] <neiljerram> /var/lib/juju/charm-get-cache/local_3a_trusty_2f_nova-cloud-controller-501.zip
[16:54] <hatch> I see that api-info is no longer a command in juju 2.0 - can anyone fill me in on what the equivelant command to `juju api-info --password password` is?
[16:59] <neiljerram> hatch, I'm afraid I doubt it.  I'm mostly seeing questions on this channel, and no answers.
[17:00] <neiljerram> Still, I wish you more luck than I've had!
[17:00] <hatch> :) Someone will pop in to answer you I'm sure
[17:04] <rick_h_> hatch: get-model-config maybe?
[17:04] <rick_h_> neiljerram: the deploy pulling from LP?
[17:04] <rick_h_> neiljerram: it comes from the store, if you've updated in LP it needs to get reingested which takes a couple of hours atm
[17:05] <neiljerram> rick_h_, I understood that it was possible to use a launchpad branch directly, with this syntax in the bundle file:
[17:05] <neiljerram>     "nova-cloud-controller":
[17:05] <neiljerram>       branch: "lp:~project-calico/charms/trusty/nova-cloud-controller/liberty"
[17:06] <rick_h_> neiljerram: juju deploy does't use that, only the juju-deployer tool. what version of juju are you using?
[17:06] <neiljerram> rick_h_, Also, my last upload to that branch was a couple days ago, so should have had any digestion needed.
[17:07] <neiljerram> root@calico14:~/md4# juju --version
[17:07] <neiljerram> 1.25.3-trusty-i386
[17:07] <rick_h_> neiljerram: k, your branch isn't /trunk so it won't be ingested to the charmstore, but once it is it'll be cs:~project-calico/trusty/nova-cloud-controller
[17:07] <neiljerram> I was deploying with: juju deployer -v -c liberty.yaml
[17:08] <neiljerram> rick_h_, Yes, that's what I thought.  I didn't want to create something in the store until I had some confidence that the code was working - hence the launchpad branch.
[17:09] <rick_h_> neiljerram: k, so to confirm you're using juju-deployer to deploy this?
[17:09] <rick_h_> neiljerram: oic, you're trying to upgrade the charm?
[17:09] <nagyz> ok, gonna ask here, since #maas is usually dead: do you guys think I can add arbitrary subnets to MaaS using the CLI? I think the requirement that the maas controller sits on every subnet that it can deploy nodes to is far fetched
[17:09] <nagyz> unless I have this backwards and it's just an auto-add-subnet function for the ones known already
[17:09] <nagyz> looking to deploy a greenfield OpenStack using proper public and private subnetting...
[17:09] <stokachu> whats the account parameter for in the CreateModel api? https://github.com/juju/juju/blob/master/api/modelmanager/modelmanager.go#L56
[17:09] <neiljerram> rick_h_, yes, exactly
[17:10] <stokachu> juju help create-model only lists --owner and --config as an option
[17:10] <rick_h_> neiljerram: ok, and how are you doing the upgrade?
[17:11] <rick_h_> stokachu: I think that's the work not complete yet
[17:11] <rick_h_> stokachu: you'll be able to specify a credentials.yaml entry
[17:11] <stokachu> rick_h_: ok
[17:11] <stokachu> gotcha
[17:11] <rick_h_> stokachu: e.g. juju create-model work-ec2-creds
[17:11] <rick_h_> and not have to pass them via the -c yaml file param
[17:11] <rick_h_> at least that's what the spec says, not looked into accounts in this code yet :)
[17:11] <stokachu> nice, yea right now i just use the ConfigSkeleton api call for that
[17:12] <stokachu> i wonder if they'll have a AccountSkeleton
[17:12] <stokachu> ok cool np
[17:12] <rick_h_> stokachu: if you're curious axw and wallyworld are the masters of this stuff
[17:12] <neiljerram> I took a fork of the upstream nova-cloud-controller, with: bzr branch  lp:~openstack-charmers/charms/trusty/nova-cloud-controller/next
[17:12] <stokachu> rick_h_: yea im just trying to stay up with the latest api changes for my work with bigdata install
[17:12] <stokachu> so i can be ready when juju goes live
[17:12] <neiljerram> Then I added my changes to that, and pushed to lp:~project-calico/charms/trusty/nova-cloud-controller/liberty
[17:13] <rick_h_> stokachu: gotcha, yea the credentials.yaml file is there, but the api for add-credential and such is in progress as next step for beta2
[17:13] <stokachu> ok cool, thanks for the info
[17:13] <rick_h_> neiljerram: k, but what command did you run expecting the charm to upgrade
[17:14] <neiljerram> rick_h_, nothing yet, I think.
[17:14] <neiljerram> rick_h_, I'm thinking the process is: 1. try out new code. 2. propose merge of my new code into lp:~openstack-charmers/charms/trusty/nova-cloud-controller/next
[17:14] <neiljerram> So at the moment I'm only at step (1).
[17:14] <rick_h_> neiljerram: right, but you were saying that the charm was't grabbing the new code
[17:15] <rick_h_> neiljerram: so you wanted to clear some caches?
[17:15] <neiljerram> Yeah, what I see is that on the machine where that charm should go, the deploy fails.  And when I did into the cause of the failure, it's because it doesn't have the latest code on that machine.
[17:16] <rick_h_> neiljerram: ok, so when you juju-deployer that bundle file it didn't get the latest bzr branch?
[17:16] <neiljerram> rick_h_, Yes, that's it.
[17:23] <bcsaller> is it too late to revise the "juju show-controller" (and similar) output so as not to put data in the keyspace. Its much harder to write validating schema for these things if things like the controller name are keys rather than data
[17:26] <rick_h_> bcsaller: shoot an email to the list with concerns and we can get feedback from wallyworld/axw and look into it.
[17:27] <bcsaller> rick_h_: yeah, sure, thanks
[17:29] <hatch> is there any way I can debug a hung " Waiting for agent initialization to finish" on aws with juju 2.0
[17:29] <hatch> it's been allocating for over 30minutes now
[17:30] <cherylj> hatch: take a look at /var/log/cloud-init-output.log and if that shows that the jujud started, look at /var/log/juju/machine-x.log
[17:31] <hatch> cherylj: the machines haven't been allocated on aws
[17:31] <cherylj> hatch: ah, that's interesting
[17:31] <hatch> is this cloud init output file on the controller?
[17:32] <cherylj> hatch: no, it would be on the instance
[17:32] <hatch> ahh ok, so yeah, no instance :)
[17:32] <hatch> These machines were created via the GUI, lemme see if I can add units via the CLI
[17:32] <cherylj> hatch: I'd look at the machine-0.log and search for the name of the service you deployed...  see if there are any errors around that
[17:32] <hatch> alright
[17:33] <cherylj> hatch: are you using beta1?
[17:33] <hatch> cherylj: tip updated this morning
[17:33] <cherylj> the GUI has some compatibility issues with 2.0-alpha2 and later
[17:33] <hatch> not anymore!
[17:33] <hatch> :)
[17:33] <cherylj> yay!
[17:33] <hatch> well...tip gui
[17:33] <hatch> lol
[17:33] <cherylj> hehe
[17:34] <hatch> actually it's still missing some features, but we're very close
[17:34] <cherylj> niiiice
[17:35] <ChrisHolcombe> using the juju coordinator seems to be a little bit tricky.  On my little ceph monitor cluster of 3 only 2 out of the 3 hosts got the coordinator lock.  The 3rd didn't for some reason
[17:37] <hatch> cherylj: the first instance of 'mariadb' in machine-0 log is: 2016-02-22 17:13:45 ERROR juju.state.unit unit.go:740 unit mariadb/0 cannot get assigned machine: unit "mariadb/0" is not assigned to a machine
[17:37] <pmatulis> rick_h_: re your config, can you confirm 'tenant-name == your account #' and 'username == name you log in to UI with' and 'password == p/w to log in to UI with' ?
[17:37] <ChrisHolcombe> sorry i should say charmhelpers coordinator*
[17:39] <hatch> cherylj: so even via the CLI it doesn't ever appear to allocate any more machines on aws
[17:39] <hatch> possible that tip is broken?
[17:41] <cherylj> hatch: bleh, that would be bad.  Let me see if I can reproduce
[17:42] <hatch> thanks cherylj - it's entirely possible that I have somehow broken this, but I was able to place units on the controller itself
[17:42] <cherylj> hatch: were you just doing "juju deploy mariadb"?  or were there special options / config?
[17:43] <hatch> I deployed the charms via the GUI, and scaled via the gui. When I tried to scale via the CLI I ran 'juju add-unit wordpress'
[17:43] <hatch> ^ cherylj
[18:02] <neiljerram> rick_h_, if you're still around - I don't think we reached a resolution in our conversation a little earlier...
[18:15] <jcastro> any resolution on the lxd/2.0beta issues identified over the weekend? I would cry if I had to move back to 1.25.
[18:16] <lazyPower> cory_fu : i've run into a context issue with relationships and peering :/  i dont recall if we solved this already.   > ValueError: Unable to determine default scope: no current hook or global scope
[18:17] <lazyPower> iirc - i think we had to assign each unit in the conversation to the scope bits, and iterate them?
[18:17] <cory_fu> Peers have to be unit scope.  Unit scope is incompatible with default conversations, so you always have to loop over self.conversations() and you can't ever use self.conversation() or self.set/get_remtoe
[18:17] <lazyPower> its all in here - https://github.com/mbruzek/interface-tls/blob/master/peers.py
[18:17] <lazyPower> found it, ta
[18:35] <rick_h_> negronjl: sorry, had a phone call
[18:36] <rick_h_> oops neiljerra...who left
[18:36] <rick_h_> doh
[19:25] <beisner> dosaboy, jamespage - ceph-* MP tests blocked on:  bug 1548478
[19:26] <mup> Bug #1548478: nova.conf section [libvirt] is missing option rbd_pool <uosci> <ceph (Juju Charms Collection):New> <ceph-radosgw (Juju Charms Collection):New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1548478>
[19:32] <dosaboy> beisner: hmm not sure how that got through wihout breaking amulet, i removed that conf entry cause it is useless
[19:32] <dosaboy> beisner: i'll see if i can fixup the tests
[19:32] <beisner> dosaboy, fyi, it made it through b/c the nova-compute test doesn't involve ceph.
[19:32] <beisner> in amulet that is
[19:32] <dosaboy> beisner: tru say
[19:33] <beisner> dosaboy, thanks for taking that
[19:33] <dosaboy> beisner: it's just a n-c thing thought right? i mean it is not a but but more an amulet test issue in teh n-c charm
[19:34] <dosaboy> s/but/bug
[19:34] <beisner> dosaboy, right, the n-c test is good.  other charms that cross-validate that the rbd conf thing was in nova.conf will need test updates
[19:35] <dosaboy> beisner: 10-4 got it
[20:15] <dosaboy> beisner: i guess we need to land this first - https://code.launchpad.net/~hopem/charms/trusty/nova-compute/lp1548478/+merge/286833
[20:16] <dosaboy> then the amulet fixes (coming up)
[20:21] <beisner> dosaboy, ack
[20:26] <dosaboy> beisner: amulet fixes all submitted but set to WIP until ^^ lands
[20:26] <beisner> dosaboy, right on.  tyvm.
[20:27] <dosaboy> beisner: thank you for raising the bug with all the necessary info :)
[20:40] <beisner> dosaboy, happy to
[21:18] <ChrisHolcombe> is it possible for one juju unit to call a function on another?
[21:19] <lazyPower> ChrisHolcombe - relations and actions make anything possible :)
[21:19] <ChrisHolcombe> lazyPower, so there's no issue with unit A calling functions on unit B?
[21:19] <ChrisHolcombe> rpc style?
[21:20] <lazyPower> Theres some glue code you'll want to patch the charm to listen to the API, and you'll have to give the charm juju API credentials
[21:20] <lazyPower> but yes, its completely possible, and wouldn't cause an issue if you encapsulate the concerns properly
[21:21] <ChrisHolcombe> lazyPower, +1000
[21:22] <ChrisHolcombe> lazyPower, so how would i go about giving api creds to a unit?
[21:30] <lazyPower> ChrisHolcombe - every time i've done it i've had marco or aisrael's help
[21:31] <ChrisHolcombe> lazyPower, time for a hacky workaround then
[21:31] <lazyPower> may the force be with you
[21:31] <ChrisHolcombe> ;)
[23:47] <stokachu> anyone run into this before: connection attempt for 172.16.0.150 failed: /var/lib/juju/nonce.txt does not exist
[23:47] <stokachu> does it just take awhile for it to generate?