[00:00] <marcoceppi> I can't remember, but probably a year or so after 2.0
[00:00] <marcoceppi> so filing a bug is a good idea
[00:00] <schkovich> marcoceppi: sure. i will file bug report; lounchpad or github?
[00:00] <marcoceppi> schkovich: launchpad
[00:00] <marcoceppi> schkovich: lmk when you do I can make sure people see it
[00:01] <schkovich> marcoceppi: thank you for assistance once again :)
[00:01] <schkovich> marcoceppi: have a nice day
[00:01] <marcoceppi> np, hopefully the core team can sort this quickly
[00:09] <schkovich> marcoceppi: it would be nice to have option to enable/disable functions per user
[00:09] <marcoceppi> schkovich: AIUI ACLs will be coming to users in 2.0
[00:11] <schkovich> marcoceppi: cool :)
[00:12] <marcoceppi> schkovich: I just did a screencap of what sharing in 2.0 looks like, since I felt bad that we weren't able to get it working
[02:10] <miken_> Is it possible to remove a service which was deployed to machine 0?
[02:11] <blahdeblah> miken_: tried "juju destroy-unit unit-name/number"?
[02:13] <miken_> blahdeblah: what I tried initially was destroy-service, which returned, but the unit is in an error state, so when I try to resolve, I just see /usr/games/sl output - I assume, warning me that if it proceeds it's going to break the env (not sure if that's something specific to the deployment environment)
[02:13] <miken_> s/but the/but as the/
[02:14] <blahdeblah> miken_: Hmmm - can't say I've seen that; Is that service deployed to other units as well?
[02:14] <miken_> Nope, just machine zero (it's the ubuntu charm with basenode)
[02:16] <blahdeblah> If it's in error state, you *might* be able to get it sorted just by "juju resolved ubuntu/0" (or whatever it's called)
[02:17] <miken_> Right - it seems I was using `juju resolve` rather than `juju resolved` . Thanks
[07:53] <jamespage> gnuoy, if you have a few seconds - https://code.launchpad.net/~james-page/charms/trusty/rabbitmq-server/tox-switchover/+merge/286139
[07:54] <gnuoy> jamespage, sure
[07:55] <gnuoy> jamespage, is the apt_cache unit test change deliberate ?
[07:58] <jamespage> gnuoy, yes - the patching was way to far down the stack
[07:59] <jamespage> gnuoy, so switched to patching cmp_revno instead
[07:59] <gnuoy> ack, it just didn't seem relevant to a move to tox
[08:00] <jamespage> gnuoy, prob is that apt is not in pypi, and I don't like relying on stuff outside of the venv
[08:00] <jamespage> it would just work tbh
[08:00] <jamespage> but its not deterministic
[08:00] <gnuoy> kk, makes sense
[08:38] <jamespage> gnuoy, well that broke osci
[08:38] <jamespage> nice
[08:39] <gnuoy> yeah, I had an inkling it might
[09:23] <jamespage> apuimedo, morning
[09:23] <jamespage> apuimedo, just running tests on https://code.launchpad.net/~james-page/charms/trusty/midonet-api/trunk/+merge/286146
[09:23] <jamespage> and then midonet-api lgtm
[09:23] <jamespage> I had to add cassandra to the tests to get the agents to generate host uuid's
[09:24] <jamespage> at least I think that was the case - also had a problem with memory on compute nodes...
[09:24] <apuimedo> mmm, It should not be necessary to have cassandra for the host uuid
[09:25] <jamespage> apuimedo, that may be surplus then - I may have got confused with midolman shutting down due to lack of memory
[09:26] <jamespage> apuimedo, let me drop that and re-check
[09:30] <apuimedo> lack of memory for sure ;-)
[09:30] <jamespage> 1.5G is not enough
[09:30] <jamespage> upped the constraint on the test to 4G
[09:36] <apuimedo> jamespage: good choice, sorry I forgot
[09:36] <apuimedo> I usually put 6G
[09:37] <jamespage> 4 works - the tests don't execute instances so there is enough
[09:41] <jamespage> apuimedo, hmm - I think cassandra is required
[09:42] <jamespage> midonet-agent won't install midolman untill the CassandraRelation is present
[09:42] <apuimedo> oh, that's right. the software does not require it, but my charm does
[09:42] <apuimedo> sorry, my bad
[09:53] <jamespage> apuimedo, ok fixed in my branch - executing all of the amulet tests now to confirm thats all ok
[09:54] <apuimedo> good
[09:54] <apuimedo> :-)
[10:45] <apuimedo> jamespage: did it work? (please say aye)
[10:45] <jamespage> apuimedo, still running but looks like it will
[10:45] <apuimedo> :-)
[10:45] <jamespage> I see a long lag on the final hook excution on midonet-api
[10:45] <jamespage> the hook is accessing the API, something times out and then it completes...
[10:45] <jamespage> but not sure what
[10:47] <jamespage> apuimedo, I think its that hang that I reported when I did my initial testing
[10:48] <apuimedo> jamespage: in my openstack env it's due to to access to the 8080 not being propertly opened by juju
[10:48] <apuimedo> haven't experienced it on maas though
[10:49] <jamespage> apuimedo, we don't have security groups turned on:-)
[10:50] <apuimedo> jamespage: anything on /var/log/tomcat/midonet* ?
[10:51] <jamespage> apuimedo, http://paste.ubuntu.com/15090189/
[10:52] <jamespage> its looping through those last few messages
[10:52] <apuimedo> from Server - jetty?
[10:55] <jamespage> apuimedo, not sure tbh
[10:55] <jamespage> that;s the midonet-api.log file
[10:57] <jamespage> apuimedo, /var/lib/juju/agents/unit-midonet-api-0/charm/hooks/host-relation-changed started running at 10:48
[10:57] <jamespage> I suspect I'll hit some sort of response timeout shortly
[11:00] <apuimedo> very odd
[11:00] <apuimedo> if you go as root in the midoent-api container
[11:01] <apuimedo> does `midonet-cli -e "host list"` show anything
[11:01] <apuimedo> or does it also block
[11:01] <apuimedo> ?
[11:01] <jamespage> apuimedo, test just completed a pulled down the env...
[11:03] <apuimedo> ok
[11:03] <apuimedo> I guess
[11:42] <jamespage> apuimedo, ok - so looking good for https://code.launchpad.net/~james-page/charms/trusty/midonet-api/trunk/+merge/286146
[11:42] <jamespage> just running the mem tests as well to verify our firewall configuration for the midokura.com repos
[11:46] <stub> Is 1.25.3 technically a development version, or did that even/odd thing get scrapped?
[11:47] <apuimedo> jamespage: I found the reason
[11:47] <jamespage> apuimedo, pray tell?
[11:47] <apuimedo> it was blocking on random number generation
[11:47] <jamespage> apuimedo, ahhhhhhh
[11:48] <apuimedo> just tomcat things :D
[11:48] <apuimedo> I'll send a patch to change the source
[11:48] <jamespage> apuimedo, oh I remember this
[11:48] <jamespage> prng on startup used to suck
[11:52] <apuimedo> yup
[11:52] <jamespage> apuimedo, sudo apt-get install haveged
[11:52] <apuimedo> on v5 we are not using tomcat anymore
[11:52] <apuimedo> haveged?
[11:52] <jamespage> not saying thats a great solution, but it does increase entropy on virt systems
[11:53] <apuimedo> jamespage: I was planning on modifyin tomcat config to have JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom"`.
[11:53] <jamespage> that works as well
[11:53] <apuimedo> ;-)
[11:55] <jamespage> apuimedo, mem +1 as well
[11:55] <apuimedo> mem +1?
[11:57] <jamespage> it passes amulet tests...
[11:57] <jamespage> for -agent and -api
[11:57] <jamespage> running amulet for neutron-agents-midonet now as well
[12:02] <apuimedo> great
[13:22] <apuimedo> jamespage: I can merge https://code.launchpad.net/~james-page/charms/trusty/midonet-api/trunk/+merge/286146 then, right? (there's the please don't merge comment still)
[13:22] <jamespage> apuimedo, go for it
[13:22] <apuimedo> thanks
[13:22] <jamespage> I have a similar one for neutron-agents-midonet - just running the tests now
[13:23] <apuimedo> cool
[13:23] <apuimedo> thanks a lot for these improvments
[13:40] <jcastro> apuimedo: hey any luck on your zfs issue?
[13:42] <apuimedo> jcastro: it went away by itself trying for the 13th time
[13:42] <jcastro> heh
[13:44] <apuimedo> jamespage: jcastro: I would like add a package to cloud-archive for mitaka
[13:44] <apuimedo> do you know who I should be speaking with?
[13:45] <jcastro> not me, someone on james' team I would guess off the bat though
[13:45] <apuimedo> cool, thanks
[13:47] <apuimedo> jamespage: midonet-api patches successfully merged
[13:47] <jamespage> apuimedo, ack
[13:47] <jamespage> apuimedo, what's the package?
[13:47] <jamespage> it needs to go into xenial development first
[13:48] <apuimedo> jamespage: kuryr
[13:48] <apuimedo> the libnetwork driver of kuryr, more specifically
[13:49] <jamespage> apuimedo, pointer?
[13:49] <jamespage> we're very close to feature freeze, but we could always go debian first if need be - its only a new leaf package
[13:54] <apuimedo> jamespage: github.com/openstack/kuryr
[14:23] <admcleod-> anyone know why 'juju status' would give me 'error: lock timeout exceeded' ?
[14:24] <lazyPower> admcleod- is your bootstrap node out of disk space?
[14:24] <lazyPower> *model controller
[14:25] <admcleod-> lazyPower: nope
[14:25] <admcleod-> lazyPower: nowhere near
[14:25] <lazyPower> thats th eonly time i've seen that error
[14:29] <jamespage> apuimedo, https://code.launchpad.net/~james-page/charms/trusty/neutron-agents-midonet/trunk/+merge/286181
[14:29] <apuimedo> thanks jamespage
[14:32] <apuimedo> jamespage: merged
[14:32] <jamespage> apuimedo, ack
[14:33] <jamespage> apuimedo, I have some general feedback on some further improvements - observability is not that great atm; but that won't block promulgation to the curated charm set
[14:33] <jamespage> apuimedo, just letting the n-a-m tests complete...
[14:34] <apuimedo> jamespage: what do you mean with observability? You mean putting status messages?
[14:34] <apuimedo> like, connection to cassandra and zookeeper not ready
[14:34] <apuimedo> for example?
[14:34] <jamespage> apuimedo, status is one aspect yes
[14:34] <apuimedo> what else?
[14:34] <admcleod-> lazyPower: well.. removing '~/.juju/current.lock' fixed it..
[14:35] <lazyPower> admcleod- well thats something i suppose
[14:35] <lazyPower> admcleod- are you running stable or 2.0-alpha* series?
[14:35] <admcleod-> lazyPower: stable
[14:55] <jose> bdx: ping
[14:56] <jamespage> apuimedo, ok - so all promulgated
[14:57] <jamespage> https://code.launchpad.net/~charmers
[14:57] <jamespage> they will injest into the charm store in the next few hours....
[14:58] <apuimedo> yay!!!
[14:58] <apuimedo> thanks a lot jamespage! I would really appreciate an email with the suggestions to improve ;-)
[15:01] <jamespage> apuimedo, two comments on https://bugs.launchpad.net/charms/+bug/1453678
[15:01] <mup> Bug #1453678: New charms: midonet-host-agent, midonet-agnet, midonet-api <Juju Charms Collection:Fix Released> <https://launchpad.net/bugs/1453678>
[15:01] <jamespage> apuimedo, thanks for all of your work on the charms - glad to get you finally landed!
[15:11] <_Sponge> | http://ubuntuonair.com/ | 50 minutees to-go :)
[15:11] <balloons> marcoceppi, jcastro, do you guys have any ideas or interest in juju + google summer of code? projects / mentors?
[15:11] <marcoceppi> balloons: yes
[15:12] <marcoceppi> I've been trying to figure out how tasks and such for GSOC
[15:15] <balloons> marcoceppi, we just need your ideas on https://wiki.ubuntu.com/GoogleSoC2016/Ideas
[15:16] <balloons> the application deadline is Friday, but we don't need more than the snippets on the wiki page. Google has to accept our application, and then the solitication of students will happen. Ideas don't have to be fully baked just yet
[15:17] <balloons> but we do need ideas + commitment to mentor
[16:00] <apuimedo> jamespage: :-)
[16:00] <apuimedo> thanks for bearing with my inexperience in charm land
[16:00] <jamespage> apuimedo, you are most welcome....
[16:53] <jose> rick_h__: mind a quick PM?
[16:53] <rick_h__> jose: not at all
[17:05] <ryotagami> Is this the correct place to ask about charmhelpers?
[17:14] <jose> bdx: lmk when you have a sec?
[17:23] <jose> ryotagami: I'd say so. ask ahead and someone will get back soon :)
[17:24] <ryotagami> jose: OK.
[17:24] <ryotagami> http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/amulet/deployment.py#L61
[17:25] <ryotagami> Line 61, by any chance the trailing comma is a typo? I don't think branch_location takes a tuple, which the trailing comma produces.
[17:30] <stub> ryotagami: Yes, that certainly looks like a bug
[17:31] <ryotagami> Ah, OK. Glad that it is confirmed.
[20:55] <cory_fu> Reviews welcome: https://github.com/juju-solutions/layer-basic/pull/36
[20:55] <cory_fu> Now you can say `@when('config.changed.my-opt')`
[21:03] <lazyPower> nice!
[23:07] <magicaltrout> here's a random question
[23:07] <magicaltrout> if I develop a charm and I deploy it
[23:08] <magicaltrout> then it gets accepted as a recommended charm and the namespace changes
[23:08] <magicaltrout> do I have to undeploy my deployed charm to change to the recommended one?
[23:24] <rick_h__> magicaltrout: no, you can switch over to it
[23:25] <magicaltrout> thanks rick_h__ I have an up to date gitlab charm that I have to deploy for a client tomorrow but it would be nice to keep it in sync if I get it into the recommended namespace
[23:25] <rick_h__> magicaltrout: yes, the upgrade-charm takes a --switch argument that let's you move to another url
[23:25] <magicaltrout> coolio
[23:25] <rick_h__> magicaltrout: so if it gets promoted you could update-charm --switch=cs:newurl
[23:39] <agunturu> Is it possible to get the details about submitted juju action
[23:40] <agunturu> juju action status only returns job id and status
[23:42] <rick_h__> agunturu: juju action status ?
[23:42] <rick_h__> agunturu: https://jujucharms.com/docs/1.25/actions
[23:43] <agunturu> That just retrurns the job id and status
[23:44] <agunturu> The python client actually provides what actions are submitted. Just wondering if there is a verbose version.