[12:50] <dandrader> cnd, about your utouch-qml specs: seems that any anonimous user can change it. At least I'm not logged in with any google account and was able to change the background of your "uTouch-QML 1.1 Algorithm"
[14:02] <cnd> dandrader|afk, yeah, but it's revisioned
[14:02] <cnd> I figure it's like a wiki page
[14:02] <cnd> and the likelyhood that someone messes with it is extremely small
[14:15] <cnd> I'm still grinding on a couple issues that Peter is seeing trying to use xorg-gtest
[14:15] <cnd> I hope to iron them out today and finish documenting some research
[14:15] <cnd> dandrader|afk, tvoss, bregma: standups
[14:16] <dandrader> working on the logic that delivers gestures to nux areas
[14:16] <tvoss> Chromium patch cleanup, writing up research results
[14:17] <dandrader> wow, so the chromium patch is still didn't get merged
[14:18] <cnd> dandrader, it's going to be a long slog for it
[14:26] <bregma> I'm preparing an SRU for #997630 and investigating #872022
[14:27] <dandrader> bug #997630, bug #872022
[14:28] <dandrader> speaking of bugs, unity still doesn't pick up my trackpad if I pair it after logging into my unity session
[14:43] <dandrader> did you get to implement this? https://docs.google.com/a/canonical.com/drawings/d/11U4inGyYFq925CdW2_yB9UskmgS0MGU4gDfG0xk-aH0/edit?pli=1
[14:43] <dandrader> cnd, ^
[14:44] <cnd> dandrader, hmmm, can't say I've had any issues with unity and trackpad pairing
[14:44] <cnd> dandrader, no, it's not implemented yet
[14:44] <cnd> I spec'd it while in oakland
[14:44] <cnd> one of the other squads is going to implement it


[01:39] <cjwatson>   276943 | -B | linux-ubuntu-modules | 2.6.22-11.28         | 13 hours
[01:39] <cjwatson>          | N linux-ubuntu-modules-2.6.22-11-hppa32/2.6.22-11.28/hppa Component: main Section: base Priority: OPTIONAL
[01:39] <cjwatson> [...]
[01:39] <cjwatson> lamont: this is intentional?
[01:39] <cjwatson> I don't see a linux-source-2.6.22 build
[01:40] <cjwatson> and hppa failed to build on -11.33 and hasn't yet built on -11.34
[02:54] <lamont> cjwatson: yeah
[02:55] <cjwatson> is it built against a non-archive linux-image?
[02:55] <lamont> gutsy is building vs the gutsy-stage0 archive, which has linux-source-2.6.22_2.6.22-11.32hppa1, which as the fix that will be in 11.34
[02:56] <lamont> -11.33 was ftbfs because hppa64 lost a module, otherwise it would have built.  BenC has the fix committed for -11.34
[02:56] <lamont> -11.32 was ftbfs because the abi/module files weren't there (since it wasn't in launchpad)
[02:57] <lamont> so it's the right bits, just of question-causing ancestry
[02:58] <cjwatson> I see, but you'd rather get this in now?
[02:58] <cjwatson> ok ...
[02:59] <cjwatson> 11.34 is uploaded fwiw
[02:59] <lamont> and I just pushed 11.34 to the front of the queue
[02:59] <lamont> cjwatson: it really doesn't matter when it shows up..
[03:00] <lamont> there are many packages that are waiting for cprov's fix, and sometime in the next 100-200 packages, we'll start building universe, since we'll be done with all of main that we know about
[03:00] <lamont> sadly, little things like db4.* and gcc-4.{1,2} are among the missing
[03:00] <cjwatson> lamont: accepted, anyway
[03:00] <cjwatson> what's cprov's fix?
[03:01] <lamont> cjwatson: the  sooner we get all that in, the sooner d-i will cause you to notice palo-installer and partman-palo :-)
[03:01] <cjwatson> did those fall into universe again?
[03:02] <lamont> they're universe atm
[03:02] <cjwatson> palo-installer source promoted
[03:02] <cjwatson> and fuck it I might as well re-promote partman-palo too
[03:04] <lamont> eventually we'll need gcc-4.1-hppa64 in main as well.  but gcc-4.1 needs to have a build record and get built before that will show up as a need.
[03:04] <lamont> and yes, that's a prereq to building linux-source-2.6.22, said prereq met from gutsy-stage0
[03:07] <lamont> for the record, expect is a cluster
[03:07] <lamont> it actually still has K&R function definitions in the C...
[03:08] <lamont> slowly working my way through all of the implicit definitions
[03:08] <lamont> which should fix the ftbfs
[03:09] <lamont> speaking of which - I need to pester infinity about adding my ugly sbuild-hack to ubuntu (it's already in debian): builds of packages that _use_ implicitly converted pointers get to FTBFS even if dpkg-buildpackage exited with 0 status.
[03:09] <lamont> it's done wonders for motivating fixes in debian. :-)
[03:10] <lamont> cjwatson: so, assuming that cprov pushed the new tarball, we're building from gutsy+gutsy-stage0.  prior to that, all depends were coming from gutsy-stage0
[03:10] <lamont> and I'm slowly overwriting gutsy-stage0 with gutsy bits from ports.u.c
[03:11] <lamont> and time for this one to head home.
[03:12] <lamont> cprov pushed my tarball.  woot
[03:15] <lamont> http://bld-4.mmjgroup.com/~wb/buildLogs/stats/gutsy.hppa.png is the current hppa-only graph,the step on the right was an IP issue - the line should actually be of fairly constant upslope.
[03:15] <lamont> and really out the door.  back on at home in about an hour give or take
[03:18] <cjwatson> lamont: sbuild-hack> that sounds like a use case for gcc-opt (or a reimplementation) ...
[04:43] <lamont> OTOH, no scrollback here for the last 6.5 hours...
[04:46] <lamont> cjwatson: the sbuild hack simply passes the log file as std in to the hook script given in .sbuildrc, with stdout appended to the logfile afterwards, and a non-zero status --> FTBFS
[04:49] <cjwatson> gross :)
[04:49] <lamont> cjwatson: for example: http://buildd.debian.org/fetch.cgi?&pkg=desmume&ver=0.7.3-2&arch=ia64&stamp=1189073971&file=log
[04:50] <lamont> the dependency of pretty much all of gnome having a segv that wasn't detected during build is to thank for that hack
[04:50] <cjwatson> neat
[04:50] <cjwatson> damn. stuck in Windows for an hour while wubi downloads an Ubuntu ISO unnecessarily.
[04:51] <lamont>         if (defined $conf::exit_hook and open TMP, '-|', "$conf::exit_hook <$main::pkg_logfile") {
[04:51] <lamont>                 local $/ = undef;
[04:51] <lamont>                 my $log = <TMP>;
[04:51] <lamont>                 close TMP;
[04:51] <lamont>                 $rv |= $?;
[04:51] <lamont>                 print PLOG $log;
[04:51] <lamont>         }
[04:52] <fabbione> cjwatson: in what timezone are you?
[04:53] <lamont> 11.34 has about 30 min more on kohnen
[04:53] <lamont> fabbione: I'm gonna bet he's on some US TZ
[04:53] <cjwatson> fabbione: usual
[04:53] <cjwatson> lamont: bzzt
[04:53] <lamont> cjwatson: why are you up at 3AM then
[04:53] <lamont> ?
[04:54] <cjwatson> lamont: yeah, I helped you write that, remember? ;)
[04:54] <cjwatson> lamont: beta freeze and number of bugs is scaring the shit out of me
[04:54] <lamont> did you?  I thought you were sleeping and I had to lean on my HP cow-orkers.
[04:54] <lamont> ah, makes sense
[04:54] <cjwatson> but now unionfs is on course to work again so I will be able to sleep shortly
[04:54] <lamont> ah hell.  how soon do I need to upload expect?
[04:54] <cjwatson> but wubi is horribly late and I want to take the opportunity to beat on it a bit
[04:55] <fabbione> cjwatson: and where are all your minions that should be slavery-working for you?
[04:55] <cjwatson> fabbione: several of them already are ;-)
[04:55] <fabbione> eheh
[04:55] <lamont> minions are good.
[04:55] <cjwatson> lamont: after tomorrow European morning, you have to get an exception
[04:55] <lamont> sigh
[04:56] <lamont> I had kinda wanted to go to bed.
[04:56] <cjwatson> maybe it should just be deferred to post-beta
[04:56] <cjwatson> it would be OK then, and would give you more time to get it right
[04:56] <lamont> ok.  I was planning to sleep and work on it tomorrow.  It's basically an iteration across the source actually including headers as needed to have function prototypes.
[04:57] <lamont> sadly, this involves adding prototypes to some of the .h files in the sourc.e
[04:58] <lamont> sadly, we have just over 50 packages to build on hppa/gutsy before we need to have that bug fixed, or do a bulk no-change-upload fest.  (that'd be post-beta, sadly.)
[04:58] <lamont> or pray that infinity's postgres foo is strong.
[04:58] <lamont> did I say that out loud?  oops.
[04:58] <cjwatson> hah
[04:58] <fabbione> ROFL
[05:02] <lamont> cjwatson: the cool part is that I can fix it on i386... I just have to make all of the "implicit declaration" warning messages go away.
[05:02] <lamont> just to change topics back to the one at hand
[05:02] <lamont> anyway, sleep now for me.
[05:02] <fabbione> lamont: iz early
[05:02] <fabbione> you usually go to sleep much later after I am awake
[05:02] <fabbione> and today i am awake way earlier than usual
[05:03] <lamont> it's been a long day.  OTOH, I generally gear it off of how long you've been up. :)
[05:04] <lamont> cjwatson: and you're _on_ a US TZ, you're just physically elsewhere. :-)
[05:04] <lamont> anyway, night time for me.
[05:04] <cjwatson> heh
[05:07] <fabbione> night lamont


