[00:07] <thomi> Hi all, is anyone able to help me parse this log message please? "unit spi-mongodb/1 cannot get assigned machine: unit "spi-mongodb/1" is not assigned to a machine"
[00:07] <thomi> it's the last 'ERROR' in a failing deployment, and I have zero clue what that means
[00:07] <thomi> In fact, it seems paradoxical to me...
[01:39] <lazyPower> thomi: thats interesting, i only see that during the first steps of deployment
[01:40] <lazyPower> i think its related to the agent deployment but i'm not entirely sure
[01:40] <thomi> hmmm
[01:40] <lazyPower> thomi: however its not critical, and i never see it again once the agent is up and running
[01:40] <lazyPower> is this a manual provider environment?
[01:40] <thomi> lazyPower: no, local
[01:40] <lazyPower> which juju version? I assume this is 1.24.3 the current -stable release?
[01:41] <thomi> 1.24.2
[01:41] <thomi> which is the latest in vivid... unless a new release came out this week?
[01:41] <lazyPower> 1.24.4 was released this week actually
[01:42] <thomi> ahh, ok
[01:42] <thomi> I'll upgrade and retry :D
[01:42] <thomi> It's all complicated by the fact that I'm also using mojo and therefore juju-deployer
[01:42] <lazyPower> thomi: another question, have you tried deploying something "simple" like the ubuntu charm to verify the local provider is indeed working?
[01:42] <thomi> so I have three places to look for errors :D
[01:43] <thomi> lazyPower: yes - by the time it errors I've already deployed apache, haproxy and a few other things
[01:43] <lazyPower> ok, well thats promising that its not a full scale local provider issue
[01:43] <lazyPower> should narrow things down a bit when debugging anyway
[01:43] <thomi> hmmm, I'm not seeing a new juju in vivid?
[01:43] <lazyPower> interesting, i wonder if vivid packages weren't published yet, i just got 1.24.4 today on trusty
[01:44] <lazyPower> seems that its in the ppa
[01:44] <lazyPower> https://launchpad.net/~juju/+archive/ubuntu/stable
[01:45] <thomi> hmmm
[01:45] <lazyPower> ah, i mis-spoke. 14.10.1 has 1.24.2-0
[01:46] <lazyPower> thomi: but if you're on vivid, 15.04 - you should have 1.24.4 available to you.. the 1.24.2 is for utopic(?)
[01:47] <thomi> apt-cache policy says 1.22.1 is all that's in the archive.
[01:47] <thomi> I could add the PPA and get it
[01:47] <thomi> I'm just wondering if that's going to break anything else
[01:55] <thomi> lazyPower: who should I talk to about juju-deployer?
[01:55] <lazyPower> thomi: our devx team currently maintains juju-deployer. tvansteenburgh (out on vaca) and marcoceppi are 2 good resources
[01:56] <thomi> thanks. I guess it's a bit late for marcoceppi :D
[01:59] <crab> hi.
[02:18] <lazyPower> hello crab
[02:18] <lazyPower> thomi: it is, its 10:20 here
[02:18] <lazyPower> however to be fair, you never know when he's lurking about
[02:22] <marcoceppi> thomi: hello o/
[02:22] <lazyPower> speak of the force of nature
[02:28] <marcoceppi> thomi: is spi-mongodb a subordinate?
[02:38] <pmatulis> should bugs be filed on github or launchpad?
[02:38] <pmatulis> i see tracking on both sites
[02:38] <lazyPower> pmatulis: Launchpad is the preferred location
[02:39] <pmatulis> lazyPower: ok, but why 2 trackers?
[02:39] <lazyPower> Good question, there was an open discussion about it on the list last year and it was decided to not have an issue tracker on github. I'm not sure why that was overturned. It may be to reduce the barrier to entry for bug contributors that are not on launchpad
[02:40] <pmatulis> lazyPower: awfully confusing and inefficient
[02:40] <marcoceppi> pmatulis: bugs are tracked on launchpad for juju, all project management is done there
[02:41] <pmatulis> marcoceppi: alright. maybe we should shut down the github tracker then
[02:41] <marcoceppi> pmatulis: we probably should
[02:41] <marcoceppi> pmatulis: I'd email juju-dev@lists.ubuntu.com to start that discussion
[02:42] <pmatulis> marcoceppi: alright, thanks for clarifying
[02:55] <thomi> marcoceppi: sorry, was AFK. Are you still here?
[02:55] <marcoceppi> thomi: yup
[02:56] <thomi> marcoceppi: I'm seeing juju-deployer errors like: http://pastebin.ubuntu.com/12058570/ when I run my mojo spec
[02:56] <thomi> marcoceppi: most of those ERROR lines occur even on a successful run
[02:56] <thomi> but the 'Unknown error' doesn't
[02:56] <thomi> any ideas what could be happening?
[02:57] <marcoceppi> what version of deplyer?
[02:57] <marcoceppi> thomi: also, it appears that deployer is having a hard time parsing your bundle
[02:57] <thomi> marcoceppi: 0.5.1-3
[02:57] <marcoceppi> thomi: cool, that's latest
[02:57] <marcoceppi> thomi: do you have the bundle? could you pastebin that?
[02:58] <thomi> marcoceppi: by 'bundle' you mean the yaml files?
[02:58] <marcoceppi> yes
[02:58] <thomi> sure, one second..
[02:59] <thomi> marcoceppi: there's two files: http://paste.ubuntu.com/12059115/ and http://paste.ubuntu.com/12059114/
[03:00] <marcoceppi> thomi: okay, so it lists charm, I'm not 100% sure on mojo stuff, but are those "charms" in a local directory somewhere? It's trying to parse the charm URL for those and it's failing
[03:00] <marcoceppi> it expects a protocol like cs:<series>/<charm>
[03:00] <marcoceppi> or local:<series/<charm>
[03:00] <marcoceppi> or instead of a charm key, a branch key with a bzr branch
[03:01] <thomi> marcoceppi: I think that's a red herring - mojo builds the charm repo, and those ERROR messages about missing charms happen even for successful runs
[03:01] <marcoceppi> thomi: then your next error is "deployer.deploy: Invalid config charm result-enum-worker nagios_context=None"
[03:02] <marcoceppi> does the result-enum-worker charm have a nagios_context configuration option?
[03:02] <marcoceppi> You may also want to try setting it to ""
[03:02] <thomi> I'm 90% sure... just double checking
[03:03] <thomi> marcoceppi: ugh... that'd be it... now I feel silly :D
[03:03] <thomi> marcoceppi: the change to the charm didn't land yet it seems.
[03:04] <marcoceppi> I feel like I should dig into mojo more, those charm/branch errors seem so...weird
[03:04] <thomi> marcoceppi: I will buy you many $(beverage_of_choice) if it means juju and mojo devs start talking to each other
[03:04] <thomi> I'm not even joking. SO MANY BEERS.
[03:05] <marcoceppi> thomi: so, on the devx team we have dedicated time to work on tooling each week (amulet, deployer, charm-tools, etc) we may take one of these slots to just get a bunch of info about how mojo is using deployer and see if we can make it happier
[03:06] <marcoceppi> thomi: we just landed something that might be useful for mojo, where charm: can now be an absolute path to a charm directory on disk, may help streamline some of what mojo is trying to do
[03:07] <thomi> marcoceppi: that sounds good. It seems like there's lots of places where mojo & juju could work better together
[03:12] <thomi> marcoceppi: if you're still around: What's the best way to make your team aware of  such issues? Perhaps there's a bug tag to use, or something? a mailing list, or...?
[03:13] <marcoceppi> thomi: if you want to tag bugs with mojo on lp:juju-deployer (or any project) we can use that for filtering
[03:14] <thomi> marcoceppi: will do - thanks
[03:14] <lazyPower> marcoceppi: did you know juju-reboot existed?
[03:14] <marcoceppi> lazyPower: yes, it came into existance because of windows charms
[03:15] <marcoceppi> lazyPower: I troll juju help-tool a lot to keep up to date with new stuff landing in hookenv
[03:15] <lazyPower> man, thats awesome. I just discovered it tonight poking around in the tools dir
[03:15] <lazyPower> i'm working off the feat-proc-mgmt branch and finding out whats impl and whats pending - ran across that nugget of goodness
[04:08] <thomi> Is there a way I can get juju to show me all the relations that a deployed charm supports?
[04:08] <thomi> 'juju stat' seems to only show me relations that are actually connected to something
[04:09] <thomi> I guess I want a 'juju list-relation'
[08:30] <Tribaal> Hi all. The ingestion queue for the charm store seems to be incredibly slow. I've been waiting for my branch to be ingested for hours... Can somebody have a look?
[09:29] <jamespage> gnuoy, https://code.launchpad.net/~james-page/charm-helpers/liberty-versioning/+merge/264998
[09:30] <jamespage> that's the other ch bit for liberty version detection
[09:54] <gnuoy> jamespage, merged
[09:55] <gnuoy> jamespage, https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-api/vpp/+merge/263224 for the neutron-api changes
[10:10] <jamespage> gnuoy, one niggle
[10:10] <gnuoy> hit me
[10:11] <gnuoy> oh, I see, you have. ta
[10:14] <gnuoy> jamespage, fixed
[10:16] <jamespage> gnuoy, http://paste.ubuntu.com/12060702/
[10:16] <jamespage> just noticed that
[10:16] <gnuoy> argh, on it
[10:18] <gnuoy> jamespage, fixed
[10:19] <jamespage> gnuoy, +1
[10:19] <gnuoy> \o/
[10:19] <gnuoy> thanks
[10:19] <jamespage> I'll asume the lint will pass now :-)
[10:19] <gnuoy> defo
[11:48] <g3naro> anyone familiar with aws ?
[11:53] <marcoceppi> g3naro: as familiar as the next person
[12:08] <g3naro> marcoceppi: elastic-beanstalk
[13:58] <g3naro> jooojooo
[14:21] <Bigdeal> Newbie seeking help on JUJU: ssl when connecting to openstack
[14:33] <Bigdeal> newbie question, problem bootstraping juju with openstack due to ssl error
[14:34] <Bigdeal> How can I foce juju to accept a self sign cert
[14:37] <jose> Bigdeal: there are no newbie questions at all :) someone should be around soon to give you a hand, I need to leave
[14:37] <Bigdeal> Jose: Thanks
[14:38] <jose> Bigdeal: what juju version are you using? (juju version gives you that)
[14:38] <Bigdeal> Jose: 1.24.4-trusty-amd64
[14:39] <jose> huh, I see a bug but it was fixed on 1.15+... let's wait for someone else to check on that :)
[14:39] <Bigdeal> Jose: I ran the quickstart -i
[14:40] <Bigdeal> used ssl-hostname-verification : false
[14:58] <hatch> I have a config field for a 'secret' this secret can be any series of characters but it fails if it is all numbers because juju says the types don't match...quoting the value solves the problem but that's not going to be very user friendly as I have to strip the quotes off if they exist (and aren't part of the actual secret string) and the user has to know to quote it...are there any other workarounds for this?
[14:58] <ddellav> Bigdeal, whats the exact error you are getting? and is it during the bootstrap process or is it in a browser we trying to access juju-gui/horizon dashboard?
[15:03] <Bigdeal> this is during the bootstrap process
[15:04] <Bigdeal> ddellav: I used quickstart -i then filled in the parameters for my openstack env.
[15:05] <ddellav> ok, can you paste me the error output? You can use http://paste.ubuntu.com
[15:15] <ddellav> hatch, as far as i know right now we only support integer, string, and boolean types for config valus.
[15:15] <ddellav> *values
[15:15] <Bigdeal> ddellav:
[15:15] <Bigdeal> ERROR there was an issue examining the environment: authentication failed.
[15:15] <zeron> ddellav: sorry for the delay, Bigdeal is currently at a meeting, he will revert to you as soon as he comes out of it. thanks.
[15:15] <ddellav> if it's a string value (meaning quoted) then you can put whatever you want in there and you shouldn't have to remove the quotes when retrieving it later (though Im not 100% sure about this)
[15:15] <hatch> ddellav, yeah, is there maybe a way to make the yaml field a 'string' without quotes?
[15:16] <hatch> yeah this is kind of an edge case bug....because it's a secret it can be anything, (the user, or I have control over this secret value)
[15:16] <ddellav> hatch, not that I know of but there may be something in the YAML spec that allows for it, I'd have to look it up. Something like heredoc syntax.
[15:17] <ddellav> zeron, no problem :)
[15:17] <ddellav> Bigdeal, have you tried setting ssl-hostname-verification to true?
[15:18] <hatch> ddellav alright np thanks, I'll keep looking
[15:20] <ddellav> also Bigdeal what provider are you using?
[15:20] <ddellav> (maas, aws, azure)?
[15:22] <Bigdeal> ddellav: I am pointing to my own Openstack environement
[15:25] <ddellav> Bigdeal, so you are using your own openstack environment as the provider?
[15:27] <Bigdeal> ddellav: I am pointing to my own Openstack environement as the provider, my environement uses selfsigned certs
[15:38] <ddellav> ok, i'm not quite sure what that could be and I can't find any relevant information on ssl issues when deploying juju on top of openstack. Perhaps lazyPower or beisner have some ideas?
[15:46] <Bigdeal> ddellav: would ssl-hostname-verification=false help?
[15:46] <Bigdeal> but I am not sure where it should go
[15:48] <ddellav> Bigdeal, that would go into your environments.yaml file
[15:49] <ddellav> https://jujucharms.com/docs/devel/config-general#alphabetical-list-of-general-configuration-values
[15:49] <Bigdeal> can you please tell me the path of the file?
[15:49] <ddellav> that's usually in ~/.juju/envionments.yaml
[15:50] <ddellav> *environments.yam
[15:50] <ddellav> ugh.. new keyboard, still breaking it in :(
[15:51] <g3naro> mechanical ?
[15:52] <lazyPower> Bigdeal: that would be a sub-key of your openstack provider environment defined in $HOME/.juju/environments.yaml
[15:53] <Bigdeal> my file is empty
[15:53] <ddellav> g3naro, yea, razer blackwidow chroma
[15:53] <lazyPower> Bigdeal: are you using encrypted homedir?
[15:53] <ddellav> Bigdeal, when using openstack provider you might want to read this: https://jujucharms.com/docs/devel/config-openstack
[15:56] <Bigdeal> lazyPower: not sure abour home dir
[15:56] <g3naro> ddellav:  nice one
[15:57] <g3naro> ive got corsair k70
[15:57] <g3naro> i tried them all
[16:05] <Bigdeal> I added the line and still getting  error: Bootstrap failed, cleaning up the environment.
[16:05] <Bigdeal> ERROR there was an issue examining the environment: authentication failed.
[16:08] <plars> I have some services that I want to deploy to lxc under maas. I'm using juju-deployer to deploy a empty ubuntu charm named something like service-host, and the rest with to: lxc:service-host
[16:08] <plars> but one of the things my service needs to do requires some changes to the default lxc apparmor template
[16:09] <plars> is there some way to pre-configure this when I deploy? or do I have to deploy some decoy to lxc, go modify the template by hand, and destroy the decoy?
[16:09] <plars> It's /var/lib/lxc/juju-trusty-lxc-template/config that I need to edit, but that doesn't seem to exist until I actually deploy something to:lxc:foo
[16:11] <lazyPower> plars: right, thats the chicken/egg of lxc configuration. What you can do, is deploy a subordinate that modifies that template and use juju-reboot to reboot the host.
[16:11] <lazyPower> plars: i ran into that when working w/ the fan and wanting to fully automate the fan networking setup
[16:14] <plars> lazyPower: I'm not sure I follow... how does a subordinate help unless you've already deployed something to an lxc container on the host?
[16:15] <plars> lazyPower: oh... I think I get it, you deploy everything, then the subordinate gets deployed, modifies the config, and reboots the host (eventually causing all the lxc instances to get restarted)
[16:15] <lazyPower> yep
[16:15] <plars> lazyPower: but is there some way to ensure that it doesn't reboot the host until after the lxc instances are finished deploying?
[16:15] <lazyPower> its not ideal as instances will reach error state, but on reboot they should re-execute and resolve themselves.
[16:15] <plars> ok
[16:16] <lazyPower> there is not, as there's no garantee that no hook is firing
[16:16] <lazyPower> juju-reboot will do its best to stop the containers then reboot the host
[16:16] <plars> lazyPower: I'll give it a try, thanks
[18:26] <Bigdeal> still stuck on the ssl issue
[18:27] <Bigdeal> my juju fesh install cant connect to my openstack private cloud, I get an authentication issue that is due to selfsigned certs
[18:59] <lazyPower> beisner: do you have any experience with openstack and selfsigned certs for auth?
[18:59] <lazyPower> beisner: the user has left, however this seems like good info to have for the future
[19:01] <beisner> lazyPower, i'd have to stand up a new environment to exercise that, in order to be able to t-shoot.
[19:02] <beisner> lazyPower, we'd also want to grab a juju stat, and know which version of OpenStack is deployed, juju version, ubuntu version, all that good stuff.
[19:02]  * beisner has to head out for a bit
[19:42] <thomi> marcoceppi: As per our conversation yesterday: https://bugs.launchpad.net/juju-deployer/+bug/1484260
[19:42] <mup> Bug #1484260: juju-deployer logs ERROR messages during successful deployment from mojo <mojo> <juju-deployer:New> <https://launchpad.net/bugs/1484260>
[20:31] <apuimedo> jamespage: gnuoy: Is there some flakiness with deploying nova-cloud-controller on an lxc container?
[20:31] <apuimedo> I got it failing when establishing the relation with nova-compute
[20:32] <lazyPower> apuimedo: they're UK based and probably not around. Can you hit the list with your findings of flakiness?
[20:32] <apuimedo> ah, that's true
[20:32] <apuimedo> I sometimes forget that people don't live in IRC :P
[20:32]  * lazyPower smirks
[20:32] <apuimedo> lazyPower: how are you?
[20:32] <lazyPower> guilty as charged
[20:33] <lazyPower> apuimedo: doing well, i sent you a follow up this morning about your charms and if there was anything required from me
[20:33] <apuimedo> oh, I didn't see it
[20:33] <apuimedo> let me check my mail filters
[20:33] <lazyPower> no worries :) You're probably not used to me emailing you since we have such an excellent record of IRC contact
[20:33] <apuimedo> oh, that was after I got home
[20:34] <lazyPower> ah yeah, important to specify *my* morning, not morning over in EU
[20:34] <apuimedo> I didn't check my email much since then
[20:34] <apuimedo> gotta entertain the child
[20:34] <apuimedo> :P
[20:34] <lazyPower> :D totally understood
[20:34] <lazyPower> and nothing pressing if you're chugging along well, thats excellent.
[20:34] <lazyPower> just wanted to make sure you're getting the help required
[20:34] <apuimedo> thanks ;-)
[20:35] <lazyPower> np np. I'm here to help
[20:36] <beisner> hi thedac, you may also be interested in checking out bug 1484260.  it's doesn't impact the run itself, but it does raise a brow or two with error noise.  not sure if mojo needs to pass things differently to deployer, or if deployer needs to just like it  ;-)
[20:36] <mup> Bug #1484260: juju-deployer logs ERROR messages during successful deployment from mojo <mojo> <uosci> <juju-deployer:New> <https://launchpad.net/bugs/1484260>
[21:02] <Bigdeal>  my juju fresh install cant connect to my openstack private cloud, I get an authentication issue that is due to selfsigned certs
[21:02] <Bigdeal> Anyone knows how to resolve it?
[21:04] <lazyPower> Bigdeal: i got some feedback from an openstack dev while you were disconnected
[21:05] <lazyPower> Bigdeal: we'd also want to grab a juju stat, and know which version of OpenStack is deployed, juju version, ubuntu version, all that good stuff.
[21:05] <lazyPower> Bigdeal: one of the things we'll need to do is try to reproduce your setup so we can accurately debug and see if we cant find an answer for you. Can you get me  a pastebin with the requested output above that i can forward over to the openstack team?
[21:15] <Bigdeal> lazyPower: We're running HP's Cloud System 8.1
[21:16] <lazyPower> Bigdeal: which version of juju, and which platform? (osx, ubuntu trusty, et-al)
[21:17] <lazyPower> beisner: ^ HP Cloud system 8.1 - i'm not familiar with this setup.
[21:18] <Bigdeal>  lazyPower: The Openstack version is Icehouse
[21:18] <Bigdeal> JUJU on ubuntu trusty
[21:19] <Bigdeal> I basically loaded a VM with Ubuntu 14.04 LTS, then I installed Juju
[21:20] <Bigdeal> then I ran juju-quickstart -i and created a new openstack config
[21:20] <Bigdeal> it fails bootstraping
[21:20] <beisner> hi Bigdeal, do you have debug output from the juju client?   fyi you can add --debug to just about any juju command.    ie.    `juju bootstrap --debug`
[21:21] <beisner> Bigdeal, also, can you paste your ~/.juju/environments.yaml  (remove passwords and other sensitives of course)?
[21:21] <beisner> Bigdeal, @ http://paste.ubuntu.com/
[21:22] <Bigdeal> I will run it again and share the output, when I looked earlier it was an SSL error, I assumed it has to do with the fact that I have self signed certs on my Openstack setup
[21:25] <beisner> Bigdeal, another bit that would be helpful is your `keystone catalog` output (sanitize to your comfort)
[21:25] <beisner> Bigdeal, however, keep in mind that i'm not specifically familiar with the undercloud you're running.  but with that ^ info we may be able to see what's going on.
[21:25] <Bigdeal> http://paste.ubuntu.com/12065817/
[21:26] <Bigdeal> here is the conf http://paste.ubuntu.com/12065827/
[21:27] <lazyPower> Bigdeal: missing object store - i think i found the issue
[21:28] <lazyPower> do you have swift/glance in this stack and have access to create object buckets?
[21:28] <Bigdeal> beisner: We running Openstack wth Vcenters for compute
[21:28] <Bigdeal> we have glance but I am not sure about object buckets
[21:28] <Bigdeal> I am new to openstack/juju
[21:28] <lazyPower> beisner: i may be mis-remembering if glance is an object store.... ally oop me?
[21:29] <lazyPower> Bigdeal: ah glance is the VM Image store, i am mis-remembering. i think it requires swift - there's a hard requirement of juju prior to 1.25 (currently in a highly unstable beta phase) which requires object storage. 1.25 will remove that limitation as i understand it
[21:30] <beisner> lazyPower, having object storage available via either swift or ceph-radosgw for object stores is pretty much a requirement with the juju openstack provider
[21:30] <beisner> er i mean, Bigdeal ^
[21:30] <lazyPower> ^
[21:30] <lazyPower> yeah, thats what I thought when i saw that output is we have found the culprit
[21:30] <beisner> lol
[21:30] <lazyPower> its not so much SSL as it is missing object storage
[21:30] <beisner> yep
[21:30] <lazyPower> juju writes a backup "state" pointer to the object store, which is used if your client .jenv is ever corrupted
[21:30] <lazyPower> so it can rebuild itself
[21:31] <lazyPower> we remove this requirement as it cut out over 1/2 of the cloud providers out there. Apprently this one included - as its missing a key component we are using today.
[21:31] <beisner> Bigdeal, `keystone catalog` would need to show a registered 'object-store' service to indicate that cloud is ready to juju
[21:31] <lazyPower> let me see if i can find the object storage removal bug and link you to that Bigdeal so you can track its progress. If you're fine with using a testing client you might even be able to install juju 1.25 and be an early adopter/driver of this provider code update.
[21:31] <Bigdeal> let me check what I have on that
[21:32] <lazyPower> or i can wait for that first :)
[21:32]  * lazyPower is notorious at putting cart before the horse
[21:32] <lazyPower> beisner: see? this is why i call you in on these projects. Mr big guns over there.
[21:33] <lazyPower> beisner: remind me in DC to buy you all the beer you can consume for being my go to for openstack stuff
[21:33] <beisner> lazyPower, ah thanks sir.   we should gather around beers regardless ;-)
[21:33] <lazyPower> a truer statement hath not been typed in this channel.
[21:33] <Bigdeal> How can I check if I have the object store?
[21:34] <Bigdeal> btw I dont mind being an early adopter, I 'll be happy to contribute
[21:35] <beisner> lazyPower, /me didn't know --object requirement @ ~1.25!
[21:35] <beisner> lol
[21:35] <beisner> xmas in aug
[21:35] <lazyPower> yessir!
[21:35] <lazyPower> Bigdeal: ok let me go dive into the bug tracker and ping some people and see what i can turn up
[21:35] <lazyPower> Bigdeal: it may not be landed in the devel ppa just yet, so there's a bit of digging i need to do before i can promise anything
[21:36] <Bigdeal> Keystone tells me I have cinder object store
[21:36] <beisner> Bigdeal, hrm.  cinder is block storage
[21:37] <Bigdeal> CinderV2 Block Storage Service API
[21:37] <Bigdeal> ok get it
[21:37] <lazyPower> Bigdeal: heres your bug you'll want to track - https://bugs.launchpad.net/juju-core/+bug/1456265
[21:37] <mup> Bug #1456265: Openstack provider should work without object-store <openstack-provider> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1456265>
[21:37] <Bigdeal> block vs objct sorry
[21:37] <lazyPower> beisner: ^ might want to flag that as well since its fix committed
[21:37] <beisner> Bigdeal, ah ok.  so not object-store available?
[21:38] <beisner> lazyPower, tyvm!
[21:38] <Bigdeal> http://paste.ubuntu.com/12065894/
[21:39] <Bigdeal> That's the keystone service list
[21:40] <beisner> Bigdeal, yep, no object store
[21:40] <lazyPower> Bigdeal: i've got open questions out, and will circle back once i get an answer.
[21:41] <beisner> lazyPower, where is devel pushing packages these days?  https://launchpad.net/~juju/+archive/ubuntu/devel  looks stale
[21:41] <Bigdeal> mhh so what are my options? would it easy enough to setup an object store in openstack (swift?)
[21:41] <lazyPower> ayy, yeah
[21:41] <lazyPower> those are some old bins
[21:41] <beisner> while https://launchpad.net/~juju/+archive/ubuntu/proposed  appears fresh
[21:42] <lazyPower> beisner: that should be where we stage the beta versions. I admittedly have not been on the -devel ppa in a while since i'm building nightlies in docker these days
[21:42] <beisner> lazyPower, Bigdeal - gotta switch into evening, dinner, kiddo mode.  may  check in later this eve, if not, catch you tomorrow.   thank you.
[21:43] <lazyPower> ack beisner, thanks for the last minute checkin
[21:43] <lazyPower> see you in the AM o/
[21:45] <lazyPower> Bigdeal: just got word back that we dont have an update for the -devel ppa yet as core hasn't had a blessed release yet w/ the new features, so its coming but is not trivial to test right this minute.
[21:45] <Bigdeal> lazypower: Thanks a lot for your help
[21:46] <Bigdeal> in the meantime I will try to setup swift
[21:47] <lazyPower> Best of luck Bigdeal. If you encounter any further questions feel free to ask and someone will be with you shortly. Sorry I didn't have a quick answer for you to get moving right away today, but we're actively working on it :)
[21:49] <Bigdeal> Thank a lot I will keep trying this evening and get back to you tomorow
[21:54] <lazyPower> Cheers Bigdeal
[21:54] <lp|conference-mo> aww my -mode got nuked