[17:08] <daker> hey cjohnston , mhall119 sounds like the js is missing http://summit.ubuntu.com/ubuntu-website/media/js/twidenash/jquery-twidenash.js
[17:21] <cjohnston> I know.  I'm going to get rid of it anyway since it isn't working


[02:40] <blr> hey there, does anyone have any advice for debugging actions? When my action status is 'failed', I can see a line in my debug-log that reads "Traceback", however there's no traceback.
[08:53] <cnf> morning
[10:41] <Neepu> Hi @stokachu i had trouble with proxy and juju bootstrapper yesterday. I had trouble with even lauching test lxd containers with ubuntu, but resolved that today. Any chance you can help me today?
[10:41] <Neepu> Given that lxd now works, i assume juju is the remaining half.
[12:48] <ybaumy> haying a very strange problem
[12:49] <ybaumy> since the last update i loose connections in juju status from services and machines
[12:50] <ybaumy> status is either unknown or down
[12:50] <ybaumy> but when i log onto openstack
[12:50] <ybaumy> everything seems to be working
[12:50] <ybaumy> anyone had this too?
[12:50] <ybaumy> root@openstacksa2:~/kube# juju version
[12:50] <ybaumy> 2.2.1-xenial-amd64
[12:52] <ybaumy> agent status is lost
[12:55] <wpk> jam: ^^^
[12:55] <ybaumy> ah and when i restart the whole machines they reconnect agents and everything is green for a day or so
[12:56] <wpk> ybaumy: do you have controllers in HA setup?
[12:56] <ybaumy> wpk: yes
[12:57] <ybaumy> Machine  State    DNS            Inst id  Series  AZ       Message
[12:57] <ybaumy> 0        down     <IP_ADDRESS>   mt4cyg   xenial  default  Deployed
[12:57] <ybaumy> 1        down     <IP_ADDRESS>   g6kfkb   xenial  default  Deployed
[12:57] <ybaumy> 2        started  <IP_ADDRESS>  w4qxnp   xenial  default  Deployed
[12:58] <ybaumy> ic
[12:58] <ybaumy> ;)
[12:59] <ybaumy> somehow my controllers seem to be  dead
[12:59] <ybaumy> but machines are running
[12:59] <ybaumy> and strangely they seem to be on different subnets
[12:59] <ybaumy> hmm
[12:59] <ybaumy> they have the same vlan
[12:59] <ybaumy> i think at least
[12:59] <jam> ybaumy: bug 1703526 is tracking this issue
[12:59] <mup> Bug #1703526: agent lost, even though agents are still responding <juju:Triaged by jameinel> <juju 2.2:Triaged by jameinel> <https://launchpad.net/bugs/1703526>
[13:00] <jam> ybaumy: is it possible for you to add some debugging info to that bug?
[13:00] <ybaumy> jam: of course .. what kind of information should i provide
[13:01] <ybaumy> there also seems to be a problem with maas dhcp
[13:01] <ybaumy> because of the different subnets
[13:01] <jam> ybaumy: so doing: juju model-config -m controller logging-config="<root>=INFO;juju.state.presence=TRACE" and then saving a few minutes of "juju debug-log -m controller" output would probably be useful
[13:01] <ybaumy> but those vlans are interconnected
[13:01] <ybaumy> so connections are possible
[13:02] <ybaumy> jam: will do
[13:02] <jam> ybaumy: from what we can tell, all the agents are connected, its just that our 'Ping to keep alive' logic is wrong
[13:02] <jam> so we start reporting 'agent is lost' even though it is happily responding to requests
[13:03] <ybaumy> jam: but i will have to wait for now since i restarted all machines like 30 minutes ago. the error is not yet happening
[13:04] <ybaumy> jam: or doesnt it matter
[13:04] <jam> ybaumy: well, maybe data-from-now and then data-from-when-it-happens will be useful for us to track what's going on
[13:04] <jam> it can be useful to see the delta
[13:05] <ybaumy> jam: how much data is generated in a day when trace is on?
[13:05] <jam> ybaumy: well, every ping from every agent gets a line in the log file
[13:05] <jam> and we ping every 20s or so
[13:05] <jam> (and there are some other bits of info)
[13:06] <wpk> ybaumy: it was working on 2.2.0 without problems?
[13:06] <jam> and there is a line every second from PingBatcher about how much stuff it had to write out
[13:06] <ybaumy> wpk: yes
[13:06] <jam> so, its fairly noisy
[13:07] <ybaumy> jam: well then i will attach a volume from my nas in order to store the data
[13:07] <ybaumy> i dont have that much space on OS
[13:08] <jam> ybaumy: napkin math says about 500MB
[13:08] <jam> ybaumy: but I don't think we need the entire time
[13:08] <jam> ybaumy: if you could do say 30min now, and then 30min tomorrow might be sufficient
[13:08] <ybaumy> ok
[13:08] <jam> or even 10min or so now, and then 10min when you see the issue present itself
[13:09] <ybaumy> jam: last question how to turn loggin to default after trace was enabled
[13:10] <jam> ybaumy: default logging is logging-config="<root>=WARNING" I believe
[13:10] <jam> (though we'd *like* it to be INFO)
[13:10] <ybaumy> jam: ok
[13:15] <ybaumy> but that with the IP addresses is also very very strange
[13:15] <ybaumy> 10.14.151 vlan is 500 ... and 10.14.162 is vlan 503
[13:16] <ybaumy> normally there shouldnt be a conflict or addresses from on net in the other one
[13:17] <ybaumy> never seen this until now on the juju controllers
[13:18] <ybaumy> hmm where does it get the vlan 503 from
[13:18] <ybaumy> i dont get it
[13:20] <jam> ybaumy: generally we get the vlan ids from the MAAS config
[13:20] <ybaumy> hmm
[13:20] <ybaumy> jam: i know it must be maas who is responsible for this
[13:21] <ybaumy> jam: but i dont see the error. its just the first 2 controller nodes who are in the wrong subnet
[14:22] <ak_dev> hello, seems that the charm store is down, says service unavailable
[14:22] <ak_dev> while deploying
[14:22] <ak_dev> same while searching for a charm on web
[14:23] <ak_dev> ERROR cannot deploy bundle: cannot resolve URL "cs:~containers/easyrsa-12": cannot resolve charm URL "cs:~containers/xenial/easyrsa-12": cannot get "/~containers/xenial/easyrsa-12/meta/any?include=id&include=supported-series&include=published": cannot unmarshal error response "
503 Service Unavailable
\nNo server is available to handle this request.\n\n": invalid character '<' looking for
[14:23] <ak_dev> beginning of value
[14:23] <ak_dev> ^^ error
[14:23] <rick_h> ak_dev: there's a current outage the team is chasing.
[14:24] <ak_dev> oh okay cool :-)
[14:24] <rick_h> ak_dev: will keep the topic up to date and update on twitter as we get things back and going. https://twitter.com/jujuui
[14:24] <ak_dev> Okay! looking out for it, thanks
[14:25] <rick_h> np, apologies for the unexpected issue
[15:07] <rick_h> ak_dev: should be back now
[15:11] <ak_dev> Hey thanks, will check soon :-)
[15:24] <cnf> hmz
[15:24] <cnf> openstack with juju is torture
[15:25] <ybaumy> cnf: i feel you
[15:26] <cnf> what a load of bs
[15:26] <ybaumy> im already using for production redhat
[15:26] <ybaumy> im testing suse currently
[15:26] <cnf> we are in RFI rounds
[15:27] <cnf> but canonical is looking unlikeley atm
[15:27] <ybaumy> whats RFI if i may ask?
[15:28] <cnf> Request For Information
[15:28] <ybaumy> ah ok i thought so.
[15:29] <ybaumy> cnf: i only had problems with juju with scale out
[15:29] <ybaumy> cnf: and other stuff
[15:29] <cnf> redhat and mirantis had a strong story, canonical next week will really have to step up.
[15:30] <ybaumy> cnf: maybe im too stupid but os-charmers should put out a documentation out IMO
[15:30] <cnf> i have had nothing but trouble with juju / charms myself :(
[15:30] <ybaumy> cnf: im a ubuntu guy normally but this just didnt work out
[15:30] <cnf> "Placement API service is not responding" is what i'm stuck at, atm
[15:31] <cnf> ybaumy: yeah, i'm thinking the same atm
[15:32] <ybaumy> cnf: im using juju and openstack at home for personal training but thats all.
[15:35] <cnf> uhu
[15:36] <ybaumy> at work i also moved from maas to https://theforeman.org
[15:37] <cnf> maas i do rather like
[15:39] <ybaumy> well do many bugs that came up and was tired getting them fixed. currently i have a bug open in relation to juju and im waiting now over a week for response. i  mean how can i work with something like that
[15:40] <cnf> oh yeah, juju is just tiresome
[15:40] <kwmonroe> hey tvansteenburgh, any objection to a PR that turns down the noise on nvidia-cuda?  the -x is making a big haystack in my logs:  https://github.com/juju-solutions/layer-nvidia-cuda/blob/master/reactive/cuda.sh#L2
[15:40] <ybaumy> i like it
[15:40] <cnf> maas is much quicker in reacting and fixing
[15:40] <ybaumy> but ...
[15:40] <tvansteenburgh> kwmonroe: no objection
[15:42] <ybaumy> i found the integration of chef and puppet with foreman very useful
[15:42] <cnf> hmz, what the hell is the problem with this BS >,<
[15:42] <beisner_> hi cnf ybaumy - are there specific issues that you're running into with openstack charms?
[15:43] <cnf> tons, atm my compute nodes apparently can't talk to the placement API
[15:45] <ybaumy> beisner_: the reason i switched from juju os-charms to redhat cloud was scale out/down and HA. i had problems adding nodes, removing nodes from the config. then HA setup from the charms should be default. i had problems with mysql HA and much more other stuff.
[15:46] <ybaumy> ybaumy: i must say i put in a lot of work to get it to run. but then there is no piece of good documentation .. here a piece in the net then go there to find something out...
[15:46] <ybaumy> beisner_: and so on. i would really like to give it another chance but in the end its management who says ok this is useful or not
[15:46] <cnf> all i get atm is "Placement API service is not responding", and I can't figure out why
[15:47] <cnf> ybaumy: it's a mess
[15:47] <beisner_> interesting.  appreciate the input.  these things are in circulation in production in lots of places, perhaps there are configuration issues which might be more clear with more docs.
[15:47] <ybaumy> beisner_: and in my presentation i had problem with scale out and they said ok how should this work in production if not in the a presenation
[15:47] <beisner_> LP bug pointers with logs are most helpful in these scenarios
[15:47] <cnf> in my experience, when something goes wrong with a juju deploy, you are on your own figureing out what went wrong
[15:48] <ybaumy> beisner_: and that was it. management said the project is dead and i had to switch to redhat and im happy with it
[15:48] <cnf> well, canonical RFI presentation next week, we'll see what they say
[15:48] <beisner_> sorry to hear that didn't work out for you.  if there are specific technical issues that need attention, please do raise a bug and ping here or on #openstack-charms
[15:49] <ybaumy> beisner_: i will. im still using it at home only though but at least i having giving up on it
[15:49] <cnf> it's not the most active channel during european time
[15:50] <ybaumy> cnf: true CEST its like dead
[15:50] <beisner_> if there is already a canonical person working with you, i'd be happy to help connect people.  lmk in a priv msg if so.
[15:50] <beisner_> but also, LP bugs are how issues are raised/tracked/prioritized with the charms.
[15:51] <cnf> beisner_: i find my issues take weeks if not longer to even get looked at
[15:51] <cnf> i don't bother anymore
[15:51] <ybaumy> the thing is .. if only one person has a bug or problem attention is not good ..
[15:51]  * D4RKS1D3 hi!
[15:52] <beisner_> if there is a specific bug or issue, please holler here with a link.  thank you.
[15:53] <cnf> right now, i just want a working openstack
[15:53] <cnf> never gotten to a functional openstack with juju
[15:55] <cnf> right, i'm done
[15:55] <cnf> i'll look at it more tomorrow
[15:56] <ybaumy> https://bugs.launchpad.net/maas/+bug/1666521 this is my maas bug .. but related to juju ... no response since 4th of july
[15:56] <mup> Bug #1666521: MAAS does not detect RAM in newly commissioned VMWARE VM's <MAAS:Incomplete> <https://launchpad.net/bugs/1666521>
[15:57] <ybaumy> there is a workaround but its just plain annoying
[15:57] <cnf> you are using MaaS to manage vmware vm's? o,O
[15:58] <ybaumy> then  bug 1703526
[15:58] <mup> Bug #1703526: agent lost, even though agents are still responding <juju:Triaged by jameinel> <juju 2.2:Triaged by jameinel> <https://launchpad.net/bugs/1703526>
[15:58] <ybaumy> im still collecting logs here
[15:58] <cnf> anyway, i'm going home
[15:58] <cnf> enough frustration for one day
[15:58] <ybaumy> cnf: bye good luck with your  setu
[15:58] <ybaumy> p
[15:59] <ybaumy> beisner_: i will submit my openstack issues this week. i will collect my problems im haying with the charm setup
[16:00] <ybaumy> to be honest without jamespage's help i would have gotten nowhere
[16:27] <julen> Hi there!
[16:28] <julen> I got stuck trying to bootstrap juju with MaaS
[16:28] <julen> from the juju command line I get the error:
[16:29] <julen> ERROR unable to contact api server after 1 attempts: unable to connect to API: Forbidden
[16:29] <ybaumy> did you juju add-cloud .. and add credentials correctly?
[16:30] <ybaumy> julen: you have to add the api key
[16:31] <julen> ybaumy, I think I did that already...
[16:31] <ybaumy> julen: the error message points that you didnt but im not the expert here
[16:31] <julen> while doing "juju add-cloud"
[16:33] <ybaumy> julen: you need to provide username and api key
[16:33] <ybaumy> root@maas:~# cat .local/share/juju/credentials.yaml
[16:33] <ybaumy> credentials:
[16:33] <ybaumy>   homemaas:
[16:33] <ybaumy>     baum:
[16:33] <ybaumy>       auth-type: oauth1
[16:33] <ybaumy>       maas-oauth:
[16:33] <ybaumy> this is a example of the credentials file
[16:34] <ybaumy> maas-oauth: <apikey>
[16:34] <ybaumy> i didnt paste that
[16:34] <julen> hmm... so I have to create the credentials.yaml file manually?
[16:34] <ybaumy> julen: no normally not but you can check the file if its correct
[16:35] <julen> and, it should be generated during bootstrap, right?
[16:35] <ybaumy> no during add-cloud
[16:36] <julen> oh! .. true.. yes
[16:36] <ybaumy> you can always make juju add-credential
[16:37] <julen> well... I got a little confused. Sure, I have the credentials file, what I was missing is the old "environment.yaml" file, but I think that it should not be there in the newer versions
[16:37] <julen> and the credentials file does look like your example
[16:37] <ybaumy> julen: ok
[16:37] <ybaumy> hmm
[16:38] <ybaumy> did you enter the enpoint correctly
[16:38] <ybaumy> endpoint: http://<IP_ADDRESS>/MAAS in ~/.local/share/juju# cat clouds.yaml
[16:39] <julen> and the key string on the credentials file does match the one on the "admin"  site or the "maas apikey --username admin"
[16:40] <julen> ybaumy: I think so... http://<IP_ADDRESS>:5240/MAAS
[16:40] <julen> I also tried without the port, with the same result
[16:40] <ybaumy> well that looks good
[16:41] <julen> the only clue I get from the juju instance is, on the /var/log/juju/logsink.log
[16:41] <julen> machine-0 2017-07-11 16:09:56 DEBUG juju.apiserver.logsink logsink.go:205 logsink receive error: websocket: close 1006 (abnormal closure): unexpected EOF
[16:42] <ybaumy> well here you have to ask the developers  then
[16:42] <ybaumy> if nobody answers here open up a bug report
[16:42] <ybaumy> sorry
[16:44] <julen> I'll try... but the problem is, that I don't even know if it is a bug. Probably I'm doing something wrong, but it's been already a few days, and I can't manage to work around it
[16:45] <ybaumy> julen: you can also write to the mailing list
[16:46] <julen> uff... too many mailing lists already... I'll try here first
[16:46] <ybaumy> good luck
[16:47] <julen> beisner, beisner_, jamespage? any idea about where would I look?
[16:47] <julen> ybaumy: thanks :)
[17:17] <cnf> aaand home
[17:53] <Budgie^Smore> o/ juju world
[18:21] <julen> The juju-gui seems to get stuck while trying to "Deploy changes". The "Choose a cloud to deploy to" dialog has the circle spinning.
[18:22] <julen> I probably has something to do with the http-proxy. Isn't there a way to configure the juju-gui to work properly behind a proxy?
[18:23] <julen> I didn't find anything on the config section, and the server does have already the http/s/no_proxy variables set on /etc/environment
[18:24] <tvansteenburgh> hatch ^
[18:24] <julen> (I mean the server/instance running the juju-gui)
[18:24] <hatch> julen what version of Juju are you using?
[18:24] <hatch> thanks for the ping tvansteenburgh
[18:25]  * tvansteenburgh waves
[18:25] <julen> hatch: juju  2.2.1
[18:26] <hatch> julen ok and are you using the GUI charm, or the one that ships with Juju?
[18:26] <hatch> ala `juju gui`
[18:26] <julen> the juju-gui on a MaaS instance
[18:28] <hatch> julen in the top right of the GUI there should be a circle with a question mark in it, can you click there and then click "Keyboard Shortcuts" it'll tell you the version of the GUI
[18:29] <julen> on the top right of my juju-gui there is only "search store" and "Logout"
[18:30] <hatch> ok then the version of the GUI you're using is very old
[18:30] <hatch> you'll want to run the one that ships with Juju and not a charm
[18:30] <hatch> you can get the path to that by running `juju gui` in the cli
[18:31] <julen> GUI 2.7.4
[18:32] <hatch> and does that version work? It will have displayed a URL and a u/p
[18:32] <julen> yes, that's the one I am logged into
[18:33] <hatch> hmm
[18:33] <julen> but the version 2.7.4 is at least relatively recent.. isn't it?
[18:33] <hatch> it's the current release yes
[18:34] <hatch> which does not have Logout in the top right :)
[18:34] <rick_h> hatch: julen if the GUI is on a MAAS and the controller needs a proxy to get out it might not be configured in Juju yet causing thigns like add-charm to fail to get the charms from the store?
[18:34] <julen> I belive it has something to do with the proxy again... It has been making me crazy
[18:34] <rick_h> julen: have you tried to see if you can juju deploy from the CLI?
[18:35] <rick_h> julen: and what are you looking to deploy?
[18:35] <hatch> rick_h that may very well be - but the GUI that julen is using is quite old - so trying to figure out why it's not running 2.7.4 as the CLI states
[18:35] <julen> juju deploy did work for the juju-gui
[18:35] <hatch> oh
[18:35] <rick_h> hatch: :)
[18:35] <hatch> so then you're not connected to the one from the CLI
[18:35] <julen> I just wanted to test the openstack charm
[18:36] <hatch> julen from the CLI when you type `juju gui` it'll print a URL and a username/password - visit the url listed there and log in using the credentials provided
[18:37] <julen> but the instance running the juju-gui does have the http/s/no-proxy variables properly set in /etc/environment...
[18:37] <hatch> you can also run `juju remove-application juju-gui` since that version is not supported on the Juju 2   you have
[18:38] <julen> hatch: Allright! this looks better! :D
[18:38] <julen> now I seem to have the GUI you mentioned
[18:38] <hatch> haha there we go!
[18:38] <hatch> now can you please re-try what you were doing before to see if it's still not working
[18:38] <julen> for some reason, I just went to the plain IP, without the port and the rest
[18:39] <hatch> no problem at all
[18:40] <julen> hatch: Aha!! not it totally works! :D
[18:40] <hatch> assuming s/not/now
[18:40] <hatch> \o/
[18:41] <julen> it's funny that the URL without the port also gives you a web interface, almost like the good one
[18:41] <julen> thank you very much hatch !!
[18:41] <hatch> no problem at all, sorry about that - we'll update the charm to fail obviously in unsupported versions of Juju to avoid this problem for others :)
[18:42] <hatch> julen also, when new GUI versions are released you can simply run `juju upgrade-gui` and it'll upgrade for you :)
[18:42] <julen> that's useful, thanks!
[18:43] <hatch> glad it all worked out for you
[18:44] <hatch> issues and feature requests can be filed here if you run into any more things - https://github.com/juju/juju-gui/issues
[18:45] <julen> sure, I was just a little bit unsure, because I kind of knew that I was doing something (relatively trivial) wrong
[18:47] <hatch> :) no problem
[19:35] <jam> ybaumy: I have a potential patch https://github.com/juju/juju/pull/7626 assuming the way I triggered the bug is representative of what is going on for you
[19:36] <jam> namely, if the worker that writes pings to the database gets restarted, it looses sync with the Pingers that were feeding it data
[19:36] <jam> I caused it by manually injecting bad data, so I can't guarantee that it is the same root cause that you are seeing
[19:36] <jam> but it might be a fix
[20:32] <ybaumy> jam: will look into it tomorow and will give you feedback
[20:35] <jam> ybaumy: so 'juju debug-log -m controller --level ERROR' might show something about pingbatcher worker dying
[20:36] <jam> if it does, then it fits the symptoms really well
[20:40] <tvansteenburgh> rick_h: you still around?
[20:43] <rick_h> tvansteenburgh: out and about. What's up?
[20:44] <tvansteenburgh> rick_h: wanted to ask some questions about `charm set extra-info`, but if it's a bad time i can wait :)
[20:53] <rick_h> tvansteenburgh: getting the boy from summer camp. Can you email questions and I can poke at it when I get back?
[20:53] <tvansteenburgh> rick_h: yeah np
[20:54] <tvansteenburgh> rick_h: if you don't here from me it means i poked until i figured it out myself :D


