[00:01] <jw4> thumper: for context we've been building up a backlog of code in the juju-actions repo - your feature flags made it possible for us to begin landing that code without it being available by default while it's incomplete
[00:04]  * thumper nods
[00:08] <perrito666> ericsnow: is it tomorrow for you already?
[00:08] <perrito666> I sent the two first patches for restore :p
[00:08] <ericsnow> perrito666: yeah, I saw
[00:08] <ericsnow> perrito666: sweetness
[00:09]  * perrito666 wonders how many more times is the power going to go off
[00:09]  * perrito666 also wonders why he forgot to get an UPS for the internet
[00:13] <anastasiamac_> thumper: was my answer to block.ProcessBlockedError doesn't use errors.Cause(err) digestable?
[00:14] <anastasiamac_> thumper: "was my answer to your question - why block.ProcessBlockedError doesn't use errors.Cause(err) -  digestable?" even
[00:14] <thumper> anastasiamac_: hey
[00:14] <thumper> just busy right now
[00:14] <thumper> with you shortly
[00:14] <anastasiamac_> thumper: np
[00:30] <thumper> anastasiamac_: well yesterday with my machine branch, I changed it to use errors.Cause
[00:31] <anastasiamac_> thumper: did ur machine branch land?
[00:31] <thumper> anastasiamac_: yep
[00:32] <thumper> anastasiamac_: all tests pass
[00:32] <thumper> anastasiamac_: don't stress, I know what I'm doing
[00:44] <mgz_> menn0: I'll fix that, looks like an unrelated ci-tools change brought in a dep it probably shouldn't
[00:47] <anastasiamac_> thumper: m not stressed about tests but the actual output on command line :D
[00:47] <thumper> anastasiamac_: doesn't change
[00:49] <thumper> jw4: review done...
[00:49] <jw4> thumper: much appreciated
[00:50] <jw4> thumper: just getting ready to update the TestHelpCommands for with and without feature
[00:52]  * thumper nods
[00:52] <jw4> thumper: good feedback - I'll work on some of these, but bodie_ knows more about most of this.
[00:52] <thumper> jw4: I recomment quite a few changes
[00:53] <anastasiamac_> thumper: thnx ')
[00:54] <jw4> thumper: s/recomment/recommend/? : if so, yeah - good stuff
[00:55] <thumper> was going for recommended
[00:55] <jw4> hehe
[00:55]  * thumper shrugs
[00:55]  * thumper is very tired
[00:59] <thumper> perrito666: are you looking at the joyent bug?
[01:03] <mgz_> menn0: requeued
[01:15] <thumper> menn0: it seems that the immutable values aren't tested in the state tests, but probably are in the config
[01:15]  * thumper double checks
[01:16] <menn0> mgz_: thank you!
[01:17] <thumper> menn0: yep tested there
[01:17] <menn0> thumper: ok. so is that good enough for them not be retested at the API level?
[01:18] <thumper> menn0: I think I'll leave one there to show the message
[01:18] <thumper> but won't do all
[01:18] <menn0> thumper: that sounds good to me
[01:21] <thumper> menn0: you seem to be invoking the boyscout rule of code
[01:21] <thumper> menn0: I'll clean the code even though it isn't my mess :-)
[01:27] <anastasiamac_> thumper: boyscout rule of code...
[01:28] <thumper> anastasiamac_: leave the code cleaner than you found it
[01:28] <thumper> anastasiamac_: like "leave the camp ground cleaner than you arrived"
[01:29] <anastasiamac_> thumper: oh.. and i thought it was "pray at the end of the session'...
[01:29] <thumper> haha
[01:29] <thumper> maybe that is apt too
[01:29] <thumper> pray before submitting
[01:29] <anastasiamac_> thumper: at least, that's what boyscout groups do here
[01:29] <anastasiamac_> thumper: :D
[01:30] <anastasiamac_> menn0: thnx for cleaning messes!
[01:30] <anastasiamac_> menn0: and campsites
[01:42] <menn0> anastasiamac_, thumper: :)
[01:42]  * thumper frowns
[01:42] <thumper> ah...
[01:42] <thumper> fark
[01:43] <thumper> found it
[01:44] <menn0> I just saw all the Ship Its for one of my branches. Thanks all for reviewing my fix that moves one line of code :)
[01:48] <menn0> thumper: should someone be looking at bug 1401130?
[01:48] <mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1401130>
[01:48] <menn0> that's the other CI blocker
[01:49] <thumper> menn0: I just had to get in on that action
[01:49] <thumper> menn0: I thought perrito666 was looking at it, but he enver marked himself as in progress
[01:49] <thumper> ericsnow: do you know?
[01:49] <ericsnow> thumper: nope
[01:50] <perrito666> thumper: I have been having power issues the whole day and I tried to look at it without much success
[01:50] <ericsnow> thumper: nate said he was going to get someone on it earlier in the day
[01:50] <thumper> menn0: if you could look that would be very helpful
[01:50]  * perrito666 has not had a full hour with power today
[01:50] <thumper> do we have creds we can use?
[01:50] <menn0> thumper: ok
[01:50] <menn0> thumper: I think I know where to look
[01:51] <thumper> menn0: oh, ok
[02:00] <thumper> menn0: just one question on your review on environments command that made no sense to me
[02:00] <thumper> menn0: could I get you to clarify?
[02:00] <menn0> thumper: sure
[02:00] <thumper> currently running the entire test suite
[02:01] <perrito666> thumper: I dont, I was running things through sinzui
[02:02] <thumper> perrito666: that's ok, menn0 is on it :)
[02:02] <thumper> \o/
[02:03] <menn0> thumper: yeah, that comment makes no sense. if there was something to unset it wouldn't be unknown :)
[02:03] <menn0> thumper: drop that
[02:03] <thumper> ok
[02:11] <anastasiamac_> thumper: RB shows that block tests were lost again (on environment super-command branch)
[02:11] <anastasiamac_> thumper: is it just RB's perspective?
[02:11] <thumper> anastasiamac_: yeah
[02:11] <thumper> also... wat?
[02:11] <thumper> no definitely there
[02:12] <thumper> but moved
[02:12] <thumper> and changed
[02:12] <thumper> \o/.
[02:12] <thumper> set_test.go, unset_test.go
[02:12] <anastasiamac_> thumper: tyvm for making them cleaner and more readibale
[02:12] <thumper> at the bottom
[02:13] <anastasiamac_> thumper: a bit of boyscouting seem to run in nz
[02:13] <thumper> that's fine
[02:13] <thumper> all good
[02:15] <thumper> by faking out the api fully we get much more control over tests
[02:15] <thumper> and we stop testing everything at every layer
[02:15] <thumper> which is a waste
[02:15] <thumper> as long as we still have enough tests to show that everything is wired up correctly
[02:17] <anastasiamac_> thumper: makes sense! thnx again :-)
[02:17] <thumper> that's fine
[02:23] <dimitern> axw, ping
[02:24] <dimitern> thumper, afternoon
[02:26] <dimitern> http://reviews.vapour.ws/r/611/ can any of you have a look at this MP for bug 1397376 please?
[02:26] <mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
[02:27] <thumper> o/ dimitern
[02:29] <axw> dimitern: pong
[02:29] <axw> ok
[02:31] <dimitern> axw, ta!
[03:08] <alexisb> jam, leads call
[03:47] <menn0> thumper: ping?
[03:47] <thumper> menn0: otp
[03:48] <menn0> thumper: i've reproed and characterised bug 1401130. I've added the details to the ticket.
[03:48] <mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1401130>
[03:49] <menn0> thumper: not sure where to look now. we might need to contact Joyent.
[03:49] <thumper> ok
[04:10] <menn0> thumper: I need to head out for a bit but will be back later
[04:10] <thumper> kk
[04:12] <thumper> jam, dimitern: passing on this critical bug to you two: https://bugs.launchpad.net/juju-core/+bug/1401130
[04:12] <mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1401130>
[04:13] <dimitern> thumper, ok
[04:13] <thumper> dimitern: menno added details, including some diagnostics
[04:13] <dimitern> btw my chrome crashed, but I still hear audio - no video from the call
[04:13] <jam> thumper: so all of the discussion I read on that seems to be pointing fingers at Joyent.
[04:13] <thumper> dimitern: very networky
[04:14] <jam> dimitern: we can still see your video feed
[04:14] <jam> I've seen that when you run into JS in another window locking up
[04:14] <dimitern> wow - it did crash without kicking me out of the hangout and then fixed itself
[04:26] <jam> fwereade: I keep meaning to schedule time to chat with you again, and now we're at the end of my week. Ping me when you're around
[04:30] <dimitern> menn0, ping
[04:31] <dimitern> thumper, menn0, jam, do we have any joyent testing account I could use?
[05:10] <menn0> dimitern: hi i'm back
[05:11] <dimitern> menn0, hey, it's fine jam got me sorted out; but can I still bug you if I have questions re bug 1401130?
[05:11] <mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1401130>
[05:12] <menn0> dimitern: sure can
[05:12] <menn0> dimitern: i've got to help get kids to bed but just ask here and i'll get back to you
[05:12] <menn0> dimitern: did you see the details i added to the ticket
[05:12] <dimitern> menn0, cheers, no worries
[05:13] <dimitern> menn0, yeah, it looks weird.. I'll dig into it some more
[05:13] <menn0> dimitern: my theories are that either something's wrong at joyent
[05:13] <menn0> dimitern: or Juju is using the wrong addresses or wrong routing
[05:14] <menn0> or wrong netmasks
[05:15] <menn0> dimitern: i'll check back in a bit
[05:15] <dimitern> menn0, right
[06:13] <menn0> dimitern: hey hey, kids asleep. i've got a little bit of time.
[06:13] <menn0> dimitern: figure anything out?
[06:13] <dimitern> menn0, nope, I was preparing a response to axw's review
[06:13] <dimitern> menn0, but since you're here, I'll try it now
[06:14] <menn0> dimitern: kk
[06:14] <menn0> dimitern: i'm just creating a card on LK
[06:14] <dimitern> axw, thanks btw - you've raised some very good points
[06:14] <axw> dimitern: nps
[06:15] <axw> dimitern: did you go to sleep last night? you were on very early :)
[06:15] <axw> or are you sprinting
[06:15] <dimitern> axw, I did - shortly after 8pm
[06:15] <dimitern> to wake up in time for the 5am call :)
[06:15] <axw> ah, fun
[08:06] <fwereade> jam, heyhey
[08:27] <jam> hey fwereade, how's it going?
[08:27] <jam> just finishing up lunch, care to meet in about 30min?
[08:27] <fwereade> jam, ehh, tolerable, a bit low-level fluey, but yes let's
[08:43] <dimitern> I'd appreciate a review on http://reviews.vapour.ws/r/623/ - it unblocks ci for the critical bug 1401130
[08:43] <mup> Bug #1401130: Joyent deployments cannot download agents from state-server <ci> <joyent-provider> <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1401130>
[08:45] <dimitern> jam, axw, menn0, ^^
[08:48] <jam> dimitern: that seems like our Networker needs some lovin', but otherwise LGTM
[08:48] <jam> dimitern: you did test that it both *failed* before this, and *worked* after, right?
[08:50] <dimitern> jam, indeed it does :)
[08:51] <dimitern> jam, I couldn't get it to fail as described, but I've seen the overwritten /etc/network/interfaces file, which wasn't including eth1.cfg for the internal network the api server is on
[08:51] <dimitern> jam, after the fix it doesn't happen
[08:53] <dimitern> jam, so even though the networker didn't stop eth1 it won't be brought up after reboot
[08:58] <jam> fwereade: whenever you would like to chat
[08:58] <fwereade> jam, joining sapphire standup
[08:58] <jam> dimitern: right, so they have a custom /etc/network/interfaces which we are overwriting and not quite matching what was there
[08:59] <jam> and dimitern, we aren't really going to be having a smart networker on Joyent soon anyway, so we're fine
[08:59] <dimitern> jam, yeah, and by sheer chance eth0 wasn't brought down (the one with the public ip) as it was considered "primary" :)
[09:00] <dimitern> jam, so I could ssh into it, and eth1 wasn't present in state (no network info during provisioning), so it wasn't stopped immediately
[09:00] <dimitern> jam, definitely not a priority now
[09:10] <dimitern> mgz_, ping
[10:01] <dimitern> jam, omw to standup
[10:01] <jam> dimitern: core-team meeting today
[10:01] <dimitern> oops team meeting actually
[10:01] <dimitern> jam, backport of that joyent bug fix for 1.21 if you're so kind :) http://reviews.vapour.ws/r/624/
[10:02] <jam> dimitern: did you have time to test it explicitly as well, or is it just a strict backport w/o testing ?
[10:02] <jam> axw: team meeting? (if you're available)
[10:03] <jam> mgz_: do you come to the juju-core-team meetings to see how we're doing ?
[10:03] <dimitern> jam, testing now
[10:04] <jam> dimitern: reviewed
[10:05] <jam> wwitzel3: if you are around as well
[10:05] <dimitern> jam, cheers
[10:19] <menn0_> dimitern: i'm back
[10:20] <menn0_> dimitern: glad that you got it figured out
[10:20] <dimitern> menn0_, yeah, I got lucky I guess :)
[10:41] <jam> fwereade: selfie got added to the Oxford dictionary, but I don't think Moar has reached that level yet :)
[10:42] <jam> fwereade: I need moar coffee, but then I'm up for moar chatting if you would like
[12:34] <perrito666> wwitzel3: ping me when you are back please
[12:52] <perrito666> axw: tx for the reviews you are the first person ever to review that part of restore :p it was too far at the end of the large patch
[14:32] <mbruzek> ping abentley
[14:32] <abentley> mbruzek: pong
[14:33] <mbruzek> Good morning.  I kicked off 5 jenkins builds yesterday to retest some of the charms hoping to update the report by charm: http://reports.vapour.ws/charm-tests-by-charm
[14:34] <mbruzek> abentley:  #10658, #10659, #10660, #10663, #10664.
[14:34] <mup> Bug #10658: evms: new changes from Debian require merging <evms (Ubuntu):Fix Released by mdz> <https://launchpad.net/bugs/10658>
[14:34] <mup> Bug #10659: mozilla-firefox-locale-it: new changes from Debian require merging <mozilla-firefox-locale-it (Ubuntu):Fix Released by thombot> <https://launchpad.net/bugs/10659>
[14:34] <mup> Bug #10660: Modem lights not working with "networks" <gnome-applets (Ubuntu):Invalid by seb128> <https://launchpad.net/bugs/10660>
[14:34] <mup> Bug #10663: Boot menu help references Morphix <Ubuntu:Invalid by amu> <https://launchpad.net/bugs/10663>
[14:34] <mup> Bug #10664: Framebuffer bootsplatch logo jpeg-like <Ubuntu:Fix Released by amu> <https://launchpad.net/bugs/10664>
[14:34] <mbruzek> Those are not bugs sorry about that.
[14:34] <mbruzek> Those are jenkins build numbers.
[14:35] <mbruzek> abentley: None of the results were reflected on the report on vapour.  Is there another step that has to happen to get the report to update?
[14:36] <abentley> mbruzek: No, it should update automatically within a minute.  I'll try to see what's going on.
[14:36] <mbruzek> abentley: The consol output shows the s3cmd run at the end of the last 4 of those 5.
[14:36] <mbruzek> abentley: Thanks for looking into it
[14:42] <abentley> mbruzek: I see results for everything except 10658.
[14:44] <mbruzek> abentley: I see results for all of them but they are not updated with the Dec 10 results.  http://reports.vapour.ws/charm-tests-by-charm
[14:45] <mbruzek> abentley: for example build 10659 is cs:precise/shelrtv, that entry has a date of August 26 2014, not December 10
[14:46] <mbruzek> abentley: build 10660 is cs:precise/solr, the entry on reports has it at September 09
[14:47] <mbruzek> abentley: I see other December 10 entries, just not for the ones I request on December 10.
[14:47] <ericsnow> wwitzel3: should we just get started after standup?
[14:48] <abentley> mbruzek: Everything you built is shown in the "All charm and bundle results" table.
[14:48] <ericsnow> wwitzel3: I'm available before too
[14:48] <abentley> mbruzek: I suspect this is a sorting bug.
[14:49] <mbruzek> abentley: OK I was looking at the charm-tests-by-charm what process builds that report?
[14:51] <mbruzek> abentley: I see a difference. the ones I requested were cs:precise/charm-name the ones in the charm-tests-by-charm have a revision number in the name.
[14:51] <abentley> mbruzek: That report is generated on the fly.  The results are ingested from s3 by a shell script.
[14:51] <abentley> mbruzek: Well, a python script.
[14:51] <mbruzek> abentley: So the ones I requested are missing a revision number.
[14:52] <abentley> mbruzek: That's right.  We test specific charm versions when we do automatic testing.
[14:52] <mbruzek> abentley: But how would I know the version numbers?  I just wanted to test the latest charm so I sent "cs:precise/solr" to charmguardian
[14:53] <abentley> mbruzek: That's not something we support, but the charm store and manage.jujucharms.com know the charm versions.
[14:54] <abentley> mbruzek: Since you're retesting the same version, you can also just look at the previous test results.
[14:57] <voidspace> dimitern: any objection to me moving decimalToIP and ipToDecimal into network and making them public?
[14:57] <voidspace> dimitern: I need them in ec2
[14:57] <dimitern> voidspace, +1
[14:57] <voidspace> dimitern: or at least I *may* do, I'll only move them if I actually need them
[14:57] <voidspace> dimitern: cool, thanks
[14:57] <mbruzek> abentley: How is it supposed to work?  When the charms get a new version number are new tests kicked off?  I thought I saw a few instances where the charms are of a newer revision.
[14:58] <mbruzek> And the tests did not get kicked off.
[14:58] <dimitern> voidspace, sorry, I got deep into bug fixing again and haven't actually asked how's it going today? :)
[14:58] <abentley> Yes, when the charms get a new version number we see that we have no results for that number in the database, so we kick off a new test.
[14:58] <dimitern> voidspace, any issues?
[15:00] <dimitern> voidspace, I hope you are feeling better today
[15:00] <ericsnow> fwereade: axw suggested I ask you about http://reviews.vapour.ws/r/608/
[15:02] <abentley> mbruzek: Please file a bug, but be aware that certain charms are blacklisted because they break charmguardian: cs:precise/cassandra cs:trusty/hdp-hadoop cs:trusty/swift-proxy
[15:03] <mbruzek> abentley: I am not trying to create more work, I just did not know an easy way to find the version number.
[15:04] <mbruzek> abentley: bug against charmguardian?
[15:04] <abentley> mbruzek: No, if you see instances where we failed to test a new version, file a bug against https://launchpad.net/juju-reports
[15:09] <voidspace> dimitern: a bit better
[15:09] <voidspace> dimitern: well enough to not be in bed anyway :-)
[15:09] <voidspace> dimitern: yeah, going fine - I've just picked back up the Subnets work
[15:09] <voidspace> dimitern: no issues - you were right about aws
[15:09] <voidspace> dimitern: first four and last IP in a CIDR are reserved
[15:10] <dimitern> voidspace, \o/
[15:11] <dimitern> voidspace, great, ping me if there's anything then :)
[15:11] <voidspace> dimitern: I will do, thanks
[15:28] <fwereade> ericsnow, I'm a bit unconvinced by putting az into *every* relation setting
[15:28] <fwereade> ericsnow, what's the thinking behind that?
[15:29] <fwereade> ericsnow, we definitely agreed to make AZ available to units
[15:29] <ericsnow> fwereade: to be honest I just followed the example of the IP address
[15:29] <fwereade> ericsnow, but I don't see how that translates to making them part of everyrelation protocol
[15:30] <ericsnow> fwereade: as far as I understand it is part of the spec: https://docs.google.com/a/canonical.com/document/d/1yVlzgKqfhKccUbm3WcZBq7WnzglBygknscr_I_u4bUg/edit
[15:30] <abentley> mbruzek: So here's what's going on: cs:trusty/hdp-storm-3 breaks charmguardian, so we never get any results for it.  Since we don't have any results for it, we test it, and we never get around to anything else.  This has been going on with hdp-zookeeper, hdp-tez, hdp-storm, hdp-pig, hdp-hive, hdp-hive since Nov 22.
[15:30] <wwitzel3> when deploying a local charm using local provider, do that charm get cached anywhere?
[15:31] <ericsnow> fwereade: it's entirely possible I took the wrong approach
[15:31] <wwitzel3> or will juju already just read from the path I provide it
[15:31] <mbruzek> abentley: thus the black list that I read about?
[15:31] <ericsnow> fwereade: I've been nervous at how small that patch is :)
[15:32] <abentley> mbruzek: Yes.
[15:32] <fwereade> ericsnow, hmm, so, I do see that in there, but (1) it only mentions peers and (2) I think it's a really bad idea
[15:32] <ericsnow> fwereade: See the "exposing to charms" section and the part about relation-get in the "mechanisms" section
[15:32] <fwereade> ericsnow, so on one side we shouldn't be inserting it in non-peer relations
[15:32] <ericsnow> fwereade: I'm fine with dropping it but it's not my spec :)
[15:33] <ericsnow> fwereade: good point
[15:33] <fwereade> ericsnow, and on the other, every charm which uses a peer relation now suddenly has two protocols, and might be using one or the other depending on what the juju version is
[15:33] <fwereade> ericsnow, which is probably not *that* harmful because I'm pretty certain we don't distinguish between "" and `missing` in relation-get
[15:35] <mbruzek> abentley: What about the storage charm?  Is that on your blacklist?  I tried running that one several times and it never gets to the s3cmd to upload the results.
[15:35] <fwereade> ericsnow, but still :)
[15:35] <fwereade> hazmat, ping
[15:35] <mbruzek> abentley: build 10647, 10658
[15:35] <abentley> mbruzek: No, it's not on the blacklist.
[15:36] <abentley> mbruzek: I have not figured out why that one doesn't upload to s3, but it isn't breaking charmguardian like the others did.
[15:36] <ericsnow> fwereade: so is "private-address" set for all relations?
[15:37] <mbruzek> abentley: I will file a bug
[15:37] <fwereade> ericsnow, yes it is
[15:37] <ericsnow> fwereade: k
[15:38] <ericsnow> fwereade: so at the least "availability-zone" should only be set if the units in the relation are peers?
[15:38] <hazmat> fwereade, pong
[15:38] <ericsnow> fwereade: or are you opposed to the adding zones to relation-get at all?
[15:38]  * hazmat reads backlog
[15:39] <natefinch> fwereade, ericsnow, hazmat: my understanding is that we needed AZ for all relations
[15:39] <fwereade> hazmat, I'm surprised about putting AZ into any relation by default
[15:39] <fwereade> natefinch, so we should change the protocol for every relation, when we have enough trouble with protocols already? colour me unconvinced
[15:39] <hazmat> fwereade, at minimal to achieve the use case it needs to be in peer relations.
[15:40] <natefinch> fwereade: I was just following the spec... it says "The set of zone names in which peer **and per-relationship counterpart units are running**"
[15:40] <natefinch> fwereade: I might be misunderstanding the spec
[15:40] <hazmat> fwereade, its not a change in protocol its analogous to the work we already do with address
[15:40] <fwereade> hazmat, auto-adding it doesn't seem worth the effort -- can't the charms that need it make it part of theirprotocol explicitly?
[15:40] <hazmat> fwereade, they could.. however. its implicit to the iaas infrastructure provisioning responsibility juju is already taking
[15:41] <hazmat> having juju provide that for relations to me automatically seems a logical extension just as we do with ip addrs
[15:41] <fwereade> hazmat, fwiw it*is* a change in protocol, you may have a case that it's not an *important* change in the protocol
[15:41] <hazmat> fwereade, hence the notion of prefixing the key in the rel
[15:42] <hazmat> fwereade, the protocol communication itself is unchanged as its a seed value
[15:42] <fwereade> hazmat, and we make those keys unwritableby normal means?
[15:42] <hazmat> fwereade, no.. they should be writable
[15:42] <fwereade> hazmat, so the juju- prefix is just a sort of hint?
[15:42] <hazmat> fwereade, natefinch, ericsnow .. fwiw. i'm fine if we don't pre-seed the rels. the advantage requires explicit charm awareness and therefore they can seed
[15:43] <hazmat> fwereade, proxy charms need to override such values and it may not have meaning to them
[15:43] <fwereade> hazmat, indeed
[15:43] <fwereade> hazmat, if we don't *need* them in every relation I'd much rather not put them in any relations by default
[15:44] <hazmat> i think thats okay
[15:44] <fwereade> hazmat, cool, thanks
[15:46] <fwereade> hazmat, btw, about the suggested unit-get changes
[15:47] <fwereade> hazmat, given that the two existing uses of unit-get are basically broken in any world with interesting networks
[15:47] <fwereade> hazmat, is there any strong reason to add to unit-get vs putting them in env vars?
[16:04] <fwereade> hazmat, also I fear that spec needs rather more detail re listing zones and/or configuring zone spread
[16:05] <fwereade> hazmat, eg it makes no sense to make all provider zones available to a charm that's meant to spread over only 3 of them
[16:05] <fwereade> hazmat, and I'm not 100% sure it makes sense to tell a service with 2 units about the 3 zones over which it might spread
[16:06] <fwereade> hazmat, possibly specifying a zone spread should also imply a minimum unit count?
[16:07] <fwereade> hazmat, (also, what happens if zone spread changes? is it immutable?)
[16:07] <natefinch> fwereade: we had decided not to list available zones
[16:07] <natefinch> fwereade: only list zones in which units exist
[16:08] <natefinch> fwereade: or rather, only list zones for units.  No general list of zones
[16:08] <fwereade> natefinch, yeah, but *that's* tricky when you go from one unit to 3
[16:08] <fwereade> natefinch, in general, if we're changing info on which a charm depends, we should be firing some hook to let it know about it
[16:09] <fwereade> natefinch, which hooks should we fire?
[16:09] <perrito666> natefinch: standup?
[16:09] <natefinch> fwereade: it's just exposing information about the units
[16:09] <natefinch> fwereade: so, peer-relation-changed I guess?
[16:09] <fwereade> natefinch, right, but then every single unit comes up seeing itself alone in a single zone
[16:10] <fwereade> natefinch, so it's more about goal-state/active-state
[16:10] <fwereade> hazmat, btw, I would really appreciate your thoughts on that
[16:10] <fwereade> hazmat, there was a thread a couple of weeks back on juju-dev
[16:10] <fwereade> hazmat, something like "feature request: expose relations in juju status"
[16:11] <fwereade> hazmat, AFAICS we need to expose both those measures to be useful
[16:11] <fwereade> natefinch, (did you see that thread btw?)
[16:11] <natefinch> fwereade: btw I'm taking this over from eric, since he and wayne are heads down on GCE
[16:12] <fwereade> natefinch, ah ok :)
[16:12] <natefinch> fwereade: yeah, I remember the thread, though not too many specifics.
[16:13] <fwereade> natefinch, tbh I was hoping it'd get some more thought and responses
[16:14] <fwereade> natefinch, it may be that I need to write up a half-assed proposal before people will really start saying what won't work for them
[16:14] <natefinch> fwereade: the only way to get the right answer is to propose the wrong answer :)
[16:15] <fwereade> natefinch, yeah, indeed
[16:15] <fwereade> natefinch, http://thecodelesscode.com/case/170
[16:16] <hazmat> fwereade, sorry stepped out, catching up
[16:17] <hazmat> fwereade, unit-get still makes sense, and even more so with multiple networks, the issue atm that bites with unit-get is the address is both ip and dns addr which is inappropriate depending on the use case and needs disambiguation
[16:18] <hazmat> fwereade, zone is immutable for an instance lifetime
[16:20] <hazmat> fwereade, the zone spread behavior is independent of surfacing zone to a unit. i agree it would be nice to have some configurable policy on the zone spread but thats not really  the issue at hand, and even a default behavior of max 3 is good enough any use case that comes to mind.. the exception is max zone 1, but we've decided to punt on that one till we have actual need.
[16:21] <hazmat> fwereade, the information doesn't change, and the charm already hooks for observing and conveying this information via relations if it so choses
[16:22] <fwereade> hazmat, I know that a single unit's zone is immutable, but the list of zones -- be it those in the provider, or those across which units are spread -- is not necessrily so
[16:23] <fwereade> hazmat, if we're exposing the list, we need to notify on changes to the list
[16:23] <hazmat> fwereade, the mutation awareness in the zone set is accompanied by new units joining the relation and there by conveying that information
[16:23] <hazmat> fwereade, we're not exposing the list
[16:23] <fwereade> hazmat, the spec has unit-get list-zones
[16:23] <fwereade> hazmat, if we can drop that I'm totally fine there
[16:24] <hazmat> fwereade, i think that was speculative, and even then it would only be those of the units in the service
[16:24] <fwereade> hazmat, but then I'm not sure that there's much benefit to unit-get zone vs $JUJU_AVAILABILITY_ZONE
[16:24] <hazmat> fwereade, the full zone list isn't really meaningiful if the service isn't present
[16:24] <hazmat> in all of them
[16:24] <fwereade> hazmat, agreed
[16:24] <fwereade> hazmat, so then we still have the active/goal state issue, I think
[16:25] <fwereade> hazmat, that everything comes up in an empty universe and needs to wait around until it has the full picture
[16:25] <hazmat> fwereade, unit-get is an information channel.. we have other uses for it, including arrays of data (net lists, addrs. etc). i'd rather not baby and bath water everything into env vars
[16:25] <fwereade> hazmat, and is never quite certain when it does
[16:26] <hazmat> fwereade, being able to know the goal state of the service would be useful
[16:26] <hazmat> ie. 8 other units are expected
[16:27] <fwereade> hazmat, it kinda feels like what zones they'll be in is also relevant info -- or at least the expected spread?
[16:28] <hazmat> fwereade, depends on the software, mongo and cassandra don't care, they'll add new partitions to the token ring or replica set respectively.. there might be others that care
[16:28]  * hazmat checks on riak
[16:29] <fwereade> hazmat, (and it remains true that the only current uses of unit-get are problematic at best -- I have no problem with hook tools, but for completely static data env vars feel somewhat neater?)
[16:30] <hazmat> fwereade, disambiguating address to ip and address is separate issue, conflating them doesn't help.  just as problematic in an env var
[16:30] <fwereade> hazmat, the concern is that while bringing a service up (or, worse, scaling it while already running) we induce an orgy of rebalancing
[16:30] <fwereade> hazmat, ok, ip vs dns is *also* a problem
[16:31] <fwereade> hazmat, my problem is that private-address and public-address are damn near meaningless in a situation where we have two networks of each kind (leaving aside the question of exactly what "public" implies)
[16:31] <hazmat> fwereade, right it needs to grow and change re unit-get, but parsing lists in env var doesn't make that better
[16:32] <hazmat> vs a cli that can format per invoker request
[16:32] <fwereade> hazmat, I wasn't at *all* suggesting lists in env var, I was suggesting "my zone" in env var
[16:32] <fwereade> hazmat, on the basis that I imagine it to be just a string
[16:32] <fwereade> hazmat, listing zones is absolutely more suitable for a hook tool
[16:32] <fwereade> hazmat, no argument there
[16:33] <fwereade> hazmat, I just thought you'd said we could drop that
[16:34] <hazmat> fwiw just checked riak and influxdb neither has rack/zone awareness so not applicable.
[16:34] <hazmat> effectively the software needs some notion of that for zone awareness to be meaningful
[16:34] <fwereade> hazmat, addresswise, we were talking address-get [-r ...], please talk to dimitern re the details there
[16:34] <fwereade> hazmat, quite so
[16:35] <fwereade> hazmat, the issue is that one's address is not very meaningful except in relation to something else that wants to connect over that address
[16:35] <fwereade> hazmat, re goal state
[16:36] <fwereade> hazmat, at least knowing that 8 more units are coming
[16:36] <fwereade> hazmat, will allow you to hold off on configuring until you can see those 8 units, and they have told you their zones
[16:36] <hazmat> fwereade, zone in env var vs unit-get.. i'm fine either way.. i'd rather not get rid of unit-get.. and we have tons of dynamic env vars as well. so the distinction between the two mechanisms isn't really clear. cli commands are much more discoverable then undocumented env vars.
[16:36] <hazmat> but that's a separate case of actually documenting things that are implemented
[16:37] <fwereade> hazmat, I heartily agree that dynamic env vars are likely to be bugs, because we generally don't trigger on changes to same
[16:37] <fwereade> hazmat, state server address
[16:37] <fwereade> hazmat, proxy settings
[16:37] <fwereade> hazmat, no doubt more
[16:37] <hazmat> fwereade, re zone and goal state awareness, that feels like perfect enemy of good to paraphrase ;-)
[16:38] <hazmat> fwereade, potentially we could surface goal state awareness to leader to coordinate at some point
[16:38] <fwereade> hazmat, (fwiw I agree that https://juju.ubuntu.com/docs/authors-hook-environment.html#environment-variables is *incomplete*)
[16:39]  * fwereade glares around at everybody who may at some stage have added env vars without updating the docs
[16:39] <hazmat> leader election alone is the probably the biggest feature thats missing atm for charm authors (resource impl would be second). the zone spread behavior we currently exhibit has good enough effects for many, getting units to at least be zone aware allows more featureful things to be built.
[16:39] <hazmat> fwereade, goal state will never substitute for the need to handle runtime changes
[16:39] <fwereade> hazmat, I think goal state is necessary across the board so units can differentiate between waiting and blocked
[16:39] <fwereade> hazmat, I know that
[16:40] <hazmat> fwereade, and initial bring up has minimal thrashing due to lack of data
[16:40] <fwereade> hazmat, subsequent scaling, not so much
[16:41] <fwereade> hazmat, to restate the above, goal state feels like a necessary part of the status work
[16:41] <fwereade> hazmat, "I'm waiting for the rest of my cluster" vs "I can't do anything, 2/3 of my cluster is not talking to me HALP"
[16:42] <hazmat> fwereade, i think its useful to surface to the leader determing service health/status
[16:42] <hazmat> fwereade, but i don't see any reason that it can't be independently implemented later
[16:43] <fwereade> hazmat, ok, to take a step back
[16:43] <hazmat> fwereade, right.. but i don't think its useful to block features till their perfect, nothings perfect, but we incremental advance the state
[16:43] <fwereade> hazmat, I'm not trying to block anything
[16:43] <hazmat> k
[16:43] <fwereade> hazmat, AFAICS there is no disagreement re exposing to units what zone they're in
[16:44] <fwereade> hazmat, the more we add, the more quibbles I have, because I worry that it's prejudicing other features like goal state
[16:45] <hazmat> fwereade, service leader determining service state just provides proper point of invocation/consideration of goal state in future
[16:45] <hazmat> afaics
[16:45] <fwereade> hazmat, goal state allows units to report status better
[16:46] <fwereade> hazmat, so they can tell the difference between "I'm not working yet and that's fine because I know friends are coming" and "I'm not working yet and I never will until something changes"
[16:46] <fwereade> hazmat, but that is indeed a separate conversation
[16:47] <hazmat> fwereade, the leader should make that distinction, units should really just report their own state knowledge not service
[16:48] <hazmat> fwereade, ie the unit scope is the unit. the leader scope is the service
[16:48] <fwereade> hazmat, it's not just about peers, is it?
[16:49] <fwereade> hazmat, "I don't work because I can't talk to the one database I know about" may or may not have a "yet" in there, depending on whether or not more units are going to join
[16:49] <fwereade> hazmat, and that's the distinction between "still coming up, part of a big deployment,some error rate is expected" and "I have no reason to believe anything will ever work"
[16:49] <hazmat> fwereade, re peers.. i think in practice we'll find leaders useful for actions, status, etc .. ie beyond peers.
[16:50] <fwereade> hazmat, yellow vs red
[16:50] <fwereade> hazmat, agreed
[16:50] <fwereade> hazmat, I'm talking about goal states, not leaders -- they'll be useful both to leaders and to other units
[16:51] <hazmat> fwereade, unit level my db isn't there yet.. is still unit level. that status will change as the db comes up... ie. knowing the goal state doesn't change the status
[16:51] <hazmat> ie. imo knowing goal state is for leaders and orchestrators.
[16:51] <fwereade> hazmat, it's the difference between *that unit* being blocked vs waiting
[16:52] <fwereade> hazmat, I have to pop out, can we pick back up in a bit please?
[16:52] <hazmat> fwereade, even then i have to know the health of the remote side to properly evaluate.
[16:52] <hazmat> fwereade, its turning into a topology awareness problem instead of a unit problem
[16:52] <hazmat> fwereade, k
[16:53] <fwereade> hazmat, (fwiw I am super happy that you are engaging on this problem, am *very* keen to talk more about it)
[17:35] <voidspace> I'm going offline for a bit
[17:35] <voidspace> maybe see you later
[19:28] <jw4> OCR, thumper : PTAL http://reviews.vapour.ws/r/616/
[19:29] <jw4> addressed feedback from thumper ^^
[19:50] <thumper> sinzui: what's the status of the CI runs to unblock trunk?
[19:51] <sinzui> master still fails on deploy joyent
[19:51] <sinzui> thumper, I ponder if precise is the issue
[19:52] <thumper> sinzui: I thought that dimiter said he tested it...
[19:52]  * thumper sighs
[19:53] <sinzui> thumper, test failed 3 times on master, but the immediate 1.21-beta4 tests that followed passed
[19:53] <thumper> hmm...
[19:53] <thumper> sinzui: so it still seems like something in the master branch is causing failures?
[19:55] <sinzui> thumper, yes. I was pondering rerunning tip with some extra joyent jobs to compare precise with trusty
[19:56] <thumper> sinzui: is the same test passing on trusty but not precise?
[19:56] <sinzui> thumper, it didn't for  me, but since several people said it worked, I wondered is series as a factor
[20:02] <ericsnow> jw4: taking a look
[20:02] <jw4> ericsnow: ta
[21:17] <wwitzel3> ericsnow: ping
[21:17] <ericsnow> wwitzel3: hey
[21:17] <ericsnow> wwitzel3: brt
[21:27] <thumper> menn0: got a minute?
[21:29] <menn0> thumper: yep[
[21:32] <jw4> ericsnow: great feedback - thank you!
[21:32] <ericsnow> jw4: you bet :)
[22:04] <perrito666> it is amazing how, whenever I try to write a spec all possible noises and movement happen in the house
[22:16] <menn0> thumper: this joyent problem isn't fixed at all
[22:16] <menn0> thumper: it still happens with the 1.21 branch, even with Dimiter's change in
[22:16] <menn0> thumper: and it still happens with master
[22:17] <menn0> thumper: and it happens with 1.21 beta3
[22:17] <menn0> thumper: going to try 1.20 to try and figure out where it started
[22:18] <menn0> thumper: and start a conversation with Joyent
[22:28] <bac> hi alexisb, do you know who is responsible for https://juju-docs.readthedocs.org/en/latest/ ? i think it should be updated or removed.
[22:33] <menn0> thumper: here's the problem but their fix is a bit shite. https://help.joyent.com/entries/21748665-Private-vlans-are-not-routing-to-each-other-by-default-
[23:20] <waigani_> I have a branch which relies on another branch which is yet to land. Is there a special dance I have to do to make github/reviewboard handle the diffs correctly?
[23:21] <perrito666> waigani_: I believe there is a dance you can do to have reviewboard know about this, you will have to ask ericsnow
[23:22] <waigani_> perrito666: thanks. ericsnow?
[23:23] <ericsnow> waigani_: rbt post -u --parent <name-of-parent-branch>
[23:23] <waigani_> ericsnow: sweet. thanks
[23:23] <ericsnow> waigani_: you'll also have to do that every time you push up to your branch
[23:23] <waigani_> ericsnow: right. good to know.
[23:26] <waigani_> ericsnow: when I push the initial pr to github, it is automatically added to RB. Should I follow up with the rbt post to flag the correct parent?
[23:27] <ericsnow> waigani_: correct
[23:28] <ericsnow> waigani_: I've hoped to have time to implement code that takes care of the dependent branch dance but haven't had time
[23:29] <ericsnow> waigani_: until then it's manual (and you end up with twice as many patch revisions in reviewboard)
[23:30] <waigani_> ericsnow: ah really? as long as we have a working solution, that is good enough for now.
[23:30] <ericsnow> waigani_: cool
[23:30] <ericsnow> waigani_: I use --parent with rbt all the time


[17:43] <PrinceRylan42> My second monitor is acting buggy. When I drag a program over to it the cursor is misaligned with the program. And sometimes the program doesn't want to leave my primary monitor. And with a program like VSCode, When I click on some of the functions. It doesn't respond.
[17:43] <PrinceRylan42> I'm using a 6-7 year old Toshiba television hooked up to HDMI. It works fine as my second monitor in Windows 11
[17:43] <PrinceRylan42> I'm running an oracle virtual machine. And I have two monitors I have 2 monitors selected in the display settings of oracle and I have the video memory turned up to max (128mg). I've tried switching the graphics controller from VMSVGA to VBoxVGA and VBoxSVGA but that doesn't help. How do I get my second monitor to function properly? Let me know if
[17:43] <PrinceRylan42> you need more information. Thank you.
[20:02] <hiyu> *
[20:02] <hiyu> ******************
[20:56] <nnn> Hello
[21:28] <c_89> Hi, why Firefox 109.0 64 bit (flatpak) does not allow to add module `/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so`?
[22:46] <guilll> hi, I have a xubuntu 14.04 pc that don't boot anymore, I use a live usb 22.04 to access it.  What should I look at to understand why it don't boot?
[22:51] <gnrp> guilll: At what point does it not boot anymore?
[22:53] <guilll> @gnrp is there a file that I can look at to see what fail when I try to boot it?
[22:54] <gnrp> guilll: There are. But you have to tell at which stage it is failing to boot
[22:54] <gnrp> generally, /var/log/syslog is always helpful
[22:55] <gnrp>  /var/log/kern.log contains the kernel messages
[22:55] <gnrp> but all that helps only if you get as far as to write these files
[22:59] <guilll> gnrp those two file are last modified on January 20, so it would seem that when I try to boot it don't get to the point when it write them
[22:59] <gnrp> guilll: What is the last thing you see when the boot fails?
[23:00] <guilll> I have a separated /var partition
[23:00] <guilll> I don't remember what I saw last, I would have to leave the chat to do a reboot
[23:00] <gnrp> because I think this would be more relevant
[23:01] <gnrp> if you have a phone, just take a screenshot and upload it somehwere
[23:01] <gnrp> !paste


[09:01] <tjaalton> boo, bug 1131614
[09:08] <bryceh> tjaalton, fun
[09:11] <tjaalton> yep
[09:14] <mlankhorst> >:(
[09:15] <tjaalton> can't do anything to it today
[09:15] <tjaalton> s/to/about/
[09:19] <bryceh> need any help?
[09:19] <tjaalton> not sure how urgent it is
[09:19] <tjaalton> and would like to hear from tstellar first
[09:48] <tjaalton> ogra_: upstream now has a test case for the touch bug, will be fixed next week
[09:48]  * ogra_ dances .....
[09:49] <tjaalton> http://cgit.freedesktop.org/~whot/xorg-integration-tests/commit/?h=touch-grab-race-condition-56578&id=51cd9dd2f55f24cbff6b270fcc479a6542bd9ea5
[09:50] <ricotz> tjaalton, hi, as i said using an independent snapshot of llvm-3.3 svn trunk seems better which won't interfere with llvm-3.2
[09:50] <tjaalton> ricotz: doko didn't want that..
[09:51] <tjaalton> besides, -3.2 is fooked anyway
[09:51] <ricotz> i see
[10:06] <gema> hey, we are seeing a regression in bootspeed and xorg seems to be the culprit
[10:06] <gema> from the 9th of Feb to the 13th has gone up from under 6 secs to over 25
[10:07] <gema> bryce: ^^
[11:25] <bryceh> gema, oh?  what's the cause?
[11:26] <gema> bryceh: we seem to have correlated this problem with bug 1124330
[11:27] <gema> or suspect it is due to that
[11:27] <gema> bryceh: but you may want to have a look and make sure
[11:27] <gema> bryceh: e.g. http://reports.qa.ubuntu.com/bootspeed/machine/1/amd64/
[11:28] <bryceh> gema, I would be doubtful it would be X; nothing really significant has changed on the X side.  whoopsie seems more plausible.
[11:29] <gema> bryceh: ok
[11:30] <bryceh> gema, the bar charts are interesting
[11:30] <gema> bryceh: good, let us know if you find ways of making them more useful
[11:49] <bryceh> gema, well, I wonder if the xorg chart is just xorg, or an aggregate of all gui startup.
[11:49] <bryceh> gema, a link to the Xorg.0.log would be helpful as well
[11:51] <gema> bryceh: we use bootchart, there are logs here: http://reports.qa.ubuntu.com/bootspeed/machine/1/amd64/raw/
[11:51] <gema> bryceh: but we can definitely add Xorg.0.log to them
[11:53] <gema> bryce: I will find out what is included in the xorg bundle, but I am pretty sure it is only xorg, since we have the desktop on a separate bundle
[12:18] <tjaalton> gema: I've seen that authenticating the lightdm user takes ~20s
[12:21] <gema> tjaalton: where?
[12:21] <gema> tjaalton: in our jobs logs or in your machine?
[12:22] <tjaalton> gema: on my machines
[12:22] <tjaalton> check lightdm.log
[12:24] <gema> tjaalton: ack