[14:39] <JamesJM> quit
[14:50] <davidcalle> Hangout link: https://plus.google.com/hangouts/_/hoaevent/AP36tYcJityc4DxCEbCGQyGi32VEO9Ypa9EAYYf5WkEbAuYQo2RaeQ
[14:50] <davidcalle> pstolowski: marcustomlinson  ^
[15:29] <pstolowski> a demo scope utlizing filters I showed on my slides: lp:~stolowski/+junk/scope-filters2
[15:45] <marcustomlinson> at the bottom of: https://developer.ubuntu.com/api/scopes/cpp/sdk-15.04.1/previewwidgets/
[17:58] <popey> DanChapman: you having connection issues?
[17:58] <popey> We can do this via irc if so.
[18:00] <popey> Seems DanChapman is having cloudy internet, in the not good way
[18:00] <DanChapman> yeah hangouts is running really slow and just going black
[18:00] <popey> hah :)
[18:00] <popey> Okay, lets do irc then :)
[18:01] <DanChapman> Ok then let's go for irc then :-(
[18:02] <popey> Ok, lets start then. So first off shall we talk about the upcoming release..
[18:02] <popey> https://launchpad.net/dekko/+milestones  milestones are here
[18:02] <popey> hmm, those don't look right :)
[18:03] <DanChapman> Yep :-) so the next milestone is  the 1.0-beta which is a big one.
[18:04] <popey> Ok, Worth setting a date as a target?
[18:04] <DanChapman> And will be shipping a completely new backend including POP3 support which is super cool.
[18:04] <popey> Ooh!
[18:04] <DanChapman> Probably a good idea. But it's hard to estimate a rough date at the current state
[18:05] <popey> Ok.
[18:05] <DanChapman> the bug list to clear to get that out is still quite large. New contributors welcomed for anyone reading :-D
[18:05] <popey> Speaking of bugs.
[18:06] <popey> https://bugs.launchpad.net/dekko is the bug list.
[18:06] <popey> https://bugs.launchpad.net/dekko/+bugs?orderby=-heat&start=0 sorted by heat.
[18:07] <popey> I notice from the tags that we don't have any tagged bitesized.
[18:07] <popey> I guess that's because dekko is complex code base and finding bitesize ones is hard?
[18:07] <popey> Or just that they all got done when we did the Google Summer Of Code thing eaerlier in the year? ;)
[18:08] <LarreaMikel> I'm in another session, but I would like to ask a question here... may I?
[18:09] <popey> sure thing
[18:09] <LarreaMikel> QUESTION:Is Dekko planning to implement PGP in the near future?
[18:09] <LarreaMikel> Thanks ;)
[18:10] <DanChapman> Yeah the old code base was rather complex, and you usually had to dig into c++. I've made an effort with the rewrite to provide a nice qml client api that new contributors would be able to get up to speed pretty quickly and do pretty much all message related tasks without touching c++ so that should help figure out bitesize stuff going forward
[18:10] <popey> https://bugs.launchpad.net/dekko/+bug/1417587 that would be this bug LarreaMikel
[18:10] <LarreaMikel> thank you popey ;)
[18:10] <popey> DanChapman: awesome.
[18:10] <DanChapman> LarreaMikel, yes it's very likely to happen some point shortly after 1.0
[18:10] <popey> The PGP question is quite popular among our user base
[18:11] <LarreaMikel> great!
[18:11] <LarreaMikel> I'll read you later!
[18:12] <popey> ok
[18:12] <popey> DanChapman: the other question which gets asked quite a lot is one of notifications 😖
[18:12] <mhall119> and desktop packages, I still want that
[18:12] <mhall119> the one I have uses all my CPU
[18:14] <popey> Desktop package as in .deb or .snap?
[18:15] <DanChapman> Lol it's that word again. So notifications is a complex issue. I see penk has made a start on getting my email plugin into the accounts-plugins https://code.launchpad.net/~penk/account-plugins/add-accounts-plugin-e-mail which is cool. But that will  now need to be extended to handle pop3 as well. We also need someone to pick up the polld plugin work
[18:16] <DanChapman> mhall119, as soon as things become usable again I will send you a deb to try :-D.
[18:16] <popey> ok, have poked pat asking if we can get some more time from Penk
[18:17] <popey> Nobody has looked at making a snap yet have they?
[18:17] <popey> Thinking that might be a nice task for somoene to take on, crafting a sane snapcraft.yaml
[18:17] <DanChapman> I looked... eyes glazed other .... closed tab
[18:17] <popey> now launchpad can spit out snaps
[18:17] <popey> Hah, wise ㋛
[18:17] <DanChapman> s/other/over
[18:17] <popey> I can take a look at that.
[18:18] <popey> I've made a few snaps now, it's quite fun
[18:18] <DanChapman> Sounds good :-)
[18:18] <popey> for some value of "fun"
[18:18] <popey> Okay. I have taken a to-do to have a go at that.
[18:19] <mhall119> popey: either format
[18:19] <popey> Actually could be quite an interesting one to do.
[18:19] <mhall119> DanChapman: awesome, thanks!
[18:20] <DanChapman> also the polld plugin is imap only so that would also need extending to pop3. otherwise the notifications issue will remain. I'll add that to the bug report
[18:20] <popey> Good call.
[18:22] <DanChapman> Is there anyone we can poke about getting help with the polld plugins. Or I can make a start after the next release if we can't
[18:22] <popey> I'll speak to pat and see if we can get some help
[18:23]  * popey adds a to-do
[18:23]  * DanChapman was going to show a demo of the new Dekko today. :-(
[18:23] <popey> aw
[18:24] <DanChapman> Cheers. One thing we have never really talked about is handling calendar invites. Is there some way currently i can share them with calendar app?
[18:25] <popey> Hm.
[18:25] <popey> We did discuss this a while back I think, using calendar:// urls?
[18:25] <popey> With Ted I think.
[18:25] <DanChapman> One of the new header section filters can show you all calendar invites so it might be nice to be able to actually do something with them.
[18:25] <popey> with the details of the event encoded in the url.
[18:25] <DanChapman> Hmm did we? I don';t recall that one :-/
[18:26] <popey> heh
[18:26] <popey> maybe it was just me, sorry.
[18:26] <popey> or maybe I'm dreaming, all possible
[18:27] <popey> So this is where you get a calendar invite via email, right
[18:27] <popey> And you want to do what with it? Send it to calendar? Or do you want to interrogate the calendar to see if we're attending?
[18:28] <popey> I think for the latter, we could possibly get access to calendar with the same apparmor profile that calendar itself uses
[18:28] <popey> Given dekko is a blessed app, I think this is reasonable, right?
[18:29] <DanChapman> Yes receive via email and you want to put the event in your calendar.
[18:30] <popey> So do you want to just read the calendar?
[18:30] <DanChapman> Like it would be nice to just pass calendar/eds/whatever the .ics attachment and let the receiving app do what it wants with it rather than try and add calendar functionality to into dekko
[18:30] <popey> or do you want to inject into it too?
[18:30] <popey> right, yes
[18:31] <DanChapman> Is it worth showing in Dekko (an icon or something?) that the event was already added to your calendar?
[18:32] <popey> Well, I think the expectation (set by gmail / outlook) is that you'd get that, yes
[18:32] <popey> if you get email notitifications from gmail saying "Meeting in 10 mins", doesn't it show in the mail that you're a "yes" attending?
[18:33] <popey> But you're mostly talking about throwing the ics at calendar app
[18:33] <popey> do we have a bug for that already? If so we can add calendar and talk to Bill / Renato about that
[18:35] <DanChapman> Yeah i think it does show you that in gmail notifications. Yeah i would ike to just pass the ics off. Would be nice to be able to show you've already done it as well. Let me see if there is a bug, i don't think there is....
[18:36] <DanChapman> Nope can't find one. I'll do that after this session then and add calendar to it.
[18:36] <popey> sweet
[18:36] <popey> I'll speak to the guys
[18:36]  * popey adds a to-do
[18:38] <DanChapman> I'm super excited about releasing the unified inbox and smart folder features in the next update :-) They are working so nice!
[18:38] <popey> \o/
[18:38] <popey> Can't wait.
[18:39] <popey> I'll test that on my laptop when I build a snap of it ㋛
[18:40] <DanChapman> So a common thing I see in client's nowadays is a "snooze" feature. Like does anyone actually use that? And is it something Dekko should look into doing?
[18:41] <popey> What does that even do?
[18:42] <DanChapman> It hides the message until a certain time and then it "re-appears".
[18:42] <DanChapman> I personally don't get the point
[18:42] <popey> Blimey, how very 21st century
[18:42] <popey> Yeah, I can see why people do it, "Procrastinate" button ㋛
[18:43] <DanChapman> hah! :-p
[18:44] <DanChapman> I'll stick that on the "maybe one day" list then.
[18:44] <popey> yeah, wishlist
[18:45] <popey> bitesize even
[18:45] <popey> i.e. Someone Elses Problem
[18:45] <DanChapman> done!
[18:45] <popey> :)
[18:45] <popey> Ok, we've got a few mins left, anything else we should discuss?
[18:46] <popey> I am thinking once we get a snap, we could possibly upload two to the snap store, stable and nightly perhaps?
[18:46] <popey> might be a good way to get wider testing
[18:46] <popey> having a cron job which shoves it in the store, warts and all ?
[18:47] <DanChapman> Nothing immediate to discuss. Next meeting i would like to go through the search filters when James is around.
[18:47] <DanChapman> Yep that sounds good to me :-)
[18:47] <popey> wanna do that as a hangout?
[18:47] <popey> if your connection can handle it heh :)
[18:48] <popey> or is it something that you can do with images and irc?
[18:49] <DanChapman> Yeah i can do that as a hangout will back on my home network then :-) It's like the 1990's on this connection. Went to download chrome 1hr30mins! hah!
[18:49] <popey> haha
[18:51] <popey> Ok. Thanks DanChapman
[18:51] <popey> I'll crack on with my to-dos
[18:51] <popey> we can pounce on James anytime though, feel free to ping him a mail
[18:52] <DanChapman> Thanks popey.
[18:52] <popey> Have a great weekend!
[18:52] <DanChapman> Sorry for the network issues everyone.
[18:52] <DanChapman> popey, and you!
[18:52] <LarreaMikel> thanks Dan ;)
[18:53] <LarreaMikel> and nice job!


