[08:34] <gnuoy> jamespage, is there any harm in having two network endpoint entries one for quantum and neutron ?
[11:29] <cholcombe> launching juju local containers over crappy hotel wifi is super painful
[11:53] <tiagogomes__> Hi, does JuJu requires Cinder to be installed when bootstrapped on OpenStack when some charms define some storage requirements?
[12:01] <cholcombe> tiagogomes__, i would guess yes.  Let me have a look at the charm
[12:03] <cholcombe> tiagogomes__, what does your deploy currently look like?
[12:05] <tiagogomes__> cholcombe which deploy? JuJu? I am not trying to deploy anything yet. I am just trying to understand if Cinder is required, because for some reasons we can't have Cinder installed in our setup
[12:05] <cholcombe> tiagogomes__, i see
[12:06] <cholcombe> tiagogomes__, i'll have to defer to one of the openstack guys.  I'm not certain
[12:06] <tiagogomes__> If JuJu calls "nova attach" i would say it needs
[12:10] <tiagogomes__> but on https://jujucharms.com/docs/1.25/storage, it says persistent storage is future work.
[12:39] <jamespage> gnuoy, hey - hows it going?
[12:46] <jamespage> tiagogomes__, to use an openstack cloud using juju, you don't need cinder deployed
[12:48] <tiagogomes__> hi jamespage. Thanks. So what happens when you assign storage to a service? Or when you run "juju storage add"
[12:48] <jamespage> tiagogomes__, you won't be able to assign persistent storage to a service without cinder
[12:48] <jamespage> I suspect the command will throw an error but I don't know definatively
[12:49] <tiagogomes__> jamespage so some charms may not work if they specify storage right and there is no Cinder service right?
[12:49] <jamespage> tiagogomes__, most will default to using the root disk if storage is not explicilty configured
[12:50] <tiagogomes__> jamespage I understood that. Bu what if f storage is explicilty configured?
[12:50] <tiagogomes__> *But
[12:50] <jamespage> tiagogomes__, tbh its such a new feature I don't think you will hit that today
[12:51] <jamespage> tiagogomes__, maybe in April...
[12:51] <jamespage> but not today
[12:51] <tiagogomes__> ah, so storage functionality is new
[13:12] <gnuoy> jamespage, good, do you see my mps?
[13:14] <stub> cory_fu_, marcoceppi : And the unreadable diff of the year goes to  https://code.launchpad.net/~stub/charms/+source/postgresql/+git/postgresql/+merge/282299
[13:15] <stub> Yay git file name tracking
[13:52] <tiagogomes__> Another JuJu question, can I choose the flavor that VMs will use for JuJu bootstrapped on OpenStack
[15:40] <tiagogomes__> Hi, is it possible to run the JuJu state server on the baremetal, whilst orchestrating the services in OpenStack VMs?
[16:21] <marcoceppi> lazyPower: ping
[16:21] <marcoceppi> tiagogomes__: technically, yes
[16:21] <marcoceppi> tiagogomes__: any reason why you would want the state server on the bootstrap node and not in the cloud?
[16:22] <tiagogomes__> marcoceppi it was requested by a costumer
[16:23] <marcoceppi> tiagogomes__: so, the bare metal and the openstack cloud would need to be on the same network, or addressable, and it's really more a hack.
[16:23] <marcoceppi> tiagogomes__: not something that juju was designed to do
[16:25] <tiagogomes__> marcoceppi they will be in the same network. Is there instructions how to do so?
[16:26] <marcoceppi> tiagogomes__: no, because it's really not a supported thing
[16:26] <marcoceppi> tiagogomes__: you basically have to bootstrap the openstack cloud first, juju add-machine ssh@baremetal; juju ensure-availability --to 1; destroy machine 0 from openstack
[16:34] <tiagogomes__> marcoceppi thanks, by "bootstrap the openstack cloud first" you mean 1. deploy openstack 2. bootstrap juju on Openstack?
[16:34] <coreycb> gnuoy, tiny mp if you can take a look: https://code.launchpad.net/~corey.bryant/charm-helpers/swift-mitaka/+merge/282337
[16:37] <gnuoy> coreycb, how can 2.5.0 equate to both liberty and mitaka ?
[16:37] <coreycb> gnuoy, I originally thought that was going to be a problem but it appears not to be
[16:38] <gnuoy> coreycb, I don't understand tbh. If I look up what release 2.5.0 is won't I always get liberty returned?
[16:39] <coreycb> gnuoy, get_os_version_codename() is called with the codename (mitaka) as the first parameter, and it then loops through the SWIFT_CODENAMES looking for the 2.5.0 that has 'mitaka'
[16:40] <coreycb> gnuoy, well, sortof.  actually it just loops until it finds mitaka and returns 2.5.0
[16:41] <coreycb> gnuoy, although there's a call to SWIFT_CODENAMES[vers] elsewhere that looks like it could be an issue
[16:42] <gnuoy> yeah, I think it'll break get_os_codename_package
[16:42] <gnuoy> coreycb, ^
[16:42] <gnuoy> From what I can tell it'll always return mitaka for 2.5.0
[16:43] <coreycb> gnuoy, ok I need to figure something out for this and I"ll get back to you. thanks.
[16:44] <gnuoy> np
[17:00] <lazyPower> marcoceppi pong
[17:09] <marcoceppi> lazyPower: I have some concerns about the 'subprocess run'.split() stuff
[17:11] <lazyPower> marcoceppi: do tell
[17:12] <marcoceppi> lazyPower: https://github.com/juju-solutions/charms.docker/pull/10 if any of those parameters have a space in it, there's a potential for breakage
[17:12] <marcoceppi> while, not likely in this scenario, it's a common pattern I'm seeing and I think it has some reprocusions
[17:12] <lazyPower> marcoceppi: Aside from scrubbing the input strings, suggestions on a fix?
[17:13] <marcoceppi> lazyPower: well, don't split the string, build a list instead
[17:14] <bdx> openstack-charmers: is there a best practice for provisioning multiple availability zones using the cinder-ceph charm?
[17:15] <marcoceppi> lazyPower: http://paste.ubuntu.com/14479145/
[17:15] <marcoceppi> lazyPower: the first command creates foo\ bar the second creates foo and bar
[17:16] <lazyPower> marcoceppi https://github.com/chuckbutler/charms.docker/commit/f19a0c67d6af5c9e2644451543b32838390d52e9
[17:17] <marcoceppi> lazyPower: thanks, not to be a stickler, but there's a potential for a breakage if the password has a space
[17:17] <lazyPower> np, good catch
[17:17] <marcoceppi> lazyPower: also, there's an extra space between [ and 'docker
[17:17]  * marcoceppi analretentive mode disabled
[17:22] <lazyPower> marcoceppi updated the pr
[17:22] <lazyPower> approve when ready :)
[17:24] <bdx> openstack-charmers: I'm currently deploying 3 extra instances of cinder volume to work around being able to have different availability zones
[17:24] <bdx> http://paste.ubuntu.com/14479202/
[17:28] <bdx> openstack-charmers: by setting cinder_cross_az_attach=True, I am able to attach instances on hypervisors in an availability zone other than nova, to storage in the nova az
[17:28] <bdx> but it seems the availability zone have to exist in cinder in order for this to work
[17:29] <bdx> openstack-charmers: what I'm wondering, is, am I going about this right?
[17:31] <bdx> "seems the availability zone have to exist in cinder in order for this to work" <-- I deploy the extra cinder-vol charms to get these availability zones created
[17:31] <bdx> even though they are not 'really' used
[17:36] <bdx> openstack-charmers: these compute nodes http://paste.ubuntu.com/14479284/ cannot use cinder volumes unless they exist in cinder as well http://paste.ubuntu.com/14479280/
[17:37] <bdx> even if there is no actual storage backend in the az, they just have to exist
[18:26] <Prabakaran> Hello Team,  I am writing amulet test code for ibm-java and since it is a subordinate charm i am using ubuntu charm to test ibm-java subordinate charm.  For testing purpose i have downloaded ubuntu charm and edited metadata.yaml file and mentioned provides as "java". Here both ibm-java and ubuntu charm are connected via java interface.  Now here i want my amulet test code to pick ubuntu charm from my local location which is (/home/ch
[18:26] <Prabakaran> i want my amulet test code to pick ubuntu charm from my local location which is (/home/charm/charms/trusty/ubuntu) here i dont want ubuntu charm from charm store. How to achieve this. Could someone please help me to resolve this?
[18:30] <Prabakaran>  if i am using ubuntu charm from charm store for my amulet test while adding the relation ie. d.relate('ibm-java:java', 'ubuntu:java') i am getting relation error. Please advise.  Please find the 10-deploy.py code is http://pastebin.ubuntu.com/14479663/
[19:52] <bdx> charmers: is the packages option in reactive-base-layer usable?
[19:54] <bdx> charmers: Is this legitimate http://bazaar.launchpad.net/~jamesbeedy/charms/trusty/fiche/trunk/view/head:/layer.yaml ?
[20:09] <mbruzek> Hi James.
[20:10] <mbruzek> bdx I don't know the answer to that
[20:11] <mbruzek> bdx: cory_fu_ or one of the bigdata charmers might know
[20:15] <lazyPower> beisner ping
[20:15] <lazyPower> nvm i see you're out on teh calendar
[20:29] <bdx> mbruzek: hey, thanks for responding ... I guess I should probably ping one of the main contributers of reactive-base-layer even ..
[20:29] <bdx> marcoceppi: can you comment on ^
[20:31] <mbruzek> bdx: Yeah I took a look but I was not sure what you were doing, I saw some fixes come in for the "options"  on base layers from the bigdatacharmers, kwmonroe, cory_fu_, or others
[20:31] <mbruzek> bdx: cory_fu_ and marcoceppi are in a different timezone right now, eating dinner I believe.
[20:31] <bdx> mbruzek: gotcha, ok
[20:32] <bdx> mbruzek: I'm trying to install apt pkg deps using the basic packages option
[20:32] <bdx> mbruzek: https://github.com/juju-solutions/reactive-base-layer/blob/master/layer.yaml
[20:33] <lazyPower> wait what?
[20:33] <lazyPower> layers supports package installation?
[20:33] <lazyPower> bdx WHERE DID YOU READ THIS WIZARDRY?
[20:33] <bdx> lazyPower: https://github.com/juju-solutions/reactive-base-layer/blob/master/layer.yaml
[20:33] <mbruzek> see bdx, not everyone knows about this
[20:34] <bdx> lol
[20:34] <bdx> darn
[20:34] <mbruzek> bdx: I saw a fix come down today, from andrewmcleod.
[20:34] <mbruzek> https://github.com/juju-solutions/reactive-base-layer/issues/21
[20:34] <bdx> mbruzek: totally, I'm tracking, and up to date with that patch
[20:35] <mbruzek> bdx: check out the layer-hadoop for more information?
[20:35] <lazyPower> https://github.com/juju-solutions/layer-hadoop-client/pull/1/files
[20:35] <lazyPower> look at how nicely that cleaned up
[20:36] <lazyPower> kwmonroe nice wizarding
[20:37] <bdx> yea, been there, from what I can understand layer-hadoop had to implement the packages option
[20:37] <bdx> not use it from basic
[20:38] <bdx> mbruzek, lazyPower: is ^ consistent with your interpretation of whats going on there?
[20:38] <lazyPower> i think there's stuff still being fleshed out with it
[20:38] <lazyPower> i mean this landed yesterday
[20:38] <lazyPower> sorry 4 hours ago
[20:40] <mbruzek> bdx: I just learned about this now, so I would not trust my interpretation of the options, kwmonroe or cory_fu_ would know more.
[20:41] <mbruzek> but if what you have works, that would be awesome and I will look into this for my next charm.
[20:43] <bdx> ok, yea .... I see this (https://github.com/juju/charm-tools/issues/85) as well, the last comment makes me think that the override needs to happen bc basic packages option isn't ready yet...
[20:44] <bdx> yea, I'm pumped on it too!
[20:44] <mbruzek> bdx this looks great!
[20:46] <mbruzek> bdx: from what I read on issue 85 it looks like your layer.html is correct, but again I just learned about this today so confirm with marco, cory or ben
[20:46] <bdx> mbruzek: thanks, yea .. will do!
[20:54] <kwmonroe> hey bdx - is your layer.yaml not working, or is it overwriting other package options (the problem discussed in issue 85)?
[20:55] <bdx> kwmonroe: my install hook fails due to the packages not being installed ... http://paste.ubuntu.com/14480678/
[20:55] <bdx> kwmonroe: my layer.yaml merges fine
[20:56] <kwmonroe> fwiw, the big data charms are kinda tough to use as a reference because we used a "dist config" class that handles packages, so we're in the process of moving stuff that we used to do with our own dist logic to more generic packages stuff handled by the base layer.
[20:57] <bdx> kwmonroe: ok, entirely.
[21:03] <wesleymason> The charm I'm working on that was fine this morning is now refusing to install, dies at the initial bootstrap phase: http://pastebin.ubuntu.com/14480739/
[21:04] <bdx> wesleymason: rebuild your charm
[21:04] <wesleymason> bdx: already did, same result
[21:04] <bdx> wesleymason: it will pull in the new changes from base layer
[21:04] <bdx> should*
[21:04]  * wesleymason kills deps
[21:06] <lazyPower> yeah wheels die slowly
[21:06] <lazyPower> make sure you nuke your artifact and rebuild occasionally
[21:06] <lazyPower> its additive only, doesn't seem to remove older deps
[21:07] <wesleymason> strange, that looks like it accidentally pulled and older pre-py3 charmhelpers wheel
[21:07] <bdx> lazyPower: yea, is there a reason for that^?
[21:07] <wesleymason> as the basestring error should only happen for py2 only being run with p3
[21:07] <lazyPower> bdx removals are hard
[21:07] <kwmonroe> wesleymason: did you rebuild within the last 6 hours?  the basestring problem was fixed in https://github.com/juju-solutions/reactive-base-layer/issues/19
[21:08] <wesleymason> kwmonroe: I rebuilt, but didn't blow away everything properly, seems to have hung on
[21:08] <kwmonroe> yeah - a charm build without an rm -rf is probably not a good charm build ;)
[21:09]  * wesleymason burns everything with fire
[21:09] <kwmonroe> that's a known issue -- obsolete artifacts should be killed Real Soon Now, but my MO is to just burn it down every time.
[21:11] <kwmonroe> bdx, i'm working up a better example for pakcages in layer options (better than the big data stuff).. but i'll need about 20 more minutes.
[21:11] <wesleymason> so, while I wait for juju to bootstrap and charm to run, let me say that I'm loving the new reactive stuff 😃
[21:11] <wesleymason> Building an errbot charm with it: https://github.com/1stvamp/juju-errbot
[21:13] <kwmonroe> meanwhile bdx, if you're blocked, you can always do the old school apt-get install git in your fiche charm: https://github.com/juju-solutions/layer-ubuntu-devenv/blob/master/reactive/ubuntu-devenv.py
[21:13] <bdx> kwmonroe: yea, I just abandoned it in favor of using the layer basic packages option
[21:17] <kwmonroe> heh. understood bdx.  it's gonna be great ;)
[21:18] <bdx> kwmonroe: funny, thats what I keep saying about HA openstack service endpoints :-0
[22:02] <kwmonroe> bdx: i've tried to break this a bunch, but it Just Works.. not sure why package options in your layer.yaml aren't working.. here's my convert from an install hook to layer.yaml: https://github.com/juju-solutions/layer-ubuntu-devenv/commit/c66183ce52e9cefe188af32facf5929406aacce5
[22:03] <kwmonroe> and the resultant charm ends up installing bzr/cvs/git/svn like i want
[22:09] <kwmonroe> bdx: the only thing i can think of is perhaps your layer.yaml isn't being parsed correctly because of the lack of indetion on lines 2-3: http://bazaar.launchpad.net/~jamesbeedy/charms/trusty/fiche/trunk/view/head:/layer.yaml  shot in the dark, but maybe try indenting those?
[22:10] <bdx> kwmonroe, thats how they end up after charm generate
[22:10] <bdx> or `charm build`
[22:10] <bdx> or `charm compose`
[22:10] <kwmonroe> :)  gotcha
[22:10] <bdx> ha
[22:10] <kwmonroe> i wasn't sure how picky the yaml parser was
[22:10] <bdx> kwmonroe: do yours not end up indented like that?
[22:12] <kwmonroe> well, now i'm embarassed to say.. i was looking at the output of charm build, but yes, in fact my layer.yaml looks like this:  http://paste.ubuntu.com/14481219/
[22:12] <kwmonroe> *wasn't
[22:12] <bdx> ok
[22:13] <bdx> hmm
[22:15] <kwmonroe> bdx, can you ssh to the unit with the failed install and see if the other stuff was there?  like autoconf, make, etc?
[22:16] <bdx> kwmonroe: yea, they are not.
[22:16] <kwmonroe> bummer
[22:17] <bdx> kwmonroe: yea... cool that it works for you
[22:17] <bdx> you give me hope
[22:18] <bdx> I think there might be an issue with my layer.yaml getting parsed.... I'm thinking only the layer from nginx gets parsed
[22:21] <kwmonroe> bdx: i'm gonna try using git in my install hook.. maybe somehow the layer packages options are still being installed when the install hook is run.  i dunno, i'm grasping here.
[22:23] <bdx> kwmonroe: thanks.... I just `rm -rf`'d my trusty/fich dir and rebuilt
[22:24] <bdx> I'm hoping that does it
[22:24] <bdx> hoping that fixes*
[22:27] <bdx> kwmonroe: it worked for me
[22:28] <kwmonroe> ha!  awesome.. that's great news bdx.
[22:28] <bdx> I must of had a stale charm-tools hanging out in my wheelhouse
[22:28] <bdx> anyway
[22:28] <bdx> thanks for your help
[22:28] <bdx> and insight
[22:30] <kwmonroe> yeah sure - glad it worked.. i won't charge you for this session.
[22:31] <bdx> ha
[22:37] <marcoceppi> bdx: do you still need help?
[22:38] <marcoceppi> bdx: your layer.yaml looks good to me
[22:38] <marcoceppi> are you seeing an issue?
[22:38] <bdx> marcoceppi: I figured it out - looks like I hadn't `rm -rf`'d my trusty/fiche dir for a few builds
[22:38] <marcoceppi> bdx: ah
[22:38] <bdx> marcoceppi: I closed that issue in layer-basic ... my bad
[22:40] <marcoceppi> bdx: cool, there are some limitations, cory_fu_ and I are working on them this week
[22:40] <marcoceppi> but we're in GMT+2 for the week
[22:42] <bdx> awesome