[23:14] <Unit193> All the stuff I see about blacklisting sync'ing xul-ext-* packages seems to be a bit vague, and quite outdated.


[06:38] <bkerensa> =o
[06:56] <el_seano> +_+
[07:29]  * bkerensa pokes el_seano with a hdmi cable
[07:56] <bkerensa> gnight guys
[14:42]  * el_seano yelps in HD.
[18:22] <bkerensa> Mmm
[18:23] <bkerensa> Jamba Juice sent me some Juice via FedEx: http://t.co/ktKlVdv <-- Breakfast


[00:09] <wallyworld> thumper: this one fixes the race curtis was talking about, but it needs anothe +1 :-( http://reviews.vapour.ws/r/5594/
[00:10]  * thumper looks
[00:11] <thumper> wallyworld: why does the testing show a badly indented table?
[00:11] <wallyworld> thumper: markdown char inpaste
[00:12] <menn0> thumper: internet is back up
[00:12] <thumper> menn0: cool
[00:13] <menn0> thumper: I must admit it was very productive having no distractions for a bit :)
[00:13] <thumper> awesome
[00:13] <menn0> axw: do you have time for a hangout to discuss macaroons
[00:15] <lazyPower> i too, see the badly indented table
[00:15] <lazyPower> wallyworld :D glad its not just me
[00:16] <lazyPower> o/ heya core devs
[00:16] <wallyworld> lazyPower: hey
[00:16] <lazyPower> i dont suppose any of you are coming to the summit D:
[00:16] <wallyworld> the charmer summit?
[00:17] <wallyworld> perrito666 is
[00:17] <lazyPower> wooo perrito666
[00:17] <wallyworld> lazyPower: save up all the beatings until then please :-)
[00:17] <lazyPower> haha no beatings! i want you people here so you can see and connect with your users!
[00:18] <wallyworld> indeed, they canbeat us
[00:18] <lazyPower> you know, the reason - other than - endless milestone sheets being handed down from planning sessions.
[00:18] <lazyPower> i'm so hype right now. I bet that wears off quickly :D
[00:19] <wallyworld> lazyPower: i can't wait for juju 2.0 to hit rc next week - hard to go back to 1.25 now
[00:19] <lazyPower> tell me about it. i'm still poking about in -stable for our testing on k8s
[00:20] <lazyPower> we get charm testing fixed just in time for it to change again .surprise!
[00:20] <axw> menn0: sorry was otp, free to hangout now
[00:21] <menn0> axw: give me 30s
[00:21] <wallyworld> lazyPower: as soon as we hit rc, no more breaking changes is the aim
[00:22] <axw> the 1.25 CLI feels very clunky every time I go back to it
[00:23] <axw> particularly bootstrap
[00:23] <thumper> wallyworld: review done, few issues
[00:23] <wallyworld> ok, ta
[00:23] <thumper> lazyPower: wish I was, but alas, can't
[00:24] <lazyPower> wallyworld - i'm not even mad my friend, not even a little bit....
[00:24] <perrito666> lazyPower: as wallyworld said, you can beat me
[00:24] <perrito666> and users can connect some punches too
[00:24] <lazyPower> perrito666 - not sure when your team turned into massochists/sadists, but you wear the role really well :P
[00:24] <lazyPower> thumper - shameeeeeeee my man! I was looking forward to seeing you again
[00:25] <lazyPower> next time
[00:25] <wallyworld> lazyPower: the beatings will continue until morla improves
[00:25] <perrito666> lazyPower: somewhere around the first time we broke the gui without letting urulama know first
[00:25] <thumper> lazyPower: I'm going to the CDO sprint in nov rather than the Juju one
[00:25] <lazyPower> hahaha
[00:25] <thumper> so we get coverage
[00:25] <lazyPower> and hatch tries so hard to tell me they aren't core ;)
[00:25] <thumper> you at that one?
[00:25] <lazyPower> hatch - you're totally owned by core now, be tee dubs
[00:25] <perrito666> lazyPower: dimitern is coming too so you can beat him about network stuff
[00:25] <lazyPower> thumper - no idea. but i doubt it. Marco has done a good job of putting us grunts to work
[00:25] <lazyPower> perrito666 - oh and i have plans on that one ;)
[00:25]  * thumper nods
[00:26]  * thumper heads out, time to pick up kiddo
[00:26] <thumper> bbs
[00:26] <lazyPower> cheers thumper
[00:27] <lazyPower> perrito666 - well i look forward to hanging out during the summit as well :) seek me out and we can make good on those OCP chassis beers promised from forever ago
[00:45] <wallyworld> thumper: issues addressed. i couldn't find any uses of those tw helper functions. am i the first to use them?
[00:45] <thumper> no
[00:45]  * thumper finds example
[00:45] <thumper> blocks/list.go
[00:45] <thumper> uses them
[00:46] <thumper> w := output.Wrapper{tw}
[00:46] <thumper> w.Println(value, value, value)
[00:46] <thumper> or
[00:46] <thumper> w.Print(value, value)
[00:46] <wallyworld> thumper: oh, i found other ones
[00:47] <wallyworld> output.TabWriterPrint(tw)
[00:47] <wallyworld> i didn't see anywhere else using those
[00:47] <thumper> yeah...
[00:48] <thumper> those were written initially to replace the stand alone p functions
[00:48] <wallyworld> they just wrap what you did by habd above :-)
[00:48] <thumper> but in the end I felt it was better to do it other ways
[00:48] <wallyworld> sigh :-)
[00:48] <thumper> should probably just remove them :)
[00:48] <wallyworld> double sigh
[00:49] <wallyworld> i'll update the PR
[00:52] <wallyworld> thumper: that wrapper really also needs a Printf so that if you are just printing one thing, you don't need to resort to fmt.Fprintf(tw, ...) and can consistently use w.Print everywhere
[00:52] <thumper> Print can take just one thing
[00:53] <thumper> what do you mean?
[00:54] <wallyworld> thumper: you need to do fmt.Sprint() inside the w.Print()
[00:54] <thumper> output.CurrentHighlight.Fprintf(tw, "%s\t", name) -> w.PrintColor(output.CurrentHighlight, name)
[00:54] <thumper> wallyworld: for now, yes
[00:54] <wallyworld> right, so if there were a w.Printf(onething) that would help
[00:54] <thumper> you don't need it for %d
[00:55] <thumper> w.Print(cores)
[00:55] <wallyworld> but i have other cases where it's needed
[00:55] <thumper> where?
[00:55] <wallyworld> fmt.Fprintf(tw, "CONTROLLER: %v\n", c.ControllerName())
[00:55] <thumper> other places, sure, but not in this branch
[00:55] <wallyworld> that's in the bits i'm changing in this branch to use the new helper
[00:56] <wallyworld> would be nice not to have to use fmt.Printf
[00:56] <thumper> w.Println("CONTROLLER: " + c.ControllerName())
[00:56] <thumper> sure
[00:56] <wallyworld> sure, but FPrintf is nicer
[00:56] <thumper> no it isn't
[00:56] <thumper> :)
[00:56] <wallyworld> just a suggestion for when you remove those other ones
[00:57] <wallyworld> the above is a simplistic example
[00:57] <thumper> I know
[00:57] <wallyworld> so if you are in the area anyway..... to remove those obsolete helpers.....
[00:57]  * thumper nods
[01:00] <wallyworld> thumper: so is there a recommended way to replace this output.CurrentHighlight.Fprintf(tw, "%s\t", name)
[01:00] <thumper> see comment 6 minutes ago
[01:00] <wallyworld> ah :-)
[01:00] <wallyworld> oh alright then
[01:14] <thumper> I'm at that stage where I know what I need to do
[01:14] <thumper> but it is more than I wanted to do...
[01:14]  * thumper sighs
[01:14] <thumper> oh well
[01:14]  * thumper dives in
[01:15] <thumper> minion, fetch me a coffee
[01:15] <thumper> oh... no minions around, will fetch own coffee
[01:15] <thumper> such are the problems of working from home
[02:12] <redir> guests here. back later.
[02:21] <menn0> axw: what type will used to represent a macaroon cookie jar in CLI code? []macaroon.Slice?
[02:21] <menn0> i'm just trying to make things as easy as I can for myself
[02:22] <menn0> by having types line up
[02:22] <axw> menn0: yeah, that's what api.Info accepts
[02:22] <axw> that gives us most flexibility
[02:22] <menn0> axw: I ask b/c the macaroon give by the API to accounts.yaml was giving the macaroon as a string
[02:22] <menn0> rather than a macaroon.Macaroon
[02:23] <axw> menn0: that was just to avoid having a dependency
[02:23] <axw> using []macaroon.Slice would be simplest I think
[02:24] <menn0> ok great. that makes my life easier
[02:28] <wallyworld> mwhudson: go 1.7 installed from the ppa doesn't seem to support running race tests, i have to resort to using 1.6
[02:28] <wallyworld> runtime.raceinit: __tsan_init: not defined
[02:28] <wallyworld> etc
[02:28] <wallyworld> is there something i'm missing?
[02:28] <mwhudson> wallyworld: install golang-1.7-race-detector-runtime from the ppa too?
[02:28] <wallyworld> ah let me check
[02:28] <mwhudson> should be recommended though
[02:29] <mwhudson> do you have recommends turned off?
[02:29] <wallyworld> i just installed golang-1.7 or whatever using apt-get
[02:29] <wallyworld> not sure, i haven't changed it explicitly i don't think
[02:30] <wallyworld> mwhudson: so gophers-archive/now doesn't have it listed but gophers-archive/xenial does
[02:31] <mwhudson> wallyworld: i don't know what either of those things mean :-)
[02:31] <mwhudson> wallyworld: this is the PPA you should be using https://launchpad.net/~gophers/+archive/ubuntu/archive/+packages
[02:31] <wallyworld> me either, i just fired up synaptic and that's what it shows as package sources
[02:32] <mwhudson> oh heh
[02:32] <wallyworld> but yeah, i didn't have the race package installed
[02:32] <wallyworld> works now, ty
[02:33] <wallyworld> and is much faster
[02:53] <wallyworld> thumper: can you see if you're ok with http://reviews.vapour.ws/r/5589/ now?
[02:53]  * thumper looks
[02:54] <wallyworld> anastasiamac_: not sure how busy you are, but would love a review on http://reviews.vapour.ws/r/5611/ if you get a moment today
[02:56]  * thumper sighs
[02:56] <thumper> some of the points were completely misunderstood
[02:56] <thumper> wallyworld: let me finish what I'm doing and I'll go through it properly
[02:56] <wallyworld> righto
[03:02] <thumper> See Also:
[03:02] <thumper> or
[03:02] <thumper> See also:
[03:03] <thumper> menn0: ^^
[03:03] <thumper> There are 9 "See Also:"
[03:03] <thumper> and 59 "See also:"
[03:03] <natefinch> Latter... it's not a title, IMO.
[03:03] <thumper> was there a definitive answer somewhere?
[03:03] <thumper> wallyworld: ?^^
[03:04] <wallyworld> thumper: i think menn0 said "See Also"
[03:04] <thumper> he has to me before, but I'm collecting input
[03:04] <thumper> I'll skip for now
[03:04] <wallyworld> i sort of prefer "See also" but that's just IMO
[03:04] <thumper> I was going to drive by fix them
[03:04] <menn0> thumper: If "See also" is the majority let's just use that
[03:04] <thumper> ok
[03:04]  * thumper fixes
[03:05] <natefinch> +1 for making the smaller fix that makes it consistent
[03:07] <natefinch> wallyworld: this auto upload-tools thing is garbage, btw
[03:08] <wallyworld> what do you really think?
[03:08] <natefinch> wallyworld: sorry... it's just been frustrating for me almost every other day
[03:08] <wallyworld> works great for all the use cases i know of
[03:08] <wallyworld> especially snaps
[03:08] <wallyworld> and devel
[03:09] <natefinch> it seems like, if the version on my branch is ever older than what's in streams, I get what's in streams
[03:09] <wallyworld> yes
[03:10] <wallyworld> that's intended
[03:10] <natefinch> what if I need to work on old code?
[03:10] <wallyworld> use --build-agent
[03:10] <wallyworld> it's been done so solve the 99% cases
[03:11] <wallyworld> so if you work on old code, you just use --build-agent instead of --upload-tools
[03:11] <wallyworld> does that not work for you?
[03:11] <natefinch> I didn't realize build-agent was the new upload tools.
[03:12] <natefinch> I thought there were some different semantics to it
[03:12] <wallyworld> there is - it will always compile
[03:12] <natefinch> oh, I don't (really) care about that
[03:12] <wallyworld> whereas upload-tools used to not compile if it found a binary
[03:12] <wallyworld> i'm sure i documented this either in email or the release notes
[03:13] <natefinch> I guess I don't understand why we have auto upload-tools if we have build-agent
[03:13] <wallyworld> for snaps
[03:14] <wallyworld> and 99% of development cases
[03:14] <natefinch> the problem during development is that depending on invisible data in the cloud (i.e. what is in streams), juju bootstrap will behave differently
[03:14] <natefinch> so, every time curtis pushes a new build, the code I built that used to auto-upload now doesn't, until I pull.
[03:15] <wallyworld> so use --build-agent as you used to use --upload-tools
[03:15] <natefinch> (assuming master has been updated with a new version number which is also not always instant)
[03:15] <natefinch> well, yes... but then why have auto-upload?
[03:15] <wallyworld> for the other 99%, it's so liberating not to have to type --upload-tools all the time
[03:15] <wallyworld> for snaps
[03:15] <natefinch> ... I don't understand what "for snaps" means
[03:15] <wallyworld> what don't you get? :-)
[03:16] <wallyworld> snaps need to not require upload-tools
[03:16] <natefinch> I know (vaguely) what a snap is.  I don't understand what that has to do with whether or not juju auto uploads
[03:16] <natefinch> again, what does a snap have to do with juju?  (other than installing juju)
[03:16] <wallyworld> a snap is a contained juju/jujud
[03:17] <wallyworld> juju run from the snap will use the jujud in the snap
[03:17] <wallyworld> for that to work, it needs aut discovery of the binary
[03:17] <wallyworld> this is all needed to allow people to publish daily snaps etc to edge
[03:18] <wallyworld> plus for development, people get so sickof having to type upload-tools all the time
[03:18] <natefinch> heh
[03:18] <wallyworld> and we also want people to be able to install debs and foro stuff to just work
[03:18] <wallyworld> this is all about 1. snaps, and 2. removing friction for bootstrap
[03:19] <wallyworld> and it holds 99% of the time
[03:19] <natefinch> so, wait... I still don't get what snaps have to do with this.  Why would the snap not just use what's in streams?  couldn't we just publish a nightly stream or something?
[03:19] <wallyworld> but when running older code, you just use --build-agent
[03:19] <wallyworld> snaps are self contained
[03:19] <natefinch> sure... on the client
[03:20] <wallyworld> and also when publishing to the edge channel
[03:20] <wallyworld> we want to remove friction for people to say "try my stuff"
[03:20] <wallyworld> creaing a snap is easy
[03:21] <wallyworld> publishing jujud to some stream you don't control is cracl
[03:21] <natefinch> sure
[03:21] <natefinch> ok, so this is for when a dev wants to give a test binary for someone to try out a fix or new feature.  Ok
[03:22] <wallyworld> yep, also daily snaps so people can get the latest stuff
[03:22] <wallyworld> for example, menno did one recently
[03:22] <wallyworld> to test out a status feature
[03:23] <menn0> axw: this macaroons change is tedious. i'm almost done but need to do a preschool pickup soon.
[03:23] <menn0> will continue afterwards
[03:23] <axw> menn0: no worries, thank you
[03:25] <natefinch> I still wish it always worked the same way unless you gave it a flag.... For example, we could build the PPA with a flag that makes the default not-upload-tools and for everything else, have it default to upload-tools. Then at least it would be consistent.  My main problem is that I don't *trust* it, because it has failed for me a few times, and it's really hard to pick out the right line of logging as it scrolls past.
[03:26] <wallyworld> we are moving away from ppas
[03:26] <wallyworld> failed is subjective - it's behaved exactly as designed
[03:27] <wallyworld> you just didn;t know about --build-agent
[03:28] <thumper> menn0: http://reviews.vapour.ws/r/5612/
[03:28] <wallyworld> also bootstrap messages have been improved to show what version is being used
[03:28] <natefinch> the design is bad, because it behaves differently than my intent.... some of the time.  And it behaves differently according to factors that are basically impossible for me to know ahead of time... and even while bootstrapping, it's difficult to see if it's uploading or not
[03:28] <wallyworld> natefinch: there are flags to force intent, like agent-version
[03:28] <wallyworld> if you want to be explicit, you can
[03:29] <wallyworld> otherwise, it will find a streams version which matches the client
[03:29] <wallyworld> that's very easy to understand the behaviour
[03:30] <wallyworld> and if you are developing and want to compile a binary which basically is not really what it says it is, then use --build-agent
[03:30] <natefinch> a brake pedal that doesn't work when the moon is in conjuction with pisces is very easy to understand too... that doesn't make it a good design.  One gets used to it working, and then one day, without any visible changes, it acts differemtly
[03:30] <wallyworld> the changes are documented, the change is semantic is deliberate. sometimes shit changes
[03:31] <wallyworld> the change solves the 99% cases very well, and for the other 1%, use --build-agent
[03:31] <natefinch> I'm not saying that the code changes are the problem.... I'm saying that with the current code "juju bootstrap" has different results based on effectively the stage of the moon
[03:31] <thumper> wallyworld: just for you http://reviews.vapour.ws/r/5613/
[03:31] <wallyworld> looking
[03:32] <thumper> wallyworld: actually http://reviews.vapour.ws/r/5612/ was for you too
[03:32] <wallyworld> thumper: did you reopne those 3 issues on that pr? i don't agree that pr should solve the check empty args case
[03:32] <thumper> not sure why menno got it
[03:32] <thumper> wallyworld: if we are changing how the command works, then giving the user good feedback when they do something wrong is part of the work
[03:32] <thumper> consider quality :P
[03:32] <natefinch> wallyworld: I'll just use build-agent all the time from now on.  That will fix my problems.
[03:33] <wallyworld> natefinch: it behaves deterministically. it will search for a packaged version which matches the client version
[03:33] <wallyworld> there's no moon involved
[03:33] <thumper> wallyworld: yes, I reopened those 3 issues
[03:33] <wallyworld> if the client reports it is a version other than what it is, then yes build-agent is needed
[03:33] <natefinch> there is a moon. it's the contents of streams.  When I'm typing at my terminal, there's no way for me to know what's in streams.
[03:34] <wallyworld> how so?
[03:34] <wallyworld> there's the validate-tools plugin
[03:34] <wallyworld> that will tell you
[03:34] <menn0> axw: change of plan... not doing pickup
[03:37] <wallyworld> thumper: awesome, that's for printf
[03:37] <wallyworld> *thanks
[03:43] <menn0> thumper: in your PR's QA steps, I presume you deleted the model before running destroy-controller ?
[03:43] <menn0> otherwise you would have needed --destroy-all-models right?
[03:47] <menn0> thumper: review done
[03:49] <thumper> menn0: I did think that was weird
[03:49] <thumper> no, I didn't
[03:49] <menn0> hmmm
[03:49] <thumper> I think that may be a different bug
[03:50] <menn0> maybe the -y is (incorrectly) allowing the check to be bypassed?
[03:51] <thumper> no
[03:51] <thumper> don't think so
[03:53] <wallyworld> thumper: reviewed, i have opinions on some of the text, see what you think
[03:53] <thumper> ok
[04:02]  * thumper away from internet for a bit
[04:02] <thumper> kiddo dropoff and wait
[04:16] <menn0> axw: here's the support for multiple macaroons with migrations: http://reviews.vapour.ws/r/5614/
[04:17] <menn0> adding QA steps
[04:17] <axw> menn0: TYVM, reviewing now
[04:25] <axw> menn0: LGTM. is there some doc somewhere which describes the commands to use for migrating? I will need to QA also when I make the changes to read from ~.go-cookies
[04:26] <menn0> axw: it's just one command: juju migrate
[04:26] <menn0> axw: but I'll email you some details
[04:26] <axw> menn0: cheers
[04:37] <wallyworld> axw: if you get a moment after the macaroon stuff, here's a small win http://reviews.vapour.ws/dashboard/
[04:38] <axw> wallyworld: I'll take a look now
[04:38] <wallyworld> and if you are feeling like poking your eye out and have time later also http://reviews.vapour.ws/r/5611/
[04:38] <axw> assume you mean the local: prefix one
[04:38] <wallyworld> ty
[04:38] <wallyworld> yeah, or both, or whatever you have time for
[04:38] <wallyworld> macaroons comes first
[04:38] <wallyworld> the local: one is small
[04:50] <wallyworld> axw: i am 100% (well 99.99%) sure our builders are all 1.6. i can confirm and land separately. also that localhosthomestack thing is deliberate to ensure the openstack cloud abuts the lxd one and is last in the file (the \n are stripped off)
[04:51] <axw> wallyworld: lemme just re-read that last bit then, I must have glanced over something
[04:52] <axw> wallyworld: ok I understand. can you please add a comment explaining that?
[04:53] <wallyworld> sure
[04:53] <wallyworld> thanks for review
[04:53] <axw> np
[05:09] <menn0> axw: i've just sent the multiple macaroons PR for merging
[05:09] <axw> menn0: awesome, thanks!
[06:27] <redir> wallyworld: yt?
[06:27] <wallyworld> depends who's asking :-)
[06:28] <redir> Ed McMahon
[06:28] <redir> wallyworld: ^
[06:28] <wallyworld> oh, well in that case
[06:29] <redir> wallyworld: thumper raised an issue re: model-config returning a string of the value when --format=json is present
[06:29] <redir> which makes sense to me
[06:30] <wallyworld> yeah, i think it's a valid point
[06:30] <redir> but should it return '{value}'
[06:31] <wallyworld> shouldn't it be {name=value}
[06:31] <redir> or '{key: {value: value, source: model}}'
[06:31] <wallyworld> yeah, something like that
[06:31] <redir> as if it is one element of the lot
[06:31] <wallyworld> what do we do for the yaml
[06:31] <wallyworld> i think with yaml it prints out gobs of extra metadata
[06:31] <redir> but tabular should still just output the value
[06:31] <redir> wallyworld: so does json
[06:32] <wallyworld> yeah, users want to have the option to get *just* the value printed
[06:32] <redir> wallyworld: works for me
[06:32] <wallyworld> for without a format arg that's what they should get
[06:32] <wallyworld> but json and yaml should be formatted
[06:32] <wallyworld> i'd argue yaml and json should have equivalent info
[06:33] <wallyworld> all the extra metadata
[06:33] <wallyworld> so just match what the yaml does now
[06:33] <redir> wallyworld: but I think that affects the juju model-config --format=yaml | juju model-config --yaml -
[06:33] <redir> idea
[06:33] <wallyworld> redir: oh, wait, i was thinking of *application* config sorry
[06:33] <redir> heh
[06:34] <wallyworld> that is the one with gobs of extra metadata
[06:34] <wallyworld> so we can still support the pipe, the get just needs to ignore the source attribute. bur for now, let's just not include it in the json or yaml
[06:34] <redir> wallyworld: model-config prints the key: \n value: value\nsource: thesource\n for yaml now in model-config
[06:34] <wallyworld> so tabular = value, from etc
[06:35] <wallyworld> ok
[06:35] <redir> OK
[06:35] <wallyworld> so the get should just ignore that field right?
[06:35] <redir> so tabular single gets just he string value
[06:35] <redir> everything else structured
[06:35] <wallyworld> yeah, tabular doesn;t change
[06:35] <redir> wallyworld: makes sense to me
[06:36] <wallyworld> and my comment before about *just* the value - that's for application config
[06:36] <redir> just wanted to verify before doing and footshooting
[06:36] <wallyworld> so i think the only change here is to the json output?
[06:36] <wallyworld> to fix that bit
[06:36] <wallyworld> yaml is ok as is right?
[06:36] <wallyworld> and tabular
[06:36] <wallyworld> is ok
[06:37] <redir> wallyworld: yes I think so.
[06:37] <wallyworld> sgtm
[06:37] <redir> I didn't realize we didn't do that already:/
[06:37] <wallyworld> the json issue?
[06:37] <redir> wallyworld: yes
[06:37] <wallyworld> yeah, i had no idea either
[06:37] <wallyworld> wtf
[06:37] <redir> added tests to
[06:38]  * redir shrugs
[06:38] <redir> should have an update and a PR for the model-defaults stuff soon
[06:38] <wallyworld> with the other comment(s), use "configuration values" i think?
[06:38] <redir> then tomorrow hopefully they'll land and I can get the --region bits in for defaults
[06:38] <wallyworld> ok, awesome
[07:46] <redir> http://reviews.vapour.ws/r/5589/ is ready for another look.
[08:11] <redir> and also http://reviews.vapour.ws/r/5616/ is ready. This second one is stacked on the first, so it may be easier to review after it lands. It is nearly identical but to flatten model-defaults rather than model-config.
[08:11] <redir> g'nite
[08:23] <jam> frobware: dimitern: ping
[08:24] <jam> we're talking about the IPAM spec, and we wanted to get some info about the rationale for a couple of the decisions.
[08:26] <frobware> jam: how/where do you want to do this?
[08:26] <jam> frobware: https://hangouts.google.com/hangouts/_/canonical.com/tech-board
[09:11] <fwereade> sorry, hangouts flailing
[09:23] <dimitern> anastasiamac_: I've updated http://reviews.vapour.ws/r/5598/ with your suggestions and added a minute change to populate parent name for bridge ports, I'd appreciate a second look, if you can
[09:23] <dimitern> frobware: ^^
[09:28] <anastasiamac_> dimitern: tyvm! I'll need to go afk - apparently kids need to go to bed :D - i'll look when i return later on \o/
[09:28] <dimitern> anastasiamac_: sure, thanks!
[09:32] <anastasiamac_> dimitern: actually, looks kind of awesome \o/ reviewed.. m going afk now
[09:32] <dimitern> anastasiamac_: \o/ :)
[09:50] <voidspace> dimitern: ping
[10:00] <voidspace> frobware: ping
[10:00] <frobware> voidspace: pong, otp
[10:02] <voidspace> frobware: have you deployed openstack (specifically I need nova compute) to KVM?
[10:02] <frobware> voidspace: not. well, not since I last deployed openstack on arm. but that was with devstack.sh
[10:03] <voidspace> frobware: does devstack.sh setup the KVM config for you?
[10:03] <frobware> voidspace: nope
[10:03] <frobware> voidspace: but then again, what do you mean by kvm config?
[10:04] <voidspace> frobware: setup the required KVM instances with the correct network config for openstack to work - similar to your scripts
[10:04] <voidspace> frobware: I imagine that in order to deploy openstack there are fairly specific requirements on what machines are available
[10:05] <voidspace> frobware: dimitern has probably done this more
[10:05] <frobware> voidspace: never tried it with/via juju
[10:05] <voidspace> frobware: I have a bug that can be repro'd with a shutdown command to nova compute issued via a run-action
[10:08] <dimitern> voidspace: sorry, was in a call until now, but I need to leave - bbiab
[10:32] <macgreagoir> voidspace: I've done a bit of openstack on kvm, if i can help.
[10:32] <voidspace> macgreagoir: great
[10:32] <voidspace> macgreagoir: so how do I do it ;-)
[10:33] <macgreagoir> :-)
[10:33] <voidspace> macgreagoir: can you tell me what KVM setup I need and then how to do the deploy
[10:33] <macgreagoir> The challenge may be having enough VMs to host the services. Is it HA?
[10:34] <voidspace> macgreagoir: I'd like the simplest possible setup that gets me nova compute
[10:34] <voidspace> macgreagoir: I can create the VMs if I know what configuration I need
[10:34] <macgreagoir> I have some scripts to create a set of KVMs with two nics each, which would be OpenStack priv and pub nets.
[10:34] <frobware> voidspace: are you looking at https://bugs.launchpad.net/juju/+bug/1555808
[10:34] <mup> Bug #1555808: Cannot deploy a dense openstack bundle with native deploy <2.0> <2.0-count> <bundles> <cdo-qa> <ci> <deployer> <eda> <juju-release-support> <jujuqa> <maas-provider> <juju:Triaged by rharding> <https://launchpad.net/bugs/1555808>
[10:35] <voidspace> frobware: no
[10:35] <voidspace> frobware: https://bugs.launchpad.net/juju/+bug/1534103
[10:35] <mup> Bug #1534103: "unknown operation kind run-action" (1.26alpha3) <2.0-count> <actions> <sts> <juju:In Progress by mfoord> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1534103>
[10:35] <voidspace> macgreagoir: there's a guide here that suggests that four machines with containers should be enough
[10:35] <voidspace> macgreagoir: https://www.hastexo.com/resources/hints-and-kinks/ubuntu-openstack-juju-4-nodes/
[10:36] <voidspace> macgreagoir: but that assumes physical machines and doesn't detail the network config they need so I can't easily repro it with KVM
[10:37] <macgreagoir> voidspace: Two should be enough. What storage is the bundle using, do you know?
[10:37] <macgreagoir> As in ceph?
[10:38] <voidspace> macgreagoir: I don't know what bundle *they're* using, I'd like to use whatever is the simplest approach
[10:38] <macgreagoir> If you just want to test nova-compute, a simple storage should be fine, making the VMs easier.
[10:38] <voidspace> macgreagoir: that sounds good
[10:39] <macgreagoir> voidspace: This is a cleane-up copy of my scripting: https://github.com/macgreagoir/maas-juju-sandbox
[10:39] <macgreagoir> It assumes on maas server and three nodes, but a forth should be OK.
[10:40] <voidspace> macgreagoir: ok, great - that looks like it deploys MAAS to KVM (which I have but I don't mind starting from scratch)
[10:40] <voidspace> macgreagoir: are you suggesting I repurpose that for openstack?
[10:41] <macgreagoir> It sets up the two new virsh nets too.
[10:41] <macgreagoir> I would think the nodes will be OK for an openstack test.
[10:41] <voidspace> macgreagoir: ah, cool
[10:42] <voidspace> macgreagoir: and how to do the openstack deploy to it, using simple storage as you suggest
[10:42] <voidspace> macgreagoir: will I need to choose a bundle and configure it? (I've not done that before so any help you can give will be appreciated)
[10:42] <macgreagoir> In a Canonical reference deployments the openstack controller services would be in lxd containers. I haven't seen if that example does the same...
[10:42] <voidspace> macgreagoir: ah, you mean follow the example for that part
[10:43] <voidspace> macgreagoir: ok
[10:43] <macgreagoir> voidspace: Let me see if there in a non-HA bundle. HA is what will kill your resources.
[10:43] <macgreagoir> I have an old OpenStack example deployment somewhere too, but it's not Juju.
[10:46] <voidspace> macgreagoir: I'll try the example and hassle you when I have problems
[10:46] <voidspace> macgreagoir: thanks :-)
[10:47] <macgreagoir> voidspace: nw, I'm just finishing a thing here, but I'll try to send you something more concrete in a few.
[10:53] <voidspace> who knows anything about run-action?
[10:53] <voidspace> fwereade: ping
[10:54] <fwereade> voidspace, pong
[10:55] <voidspace> fwereade: hey, you've left comments in the run action code - so you've probably at least looked at it...
[10:55] <voidspace> fwereade: ok to ask a question (I'm back on the run action bug "unknown operation kind run-action" bug)
[10:55] <fwereade> voidspace, in uniter? right, I probably still remember some of it ;p
[10:55] <fwereade> voidspace, ofc
[10:55] <voidspace> fwereade: yeah, uniter resolver
[10:56] <voidspace> fwereade: so the specific error (unkown operation kind) is coming out of the resolver switch statement looking at "locaState.Kind"
[10:57] <voidspace> fwereade: if localState.Kind is RunAction then before it gets there it will have gone into the Actions resolver
[10:57] <fwereade> voidspace, hmm -- so the actions resolver isn't handling it?
[10:58] <voidspace> fwereade: ah, and if we have an operation.RunAction with a hook of nil then we will return resolver.ErrNoOperation
[10:58] <voidspace> fwereade: so if the hook is nil but Kind is RunAction then we will drop into that switch statement which will barf
[10:58] <voidspace> fwereade: so what does a Kind of RunAction with a Hook of nil mean? is it an error that we should flag in some other way
[10:59] <voidspace> *however*, if that's happening I ought to see "run-action hook is nil" in the logs - which I don't
[10:59] <fwereade> voidspace, surprised Hook is relevant -- isn't action-id the bit that we should be looking at?
[10:59] <voidspace> if I can repro I can check
[11:00] <voidspace> fwereade: worker/uniter/actions/resolver.go
[11:00] <voidspace> fwereade: line 57
[11:01] <fwereade> voidspace, ha
[11:01] <voidspace> fwereade: should there be a return there?
[11:03] <fwereade> voidspace, I think we need to return some sort of operation that marks the current action failed in the db and updates the local state to make sense again
[11:04] <voidspace> fwereade: ok, any pointers on that?
[11:04] <voidspace> fwereade: like what "makes sense again" means :-)
[11:05] <voidspace> the operation factory doesn't have a failure operation it seems
[11:06] <fwereade> voidspace, if you look at operation/runaction.go
[11:06] <voidspace> there is a FailAction on the Callbacks interface
[11:07] <fwereade> voidspace, the Commit step seems to have the right way to change local state once an action has completed...
[11:07] <fwereade> voidspace, and, indeed, you (probably) want an operation that just calls FailAction and then restores local state in the same way we do on successful commit
[11:07]  * dimitern is back
[11:07] <fwereade> voidspace, we've done the action, success or failure is immaterial to what we do next
[11:08] <dimitern> voidspace: you shouldn't need any kvm config - nova takes care of creating these based on the configured flavors
[11:09] <dimitern> voidspace: I've installed openstack-base bundle with a few mods to the 4 NUCs I have here, and managed to start a guest via nova, after configuring OS as described in the bundle
[11:09] <dimitern> my 5/6 blog posts are all about that
[11:10] <voidspace> dimitern: cool, thanks
[11:10] <fwereade> voidspace, making sense?
[11:10] <dimitern> frobware: ping
[11:10] <frobware> dimitern: pong
[11:11] <voidspace> fwereade: so an operation that marks the action as failed and modifies localState
[11:11] <dimitern> frobware: any thoughts on my last PR? I'm eager to land it, so we can then land yours (re bridge everything one)
[11:11] <fwereade> voidspace, yeah, I think that's the right thing
[11:11] <dimitern> frobware: http://reviews.vapour.ws/r/5598/
[11:11] <frobware> dimitern: ah, let me take a look. a thoudand different things.
[11:12] <dimitern> frobware: I've come up with a really simple merge step for the follow-up
[11:12] <dimitern> frobware: no more sorting, guessing, etc.
[11:12] <voidspace> fwereade: ok on the high level, I might come and pester you for details
[11:12] <dimitern> and once that's done, we're .. well perhaps 2 PRs away from fixing bug 1566791
[11:12] <mup> Bug #1566791: VLANs on an unconfigured parent device error with "cannot set link-layer device addresses of machine "0": invalid address <2.0> <4010> <cpec> <network> <juju:In Progress by dimitern> <https://launchpad.net/bugs/1566791>
[11:12] <fwereade> voidspace, any time :)
[11:12] <voidspace> fwereade: I'm going to try and repro first to confirm this is the problem
[11:12] <fwereade> sgtm
[11:12] <voidspace> fwereade: or at least the code path, although I think it must be
[11:13] <voidspace> fwereade: thanks
[11:13] <fwereade> pleasure :)
[11:21] <rick_h_> morning party people
[11:21] <frankban> redir: hi, could you pleae take a look at https://github.com/juju/juju/pull/6181 ? thanks
[11:23] <rick_h_> frankban: redir is a ways from being up. fwereade are you ablento peek at ^ please?
[11:23] <fwereade> rick_h_, ack
[11:23] <frankban> fwereade: ty
[11:23] <frankban> rick_h_: morning
[11:32] <dimitern> welcome back rick_h_ ;)
[11:33] <rick_h_> dimitern: ty :)
[12:18] <frobware> dimitern: I reviewed http://reviews.vapour.ws/r/5598/
[12:19] <dimitern> frobware: thanks! wow you've been thorough! :)
[12:21] <frobware> dimitern: we need to get this right - it's complicated and partitioning the steps we require would be really helpful. (I know that some of this may come in a follow-up PR.)
[12:23] <dimitern> frobware: yeah, the follow-up will clean a lot of the mess in networkingcommon
[13:23] <rock_> Hi. I have a question. We have developed a JUJU Charm for configuring cinder to use one of our Storage array as the backend.   So How to redeploy the Charm to add more storage arrays to configure cinder without destroying/removing the current deployed charm. [For example, We don't want to remove the current configured storage arrays from the Cinder configuration.]
[13:24] <rock_> Please anyone provide me some solution for this.
[13:35] <voidspace> dimitern: ah, you deployed to NUCs - I want to deploy *to* KVM
[13:35] <voidspace> dimitern: so yes I need some KVM config...
[13:37] <mgz> rock_: you probably want to ask in the #juju channel, but generally you just use `juju set-config` and `juju upgrade-charm` to change an deployed charm's behaviour
[13:37] <dimitern> voidspace: I've managed to do the same on 4 KVMs and use force nova to use nested kvms - dead slow though
[13:38] <voidspace> dimitern: I only want it running so I can shut it down again, don't need it to create any nodes for me
[13:38] <voidspace> dimitern: I don't have a hardware setup that can do this
[13:38] <voidspace> dimitern: shutting it down via an action should be enough to repro the bug
[13:45] <rock_> mgz: OK. Thank you.
[13:47] <frobware> voidspace: I'm confused by your KVM "config" - do you not just need machines available in your MAAS setup or is this about making those KVM nodes accessible/available to openstack?
[13:49] <alexisb> babbageclunk, I am on the HO when you are ready
[13:50] <babbageclunk> alexisb: Oh, sorry! I thought your email also applied to me - omw
[13:50] <alexisb> :)
[13:50] <voidspace> frobware: well, doesn't openstack have some requirements about what networks are available?
[13:50] <voidspace> frobware: or if I just create six nodes with one network will that work
[13:51] <voidspace> frobware: I suspect I need at least two networks for each node, however I don't know which is why I'm asking
[13:51] <frobware> voidspace: perhaps this is why my OpenStack deploy failed a little earlier today
[13:52] <voidspace> frobware: macgreagoir seems to think that two networks should be enough - so I can use your scripts to create the nodes
[13:52] <frobware> dimitern: do you have a working (dense) openstack bundle?
[13:52] <voidspace> frobware: and there's a guide here (from 2015) suggesting four nodes
[13:53] <voidspace> frobware: https://www.hastexo.com/resources/hints-and-kinks/ubuntu-openstack-juju-4-nodes/
[13:56] <macgreagoir> voidspace: Sorry I haven't got back to you yet. Also note which libvirt type nova-compute is configured to use. You'll want to not use kvm (on kvm). nova-lxd maybe?
[14:01] <dimitern> frobware: how dense do you need? :)
[14:01] <frobware> dimitern: I have one 24GB node.
[14:01] <frobware> VM
[14:08] <wallyworld> frankban: hey, looks like the latest rev still uses a separate APICallCloser? did you forget to push an update?
[14:09] <frankban> wallyworld: no, it seems to me that reviewboard went crazy, see https://github.com/juju/juju/pull/6181/files
[14:09] <frankban> wallyworld: I also applied some changes to the test file suugested by fwereade
[14:09] <wallyworld> frankban: awesome, ty. sorry for noise. not sure wgat crack rb is on
[14:13] <dimitern> frobware: 24G disk or ram?
[14:13] <frobware> dimitern: RAM. disk is a solved problem. :)
[14:14] <dimitern> frobware: :) well - i haven't tried all-in-one deployment
[14:14] <dimitern> apart from I guess deploying maas on that node adding kvms and then deploying to them :D
[14:24] <natefinch> rick_h_: btw, I'm not convinced that marking https://bugs.launchpad.net/juju-core/1.25/+bug/1610880 as invalid is correct. the explanation about CPC doesn't make sense with the symptoms stated.  We're failing to validate the certificate that Juju created.... this is a couple steps away from anything to do with CPC
[14:24] <mup> Bug #1610880: Downloading container templates fails in manual environment <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1610880>
[14:26] <rick_h_> natefinch: ok, looks like might be a few things goin on there.
[14:26] <rick_h_> natefinch: let's let dave/dan run with it for now and if it comes back up we'll know where to start
[14:27] <natefinch> rick_h_: ok.  FWIW, I had a hellish time trying to figure out what was going on.  Lots of moving parts and unclear what the correct behavior was of several parts of the code... almost entirely due to the fact that manual is a special flower.
[14:28] <natefinch> rick_h_: for a week it was 100% reproducible, and then all of a sudden, 100% not reproducible.  I stopped working on it because I wasn't getting anywhere, and didn't want to sink any more time into it without talking to you.
[14:30] <babbageclunk> wallyworld: it turns out thumper was referring to owner data (although it would have been handy if he'd replied to my question to clarify!). :(
[14:31] <rick_h_> natefinch: understand, we've got other stuff to run onto so we'll just keep an eye out for a repro
[14:57] <mup> Bug #1474607 opened: worker/uniter/relation: HookQueueSuite.TestAliveHookQueue failure <ci> <go1.5> <go1.6> <regression> <windows> <juju:Fix Released by axwalk> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1474607>
[16:36] <redir> morning
[17:18] <redir> alexisb: yt?
[17:18] <alexisb> redir, yep
[17:18] <alexisb> wuz up?
[17:47]  * rick_h_ goes for late lunchables
[20:36] <babbageclunk> Anyone seen thumper?
[20:36] <alexisb> babbageclunk, he has not arrived yet today
[20:36] <alexisb> should be on shortly though
[20:36] <babbageclunk> ok, thanks alexisb
[20:38]  * perrito666 does some surgery in jujupy
[20:38] <alexisb> babbageclunk, as promised :)
[20:38] <alexisb> there is thumper
[20:39] <alexisb> thumper who forgot to send mail to babbageclunk ;)
[20:39] <alexisb> morning thumper
[20:39] <thumper> oops
[20:39] <thumper> my bad
[20:39] <alexisb> yep
[20:51] <natefinch> gahh.. I cannot for the life of me reproduce https://bugs.launchpad.net/bugs/1614635 even in the same environment where ahasenack says it happens 50% of the time.
[20:51] <mup> Bug #1614635: Deploy sometimes fails behind a proxy <deploy> <landscape> <proxy> <juju:In Progress by natefinch> <https://launchpad.net/bugs/1614635>
[20:55] <natefinch> wallyworld: how do I make bootstrap just use what's in streams?  I removed jujud locally and now I just get  ERROR cmd supercommand.go:458 failed to bootstrap model: cannot package bootstrap agent binary: no prepackaged agent available and no jujud binary can be found
[21:21]  * thumper claps
[21:26] <wallyworld> natefinch: that means there is no matching binary in strams for your client
[21:26] <wallyworld> you will need to force it with agent-version
[21:26] <wallyworld> but you then wear any compatibility issues
[21:27] <wallyworld> between mismatched agent and client
[21:27] <wallyworld> or you use --build-agent to build a local compatibile binary
[21:28]  * thumper needs an alias of 'got est' to be 'go test'
[21:47] <thumper> wallyworld: are you doing this one? https://bugs.launchpad.net/juju-core/+bug/1458576
[21:47] <thumper> wallyworld: as I'm going to be doing some more status stuff soon
[21:48] <wallyworld> thumper: my plate is full this week, i wasn't going to
[21:48] <wallyworld> can look next week
[21:48] <thumper> I'll take it
[21:48] <thumper> I'll be in there
[21:48] <thumper> messing around
[21:48] <wallyworld> ok
[21:54] <voidspace> thumper: ping
[21:54] <thumper> voidspace: hey, in release call
[21:54] <thumper> need a review?
[21:54] <voidspace> thumper: yeah, just checking you were aware
[21:54] <thumper> yep, aware, just busy
[21:54] <voidspace> thumper: np
[21:57] <redir> wallyworld: got a minute to chat about the cloud/region stuff?
[21:57] <wallyworld> redir: in meetings sadly, i will ping when free
[21:57] <redir> np
[22:09] <redir> anyone know where I can find the cloud type the current modelcmd is operating on?
[22:12] <wallyworld> redir: i have a couple of minutes between meetings if you want to chat
[22:12] <redir> sure thing
[22:12] <wallyworld> 1:1
[22:12] <redir> brt wallyworld
[22:23] <alexisb> wallyworld, I have a few minutes if you are avaailable
[22:23] <alexisb> if not I will catch you tomorrow
[22:23] <wallyworld> alexisb: ok, brt
[22:35] <thumper> review up: http://reviews.vapour.ws/r/5622/
[23:26] <axw> wallyworld: you'll appreciate this: https://twitter.com/MarkKriegsman/status/739664279083814912
[23:26] <wallyworld> axw: indeed :-)
[23:27] <perrito666> oh, we need to spray stencil juju changelog on a cow
[23:42] <anastasiamac_> thumper: just to confirm: u r taking over this one, so i can re-assign to u? https://bugs.launchpad.net/juju/+bug/1455627
[23:42] <mup> Bug #1455627: TestAgentConnectionDelaysShutdownWithPing fails <ci> <intermittent-failure> <lxc> <test-failure> <unit-tests> <windows> <juju:Triaged by dimitern> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1455627>
[23:42] <redir> wallyworld: landing PR, let me know if htere's anything I can do to start on changing modeldefaults to be a controller command
[23:42] <thumper> looking at it
[23:43] <wallyworld> redir: great. to make the change, the api methods need to move to the ModelManager facade, and the CLI command itself needs to embed BaseController not BaseModel
[23:43] <wallyworld> redir: so essentially cut and paste and bit bit of jiggery
[23:44] <perrito666> the only nice thing about working in b&r is that I never ever get a conflict
[23:44] <redir> whelp I'll see what I can do to start and leave it with you at EoD
[23:45] <wallyworld> sure
[23:46] <thumper> really would like this reviewed: http://reviews.vapour.ws/r/5622/
[23:51] <redir> thumper: looking
[23:54] <redir> thumper: LGTM, but you'll want another +1.
[23:58] <thumper> wallyworld: care for another +1?
[23:59] <wallyworld> oh if i must
[23:59] <thumper> wallyworld: or alternatively, we graduate redir so we don't need to bother
[23:59]  * thumper has lunch appt
[23:59] <thumper> so off for a bit
[23:59]  * thumper just proposes a bit of work


