[02:17] <Hobbsee> @schedule sydney
[02:17] <Ubugtu> Schedule for Australia/Sydney: 10 Jan 02:00: LoCo Team | 10 Jan 03:00: Forum Council | 10 Jan 06:00: Kubuntu Developers | 10 Jan 08:00: Community Council | 10 Jan 23:00: Edubuntu | 12 Jan 08:00: Ubuntu Development Team
[02:24] <Jucato> @schedule
[02:24] <Ubugtu> Schedule for Etc/UTC: 09 Jan 15:00: LoCo Team | 09 Jan 16:00: Forum Council | 09 Jan 19:00: Kubuntu Developers | 09 Jan 21:00: Community Council | 10 Jan 12:00: Edubuntu | 11 Jan 21:00: Ubuntu Development Team
[02:31] <Jucato> @schedule Manila
[02:31] <Ubugtu> Schedule for Asia/Manila: 09 Jan 23:00: LoCo Team | 10 Jan 00:00: Forum Council | 10 Jan 03:00: Kubuntu Developers | 10 Jan 05:00: Community Council | 10 Jan 20:00: Edubuntu | 12 Jan 05:00: Ubuntu Development Team
[04:16] <Joey_> nickserv
[04:16] <Joey_> ?
[04:16] <Joey_> MOTD
[04:23] <Proletariat> hello?
[04:29] <proletariat420> hello?
[04:29] <proletariat420> did i miss it?
[04:34] <lifeless> miss what
[05:06] <proletariat420> i heard this was a meeting for ubuntu?
[05:14] <_ion> Please see the topic.


[06:01] <AskUbuntu> juju server relation hook files are not running? | http://askubuntu.com/q/505310
[08:27] <AskUbuntu> juju charm relation-joined hook not working? | http://askubuntu.com/q/505342
[09:09] <jamespage> marcoceppi, hey - do you think it would be possible to have an openstack-charmers review queue like we have a charmers on on jujucharms.com?
[09:10] <jamespage> marcoceppi, I'm struggling with visibility of proposed changes right now and a central report would be useful for everyone
[09:10] <jamespage> gnuoy, ^^
[11:24] <marcoceppi> jamespage: yes, I'm in the process of re-doing the review queue to be way more robust. In doing so it'll be a stand alone application that anyone can run and configure to track changes for whatever user/group/project
[11:24] <marcoceppi> as such, we could spin up an instance on canonistack to track openstack-charmers stuff
[11:57] <jamespage> marcoceppi, sounds good
[11:58] <marcoceppi> jamespage: it's a little lower priority than everything else, but it's on my personal "I really care about this and want it done" list
[11:58] <jamespage> marcoceppi, if you have something in flight maybe post a branch? I'm happy to hack on this as well
[11:59] <marcoceppi> jamespage: I have early musing of some pyramid stuff, nothing connected to lp or gh yet
[11:59] <marcoceppi> just a databases schema
[11:59] <marcoceppi> jamespage: https://github.com/marcoceppi/review-queue
[12:00] <marcoceppi> I hope to get more time on it this weekend, get celery and lp hooked up for initial imports
[12:48] <mfa298> I've got a Juju instance bootstrapped within Openstack using trusty. Is it possibly to use that to deploy a charm that uses precise or is that not supported (I've got the precise image in glance but can't see a way to tell Juju where to find that image).
[12:51] <marcoceppi> mfa298: you'll need to upload a custom image-metadata file to juju
[12:51] <marcoceppi> so it'll know where the precise images are
[12:52] <mfa298> that's presumably created with juju metadata generate-image, how do I then upload it ?
[12:52] <marcoceppi> mfa298: great question, I forget how, but I believe it's done at bootstrap time
[12:52]  * marcoceppi checks
[12:53] <mfa298> so it may not be possible to upload after bootstrap
[12:54] <marcoceppi> mfa298: does not appear, but again I'm not 100% certain, it's something that's defined in the environments.yaml https://juju.ubuntu.com/docs/config-openstack.html
[12:54] <marcoceppi> However, let me check set-environment
[12:55] <marcoceppi> mfa298: you can update this after bootstrap
[12:55] <marcoceppi> with `juju set-environment image-metadata-url="url-to-generated-metadata"`
[13:00] <mfa298> hmmm, looking at the metadata that generate-metadata created for the precise image it seems to reference 14.04 rather than 12.04
[13:02] <marcoceppi> mfa298: you should be able, as a command line option, provide a series flag
[13:02] <marcoceppi> mfa298: with the -s flag
[13:02] <mfa298> I'd just spotted that
[13:08] <mfa298> looks like juju still can't find the image
[13:09] <marcoceppi> mfa298: what do the logs look like when trying to deploy a precise charm?
[13:10] <mfa298> debug-log shows machine-0: 2014-08-01 13:07:20 WARNING juju.worker.instanceupdater updater.go:231 cannot get instance info for instance "": no instances found
[13:10] <mfa298> and the machine state in juju status shows: agent-state-info: '(error: index file has no data for cloud {RegionOne http://<IP_ADDRESS>:5000/v2.0}
[13:11] <marcoceppi> mgz_: who should I bug about juju deploying to openstack?
[13:12] <mfa298> trying juju metadata  validate-images seems to suggest it's using cloud-images.ubuntu.com rather than the local images, although that could be me missing something
[13:12] <mgz_> marcoceppi: that'd pretty generic
[13:12] <mgz_> what more specifically?
[13:13] <mgz_> I'm a pretty good atrting point
[13:13] <marcoceppi> mgz_: mfa298 is trying to upload image-metadata post bootstrap, not sure the process as I've never tried
[13:13] <mgz_> I see, reading log
[13:18] <mgz_> setting up image-metadata is something you do prior to bootstrap
[13:19] <mfa298> so having bootsrapped juju with it only knowing about trusty there's not a way to add in precise other than destroying the environment and bootstrapping again ?
[13:19] <mgz_> yup
[13:20] <mfa298> or is this going down the wrong route for what I was hoping to acheive.
[13:20] <mgz_> if you're setting this up yourself, you should instead make your keystone advertise the simplestreams
[13:20] <mgz_> rather than have juju supply it at run time
[13:23] <mfa298> quickly googled and that looks like it might be what I want. Is there a decent guide somewhere for setting that up ?
[13:26] <mgz_> mfa298: https://juju.ubuntu.com/docs/howto-privatecloud.html
[13:27] <marcoceppi> mgz_: whoa, where has this link been all my life
[13:28] <marcoceppi> also, wow tha page is rendered wrong
[13:28]  * marcoceppi goes to patch
[13:35] <mfa298> mgz_: I've done the juju metadata generate-image commands and have the metadata files which contain both the precise and trusty files.
[13:35] <mfa298> the issue seems to be getting that into juju
[13:36] <mfa298> I can run juju set-environment image-metadata-url=file://home/ubuntu but I still don't seem to be able to deploy a charm using precise
[13:37] <mfa298> or is the answer here that I need to have a web server to provide those files rather than file://
[13:37] <mgz_> no, that doesn't help
[13:38] <mgz_> you set those values in your environments.yaml at the start, and they need to be accessible from the cloud you've deployed, eg in swift
[13:38] <mgz_> file:// is no good
[13:39] <mfa298> so installing a webserver would be enough or do I also need to destroy the environment and bootstrap again with the url configured as well
[13:49] <mfa298> looks like a http server is enough. That seems to be working
[13:49] <mfa298> thanks
[13:52] <mfa298> now to work out the sets of commands that were actually needed so I can write the local documentation
[13:56] <jcastro> sebas5384, arosales: hi
[13:57] <sebas5384> hey jcastro!
[13:57] <arosales> sounds like jose has us set up
[13:57] <jcastro> oh cool
[13:57] <jcastro> link?
[13:57] <arosales> just in case I am going to joing the old hangout in case any folks join there
[13:57] <jose> ohai
[13:57] <jose> jcastro: sec
[14:00] <sebas5384> link?
[14:00] <sebas5384> :P
[14:01] <arosales> Just a quick reminder to folks that we will be hosting on ubuntuonair.com not via the google hangout event.
[14:03]  * marcoceppi tunes in
[14:03] <arosales> I confirmed no folks are in the Google Event hangout, which is good
[14:05] <jcastro> sebas5384, https://plus.google.com/hangouts/_/ytl/vjVQa1PpcFNNnOvmc6cVeIQVTxHO4-o-wB5b0uus7JY
[14:06] <arosales> also we'll be using the following document to capture input
[14:06] <arosales> https://docs.google.com/a/canonical.com/document/d/1t_55N1il3XoL8z-jfa1CBoSxzOQjC90cgSpCqx5wkH0/edit
[14:06] <arosales> we'll be starting in a couple of minutes.
[14:06] <lazyPower> ah ok we haven't started yet. I was following along on Ubuntu on Air and its still broadcasting please stand by.
[14:07] <arosales> lazyPower: correct haven't staretd yet.
[14:07] <jose> :P
[14:08] <sebas5384> i'm there!
[14:08] <jose> we should have a slide saying 'Hey! We're late, but don't go!'
[14:10] <arosales> jose: looks like we are running into a perms issue
[14:11] <arosales> jose: are you in the hangout?
[14:11] <jose> arosales: I am
[14:11] <arosales> jose: jorge and I are in the hangout but don't see you.
[14:11] <jcastro> jose, can you paste the link in here?
[14:11] <jcastro> the one you PMed me isn't the one you are in apparently
[14:11] <cory_fu> Regarding the first point, I think what we really need is an extension to `juju resolved --retry` that essentially does a forced upgrade-charm before retrying the failed (or maybe even last successful) hook.  `juju resolved --upgrade-and-retry`
[14:11] <sebas5384> i'm already there, but i cant hear jose
[14:11] <jose> https://plus.google.com/hangouts/_/ytl/vjVQa1PpcFNNnOvmc6cVeIQVTxHO4-o-wB5b0uus7JY
[14:12] <zirpu> i thought the hangout wasn't being used today.
[14:12] <jose> I could go ahead and create another event
[14:13] <jose> arosales, jcastro: want me to create another event?
[14:13] <jcastro> Why don't we all just join the same hangout?
[14:13] <jcastro> I am confused why there are two?
[14:13] <sebas5384> jose: can you hear me?
[14:13] <jose> sebas5384: not at all
[14:14] <sebas5384> damn it
[14:14] <sebas5384> hangout is trolling us
[14:14] <jose> blame Google
[14:14] <jose> aaaalways happens
[14:14] <jcastro> what hangout are you in? can you paste in the URL?
[14:14] <jose> jcastro: https://plus.google.com/hangouts/_/ytl/vjVQa1PpcFNNnOvmc6cVeIQVTxHO4-o-wB5b0uus7JY
[14:14] <sebas5384> https://plus.google.com/hangouts/_/g6mlkq4hfo6jvgjqmvksxo3inia?authuser=1&hl=pt-BR
[14:14] <jose> wait... that's another hangout link
[14:14] <jose> urgh
[14:14] <jcastro> ...
[14:14] <jose> I believe Google is playing with us
[14:15] <jcastro> ok which hangout link are we going to?
[14:15] <jose> we have different links
[14:15] <jcastro> pick one
[14:15] <jose> https://plus.google.com/hangouts/_/ytl/vjVQa1PpcFNNnOvmc6cVeIQVTxHO4-o-wB5b0uus7JY is the one I'm in
[14:15] <sebas5384> permissions problems
[14:16] <jose> let me just quickly create another event. Google is a mess atm
[14:16] <jcastro> do you have them set to private or something?
[14:16] <jose> not at all
[14:17] <jcastro> hmmm
[14:17] <jcastro> ok fire up a new one I guess
[14:17] <jose> https://plus.google.com/hangouts/_/ytl/vjVQa1PpcFO4tsipIQdBcOcv_43jywHwKQvrzxaa9XA=
[14:17] <zirpu> the ubuntu-on-air one was supposed to replace the hangout.
[14:17] <jose> jcastro, arosales, sebas5384: ^
[14:18] <sebas5384> now i'm in the last link you passed jose
[14:18] <arosales> this one is looking better
[14:18] <jose> zirpu: ubuntuonair uses hangouts :)
[14:18] <arosales> jcastro: I am in
[14:19] <jose> refresh ubuntuonair if you were in before
[14:20] <arosales> we got it started
[14:20] <arosales> Thanks for the patience.
[14:21] <arosales> live on ubuntuonair.com or join the hangout @ https://plus.google.com/hangouts/_/ytl/vjVQa1PpcFO4tsipIQdBcOcv_43jywHwKQvrzxaa9XA=
[14:22] <zirpu> i switched to the ubuntuonair version. i'm just listening.
[14:35] <cory_fu> You can give debug-hooks a hook name to only have it trigger on the one hook you're interested in fixing.
[14:35] <cory_fu> I just learned this the other day.  Very helpful
[14:37] <cory_fu> jcastro: If local-mapped-to-remote charm source is not an option, my preferred alternative would be `juju resolved --update-and-retry`
[14:38] <lazyPower> thats good to know cory_fu. We should make that more pronounced in the docs, which might help alleviate some of that frustration.
[14:46] <lazyPower> noodles775: you've done roles with ansible scripts in charms correct?
[14:47] <lazyPower> i'm fairly sure its still very experimental at present right? we haven't ironed out how it shoud look
[14:47] <lazyPower> jcastro: we dont have --force on service.
[14:48] <jcastro> ack
[14:48] <arosales> lazyPower: thanks.
[14:48] <cory_fu> If you --force destroy the machine out from under the service, you can then remove the service
[14:48] <zirpu> i think the ansible buffering is a function of the parallelism code. so make ansible serial and lower the polling from the default 15 seconds.
[14:49] <lazyPower> cory_fu: i think the idea is more that they want to force destroy the service, and leave the machine, so they aren't waiting for a machine spin up
[14:49] <lazyPower> jcastro: you're left with a service definition, with no units.
[14:50] <cory_fu> lazyPower: If you redeploy after removing a service, it creates a new machine.  If you use --to to put it on the same machine, that's not much different than upgrade-charm.  But I guess it would force it to re-run all of the hooks, at least.
[14:51] <lazyPower> well, the scary part about what's being asked is deploying to a tainted machine may yield really crazy results
[14:51] <lazyPower> but i get what you're saying cory_fu
[14:51]  * cory_fu isn't arguing against adding --force to destroy-service, though.
[14:51] <cory_fu> I've tried to do that many times, even after realizing it doesn't work.
[14:51] <lazyPower> haha
[14:51] <lazyPower> it gets me too
[14:51] <lazyPower> more often than i care to admit... and i know it doesn't exist.
[14:51] <lazyPower> muscle memory i suppose
[14:52] <cory_fu> :)
[15:13] <arosales> lazyPower: is this: http://manage.jujucharms.com/~lazypower/precise/dns your latest DNS charm?
[15:13] <sebas5384> arosales: Handrus and Renato where here too :)
[15:14] <arosales> ah thanks Handrus and Renato!
[15:15] <arosales> sebas5384: take a lookt at http://manage.jujucharms.com/~lazypower/precise/dns just need to confirm this is the last rev from lazyPower (re DNS)
[15:15] <lazyPower> arosales: it is. i sync'd it a few weeks ago witht he latest work.
[15:16] <arosales> lazyPower: thanks for confirming.
[15:21] <jose> hey guys! question around here. I'm working on a chamilo-memcached relation, and it would allow multiple servers. when I do 'relation-get host', will it tell me just one IP address, or multiple IP addresses?
[15:22] <jose> (in the event I have multiple memcached instances)
[15:23] <benji> now
[15:23] <benji> wrong window :)
[15:25] <marcoceppi> jose: you can infer all the hosts at once if you wanted to
[15:25] <marcoceppi> jose: using relation-list
[15:25] <marcoceppi> jose: then just loop through the list
[15:26] <jose> hmm, I'm gonna check how that may work for me in a debug-hooks session
[15:26] <marcoceppi> memcached_hosts=`relation_list`; for m  in "$memcached_hosts"; do relation-get host $m >> /file/to/track/hosts; done
[15:26] <marcoceppi> as an example
[15:26] <jose> cool
[15:26] <marcoceppi> the relation-get is from memory
[15:27] <marcoceppi> but there's a way to specify which unit you wish to query in a relation context
[15:45] <jcastro> lazyPower, https://github.com/juju/docs/pull/135
[17:33] <sebas5384> lazyPower: thanks!!! could you show us how to use it? http://manage.jujucharms.com/~lazypower/precise/dns
[19:23] <lazyPower> sebas5384: its not production ready yet. There's no HA support as of yet.
[19:23] <lazyPower> if you use that, and your DNS charm server tanks, you've lost DNS
[19:23] <lazyPower> sebas5384: but i'm more than happy to talk you through the implementation details, and how its structured / how to implement hooks.
[19:25] <lazyPower> sebas5384: take a look at https://github.com/chuckbutler/DNS-Charm - and scroll down to CHARM Integration, it talks about a programmable and programmable-multiple relationship hook. You set the proper variables, and it will build the configuration on the fly for you. The DNS charm itself spits out the public-address OTW so you can update /etc/resolve.conf as the primary DNS server, and your domains will then be avialble to each node connected to the dns
[19:25] <lazyPower> charm.
[19:25] <lazyPower> sebas5384: there's more implementation logic that needs to happen with regard to updating third party providers, and/or implementing your DNS server in the global DNS tree with your registrar (if you want it to be authoritative)
[19:30] <jcastro> lazyPower, hey so btw my last PR didn't touch the precise box URLs
[19:30] <jcastro> so you might want to pull those
[19:30] <lazyPower> ack was already on it
[19:31] <lazyPower> jcastro: just in master? or do i need to touch another branch?
[19:34] <lazyPower> jcastro: https://github.com/juju/docs/pull/136
[19:49] <jcastro> lazyPower, LGTM, merged
[19:50] <jcastro> lazyPower, marco told me a while back it's better to just do all the work in personal branches and then submit to master
[19:50] <jcastro> rather than under the juju namespace
[19:50] <jcastro> I was like, ok, sounds good to me
[19:50] <lazyPower> jcastro: thats what i did
[19:50] <jcastro> yeah, I saw
[19:50] <jcastro> I was just responding to your irc question
[19:50] <lazyPower> oh you mean the web editor
[19:50] <lazyPower> well i was curious which branch to target
[19:50] <lazyPower> if i needed to touch the 1.18 docs as well
[19:50] <lazyPower> not that we are still actively pointing anything at them
[20:07] <lazyPower> actually no need to sync, just riddle me this batman
[20:07] <lazyPower> https://code.launchpad.net/~asanjar/charms/trusty/hdp-hadoop/trunk <-- hortonworks?
[20:08] <lazyPower> https://code.launchpad.net/~asanjar/charms/trusty/hdp-zookeeper/trunk <-- has first traces of hortonworks charm helpers?
[20:13] <asanjar> lazyPower: yes, that is hortonworks .. but if you need to investigate  bdutils.py (general big data charm helper) or hdputils.py (hortonworks dirstro specific charm helpers)  look at ~asanjar/charms/trusty/hdp-zookeeper
[20:15] <asanjar> lazyPower: as soon as I get a chance, I will update hortonworks hadoop with the latest helper..
[20:16] <lazyPower> ok thats all i needed
[20:16] <lazyPower> I'm wrapping up my last fringe issues thsi week with vagrant that jcastro just brought to me
[20:16] <lazyPower> Monday is when i start digging heavy into teh apache hadoop rewrite
[23:31] <AskUbuntu> Swift Through Horizon | http://askubuntu.com/q/505650


