[03:52] <lathiat> Hi Folks.. using juju local/kvm container (as part of openstack-install single-machine), trying to figure out how I can add a second disk to the machines when I deploy ceph/ceph-osd.  Can anyone point me in the right direction?
[05:32] <sebas5384> what happened with the service's settings in the juju-gui ?
[11:46] <cindy_> good morning guys
[11:46] <cindy_> having problems with bootstrap
[11:46] <cindy_> can somebody help me?
[13:50] <hazmat> any charmers around, can someone add me to charmhelpers, i've got pending merge i wanted to land
[14:36] <jujuer> good morning guys
[14:36] <jujuer> having problems with bootstrap
[14:36] <jujuer> may you help me?
[14:45] <roadmr> jujuer: go ahead and describe your problem, if someone knows how to solve it, you'll get help :)
[14:46] <jujuer> roadmr: thanks!
[14:46] <jujuer> well, I have a server where
[14:47] <jujuer> we deployed an all in one solution of openstack: glance, nova, neutron, swift, etc.
[14:47] <jujuer> now, I'm trying to "juju" to this server with my laptop
[14:47] <jujuer> we are on the same LAN: 10.0.0.0/24
[14:47] <jujuer> naturally, I'm sure both my laptop and the server have internet access
[14:47] <jujuer> also the VMs have internet access and can access to them via floating IPs with no problems
[14:48] <jujuer> I've set the parameters of my environments.yawl
[14:48] <jujuer> but... bootstraping always fails
[14:48] <jujuer> need logs?
[14:50] <jujuer> environments.yawl: http://paste.ubuntu.com/10092804/
[14:55] <jujuer> my terminal log: http://paste.ubuntu.com/10092884/
[14:56] <jujuer> btw, juju successfully creates a VM and a container on my openstack
[14:56] <jujuer> but it can't bootstrap... who knows why
[15:08] <roadmr> jujuer: hm are you sure about --metadata-source /opt/stack ? it seems unable to fetch data from there, check your log file
[15:09] <roadmr> jujuer: I haven't used that option before, so I'm not sure if it's OK, but that may be a good clue
[15:09] <jujuer> I'm pretty sure it does - as I said, it is able to instantiate the VM on the cloud
[15:10] <roadmr> jujuer: what happnens if you don't use that metadata source?
[15:11] <jujuer> you mean, the parameter?
[15:11] <roadmr> yep :)
[15:11] <jujuer> gonna try
[15:13] <jujuer> roadmr: I get an "earlier" error, logs incoming
[15:13] <jujuer> roadmr: http://paste.ubuntu.com/10093161/
[15:13] <roadmr> jujuer: oohh ok... well then :/ heh
[15:16] <jujuer> roadmr: this seems quite hard to fix :)
[15:18] <roadmr> jujuer: yes, I haven't deployed to openstack a lot so I'm not sure if I can help :/
[15:19] <roadmr> jujuer: when I did, I didn't use the metadata-source flag and everything worked fine, but clearly my config may have been different
[15:24] <frankban> tvansteenburgh: if you have time, could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/guiserver-auth/+merge/244984 ?
[15:31] <jujuer> nobody has ideas, guys?
[15:39] <tvansteenburgh> frankban: looking
[15:40] <roadmr> jujuer: if there's no reply I suggest you post a question in askubuntu.com :( sorry you haven't had any replies yet :(
[15:42] <frankban> tvansteenburgh: thanks
[15:44] <tvansteenburgh> frankban: commented with a suggestion. happy to discuss if you disagree or i'm missing something
[15:45] <hazmat> jujuer: thats an  interesting error
[15:45] <jujuer> hazmat: I'm literally going crazy... can't figure what to do
[15:46] <hazmat> jujuer: i pinged on #juju-dev to see if someone can come over here
[15:46] <jujuer> hazmat: thanks :)
[15:46] <hazmat> jujuer: it looks like a mongodb error getting setup.. how big of an instance type are you using?
[15:47] <jujuer> hazmat: what do you mean exactly?
[15:47] <hazmat> jujuer: how big is the machine your bootstrapping
[15:47] <hazmat> jujuer: how much memory / cpu / disk?
[15:48] <frankban> tvansteenburgh: reasonable suggestion, but since that deployer path is GUI server specific, and since the GUI server always use the deployer embedde in the Juju GUI charm, we do not have the backward compatibility problem. Actually, a fork of the deployer with that change has been included in the charm from quite a while now. for the enwxt release, we'd like to restore the upstream version (new deployer release)
[15:48] <jujuer> well, I'm not telling juju how much it's big... I'm simply running "juju bootstrap --metadata-source /opt/stack --upload-tools -v --debug"
[15:48] <frankban> next release even
[15:48] <hazmat> frankban: i already  merged that
[15:48] <jujuer> but, if you want, I can see on OpenStack how big it is instanced
[15:49] <frankban> hazmat: oh, didn't notice that
[15:49] <tvansteenburgh> lol
[15:49] <jujuer> well, hazmat, it creates a m1.small | 2GB RAM | 1 VCPU | 20.0GB Disk machine
[15:49] <hazmat> frankban: next release is roughly next week
[15:49] <frankban> hazmat: great thank you!
[15:49] <hazmat> jujuer: k, thanks. it does look like a config issue, just not clear what
[15:49] <frankban> tvansteenburgh: sorry about that
[15:49] <tvansteenburgh> frankban:  no worries
[15:49] <hazmat> frankban: np
[15:50] <jujuer> hazmat: you mean, my configuration is bad?
[15:50] <hazmat> jujuer: we have alot folks traveling atm unfortunately, they'll be back next week. no.. i think its a juju internal configuration error afaics. its setting up an invalid mongo replication config
[15:51] <jujuer> aw, fine. That's weird since I can't google any other guy having mine problem
[15:52] <hazmat> jujuer: yeah.. its not something i've seen before
[15:52] <hazmat> jujuer: but its pretty clear what the error is .. juju initializing a replica set on mongo without the required config on replicaset members
[15:53] <hazmat> jujuer: actually probably best is to file a bug for now
[15:53] <jujuer> hazmat: have I got any control on this?
[15:54] <jujuer> hazmat: or I can do nothing atm?
[15:55] <hazmat> jujuer: use an older version of juju (1.20)
[15:56] <hazmat> jujuer: your on osx?
[15:57] <jujuer> no - I'm using a Xubuntu 14.04 on the laptop where I'm trying to run juju bootstrap, and an Ubuntu server 12.04 on the openstack server
[15:57] <jujuer> hazmat:
[15:59] <hazmat> jujuer: so default juju in trusty/14.04 is currently 1.20.11 it looks like
[15:59] <hazmat> jujuer: i'd try that
[15:59] <jujuer> hazmat: sorry, I haven't understood much :/
[16:00] <hazmat> jujuer: what does juju --version show?
[16:00] <jujuer> on my laptop? 1.21.1-trusty-amd64
[16:02] <hazmat> jujuer: so its a little unclear where that version came from.. i'd guess from a ppa, i'm suggesting you might want to try uninstalling that version/ purging the ppa/ and then install the default distro version which is 1.20.11
[16:03] <jujuer> hazmat: installed juju via these two commands: sudo add-apt-repository ppa:juju/stable  sudo apt-get update && sudo apt-get install juju-core
[16:03] <hazmat> jujuer: but please do file a bug with that pastebin, its something that needs looking at http://bugs.launchpad.net/juju-core
[16:04] <jujuer> sooo hazmat ... should I purge juju and reinstall everything?
[16:06] <hazmat> jujuer: you have to apt-get remove juju / sudo ppa-purge ppa:juju/stable (if you don't have that you have to remove the ppa from /etc/apt/source.list.d and the apt-get update) / then apt-get install juju
[16:06] <TimNich> Agggh! Tried a juju bootstrap on my MAAS set up and it randomly chose a node that was unavailable, so the whole process hung. I aborted and tried to "juju destroy-environment" but that too tries to access the broken node and hangs. So I am now stuck with what the system thinks is a bootstrapped environment (but isn't) and I can't re bootsrap onto a specidied node until I persuade it its not! But as "juju destroy-environment" wont work how can I d
[16:06] <TimNich> that (catch22)?
[16:08] <hazmat> TimNich: juju destroy-environment --force
[16:10] <TimNich> hazmat: Thnaks
[16:11] <jujuer> hazmat: SOME BIG NEWS HERE!
[16:11] <jujuer> mongodb works, now I hit my head on a new error that comes later
[16:11] <jujuer> need logs?
[16:12] <jujuer> hazmat: http://paste.ubuntu.com/10094040/
[16:12] <hazmat> jujuer: sure, but hopefully someone else can help... i've got get back to work. i'll check back in a bit though.
[16:13] <jujuer> hazmat: aw ok, thanks anyway
[16:16] <hazmat> jujuer: that error is because you need to upload / create some 'simplestreams' data for juju to consume. its basically tells juju which images it should launch... see juju-metadata generate-image -h for more info
[16:16] <hazmat> and also juju-metadata validate-images
[16:17] <hazmat> jujuer: should be covered here https://juju.ubuntu.com/docs/howto-privatecloud.html
[16:42] <jujuer> hazmat: as long as I try, I can't solve that issue
[16:43] <jujuer> hazmat: it's strange since juju actually starts the right VM on the openstack
[16:43] <hazmat> jujuer: agreed it is strange
[16:44] <jujuer> hazmat: lol
[16:44] <jujuer> hazmat: sooo... have you got any suggestions?
[16:46] <dbart> lazyPower: around?
[16:46] <lazyPower> o/ dbart
[16:48] <dbart> lazyPower: I fiddled a little with the test, based on what you did prior to flying home, it looks like the 10-deploy-and-upgrade test now passes on the p8 machine
[16:48] <lazyPower> dbart: AWESOME
[16:48]  * lazyPower throws confetti and sounds trumpets
[16:49] <lazyPower> dbart: let me get someone thats on shift verify that for you and when I get back from my meeting I can run the gambit on getting mariadb ack'd
[16:49] <dbart> I wanted to get your opinion about the "test_enterprise_eval(self)" test, I'm thinking it might not be needed
[16:49] <lazyPower> are those changes checked in to bzr?
[16:49] <dbart> no, not yet
[16:49] <lazyPower> dbart: yeah that was a check to go from community => entp right?
[16:50] <dbart> yes, but currently it just starts with enterprise
[16:50] <lazyPower> its still a valid path that we need to account for, but it will consistently fail on p8 as the community edition doesn't have an installation candidate
[16:50] <dbart> yes
[16:50] <lazyPower> so that test works on x86 arch
[16:50] <lazyPower> I was thinking on this on the plane ride home - about how we want to address that as either split it out into another test suite that only gets kicked on p8, or if we add some conditional checks to find out which methods to run
[16:51] <lazyPower> kwmonroe: mbruzek: - Could really use your input as to how you feel we should proceed here wrt testing on p8
[16:51] <dbart> yes, something that can detect when it's on p8 and not run a new test that tests community installs
[16:52] <lazyPower> kwmonroe: mbruzek: the situation is - MariaDB Community edition doesn't exist on p8, just the enterprise installation. Our CI infra will test x86 all day every day, but if we get p8 added, this is a consistent failure we will see.
[16:52] <lazyPower> kwmonroe: mbruzek: so is this where we add some additional logic to the runner, or do we do an arch check in the test itself, and say "do this when x, do this when y"
[16:52] <dbart> I'm also waiting on a request I made on my side for proper test credentials
[16:52] <mbruzek> lazyPower: yes that!
[16:53] <lazyPower> dbart: We can probably get around some of that by stealing some logic from mojo
[16:53] <mbruzek> lazyPower: It would be ideal to have a passing test on both architectures
[16:53] <lazyPower> mojo has hiding test credentials baked in by default
[16:53] <lazyPower> mbruzek: agreed - i just dont know how we want to do this. if thi sis amulet's responsiblity or the tests responsibility.
[16:53] <mbruzek> lazyPower: But I understand the situation and would be OK with x86 only right now.
[16:54] <lazyPower> right, as we dont have p8 added to our CI - the tests in their current incantation are the proper path forward - but this is a short road until we get p8 added aiui
[16:54] <mbruzek> I would code the test to detect the architecture and react accordingly
[16:54] <lazyPower> ok. I'll file a bug on that and get cracking
[16:54] <lazyPower> mbruzek: do you have time to inspect kwmonroe's p8 box he lent me and validate dbart's assertions we are g2g for p8 mariadb?
[16:54] <lazyPower> i'm leaving in 8 minutes to head downtown
[16:55] <mbruzek> we have a meeting in 5 minutes, I could take a look after that, but I haven't touched mariadb in a while.  I was unware of the enterprise difference
[16:55] <mbruzek> I peeked at the branch yesterday.
[16:56] <lazyPower> mbruzek: its a pretty straight forward review - I gave the code a review 2 days ago.
[16:56] <lazyPower> this is mostly asserting that we're g2g for the turbolamp book
[16:56] <mbruzek> hrmm....
[16:56] <lazyPower> so we can unblock there and any "fringe" issues like tagging and what nto can be taken care of as follow up - if the installation path doesn't change
[16:56] <lazyPower> which it shouldn't
[16:56] <mbruzek> lets separate those two concerns
[16:57] <lazyPower> ack
[16:57] <lazyPower> I'm focused on clearing teh critical path first :)
[16:57] <mbruzek> understood
[16:57] <lazyPower> dbart: hi5 on your work there. Thanks for circling back so quickly
[16:57] <dbart> lazyPower: you're welcome!
[16:57] <lazyPower> dbart: i'll sync with mbruzek when i get back if you two aren't in a communication loop
[16:58] <dbart> sure thing
[16:58] <mbruzek> lazyPower: OK
[16:58] <lazyPower> mbruzek: thanks a million for taking a look
[16:58] <lazyPower> you're the best
[16:58] <lazyPower> i gotta jet gentlemen, see you shortly
[17:10] <jujuer> hazmat: no ideas? I dunno what to do, :/
[17:11] <brandonclark> I want to get the name of the attached relation for a mongodb server.  what would I use?  >>>  `relation ???`
[17:11] <hazmat> jujuer: not really, but i'm busy doing other things atm, hopefully someone else might be able to help
[17:11] <hazmat> or dig in
[17:12] <brandonclark> is there a `relation-get ` reference?
[17:16] <brandonclark> oh never mind i get it, relation-get pulls from the config.yaml
[17:17] <mbruzek> brandonclark: config-get pulls from config.yaml
[17:18] <mbruzek> brandonclark: relation-get pulls from what another charm did relation-set on
[17:21] <jujuer> have a good weekend everyone
[17:22] <brandonclark> yep thats what i meant. but there is a better way of getting the relation name i am reading on relation changes '$JUJU_REMOTE_UNIT'
[17:29] <brandonclark> good job on putting together some good usage documentation.  Nice to have it!
[17:36] <brandonclark> is it just me or is the magic key for the terminal commands slow to react? Maybe because I have it bootstrapped to a low process server?
[21:19] <whit> is there anyway for a charm to know that it's been added to machine 0? (other than sniffing around the filesystem)
[22:27] <lazyPower> o/ mbruzek
[22:27] <mbruzek> lazyPower: How was lunch?
[22:27] <lazyPower> whit: i do believe so, and its exposed in an env var i do believe
[22:27] <lazyPower> whit: otherwise, no i dont think so
[22:27] <lazyPower> mbruzek: i just got back - did you get a chance to peek at mariadb?
[22:28] <mbruzek> lazyPower:  notyet
[22:28] <lazyPower> ok, i'll take that work item and run it now that i'm back in office
[22:28] <lazyPower> ta
[22:29] <mbruzek> lazyPower: I still mean to get to it, perhaps we can pair
[22:29] <lazyPower> sounds good 2 me
[22:29] <mbruzek> but today is your swap day
[22:29] <lazyPower> i just remoted into the box
[22:29] <mbruzek> so go away!
[22:30] <lazyPower> yeah well, i just got back from running a meeting with shift interactive downtown - i've got a small business that wants juju
[22:30] <lazyPower> ;)
[22:30] <lazyPower> and... get this
[22:30] <lazyPower> its our "feature rich environment" that they are interested in
[22:30]  * lazyPower rimshots
[22:30] <mbruzek> troll
[22:30]  * mbruzek trolls his eyes
[22:30] <lazyPower> not even :D
[22:31] <lazyPower> legit, the fact they are primarily a wordpress based business, but we are giving them full stack agility is whats the real story here
[22:31] <lazyPower> there's some additional tooling I need to get built so they can run isolated environments for customers and hand those off easily - but 99% of the magic is raw juju
[22:32] <lazyPower> dbart: have you EOD'd?
[22:34] <lazyPower> mbruzek: ping when you're ready
[22:35] <mbruzek> lazyPower: Will do
[22:50] <kwmonroe> hey lazyPower mbruzek, i did the deed
[22:50] <lazyPower> kwmonroe: ?
[22:50] <kwmonroe> bundletester does the business http://paste.ubuntu.com/10097741/
[22:50] <lazyPower> kwmonroe: <3
[22:50] <lazyPower> you crack me up
[22:50] <kwmonroe> and i poked on mediawiki to verify mariadb was hooked up
[22:50] <mbruzek> kwmonroe: awesome!
[22:50] <mbruzek> Thank you!
[22:50] <kwmonroe> but i wouldn't commit that test.  it's got dbart's special sauce in it.
[22:51] <lazyPower> All thats left of this is ensuring we have a good path forward for our CI story
[22:51] <lazyPower> yeah
[22:51] <lazyPower> I think we may have to steal some mojo schenanigans to isolate the credentials
[22:51] <lazyPower> as i do believe mojo gives us some inroads to keeping credentials out of the test suite
[22:52] <kwmonroe> i do think we should switch on uname.. x86 gets comm source, ppc64le gets dbart's.  and if we do that, the test_enterprise_eval can go away.
[22:52] <lazyPower> kwmonroe: either way there's still a requirement of having that repository set of credentials around
[22:52] <kwmonroe> ack
[22:52] <lazyPower> *set of repository credentials
[22:53] <lazyPower> my english, is not so good
[22:53] <kwmonroe> yeah, i didn't read what you wrote.. just ack'd so you'd be quiet.
[22:53] <lazyPower> zing!
[22:53] <kwmonroe> Pow! (er)
[22:53] <lazyPower> You've been hanging aroudn randall too much
[22:54] <kwmonroe> he's gonna buy me a car.. so yeah.
[22:55] <mbruzek> lazyPower: no schenanigans on the tests they are fragile enough
[22:58] <lazyPower> kwmonroe: http://imgur.com/Oym36MG
[22:59] <kwmonroe> nice