[21:37] <jderose> does anyone know when the *-lts-utopic packages will get included in the daily trusty ISO? in other words, where  are the 14.04.2 ISOs being staged?
[21:53] <tjaalton> not here, try -release
[22:11] <jderose> tjaalton: gotcha, thanks!
[22:25] <mlankhorst> considering the release is on the 5th, i would imagine 'soon'


[21:40] <k1l> ftr: i told taterots in pm he should come here to talk about that mute.
[21:42] <k1l> but now i think a mute wasnt the right thing, since he was the user requesting access to user's systems in pm last time.
[23:01] <k1l> ohlolz> hey pastor bazhan_g


[00:02] <peanutb> Ahmuck: this comp has 512 megs of ram
[00:02] <peanutb> the other one i was using had some weird Rambus ram in it or something so it got debian on it
[09:53] <spiekey> howdy!
[09:53] <spiekey> has someone ever made a AP out of a ubuntu box?
[09:54] <spiekey> there are tons of documentation about Wirless Clients, but not how to set up your own AccessPoint
[10:03] <t94xr> yeah i've wanted to that aswell
[10:04] <pteague> anybody know how to remove tomcat from the services started on boot?
[10:04] <t94xr> lots of people usually end up reflashing a WRT54GL and extending the antenna's to larger amplified ariels
[10:13] <spiekey> if i use: "pre-up iwconfig wlan0 mode Ad-Hoc"  then i can see my box, if i change it to "pre-up iwconfig wlan0 mode Managed" it disapears.
[10:14] <spiekey> any idea why?
[10:14] <spiekey> where is my config: http://pastebin.ca/830877
[11:39] <Nafallo> hmm
[11:39]  * Nafallo needs to implement mailfiltering on the serverlevel
[16:10] <zylmak> hello
[16:10] <zylmak> i have a problem setting up perl in apache
[16:24] <nealmcb> zylmak: I may not know how to help, but you'll be much more likely to get an answer .... damn
[22:36] <pteague> anybody know what the url for the buy one get one is? for the laptops?
[23:25] <pteague> The Ubuntu project is poised to release its second Long Term Support (LTS) release in April, which will be crucial to its acceptance in corporate environments.  We don't know a lot about the Ubuntu 8.04 LTS release ("Hardy Heron") but the server release better support virtualization in a big way if the company is going to push into data centers with any success...