[12:50] <do3meli> hey folks
[12:53] <do3meli> just came around a freebsd issue with newest 18.3 release. may @smoser or chad can look at https://bugs.launchpad.net/cloud-init/+bug/1779672 quickly? i see you guys recently changed something in netinfo -> commit id: 14cb4924a6cf191107f9c04698ace2753eb44d2b
[14:29] <ybaumy> smoser: today ive seen that my centos box sees itself as ubuntu distro and tries package_upgrade for example with apt.. is this a known bug?
[14:30] <ybaumy> im on 18.2
[14:33] <ybaumy> i looked at the code from stages.py and util.py.. the get_linux_distro function makes a lookup at /etc/os-release which is there
[14:33] <ybaumy> i havent debugged the function yet
[14:35] <ybaumy> https://github.com/cloud-init/cloud-init/commit/bbcc5e82e6c8e87ca483150205127cb0436c4cd9#diff-c4ca7388c7bb98a487f86f4d62d7fab3
[14:35] <ybaumy> can it be that i have to use 18.3?
[14:49] <danMS> @smoser - just wondered if you can take a look at https://bugs.launchpad.net/cloud-init/+bug/1779207 and let me know your thoughts on it?
[16:02] <blackboxsw> danMS: smoser is out for a few days, one of us will look at it this week.
[16:02] <blackboxsw> perharps today even :).
[16:03] <danMS> Thank you, appreciated!
[16:03] <blackboxsw> looks like it's time for our cloud-init bi-weekly status meeting
[16:03] <blackboxsw> ... the topic lies :)
[16:03] <blackboxsw> not anymore it doesn't :)
[16:04] <blackboxsw> danMS: I'll potentiall have an item of interest for you(Azure-related) in this meeting
[16:04] <danMS> :)
[16:04] <blackboxsw> if you have a chance to glance at it today, it's nothing pressing, but might be interesting.
[16:05] <blackboxsw> #startmeeting Cloud-init bi-weekly status meeting
[16:05] <meetingology> Meeting started Mon Jul  2 16:05:44 2018 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:05] <meetingology> Available commands: action commands idea info link nick
[16:06] <blackboxsw> hi folks, just kicking off another cloud-init status meeting to communicate the recent events in cloud-init land.
[16:06] <blackboxsw> welcome to all, feel free to interrupt as we go through the agenda. As always cloud-init status minutes will live at the following url
[16:07] <blackboxsw> #link https://cloud-init.github.io/
[16:07] <blackboxsw> The meeting agenda is as follows:
[16:08] <blackboxsw> agenda: Previous Actions, Recent Changes, In-progress develepment and office hours (~30 minutes)
[16:09] <blackboxsw> #topic Previous Actions
[16:09] <blackboxsw> Last meeting we have a couple of actions to look over:
[16:10] <blackboxsw>  #ACTION blackboxsw carryover network hotplug vs network maintenance on reboot-only
[16:10] <blackboxsw>  #ACTION blackboxsw carryover network hotplug vs network maintenance on reboot-only [DONE]
[16:11] <blackboxsw> we held multiple meetings, including discussion with mgerdts on a SmartOS solution for handling regenerating network configuration per-boot when a user selects this behavior
[16:12] <blackboxsw> We have just landed a supporting branch in cloud-init tip to enable datasources to define what events (BOOT vs BOOT_NEW_INSTANCE) they will react to when generating network config.
[16:12] <blackboxsw> #link https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348000
[16:13] <blackboxsw> that should give a foundation for other datasources to write/change network config across boots, instead of allowing network config to remain static based on cloud-init's initial network configuration
[16:13] <blackboxsw> the 2nd action ..
[16:14] <blackboxsw> #ACTION haper/blackboxsw review https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904 [CARRYOVER]
[16:14] <meetingology> ACTION: haper/blackboxsw review https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904 [CARRYOVER]
[16:14] <blackboxsw> I'd like to carry this one over. We got a bit bogged down in SRU, CentOs stuff last week and we shold be able to get some eyes on this branch
[16:14] <blackboxsw> I think that's it for actions.
[16:15] <blackboxsw> #topic Recent Changes
[16:16] <blackboxsw> Below is a list of changes landed in cloud-init tip or package publishing that has occured for the project:
[16:16] <blackboxsw> * our 18.3 release was cut from tip if you caught the email on that mailing list
[16:16] <blackboxsw> Congrats all for a great effort at improving quality and adding more datasource/cloud support
[16:17] <blackboxsw> #link https://lists.launchpad.net/cloud-init/msg00164.html
[16:17] <blackboxsw> ^ in case you didn't get the message
[16:18] <blackboxsw> * we also publish 18.3 release into Ubuntu Cosmic and started a stable release update (SRU) to publish 18.3 in to xenial, artful, bionic
[16:18] <blackboxsw> published*
[16:19] <blackboxsw> expectations are that xenial, artful and bionic will have 18.3 after this week of testing
[16:20] <blackboxsw> the remaining changes landed in tip are:
[16:20] <blackboxsw>     - update_metadata: a datasource can support network re-config every boot
[16:20] <blackboxsw>       [Chad Smith]
[16:20] <blackboxsw>     - tests: drop salt-minion integration test (LP: #1778737)
[16:20] <blackboxsw>     - Retry on failed import of gpg receive keys.
[16:20] <blackboxsw>     - tools: Fix run-container when neither source or binary package requested.
[16:20] <blackboxsw>     - docs: Fix a small spelling error. [Oz N Tiram]
[16:20] <blackboxsw>     - tox: use simplestreams from git repository rather than bzr.
[16:20] <blackboxsw>     - release 18.3 [Chad Smith] (LP: #1777743)
[16:20] <blackboxsw>     - docs: represent sudo:false in docs for user_groups config module
[16:20] <blackboxsw>       [Chad Smith]
[16:20] <blackboxsw>     - Explicitly prevent `sudo` access for user module
[16:20] <blackboxsw>       [Jacob Bednarz] (LP: #1771468)
[16:21] <blackboxsw> next topic
[16:21] <blackboxsw> #topic In-progress Development
[16:22] <blackboxsw> Our ongoing development is always listed publicly at the following trello board
[16:22] <blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
[16:23] <blackboxsw> We are going to be focused on SRU validation for Ubuntu this week which should take up the majority of the week.
[16:23] <blackboxsw> At the end of this SRU process we will also rebuild centos binaries in our copr repo
[16:23] <blackboxsw> #link https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/
[16:24] <blackboxsw> so that folks in other envs will have access to latest bits if their distro/cloud doesn't have that update
[16:24] <blackboxsw> Also, specfic to mgerdts  and danMS_ there is a branch in progress for Azure support to regenerate network-config for all interfaces on each boot.
[16:25] <blackboxsw> #link https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348704
[16:25] <blackboxsw> mgerdts: might like it only as another example of a datasource managing network config across boots
[16:26] <mgerdts> Thanks.  Will look at that soon.
[16:26] <blackboxsw> no prob, sorry for all the pings :)
[16:26] <danMS_> will take a look too and spk to paulmey
[16:27] <blackboxsw> also smoser is working on implementing an OCIC datasource (Oracle Cloud Infrastructure Classic)
[16:31] <blackboxsw> think that wraps it up for this week.
[16:31] <blackboxsw> #topic Office Hours (next ~30 mins)
[16:31] <blackboxsw> there should be a couple of eyes on this channel for discusssions, questions, bug requests etc that might need a bit more attention.
[16:33] <blackboxsw> again, thanks for tuning in and helping make cloud-init better!
[16:33] <blackboxsw> meeting minutes will ultimately show at
[16:33] <blackboxsw> #link https://cloud-init.github.io/
[17:02] <blackboxsw> #endmeeting
[17:02] <meetingology> Meeting ended Mon Jul  2 17:02:56 2018 UTC.
[17:02] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-07-02-16.05.moin.txt


 I don't recall exactly why, but not being able to deploy to lxd seems familiar.
[00:38] <perrito666> redir: remember how to do that?
[00:42] <redir> perrito666: well that was last year
[00:43] <redir> I think something like `sudo ip link set lxdbr0 down && sudo ip link delete lxdbr0 type bridge` followed by `sudo lxd init`
[00:44] <redir> but IIRC I prolly also had to remove all the lxd containers and images I had to init again
[00:44] <redir> I don't recall if there's an init only bridge command
[00:44] <redir> perrito666: ^
[00:47] <redir> perrito666: looks like there's a non-interactive option now -- `lxd init --auto`
[00:48] <redir> oh, and you prolly have to kick lxd with sysctl too
[00:48] <redir> erm, systemctl
[02:28] <redir> babbageclunk: were you still reviewing my pr from last year?
[02:29] <babbageclunk> redir: oh sorry - I haven't picked it back up - have you solved the timing problem you were talking about in the meeting?
[02:30] <redir> yep, not really timing, just order of apt installs
[02:30] <redir> and updated the QA steps with a note about fixing a kvm breaking network change
[02:31] <redir> for QA at least
[02:31] <redir> but I need 2 +1s since is it over 500 lines
[02:32] <babbageclunk> redir: ok, taking another look
[02:32] <redir> babbageclunk: much  obliged
[02:44]  * redir goes afk for a bit. I'll check back later
[04:15]  * redir is unclear about the failures on http://juju-ci.vapour.ws/job/github-check-merge-juju/485/
[04:15] <redir> if they look familiar to anyone let me know
[04:22] <babbageclunk> jam: could you take another look at https://github.com/juju/juju/pull/6735?
[04:22] <babbageclunk> jam: Also, happy new year!
[04:23] <babbageclunk> Hmm, I'm confused - why is my irc client completing jam when he's not here?
[04:28] <wallyworld> babbageclunk: ah, i just sent an email, thought you were EOD. when you start tomorrow, there's another PR to look at, sorry
[04:29] <babbageclunk> wallyworld: ok, will take a look soon - still going through redir's one at the moment!
[04:29] <jam> babbageclunk: I'm afk, but I have an IRC forwarder.
[04:29] <jam> babbageclunk: so technically I'm always here. :)
[04:30] <wallyworld> babbageclunk: ty. once we get this landed and in the hands of the GUI guys, we may see some nice progress for next week hopefully
[04:31]  * wallyworld needs to do a coffee run, state of emergency here, bbiab
[04:31] <babbageclunk> jam: Ah - I didn't see you in the list because you're an op!
[04:32] <jam> I am OP :)
[04:32] <jam> so technically I'm off this week, I'm only around because I'm sitting here doing my personal budgeting. but I can try and give it a look sometime
[04:34] <jam> babbageclunk: so what is DefaultCloudName() vs Cloud.Name? It isn't quite clear from the diff why you need both.
[04:34] <jam> is the latter the variable where you store the result of the former?
[04:35] <babbageclunk> jam: yes
[04:36] <jam> babbageclunk: I will fully admit to not doing as full of a review as last time, but LGTM
[04:36] <babbageclunk> jam: good enough for me! ;)
[04:36] <babbageclunk> jam: thanks - sorry to interrupt your holiday!
[07:09] <mup> Bug #1653888 opened: juju-db service using 30GB+ memory <juju-core:New> <https://launchpad.net/bugs/1653888>
[11:00] <voidspace> frobware: macgreagoir: if you have a chance https://github.com/juju/juju/pull/6761
[11:12] <macgreagoir> voidspace: Testing it now.
[11:21] <voidspace> macgreagoir: thanks
[11:44] <macgreagoir> voidspace: LGTM, fwiw
[11:44] <voidspace> macgreagoir: thanks
[11:45] <voidspace> macgreagoir: I'm going to merge then
[11:46] <macgreagoir> voidspace: ianagr :-) but OK by me.
[11:46] <voidspace> macgreagoir: gah, you should be by now
[12:02] <rick_h> macgreagoir: not a 'gr'?
[12:02] <rick_h> oh, reviewer
[12:02] <rick_h> heh
[12:02] <macgreagoir> :-)
[12:07] <perrito666> does anyone know how to nuke the lxd bridge and re-create it?
[12:12] <macgreagoir> perrito666: Does `lxd init ...` give you what you need?
[12:23] <perrito666> macgreagoir: meh, it says I have containers, which I dont
[12:23] <perrito666> macgreagoir: but most likely its what I need
[12:26] <macgreagoir> `brctl delbr` et cetera
[12:27] <voidspace> rick_h: desparate for coffee - will be 2 mins late!
[12:29] <perrito666> macgreagoir: oh I get it, It can not just run init on networking, that is kind of sad :(
[13:45] <perrito666> man, apt-get purge has lost some of its touch
[13:48] <natefinch> perrito666: I have a vsphere question for you
[13:49] <perrito666> natefinch: oh, for me? you shouldn't have bothered
[13:49] <natefinch> perrito666: well, just trying to start off the new year on the right foot ;)
[13:50] <natefinch> perrito666: I am testing my provider Ping method, which is really just calling govmomi.NewClient with the given URL... but I am getting back 400 bad request for some reason
[13:50] <perrito666> natefinch: well shoot, in a moment ill need to go fetch my wife's bd cake
[13:51] <natefinch> perrito666: I'll try to be quick
[13:51] <perrito666> you might be doing a bad request??
[13:51] <natefinch> perrito666: also, happy birthday to your wife :)
[13:51] <natefinch> perrito666: is there a specific path I need to give the NewClient function other than https://<someip> ?  I'm running against the vsphere that QA uses, in oil
[13:52]  * perrito666 checks code
[13:53] <perrito666> natefinch: first of all, remember you need to close that because they never time out
[13:53] <natefinch> perrito666: yeah, doing that
[13:53] <natefinch> perrito666: oh, hmm, looks like it might be /sdk
[13:54] <perrito666> look for providers/vsphere/client.go line 79
[13:54] <perrito666> yep
[13:54] <perrito666> I wonder if that is going to answer to you without credentials
[13:55] <perrito666> natefinch: on second thought, 40X is a good indicator of ping
[13:55] <perrito666> it means something is up there and can tell you "no"
[13:55] <natefinch> perrito666: well, almost anything will respond with 400 bad request, though
[13:56] <perrito666> true, I am not sure how accurate you need your ping to be
[13:57] <natefinch> perrito666: as accurate as possible.... with /sdk I get ServerFaultCode: Cannot complete login due to an incorrect user name or password.   which is probably good enough
[14:11] <perrito666> k bbl
[14:36] <frobware> macgreagoir, voidspace: updated https://github.com/juju/juju/pull/6758 with some unit tests. Would appreciate a look so that I can address any issues and try to get a CI run before tonight.
[14:36] <frobware> rick_h: ^^
[14:37]  * frobware bbiab
[14:55] <mup> Bug #1651260 changed: landscape bundle error when deployed via gui (KeyError in config changed hook in haproxy charm) <matrix> <juju:New> <https://launchpad.net/bugs/1651260>
[15:07] <mup> Bug #1651260 opened: landscape bundle error when deployed via gui (KeyError in config changed hook in haproxy charm) <matrix> <juju:New> <https://launchpad.net/bugs/1651260>
[15:10] <mup> Bug #1651260 changed: landscape bundle error when deployed via gui (KeyError in config changed hook in haproxy charm) <matrix> <juju:New> <https://launchpad.net/bugs/1651260>
[15:18] <perrito666> back
[15:32] <macgreagoir> voidspace: If you have a wee sec, please: https://github.com/juju/juju/pull/6762/
[15:35] <voidspace> macgreagoir: looks straightforward to me
[15:36] <macgreagoir> 'Tis :-)
[15:37] <voidspace> macgreagoir: LGTM
[15:38] <macgreagoir> Cheers
[15:38]  * voidspace lunches
[15:58] <natefinch> rick_h: lol, so, I was looking at my old change, and I think I know why it's causing a failure now.... because I stopped throwing away the error that we get from lxd init
[15:58] <rick_h> natefinch: heh, one step forward...
[15:59] <natefinch> rick_h: so I think we were always hitting this error, we just were logging it and ignoring it before.  The easy fix is to go back to ignoring it.  The harder fix is to try to only run lxd init if it's needed (or handle the "you already ran this, dummy!" error)
[16:01] <natefinch> probably #3 is easiest - still always run lxd init, but check for the "you already ran it" error and ignore just that one.  That way if it fails the first time, we actually fail early, rather than try to continue on even though there's no lxd running
[16:02] <frobware> natefinch: Logging an error causes too many false positives, IMO. I've seen bug reports / mail / IRC saying, "lxd is broken, it reports an error, see this error in the logs..."
[16:03] <natefinch> frobware: right, my point is, let's not log the error in this known case, since it's basically like the error when you try to create a file that already exists.
[16:04] <natefinch> frobware: but for other unknown errors, let's actually return them, not just log them and effectively ignore them
[16:06] <frobware> macgreagoir: ping
[16:06] <macgreagoir> frobware: pong
[16:07] <frobware> macgreagoir: do you have some time to look through https://github.com/juju/juju/pull/6758
[16:07] <macgreagoir> frobware: I have it loaded, just kicking a couple of other things first, sorry.
[16:08] <frobware> macgreagoir: ty
[16:32] <redir> happy wednesday juju-dev
[16:42] <frobware> redir: only 2 to go. :)
[16:47] <macgreagoir> G'day redir
[16:57] <macgreagoir> frobware: Review and comment. No show-stopper.
[16:57] <frobware> macgreagoir: wall clock in tests...
[16:58] <macgreagoir> :-)
[16:58] <macgreagoir> I have one like that and I'd like to see you solve it :-D
[16:59] <frobware> macgreagoir: ah, you found a bug.
[17:05] <frobware> macgreagoir: all the tests pass 0 for a timeout, which means indefinite, and therefore no timer/clock is used.
[17:06] <frobware> macgreagoir: there is one test that checks for timeout and passes 1s.
[17:06] <frobware> macgreagoir: because of this I chose not to use the testing clock.
[17:06] <macgreagoir> frobware: Maybe worth a comment so we don't scoop it up next time there's a testing sprint?
[17:12] <frobware> macgreagoir: done
[17:14] <frobware> voidspace: you about?
[17:14] <voidspace> frobware: yep
[17:14] <macgreagoir> frobware: acked in PR
[17:14] <frobware> voidspace: could you also take a look over https://github.com/juju/juju/pull/6758
[17:14] <voidspace> frobware: yep
[17:15] <voidspace> coffee first though
[17:15] <frobware> macgreagoir: you've gone all recursive on me.
[17:18] <redir> sinzui: yt?
[17:18] <sinzui> redir: yes
[17:19] <redir> happy new year:)
[17:19] <rick_h> natefinch: is it not something that we can check if lxd is configured and fail fast that way? I guess what's fail here?  Can I use that for live testing kvm? Are the details in the usual place?
[17:21] <natefinch> rick_h: maybe there's a lxd command we can run that'll tell us if it is initialized?  I definitely don't want to write any heuristics outside of what lxd itself tells us though
[17:21] <sinzui> redir: I don't think I can help. QA has ppc64el guests. I am not sure we can run kvm on them.
[17:22] <redir> sinzui: OK. Good to know, I won't spend time trying
[17:22] <sinzui> redir: well maybe. this can be done because I know a bit about borbein and its vms
[17:22]  * redir backs up
[17:23] <natefinch> tych0: is there an lxd command that we can run that'll tell us if we need to run lxd init?
[17:23] <rick_h> natefinch: I guess the error you're getting *is* telling you that in some sense
[17:23] <sinzui> redir: I can get you on to a Juju QA host and on to a charm testing host. brobein has a special kernal to support libvirt. Juju wont just work because the ubuntu kernel needs to be special
[17:24] <natefinch> rick_h: yeah, just wondering if there's a better way.  Ideally something that doesn't require string matching on the lxd output for a specific error message
[17:26] <sinzui> redir: So borbein is your best chance to verify that juju can drive kvm, but surely you need a cloud that is ppc64el with the right kernel to test that juju can deploy kvm containers to an instance
[17:27]  * sinzui writes email with instructions.
[17:28] <redir> sinzui: yeah that sounds right -- that I need both. I just had a note to ask when it came timet to live test on a different arch. I'll just work with the arm and ppc folks where they can test it.
[17:28] <redir> sinzui: the code wants same host/arch to work
[17:29] <sinzui> redir: I understand. QA has been asking for proper ppc64el resources for more than a year
[17:29] <sinzui> redir: arm is a different, but also painful story
[17:30] <redir> sinzui: tyvm
[17:31] <sinzui> redir: We have a powerful arm64 host, but have never gotten libvirt working to build a vmaas. I really want to do this, but qemu/libvirt don't like the arch
[17:37] <frobware> The GIL is gone: https://opensource.googleblog.com/2017/01/grumpy-go-running-python.html
[17:37] <frobware> And C extensions too. But...
[17:43] <perrito666> frobware: lol, yeah, I think without C extensions its a bit useless though
[17:43] <perrito666> isnt ssl in python a C extension?
[17:43] <frobware> perrito666: it cuts out a LOT OF STUFF
[17:44] <perrito666> frobware: I presume its a "we just dont want to re-write all this code base in go"
[17:44] <frobware> perrito666: I think it just shows that if you are running your own stuff on your own infra you can do whatever makes sense _for_ _you_
[17:44] <perrito666> yep
[17:45] <natefinch> ahh, it's a transpiler... interesting
[17:46] <frobware> voidspace: any feedback. I need to EOD soon and want to merge before we scream "RC1 - ship it!"
[17:46] <voidspace> frobware: looks good to me I think
[17:47] <frobware> voidspace: when we rewrite the script in Go (^^) I think a lot of the testing friction will begin to disappear w.r.t. the bridge.py.
[17:47] <voidspace> I like the scriptrunner
[17:47] <voidspace> frobware: ok
[17:47] <voidspace> frobware: I struggle to believe that Go is *really* easier to test ;-)
[17:47] <voidspace> frobware: but possibly
[17:47] <voidspace> the impedance mismatch goes
[17:48] <frobware> voidspace: I think it's still the fact the script "does it all". Some of the invocation is in python, wrapped by Bash, invoked from Go.
[17:48] <voidspace> yep
[17:53] <frobware> voidspace: I would like to not expose dry-run too. :/
[17:53] <voidspace> frobware: yeah, if possible
[17:54] <frobware> voidspace:  that is purely an implementation detail.
[17:54] <voidspace> frobware: anyway, LGTM
[17:54] <frobware> voidspace: I'm happy to follow-up, but I think it's important to know get a CI test run on this _feature_ branch.
[17:54] <frobware> s/know/now
[17:54] <voidspace> frobware: yep, cool
[17:54] <voidspace> frobware: not sure if I'll get mine in today
[17:55] <voidspace> struggling
[17:55] <frobware> voidspace: want a review or something else?
[17:55] <voidspace> frobware: no, still trying to find the bug
[17:55] <voidspace> frobware: or at least find whereabouts user config are passed into lxd
[17:56] <voidspace> frobware: just getting back to it really, I'll give it a couple of hours or so before EOD
[17:56] <voidspace> be nice to find itt
[17:56] <frobware> SetConfig()?
[17:59] <voidspace> frobware: not sure
[17:59] <voidspace> I don't think so - or at least I'd like to see all the layers
[18:13] <perrito666> we should get  a free day every time we change something in the output of status
[20:09]  * perrito666 considers hacking his  desktop to support a 3rd monitor
[20:18] <natefinch> does it not?  My laptop supports integrated screen + 2 external
[20:22] <perrito666> natefinch: the furniture I meant :p
[20:22] <perrito666> the computer card supports like 8 screens
[20:30] <natefinch> perrito666: lol,
[20:47] <natefinch> rick_h: should this fix go to develop?
[20:47] <natefinch> rick_h: for the LXD init thing?
[20:47] <rick_h> natefinch: into the 2.1-dynamic-bridges branch and the 2.1 and develop
[20:47] <natefinch> okie
[20:47] <rick_h> natefinch: actually just the 2.1-dynamic-bridges and develop
[20:47] <rick_h> the 2.1 will get merged in
[20:52] <natefinch> https://github.com/juju/juju/pull/6764 and https://github.com/juju/juju/pull/6765
[20:53] <alexisb> babbageclunk, perrito666 is one of you around
[20:53] <perrito666> alexisb: I am
[20:53] <babbageclunk> alexisb: yup
[20:53] <babbageclunk> alexisb: perrito666 is.
[20:53] <babbageclunk> ;)
[20:53] <alexisb> babbageclunk, rick_h has a request
[20:53] <rick_h> babbageclunk: can you please look gat ^
[20:53] <rick_h> look at that is
[20:53] <rick_h> babbageclunk: and help natefinch get his PR landed
[20:54] <perrito666> babbageclunk: I can do it so your day start is not so rough
[20:54] <babbageclunk> rick_h: yup yup
[20:54] <babbageclunk> perrito666: ok, thanks
[20:54] <rick_h> natefinch: can you put a bit more background in that PR description please?
[20:55] <perrito666> natefinch: that is 6764 and 6765 right?
[20:57] <rick_h> perrito666: correcty
[20:57] <perrito666> k
[20:58] <natefinch> QA steps and description added
[20:59] <rick_h> ty natefinch
[21:01] <perrito666> natefinch: interesting "sudo dpkg-reconfigure -p medium lxd" <-- that error by lxd is also a lie
[21:05] <perrito666> natefinch: ship them
[21:08] <natefinch> merging
[21:21] <rick_h> natefinch: ty, balloons ^ once that hits we can start a full test run of the feature branch please
[21:27] <perrito666> since we are in it, could anyone review this? https://github.com/juju/juju/pull/6763
[21:30] <natefinch> perrito666: looking
[21:32] <natefinch> perrito666: why isn't this using model status
[21:32] <natefinch> perrito666: surely controller upgrading should cause the model to become busy until it's finished
[21:32] <perrito666> natefinch: you would think
[21:33] <perrito666> but no, status actually answers even while controller is upgrading
[21:33] <perrito666> I believe this patch will make us discover a whole new world of bugs where juju answers its upgrading when its not
[21:34] <natefinch> right but, what I mean is, the model-status is going to still say "available" when it's really not
[21:35] <natefinch> i.e. you can't juju deploy something while the controller is upgrading
[21:35] <natefinch> (presumably)
[21:37] <perrito666> natefinch: interesting, the rules gouvering statuses are a bit heavier than this
[21:39] <natefinch> perrito666: I'm not sure that that means
[21:41] <perrito666> natefinch: there is a logic behind when each status is set
[21:41] <perrito666> and we dont have a status that correctly reflects "upgrading" afaik nor think to add it, also adding a status might not be backwards nice
[21:42] <natefinch> perrito666: model-status is the correct place to put this.  We only recently created it, so there's no backward compatibility problem
[21:42] <natefinch> perrito666: that may be why the powers that be were thinking of just adding a boolean rather than using the status we already have in place.
[21:42] <natefinch> rick_h: ^
[21:43]  * rick_h reads back
[21:43] <perrito666> natefinch: nope, there was not much thought behind it
[21:44] <natefinch> rick_h: basically... we added a new boolean to Model status, but probably should just reuse the relatively new model-status field
[21:44] <rick_h> natefinch: perrito666 +1 to using the field. We don't want to make decisions based on checknig several different fields
[21:44] <natefinch> re: https://github.com/juju/juju/pull/6763
[21:44] <rick_h> natefinch: perrito666 adding a new "is-controller-doing-X" isn't ideal
[21:47] <perrito666> mm, I think I agree with both of you
[21:48] <perrito666> rick_h: what do you reckon is the status we should set? I presume I should be adding an "upgrading" message too
[21:49] <alexisb> does model-status only show up in yaml?
[21:51] <rick_h> natefinch: do you have a link to your PR from the sprint?
[21:51] <natefinch> rick_h: I can get it
[21:51] <natefinch> rick_h: https://github.com/juju/juju/pull/6661
[21:52] <perrito666> natefinch: that seems to also work on json right?
[21:52] <natefinch> alexisb: it's shown for juju models and juju status --format=yaml/json
[21:52] <rick_h> perrito666: ^ shows how the model status was updated to be able to be used generically and might help point to where we're thinking.
[21:53] <rick_h> perrito666: right, so the idea is that during an actual upgrade we'd update that as "upgrading" and so it could be "migrating" or "upgrading" or ...
[22:01] <natefinch> rick_h, perrito666: gotta run for dinner.... but I recommend Status: status.Busy and StatusInfo: "controller is upgrading"
[22:02] <perrito666> sounds like a fair start
[22:02] <rick_h> ty natefinch
[22:02] <perrito666> rick_h: ok there is some room for thought there but I believe that the rule should be something like if status != error && upgrading return  Status: status.Busy and StatusInfo: "controller is upgrading"
[22:03] <rick_h> perrito666: k
[22:03] <perrito666> I would not Set status for upgrading because we risk having other statuses shadowing that in the future
[22:03] <perrito666> sorry for rubber ducking you btw
[22:03] <rick_h> hmmm, yea thinking
[22:04] <rick_h> so...you're marking it busy though right?
[22:07] <perrito666> yes, but I am sort of hijacking that model.Status call and returning a status that is not the one set because the fact that an upgrade is in progress superseeds whatever model think its doing, makes sense?
[22:07] <perrito666> rick_h: ^
[22:07] <rick_h> perrito666: well, not really. I mean can the model be migrating and upgrading?
[22:08] <rick_h> perrito666: I'm concerned that going that route leaves us open to a non-finite state machine of what is going on
[22:08] <perrito666> should not
[22:08] <perrito666> I mean upgrade a non concurrent task, nothing else should be happening with upgrade
[22:08] <rick_h> perrito666: so I'd rather that it was actually set and that other code could rely on that information. e.g. a requested migration call should check that it's available before migrating and it then sets migrating?
[22:09] <rick_h> perrito666: and the same is true of upgrading, a requested upgrade would fail if not available and if it starts it updates status and is tracked with "since..." and such
[22:09] <rick_h> perrito666: like any other long running activity like that?
[22:09] <perrito666> rick_h: if you request anything that makes a change on juju while upgrading juju will say no
[22:09] <perrito666> not very politely
[22:09] <rick_h> perrito666: right, but by setting a firm status we're allow juju to get more polite?
[22:10] <perrito666> rick_h: we are, in this case we should set this status for all models before ugprading
[22:10] <rick_h> perrito666: and without tracking the actual change by setting status we don't have real visiblity as to when it started/etc like we do the migration? I guess it feels like we're doing this one different than migration/etc without something I see as really different
[22:10] <perrito666> then set.... mm I am not sure what to set after finishing
[22:10] <rick_h> perrito666: but you can upgrade a model at a time
[22:10] <rick_h> perrito666: only some models may be upgrading
[22:10] <rick_h> perrito666: available?
[22:10] <rick_h> since nothing else can take that while you own it
[22:11] <rick_h> perrito666: I understand where you're coming from, I'm asking for a bigger promise that Juju works
[22:11] <perrito666> rick_h: I am thinking in the not so long term, I mean if the model was in some other status and I mark upgrading I would be loosing that status right?
[22:11] <perrito666> also, upgrade cannot happen for a model only, can it?
[22:11] <perrito666> In a regular juju I mean
[22:12] <perrito666> in a regular juju install upgrading upgrades the controller binary and the mongodb for all models in that controller
[22:13] <rick_h> perrito666: yes, because the controller is upgraded on it's own, then the model is migrated at the same version it was, and then can be upgraded I thought
[22:13] <rick_h> perrito666: but the whole rule of "the model can't be on a version > than the controller" and migrations and all this comes to play
[22:14] <rick_h> nope
[23:00] <voidspace> rick_h: I'm going to have to rethink my approach to bug #1631254
[23:00] <mup> Bug #1631254: [2.0rc3] lxd containers do not autostart <rteam> <juju:In Progress by mfoord> <https://launchpad.net/bugs/1631254>
[23:00] <voidspace> rick_h: however, given that the way to reproduce it is now to *manually* stop the container
[23:00] <voidspace> rick_h: as the "hard shutdown" failure mode has been fixed in lxd
[23:00] <voidspace> rick_h: I think it can be demoted from critical and need not hold up 2.1.0
[23:00] <voidspace> rick_h: ok, for me to change it from critical to high?
[23:01] <voidspace> rick_h: (basically we need to keep the user namespace and special case the ones that don't need it I think - which is the opposite way to how I was doing it)
[23:03] <voidspace> rick_h: I haven't changed it from critical to high myself yet, and I'm now EOD (11pm) - g'night
[23:06] <mup> Bug #1492237 opened: juju state server mongod uses too much disk space <canonical-bootstack> <mongodb> <oil-2.0> <uosci> <juju:Triaged> <juju-core:New> <https://launchpad.net/bugs/1492237>
[23:06] <mup> Bug #1634390 opened: jujud services not starting after reboot when /var is on separate partition  <uosci> <juju:Triaged by rharding> <juju-core:New> <https://launchpad.net/bugs/1634390>