[02:59] <hyperair> hmm this is weird. i can't seem to upgrade from precise to quantal due to unmet dependencies
[03:00] <hyperair> oh crap, i forgot i pinned quantal to prio 1
[07:47] <apw> ;b 9
[08:33] <tkamppeter> OdyX, Debian bug 690982 is easy to fix, you only nedd to upload the current GIT og the CUPS package to Debian, the fix is already contained there and tested under Ubuntu.
[08:39] <OdyX> tkamppeter: aww well. I can't upload 1.6 to Wheezy. You mean the patched backend/usb-libusb.c ?
[11:10] <geser> is there something wrong with publishing currently? the latest python3-defaults from raring is missing on archive.u.c but LP says it's published
[11:15] <mitya57> geser: http://archive.ubuntu.com/ubuntu/pool/main/p/python3-defaults/python3-defaults_3.2.3-5ubuntu2.dsc
[11:15] <mitya57> it's not missing
[11:19] <geser> hmm, apt-get complained about a 404 for fetch http://archive.ubuntu.com/ubuntu/pool/main/p/python3-defaults/python3_3.2.3-5ubuntu2_all.deb
[11:19] <geser> but I checked it a couple minutes ago and didn't see it (now it's there)
[11:19] <geser> I wonder what happened in the last 5 minutes
[11:22] <geser> looks like one of the archive.u.c mirrors isn't up-to-date
[11:22] <geser> because I forced reload that listing in FF again, but this time I don't see -5ubuntu2 anymore
[11:24] <geser> http://archive.ubuntu.com/ubuntu/dists/ doesn't list raring for me either
[11:27] <geser> looks like only <IP_ADDRESS> it affected (out of sync)
[11:59] <xnox> geser: aren't we meant to be "pre-release frozen" and publisher not pushing stuff out for raring yet? /me is not sure at all.
[12:02] <geser> xnox: in that case the published Packages files shouldn't mention it either, but it looks like 1 of 6 archive.u.c mirrors was out of sync (didn't have raring at all)
[12:02] <xnox> sigh
[12:03] <geser> at it probably also affect quantal-updates if you got the package list from a different mirror than it tries to fetch the debs later
[12:04] <geser> (3 days out of sync)
[14:54] <psusi> what is up with the livecd no longer fitting on a cd?  I thought the plan was to turn the dvd image into a ~1 gb image meant for usb sticks, not enlarge the desktop image?
[15:40] <infinity> psusi: We decided to give up on shiny spinning things at the last UDS.
[15:41] <infinity> psusi: At least, for Ubuntu images.  Many flavours have tried to stay CD-sized.
[15:43] <infinity> psusi: For serial installers (ie: people who seem to install more often than they actually use their computer), writing images to USB sticks is way more convenient anyway, and for one-off folks who need shiny spinning things, if you have a newish computer with a CD burner, it's probably also a DVD burner, so that works out.
[15:43] <infinity> psusi: (And for people doing bulk installs and other such things, it shouldn't affect them at all, cause they probably all use netboot, or should do)
[18:51] <cjwatson> xnox: in general, if the publisher weren't running for a given series, it would be impossible to prepare it for general opening in any meaningful way ...
[22:59] <xnox> cjwatson: ack. Maybe I should read up about https://dev.launchpad.net/Soyuz


[00:05] <Daganoweda> Hello
[00:12] <holstein> Daganoweda: hey
[00:12] <holstein> welcome!
[00:15] <Daganoweda> Check this out
[00:15] <Daganoweda> http://i.imgur.com/5WcUO.jpg
[00:15] <Daganoweda> Its a $5 gold coin
[00:15] <Daganoweda> Issued by Bechtler family in North Carolina
[00:15] <Daganoweda> 1834
[00:16] <Daganoweda> http://i.imgur.com/tO77h.jpg
[00:16] <Daganoweda> They did it before the US government minted gold!
[00:17] <holstein> cool
[00:30] <Daganoweda> They didnt really make a lot of them and and most of them actually were worth a bit more than the face value so what ended up happening to them was that most of them have from their way to be melted and then reused by the mint for othe governmental and other gold coins
[00:30] <Daganoweda>  So theres not a lot of them left, only 15 such examples have survived and that makes them extremely desirable by collectors


[01:14] <davecheney> how are we doing on those blockers ?
[01:15] <davecheney> mwhudson: did you fix http://pad.lv/1494441
[01:15] <davecheney> >
[01:15] <axw> thumper: re #1495320, why should we have any of those things? IMO we should have per-facade mock states, which is what some of the newer facades have been doing already
[01:15] <mup> Bug #1495320: New base test suite for apiserver <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1495320>
[01:17] <thumper> axw: fair point...
[01:35] <axw> wallyworld: FYI, https://bugs.launchpad.net/juju-core/+bug/1495338
[01:35] <mup> Bug #1495338: cmd/juju/storage: "volume list" YAML/JSON format is non-obvious <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1495338>
[01:35] <wallyworld> np, ty
[01:37] <anastasiamac> axw: this is a nice bug :D i wish they were all like that!
[01:59] <mup> Bug #1495338 opened: cmd/juju/storage: "volume list" YAML/JSON format is non-obvious <juju-core:Triaged by axwalk> <juju-core 1.25:In Progress by axwalk> <https://launchpad.net/bugs/1495338>
[02:10] <wallyworld> thumper: waigani: please don't use JujuConnSuite for testing new apiserver facades
[02:11] <wallyworld> there's plenty of existing apiserver facades that have been written with better tests you can copy fro
[02:11] <waigani> wallyworld: okay, sorry
[02:12] <wallyworld> waigani: best not to perpetuate our misery :-)
[02:12] <wallyworld> especially for new work
[02:12] <wallyworld> adding a new test i could live with
[02:12] <wallyworld> but a whole new facade package, not really
[02:13] <waigani> wallyworld: yep, understood - fixing it now
[02:14] <wallyworld> waigani: there should be a happy path feature test though that (for now) does use jujuconnsuite to ensure it is glued together end-end
[02:15] <wallyworld> in the featuretests package
[02:17] <waigani> wallyworld: I was going to add a feature test once the api and worker have landed, to make sure they all work as intended.
[02:27] <axw> wallyworld anastasiamac: how's this look as an alternative "volume list" YAML format? http://paste.ubuntu.com/12405626/
[02:28] <anastasiamac> axw: "machines" as a collection? :D
[02:28] <anastasiamac> looks nice :))
[02:28] <axw> wallyworld anastasiamac: there will be a "units" field below "machines" when the data is available in the API
[02:28] <anastasiamac> \o/
[02:28] <anastasiamac> personally, i like :)
[02:28] <wallyworld> axw: "provider-id" - could that be just "id", or "volume-id"
[02:29] <axw> wallyworld: hum, I'm trying to distinguish between the internal and provider-supplied one. it's kinda ambiguous
[02:29] <wallyworld> yeah
[02:29] <anastasiamac> axw: is status per volume or machine/unit? coz what does "attached" mean when there r 1+ machines/units?
[02:30] <axw> anastasiamac: currently only per volume, but later we'd have per-machine and per-unit also (and they'll go in the "machines" struct, along with "device" and "read-only"
[02:30] <axw> anastasiamac: atm, "attached" means all attachments are created
[02:31] <axw> otherwise it's "attaching"
[02:32] <anastasiamac> axw: sounds great! let's remember to deal with/display multiple status when we have per-machine and per-unit specific ones :D
[02:32] <axw> anastasiamac: I'll adda  TODO in the relevant structs
[02:32] <anastasiamac> axw: tyvm for making output user-helpful \o/
[02:33] <axw> anastasiamac: np
[02:33] <wallyworld> axw: the id i think should be whatever we expect the user to use when we add CLI that requires it to identify a volume
[02:33] <axw> wallyworld: yeah, that's the top-level string "1/0"
[02:33] <axw> wallyworld: same sort of format for machine IDs as in "juju status"
[02:34] <wallyworld> ok, yeah, that makes sense
[02:38] <axw> wallyworld: so, yea or nay?
[02:38] <wallyworld> axw: oh sorry, +1 i think
[02:39] <wallyworld> is the user generally inetrested in provider id?
[02:39] <wallyworld> could it be left off?
[02:39] <axw> wallyworld: same level of interest as people have in instance IDs
[02:39] <axw> wallyworld: useful for matching up juju resources with things in your cloud provider
[02:40] <wallyworld> so it adds value in showing it
[02:40] <axw> wallyworld: I think so
[02:40] <wallyworld> sgtm
[02:47] <thumper> wallyworld: got 10 minutes for a quick chat about a critical bug?
[02:47] <thumper> wallyworld: it has to do with the new uniter code
[02:47] <wallyworld> sure
[02:47] <thumper> https://bugs.launchpad.net/juju-core/+bug/1494356
[02:47] <mup> Bug #1494356: OS-deployer job fails to complete <blocker> <ci> <regression> <juju-core:In Progress by thumper> <https://launchpad.net/bugs/1494356>
[02:47] <thumper> 1:1 hangout
[03:14] <mup> Bug #1495320 changed: New base test suite for apiserver <tech-debt> <juju-core:Invalid> <https://launchpad.net/bugs/1495320>
[03:17] <mup> Bug #1495320 opened: New base test suite for apiserver <tech-debt> <juju-core:Invalid> <https://launchpad.net/bugs/1495320>
[03:23] <mup> Bug #1495320 changed: New base test suite for apiserver <tech-debt> <juju-core:Invalid> <https://launchpad.net/bugs/1495320>
[03:29] <mup> Bug #1495320 opened: New base test suite for apiserver <tech-debt> <juju-core:Invalid> <https://launchpad.net/bugs/1495320>
[03:32] <mup> Bug #1495320 changed: New base test suite for apiserver <tech-debt> <juju-core:Invalid> <https://launchpad.net/bugs/1495320>
[03:40] <thumper> ah fuck
[03:40] <thumper> my passport hits the <6 months until expiry mid-sprint
[03:41] <davecheney> you shall receive an imigration fail
[03:42] <davecheney> 3 weeks, you should be able to get an expidited one by then
[03:44] <thumper> 10 working days for NZ is normal
[03:44] <thumper> File type: Jpg or Jpeg
[03:44] <thumper> heh
[03:44] <thumper> for photo
[03:47] <davecheney> will they accept JPEG ?
[03:47] <thumper> hmm... deems dubious
[03:48] <thumper> seems
[03:50] <wallyworld> thumper: i got my passport in 2 days after paying an exhorbitant fee after i put it through the wash 10 days before the malta sprint
[03:51] <thumper> heh
[03:51] <thumper> I don't want to pay the 2x amount for 3 day shipping
[03:51] <thumper> 10 should be fine
[04:03] <mwhudson> davecheney: yes, but the fix will take a loong time to get anywhere i suspect
[04:11] <davecheney> mwhudson: that's what I figured
[04:11] <davecheney> it looks like the commit that used the encoding package got rolled back for unrelated reasons
[04:11] <davecheney> can we mark that issue as not a blocker for now ?
[04:12] <mwhudson> i don't actually understand all steps of the process by which the fix will get into trusty-updates, i guess it would be good to learn that
[04:12] <mwhudson> but oops, i'm supposed to be on leave today :-)
[04:18] <thumper> wallyworld: http://reviews.vapour.ws/r/2650/
[04:18] <wallyworld> looking
[04:19] <wallyworld> thumper: +1
[04:19] <thumper> wallyworld: pretty dull fix I admit
[04:21] <davecheney> ship it
[04:29] <thumper> oh fuck
[04:29]  * thumper found a bad bug
[04:29] <thumper> testing bug only
[04:29] <thumper> windows only
[04:29] <thumper> but bad none the less
[04:30]  * thumper things
[04:30] <thumper> and thnks
[04:30]  * thumper gives up
[04:33]  * thumper head-desks
[04:37] <thumper> MEH
[04:38] <thumper> anyone got a windows 2012 image running?
[04:38] <thumper> wallyworld: another quick sanity check chat?
[04:38] <wallyworld> sure
[05:02] <thumper> wallyworld: http://reviews.vapour.ws/r/2651/diff/#
[05:02] <wallyworld> looking
[05:04] <wallyworld> thumper: thanks for fixing that
[05:04] <thumper> wallyworld: np
[05:16] <thumper> davecheney: that last one was just a windows time bomb
[05:16] <thumper> davecheney: it was bound to fail eventually
[05:16] <thumper> :)
[05:31] <waigani> thumper: http://pastebin.ubuntu.com/12406461/
[05:32] <waigani> thumper: first three is using jujuconnsuite
[05:32] <waigani> thumper: second three, after pop, are using a mock state
[05:39] <waigani> wallyworld, thumper: updated PR: http://reviews.vapour.ws/r/2649/
[05:39] <wallyworld> looking
[05:51] <wallyworld> waigani: i don't like how getEnvironment is patched. hopefully my comments make sense
[05:51] <wallyworld> it's unnecessary
[05:51] <waigani> wallyworld: okay, thanks for the review
[05:54] <waigani> wallyworld: btw rewriting from jujuconnsuite to mock state afforded me the opportunity to benchmark the two: http://pastebin.ubuntu.com/12406461/
[05:54] <waigani> wallyworld: after the pop is with the mock
[05:55] <wallyworld> waigani: yeah. although even with the mock the numbers look too high
[05:55] <wallyworld> i would expect say 5 or 10ms
[05:55] <wallyworld> but still a good reduction
[05:55] <waigani> hmm, that could be my laptop..
[05:55] <wallyworld> maybe there's something else there that needs fixing also
[05:56] <wallyworld> waigani: did you remember to remove the ngotestsuite
[05:56] <waigani> wallyworld: I think so... I'll check
[05:57] <waigani> wallyworld: good catch, that was it.
[05:58] <wallyworld> thought so :-)
[05:58] <wallyworld> i didn't believe you when you said you'd removed it :-)
[05:59] <wallyworld> axw: this fixes a ci blocker, removes a crappy initial port of the update status stuff that i did http://reviews.vapour.ws/r/2652/
[05:59] <axw> wallyworld: okey dokey, looking
[06:03] <axw> wallyworld: is operation.State.UpdateStatusTime used at all after these changes?
[06:04] <wallyworld> axw: no, not supposed to be, did i forget to remove it
[06:04] <axw> wallyworld: I think so
[06:04] <wallyworld> ffs, so i did
[06:05] <axw> wallyworld: can you please explain how it was spinning before?
[06:06] <wallyworld> tl;dr; the decoupling of remote state from the update status hook action meant that the previous helper to find the duration to wait based on now and last fire time would always trigger a very short wait
[06:06] <wallyworld> and that would caue the timer to fire again
[06:06] <wallyworld> and again
[06:06] <wallyworld> and again
[06:06] <axw> wallyworld: ah, I see
[06:07] <wallyworld> the old world and new didn't match
[06:07] <axw> wallyworld: so now we always just wait for the full period, right?
[06:07] <axw> wallyworld: and if somethign else happens within that period, we'll wait again for another full period
[06:07] <wallyworld> yeah, but all we do is update the counter
[06:07] <axw> yep
[06:08] <wallyworld> each time the update status hook runs, it sets current value to current counter
[06:08] <wallyworld> counter could be +10 or +20 over last local recorded value, we dont care
[06:08] <wallyworld> we just wait till idle and see if counters are different
[06:09] <axw> wallyworld: yeah I was just thinking about the difference in when the remote state watcher is triggered. I think with this change we'll never set status until the unit has quiesced, and *then* the update-status idle period has elapsed
[06:09] <axw> as opposed to period since the last update
[06:09] <axw> wallyworld: (which seems fine to me)
[06:09] <wallyworld> me too
[06:09] <wallyworld> because when hooks are run, unit can set status
[06:10] <wallyworld> so it could have done it during config changed or something
[06:11] <axw> wallyworld: thanks. reviewed
[06:11] <wallyworld> tyvm
[06:11] <wallyworld> axw: i had a small unit test that showed the spinning, but it used wall clock so i removed it
[06:12] <wallyworld> i'll test live also after school pickup
[08:10] <axw> wallyworld: don't suppose you're still working are you?
[08:13] <wallyworld> axw: hey
[09:58] <voidspace> frobware: dimitern: TheMue: dooferlad: morning, I'm back in the UK
[09:58] <dimitern> voidspace, morning :)
[09:59] <frobware> voidspace, hiya
[09:59] <dooferlad> voidspace: welcome back. Enjoy the rain!
[10:00] <voidspace> o/
[10:01] <voidspace> dooferlad: hehe, we had quite a lot of rain (warm rain though) in North Carolina. A couple of impressive thunderstorms.
[10:01] <voidspace> dooferlad: a few days of good sun too though.
[10:02] <voidspace> dimitern: frobware: so fwreade gave me a comprehensive review on my "unit public address branch"
[10:02] <voidspace> dimitern: frobware: I've already started work on it - the biggest change is to set the "preferred addresses" (he doesn't like the Default name) when the addresses are set rather than when they're fetched
[10:03] <voidspace> dimitern: frobware: plus a bunch of issues he identified in existing code that the PR touches
[10:03] <voidspace> dimitern: frobware: so that's what I'm up to...
[10:03] <voidspace> frobware: when is good for you to chat?
[10:03] <frobware> voidspace, now is good.
[10:03] <voidspace> frobware: cool
[10:04] <voidspace> frobware: hmm.... the one-to-one isn't on my calendar for some reason
[10:04] <voidspace> frobware: what hangout should we use?
[10:05] <frobware> voidspace, I just sent you an invite (https://plus.google.com/hangouts/_/ejtwk7d5mqnwljcwmbxkvzi2uaa?hl=en-GB&authuser=0)
[10:06] <voidspace> frobware: gah, I have to do the authentication dance - there in a minute
[10:18] <voidspace> frobware: https://bugs.launchpad.net/juju-core/+bug/1435283
[10:18] <mup> Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment <addressability> <bug-squad> <network> <openstack-provider> <juju-core:Triaged by mfoord> <https://launchpad.net/bugs/1435283>
[10:20] <voidspace> frobware:  http://reviews.vapour.ws/r/2593/
[10:23] <dimitern> voidspace, I'm fine with calling it preferred instead of default
[10:30] <voidspace> dimitern: yeah, me too
[12:12] <rogpeppe> mwhudson, anyone else: do you know the status of this bug? https://bugs.launchpad.net/juju-core/+bug/1494441
[12:12] <mup> Bug #1494441: ppc64el: cannot find package "encoding" <blocker> <ci> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <gccgo-go (Ubuntu):Invalid> <gccgo-go (Ubuntu Trusty):In Progress> <https://launchpad.net/bugs/1494441>
[12:19] <perrito666> hey, if I wanted to stop/start juju mongo on local provider, where would I find the start/stop script?
[12:26] <perrito666> meh systemv
[12:42] <rogpeppe> jam1: any idea if this bug is likely to be fixed, by any chance? https://bugs.launchpad.net/juju-core/+bug/1494441
[12:42] <mup> Bug #1494441: ppc64el: cannot find package "encoding" <blocker> <ci> <ppc64el> <regression> <unit-tests> <juju-core:Triaged> <gccgo-go (Ubuntu):Invalid> <gccgo-go (Ubuntu Trusty):In Progress> <https://launchpad.net/bugs/1494441>
[12:42] <rogpeppe> jam1: it's blocking us currently
[12:45] <jam> rogpeppe: this is the first that I've heard of the problem. It is marked as In Progress my mwhudson
[12:46] <rogpeppe> jam: ok, thanks. i'll wait for him to come online
[12:46] <jam> which might be the patch he proposed, I'm not sure the timeline for getting that actually into the trusty gcc-go build
[12:46] <jam> alexisb would be another person to raise awareness of the bug to
[12:52] <mattyw> wallyworld, just saw the news, congratulations
[12:53] <wallyworld> mattyw: 4th one in 5 years :-(
[12:53] <wallyworld> as bad as italy
[12:53] <mattyw> wallyworld, you going to put your name forward?
[12:53] <wallyworld> thinking about it
[12:54] <wallyworld> can't do any worse
[13:03] <fwereade> ok, I have been pushing through a filthy headache for a while, and I'm not actually getting anything done
[13:03]  * fwereade goes to lie down
[14:22] <mup> Bug #1495542 opened: 1.20.x cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1495542>
[14:27] <katco> ericsnow: natefinch: looks like there is a new blocker: 1495542
[14:27] <katco> bug 1495542
[14:27] <mup> Bug #1495542: 1.20.x cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1495542>
[14:28] <ericsnow> katco: related to #1494070, perhaps?
[14:28] <mup> Bug #1494070: unit agent upgrade steps not run <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1494070>
[14:28] <katco> ericsnow: sounds plausibly correct. sinzui is that a dupe?
[14:30] <katco> ericsnow: at any rate, pick that one up and maybe you'll find they're the same thing
[14:30] <katco> ericsnow: pick the blocker up that is
[14:30] <ericsnow> katco: k
[14:30] <natefinch> godspeed, ericsnow
[14:30] <mgz> katco: my guess is it's not related
[14:31] <natefinch> I've always wanted to say that
[14:31] <mgz> katco: as we have to un-run upgrade steps, one long standing, and casey hacked around the other one
[14:32] <ericsnow> katco, natefinch: FYI, looks like the 1.25-beta1 list has several open that have been resolved
[14:33] <katco> ericsnow: example?
[14:34] <ericsnow> katco: #1465317
[14:34] <mup> Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series <osx> <packaging> <wily> <windows> <juju-core:Triaged> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1465317>
[14:34] <sinzui> katco: ericsnow Well, if that bug is a dupe then it isn't 100% correct. http://reports.vapour.ws/releases/3049/job/aws-upgrade-20-trusty-amd64/attempt/8 shows 1.20 can upgrade to 1.25
[14:34] <ericsnow> may or may not be forward-ported
[14:35] <katco> ericsnow: what makes you say this is resolved?
[14:36] <ericsnow> katco: fixed in an earlier version
[14:36] <katco> ericsnow: how do you know that? and why isn't this bug targeted to that version?
[14:36]  * ericsnow only skimmed through, so only a quick estimation
[14:37] <ericsnow> katco: sorry, bad example
[14:37] <katco> ericsnow: no worries, just trying to get up to speed
[14:37] <ericsnow> katco: #1468815 is better
[14:37] <mup> Bug #1468815: Upgrade fails moving syslog config files "invalid argument" <ci> <regression> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1468815>
[14:38] <katco> ericsnow: k, same question... what makes you think it's resolved in 1.25-beta?
[14:38] <ericsnow> katco: it *might* be resolved already
[14:38] <katco> ericsnow: based on what?
[14:39] <ericsnow> katco: fix-released on 1.24
[14:39] <katco> ericsnow: so you're thinking 1.25-beta1 was cut after this fix was released?
[14:40] <ericsnow> katco: rather that someone may have forward-ported and not updated the ticket
[14:40] <ericsnow> katco: or that it just needs a forward-port
[14:41] <katco> ericsnow: couldn't we say that about any bug?
[14:41] <ericsnow> katco: sure, as long as it's been fixed in an earlier release
[14:42] <ericsnow> katco: another example: #1449054
[14:42] <mup> Bug #1449054: Intermittent panic: rescanned document <ci> <test-failure> <juju-core:Triaged> <juju-core 1.22:Fix Released by dimitern> <juju-core 1.23:Won't Fix by fwereade> <juju-core 1.24:Fix Released by fwereade> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1449054>
[14:42] <katco> ericsnow: hm. just unsure why someone would go through the trouble of forward-porting without updating the bug.
[14:43] <ericsnow> katco: sometimes folks simply merge an earlier branch forward, picking up multiple fixes
[14:43] <katco> ericsnow: ah, this is the whole merge vs. cherrypick issue?
[14:43] <ericsnow> katco: sometimes
[14:44] <ericsnow> katco: anyway, at the least there are some bugs on that list that may just need forward-porting
[14:44] <katco> ericsnow: yep
[14:44] <ericsnow> katco: I guess that was my original point lol
[14:44] <katco> ericsnow: thanks for walking me through your thought process
[14:44] <ericsnow> katco: haha
[14:45] <katco> ericsnow: no seriously :) just wasn't understanding how you arrived at that conclusion
[14:45] <ericsnow> katco: mostly I skimmed through the list and several looked like ones we'd already fixed :)
[15:50] <rogpeppe> hi peeps, this PR was backed out earlier because of issues not directly related to the PR itself. This is a re-proposal: https://github.com/juju/juju/pull/3275
[15:50] <rogpeppe> could someone please rubberstamp it please?
[16:03] <dooferlad> dimitern: ping!
[16:04] <dooferlad> dimitern, voidspace: https://plus.google.com/hangouts/_/canonical.com/networking?authuser=0
[16:04] <dimitern> dooferlad, omw
[16:07] <cmars> rogpeppe, looking
[16:07] <rogpeppe> cmars: thanks
[16:08] <rogpeppe> cmars: though i already have two reviews, just waiting for the juju blockage clouds to lift momentarily so i can land it
[16:16] <mup> Bug #1495591 opened: TestRunCommand fails on windows <blocker> <ci> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1495591>
[16:18] <voidspace> dooferlad: omw
[16:19] <voidspace> dooferlad: thanks
[16:19] <voidspace> dooferlad: ah, I'm late
[16:19] <mup> Bug #1495591 changed: TestRunCommand fails on windows <blocker> <ci> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1495591>
[16:25] <mup> Bug #1463408 changed: TestRunCommand fails <ci> <intermittent-failure> <test-failure> <juju-core:Fix Released> <juju-core db-log:Fix Released> <https://launchpad.net/bugs/1463408>
[16:25] <mup> Bug #1495591 opened: TestRunCommand fails on windows <blocker> <ci> <test-failure> <windows> <juju-core:Triaged by cmars> <https://launchpad.net/bugs/1495591>
[16:28] <mup> Bug #1463408 opened: TestRunCommand fails <ci> <intermittent-failure> <test-failure> <juju-core:Fix Released> <juju-core db-log:Fix Released> <https://launchpad.net/bugs/1463408>
[16:40] <mup> Bug #1463408 changed: TestRunCommand fails <ci> <intermittent-failure> <test-failure> <juju-core:Fix Released> <juju-core db-log:Fix Released> <https://launchpad.net/bugs/1463408>
[16:54] <rogpeppe> here's a mostly-cosmetic change to the apiserver internals. review appreciated: http://reviews.vapour.ws/r/2656/
[18:07] <jam> katco: ping
[18:07] <katco> jam: pong
[18:08] <jam> katco: hi. are you able to meet tomorrow sometime early-ish in your morning?
[18:09] <katco> jam: sure
[18:09] <katco> jam: calendar is up to date
[18:09] <jam> 11 or 12 utc ?
[18:10] <katco> jam: 12 would work better, but can make either time
[18:15] <katco> jam: thx for taking the time to meet
[18:16] <jam> katco: happy to
[18:26] <natefinch> that feeling when you've changed a whole bunch of code and finally get it all compiling... and the tests all pass on the first try.
[18:26] <natefinch> <_<
[18:26] <natefinch> >_>
[18:26] <natefinch> not sure if tests are passing because you did it right... or there weren't tests for this code.
[19:01] <jam> rick_h_: your early meeting tomorrow needs to be postponed. I have to go to my son's school right at that time.
[19:02] <jam> anastasiamac: rick_h_: ^ same time on Wed works for me. I can also easily go 1 hr later if that helps Rick
[19:07] <katco> ericsnow: natefinch: can i run a question by one/both of you about constraints?
[19:07] <ericsnow> katco: sure
[19:07] <katco> ericsnow: moonstone
[19:09] <rick_h_> jam: all good will work with anastasiamac and see what can be done
[19:26] <mgz> ericsnow: do you need any help with bug 1495542?
[19:26] <mup> Bug #1495542: 1.20.x cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1495542>
[19:27] <ericsnow> mgz: not sure yet
[19:27] <ericsnow> mgz: still making sense of the logs
[19:27] <ericsnow> mgz: machine-0.log shows a panic, but the cause isn't exactly clear
[19:27] <ericsnow> yet
[19:30] <mgz> ericsnow: hm, as does the previous run, suggests it's not random
[19:32] <mgz> ericsnow: the end cause of the test being failed is that the `juju set` token didn't propogate through the relation between charms
[20:05] <mup> Bug #1495681 opened: quickstart delployments broken in 1.24 <blocker> <ci> <quickstart> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1495681>
[20:08] <mup> Bug #1495681 changed: quickstart delployments broken in 1.24 <blocker> <ci> <quickstart> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1495681>
[20:14] <mup> Bug #1495681 opened: quickstart delployments broken in 1.24 <blocker> <ci> <quickstart> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1495681>
[20:17] <mup> Bug #1495681 changed: quickstart delployments broken in 1.24 <blocker> <ci> <quickstart> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1495681>
[20:20] <mup> Bug #1495681 opened: quickstart delployments broken in 1.24 <blocker> <ci> <quickstart> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1495681>
[20:48] <perrito666> wow, juju is not especially smart to report when it has issues with the state server
[20:51] <wallyworld> ericsnow: i'll take the session closed bug off your hands; looking at your analysis (thank you) it looks like something tanzanite landed is the cause
[20:51] <ericsnow> wallyworld: \o/
[20:52] <katco> wallyworld: hey have a sec before the release standup?
[20:52] <wallyworld> katco: still in my jammies, just woke up, give me a few
[20:52] <katco> wallyworld: np at all... w/e you have time (can use 1:1)
[20:52] <wallyworld> ok
[20:53] <anastasiamac> ah there is proof that wallyworld does indeed sleep sometimes :D
[20:54] <wallyworld> haha
[20:54] <wallyworld> like you can talk :-P
[20:54] <anastasiamac> :P
[20:54] <perrito666> you should be both sleeping
[20:55] <anastasiamac> perrito666: no sleep for me - school dropoff :)
[20:56] <perrito666> do you people not have school buses?
[20:56] <perrito666> or school kangaroos?
[20:56] <mup> Bug #1495681 changed: quickstart delployments broken in 1.24 <blocker> <ci> <quickstart> <regression> <juju-core:Invalid> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1495681>
[21:09] <anastasiamac> perrito666: not form where we r and not for 3yo anyway..
[21:09] <anastasiamac> perrito666: school buses here otherwise r known as parents :D
[21:09] <perrito666> anastasiamac: well that sounds terribly inefficient
[21:10] <anastasiamac> perrito666: are u saying tha parents r not efficient?
[21:10] <anastasiamac> :D
[21:11] <perrito666> well I live around the corner to a school
[21:12] <perrito666> parents here seem to think that their children might break if they walk something more than 2m
[21:12] <perrito666> which causes a heavy traffic jam 3 times a day
[21:30] <xwwt2> alexisb: We are running late
[21:30] <alexisb> xwwt2, ack
[21:37] <xwwt2> alexisb: We are having a meeting running long with good info.  We should bag release meeting?
[21:37] <xwwt2> s/?/.
[21:37] <alexisb> xwwt2, we are meeting tha tis fine
[21:37] <alexisb> do what you need at the sprint
[22:20] <mup> Bug #1449054 changed: Intermittent panic: rescanned document <ci> <test-failure> <juju-core:Fix Released> <juju-core 1.22:Fix Released by dimitern> <juju-core 1.23:Won't Fix by fwereade> <juju-core 1.24:Fix Released by fwereade> <juju-core 1.25:Fix Released> <https://launchpad.net/bugs/1449054>
[22:32] <mup> Bug #1449054 opened: Intermittent panic: rescanned document <ci> <test-failure> <juju-core:Fix Released> <juju-core 1.22:Fix Released by dimitern> <juju-core 1.23:Won't Fix by fwereade> <juju-core 1.24:Fix Released by fwereade> <juju-core 1.25:Fix Released> <https://launchpad.net/bugs/1449054>
[22:35] <mup> Bug #1449054 changed: Intermittent panic: rescanned document <ci> <test-failure> <juju-core:Fix Released> <juju-core 1.22:Fix Released by dimitern> <juju-core 1.23:Won't Fix by fwereade> <juju-core 1.24:Fix Released by fwereade> <juju-core 1.25:Fix Released> <https://launchpad.net/bugs/1449054>
[23:15] <wallyworld> axw: anastasiamac: perrito666: give me a minute
[23:15] <anastasiamac> wallyworld: k
[23:25] <wallyworld> anastasiamac: we in standup