[07:40] <gnuoy> jamespage, easy one if you have a moment: https://code.launchpad.net/~gnuoy/openstack-mojo-specs/mojo-openstack-specs-quantum-fix/+merge/291586
[08:11] <jamespage> gnuoy, ok looking now
[08:12] <jamespage> gnuoy, +1
[08:12] <gnuoy> ta
[08:12] <jamespage> gnuoy, I'd also be tempted todo Quantum/Neutron
[08:12] <jamespage> but not required - the charms still support both
[08:13] <gnuoy> jamespage, ok, I'll do that on my next pass if thats ok
[09:14] <Alex____> Hi, I have a quick question about BigData charms - there was an update announced on the list https://lists.ubuntu.com/archives/bigdata/2016-April/000068.html so my question is: if one tries `juju quickstart apache-hadoop-spark-zeppelin` does it supposed to deploy a bundle with new, layerd\renamed charms?
[09:26] <TheMue> Alex____: not yet deeply in there, but http://bigdata.juju.solutions is a good starting point. maybe you'll find your answer there
[09:29] <Alex____> Thanks! I tried :) it mentions this channel. Will try the mailing list then
[09:30] <TheMue> hehe, ok, the channel here is fine. but it's a bit early. maybe more luck later.
[09:31] <jamespage> gnuoy, amulet used deployer right?
[09:31] <gnuoy> jamespage, yes, I believe so
[09:31] <jamespage> gnuoy, OK I think the move to make our amulet tests used github is failry trivial then
[10:42] <jamespage> gnuoy, https://review.openstack.org/#/c/304482/ if you have two ticks
[13:44] <jamespage> gnuoy, nice spot on corosync - just peeking at the packages to see why that happens now
[13:44] <gnuoy> jamespage, I can't make it out atm. I checked the src package for 3.5 and the dir is still valid looking at the code and docs
[13:45] <jamespage> gnuoy, it is yes
[13:45] <jamespage> not sure why the package is not longer creating it tbh
[13:45] <jamespage> gnuoy, +1 on that
[15:09] <aisrael> stub (or anyone else), Can you spot what I'm doing wrong setting install_sources? http://pastebin.ubuntu.com/15792985/
[15:10] <lazyPower> aisrael i dont think you need the full string in there, just ppa:openjdk-r/ppa should suffice
[15:10] <aisrael> lazyPower: it's getting it to accept all three sources that seems to be the problem
[15:18] <SaMnCo-laptop> Hi there! Reformulating a question here to share info with everyone
[15:18] <SaMnCo-laptop> so essentially my problem is that I want to use a layer to create a higher level solution
[15:18] <SaMnCo-laptop> the underlying layer has configuration (config.yaml), but the default values do not fit my usecase
[15:18] <SaMnCo-laptop> so I would like to change them
[15:19] <SaMnCo-laptop> and I was wondering what would be the best practice for that
[15:22] <lazyPower> SaMnCo-laptop - Great question! So you want to change the default configuration of a lower included layer, and it doesn't make sense to use that layers provided default ever in your inheriting layer?
[15:22] <lazyPower> SaMnCo-laptop - i ask that as a bit of a leading question if it doesn't make sense to simply set that ocnfiguration option in a bundle.yaml.  If this is to provide a sane default all around - simply override the config option in your top most layers config, yaml
[15:23] <SaMnCo-laptop> lazyPower-  exactly. The example to be fully transparent is openjdk. By default it would only provide jre, and I need full (which is jdk + jre)
[15:23] <SaMnCo-laptop> well, in a bundle that would mean I lose control of the states
[15:23] <SaMnCo-laptop> plus you don't necessarily always use bundles
[15:23] <lazyPower> SaMnCo-laptop - as i understand it, there's an interface: java - which would leave all that up to the subordinate which is delivering java
[15:25] <lazyPower> in which case, overriding config in your layer doesn't make sense unless you are extending layer: openjdk, to provide a new subordinate, which should still go in a bundle.
[15:26] <SaMnCo-laptop> lazyPower-  well my initial thought was to extend openjdk yes
[15:27] <lazyPower> SaMnCo-laptop are you deleting the subordinate key in metadata to just consume the states/et-al? then yeah, just override in config and you're on your way to success
[15:27] <mbruzek> SaMnCo-laptop: kwmonroe wrote the openjdk layer, perhaps he could help with your question
[15:27] <SaMnCo-laptop> ah I can do that?
[15:27] <SaMnCo-laptop> interesting
[15:28] <SaMnCo-laptop> Yeah, I'll also connect with Kevin to fully understand best practice here, but this isn't the first time I sort of get into "how can I change the config values from higher layer charms"
[15:28] <lazyPower> SaMnCo-laptop - yep, in layer.yaml you can trim keys out of lower layers config and metadata.
[15:28] <SaMnCo-laptop> since there are also the layer options that can be tweaked
[15:29] <SaMnCo-laptop> ah so in layer.yaml, what I am  changing is actually the config.yaml options from lower layers
[15:29] <SaMnCo-laptop> that's what I wanted to nail
[15:29] <mbruzek> Yes think of layer options as build time configuration, but config as user level runtime config
[15:29] <lazyPower> well, yes and no SaMnCo-laptop
[15:29] <SaMnCo-laptop> Shrödinger config option
[15:29] <SaMnCo-laptop> now let me open the box :P
[15:30] <lazyPower> SaMnCo-laptop https://jujucharms.com/docs/devel/reference-layer-yaml#yaml-modifications
[15:31] <lazyPower> SaMnCo-laptop so dont confuse that with the options declared in layer.yaml - which as mbruzek  stated are build time constructs, or immutable options that are only exposed at build time
[15:32] <SaMnCo-laptop> never the less, this is good and what I was looking for
[15:32] <SaMnCo-laptop> I don't know why I missed that
[15:32] <lazyPower> happy to help :) o/
[15:33] <SaMnCo-laptop> thx buddy!
[15:42] <marcoceppi> jcastro: have you updated to lxd 2.0.0 from xenial yet?
[15:53] <SaMnCo-laptop> lazyPower-  So something is still unclear in that link
[15:53] <SaMnCo-laptop> I can delete keys from config, that is great
[15:54] <SaMnCo-laptop> but how do I set them for the underlying layer?
[15:54] <SaMnCo-laptop> like if I delete the java version it's great, less to think about at deploy time, but I would still need to pick one of the avialable options in my code;
[15:55] <SaMnCo-laptop> in that case, should I delete and recreate the same option in the new config.yaml?
[15:55] <SaMnCo-laptop> from the upper layer?
[15:55] <lazyPower> SaMnCo-laptop you dont need to implicitly delete, layers by default override anything declared further below
[15:55] <lazyPower> config.yaml keys get merged, top most layer wins, so if you declare in config.yaml your overriding config option, it will 'just work' for this usecase
[15:55] <SaMnCo-laptop> ok so in my case I am just resetting the value in my upper layer
[15:56] <SaMnCo-laptop> ok cool
[15:56] <SaMnCo-laptop> useful
[15:56] <SaMnCo-laptop> thanks
[15:58] <cmars> charm-tools just upgraded and i got this: https://paste.ubuntu.com/15794377/
[15:58] <cmars> i'm on xenial
[15:58] <gnuoy> tinwood, didn't you see something like ^ ?
[15:59] <rick_h_> marcoceppi: I thought that was corrected a while back when this got packaged? ^
[15:59] <tinwood> cmars, gnuoy: yes, marcoceppi has fixed this and it's going into the ppa as we speak.
[15:59] <marcoceppi> cmars rick_h_ it's a known issue, it's because of amulet in stable ppa
[15:59] <rick_h_> marcoceppi: ah gotcha
[16:00] <marcoceppi> cmars: just pushed a fix to the ppa, and backporting the now stable charm-tools and charm from xenial to trusty/wily in the ppa
[16:00] <jcastro> marcoceppi: I can, I'm a day behind
[16:00] <marcoceppi> jcastro: it'll break networking, as an fyi
[16:00] <marcoceppi> jcastro: you'll have to run a thing as a heads up
[16:01] <jcastro> ok
[16:01] <magicaltrout> what have i ballsed up this time
[16:01] <magicaltrout> I thought you set your review queue issue to new to get it back in the queue?
[16:01] <marcoceppi> magicaltrout: yes
[16:01] <magicaltrout> well i set it to new 23 hours ago
[16:02] <magicaltrout> the last thing in the queue was 2 days ago
[16:02]  * marcoceppi checks this bloody old review queue
[16:02] <magicaltrout> the review queue is about as stable as XWindows when I unplug my displaylink adapter
[16:03] <marcoceppi> magicaltrout: in so many words, yes
[16:04] <marcoceppi> magicaltrout: we've got a /so much better instant updated review queue/ on it's way, we hope to have a public beta in the next week or two
[16:05] <marcoceppi> magicaltrout: I've kicked, sharply, it'll take an hour or so to work through the backlog and you'll find your review in there
[16:05] <magicaltrout> thanks marcoceppi no problem
[16:15] <bdx> charmers: can someone point me to an example of how to bootstrap an openstack cloud using juju2?
[16:17] <marcoceppi> bdx: the release notes is the best place at the moment, let me dig
[16:20] <bdx> marcoceppi: thanks. I think I'm close ...
[16:20] <lazyPower> cory_fu http://paste.ubuntu.com/15795105/ - have you seen this? I'm getting this on a xenial deployed host
[16:21] <bdx> marcoceppi: clouds.yaml -> http://paste.ubuntu.com/15795119/, credentials.yaml -> http://paste.ubuntu.com/15795152/
[16:21] <cory_fu> lazyPower: No, but I'd check `env` for some strange LC settings
[16:22] <lazyPower> cory_fu - this seems to go deeper, http://paste.ubuntu.com/15795170/
[16:22] <lazyPower> so id ont think its base layer related, looks like poss an image issue?
[16:22] <marcoceppi> bdx: that looks right
[16:22] <bdx> marcoceppi: I feel like I need to add a bunch of other configs like `image-stream`, `image-metadata-url` .... should these go in clouds.yaml ?
[16:24] <marcoceppi> bdx: don't you have to add an endpoint to the region?
[16:24] <marcoceppi>           regions:
[16:24] <marcoceppi>              RegionOne:
[16:24] <marcoceppi>                 endpoint: http://<whatever>/1.0
[16:25] <bdx> marcoceppi: so ... exactly .... here is what I get when trying to bootstrap -> http://paste.ubuntu.com/15795224/
[16:25] <marcoceppi> bdx: IIRC, it should just look up image information from the provider
[16:25] <cory_fu> lazyPower: I'm in a meeting right now, so I'm not going to be of much help.  Maybe tvansteenburgh can offer some insight
[16:25] <marcoceppi> bdx: you're going to hvae to forgive me, I know this is a silly question, but you're def just censoring the ip address for privacy, right?
[16:26] <bdx> marcoceppi: yea
[16:26] <marcoceppi> bdx: cool, just wanted to double check
[16:26] <lazyPower> cory_fu - we have an update, there's a package missing on xenial and debug-hooks gave us some insight when properly trapped
[16:26] <marcoceppi> bdx: is RegionOne a valid name in the openstack?
[16:26] <bdx> marcoceppi: yes
[16:27] <marcoceppi> hum, bdx I'm not sure, rick_h_ do you know who can help with the new openstack cloud/credentials setup?
[16:27] <bdx> marcoceppi: so, basically I am specifying the endpoint in the wrong section of clouds.yaml?
[16:27] <marcoceppi> bdx: well, each region should have it's own endpoint, right?
[16:27] <jrwren> bdx: sounds like your novarc wasn't sourced.
[16:28] <jrwren> bdx: oh, nevermind. I read up now. i'm wrong.
[16:28] <marcoceppi> bdx: could you move endpoint as a key under RegionOne?
[16:29] <rick_h_> bdx: so the config is passed in the --config=yaml or --config key=value to the bootstrap command
[16:30] <bdx> rick_h_: yeah ... yeah possibly I need to be specifying the credentials.yaml when I bootstrap?
[16:31] <bdx> marcoceppi: I'll try that now
[16:31] <rick_h_> bdx: sorry, otp and tring to multi-task
[16:31] <lazyPower> rick_h_ - is that how we flip amazon image stream from release to daily?
[16:31] <bdx> np
[16:31] <lazyPower> rick_h_ juju bootstrap --config image-streams='daily' or somesuch?
[16:31] <rick_h_> lazyPower: yes, any config that was in the env.yaml file is moved to the --config or key=value args on bootstrap of the controller
[16:32]  * rick_h_ pulls up release notes for that section
[16:32] <rick_h_> lazyPower: bdx the idea is clouds never change really, but how you bootstrap to them might. So that config isn't in the cloud as you could bootstrap with and without daily streams/etc
[16:33] <lazyPower> rick_h_ - solid, thanks :) you just unblocked mbruzek and I
[16:33] <bdx> rick_h_: ok, so I must pass key=value params when bootstrap openstack cloud?
[16:33] <rick_h_> bdx: or a --config something.yaml
[16:34] <rick_h_> bdx: see the section "#### Model Configuration at Bootstrap
[16:34] <bdx> rick_h_: alongside --config credentials.yaml ?
[16:34] <rick_h_> bdx: in https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U/edit#
[16:35] <bdx> marcoceppi: using ->  http://paste.ubuntu.com/15795504/ I get the same error
[16:36] <bdx> http://paste.ubuntu.com/15795520/
[16:36] <bdx> ok, I think credentials.yaml is automatically being picked up
[16:36] <bdx> so I probably don't need to specify it...
[16:36] <bdx> hmmm
[16:40] <marcoceppi> bdx: right, it will be
[16:40] <marcoceppi> bdx: ERROR index file has no data for cloud
[16:40] <rick_h_> bdx: no, credentials.yaml are added through add-credential
[16:40] <marcoceppi> index file is interesting
[16:40] <marcoceppi> I wonder if that refers to the index file for images
[16:40] <rick_h_> bdx: right, it'll grab the default for the cloud if you've added them
[16:41] <rick_h_> marcoceppi: I bet
[16:41] <marcoceppi> rick_h_: no --debug flag for bootstrap anymore?
[16:41] <rick_h_> marcoceppi: :/ ummm, didn't realize that
[16:41] <bdx> marcoceppi: yeah, it wants an image streams location e.g. somewhere where the index.json references an image id from my cloud ....
[16:42] <marcoceppi> rick_h_: not showing in `juju help bootstrap`
[16:42] <rick_h_> marcoceppi: yea, noticing that
[16:42] <marcoceppi> bdx: can you try with the --debug flag anyways on bootstrap? that might help lock down a location
[16:42] <marcoceppi> rick_h_: hoepfully it's just a silent flag
[16:42] <rick_h_> marcoceppi: want to test it out, I don't know why it'd be removed
[16:42] <rick_h_> marcoceppi: yea, exactly
[16:42] <bdx> marcoceppi, rick_h_: which I have setup, I just don't know how to specify it as config ....
[16:43] <marcoceppi> bdx: ahhh, okay, this probably lives in the clouds.yaml
[16:43] <rick_h_> marcoceppi: bdx yes, that seems like it's common to any bootstrap and part of talking to OS
[16:43] <rick_h_> marcoceppi: bdx I'd expect that to be in the clouds.yaml info
[16:43] <marcoceppi> bdx: you should be able to put them as parent keys at the same level as regions as the same key name that was in the old environments.yaml
[16:44] <bdx> marcoceppi: ok, trying now
[16:44] <rick_h_> beisner: do you have a sample juju 2 clouds.yaml for openstack around?
[16:46] <bdx> rick_h_, marcoceppi: http://paste.ubuntu.com/15795783/
[16:46] <bdx> gives the same index file error
[16:47] <marcoceppi> butts, hopefully beisner knows, if not I'll go pok some other people
[16:48] <bdx> marcoceppi, rick_h_: sweet, thanks
[16:48] <rick_h_> bdx: what's the exact error?
[16:48]  * rick_h_ goes to look at the source for the openstack config
[16:48] <bdx> http://paste.ubuntu.com/15795844/
[16:50] <bdx> rick_h_, marcoceppi: some concrete docs on how to bootstrap an openstack cloud using juju2 would be a huge win
[16:50] <rick_h_> bdx: +1
[16:52] <rick_h_> bdx: https://jujucharms.com/docs/devel/clouds#specifying-additional-cloud
[16:54] <marcoceppi> rick_h_: yeah, looks like we need to expand these a bit
[16:54] <marcoceppi> as soon as we figure this out bdx, I'll be opening a merge to update them
[16:54] <rick_h_> bdx: looking at that can you try https://pastebin.canonical.com/154062/ please?
[16:55] <rick_h_> marcoceppi: yea, I know I got a working copy from sinzui at one point in the past but can't find the link
[16:55] <bdx> ok, yea, omp
[16:55] <jhobbs> :q
[16:55] <jhobbs> oops
[16:56] <bdx> rick_h_: I haven't permission to access either of the links you have pasted me
[16:56] <rick_h_> bdx: ah sorry
[16:56] <marcoceppi> bdx: http://paste.ubuntu.com/15796065/
[16:56] <bdx> I'm not that cool man
[16:56] <bdx> awesome
[16:56] <rick_h_> http://paste.ubuntu.com/15796067/
[16:56] <rick_h_> bdx: ^
[16:56] <rick_h_> sorry, autocomplete fail
[16:57] <jrwren> bdx: I dont know as much as these guys about juju2, but it seems to me you need to fill in that <keystone-ip> with your keystone IP.
[16:57] <bdx> rick_h_, marcoceppi: I get the same error
[16:57] <bdx> jrwren: tracking
[16:57] <rick_h_> bdx: ok, and you've gone through https://jujucharms.com/docs/master/howto-privatecloud ?
[16:58] <bdx> yeah, I have juju1 controllers bootstrapped all over the place using my local image and tools streams
[16:58] <rick_h_> bdx: ah ok
[16:59] <bdx> seeing as the error is referencing `index` file .... I'm inclined to think the heart of this issue revolves around juju not knowing the location of my tools/metadata
[17:00] <marcoceppi> bdx: it's a good guess
[17:05] <rick_h_> bdx: http://paste.ubuntu.com/15796290/ is what I got from sinzui
[17:07] <bdx> rick_h_: that is the same thing I have going on .... how is he specifying his image-stream/image-metadata-url ?
[17:07] <bdx> those are required params yea?
[17:07] <rick_h_> bdx: I don't think so if it's standard location
[17:08] <bdx> rick_h_: standard location?
[17:08] <bdx> rick_h_: simplestreams tools and metadata
[17:09] <bdx> rick_h_: tools and metadata must be generated on a per cloud basis ....
[17:09] <rick_h_> bdx: right, but I *think* they're in a specific key in keystone
[17:12] <bdx> rick_h_: ehh, a user would define a custom location to where there per cloud generated tools and metadata are ... because there is no generic location ... because they must be generated per an image id  that exists in your cloud right?
[17:17] <bdx> their*
[17:37] <marcoceppi> cmars tinwood rick_h_ amulet - 1.14.2-0ubuntu4 fixes the python-path dep issue, charm-tools, amulet, and all are co-installable again
[17:38] <marcoceppi> urulama rick_h_ charm and charm-tools landed in xenial last night \o/ I'm drafting up the release announcement now to the list. they've already been backported to the stable ppa for trusty and wily
[17:43] <cmars> marcoceppi, thanks! updating now
[17:45] <stub> aisrael: It needs to be a yaml list encoded as a string, Because you don't have line breaks or indentation in there, it isn't a yaml list but a yaml string. Try setting it to install_sources="['sourcea', 'sourceb']"
[17:46] <bdx> charmers, marcoceppi, rick_h_, stub: I just pm'd stub with this, thought I would paste this here instead of retyping it so others can see -> http://paste.ubuntu.com/15797232/
[17:48] <skaul> hi, I have a doubt for charming a product which does not support silent way of installation and user has to provide input through the command line. How can we charm such types of products where silent mode of installation is not present.
[17:49] <marcoceppi> skaul: well, you could have the user provide that information via the configuration for the charm, then when all is collected execute the installation prefilling the prompts either via flags on the command or creating an expect script that answers the prompts
[17:50] <stub> bdx: I don't know sorry. I've only used Swift, and even then only with credentials provided by others.
[17:51] <bdx> stub: using db's > 30GB ?
[17:52] <stub> No
[17:52] <bdx> jesus
[17:52] <bdx> ok
[17:53] <bdx> well thanks for writing such an awesome charm
[17:53] <stub> wal-e can do it. I don't know how to tell ceph to give you a large quota
[17:53] <bdx> its not ceph
[17:53] <skaul> the user input provided via the command line has to be read by our juju script which we are writing to automate, through expect script we can get all this user responses and provide it to our install script?
[17:53] <bdx> stub: http://docs.openstack.org/liberty/config-reference/content/object-storage-account-quotas.html
[17:55] <bdx> stub: I feel this `accout quota` data is stored in one of the .rgw buckets
[17:55] <bdx> `account quota`
[17:55] <bdx> or possibly in .users.swift
[17:56] <stub> No idea. I do know I've stuffed over 16TB in swift using other tools, just not wal-e.
[17:56] <bdx> I have spent a good amount of time trying to figure this out, although I'm getting time boxed by higher ups and am going to have to focus on other things atm
[17:57] <bdx> hopefully I have aired this out well enough that others might look into it
[17:59] <marcoceppi> skaul: you can have the user fill in this information via the config.yaml file. So you say essentially declare these are the configuration options I need YOU the user to provide, they provide that, once you have it all collected ten you can run the setup script
[17:59] <stub> bdx: You might need to air it out in openstack or swift channel, unless one of the openstack charmers here happens to know.
[18:00] <bdx> stub: yea ...shoot ... this is not an issue when using swift backend
[18:01] <bdx> stub: and radosgw isn't an `openstack` project
[18:01] <bdx> lol
[18:03] <skaul> ok, thanks
[18:03] <bdx> stub: thanks, I'll poke around it the ceph chanels, but radosgw is really a grey area openstack service I feel like
[18:06] <bdx> people who are using ceph alongside/underneath their openstack (the majority) aren't going to want to provision a swift solution too
[18:10] <cory_fu> kwmonroe, admcleod-: New charms.reactive released with the fix for the str.pop bug
[18:17] <kwmonroe> +1 cory_fu!  thx
[18:35] <cmars> ok, i've upgraded charm-tools, now I'm getting this issue with `charm build`: https://paste.ubuntu.com/15798307/
[18:36] <cmars> should i open a bug?
[18:36] <rick_h_> lol, "otherstuf"?
[18:36] <tvansteenburgh> marcoceppi: ^
[18:37] <cmars> https://i.imgur.com/HvMP3pE.jpg
[18:37] <marcoceppi> cmars: do you have python-otherstuf instlaled?
[18:37] <cmars> marcoceppi, probably not
[18:37] <marcoceppi> cmars: you should have gotten it
[18:38] <cmars> marcoceppi, nope, it wasn't installed. missing a dependency in the deb?
[18:38] <marcoceppi> cmars: it looks like, eek, how did this happen
[18:38] <cmars> lol, python-stuf and python-otherstuf
[18:39] <marcoceppi> cmars: yeah, it's stupid. /me glares at whoever committed that into the project
[18:39] <cmars> stuf is the new utils
[18:41] <cmars> oh snap, now i'm missing pathspec: https://paste.ubuntu.com/15798416/
[18:41] <cmars> and ruamel.yaml
[18:41] <marcoceppi> cmars: O_O python-pathspec python-ruamel.yaml
[18:42] <marcoceppi> cmars: I have no idea how this broke from devel ppa to archive
[18:42] <cmars> marcoceppi, ok that's all that was missing. my mattermost layer is now happy again :)
[18:43] <marcoceppi> cmars: dang dude, thanks for pushing through, I'll have a new package ready for update to xenial with these added
[18:43] <cmars> marcoceppi, no worries, that's why i run xenial and run this stuff everyday :)
[19:20] <tinwood> thanks marcoceppi