[03:52] <beisner> jamespage, gnuoy, wolsen  - even with happy a/ptr records, Precise-Icehouse n-c-c/next is broken when ssh migration auth is set.   if i substitute the n-c-c stable charm into next.yaml, the problem goes away.   break is at or after n-c-c/next rev188.
[03:52] <beisner> https://bugs.launchpad.net/charms/+source/nova-cloud-controller/+bug/1480677
[03:52] <mup> Bug #1480677: oslo.messaging.rpc.dispatcher AttributeError: 'Connection' object has no attribute 'connection_errors' <amulet> <openstack> <uosci> <nova-cloud-controller (Juju Charms Collection):New for gnuoy> <nova-compute (Juju Charms Collection):New for gnuoy> <rabbitmq-server (Juju Charms
[03:52] <mup> Collection):New> <https://launchpad.net/bugs/1480677>
[03:53] <beisner> bahh wrong link.
[03:53] <beisner> jamespage, gnuoy, wolsen - https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1500589
[03:53] <mup> Bug #1500589: n-c-c/next fails cloud-compute-relation-changed when migration-auth-type set for Precise-Icehouse <openstack> <uosci> <nova-cloud-controller (Juju Charms Collection):New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1500589>
[09:12] <gnuoy> beisner, https://code.launchpad.net/~gnuoy/charms/trusty/nova-cloud-controller/lp1500589/+merge/273508 should fix Bug #1500589
[09:12] <mup> Bug #1500589: n-c-c/next fails cloud-compute-relation-changed when migration-auth-type set for Precise-Icehouse <openstack> <uosci> <nova-cloud-controller (Juju Charms Collection):Confirmed for gnuoy> <nova-compute (Juju Charms Collection):Invalid by gnuoy> <https://launchpad.net/bugs/1500589>
[10:16] <jamespage> thedac, https://code.launchpad.net/~james-page/charms/trusty/ceph/status - will work on osd and radosgw as well
[10:17] <jamespage> that one works OK  - needs unit tests
[10:17] <jamespage> gnuoy, beisner: I fixed up my crappy failing unit tests - apologies for that
[10:17] <jamespage> insufficient patching
[10:17] <jamespage> thedac, http://paste.ubuntu.com/12696040/
[10:18] <jamespage> 'Unit is active' has become policy ....
[10:19] <jamespage> thedac, and - http://paste.ubuntu.com/12696048/
[12:51] <beisner> hi jamespage, gnuoy, thedac - http://paste.ubuntu.com/12696720/   i'm noticing that with next.yaml deploys, glance status stays in blocked 'Missing relations: messaging' - although the deploy completes successfully otherwise.  indeed there's no amqp relation.  do we need one?
[12:52] <beisner> jamespage, ty for the quick n-c fix btw
[12:52] <jamespage> beisner, we should probably just add that
[12:52] <jamespage> its used for ceilometer notifications
[12:52] <gnuoy> jamespage, I'm not sure I agree
[12:53] <gnuoy> IS for one, don't use ceilometer
[12:53] <beisner> jamespage, right, but i think 'blocked' will eventually really block us when we do more clever 'my thing is really deployed' logic.   i imagine deployer, amulet and juju itself will start watching that soon.
[12:53] <gnuoy> jamespage, I think we should move it to an optional relation
[12:53] <jamespage> gnuoy, beisner: ok so maybe the glance messaging relation should be optional
[12:53] <jamespage> I'm easy either way
[12:53] <beisner> so, optional relation then.
[12:53] <beisner> ;-)   yeah that
[12:53] <jamespage> but +1 on it being optional
[12:55] <beisner> jamespage, gnuoy - either way, since defauly/next yamls include ceilo, should we relate it to glance in those bundles?
[12:56] <gnuoy> I would think so
[12:56] <beisner> i haven't dug into the code.  is glance aware of whether/not ceilo is present
[12:56] <beisner> ?
[13:01] <jamespage> beisner, nope
[13:01] <jamespage> beisner, +1 to adding it to the bundle tho
[13:03] <jamespage> thedac, gnuoy: how does this look - http://paste.ubuntu.com/12696803/ ?
[13:03] <jamespage> that's ceph-osd
[13:04] <gnuoy> jamespage, it looks wonderful, I'd like to hug it
[13:05] <jamespage> gnuoy, unit tests of the atlantic and mps by the end of today
[13:05] <jamespage> gnuoy, its basic but I think its all fairly sound
[13:05] <gnuoy> kk, thanks
[13:06] <beisner> ok, i'll adjust o-c-t bundles.
[13:09] <beisner> fyi, raised for tracking:  bug 1503272
[13:09] <mup> Bug #1503272: workload status:  amqp relation should be optional <openstack> <uosci> <glance (Juju Charms Collection):New> <https://launchpad.net/bugs/1503272>
[14:02] <apuimedo> jamespage: is it possible to limit the amount of units of a charm?
[14:28] <thedac> jamespage: wrt, ceph, fantastic.
[14:28] <thedac> wrt glance +1 to moving messaging to optional. In fact if no one has done it already I will
[14:31] <beisner> ha!  /me just saw gnuoy hug a pastebin
[14:51] <mhall119> jcastro: jose: is there an official way to request a charm be written?
[14:52] <mhall119> the developer portal could really benefit from using Haystack, but I don't see a charm for it in the charm store
[14:57] <thedac> gnuoy: care to review? https://code.launchpad.net/~thedac/charms/trusty/glance/optional-amqp/+merge/273542
[15:00] <gnuoy> thedac, approved, would you mind doing the landing?
[15:00] <thedac> will do
[15:00] <gnuoy> ta
[15:01] <thedac> I'll wait on osci amulet before doing so
[15:14] <beisner> gnuoy, fyi, you'll be getting 2 amulet tests for kicking the bot while he/she/it was already running an amulet test on behalf of n-c-c  ;-)
[15:15] <gnuoy> Can I kick it ? It seems I can
[15:15] <beisner> new commit = retest
[15:15] <beisner> so the amulet result that is there, was for rev 199
[15:16] <beisner> there will be a new set for rev 200
[15:16] <gnuoy> beisner, so I think it fixes the bug you found either way
[15:16] <beisner> lol
[15:16] <beisner> yes thanks!
[15:16] <gnuoy> np
[15:29] <beisner> coreycb, thedac - i'm on a normalize-makefiles mission for *os-charms.  noticing that some charms aren't lint checking the actions/ dir.  when i enable that, some of them have unused uuid import in actions/openstack_upgrade.py
[15:30] <beisner> and when i remove that import, unit tests start to fail with 'actions/openstack_upgrade.py'> does not have the attribute 'uuid'
[15:30] <coreycb> beisner, I'd mark that low priority for now
[15:30] <thedac> agreed
[15:31] <beisner> coreycb, thedac - if i move forward, we'll either have failing lint checks or failing unit checks.
[15:31] <beisner> i can just ignore the actions dir for now ?
[15:31] <coreycb> beisner, yeah I'd vote for that and a bug
[15:32] <thedac> Yes, I would not make the change (yet) that checks the actions directory
[15:32] <beisner> fwiw, some do have it enabled, though for the pause/resume actions
[15:32] <beisner> be aware ^
[15:32] <beisner> so that'll force the next guy to make it right ;-)
[15:32] <beisner> on those ones
[15:37] <beisner> ok, squashing actions/ dir normalization wrt lint checks for now, will add affected charms to bug/1503340
[15:37] <mup> Bug #1503340: actions dir not checked for lint;  unused import when checked;  unit test fails when lint is resolved. <openstack> <uosci> <ceilometer (Juju Charms Collection):New> <https://launchpad.net/bugs/1503340>
[15:38] <beisner> ie. if it's already checking actions/, it will keep checking, but i won't force it to just yet.
[15:48] <coreycb> beisner, sounds good, thanks
[15:48] <beisner> coreycb, yw
[15:51] <beisner> jamespage, gnuoy, thedac, coreycb - while i'm batch-updating, any input on changing maintainers in metadata.yaml to something generic?   it'd be an easy change now.   atm, we have a mix of yolanda, adam g, jamespage.
[15:52] <thedac> Do we have an openstack-charmers@ mail alias? or something like it?
[15:52] <thedac> ls
[15:52] <thedac> :)
[15:53] <beisner> thedac,
[15:53] <beisner> -rw-rw-r-- 1 ubuntu ubuntu 467 Oct  6 14:09 metadata.yaml
[15:53] <beisner> ;-)
[15:53] <thedac> wow, my system is lagging
[15:54] <beisner> not sure re: mail alias.  that's what we should probably do i think
[16:00] <beisner> coreycb, can you check if you just rcvd a test email from my gmail acct to the openstack charmers list?
[16:05] <coreycb> beisner, I'm not seeing anything
[16:09] <ddellav> beisner, coreycb thedac i can take a look at that uuid and lint issues with the upgrade actions just as soon as im done with what im working on here.
[16:12] <beisner> coreycb, hrm.  no reject or awaiting-moderation reply on my end.  i wonder if the public can send to that?
[16:12] <beisner> https://launchpad.net/~openstack-charmers
[16:13] <beisner> jamespage, gnuoy, thedac, coreycb - i'm going to ignore the maintainers field for this batch.  but let's figure that out before release and i can push another batch to update all of the oscharms.
[16:31] <mattyw> lazypower, ping?
[16:34] <lazypower> mattyw, pong
[16:34] <mattyw> lazypower, hey hey - I'm not sure who else to ping - but if you're busy feel free to move me along...
[16:35] <mattyw> lazypower, wondering why my merge request isn't appearing the queue https://code.launchpad.net/~mattyw/charms/trusty/mongodb/mongodb-backup/+merge/273544
[16:37] <lazypower> mattyw, its only an hour old, its likely to be pending an intgest into review.juju.solutions
[16:37] <mattyw> lazypower, ok cool, so be patient grasshopper is the message :)
[16:47] <beisner> o/ lazypower, mattyw - our openstack testing bot cares about mongodb (because of ceilometer) and it does some automated testing on proposals there.  i've added a pre-review review ;-)
[16:47] <beisner> https://code.launchpad.net/~mattyw/charms/trusty/mongodb/mongodb-backup/+merge/273544
[16:48] <mattyw> beisner, thanks very much - I've just seen it, I'll make those changes
[16:48] <beisner> mattyw, cool, thanks!
[16:48] <mattyw> beisner, there was already an action - who's implementation I basically followed, would you like me to fix that up as well?
[16:48] <lazypower> beisner, <3 :)
[16:48] <beisner> mattyw, /me looks back...
[16:51] <beisner> mattyw, lazypower - indeed, there was 1 existing action, outside the coverage of lint checks.
[16:52] <beisner> http://bazaar.launchpad.net/~charmers/charms/trusty/mongodb/trunk/annotate/head:/actions/perf
[16:54] <mattyw> beisner, I'm eoding now, anything you'd like me to do just shove a message on the pr
[16:54] <mattyw> beisner, if I don't see anything new I'll go ahead with the linting fixes
[16:54] <beisner> mattyw, thanks.  i'll pull a few heads together and one of us will advise there.
[16:55] <mattyw> beisner, perfect
[16:55] <mattyw> night all
[17:47] <beisner> o/ coreycb - look out!  here's that batch to normalize makefiles and amulet test dependencies @ http://paste.ubuntu.com/12698366/    as discussed, did not address upgrade actions lint or maintainer bits yet.
[18:12] <coreycb> beisner, ok
[18:24] <cholcombe> is charmhelpers build for python 2.x?
[18:40] <cholcombe> coreycb, i believe you set pulls are welcome? :) https://code.launchpad.net/~xfactor973/charm-helpers/status_set-enum
[18:40] <cholcombe> coreycb, oh wait that has some junk from another branch in there.  i need to clean it up
[18:41] <coreycb> cholcombe, hmm dunno if I said that or not, but they are!
[18:42] <cholcombe> :)
[18:42] <coreycb> cholcombe, actually I can't land to charm-helpers though
[18:42] <cholcombe> coreycb, who lands that stuff?
[18:42] <coreycb> cholcombe, for openstack, typically gnuoy, jamespage or dosaboy
[18:43] <cholcombe> coreycb, oh i meant for charm-helpers
[18:43] <coreycb> cholcombe, right I was referring to openstack related charm-helpers code
[18:43] <cholcombe> gotcha
[18:44] <cholcombe> coreycb, alright i'll add one of them to the review.  thanks!
[18:44] <marcoceppi> cholcombe: there's a group of charm-helper maintainers that currate that
[18:44] <cholcombe> marcoceppi, even better
[21:53] <bdx> core, dev: hey whats going on everyone? I'm wondering which part of cinder (api, volume, scheduler) provides the image-service interface?
[21:54] <bdx> core, dev: I'm thinking it must be cinder-api..
[21:54] <bdx> or scheduler, or both...
[22:01] <marcoceppi> bdx: not sure I understand your question
[22:02] <marcoceppi> bdx: the cinder charm provides image-servce which connects to glance
[22:04] <bdx> marcoceppi: In the case you deploy cinder in a decoupled fashion, with separate volume units ..... you end up with different units running different cinder services...
[22:04] <marcoceppi> bdx: right, but we don't have a decouple charm (this is where my knowledge of the openstack charm ecosystem begins to fade)
[22:04] <bdx> marcoceppi: https://jujucharms.com/cinder/trusty/29
[22:05] <marcoceppi> bdx: beisner coreycb or ddellav might be able to help more
[22:05] <marcoceppi> bdx: OIC
[22:05] <marcoceppi> it's probably api
[22:05] <marcoceppi> but that's a guess
[22:06] <bdx> marcoceppi: how could I preform introspection into this?...there are a few different relations made to cinder that I have questionabout
[22:06] <marcoceppi> bdx: well, a better readme would be my guess
[22:08] <bdx> beisner, coreycb, ddellav, marcoceppi: so .... I have 3 availibility zones ....in order to use cinder across all 3
[22:08] <bdx> I need to run cinder volume service in the 3 separate locations
[22:09] <bdx> in which I configure each of the 3 cinder volume services to include a config-flag that specifies each zone
[22:10] <bdx> such that "cinder availibility-zone-list" shows all three zones are enabled
[22:12] <bdx> what I am trying to figure out is what relations should be made from the cinder component's interfaces to what other charms
[22:13] <marcoceppi> bdx: well it probably wouldn't hurt to connect them all to glance, tbh
[22:13] <marcoceppi> bdx: let me see if I can find a bundle with cinder spun off
[22:18] <bdx> marcoceppi: here's a small script of what I'm doing to give an idea https://gist.github.com/jamesbeedy/6429af503c3581ba9e7e
[22:19] <bdx> I have most of the relations dialed...I feel like I should just test the last few to see what happens
[22:21] <marcoceppi> bdx: whoa that is, whoa
[22:21] <bdx> ha
[22:21] <marcoceppi> bdx: I may be able to help make that script a little more managable
[22:21] <bdx> oh...do tell
[22:21] <marcoceppi> bdx: what does charmconf.yaml have in it?
[22:23] <bdx> marcoceppi: http://paste.ubuntu.com/12699829/
[22:23] <marcoceppi> bdx: yeah, you basically want a bundle
[22:24] <JerryK_> Hi! Please is there anyone able & willing to help me with maas & juju networking? Trying to figure out how to expose juju openstack services to public network
[22:25] <marcoceppi> JerryK_: I can certainly try
[22:31] <JerryK_> thanks! The thing is I have maas controller connected to internet + private network. Nodes are connected to private network + public. Everything I install through juju is exposed on the private network but I would like to move some of those services to the public one ...
[22:32] <marcoceppi> JerryK_: what maas version do you have?
[22:32] <JerryK_> Or maybe I just misunderstood how to make "the right" network layout ...
[22:32] <JerryK_> 1.8.2
[22:33] <JerryK_> and juju 1.24.6
[22:35] <JerryK_> e.g. can't find any doc on how to work with networks in juju. I see the networks section with cird as provided from maas in juju status, but that's all
[22:58] <marcoceppi> bdx: okay, took forever, https://gist.github.com/marcoceppi/1029c03170a35ca48a10 I got lazy and didn't add all the relations, but we have a way to model large scale deployments without having to write scripts and waits
[22:58] <marcoceppi> bdx: doesn't asnwer your question about relations, but it should be something that's easier to maintain over time
[22:59] <marcoceppi> JerryK_: so networking in maas is still a bit lite, do you have multiple interfaces in the services deployed with juju? or is it just a single private network?
[22:59] <marcoceppi> JerryK_: fwiw, 1.9 of MAAS makes networking and storage a first class tennant, it'll be so much easier in the next release
[23:02] <bdx> marcoceppi: that is awesome. thanks!
[23:03] <JerryK_> marcoceppi: yeah, heard about that. Code "1.9.alpha" still feels a little bit unstable but I'll give it a try
[23:05] <JerryK_> marcoceppi: juju goes directly for the network managed by maas. The node has two nic - one for private(maas managed) and second public network