[16:38] <topyli> oh
[16:39] <topyli> for the record, the above factoid is not needed. slovenian channel is -si not -sl
[16:44] <topyli> !si
[16:44] <topyli> so we do need a factoid still
[17:17] <topyli> that's at least from someone who knows the language. however, they told me they're not an official loco yet. i couldn't reach the ops though
[17:53] <durt> hey folks, ubottu died.
[17:54] <durt> thx
[18:01] <jpds> Oh, auto_bleh failed.
[18:04] <jpds> bazhang: You called?
[21:15] <UbuntuMartyr> I need to join #ubuntu, NOW.
[21:16] <UbuntuMartyr> HURRY UP
[21:18] <elky> ah, so there's a reason the floodbot didn't exempt him?
[21:18] <nalioth> i think he's banned for being himself
[21:19] <elky> yeah, i sort of suspected. his manner of engagement was as endearing as a mosquito
[21:19] <elky> anyway, werk tiem
[21:30] <Flannel> He's WhyUbuntuSucks from lastnight
[21:31] <Flannel> maine.res.rr and all that jazz
[23:06] <eternaljoy> Cannot join #ubuntu (You are banned) <--- any possiblity of having this lifted?
[23:09] <Flannel> eternaljoy: Can you give us a good reason to?
[23:10] <eternaljoy> Flannel: ok
[23:10] <eternaljoy> because I am not the same person I used to be. People change, and in the last year I have grown more mature and more respectful of people. I have geuinly learned a lot and learned to be cautious of how I speak and deal with people
[23:11] <eternaljoy> everyone deserves a chance to change. yes?
[23:13] <Flannel> eternaljoy: Of course.  And you're aware of, and agree to follow our channel guidelines?
[23:13] <Flannel> ( https://wiki.ubuntu.com/IrcGuidelines )
[23:13] <eternaljoy> yes 100%.. and I realise I am on last ever chance, and will honour the rules
[23:14] <eternaljoy> especially the rule that says "Don't be annoying
[23:14] <eternaljoy> " :)
[23:14] <eternaljoy> hehe ;)
[23:14] <Flannel> eternaljoy: Alright, let me find it to remove it.
[23:14] <eternaljoy> thank you
[23:15] <Flannel> eternaljoy: Can you join #ubuntu right now? (can you try?)
[23:15] <eternaljoy> yes
[23:15] <eternaljoy> Cannot join #ubuntu (You are banned).
[23:15] <Flannel> Hmm
[23:15] <eternaljoy> yeah still banned
[23:16] <Flannel> alright, let me find the ban manually
[23:17] <eternaljoy> ok
[23:21] <elky> Flannel, in his ventures of ban evading, there's likely many to remove. possibly even a d ban
[23:21] <Flannel> elky: I don't see one
[23:21] <Flannel> Ah, there it is.
[23:22] <eternaljoy> elky i give you my word, i will abide by the rules in future. I promise
[23:24] <Flannel> eternaljoy: Alright, I believe I've removed all of your bans
[23:24] <eternaljoy> Flannel: yes, ty. im in
[23:25] <eternaljoy> cheers, bye. I am in ubuntu now.
[23:26] <Flannel> He's still got an akick for his old cloak that I can't remove
[23:27] <nalioth> removed


