[01:27] <AskUbuntu_> Problem installing MAAS nodes on Intel NUC | http://askubuntu.com/q/489786
[08:21] <gnuoy`> jamespage, I have a few mps attached to a couple of bugs if you get a moment. Bug#1335760 & Bug#1335762
[08:21] <_mup_> Bug #1335760: neutron metadata agent service fails if https-service-endpoints is enabled on the keystone charm <Juju Charms Collection:New for gnuoy> <https://launchpad.net/bugs/1335760>
[08:21] <_mup_> Bug #1335762: neutron-api charm does not support https <Juju Charms Collection:New> <https://launchpad.net/bugs/1335762>
[08:41] <jamespage> gnuoy`, ack
[08:41] <jamespage> that first one points me at something I need to fix in the neutron-gateway for the network-splits work
[08:44] <jamespage> gnuoy`, reviewed - 2 x +1 and 1 needs some more work
[08:44] <gnuoy`> jamespage, ack, thanks
[09:14] <gnuoy`> jamespage, I've updated that branches with fixes for the issues you mentioned
[09:24] <jamespage> gnuoy`, all looks good to me
[09:24] <gnuoy`> jamespage, thanks I'll merge them into next
[09:24] <jamespage> gnuoy`, +1
[10:18] <jamespage> gnuoy`, https://code.launchpad.net/~james-page/charms/trusty/rabbitmq-server/resync-plus-makefile-helpers/+merge/224973
[10:18] <jamespage> if you have 2 mins
[10:19] <gnuoy`> jamespage, sure
[10:21] <jamespage> gnuoy`, also this MP (which is not yet approved/review/landed) impacts on the neutron-api charm
[10:21] <jamespage> https://code.launchpad.net/~openstack-charmers/charms/precise/nova-cloud-controller/worker-configuration/+merge/221683
[10:25] <gnuoy`> jamespage, Shouldn't we block on lint even if your mp doesn't introduce that lint ?
[10:25] <jamespage> gnuoy`, yeah - lemme sort that out
[10:25] <gnuoy`> ta
[10:26] <jamespage> gnuoy`, done
[10:29] <AskUbuntu_> ubuntu juju local configure failed | http://askubuntu.com/q/489917
[10:31] <gnuoy`> jamespage, rabbit mp approved
[10:58] <jamespage> gnuoy`, ta
[11:01] <schegi> jamespage, got something done for the osd journal devices but still got some questions.
[11:11] <jamespage> schegi, ok
[11:28] <jamespage> marcoceppi, if you are around today pls can we talk mysql and networking stuff :-)
[11:50] <schegi> jamesapage, the thing with the osd devices was quite straight forward but i ran into problems when write the config back to the ceph.conf like it is done in emit_cephconf. emit_cephconf is called before the osds are osdized. The problem is now once an osd is osdiced getting all the information that should be presented in the ceph.conf seems very complicated. one the one hand i got the devices list like defined in the config (journal and
[11:52] <schegi> but at this point i have no clue which osd.X is actually using which device. getting all osd_ids is trivial but getting the used journal and data device given an osd_id might only be possible by using ceph-disk list, which can't be called clusterwise but only per node.
[12:46] <lazypower> sparkiegeek: awesome! I'll check it out when i'm done with my morning email run
[12:46] <sparkiegeek> lazypower: thank ye kindly
[13:07] <schegi> jamespage, back at the desk so if you got some time notify me
[13:08] <jamespage> schegi, give me a few
[13:08] <jamespage> just wrapping something else up
[13:10] <bloodearnest> bcsaller: heya - when you playing with using docker in a charm, did you try with that charm on an lxc unit?
[13:10] <bloodearnest> am encountering some issues
[13:10] <schegi> jamespage, kk
[13:18] <jamespage> schegi, ok - back
[13:18]  * jamespage reads
[13:18] <schegi> jamespage, ok
[13:19] <jamespage> schegi, Q - why do you need to store the journal information in ceph.conf?
[13:19] <schegi> as long as i can read from the comments in the code the ceph.conf is written as a kind of backup
[13:20] <schegi> and i thougth it would be nice to have [osd.XX] sections also in the ceph.conf. to get it working this is not necessary
[13:20] <jamespage> schegi, I've tried to keep it minimal in the charms and use ceph-disk an the OS integration it uses as much as possible
[13:21] <jamespage> schegi, I think maintaining a consistent ceph.conf in a large cluster will be hard to implement, and not provide a huge amount of value.
[13:21] <schegi> This is true
[13:21] <jamespage> schegi, ceph-disk can initialize blocks on a journal device, and it links to the device by UUID in /var/lib/ceph/osd/ceph-N/journal where N is the OSD number
[13:22] <jamespage> schegi, I guess the trick is distributing journals over avaliable SSD's automatically during provisioning right?
[13:23] <schegi> i justadded an osd-journal-devices parameter to the config and build device/journal-device tuples.
[13:24] <schegi> iwhich i then pass to ceph.osdize
[13:25] <schegi> seems to work. now working on an modulo functionality to distribute multiple journals on one given device if more devices (osds) are defined than journal devices. But i am not shure how ceph behaves if a given journal device has not enought space (too many journals and/or to big journal size) have to experiment a bit
[13:27] <jamespage> schegi, well we have the journal size specified in configuration as well
[13:27] <jamespage> schegi, so we can calculate the number of OSD's that a specific journal device should be able to accomodate
[13:28] <jamespage> schegi, as osd-devices is a whitelist, we need to determine which devices are present on the current unit, and then distributed their journals evenly across the available journal devices
[13:28] <jamespage> schegi, I would suggest that if there is insufficient capacity on the journal devices, we error out the hook so an admin can see this
[13:28] <jamespage> rather than reverting to on-OSD-disk journal
[13:29] <schegi> ok
[13:40] <rbasak> sinzui: around? I have a 1.18.4 SRU prepared for upload to trusty-proposed. I wonder if you can advise what testing I can do on it, please?
[13:41] <rbasak> I wondered how I might align SRU verification testing so that it's essentially the same at the testing you already do on your (upstream) stable releases.
[13:43] <lazypower> sparkiegeek: merged and pushed
[13:44] <sparkiegeek> lazypower: cheers!
[13:44] <lazypower> Thanks for the update :) That'll be a lot friendlier in CI / new users
[13:48] <d4rkn3t> hello dear, I neet help with JUJU is there someone can help me? thanks
[13:53] <d4rkn3t> I've run the command "juju bootstrap --upload-tools -e maas --debug" during the all debug JUJU try to connect to a node "Node02Cluster01Svr:22". the node change its status from ready to allocated, with the OS in running. after 10 minutes the error is this "ERROR juju.cmd supercommand.go:305 waited for 10m0s without being able to connect: ssh: Could not resolve hostname node02cluster01svr: Name or service not known". In the Region Contro
[13:53] <d4rkn3t> ller I've set DNS and DHCP
[13:57] <sinzui> rbasak, I am not sure what to advise, CI tested 1.18.4 with http://juju-ci.vapour.ws:8080/view/Architectures%20and%20Series/  , http://juju-ci.vapour.ws:8080/view/Functions/  , http://juju-ci.vapour.ws:8080/view/Providers/ .
[13:58] <mbruzek> Does anyone know if the pprint plugin works for hp-cloud?
[13:59] <sinzui> rbasak, Those tests verified the package CI created with the streams that could be published...but since streams are now published, and 1.18.4 was tested, I think you want a set of verification tests that demonstrate that ubuntu's 1.18.4 is still compatible
[13:59] <sinzui> oh
[13:59] <AskUbuntu_> juju bootstrap using maas unable to ssh into nodes | http://askubuntu.com/q/490000
[14:00] <mbruzek> Am I using the plugin incorrectly?  http://pastebin.ubuntu.com/7726582/
[14:00] <rbasak> sinzui: I've been looking there, but they seem to all relate to 1.20? Or is there a particular build in the past that is the 1.18 branch?
[14:00] <mbruzek> It seems to work when I am using Juju local.
[14:00] <rbasak> sinzui: I'd like to be able to somehow run all the tests that you consider required for a stable release, except against what I'm about to upload.
[14:01] <rbasak> sinzui: (or, if needed, I could do it after it appears in trusty-proposed)
[14:01] <sinzui> rbasak, This is the log of the 1.18.4 release. I think the 1.18.1 upgrade verification and 1.18.4 deploy are relevant. That demonstrates that version of juju works with each cloud, each stream, and the cloud images: https://docs.google.com/a/canonical.com/document/d/1YtE-V83H20RVW8Gd8byPQyULU5nP0KOMUbESk9_UUNY/edit#heading=h.dp1wyrj1wujg
[14:03] <sinzui> rbasak, well the the ci set of tests are more relevant then. The did use the package
[14:03]  * rbasak looks
[14:03] <marcoceppi> jamespage: I am around!
[14:03] <jamespage> marcoceppi, w00t!
[14:03] <jamespage> marcoceppi, so two things
[14:03] <jamespage> 1) hows the mysql charm redux going?
[14:03] <jamespage> 2) I need to hack it
[14:03] <jamespage> marcoceppi, re 2) specifically I want to be able to make 'data' traffic run over a specific network
[14:04] <jamespage> I have a few ideas on how but wanted to discuss with you first.
[14:04] <marcoceppi> 1) Rewrite has slowed because of other work, unfortunately
[14:04] <marcoceppi> 2) It's pretty hackable, I'm putting a lot of the new code in to charm-helpers under contrib/mysql
[14:04] <lazypower> mbruzek: juju pprint should work on *any* provider
[14:04] <marcoceppi> I'll push up an updated branch of both today
[14:05] <jamespage> marcoceppi, excellent
[14:05] <mbruzek> lazypower, According to my pastebin was I using it incorrectly?
[14:05] <jamespage> marcoceppi, I was hoping to take a similar approach to the one I took for rabbitmq
[14:05] <marcoceppi> mbruzek: it's just `juju pprint` not `juju status pprint`
[14:05] <jamespage> which is to override the private-address setting on the amqp relation with a different one
[14:05] <marcoceppi> jamespage: that sounds sane enough
[14:06] <jamespage> marcoceppi, but its more complex due to the grants that get created for each user/accessing server
[14:06] <mbruzek> thanks marcoceppi
[14:06] <marcoceppi> jamespage: ah, for the user/db perms
[14:06] <jamespage> yes
[14:06] <marcoceppi> should still be doable with a little work. Are you going to make this a configuration option?
[14:07] <jamespage> marcoceppi, I can do it within the scope of the existing relation data on the shared-db relation type
[14:07] <jamespage> marcoceppi, yes
[14:07] <jamespage> to "configuration option"
[14:07] <sinzui> rbasak, There is no easy way to make CI test a package it didn't create, but I can imagine a new job that starts with a set of debs. the provider and function tests just pickup debs from the publish-revision job. The arch and series tests for local also pickup the deb. The unittests also accept a tarball though
[14:07] <marcoceppi> jamespage: cool, yeah I'll push up what I have after I get the tests passing again so you want to take a look
[14:07] <jamespage> marcoceppi,  so default is as now; turn this on and it will switch to using a new network, on the assumption that the service unit is actually connected to the configured network
[14:08] <sparkiegeek> dpb1: this really is a terrible idea
[14:09] <rbasak> sinzui: that sounds promising. How difficult / how much work would it be for you to add corresponding jobs that enables -proposed and uses apt-get install instead of installing debs directly?
[14:09] <rbasak> sinzui: then we could have a process where I upload to trusty-proposed, and then we just need to run those jobs to get to verification-done state.
[14:15] <sinzui> rbasak, I think the solution is to revise the build-revision and publish-revision jobs to accept an alternate start param. Build rev would pickup the packages, publish moves them to a location to the tests.
[14:17] <sinzui> rbasak, I hesitate to proper install the proposed package because we need to add a way to restore the previous packages. We manually control when package is stable. since the machines are shared with other procs
[14:18] <dpb1> marcoceppi, jcastro: sorry 'bout this, if someone could look at this i would appreciate it.  selfsigned cert is broken (by my last commit) for apache2 (missing dependency on precise): https://code.launchpad.net/~davidpbritton/charms/precise/apache2/1335473-pyasn1-libs
[14:18] <marcoceppi> dpb1: taking a look now
[14:18] <sinzui> rbasak, I can certainly add support to test your packages starting this week. I am dedicated to sorting our this kind of problem for Ubuntu this month
[14:19] <dpb1> marcoceppi: thx
[14:19] <jcastro> mbruzek, you're back from holiday I take it?
[14:19] <rbasak> sinzui: thanks. Sorry, I assumed that the tests could run destructively.
[14:19] <mbruzek> jcastro, yes
[14:20] <rbasak> sinzui: so you're OK with installing debs directly, but don't want to add -proposed itself?
[14:21] <rbasak> sinzui: in any case, I think we're agreeing on some kind of vague verification plan here, that we need to iron out and implement?
[14:21] <rbasak> sinzui: if that's right, then shall I go ahead and upload and try and get this update landed in trusty-proposed, on the basis that we'll sort out a process and get it verified between us?
[14:21] <sinzui> rbasak, The tests extract the package, set the paths to the package, then execute the test. We don't install to the system location
[14:22] <rbasak> sinzui: ah, I see. Well I suppose the existing archive dep8 tests will make sure that package is hooked up to the user OK, so I guess that's OK for now.
[14:22] <rbasak> (ie. the user can call the client)
[14:23] <rbasak> Then if these tests verify that juju itself is functional, given that it's essentially a static binary I don't see a problem not testing it from the normally installed location.
[14:23] <sinzui> rbasak, I definitely want to allow you or me to pass in built debs/archives and reverify that things work. When clouds change. I do this manually to verify the cloud broke stable juju
[14:24] <sinzui> we have simple automated tests for cloud health, comprehensive testing of done my hand
[14:24] <rbasak> sinzui: sounds like a plan. I'll get this upload done today then - thanks.
[15:05] <jcastro> hey hazmat
[15:05] <jcastro> I see you pushed up personal branches of logstash and kibana for trusty
[15:05] <hazmat> jcastro, g'morning
[15:05] <jcastro> How are those working out for you? I'd like the get them up in trusty for real alongside ES
[15:06] <hazmat> jcastro, i'd say the log stash one is still a work in progress. i need to sync up with charles he was looking at them.. atm just trying to clear out post vacation tasks.
[15:07] <jcastro> ack
[15:07] <jcastro> welcome back
[15:07] <jcastro> hazmat, I have a demo with ES people at OSCON, think we can sort it by then?
[15:08] <lazypower> hazmat: i haven't leveraged any brain power against them yet. I saw that you were going for monitoring - i need to get the basic stuff in there like the forwarder and it should be g2g for basic deployment no?
[15:08] <lazypower> well, that and some tests
[15:09] <hazmat> jcastro, definitely
[15:09] <jcastro> hazmat, if you have demo ideas or useful bundles with all the ELK stuff lmk.
[15:15] <jamespage> marcoceppi, ping me a branch for mysql once you have one up - not going to hack into the current version - its like crawling through mud.
[15:19] <jamespage> gnuoy`, how do you feel about a context mutating data on the relation its associated with?
[15:20] <gnuoy`> jamespage, I don't follow
[15:20] <jamespage> gnuoy`, ok - heres the context
[15:20] <jamespage> we want access to mysql databases to flow of a specific network
[15:20] <jamespage> I just want to configure that in the mysql charm
[15:21] <jamespage> however grants are made based on remote host addresses; so the related charms need to know which IP to provide
[15:21] <jamespage> http://paste.ubuntu.com/7726892/
[15:21] <jamespage> this works via a deferred hook execution on a -changed hook
[15:22] <jamespage> the mysql charm would provide the required 'access-network' relation data; the remote charms would then provide their IP on said network back
[15:22] <jamespage> gnuoy`, I could write this into the SharedDBContext
[15:22] <jamespage> but that would mean invoking a relation_set on that relation
[15:26] <gnuoy`> jamespage, I have no strong ideological objection to that being in the hook context
[15:26] <jamespage> gnuoy`, ack
[15:57] <jcastro> jose, and niedbalski
[15:58] <jcastro> hey, antonio told me you guys wanted to get in on the review schedule for charms?
[16:00] <niedbalski> jcastro, i have been doing it unofficially, count me in.
[16:00] <jcastro> ok
[16:00] <jcastro> I'll add you to the calendar
[16:00] <niedbalski> jcastro, great!
[16:01] <jcastro> how's next week look like to you?
[16:01] <jcastro> you'll be with mbruzek
[16:01] <niedbalski> jcastro, i prefer this one, next week i will be on Cts sprint
[16:02] <lazypower> jcastro: not a bad idea. asanjar is out for spark conf.
[16:02] <lazypower> niedbalski: that pairs you with bcsaller.
[16:02] <jcastro> ok
[16:02] <jcastro> I'll take next week then with bruzer
[16:03]  * mbruzek waves
[16:04] <jcastro> niedbalski, basically we usually do top to bottom in the queue (link in the topic)
[16:12] <lazypower> niedbalski: if you run into anything you need help with, feel free to ping me if bcsaller isn't available.
[16:18] <niedbalski> lazypower, jcastro no worries.
[16:19] <niedbalski> thanks !
[16:21] <jose> jcastro: yeah, sure, I'd love to help with that
[16:25] <jcastro> marcoceppi, oh I forgot to remind you
[16:25] <jcastro> when you're working on the mysql charm
[16:25] <jcastro> keep in mind the open bugs on the charm (duh)
[16:25] <jose> jcastro: you can schedule me for next week with mbruzek if you want
[16:26] <jcastro> I'll put you after, I go to oscon the week after that and I wanted to pull my weight. :)
[16:27] <lazypower> jose: you're with me dude
[16:27] <jose> oh cool
[16:27] <lazypower> we're gonna rock that queue like it's never been rocked before
[16:27] <jcastro> https://bugs.launchpad.net/charms/+source/mediawiki/+bug/1298674
[16:27] <_mup_> Bug #1298674: Mediawiki defaults to PPA  use <audit> <mediawiki (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1298674>
[16:27] <jcastro> if you guys run out of things to do
[16:27] <lazypower> Pretty sure that's been patched
[16:27] <jcastro> this bug is so embarrassing!
[16:27] <lazypower> i think its a stale bug
[16:28] <jcastro> I just looked in the store
[16:28] <jcastro> PPA is there. :-/
[16:28] <lazypower> booo
[16:28] <lazypower> oh thats right, its got some clint fixes in there
[16:30] <jose> I tried to fix it but pushed to precise instead :P
[16:30] <jose> I'll take a look after I take this exam
[16:30] <jose> laters!
[16:32] <jcastro> ahasenack, can you resolve this bug as appropriate? https://bugs.launchpad.net/charms/+bug/1124471
[16:32] <_mup_> Bug #1124471: swift-proxy fails to install when source is a ppa <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1124471>
[16:32] <jcastro> trying to clean up our bugs
[16:32] <jcastro> jose, yeah if it's all set to go we should push to trusty
[16:34] <jose> cool, I'll check in a couple hors
[17:10] <mattyw> has anyone got juju working with devstack?
[17:11] <mattyw> I'm stuck on what to configure as the region on the env.yaml
[17:31] <sherl0ck_> Hello..We have deployed OpenStack environement using MAAS and Juju. I had a question - Is it possible to shutdown the compute blade and bring it back up safely?
[18:09] <ahasenack> jcastro: done
[18:23] <marcoceppi> sherl0ck_: if you restart the machine, it should re-register in Juju properly
[18:23] <marcoceppi> sherl0ck_: or are you referring more to a safe reboot within OpenStack context?
[18:56] <sherl0ck_> Hey thanks marcoceppi
[18:57] <sherl0ck_> I meant to shutdown  (power down )the physical node completely and than bringing back up. Do you think Juju will still identify it as compute node
[18:58] <marcoceppi> sherl0ck_: yes, there's an upstart job that will start on boot which will re-register it in the juju environment
[18:59] <marcoceppi> sherl0ck_: until then, it will show up as "DOWN" in juju status
[20:02] <jose> jcastro: hey, about bug 1170034, I have a duplicate (bug 1309980) https://code.launchpad.net/~jose/charms/precise/wordpress/fix-1309980/+merge/216568 is on the works
[20:02] <_mup_> Bug #1170034: integration with memcached broke <wordpress (Juju Charms Collection):Confirmed> <https://launchpad.net/bugs/1170034>
[20:02] <_mup_> Bug #1309980: Relationship to memcache seems incomplete <wordpress (Juju Charms Collection):In Progress by jose> <https://launchpad.net/bugs/1309980>
[20:50] <avoine> marcoceppi: Do you know where I could find a generic jenkins job for testing charm?
[20:50] <marcoceppi> avoine: not off the top of my head, tvansteenburgh did you get access to the old jenkins setup?
[20:51] <avoine> marcoceppi: your not using jenkins for automated testing anymore?
[20:51] <marcoceppi> avoine: we are, we're just re-vamping things at the moment
[20:52] <avoine> ok ok
[20:55] <jose> tvansteenburgh: hey, did you get to take a look at that test I linked last week?
[21:00] <tvansteenburgh> marcoceppi: i got access to what sinzui set up for us
[21:01] <tvansteenburgh> jose: no, i never got back to that, is it still failing?
[21:01] <jose> tvansteenburgh: it is, the relations hooks are not being ran even though the relation is there
[21:01] <jose> which is kinda concerning - may happen for other tests too
[21:01] <tvansteenburgh> jose: i've never seen it happen.
[21:01] <tvansteenburgh> jose: but, i'll pull the branch and take a closer look
[21:02] <jose> tvansteenburgh: if there's the chance you could check if the hooks are running on your end that's be awesome
[21:17] <jose> is anyone around having troubles with AWS? I'm getting 502s and 503s a lot
[21:56] <tvansteenburgh> jose: i've tried to run the tests a couple times and the install hook keeps failing with this in the log: http://paste.ubuntu.com/7728539/
[21:56] <tvansteenburgh> any ideas?
[21:56] <jose> tvansteenburgh: apt-get update
[21:56] <tvansteenburgh> tried that
[21:56] <jose> hmm, lemme check
[21:57] <AskUbuntu_> deploying charms using juju fails with tcp connection timed out | http://askubuntu.com/q/490141
[21:58] <tvansteenburgh> jose: i guess it could be a transient problem with the archives?
[21:59] <jose> tvansteenburgh: not sure. last week the issue was resolved with apt-get update and retrying the hook
[21:59] <jose> let me guess - you're in the local provider?
[21:59] <tvansteenburgh> yeah
[22:00] <jose> then that may be it
[22:00] <tvansteenburgh> there's an apt-get update in the install hook itself even
[22:01] <jose> yeah, but I'm not sure if it's getting the charm from the charm store or locally
[22:02] <tvansteenburgh> ok, i'll try some other stuff
[22:02] <jose> cool, thanks
[22:02] <jose> I wouldn't suggest AWS as I've been seeing some issues lately
[22:38] <mbruzek> tvansteenburgh, were you able to resolve this issue?
[22:40] <mbruzek> tvansteenburgh, I am hitting something similar too on local provider on Power.. http://pastebin.ubuntu.com/7728552/
[22:42] <mwhudson> i don't have context, but that means you need to run apt-get update maybe?
[22:43] <mwhudson> trusty-updates has 2:4.1.6+dfsg-1ubuntu2.14.04.2 now
[22:43] <mwhudson> that paste is trying to install 2:4.1.6+dfsg-1ubuntu2.14.04.1
[22:44] <mwhudson> and yeah tvansteenburgh's issue looks similar
[23:00] <tvansteenburgh> mbruzek: no, haven't resolved
[23:03] <mbruzek> tvansteenburgh, I thought my problem was related to setting proxies with juju but you have the same problem as I do.  Is it fair to assume you did not set proxies in Juju?
[23:05] <tvansteenburgh> mbruzek: correct, no proxy
[23:05] <tvansteenburgh> mbruzek: i've got to EOD, will pick this back up in the morning
[23:05] <mbruzek> tvansteenburgh, Thanks for the clarification, marco thinks we need to open a defect.
[23:05] <mbruzek> tvansteenburgh, is your scenario reproducable?
[23:05] <tvansteenburgh> so far, every time
[23:06] <mbruzek> tvansteenburgh, I am also going to EOD, we should talk tomorrow morning
[23:07] <tvansteenburgh> mbruzek: sounds good, ttyl