[02:39] <andreabedini> anyone help having trouble with the charm cs:trusty/mysql-25 ?
[02:40] <andreabedini> lol, anyone *else*
[02:41] <andreabedini> hook start fails and I can't get it to work
[02:44] <andreabedini> haha, I got it, it's running out of memory ...
[02:57] <lazyPower> andreabedini: which provider are you using? i'm assuming the local provider?
[02:57] <andreabedini> correct, jujubox vagrant image
[02:58] <lazyPower> yeah, this is a known bug - sorry you found out about it the hard way
[02:58] <lazyPower> juju set mysql dataset-size=20%
[02:58] <lazyPower> or 128M
[02:58] <lazyPower> either value will work - but thats teh fix for local provider. Its documented in the readme
[02:58] <andreabedini> no problem, main difficulty was troubleshooting
[06:19] <gnuoy> wallyworld, I've attached logs from a deploy with --debug . I'll leave the environment up for the next few hors just incase you can think of anything else that would be helpful
[06:20] <wallyworld> gnuoy: awesome, ty. i have a pull request up to add extra debugging also, which will come in beta2 on thursday. i must admit i'm quite perplexed at this stage as what i'm seeing doesn't make sense
[06:20] <wallyworld> gnuoy: i'm off to soccer in a bit but will be back later when i'll look at the logs in detail
[11:11] <jamespage> dosaboy, wolsen, gnuoy, coreycb: hey - I've switched over the quantum-gateway charm in /next to be called neutron-gateway
[11:11] <jamespage> next.yaml being updated now
[11:11] <gnuoy> kk
[11:12] <jamespage> all outstanding merge proposals rejected with an appropriate comment
[11:16] <dosaboy> jamespage: slick
[11:57] <Baqar> Any openstack charm developers here?
[11:57] <Baqar> About to pull out my hair with writing a unit_test for my charm ..
[18:42] <tvansteenburgh> hazmat: dpb and i would like to do a hangout with you sometime to get a walkthrough on deployer and jujuclient releases, to make sure we actually know all the steps. let me know if/when you'd have time for something like that
[18:49] <rick_h_> tvansteenburgh: frankban has been helping copying builds into the juju stable PPA. We generally work to get them into our team PPA and QA them with the gui charm and such and once they're ok we copy them to the juju stable ppa
[18:49] <rick_h_> tvansteenburgh: so not at the start, but fyi towards the end
[18:55] <tvansteenburgh> rick_h_: ack, thanks
[19:10] <hazmat> tvansteenburgh: sure, its basically full ci smoke test, push to pypi, ping non daily ppa owners, and notify server team re new package for dev distro.
[19:10] <hazmat> jcastro: tvansteenburgh: do you know if anyone is coming to gluecon next week?
[19:11] <jcastro> not afaik
[19:13] <tvansteenburgh> hazmat: cool thanks, what's a good day/time?
[19:14] <hazmat> tvansteenburgh: how's the 26th work for you?
[19:15] <hazmat> i'm basically slammed or traveling till then
[19:15] <tvansteenburgh> hazmat: works for me
[19:15] <hazmat> tvansteenburgh: anytime works, i'll be on pacific tz that day
[19:16] <tvansteenburgh> hazmat: ok, i'll set something up, thanks!
[19:49] <firl> anyone able to help me figure out why/where my charms for vivid are? I installed and bootstrapped a 15.04 environment on juju 1.23.2
[19:50] <rick_h_> firl: what's up? which charms are you looking for? You set the series to vivid pre-bootstrap?
[19:51] <firl> default-series: vivid
[19:51] <firl> I am ultimately trying to install openstack kilo via charms
[19:52] <rick_h_> firl: ok, I don't htink the openstack charms are released for vivid. At least none in the charm store https://api.jujucharms.com/v4/search?series=vivid
[19:52] <firl> That’s what I figured :( just figured I would ask here to double check
[19:52] <rick_h_> firl: because charms tend to run production we usually encourage/check things against LTS
[19:53] <firl> I completely understand
[19:53] <rick_h_> firl: and in between folks can download/checkout the charms and use them locally on the in-between releases
[19:53] <firl> yeah, I am just trying to figure out one of the easier ways to automate install Openstack Kilo
[19:53] <rick_h_> but with the systemd change I'll be a few charms need some love before running smoothly on vivid. That's just me guessing though
[19:54] <rick_h_> firl: if you change the series to trusty you should be good
[19:55] <firl> yeah, it looks like trusty is the way to go with me just changing the origin to openstack-origin: cloud:trusty-kilo
[19:56] <rick_h_> firl: you might find http://summit.ubuntu.com/uos-1505/meeting/22426/openstack-kilo-updates-and-roadmap/ interesting from the recent online summit as well
[19:57] <firl> nice, thanks rick_h_ I appreciate it
[19:59] <marcoceppi> firl: you can run kilo on trusty, we backport all releases of Openstack to the previous Ubuntu LTS :)
[20:00] <firl> marcoceppi: I am just trying to find the best way to get Kilo, the auto pilot didn’t seem to install kilo, so it looks like configuring charms one by one with setting kilo as the origin is the best bet
[20:00] <marcoceppi> firl: yes, but you can take the openstack bundle and just edit it once for all the charms
[20:00] <marcoceppi> isntead of doing it by hand
[20:00] <rick_h_> dpb1: ^ any word on autopilot/kilo? I didn't check out the session if that's on the way or there already?
[20:01] <marcoceppi> I think the plan is that autopilot will be LTS/LTS (Ubuntu/OpenStack) but I'm not 100% on that
[20:01] <rick_h_> marcoceppi: ah, gotcha
[20:01] <marcoceppi> firl: https://jujucharms.com/openstack you can grab either teh base bundle or another one, and just set the openstack-origin option for each charm in that bundle's YAML file
[20:01] <firl> marcoceppi: oh yeah? I will have to try that, I was having issues with my juju-gui and deciding which services where were.
[20:01] <marcoceppi> then use juju quickstart to deploy the bundle
[20:02] <firl> I will try that now
[20:02] <firl> via command line or gui
[20:02] <rick_h_> firl: let me know if you've got juju gui issues.
[20:02] <firl> will try it now, probably a 30 minute turn around on my MAAS environment
[20:04] <marcoceppi> firl: either should work, you're jsut going to have to modify the "bundle.yaml" file for that deployment from "cloud:trusty-juno" to kilo, etc
[20:45] <firl> rick_h_: I am trying to see where to specify the version via the juju-gui and I think I might be missing it, it looks as though i might have to deploy it first
[20:46] <rick_h_> firl: from the bundle?
[20:46] <firl> yes
[20:46] <rick_h_> firl: ah, wait a couple of days? :)
[20:46] <firl> haha ok, command line it is :)
[20:46] <rick_h_> firl: the guys are finishing a new feature in the GUI to make bunldes 'uncomitted' when you drop them on the canvas so you can change config/etc before you hit deploy
[20:46] <rick_h_> firl: it's going through QA and some last updates today and hopefully out later this week if you care to try it out :)
[20:47] <firl> that’d be aweseome, because i have some machines that can run services but can’t run emulation
[20:48] <rick_h_> firl: yea, we're excited to get it out to allow you to take a large bundle and maybe tweak it down to size, or change up the services before you hit go
[21:03] <firl> marcopeppi: rick_h_: I am having trouble finding documentation on how to change the origin for an entire bundle to deploy via the command line. Do I just clone: http://bazaar.launchpad.net/~charmers/charms/bundles/openstack-base/bundle/view/head:/bundles.yaml and then change each reference to openstack-origin and deploy a local bundle?
[21:20] <rick_h_> firl: yes, unfrotunately that's exactly what marcoceppi was saying. To get the bundle file and edit it and then deploy it once the file is changed
[21:21] <firl> So, configure maas, bootstrap a node, add the other machines to the juju environment, checkout bundle, change release, deploy bundle?
[21:22] <hatch> firl: you'll want to let juju handle spinning up the machines the bundle will deploy to
[21:22] <hatch> bundles can't deploy to existing machines
[21:22] <firl> hatch: so should I bootstrap to a node that won’t be used inside the bundle essentially?
[21:23] <hatch> correct
[21:23] <firl> understood ( destroying my environment again hah )
[21:24] <hatch> haha sorry
[21:26] <firl> no worries, all a learning process
[23:02] <firl> while waiting for the bundle to deploy from juju-gui should I be seeing “agent-state-info: 'cannot run instances: cannot run instances: gomaasapi: got error back from server: 409 CONFLICT (No available node matches constraints” from a bunch of agents?
[23:07] <lazyPower> firl: no, that means maas is having trouble fulfilling the request
[23:07] <firl> had that fear
[23:08] <lazyPower> ensure you have machines in the maas pool that meet the constraints passed, such as mem= cpu=
[23:09] <lazyPower> that or change the constraints to fit your avilable pool of instances
[23:25] <firl> lazyPower: I am just trying to install the openstack-base and I thought it only needed 4 nodes
[23:25] <firl> but it tries to create 17 states essentially
[23:26] <lazyPower> ah yeah
[23:26] <firl> so I am confused lol
[23:26] <lazyPower> each service has num_units that indicates how many machines to provision, and none of this is colocated
[23:27] <firl> do i need to edit the bundle file manually?
[23:28] <lazyPower> firl: there's a lot going on in here that will cause you trouble if you only have 4 machines avialable to you
[23:28] <lazyPower> juju-quickstart doesn't understand colocation unless you implicitly call --to machine# (and this is discouraged - but can be done)
[23:28] <firl> gotcha
[23:28] <firl> gotcha, so I am better off manually building it out using the gui or auto pilot?
[23:28] <lazyPower> the gui supports placement, but the bundle then becomes interesting - as you have to manually place them in the machine-view of the gui
[23:29] <lazyPower> unfortunately i know very little about autopilot, i beleive autopilot still assumes a certain number of machines.
[23:29] <lazyPower> our opstack charmer team has EOD'd by now
[23:29] <lazyPower> *openstack
[23:29] <firl> gotcha
[23:30] <lazyPower> but what I suggest is if you've got the time - to circle back and ping beisner, or gnuoy about what your options are with 4 machines aside from doing it manually
[23:30] <lazyPower> i know the manual route will work - but its a bit more complicated that way, and untested in terms of garanteed deployment. The formation thats in the bundle is what we've got under CI and is known to work
[23:31] <firl> yeah, I am just doing this at home with only 9 physical machines
[23:32] <lazyPower> 9 machines? :)
[23:32] <lazyPower> sounds like my house
[23:33] <firl> hah, at least just in the rack
[23:33] <firl> I was using RDO, to do the deployment before, figured I would learn something new
[23:59] <hatch> firl: if you're familiar with openstack you can drag and drop the appropriate services using the GUI
[23:59] <hatch> bundle modifications in the gui are coming very soon