[00:05] <mup> Bug #1554797 opened: juju 2.0 bootstrap should explain what was missing <juju-core:New> <https://launchpad.net/bugs/1554797>
[00:05] <mup> Bug #1554802 opened: juju deploy should give more information, or less <juju-core:New> <https://launchpad.net/bugs/1554802>
[00:05] <mup> Bug #1554807 opened: juju backups restore makes no sense <juju-core:New> <https://launchpad.net/bugs/1554807>
[00:10] <alexisb> so a noob go question what exactly does the "..." do
[00:10] <alexisb> so for example you have "...string" instead of "string"
[00:11] <davecheney> it's the varargs operator
[00:11] <davecheney> so in a function declaration
[00:11] <davecheney> func f (args ...string) lets you write
[00:11] <mup> Bug #1554802 changed: juju deploy should give more information, or less <juju-core:New> <https://launchpad.net/bugs/1554802>
[00:11] <mup> Bug #1554807 changed: juju backups restore makes no sense <juju-core:New> <https://launchpad.net/bugs/1554807>
[00:11] <davecheney> f("a", "b", "c")
[00:12] <davecheney> inside f args will be of type []string
[00:12] <alexisb> ok thanks davecheney
[00:12] <davecheney> alexisb: https://golang.org/ref/spec#Passing_arguments_to_..._parameters
[00:12] <menn0> alexisb: also: https://gobyexample.com/variadic-functions
[00:13] <davecheney> it's slightly confusing when using f if you aready have a []string
[00:13] <davecheney> in that case you have to use the ... as a suffix
[00:13] <davecheney> var s []string
[00:13] <menn0> alexisb: ... can also be used during a function call to expand a slice into separate arguments
[00:13] <davecheney> f(s...) // don't treat s, []string as a single argument, treat it as the arguments
[00:14] <alexisb> o! davecheney that last bit is very helpful
[00:14] <mup> Bug #1554802 opened: juju deploy should give more information, or less <juju-core:New> <https://launchpad.net/bugs/1554802>
[00:14] <mup> Bug #1554807 opened: juju backups restore makes no sense <juju-core:New> <https://launchpad.net/bugs/1554807>
[00:18] <davecheney> alexisb: we have both styles inside juju
[00:18] <davecheney> if you have a fn that already uses a []string (or another slice) then it can be a little more work to pass it down to something else with the ... suffix
[00:19] <davecheney> OTOH we have many APIs that take a []slice of things, but almost always are called with just one thing
[00:19] <davecheney> so there is a lot of typing to declare a literal slice of just one thing, in which case changing those APIs to be variadic can make them more pleasant to use
[00:21] <alexisb> thank you davecheney; that explanation gave me the insight I needed to figure out how to update the func call
[00:21] <alexisb> geeze I wasted too much time on that :)
[00:22] <davecheney> wallyworld: everything was going so well
[00:22] <davecheney> lucky(~/src/github.com/juju/juju) % juju create-model testing2
[00:22] <davecheney> ERROR provider validation failed: invalid EC2 provider config: model has no access-key or secret-key
[00:22] <davecheney> create model the right thing ?
[00:22] <davecheney> a controller has many models ?
[00:22] <davecheney> so if I have the local.testing controller
[00:23] <davecheney> i should be able to create a new model in that ?
[00:23] <wallyworld> davecheney: currently, as of forever, each time you create a new model, you need to supply credentials
[00:23] <wallyworld> but
[00:23] <wallyworld> there's a feature branch which relaxes that requirement
[00:23] <davecheney> so, i dn't need credentials to create the first model
[00:23] <wallyworld> if you are controller admin, you don't need to re-suipply
[00:23] <wallyworld> correct
[00:23] <davecheney> but every subsiquent one I do ?
[00:23] <davecheney> wat ?
[00:23] <wallyworld> yes, that was the jes design
[00:24] <wallyworld> you were on that team :-)
[00:24] <davecheney> so much for avoiding head trauma
[00:24] <davecheney> wallyworld: I blame tim
[00:24] <davecheney> by default
[00:24] <wallyworld> we are fixing it for 2.0. there was a valid reason at the time
[00:37] <arosales> Hello juju-core!
[00:37] <arosales> should I see juju 2.0 in the Xenial archive when I apt-cache search or apt-get install juju?
[00:37] <arosales> I am currently only seeing 1.25, but could be pilot error
[00:39] <arosales> scratch that I see 2.0-beta1-0ubuntu1~16.04.1~juju1  in the archive
[00:40] <arosales> keep up the good work. Looking forward to beta2
[00:51] <axw> wallyworld: hey sorry I missed standup, didn't get home till 1:30am, so slept in a bit
[00:51] <davecheney> wallyworld: is the format of creds.yaml document ?
[00:51] <wallyworld> davecheney: it's in the release notes
[00:51] <wallyworld> axw: no worries :-) did you want a chat now?
[00:51] <davecheney> wallyworld: ta
[00:52] <axw> wallyworld: sure, will be in tanzanite in a minute
[00:52] <wallyworld> davecheney: the tooling is improving around managing creds, not quite there yet
[00:52] <alexisb> wow, first experience of existing unit test catching an actual error I introduced into the code
[00:52] <alexisb> nice
[00:53] <wallyworld> davecheney: https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U
[00:53] <wallyworld> alexisb: yay tests :-)
[00:53] <alexisb> btw davecheney I always blame tim by default as well ;)
[00:54] <axw> wallyworld: there now
[01:09] <mup> Bug #1554819 opened: juju help create-model is misleading <juju-core:New> <https://launchpad.net/bugs/1554819>
[01:09] <perrito666> wallyworld: are you around?
[01:09] <wallyworld> perrito666: in standup hangout with andrew
[01:09] <perrito666> jam: you dont have the pre push script in your git
[01:09] <perrito666> wallyworld: that is an invitation?
[01:10] <wallyworld> we are talking work stuff so feel free
[01:13] <katco> wallyworld: natefinch: fyi: https://github.com/juju/juju/compare/nate-minver#files_bucket
[01:13] <wallyworld> katco: ty, will look after meeting
[01:13] <katco> wallyworld: natefinch: nate-minver has master merged in; can merge into master with a bless
[01:18] <thumper> well that took longer than I was expecting...
[01:18] <thumper> but I guess I should expect that
[01:20] <thumper> menn0: http://reviews.vapour.ws/r/4100/
[01:26] <menn0> thumper: looking
[01:26] <thumper> menn0: I'm just preparing a branch to merge master into model-migration
[01:26] <thumper> menn0: and I'm thinking we should merge model-migration-control into model-migration
[01:27] <menn0> thumper: I was thinking the same thing
[01:27] <thumper> menn0: because you are going to want these functions RSN
[01:27] <menn0> thumper: indeed
[01:27] <thumper> cool
[01:27] <thumper> let's get model-migration synced up with master first
[01:27] <thumper> because I think model-migration-control is ahead of it there
[01:27] <menn0> thumper: CI has picked up a timing problem with one of the tests which I'm working on now
[01:27] <menn0> thumper: and we can merge afterwards
[01:28] <thumper> sounds good
[01:28]  * thumper has make check running on merge master
[01:28] <thumper> good time to go make a coffee
[01:38] <thumper> yep
[01:38] <thumper> tests still running
[01:38] <davecheney> thumper: that's how you know your change is good :)
[01:38] <davecheney> thumper: how long do the tests ttake on your machine ?
[01:38] <davecheney> mine are the best part of 30 mins
[01:39] <thumper> I don't think I have timed a full run recently
[01:39] <thumper> it used to be around 23 minutes
[01:44] <davecheney> it takes 25 mins in CI
[01:44] <davecheney> my times are 30-40 mins locally
[01:48] <thumper> hmm...
[01:48] <thumper> my machine has going suspiciously quiet
[01:48] <davecheney> time.Sleep(60 * time.Minute)
[01:48] <thumper> github.com/juju/juju/cmd/jujud/dumplogs
[01:48] <thumper> last pass
[01:49] <davecheney> somethings' waiting for monog to time out
[01:49] <davecheney> then you will receive _ALL_ the stack traces
[01:49] <thumper> \o/
[01:54] <davecheney> lucky(~/src/github.com/juju/juju) % juju list-models
[01:54] <davecheney> NAME     OWNER        LAST CONNECTION
[01:54] <davecheney> testing  admin@local  20 seconds ago
[01:54] <davecheney> lucky(~/src/github.com/juju/juju) % juju destroy-model testing
[01:54] <davecheney> ERROR "testing" is a controller; use 'juju destroy-controller' to destroy it
[01:54] <davecheney> so, is "testing" a model or not !?!
[02:04] <thumper> davecheney: cmd/jujud/reboot timed out
[02:04] <davecheney> rup row
[02:04] <thumper> davecheney: testing is probably the controller model
[02:07] <thumper> ah poo
[02:07] <thumper> someone has added another exported field to serviceDoc
[02:07]  * thumper goes to see what it is
[02:08] <thumper> CharmModifiedVersion
[02:08] <thumper> wallyworld: do you know about this? ^^
[02:08] <thumper> maybe?
[02:08] <wallyworld> thumper: that i believe is from the resources work
[02:08] <thumper> hmm..
[02:08] <thumper> yeah
[02:08] <thumper> nate did it
[02:09] <wallyworld> it is used to track whether a chanr for a service has changed at all
[02:09] <wallyworld> and fires a hook if needed
[02:09] <thumper> for what purpose?
[02:09] <wallyworld> if resources change
[02:09] <wallyworld> a hook is fired
[02:09] <wallyworld> it uses the same pattern as we use for config-changed hooks
[02:10] <wallyworld> thumper: although why that is on the serviceDoc i am not sure
[02:11] <wallyworld> i guess for config we always fire an initial config changed hook
[02:11] <wallyworld> whereas for charm-upgrade we don't want to do that
[02:15] <davecheney> menn0: 2016-03-09 00:08:41 INFO juju.worker runner.go:281 stopped "engine", err: cannot open api: agent should be terminated
[02:16] <davecheney> is this a dependency engine thing ?
[02:16] <davecheney> i've never seen that final error message
[02:18] <menn0> davecheney: that's something fwereade's been working on I believe although I didn't realise it was in master
[02:18] <menn0> davecheney: when are you seeing it?
[02:18] <davecheney> in master
[02:19] <menn0> davecheney: I under conditions I meant?
[02:21] <davecheney> oh, bootstrap worked but the rest of the agents in the deploy just went to sleep and never woke
[02:21] <davecheney> i'll have to redeploy to figure out what happened
[02:21] <davecheney> to be fair, I did a backup while units were deploying
[02:21] <davecheney> then restored the backup over the top
[02:21] <menn0> davecheney: that would do it
[02:21] <davecheney> I didn't expect that to be a good result
[02:22] <davecheney> i just wanted to see how many pieces broke off
[02:22] <menn0> davecheney: i believe that you get that error when a machine or entity can't be found at login (or is no longer in the Alive state)
[02:23] <menn0> davecheney: they thing that connects to the API returns that error in that case, which has special meaning: stop the agent and uninstall from the init system so it doesn't get restarted
[02:23] <menn0> davecheney: that behaviour has been there forever
[02:23] <menn0> davecheney: but Will has been fixing and improving that functionality
[02:23] <davecheney> and that is indeed what it did
[02:23] <davecheney> agent stoped and the upstart job went away
[02:23] <menn0> davecheney: i'm not sure if you're dealing with the old or the new version of it (not sure where fwereade is at with merging)
[02:25] <menn0> davecheney: I have no idea how restore is actually supposed to be used - i.e. what are the expected preconditions
[02:25] <davecheney> me neither
[02:25] <davecheney> which makes it a bit hard to tell if I broke it
[02:26] <menn0> thumper: review done
[02:26] <thumper> menn0: ta
[02:26] <menn0> davecheney: really though you shouldn't be able to hose things like this using it
[02:32] <thumper> davecheney: can I get you to try cmd/jujud/reboot tests?
[02:32] <thumper> even running by themselves, they are timing out
[02:42] <thumper> menn0: re Backend
[02:42] <thumper> menn0: was talking to fwereade this morning
[02:42] <thumper> before that it was stateMethods
[02:43] <thumper> he suggested using backend
[02:43] <thumper> so I went for consistency
[02:43] <thumper> happy to be more descriptive
[02:43] <menn0> thumper: I was thinking something like BinariesUploadBackend, or just UploadBackend
[02:43] <thumper> hmm...
[02:44] <menn0> thumper: given that there's other stuff in migration.go that's not related to tools/charms upload
[02:44] <menn0> thumper: I don't feel too strongly about it if you disagree
[02:44] <thumper> hmm...
[02:44] <thumper> sounds fine
[02:44]  * thumper makes changes
[02:49] <thumper> tools/lxdclient/client_instance.go:331: wrong number of args for format in Tracef call: 1 needed but 2 args
[02:49] <thumper> how did this even get into master?
[02:49] <menn0> thumper: yeah, I saw that too
[02:49] <thumper> I thought we caught that shit
[02:50] <davecheney> % juju deploy wordpress -n 3 && juju deploy mysql -n 2 && juju add-relation wordpress mysql
[02:50] <davecheney> [Units]
[02:50] <davecheney> ID          WORKLOAD-STATE AGENT-STATE VERSION     MACHINE PORTS    PUBLIC-ADDRESS MESSAGE
[02:50] <davecheney> mysql/0     error          idle        2.0-beta2.1 4       3306/tcp <IP_ADDRESS>  hook failed: "db-relation-joined" for wordpress:db
[02:50] <davecheney> mysql/1     unknown        idle        2.0-beta2.1 5       3306/tcp <IP_ADDRESS>
[02:50] <davecheney> wordpress/0 unknown        executing   2.0-beta2.1 1       80/tcp   <IP_ADDRESS>
[02:50] <davecheney> wordpress/1 maintenance    executing   2.0-beta2.1 2                <IP_ADDRESS> (config-changed) installing charm software
[02:50] <davecheney> wordpress/2 unknown        executing   2.0-beta2.1 3       80/tcp   <IP_ADDRESS>
[02:50] <davecheney> \o/ reproducable builds
[02:59] <natefinch> thumper: I'm around if you want to talk about CharmModifiedVersion
[03:02] <natefinch> actually, brb
[03:05] <natefinch> back
[03:09] <thumper> menn0: http://reviews.vapour.ws/r/4100/ updated
[03:09] <thumper> hi natefinch
[03:10] <thumper> natefinch: what is the purpose of the number?
[03:10] <natefinch> thumper: we needed to update the service doc such that it would trigger charm-upgrade for something other than changing its charm url
[03:11] <natefinch> thumper: this is because charm-upgrade is supposed to fire when resources change
[03:11] <natefinch> thumper: so when resources change, we increment CharmModifiedVersion (we also increment it when the charm url changes, just in case)
[03:13] <thumper> ok
[03:14] <natefinch> thumper: the PR review, if you're curious: http://reviews.vapour.ws/r/3910/
[03:15] <mup> Bug #1554863 opened: juju bootstrap does not error on unknown or incorrect config values <juju-core:New> <https://launchpad.net/bugs/1554863>
[03:17] <thumper> menn0: my update to model-migrations landed (master)
[03:17] <thumper> menn0: I'll propose one that merges model-migration-control
[03:17] <thumper> and look
[03:18] <mup> Bug #1554863 changed: juju bootstrap does not error on unknown or incorrect config values <juju-core:New> <https://launchpad.net/bugs/1554863>
[03:21] <mup> Bug #1554863 opened: juju bootstrap does not error on unknown or incorrect config values <juju-core:New> <https://launchpad.net/bugs/1554863>
[03:23] <thumper> menn0: http://reviews.vapour.ws/r/4102/
[03:23] <thumper> if you are happy to merge that branch in, lets do it
[03:26] <menn0> thumper: yep, I have that test fix ready
[03:26] <menn0> thumper: 2 secs
[03:27] <thumper> menn0: so.. you are going to merge one final thing into the model-migratiion-control branch first?
[03:27] <thumper> menn0: when it has the right commits, I'll let you get the bot to merge the two
[03:27] <menn0> thumper: yep, just this: http://reviews.vapour.ws/r/4103/ (review pls)
[03:27] <menn0> thumper: yep, I can handle the merge
[03:28] <natefinch> wallyworld: you around?
[03:28] <menn0> thumper: mm-control into mm right?
[03:28] <wallyworld> yup
[03:28] <thumper> menn0: yeah, this one: https://github.com/juju/juju/pull/4662
[03:29] <menn0> thumper: ah right, you've already done the merge
[03:29] <thumper> menn0: well, I clicked on a github button
[03:29] <thumper> not a lot to do really :)
[03:29] <wallyworld> natefinch: did you have a q?
[03:30] <menn0> thumper: so that PR should update if I get further changes into model-migration-control I guess
[03:31] <thumper> menn0: why add the wait?
[03:32]  * thumper actually reads the comment
[03:32] <natefinch> wallyworld: yes, so... I was going to write those tests for charm push-resource by mocking out the http Client... however, it occurs to me, that it's pretty damn fragile to do it that way.  I mean, it requires the tests to know what exact responses some package two layers away is expecting.. totally breaks encapsulation and relies on internal implementation details.
[03:33] <thumper> menn0: to be honest, still not sure why it waits
[03:33] <menn0> thumper: yeah, it took me a while of looking at the shared api watcher loop code to figure it out
[03:33] <menn0> thumper: there's a goroutine which calls Stop as the client side loop exits. it's outside of the main loop monitored by the tomb and can run *after* the worker loop exits
[03:34] <menn0> thumper: it never happens on my machine but it does in CI, especially on i386, ppc and arm
[03:34] <wallyworld> natefinch: yeah, for unit tests that's not very useful. that's where the CharmStore strcu can help. but then we need tests to ensure CharmStore does the right thing. and we do at some point need to next the calling of the csclient
[03:34] <thumper> menn0: but what does that do?
[03:35] <thumper> menn0: so are we saying that sometimes on other architectures, the results don't come as fast?
[03:35] <menn0> thumper: yep, on slower or different archs that cleanup goroutine runs a bit later and so the test wasn't seeing the Stop call
[03:36] <menn0> thumper: https://github.com/juju/juju/blob/master/api/watcher/watcher.go#L73-L86
[03:37] <thumper> menn0: shipit
[03:38] <menn0> thumper: ship it for http://reviews.vapour.ws/r/4100/
[03:38] <menn0> 2 little suggestions
[03:41] <natefinch> wallyworld: well, I have tests to test that charmstore works and I have tests that test that csclient works... we should also have some full stack CI and/or feature tests, but if those fail, it really just means we have some assumptions that aren't well communicated in our APIs and not covered in our unit tests, which could be fixed easily.
[03:41] <natefinch> s/charmstore/charmrepo.CharmStore
[03:42] <thumper> menn0: ta
[03:42] <wallyworld> natefinch: yep, a feature test to round it all out sounds like is all we need now
[03:42] <natefinch> wallyworld: ok
[03:42] <thumper> menn0: ah... yeah, sould have fixed those
[04:23] <natefinch> my kingdom for people to use an interface, once in a while, somewhere.
[04:24] <mup> Bug #1507867 changed: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Expired> <https://launchpad.net/bugs/1507867>
[04:36] <mup> Bug #1507867 opened: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Expired> <https://launchpad.net/bugs/1507867>
[04:39] <mup> Bug #1507867 changed: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Expired> <https://launchpad.net/bugs/1507867>
[04:39] <mup> Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <lxc> <maas-provider> <network> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1546561>
[04:42] <natefinch> ug.... I can't believe the charm command depends on code inside github.com/juju/juju  .... and of course it's now broken
[04:48] <mup> Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <lxc> <maas-provider> <network> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1546561>
[04:54] <mup> Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation <lxc> <maas-provider> <network> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1546561>
[05:32] <wallyworld> axw: could i get a small review? https://github.com/juju/charm/pull/196
[05:33] <axw> wallyworld: ok, looking
[05:40] <axw> wallyworld: VerifyLocal isn't used anywhere except in a test. where will it be used?
[05:41] <axw> wallyworld: oh, this is just the charm package. it'll be used in juju... never mind
[05:41] <wallyworld> axw: i'm doing a core branch that will use it - wehn we deploy bundles with local charm paths
[05:41] <axw> wallyworld: LGTM
[05:41] <wallyworld> i almost have that branch ready
[05:41] <wallyworld> ty
[06:41] <davecheney> dummy is the only provider that imports the apiserver
[06:41] <davecheney> and it doesn't do anything with the api
[06:41] <davecheney> if I delete the call to the apiserver from Dummy's bootstrap method
[06:41] <davecheney> millions of tests fail
[08:10] <TheMue> morning o/
[08:20] <jam> davecheney: fundamentally after bootstrap completes we should have an API server running. Its just that all other bootstraps do it via "jujud bootsrap-???".
[08:59] <fwereade> davecheney, the main thing is that the dummy provider is basically evil -- but I'm pretty sure it *does* do things with the api? in that it exposes the info necessary to connect to the api, which comes from the apiserver it actually runs
[09:00] <fwereade> davecheney, the fact that a "dummy" provider goes so far as to actually run an apiserver is the heart of the problem
[09:00] <fwereade> davecheney, life would be better if dummy were dumber
[09:01] <fwereade> davecheney, jam: is there a name for that style of test double, that attempts to *simulate* some external component, and invariably ends up hideously complex and brittle?
[09:02] <dooferlad> frobware: hangout?
[09:31] <davecheney> fwereade: i want to find out what dummy is doing and move it into a test suite
[09:32] <davecheney> the interesting thing is not all of the tests fail, only some packages, albeit spectularly
[09:32] <davecheney> so I suspect that a byproduct of importing dummy is the get a sort of kind of working api server, which we helpfully advertise via a package singleton, and have logic that avoids reinitalising it if it is already present
[09:34] <fwereade> davecheney, yeah, and we have that happy fun Reset lark as well :(
[09:35] <fwereade> davecheney, fwiw, tests that *don't* fail when you break dummy would be excellent candidates for disentangling from JujuConnSuite, I think
[09:35] <fwereade> davecheney, easier bits to carve off the edges, hopefully makes it easier to see what the pleftover problematic tests are depending on, maybe?
[09:39] <davecheney> the sadface was I wasn't trying to eviscerate dummy
[09:39] <davecheney> i was actually doing some refactoring of th apiserver
[09:39] <davecheney> and found a bonkers circular dependency from juju/testing to dummy to the apiserver
[10:03] <frobware> dimitern, jam: standup?
[10:39] <rogpeppe> i need a second review on this simple change to the charm package; anyone care to take a look? https://github.com/juju/charm/pull/195
[10:43] <dimitern> rogpeppe, isn't it better to switch to yaml.v2 throughout?
[10:43] <rogpeppe> dimitern: i'm not going to be responsible for changing juju-core to use yaml.v2 throughout
[10:44] <dimitern> rogpeppe, I meant the charm package
[10:44] <rogpeppe> dimitern: and it's kinda reasonable to be compatible with both, i think
[10:44] <rogpeppe> dimitern: it does use yaml.v2 only
[10:44] <rogpeppe> dimitern: but clients can use yaml.v1 to marshal a Meta value
[10:44] <rogpeppe> dimitern: and i don't want to break that
[10:45] <dimitern> rogpeppe, any important differences between v1 and v2 wrt behavior ?
[10:45] <rogpeppe> dimitern: there are a few differences - i think they were documented somewhere
[10:45] <rogpeppe> dimitern: *most* of juju-core seems to use v2 now
[10:45] <dimitern> rogpeppe, so marshaling with v1 and unmarshaling with v2 works as well as vice versa?
[10:46] <rogpeppe> dimitern: it's possible that the only two places in core which use v1 are doing so by mistake
[10:46] <rogpeppe> dimitern: yeah
[10:46] <rogpeppe> dimitern: it's still YAML
[10:47] <dimitern> rogpeppe, btw I had some issues recently with changes spanning multiple subrepos with slightly different dependencies.tsv
[10:47] <rogpeppe> dimitern: yeah, it can be awkward
[10:47] <rogpeppe> dimitern: i've found the new -N flag to godeps very useful
[10:47] <dimitern> rogpeppe, it turned out we don't have a good way of enforcing same revs across multiple related projects
[10:47] <rogpeppe> dimitern: for converging on an agreed set of deps
[10:47] <dimitern> rogpeppe, what does it do?
[10:48] <rogpeppe> dimitern: it updates dependencies only if the deps are newer than what's already there
[10:48] <dimitern> rogpeppe, that's useful indeed
[10:48] <rogpeppe> dimitern: i think there is fundamentally no way of enforcing revs across projects
[10:49] <rogpeppe> dimitern: separate projects are independent
[10:49] <dimitern> rogpeppe, there should be a way to declare nested deps for juju/juju/ at least and other standalone projects
[10:49] <dimitern> rogpeppe, that PR LGTM btw
[10:50] <rogpeppe> dimitern: what do you mean by "nested deps"?
[10:50] <dimitern> rogpeppe, i.e. dependencies.tsv or juju/juju "including" other .tsvs per import path
[10:51] <rogpeppe> dimitern: what would it do if those tsvs conflicted?
[10:51] <dimitern> rogpeppe, some way to verify revisions in juju/juju/deps.tsv for repo X matches the rev used by repo Y that depends on X, and juju/juju depends on both X and U
[10:51] <dimitern> s/U/Y/
[10:52] <rogpeppe> dimitern: that sounds like it's going to produce conflicts more often than not
[10:52] <dimitern> rogpeppe, if they conflicted, you can know and do something about it, rather than get random build failures for subrepos (like I had for charm.v6 recently)
[10:53] <rogpeppe> dimitern: what I tend to do now is something like: for repo in $(awk '{print $1' < dependencies.tsv}); godeps -N -u $(godir $repo)/dependencies.tsv; done
[10:54] <dimitern> because charm.v6 needs bundlechanges, which in turn needs revX of yaml.v1 (and charm.v6 uses revY of yaml.v2), effectively refusing to build charm.v6 unless it also depends on yaml.v1 with same revX
[10:54] <rogpeppe> dimitern: you got a build failure in charm.v6 because of a juju/juju tsv file?
[10:55] <rogpeppe> dimitern: if in doubt, choose the latest version of all dependencies
[10:55] <rogpeppe> dimitern: because it's fairly unusual for something to depend on being *earlier* than a certain revision
[10:55] <dimitern> rogpeppe, yeah, that's what I usually do - and that works well for repos with merge gating that uses godeps -u as part of testing the merge
[10:57] <rogpeppe> dimitern: one problem is that it's allowed to have cyclic dependencies between repos
[10:57] <rogpeppe> dimitern: at least you had a build failure rather than a bug later on
[10:58] <dimitern> rogpeppe, yeah, that's causing some of the issues I suppose
[10:58] <rogpeppe> dimitern: i found that godeps -N eased my pain quite a bit
[10:58] <dimitern> rogpeppe, this is the issue I was talking about: https://github.com/juju/bundlechanges/pull/16
[10:58] <rogpeppe> dimitern: 'cos you can just run it without worrying too much
[10:59] <dimitern> rogpeppe, bundlechanges thus far didn't have to depend on yaml.v2, but without it it won't build as charm.v6 needs it
[11:00] <rogpeppe> dimitern: charm.v6 doesn't need it
[11:00] <rogpeppe> dimitern: only its tests do
[11:00] <rogpeppe> dimitern: if you run godeps, it'll tell you that
[11:03] <dimitern> rogpeppe, so you're saying that gating job for bundlechanges should've called godeps -u -t dependencies.tsv instead?
[11:04] <rogpeppe> dimitern: i don't understand. that's an invalid godeps command.
[11:05] <rogpeppe> dimitern: the gating job for bundlechanges should always call godeps -u dependencies.tsv as usual
[11:06] <dimitern> rogpeppe, the "-t" according to "godeps -h" updates tests deps as well
[11:08] <rogpeppe> dimitern: ah, that's an ambiguity in the help. -t is a no-op with -u.
[11:08] <rogpeppe> dimitern: it only influences whether testing deps are printed without the -u flag.
[11:08] <rogpeppe> dimitern: -u always updates all the deps mentioned
[11:11] <dimitern> rogpeppe, ah, didn't know that detail :) thanks
[11:12] <rogpeppe> dimitern: i should probably make the docs clearer
[11:16] <dimitern> +1 :)
[11:16]  * dimitern steps out for ~1h
[12:08] <xnox> who is on-call reviewer?
[12:08] <xnox> =) please review
[12:08] <xnox> https://github.com/juju/utils/pull/199
[12:16] <TheMue> xnox: S390? Mainframe?
[12:16] <TheMue> xnox: neat
[13:01] <dooferlad> dimitern: http://reviews.vapour.ws/r/4002/ should, I hope, be ready.
[13:02]  * dooferlad goes for lunch
[13:02] <dimitern> dooferlad, cheers, will look shortly
[13:34] <mup> Bug #1555083 opened: Certificate error when visiting the embedded Juju GUI <juju-core:New> <https://launchpad.net/bugs/1555083>
[13:56] <dimitern> dooferlad, we should have a quick chat when you're back
[14:12] <perrito666> I am not sure you people saw this since its the sort of stuff that happens during the night :p
[14:12] <perrito666> https://docs.google.com/spreadsheets/d/1mczKWp3DUuQvIAwZiORD29j5LRb96QZC4mZDn72gAE4/edit#gid=0
[14:12] <perrito666> quite interesting
[14:12] <perrito666> comes from https://github.com/davecheney/benchjuju
[14:15] <natefinch> ...and this is why I still build with 1.4
[14:17] <natefinch> btw, the discussion among the Go devs: https://groups.google.com/forum/#!topic/golang-dev/DpMyPbclI3o
[14:19] <natefinch> also, looks like the govmomi code is a SIGNIFICANT addition to our compile times
[14:20] <natefinch> and this is probably why: https://github.com/juju/govmomi/blob/master/vim25/types/types.go
[14:22] <perrito666> natefinch: curious name :p
[14:23] <natefinch> perrito666: it's the vmware cloud api wrapper
[14:23] <perrito666> I was talking about the vim part :p
[14:25] <natefinch> yeah, dunno
[14:27] <perrito666> the whole juju takes 1m3.982s here
[14:28] <perrito666> 55s of that are jujud
[14:28] <natefinch> perrito666: what go version are you using, and did you remove $GOPATH/pkg first?
[14:29] <perrito666> 1.5
[14:29] <perrito666> natefinch: yep
[14:29] <perrito666> on my desktop
[14:30] <perrito666> if I tried this on my laptop I would get significantly higher numbers
[14:30] <TheMue> simply imagine juju would be written in C++ making high usage of boost.
[14:31] <TheMue> heya btw
[14:31] <natefinch> perrito666: is that real time or user time?
[14:32] <perrito666> natefinch: real
[14:32] <perrito666> natefinch: do you know how can I run the test build step without running the actual tests?
[14:35] <natefinch> perrito666: go test -run=xxx
[14:35] <natefinch> perrito666: it's still slow as hell, since it builds a binary per package
[14:35] <perrito666> natefinch: that is what I want
[14:35] <natefinch> perrito666: but obviously faster than actually running tests
[14:38]  * perrito666 times the test build times
[14:42] <dooferlad> perrito666: to speed up subsequent runs go test -i will install deps rather than using them as a one-off build.
[14:43] <dooferlad> dimitern: did you want to jump in a hangout?
[14:43] <perrito666> dooferlad: tx
[14:44] <natefinch> perrito666: 28s building with go 1.4.2, 1m5s building with go 1.5.3
[14:44]  * natefinch goes back to 1.4
[14:45] <dimitern> dooferlad, sure, is top of the hour ok?
[14:45] <perrito666> time go test  --run=xxx github.com/juju/juju/... <--- 7m16.197
[14:45] <dooferlad> dimitern: yep
[14:47] <dimitern> frobware, voidspace, dooferlad, please have a look at http://reviews.vapour.ws/r/4104/
[14:48] <dooferlad> dimitern: *click*
[14:48] <ericsnow> natefinch: PTAL http://reviews.vapour.ws/r/4099/
[14:48] <dimitern> the diff got messed up somewhat - ipaddresses_test.go is entirely new, while the legacy_ipaddresses_test.go is unchanged
[14:48] <ericsnow> natefinch: also, I responded in http://reviews.vapour.ws/r/4090/
[14:51] <TheMue> natefinch: buy a faster computer *lol*
[14:51] <natefinch> TheMue: the fastest computer in the world isn't going to make 1.5 compile faster than 1.4 ;)
[14:51] <natefinch> ericsnow: thanks
[14:52] <perrito666> interesting, when timing it some tests fail
[14:52] <ericsnow> natefinch: no, thank you!
[14:52] <katco> ericsnow: natefinch: o/
[14:52] <ericsnow> katco: \o
[14:52] <natefinch> ericsnow: I think I'd prefer that service-exists check on the way out... so we are sure we don't get into a race condition
[14:52] <katco> ericsnow: natefinch: got master merged into minver... i think if we get a bless it will be in 2.0!
[14:52] <natefinch> katco: amazing, thanks so much!
[14:52] <TheMue> natefinch: that's right, I only described typical behavior needing always more faster computers to do the same as before
[14:53] <natefinch> TheMue: yep
[14:53] <ericsnow> katco: sweet
[14:53] <katco> natefinch: thanks for coding it up. just wish it wasn't a rushed blitz at the end to land features
[14:53] <ericsnow> natefinch: that's a good idea, I'll try it out
[14:53] <natefinch> ericsnow: i.e. try the DB op, see that it failed, check if the service exists, if not, then we have a good idea why it failed ;)
[14:54] <ericsnow> katco: the mad rush is really making it hard to collaborate with others in the same situation :(
[14:54] <katco> ericsnow: i know... there are many, many, negatives
[14:59] <natefinch> ericsnow, katco: working on reviews and getting my stuff landed this morning. See if we can drain that under review column some
[15:00] <ericsnow> natefinch: +1
[15:00] <katco> yeah nk
[15:00] <dooferlad> dimitern: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire ?
[15:00] <katco> i'm very sorry i haven't been able to perform reviews... i just have 1 last thing in my backlog
[15:00] <natefinch> esp since we don't actually have any points landed yet :/
[15:01] <dimitern> dooferlad, omw
[15:01] <ericsnow> natefinch: I could land this one with re-review from katco (hint, hint): http://reviews.vapour.ws/r/3975/
[15:01] <ericsnow> katco: :)
[15:01] <katco> ericsnow: ok ok you just popped to the head of the queue
[15:04] <perrito666> natefinch: the almost full test run on my desktop 16m58.859s
[15:04] <natefinch> perrito666: yeah.... *shudder*
[15:04] <katco> cherylj: did you say the lxd instance with no ssh issue had a fix, or some progress had been made?
[15:08]  * TheMue remembers the times when juju has been so small running build and tests in a few seconds
[15:10] <natefinch> TheMue: must have been long before I got here :)
[15:15] <katco> ericsnow: you have a review, sir
[15:15] <cherylj> katco: the outstanding issues that I know about with lxd have been addressed.
[15:16] <ericsnow> katco: (ノ^_^)ノ┻━┻ ┬─┬ ノ( ^_^ノ)
[15:16] <katco> cherylj: hm, ok. i think jrwren was having some issues
[15:16]  * ericsnow puts table back
[15:16] <katco> lol
[15:16] <cherylj> heh
[15:16] <katco> ericsnow: you've been hanging around wwitzel3 too long
[15:16] <katco> cherylj: sounds like it may have been a lxd issue though... cmars is chatting with jrwren
[15:17] <katco> cherylj: hey, when can we expect a bless on the nate-minver branch?
[15:18] <cherylj> katco: I think that depends on the content of that branch ;)
[15:18] <cherylj> katco: are you asking when to expect a CI run?
[15:18] <katco> cherylj: yes :)
[15:24] <TheMue> natefinch: yep, and we've been a small team too. porting juju from python to go, later exchanging zookeeper with mongo
[15:25] <TheMue> natefinch: and in a pre-api era, only direct access to the database
[15:59] <katco> cherylj: ping, have an answer for me yet? :)
[16:13] <cherylj> katco: sorry, was on a call.
[16:13] <natefinch> ericsnow: ug.. in that check extension patch... you were right to wonder where the definition for formatMediaType was.... it was in files that didn't get added to git... and unfortunately subsequently got deleted as I switched between branches.
[16:13] <katco> cherylj: no worries
[16:14] <cherylj> sinzui or abentley would know better than I
[16:14] <ericsnow> natefinch: :(
[16:14] <cherylj> about what the queue looks like
[16:14] <katco> natefinch: switching branches shouldn't delete files i don't think?
[16:14] <ericsnow> natefinch: you don't need it if you use a query arg <wink>
[16:14] <natefinch> katco: no, but when you look and see a resources directory that shouldn't exist and so you delete it.... they do :/
[16:15] <katco> ...
[16:15]  * natefinch clutches his foot where he shot it.
[16:15] <natefinch> luckily this was just the code to copy the FormatMediaType code from 1.6, so it's pretty trivial to replace.
[16:16] <natefinch> ericsnow: IETF says it should be in the filename param of the content-disposition.
[16:16] <ericsnow> natefinch: for server responses (not requests), no?
[16:17] <abentley> katco: it appears to be 6th in the order.
[16:17] <perrito666> oh please, dont pass content metadata in query parameters, that is a sin in several major religions
[16:17] <katco> abentley: cool, ty! any eta?
[16:18] <natefinch> ericsnow: UNder the section called "Form-based File Upload in HTML" :  "The original local file name may be supplied as well, either as a 'filename' parameter either of the 'content-disposition: form-data' header or in the case of multiple files in a 'content-disposition: file' header of the subpart."
[16:18] <abentley> katco: roughly a day, everything going smoothly.
[16:18] <katco> abentley: great, thanks :)
[16:18] <natefinch> ericsnow: http://tools.ietf.org/html/rfc1867
[16:18] <natefinch> ericsnow: search for filename
[16:18] <abentley> katco: Less if any of the branches ahead of it have failed to update their version number :-)
[16:19] <katco> lol
[16:19] <ericsnow> natefinch: that's for form-based upload
[16:19] <ericsnow> natefinch: I suppose you could interpret this that way
[16:19] <natefinch> ericsnow: yes, and the GUI guys will thank me when they want to write a form to let people upload resources :)
[16:19] <ericsnow> natefinch: I still think it makes more sense as a query arg
[16:20] <ericsnow> natefinch: good point, though they will still have to supply the other query arg
[16:20] <katco> abentley: i'm glad you said something... it looks like the version is wrong in the nate-minver branch b/c we were fiddling with that file
[16:20] <katco> abentley: master has what it's supposed to be set at?
[16:21] <abentley> katco: Right.
[16:23] <abentley> katco: We actually tried to test it earlier today: http://reports.vapour.ws/releases/3724
[16:24] <rick_h__> ericsnow: natefinch +1 to gui wanting to upload resources down the road
[16:25] <natefinch> rick_h__: is content-disposition:  "formdata; filename=foo.zip" the correct place for a filename for a file we're uploading?  I'd like to make sure we're using a standard place
[16:25] <katco> abentley: looks like this was the issue? "[description-setter] Could not determine description."
[16:26] <abentley> katco: No, the issue was that get_git_version failed to determine the version.  Description-setter tries to include the version so that's why *it* failed.
[16:27] <katco> abentley: 1-line review? http://reviews.vapour.ws/r/4106/
[16:28] <katco> abentley: gah actually hold on. totally screwed that up
[16:30] <katco> abentley: ok, corrected
[16:31] <rick_h__> natefinch: the filename comes up from the browser, I'd defer to hatch on it since it's been a while since I tinkered with it.
[16:31]  * hatch pokes head in
[16:32] <natefinch> hatch: file upload via http... we want to include the filename... Content-Disposition: form-data; filename=foo.zip  ... or just pass it as a query param?
[16:32] <natefinch> hatch: note this is in Go code, so we can make it do wahtever we want... but I want it to stick to standards so no one is surprised down the road
[16:33] <hatch> this is for resources I see from the backscroll?
[16:33] <natefinch> yeah, uploading resource files to the controller
[16:34] <natefinch> from your local machine
[16:34] <hatch> do we want to allow people to upload multiple files or are we saying it needs to be in an archive(zip)
[16:34] <katco> ericsnow: can you give me a 1-line review? http://reviews.vapour.ws/r/4106/
[16:34] <natefinch> filename was a stand-in.  It'll be one at a time
[16:35] <ericsnow> katco: sure
[16:35] <natefinch> filename=foo.somedata :)
[16:35] <ericsnow> katco: LGTM
[16:36] <katco> ericsnow: ty
[16:37] <hatch> natefinch: ahh ok so one at a time....sounds good to me
[16:37] <hatch> natefinch: so sorry I don't understand the question - you want to know what information we will be sending? I suppose that depends on what resources requires, I'm not really familiar with it
[16:38] <mup> Bug #1555211 opened: Model name that "destroy-model" accepts doesn't match "list-models" output <juju-core:New> <https://launchpad.net/bugs/1555211>
[16:38] <natefinch> hatch: sorry, no... I'm wondering what the standard way is to include the filename for an HTTP upload of a file
[16:39] <natefinch> hatch: my googling suggests a header with Content-Disposition: form-data; filename=foo.something   ... but just wanted to make sure that was correct
[16:39] <hatch> ohh NOW i understand what you're asking
[16:39] <hatch> ;D
[16:39] <hatch> sorry
[16:39] <hatch> yes that is good
[16:39] <hatch> :)
[16:39] <natefinch> no, my fault for not describing it more clearly
[16:39] <natefinch> coo
[16:39] <natefinch> cool
[16:40] <natefinch> ericsnow: FWIW, that's what chrome produces when you do a file upload, too (granted, that's explicitly from a webpage not a raw API call... but it seems like a good idea to mimic a browser when doing http calls, to make our lives easier later)
[16:41] <ericsnow> natefinch: okeedokee :)
[16:52] <perrito666> natefinch: http cares little about if you are using a web form or just making the request by hand
[17:00] <cory_fu> Anyone have any idea what "agent-status: failed" means?  http://pastebin.ubuntu.com/15335596/
[17:05] <perrito666> cory_fu: that juju failed (workload being the charm)
[17:05] <perrito666> I would guess juju failed to run the relation-changed hook?
[17:06] <cory_fu> perrito666: The workload status doesn't show any error
[17:07] <perrito666> cory_fu: unless its a bug, agent status shows errors from juju itself and workload errors in the charm, (agent is being renamed to juju-status in 2.0 to make this more clear)
[17:08] <perrito666> cory_fu: so this might mean that the workload itself is ok but juju could not run the hook
[17:08] <perrito666> cory_fu: I am not sure I am explaining this clearly :(
[17:09] <cory_fu> No, I understand.  This seems to be the error that caused it: http://pastebin.ubuntu.com/15335783/
[17:09] <cory_fu> After that, the log is just filled with "failed to start "uniter" manifold worker: dependency not available" messages
[17:10] <perrito666> cory_fu: using master?
[17:10] <cory_fu> 1.25
[17:11] <perrito666> cory_fu: could you submit a dmesg on that machine?
[17:12] <perrito666> that should be trying to write in /var/lib/juju/.../agent.conf
[17:12] <perrito666> I am a bit worried that you get an io timeout
[17:13] <cory_fu> perrito666: Where should I submit that?
[17:40] <ericsnow> uiteam: the resources endpoints shouldn't be in the v4 API, right?
[17:44] <ericsnow> rogpeppe, rick_h__: ^^^
[17:44] <rogpeppe> ericsnow: that's right
[17:45] <ericsnow> rogpeppe: the v4 ReqHandler embeds the v5 one, so the endpoints get pulled along for the ride :(
[17:45] <rogpeppe> ericsnow: delete 'em from the map
[17:45] <ericsnow> rogpeppe: k
[17:53] <mup> Bug #1555248 opened: help text for juju destroy-controller needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1555248>
[17:53] <mup> Bug #1555260 opened: (1.25.3) agent-status: failed (could not write settings ... timeout) <juju-core:New> <https://launchpad.net/bugs/1555260>
[18:11] <bogdanteleaga> any reason wily isn't here? https://github.com/juju/utils/blob/master/series/supportedseries.go#L92
[18:11] <rogpeppe> uiteam: migration tests (still not for the new channels model though): https://github.com/juju/charmstore/pull/567/files
[18:56] <natefinch> ericsnow: what do you think for the "filename" constant name? FilenameParam?  pretty much every combination of words I can think of is confusing in some way
[18:57] <ericsnow> natefinch: if possible, I'd not use a constant (or declare the constant right next to where you use it); I'd expect it to be used in 1 place inside a helper
[18:58] <natefinch> ericsnow: well, 2 places, one for setting and one for getting
[18:59] <natefinch> ericsnow: which is why I made it a constant.... 2 places in the same file, I could almost just swing making it a raw string... it just makes me twitch
[18:59] <ericsnow> natefinch: really the string should be hidden away in some library helper; beyond that I'd say just use some ridiculous (non-exported) name that explicitly declares it
[19:00] <natefinch> ericsnow: filenameParamForContentDispositionHeader... got it
[19:01] <ericsnow> natefinch: the tricky thing is that the value is dependent part of a "standard" and should be hidden away in something that couples it to handling that RFC
[19:01] <ericsnow> natefinch: fine with me :)
[19:02] <natefinch> ericsnow: I agree, believe me.  I hate implementing standards ad-hoc in the middle of the rest of my code.
[19:02] <ericsnow> natefinch: yeah, no joke :(
[19:05] <mup> Bug #1555291 opened: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555291>
[19:09] <natefinch> ericsnow: the build tag means only build if go 1.6 is not defined.... I was calling this _go15 to indicate it's go 1.5 (and below)... I just didn't know how to indicate "and below".  open to suggestions.
[19:10] <ericsnow> natefinch: just drop _go15 bit; given the existence of a _go16.go file, that implies the alternative covers everything else
[19:12] <natefinch> ericsnow: good point.   I was using them as placemarkers, too, hoping to delete all of those files once we move to 1.6 for everything.. but I think the TODOs are ok
[19:13] <ericsnow> natefinch: it may also make sense to reverse that, using XXX.go for the 1.6+ code and XXX_pre-go16.go for the rest
[19:14] <natefinch> ericsnow: I think I like that better, since in theory we should be able to just delete all the go15 files at some point
[19:14] <ericsnow> natefinch: exactly
[19:14] <mup> Bug #1555291 changed: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555291>
[19:14] <ericsnow> natefinch: make the exceptional case stand out
[19:14] <natefinch> ericsnow: nice, thanks
[19:15] <ericsnow> natefinch: np
[19:15] <ericsnow> natefinch: also, I left a few more comments on that review request
[19:15] <ericsnow> natefinch: but that should be about it for me :)
[19:18] <natefinch> ericsnow: at least filenames are trivial to change
[19:26] <thumper> o/
[19:29] <mup> Bug #1555291 opened: TestStartInstancePopulatesNetworkInfoWithoutAddressAllocation fails on centos <centos> <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555291>
[19:41] <katco> ericsnow: natefinch: new version of the architectural doc up. relevant section on the charm command pasted into https://docs.google.com/document/d/1T_7XQ-pmE4gFiD2SSaZnQUqlcLkA7dk0c0PB_ebEkrI/edit# for discussion
[19:41] <ericsnow> katco: thanks
[19:42] <katco> ericsnow: natefinch: and now i'm free for reviews! what can i do?
[19:43] <natefinch> katco: https://github.com/juju/charmrepo/pull/65  http://reviews.vapour.ws/r/4047/  http://reviews.vapour.ws/r/4006/  https://github.com/CanonicalLtd/charmstore-client/pull/181
[19:43] <katco> natefinch: ty
[19:44] <ericsnow> natefinch: I have http://reviews.vapour.ws/r/4090/ and http://reviews.vapour.ws/r/4099/, but natefinch's 4006 should take priority
[20:03] <natefinch> ericsnow: ship it on the file extension stuff?
[20:04] <ericsnow> natefinch: I'd still like to see that copied code in a separate package (like we've done in the past for code copied from the stdlib, etc.)
[20:04] <natefinch> ericsnow: bah, ok... yes, that's probably for the best
[20:05] <deanman> I'm interested on writing a new provider for a cloud infra not currently supported. Do i have to write it in Go or can i use other programming lanugages?
[20:06] <ericsnow> natefinch: I explained a little more in a comment on my review
[20:06] <katco> deanman: at the moment, you'll have to write it in go
[20:06] <katco> deanman: all providers live in the main repo here: https://github.com/juju/juju/tree/master/provider
[20:07] <katco> deanman: we've tried to push for a plug-in model in the past so that you can write providers in any language, but that has been met with resistance. if that's something you'd like to see, please do reach out on the mailing list
[20:07] <deanman> Can i wrap an already provided CLI tool in a Go provider or do i have to implement REST calls in Go from scratch?
[20:08] <katco> deanman: i think the implementation doesn't matter so much. juju just needs to know how to interop with your provider
[20:09] <ericsnow> deanman: adding dependencies on some CLI may also be a harder sell (harder than depending on some 3rd party Go library)
[20:10] <deanman> katco: Is there any guide on how to start about on such a project?
[20:11] <katco> deanman: https://github.com/juju/juju/wiki/Implementing-environment-providers
[20:11] <katco> deanman: i also have some diagrams that aren't on the wiki (my fault) if you're interested
[20:12] <deanman> I wanted to be able to manage eucalyptus infrastructure and did try to use the AWS one but it seems Euca was returning something extra (although claiming close to 100% AWS compatibility) so i decided whether it is reasonable to implement it from scratch...
[20:12] <katco> deanman: we do have some precedent for similar providers
[20:13] <katco> deanman: the recommendation is that you find the commonality, split that out into modules of responsibility (e.g. authenticator, instanceCreator, whatever), and then pass those into each provider which would receive interfaces
[20:13] <deanman> katco: What do you mean? (yeah i would be interested in any material i can get to start researching and hacking)
[20:21] <katco> deanman: architectural diagrams. here's probably the most helpful one: https://www.dropbox.com/s/kxlg150cjm3sggl/drivers-class.eps?dl=0
[20:22] <katco> deanman: it may be a bit out of date, but combined with the wiki that should get you going
[20:25] <deanman> katco: thank you for your help...
[20:25] <natefinch> deanman: hopefully it would be a matter of tweaking the AWS provider so it can work with Eucalyptus as-is (without harming AWS compatibility)... if that's not feasible, refactor it so you can swap out the parts that need to be different between the two
[20:25] <katco> deanman: hth, and welcome to the juju community ^.^
[20:26] <katco> natefinch: that would add cyclomatic complexity... best not to have several if statements in the body of the provider
[20:26] <deanman> natefinch: Yeah, i believe so, some first tests showed that euca was returning a "timestamp" field which aws provider didn't expect or something like that..
[20:27] <natefinch> katco: hopefully it wouldn't just be if statements... I was thinking more like being slightly more flexible about the expected responses etc
[20:27] <katco> natefinch: and how would you implement that flexibility? ... :)
[20:28] <natefinch> katco: depends on how you need to be flexible... ignoring fields you don't understand, rather than erroring out, for example.
[20:29] <katco> natefinch: and how would you make that decision to ignore the field?
[20:29] <katco> natefinch: tldr; at some point you're talking about a branching conditional, i.e. cyclomatic complexity
[20:35] <ericsnow> natefinch: thanks for addressing all my concerns! :)
[20:35] <ericsnow> natefinch: LGTM
[20:38] <natefinch> ericsnow: thanks for helping making the code better :)
[20:39] <ericsnow> natefinch: teamwork! :)
[20:39]  * natefinch sings kumbaya
[20:41] <mup> Bug #1555325 opened: Active model determination is weak <docteam> <juju-core:New> <https://launchpad.net/bugs/1555325>
[20:47] <mup> Bug #1555325 changed: Active model determination is weak <docteam> <juju-core:New> <https://launchpad.net/bugs/1555325>
[21:02] <mup> Bug #1555325 opened: Active model determination is weak <docteam> <juju-core:New> <https://launchpad.net/bugs/1555325>
[21:09] <natefinch> dammit godeps
[21:16] <katco> ericsnow: natefinch: standup time
[21:58] <thumper> :-(
[21:59] <thumper> just found that doing /o\ on my rigged standing desk is double fail
[21:59] <thumper> all tilts
[22:00] <menn0> thumper: http://reviews.vapour.ws/r/4107/ please (boring one)
[22:01]  * thumper looks
[22:02] <thumper> shipit
[22:02]  * thumper is poking around with service leadership...
[22:05] <thumper> oh FFS
[22:05]  * thumper headdesks
[22:05] <thumper> sometimes I think we do things hard just for the hell of it
[22:06] <mup> Bug #1555355 opened: MachineSerializationSuite.TestAnnotations unit test failure (Go 1.6) <ci> <go1.6> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1555355>
[22:07] <natefinch> thumper: lol yep
[22:09] <alexisb> thumper, you sound like you are having a fun morning
[22:09] <thumper> yeah... *fun*
[22:10] <thumper> today is a crazy day just with home stuff
[22:10] <thumper> don't need crazy work stuff too
[22:10] <alexisb> is there work that exists without crazy?
[22:12] <thumper> heh, yeah
[22:15]  * thumper goes and pokes code with a stick while thinking about making a coffee
[22:38] <menn0> thumper: easy one: http://reviews.vapour.ws/r/4108/
[22:39] <thumper> shipit
[22:40] <menn0> thumper: cheers
[22:45] <thumper> I still struggle with simple go integer for loops
[22:45] <thumper> I always want to write:
[22:45] <thumper> for i := 0; i < n; ++i {
[23:01] <alexisb> thumper, those of us on the release call will be late to the leads call
[23:01] <thumper> alexisb: ok
[23:06] <mup> Bug #1555368 opened: Panic due to sending on closed channel <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555368>
[23:12] <mup> Bug #1555368 changed: Panic due to sending on closed channel <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555368>
[23:14] <thumper> alexisb: ETA?
[23:14] <perrito666> wallyworld: standup not happening?
[23:15] <wallyworld> perrito666: not on thursdays, stuck in meetings :-(
[23:15] <perrito666> wallyworld: I know, but since sometimes it happens I ask
[23:15] <wallyworld> perrito666: we can catch up a bit later maybe
[23:15] <perrito666> better safe
[23:15] <wallyworld> ty
[23:16] <perrito666> I ve been wanting to write a blog post for days, this is my chance
[23:18] <mup> Bug #1555368 opened: Panic due to sending on closed channel <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1555368>
[23:32] <katco> ericsnow: can you move the resources tech debt cards to the tech debt board?
[23:33] <ericsnow> katco: sure
[23:34] <katco> ericsnow: also, we have past 3/22 to fix bugs. ~4/12. so we should figure out what's most important to work on next
[23:34] <ericsnow> katco: k
[23:35] <katco> ericsnow: imo, it's definitely supporting revisions of resources in the resource flag. wallyworld ?
[23:35] <ericsnow> katco: fine with me
[23:35] <wallyworld> ericsnow: katco: yeah, i think we do the resource flag work
[23:35] <katco> wallyworld: k
[23:36] <katco> ericsnow: we should point this
[23:38] <katco> ericsnow: can you create a user story card with tasks defined so we can point first thing tomorrow?
[23:38] <katco> ericsnow: sorry otp
[23:38] <ericsnow> katco: sure
[23:38] <katco> ericsnow: ta
[23:41] <wallyworld> perrito666: wanna do standup now? too late?


[03:45] <lotuspsychje> good morning
[09:31] <myappie> hey
[09:32] <lotuspsychj3> welcome myappie
[09:32] <lotuspsychj3> here you can start any quality ubuntu discussion if you like
[09:32] <myappie> thanks :)
[10:13] <myappie> so
[10:18] <myappie> does ubuntu have a mailinglist where everything goes down?
[10:22] <myappie> say i were to improve https://packages.ubuntu.com/ -- where would i announce that? would i even be allowed to announce it?
[11:04] <tomreyn> myappie: there is https://lists.ubuntu.com
[11:04] <tomreyn> and packages.ubuntu.com is based on packages.debian.org, i think, and i also think the code is open source.
[11:05] <tomreyn> ...licensed
[11:05] <tomreyn> as in Free Software. but not 100% sure there


[00:56] <mate|93440> Greetings I am Russell trying this chat feature out
[13:30] <mate|555555> hi
[13:32] <mate|555555> need help     how  run    "traceroute     aaaa"  ,     "traceroute     bbb"   "traceroute     cccc " command in bash ,,,    like windows bat file
[13:38] <vlt> mate|555555: You can write a shell skript containing the command line by line. If you mark that file as "executable", for example by running `chmod +x your_file` you can run it afterwards: `./your_script`.
[13:39] <vlt> mate|555555: Not that in order to run it you need to specify either the absolute or relative path to the file. The file alone is not enough to execute it. That's a security measure.
[13:39] <vlt> s/Not/Note
[13:44] <mate|555555> this time saying    ' (argc 2) `-   ??
[13:44] <mate|555555> thank y answerd
[13:45] <vlt> mate|555555: What did you do before you got that message?
[13:46] <mate|555555> thank y answerd
[13:47] <mate|555555> ""    /bat.sh: line 1: $'\r':
[13:49] <kendell> I'm trying to fix a weird bug that seems to affect mate and most display managers. If you have a sound theme which has sounds for logging in, and when the system is ready for logging in, neither the display manager nor mate play them. Should thie be fixed in mate, or the display managers, or in the sound libraries used to play the sounds, called libcanbera? That would fix  it for al desktops and display managers, not j
[13:49] <kendell> lick greeter. Sorry if this is greek to everyone.
[13:49] <vlt> mate|555555: I don't understand anything of your last message.
[13:50] <mate|555555> "traceroute    google.com >    /root/Desktop/son1.txt   -n    "
[13:50] <mate|555555> "traceroute   facebook.com >    /root/Desktop/son2.txt   -n    "
[13:50] <mate|555555> "traceroute     youtube.com >    /root/Desktop/son3.txt  -n     "
[13:50] <mate|555555> and go onn    son4 5 6 7 ...  son 580 domain iptables auto generated
[13:51] <mate|555555> in windows line by line  bat file working
[13:51] <kendell> well, to try to simplify it, if you have sounds that are supposed to play when you log in, called desktop-login, your desktop, mate in this case, is supposed to play it when you log in. But it doesn't. There's also a sound that plays wht the login screen shows up, called system-ready. But it doesn't play either. Is this a mate bug, or a bug in the underlying sound library mate uses, called libcanbera?
[13:51] <mate|555555> in linux how do this
[13:51] <mate|555555> this is for iptables for ufw  but  i cant
[13:53] <mate|555555> in my plan   pc will connect  allow only top 500 sites  and its routes
[14:19] <mate|555555> ok thanks..  problem is  windows character encoder  // no showing but theris weird chars..
[14:20] <mate|555555> thats blocking bash things.. :D
[14:20] <mate|555555> good days all..
[16:53] <detherious> steam powered ist working. can i get help?
[16:54] <diogenes_> help with steam?
[16:55] <detherious> yes its a video game hub and installer
[16:55] <diogenes_> detherious, type in: /j #steam
[16:56] <detherious> in the terminal?
[16:56] <diogenes_> no
[16:56] <diogenes_> here in the chat
[16:57] <detherious> nothing
[16:57] <diogenes_> u using hexchat?
[16:58] <detherious> yes
[16:58] <diogenes_> did you type here in the chat: /j #steam
[16:58] <diogenes_> did you press enter?
[16:58] <detherious> yes
[16:59] <diogenes_> ok now you did
[16:59] <diogenes_> now ask your question in that channel
[18:27] <mate|31489> Hello :)
[18:27] <mate|31489> I hope this is the right place to ask...
[18:28] <mate|31489> Does someone know how to change the I2C baudrate in Ubuntu Mate, running on a Raspberry Pi (3)?
[20:27] <nekoseam_> Cupertino is a great layout
[20:43] <chrisis> Hallo
[20:45] <chrisis> try to start firefox, fresh install of ubuntu on raspy2 with update & upgrade - FF start with crash reporter, again and again
[20:48] <alkisg> chrisis: it's a known bug for firefox in rpi
[20:49] <alkisg> Use firefox esr, or the last version offered by xenial, not by xenial-updates
[20:49] <alkisg> I don't know why they're not fixing this after so many months
[20:50] <chrisis> thank you very much alkisg, i will try that
[20:50] <alkisg> np
[21:30] <chrisis> okay, i did it, i got firefox esr, firefox starts, i can use it. but to be honest, that was a way to complicate.
[21:31] <PenguinProblem10> Hi. Is anyone about that would be able to let me know if a fix for Wine has been made yet?


[01:04] <nerophibia> hey all
[01:04] <nerophibia> a question about FAI
[01:05] <nerophibia> Is there any plan to develop a kind of trusted master server for Ubuntu-Server version
[01:05] <nerophibia> that could be very interesting for people who have to deploy a huge range of server
[01:06] <maswan> trusted master server?
[01:06] <nerophibia> I also quite interested about that and very interested in participation
[01:06] <nerophibia> maswan: sorry for my english... want to say something like the lamp functionnality... that permit to deploy from scratch a master server
[01:07] <nerophibia> with trusted FAI template... or something like that
[01:07] <maswan> nerophibia: ah, ok. don't know about any such projects as such, but in general the fai package should be the place for such development
[01:08] <nerophibia> maswan: what do you mean by 'should be the place'
[01:10] <maswan> nerophibia: that installing the fai package should be enough to get a good master server etc
[01:13] <nerophibia> Yeah it should but from my personal use, the package comes with 'too much' generic template, only focused on bewolf deployement... without out-of-the-box functionnality for datacenter deployment (LAMP,etc)
[01:14] <nerophibia> maswan: another question if you permit, what are the current project of the server team (perhaps only a link :$)?
[01:17] <maswan> nerophibia: well, that's the tricky part, I'd expect pretty much all fai users to be different, that's why flexibility in class definitions are so important
[01:18] <maswan> and no clue, I'm not in it
[01:19] <nerophibia> maswan: maybe increase the number of default classes ;) thanks for all... gonna sleep now
[01:21] <maswan> nerophibia: I'm sure they'll be happy to get a patch for a lamp class or so


[02:36] <Nothing_Much> OMG Nvidia's gonna support Mir 100%!
[08:14] <lordievader> Good morning.
[08:19] <elfy> hey lordievader
[08:20] <lordievader> Morning elfy, how are you doing?
[08:20] <elfy> good thanks - watching the world go by today though - how are you?
[08:22] <lordievader> Having breakfast and coffee, can't complain.
[09:23] <vitimiti> Hi
[09:25] <lordievader> Good morning vitimiti, how are you doing?
[09:25] <vitimiti> Hi, lordievader, fine, thanks :)
[12:21] <BluesKaj> hi all
[16:49] <knittl> hi guys. anybody else using gnome 3.14 from gnome-staging ppa?
[16:50] <knittl> gnome-shell won't start since 3 days ago :(
[16:51] <knittl> but I'm not finding any evidence on the internet that this is happening to anybody else
[16:51] <knittl> how can I find out why gnome-shell fails to come up?
[17:23] <knittl> where is everyone?
[17:34] <dreamcat4> hi. any chance we can have a way to re-install grub / re-scan boot partitions from the .ISO ?
[17:35] <dreamcat4> the installer seems to do that. i mean for to repair a bad grub (so not to have to re-install the whole ubuntu OS again)
[17:35] <dreamcat4> many thanks for any consideration
[17:38] <lordievader> knittl: Is your ~/.xsession-errors filled with errors?
[17:38] <lordievader> dreamcat4: That is already possible, just invoke the installed manually.
[17:39] <dreamcat4> lordievader: sorry, can you please clarify? That would be very useful to me right now
[17:39] <knittl> lordievader: no, not really. although it has errors (not sure if related to this very problem)
[17:40] <knittl> openConnection: connect: No such file or directory and cannot connect to brltty at :0
[17:40] <lordievader> dreamcat4: Load a live-cd/usb, mount /boot run "sudo grub-install --boot-directory=<mount-point-of-/boot> /dev/<your-drive>
[17:41] <lordievader> knittl: It is able to start X (after login).
[17:41] <dreamcat4> thanks lordievader! but will that re-scan my HDD for the windows and linux boot partitions and create a new grub.cfg ?
[17:42] <lordievader> dreamcat4: Hmm, for that you can also use update-grub2, but yes.
[17:42] <knittl> lordievader: I guess … no mouse yesterday, but mouse today. I can start firefox from tty with DISPLAY=:0 firefox
[17:43] <knittl> but without window decorations
[17:43] <knittl> so it looks like that gnome-shell or gtk is not running properly
[17:43] <lordievader> knittl: Surely sounds like that.
[17:43] <lordievader> Unfortunately I don't have any experience with Gnome3.
[17:44] <knittl> alright. thanks anyway
[17:45] <dreamcat4> lordievader: will that install grub onto my existing MBR partition ? i don't want to muck windows up
[17:46] <knittl> dreamcat4: you said you wanted to re-install grub
[17:48] <lordievader> dreamcat4: Yes, well part will go the the MBR. How else do you want to do it?
[17:48] <lordievader> dreamcat4: Are you running Utopic?
[17:48] <dreamcat4> lordievader: no that's fine. i'm just being paranoid i guess
[17:49] <dreamcat4> recently upgraded from 14.04 -> 14.10. by usb key is still 14.04 though
[17:50] <lordievader> dreamcat4: Running a development release might not be the best option for you.
[17:51] <dreamcat4> hibernate mode is why. that didn't work properly for me on 14.04 LTS
[17:51] <lordievader> Not to be offensive, but installing/updating a bootmanager is, i.m.o., part of the basic skill set you need if you are going to run a development release.
[18:05] <dreamcat4> don't worry i'll be ok. to rephase my original suggestion - maybe provide a graphical way to run those 'grub-install' or 'update-grub2' commands
[18:05] <dreamcat4> you know, for noobs and people like me who aren't as knowledgable
[18:06] <dreamcat4> because when i go to this web page: https://help.ubuntu.com/community/Boot-Repair
[18:06] <dreamcat4> the recommended graphical boot-repair tool is A) 3rd party download B) didn't work anymore
[18:07] <lordievader> Pff, no idea. I trust CLI tools more anyways.
[18:14] <knittl> dreamcat4: gui tools are rarely available when it comes down to system and boot level stuff
[18:14] <knittl> using dev releases and "there should be a gui tool for noobs" doesn't go well together :)
[18:15] <lordievader> +1
[18:15] <dreamcat4> sorry - i'm not sure why my suggestion is a bad one. clearly i've had massive issues today
[18:16] <lordievader> dreamcat4: What issues?
[18:17] <dreamcat4> just getting grub re-installed / repaired. i'm not the only guy who has had these sorts of problems either
[18:18] <knittl> how did your grub get broken?
[18:18] <lordievader> dreamcat4: You are running a development release, breakage is to be expected. Besided when you aare running a development release repairing grub should be a piece of cake, else don't run a development release.
[18:19] <dreamcat4> i think next month it's going to be released, right ?
[18:19] <knittl> yes
[18:19] <knittl> but right now it's still in development
[18:20] <dreamcat4> so i downloaded the nightly ISO, will re-install from scratch. problem solved.
[18:20] <dreamcat4> then upgrade it next month to the proper release
[18:20] <knittl> I don't understand what you are trying to achieve
[18:20] <ObrienDave> neither does he
[18:21] <dreamcat4> well a re-install from scratch will find again my windows boot partition - so at least i will be able to boot back into windows again
[18:21] <lordievader> Nighlty still sounds like development.
[18:21] <lordievader> Nightly*
[18:21] <dreamcat4> b/c hibernation doesn't work on 14.04...
[18:22] <ObrienDave> dreamcat4, do you have a swap partition?
[18:22] <lordievader> dreamcat4: Did you investigate why it didn't work?
[18:22] <knittl> dreamcat4: but since you have already installed it, why don't you just re-install grub?
[18:24] <dreamcat4> i believe it's just a lot easier way since ubuntu doesn't have any official grub-repair tool
[18:24] <dreamcat4> i know that grub didn't work because my 'grub.cfg' file disappeared entirely
[18:25] <knittl> dreamcat4: I assume with "any official grub-repair tool", you mean a graphical one? because the official canonical way to repair grub is to simply reinstall it with "update-grub"
[18:26] <penguin42> dreamcat4: Is your /boot full?
[18:26] <dreamcat4> knittl: doesn't work from usb key. there's a web page about it. i got the same error message as other people on serverfault
[18:26] <dreamcat4> too much hassle
[18:26] <knittl> sure it works from usb key. I've done it multiple times in the past
[18:26] <dreamcat4> penguin42: no it's probably fine. but since i have to *move* my linux partition anyways i might aswell install fresh
[18:27] <penguin42> dreamcat4: OK, it's just not uncommon on Ubuntu to sometimes fill /boot if you have a separate one and that generally causes chaos
[18:28] <lordievader> dreamcat4: What was the exact command you used to try and repair your grub?
[18:29] <dreamcat4> lordievader: sorry i've since rebooted 14.04 usb key. so can't go back to check up on which cmds i used
[18:29] <knittl> let's see if ppa-purge fixes my gnome mess
[18:29] <knittl> dreamcat4: sure, you could mount your home partition and look at the contents of your .bash_history file
[18:30] <dreamcat4> well.. i'm also about to overwrite that usb key with a 14.10 desktop ISO img
[18:30] <dreamcat4> knittl: and not sure if i can mount ext /home on mac os x ?
[18:31] <dreamcat4> well - maybe with some 3rd party tool or something
[18:32] <lordievader> dreamcat4: Again I advice against installing Utopic at this time, wait a month for it to be released.
[18:32] <knittl> you are running a live system, right? so you can mount your partition. and before you said something about windows. I'm very confused about your system configuration
[18:32] <ObrienDave> in about 2.5 weeks
[18:32] <dreamcat4> anyway, lordievader this was the error i got: http://askubuntu.com/questions/254491/failed-to-get-canonical-path-of-cow
[18:33] <dreamcat4> it's a common enough issue from the usb stick
[18:33] <knittl> I don't have a graphical environment right now, I cannot click your link
[18:33] <lordievader> knittl: elinks!!!
[18:33] <dreamcat4> knittl: curl , wget :)
[18:33] <knittl> lordievader: yeah, I used elinks a lot to search for bugreports
[18:34] <knittl> but I don't have a screen instance running, so it's very annoying to get that link into my elinks
[18:35] <lordievader> Debootstrapping is made a whole lot harder if you cannot pull in that one meta package that pulls in all the necessary bits... :(
[18:35] <knittl> besides, I want to fix my own problems first :)
[19:08] <labsin> Does anyone know since when systemd was the default in Utopic?
[19:10] <labsin> or why it runs on the latest daily image
[19:12] <knittl> wooohooo, I think I fixed it
[19:12] <knittl> after purging all ppas
[19:12] <knittl> and rebooting several times :]
[19:12] <knittl> labsin: afaik utopic still runs on upstart
[19:13] <labsin> knittl, I just did a new install and when I do 'ps -aux | grep systemd' I get: /lib/systemd/systemd-udevd --daemon and /lib/systemd/systemd-udevd --daemon
[19:14] <knittl> labsin: what does ls -ld /sbin/init print?
[19:14] <labsin> upstart
[19:15] <knittl> so it still uses upstart as init system. no idea what systemd-udevd is for
[19:15] <labsin> nevermind then
[19:16] <labsin> My desktop stopped booting and I saw a bunch of systemd lines in syslog
[19:17] <knittl> labsin: ubuntu gnome?
[19:17] <labsin> knittl, No standard
[19:18] <knittl> hm. no idea then. my gnome started working two days back
[19:18] <labsin> I had to reïnstall. It was something with the graphics. On a fresh install, it still doesn't boot on the mesa drivers :S only on fglrx
[19:18] <knittl> nice touch on that reïnstall :]
[19:19] <labsin> knittl, Sorry, it's in my local language :)
[19:20] <knittl> I like it! (and it makes sense)
[19:20] <labsin> I now installed with btrfs and install apt-btrfs-snapshot to see if it could come handy sometime
[19:57] <labsin> Anyone know what package the aditional packages installantion in system settings is from?
[19:58] <labsin> Cause it doesn't remove fglrx-updates-core when switching to xorg drivers
[19:59] <genii> Not sure why but latest dist-upgrade wanted to install a crapload of libmir things even though I have only Kubuntu installed.
[21:12] <labsin> anyone else that can't login with radeon drivers (I think after the mesa update)


[13:36] <mrgoodcat> need to figure out auto identify
[13:36] <mrgoodcat> somehow dropped server connection and auto join failed because +r on channel
[13:39] <cmaloney> Good morning
[13:39] <cmaloney> mrgoodcat: Which client are you using?
[13:44] <mrgoodcat> weechat
[13:44] <mrgoodcat> i just haven't set up sasl yet
[13:45] <cmaloney> https://weechat.org/files/doc/stable/weechat_quickstart.en.html
[13:45] <mrgoodcat> seems to have worked
[13:46] <cmaloney> You'll also want to update your version of Weechat
[13:46] <mrgoodcat> wrong nick though
[13:46] <cmaloney> 1.9.1 is from 2017
[15:38] <Scary_Guy> I'm on 2.3 though some distros use an older version for whatever reason in their repos.
[15:58] <cmaloney> Yeah, I moved to the PPA for weechat
[15:58] <cmaloney> I'm on the 2.5 series
[16:46] <mrgoodcat> suppose i should same