[01:56] <chatter> hey guys
[01:56] <chatter> allah is doing
[01:56] <chatter> sun is not doing allah is doing
[01:56] <chatter> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
[08:45] <slevchenko_> Hi guys, can Maas serve as proxy for release upgrade ?
[16:28] <indious> hi all i am new to maas and am setting up a lab. I am having issue with IPMI on HP servers with ILO2 but am able to get the Cisco UCS servers with CIMC working with no issues
[16:29] <indious> i see something about ipmi.template file online which was previously a bug
[16:30] <indious> but with the 2.1.1 MAAS that i am running on Ubuntu 16.04 LTS i have the option to choose IPMI 1.5 or IPMI 2.0 i think that the ILO2 is IPMI 1.5 but i get action denied when with power action
[16:31] <indious> when i switch to IPMI 2.0 just gives me the error that failed to power node on
[16:31] <indious> could anyone assist me with this issue?
[17:08] <hachi> indious: I am not expert but i think you should check your ILO password in the power section of MAAS. We are using IMPI 2.0 and ILO2 without any issue
[17:42] <indious> ok when i use IPMI 2.0 i do not get the access restriction but i can not power the node on
[17:42] <indious> i get this error
[17:42] <indious> Failed to query node's BMC - Access denied while performing power action. Check BMC configuration and try again.
[17:43] <indious> but user settings has full rights
[17:46] <indious> here is what i get in the IPMI logs
[17:46] <indious> Informational
[17:46] <indious>
[17:46] <indious> iLO 2
[17:46] <indious>
[17:46] <indious> 12/28/2016 17:45
[17:46] <indious>
[17:46] <indious> 12/28/2016 17:44
[17:46] <indious>
[17:46] <indious> 3
[17:46] <indious>
[17:46] <indious> IPMI/RMCP login by admin - <IP_ADDRESS>(openmaas.maas).
[17:46] <indious> Informational iLO 212/28/2016 17:45 12/28/2016 17:44 3 IPMI/RMCP login by admin - <IP_ADDRESS>(openmaas.maas).
[17:52] <indious> hachi what is your firmware version on ILO2?
[17:57] <indious> i was able to telnet to the IL02 and login as the users specified and was able to boot the server
[17:57] <indious> not sure why it is failing for MAAS


[01:14] <guiverc> thanks oerheks Bashing-om
[01:17] <Bashing-om> guiverc: Huh .. thanks just for hand holding ?  But... borderline
[04:33] <lotuspsychje> yeah could be he's real
[04:34] <oerheks> no, there are no simular issues, he is drunk, or bored
[04:35] <lotuspsychje> lol
[04:36] <oerheks> guys he is going to reboot
[04:36] <oerheks> say "ay"
[04:36] <hggdh> aie
[04:36] <hggdh> aye
[04:37] <lotuspsychje> hehe
[04:37] <hggdh> well...  SSD firmware updates. I had no idea but I guess it makes sense. ogawd, yet another thing to worry about updating.................
[16:31] <lotuspsychje> blackflow: aka the samsung 840 evo has bad performance bugs==needs firmware
[16:32] <oerheks> for that 840 yes
[16:32] <lotuspsychje> blackflow: the pro's are mostly good to go
[16:32] <lotuspsychje> but check anyway on samsungs site
[16:32] <blackflow> lotuspsychje: yeah but I see on samsung's site there are fw updates even for 850
[16:32] <lotuspsychje> evo or pro blackflow ?
[16:33] <blackflow> BOTH
[16:33] <blackflow> sorry, caps lock
[16:33] <lotuspsychje> oh tnx for feedback blackflow
[16:33] <lotuspsychje> must have been added
[16:33] <lotuspsychje> well, if there are firmwares available: do them :p
[16:33] <lotuspsychje> just keep in mind there 'can' be datalost resulting to reformat
[16:34] <blackflow> yyyyyyyyyeah, not sure about that. if it ain't broken and all that, and so far I don't see anything broken.
[16:34] <tomreyn> i think this is only for old drives, newer ones were seold with newer firmware already. smartctl / hdparm would tell which firmware is running
[16:34] <lotuspsychje> depending on what the firmware holds of course
[16:34] <blackflow> reason I'm also not keen on doing BIOS updates either. got burnt in the past.
[16:35] <blackflow> tomreyn: indeed, good idea
[16:35] <lotuspsychje> blackflow: but lets say we have a 850 pro, samsung gives out 10y warranty, if you dont do the firmware they could say its not under warranty perhaps
[16:36] <blackflow> I'm sure I'll be getting new drives one way or another in half that time :)
[16:36] <blackflow> I renew my computing infrastructure every 5 or so years
[16:37] <lotuspsychje> thats why i work with the 850 pro 10y warranty i like
[16:38] <blackflow> I'll probably hasten this cycle tho'. I'm currently on equipment from 2015, and I'm drooling for some ryzen2 goodness later this year or early next year.
[16:38] <lotuspsychje> didnt get dataloss or breakage neither on them
[16:38] <tomreyn> unfortunately samsung ssd's also dont do TRIM properly https://github.com/torvalds/linux/blob/e64f638483a21105c7ce330d543fa1f1c35b5bc7/drivers/ata/libata-core.c
[16:39] <tomreyn> well not queued TRIM anyways. they just doint support it, but claim that they do.
[16:39] <tomreyn> which is whys there's this blacklist in libata
[16:39] <lotuspsychje> but xenial and up autotrims already right?
[16:40] <tomreyn> yes, there are queued trim and another method. queued would be better if it worked, but the other method (i forgot the name) still works.
[16:40] <lotuspsychje> aha
[16:40] <tomreyn> its just bad for hardware / firmware to claim they support features and when you try to use them they fall flat on their face.
[16:41] <lotuspsychje> tru that
[16:42] <tomreyn> and others, microns, i think, or some of them, actually do queued trim fine
[16:48] <lotuspsychje> ill have a look later on the new firmwares
[17:02] <sonicwind> I gotta read this discussion later... I'm actually in the market for an SSD and am considering both Micron/Crucial and Samsung
[17:03] <lotuspsychje> im fan of the 850 pro's :p
[17:03] <lotuspsychje> but what tomreyn stated is true
[17:03] <sonicwind> I have an 840 in this used laptop I just got and can't say i'm terribly impressed with it, although i think most of that is Ubuntu... haven't had time to work on that
[17:03] <lotuspsychje> sonicwind: evo?
[17:03] <sonicwind> yeah I think... not pro I don't think
[17:04] <lotuspsychje> sonicwind: they i presume you didnt firmware it?
[17:04] <lotuspsychje> *so
[17:04] <sonicwind> mostly whatever all my friend did to it before he handed it over to me... he works in IT
[17:05] <sonicwind> I know much of it is ubuntu, from having done systemd-blame analyze and such... it sits around for 10 seconds just looking for btrfs partitions
[17:05] <lotuspsychje> you can check firmware the way tomreyn suggested above
[17:05] <sonicwind> unfortunately my friend put encryption lvm and uefi on it even though I asked him not to lol...
[17:06] <lotuspsychje> and btrfs isnt the most stable neither :p
[17:07] <sonicwind> I'm eventually going to put plain ext4 and mbr on it, no encryption
[17:07] <lotuspsychje> yeah try that sonicwind
[17:07] <sonicwind> learning curve these past 2 1/2 years has been so crazy fast, I feel sometimes like I'm forgetting as much as I'm learning
[17:08] <lotuspsychje> yeah recall stuff is harder when you grow older :p
[17:08] <sonicwind> so, have enough to remember now without tackling uefi encryption and lvm
[17:08] <sonicwind> yeah I just turned 49
[17:08] <sonicwind> yesterday
[17:08] <sonicwind> plus, seems like there are more problems on ubuntuforums with encryption and lvm than anything else
[17:08] <tomreyn> "sudo hdparm -I /dev/sda | head" should tell the firmware
[17:09] <sonicwind> Firmware Revision:  DXT0AB0Q
[17:10] <sonicwind> samsung ssd 840 series
[17:11] <sonicwind> I do have over 50 pages of notes from that 2 1/2 years though, that I'm constantly revising. It's been a great help. My own manual so to speak. Once I know I have certain stuff down, I can get rid of it.
[17:12] <lotuspsychje> sonicwind: compare your firmware with the one on samsungs site(for your model)
[17:12] <sonicwind> I'll eventually get an encryption, lvm and uefi section to it but not now... I have some basic uefi stuff in it already.
[17:14] <sonicwind> I only see firmware for windows and mac users
[17:15] <lotuspsychje> its non Os related, it just has to be loaded on an usb, then get to your ssd
[17:15] <lotuspsychje> i think i did it with the site frop plop boot manager, to get it on stick
[17:15] <lotuspsychje> from
[17:16] <sonicwind> * Notice: ISO files may be used only via DOS using a bootable CD/DVD.
[17:17] <lotuspsychje> yeah it means you need to boot your made usb, at F12 boot, then let do its job to firmware it
[17:17] <lotuspsychje> this is before ubuntu loading right
[17:18] <sonicwind> right, gotcha
[17:19] <sonicwind> ISO DXT09B0Q ... yep, guess its oudated
[17:19] <lotuspsychje> yeah this will be big performance fix
[17:19] <sonicwind> think I'll just deal with it... another thing for me to mess up
[17:19] <lotuspsychje> lolll
[17:19] <lotuspsychje> if you succesfully burn to usb, nothing can go wrong
[17:20] <lotuspsychje> not sure how i did it exactly anymore
[17:20] <sonicwind> will make a note of it and wait for a day I feel ambitious
[17:21] <lotuspsychje> sonicwind: https://www.plop.at/en/bootmanager/index.html
[17:21] <lotuspsychje> with a tool from here
[17:21] <sonicwind> truth be told, I got all the time in the world to wait for stuff to happen... just want it to work... low expectations.. I'd be happy with 5 minute boot time. I wake up , turn it on and go get breakfast.
[17:22] <lotuspsychje> i dont lol, when i buy an ssd it has to be TURBO!
[17:22] <sonicwind> as it is, my boot time on this laptop with the SSD now is about 46 seconds... at least 20 of that appears to be wasted, but haven't had time to work on it
[17:23] <sonicwind> and 46 seconds isn't any faster than my other sytem with docked external HD I run Ubuntu off of
[17:23] <lotuspsychje> your new purpose in life, 840 performance bug fix :p
[17:23] <sonicwind> actually, the ext HD has booted as fast as 38 seconds or so
[17:23] <lotuspsychje> neat
[17:24] <sonicwind> seemed to get slower after the meltdown/spectre fixes
[17:24] <lotuspsychje> yeah whole world is turning slower now :p
[17:25] <sonicwind> since that started, I still haven't heard of any actual issues in the wild with them... that weren't from someone testing
[17:31] <sonicwind> still amazes me how much you guys offer here... lotuspsychje, tomreyn, oerheks among others
[17:31] <sonicwind> help
[17:32] <lotuspsychje> we share & learn sonicwind
[17:33] <lotuspsychje> togheter as a team we can do alot, co-operate
[17:33] <lotuspsychje> we also learn from issues
[17:34] <sonicwind> Do any of you also work with linux in your day job?
[17:34]  * blackflow raises hand.
[17:35] <lotuspsychje> im running an ubuntu business with barebone laptops and ssd's LTS
[17:35] <sonicwind> nice
[17:35] <sonicwind> usually running a business requires as much time as you spend here lol
[17:35] <lotuspsychje> alot of volunteers are working in IT
[17:36] <lotuspsychje> but others also have years ubuntu experience
[17:36] <sonicwind> yeah
[17:36] <lotuspsychje> we dont judge :p
[17:36] <sonicwind> I started with 14.04 LTS late in the going... lots of change with ubuntu since then, just in that short time
[17:36] <lotuspsychje> we are legion
[17:36] <lotuspsychje> oops
[18:15] <sonicwind> ok, caught up on that earlier discussion... I think maybe NCQ is the other type of TRIM tomreyn was referring to.
[18:16] <tomreyn> sonicwind: yes i think so, thanks ;)
[18:57] <lotuspsychje> man this zexaron can talk some branches oO
[18:57] <tomreyn> :)
[19:00] <tomreyn> there's a reason why i asked him to put the whole story on etherpad or pastebin
[19:00] <lotuspsychje> yeah
[19:01] <lotuspsychje> jeez he can turn around the corner lol
[19:01] <tomreyn> he wouldnt do it, though, and i'm not willing to try to understand the way they present it on the chat
[19:01] <tomreyn> !next
[19:05] <tomreyn> lotuspsychje: they are just not in a very good mental state at this time, which makes it hard to work with them. i'm not sure you saw this: <Zexaron> Yeah trying to get what other people think, sorry I have a ... i'm not able to explain so good the events of past 2 weeks coherent, i've been to hospital in the middle, doing much better now but I'm not that energetic etc
[19:05] <lotuspsychje> yeah
[19:14] <lotuspsychje> pauljw: ignore is like an austrich stick head in the sand :p
[19:16] <tomreyn> i think todays' #ubuntu chat can't get much worse, so things can only get better now.
[19:16] <lotuspsychje> lol
[19:17] <lotuspsychje> that promises for 26 tomreyn
[19:17] <tomreyn> lotuspsychje: 26?
[19:17] <lotuspsychje> .1 release
[19:17] <tomreyn> oh right
[19:18] <tomreyn> well, its mostly about the people and their behaviours and abilities (the latter is okay, but can be daunting, too)
[19:19] <sonicwind> it looks like yates left, but he could have installed net-tools to get ifconfig back
[19:20] <tomreyn> yes, but it semed like he should read the release notes first of all.
[19:20] <sonicwind> :-)
[19:20] <tomreyn> s/he/they/
[19:20] <pauljw> no it's not, lotuspsychje.  it keeps my blood pressure under control and prevents me from telling exactly what i think of his whiney attitude.  he should just go back to Windows where he came from.
[19:20] <lotuspsychje> lol
[19:24] <lotuspsychje> ventilate agression to unaware trolls...hmm thats an idea pauljw :p
[19:24] <lotuspsychje> i might finally get rid of my years built frustrations
[19:25] <oerheks> welcome to weekend support .. gna gna
[19:25] <lotuspsychje> haha
[19:26] <ducasse> until we have a way to remotely whack them over the head with a rolled-up newspaper. /ignore is a good tool
[19:26] <pauljw> life's too short to put up with the likes of some of these people.
[19:26] <ducasse> s/./,/
[19:26] <pauljw> :)
[19:27] <lotuspsychje> and when your heads in the sand, you hearing the sound of your suffering volunteer friends
[19:27] <lotuspsychje> helpppp
[19:27]  * sonicwind can't wait to get whacked
[19:28] <pauljw> if you're still helping the likes of that one, you're on your own.
[19:29] <lotuspsychje> :p
[19:31] <pauljw> besides, i didn't notice him looking for help.  just complaining about something he has paid nothing for, to people he's paying nothing to.
[19:33] <ducasse> ...for project he's probably not contributing to
[19:33] <ducasse> *for a
[19:34] <lotuspsychje> yeah its not fair canonical gets payed and we dont :p
[19:35] <lotuspsychje> where's my wonga's
[19:35] <sonicwind> you guys should get something for it...
[19:35] <sonicwind> stickers from the Canonical website or something haha
[19:35] <sonicwind> :-)
[19:35] <lotuspsychje> sonicwind: yes man! my bank number is<PHONE_NUMBER>-87
[19:35] <ducasse> pizza!
[19:36] <sonicwind> pizza
[19:36] <ducasse> :)
[19:37] <lotuspsychje> hmmm thats a new idea, ubuntu pizza's
[19:37] <pauljw> :)
[19:37] <lotuspsychje> with the round logo n all
[19:37] <lotuspsychje> you found a new hole in the market ducasse
[19:37] <ducasse> :)
[19:39] <lotuspsychje> EriC^ uses his mycroft to bake pizza's and bring them to him
[19:53] <sonicwind> cookie for tom
[19:53] <sonicwind> lol
[19:53] <lotuspsychje> we getting nice prices today :p
[19:53] <tomreyn> much better than a cookie!
[19:54] <lotuspsychje> welcome oliver_swift
[19:55] <lotuspsychje> whats up on kdenlive oliver_swift ?
[19:57] <lotuspsychje> welcome CaCO3
[19:57] <oliver_swift> Just brought out an old camera to film a video and used kdenlive to edit, and I just wanted to hear if there were tips from anyone on using it? It'd be cool to start writing extensions for it but I don't know much about it. I heard it's written in python though!
[19:57] <lotuspsychje> never used myself here
[19:58] <oliver_swift> Or some portion in Python, I guess a video editor might be a bit slow if it were all in Python?
[19:58]  * tomreyn neither
[19:58] <EriC^> lotuspsychje: :D
[19:58] <lotuspsychje> :p EriC^
[19:58] <sonicwind> I use Avidemux for video editing lol
[20:01] <lotuspsychje> nite nite all
[20:01] <lotuspsychje> ttyl
[20:01] <sonicwind> nite
[20:10] <sonicwind> tom with the google-fu for another cookie :-)
[20:36] <tomreyn> hope i can make it work, wireless can be tough


[04:50] <FourDollars> Hi, I would like to solve https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1685062. Could you help to review my merge proposal?
[09:30] <bdrung> pitti, hi. how do you detect duplicates? do you just use StacktraceAddressSignature?
[09:38] <pitti> bdrung: the client side uses that, unless a hook set a custom DuplicateSignature:; the server side uses a signature built from the symbolic stack trace, which is usually more reliable
[09:39] <pitti> bdrung: see apport/report.py crash_signature()
[09:45]  * juliank finally remembered to verify the apt SRU for yakkety, and just did it :)
[09:49] <bdrung> pitti, would be nice if apport-retrace would add the crash signature to the crash file
[13:26] <ricotz> infinity, hi, looks like dpkg in artful generates invalid *.changes files, the Files section doesnt list *.buildinfo as in Checsums-*
[13:27] <infinity> ricotz: http://launchpadlibrarian.net/316412144/dpkg_1.18.23ubuntu1_1.18.23ubuntu2.diff.gz
[13:28] <infinity> ricotz: Entirely intentional, as there was a bug in launchpad's handling of buildinfo files on upload.
[13:28] <infinity> ricotz: The feature will be restored in a few days when the LP fix is QAed and deployed.
[13:29] <infinity> ricotz: Though, I'm curious what you mean by "invalid".
[13:29] <infinity> Perhaps you meant "unexpected"? :P
[13:30] <ricotz> infinity, launchpad rejected my upload which looks like https://paste.debian.net/plain/928699 with 1.18.23ubuntu3
[13:30] <ricotz> so Files does not contain buildinfo
[13:31] <infinity> ricotz: Oh.  I didn't check source builds.  Binaries are behaving correctly.  Bother.
[13:32] <infinity> Although.  Huh.
[13:32] <ricotz> yeah, this is a source build
[13:32] <infinity> The testsuite does check source builds.
[13:32] <infinity> And it works correctly.
[13:32] <infinity> ricotz: How did you generate that?
[13:33] <ricotz> with "dpkg-buildpackage -S -sd -d"
[13:38] <infinity> ricotz: Oh, gross.  If you sign with dpkg-buildpackage, it screws up.  If you don't (ie: pass -uc), then it DTRT.
[13:38] <infinity> ricotz: Might fix, or might not care, since I can revert that bit Very Soon anyway.
[13:39] <ricotz> infinity, I would prefer a fix ;)
[13:39] <infinity> ricotz: :P
[13:40] <infinity> ricotz: Quick workaround for now is to build with "-uc -us", and then "debsign foo.changes"
[13:41] <ricotz> hmm, not really applicable here, I want to avoid altering my scripts
[13:41] <ricotz> infinity, what is "Very Soon"?
[13:42]  * ricotz downgraded to the zesty packages already
[13:42] <infinity> ricotz: Early next week at the latest.  Not sure how long it'll take to QA and deploy the LP fix.
[13:42] <ricotz> alright
[13:45] <cjwatson> I'll get it deployed today
[13:45] <cjwatson> Assuming nothing explodes horribly
[13:47] <cjwatson> BTW do we have a new enough debsign that signs buildinfo?
[13:47] <cjwatson> infinity: ^-
[13:53] <infinity> cjwatson: Possibly not.
[13:54] <infinity> cjwatson: Definitely not.  I'll sort that.
[13:55] <infinity> ricotz: http://paste.ubuntu.com/24426912/ might solve your issue for right now.  But looks like we'll be fixing things properly by EOD.
[14:01] <ricotz> infinity, thanks, dropping buildinfo from changes works too ;)
[14:20] <infinity> cjwatson: New devscripts uploaded.
[14:37] <infinity> cjwatson: Well, devscripts uploaded, but it'll be FTBFS until you do your thing to LP and I do my thing to dpkg. :P
[14:40] <cjwatson> Yeah, just QAing stuff in https://dogfood.paddev.net/~cjwatson/+archive/ubuntu/dogfood-buildinfo/+packages now
[14:47] <infinity> cjwatson: Shiny.  I'm going to go find a very large coffee and install it in my face.  Back soon.
[15:10] <mdeslaur> chiluk: FYI, I agree with your comment in the qemu bug, but I saw it too late
[16:05] <nacc> rbasak: fyi, i'm starting up the importer job again, using the snap only :)
[16:24] <rbasak> \o
[16:24] <rbasak> \o/
[17:57] <cjwatson> buildinfo should be fixed on LP production now.
[18:32] <infinity> ricotz: dpkg 1.18.23ubuntu4 should behave correctly now (and LP will accept the uploads, too!)
[18:56] <juliank> slangasek: re bug 1615482 - not sure why we ended up with 6am/6pm +/- 12 hours randomized delay. It's kind of odd. I think there's an IRC backlog for it in #debian-apt, but not looked yet. I suggested some improvements I recently thought about in the bug.
[18:57] <slangasek> juliank: right; long before this code landed in apt upstream, Ubuntu had integrated a carefully designed experience and this has very much regressed
[18:57] <juliank> slangasek: Well no
[18:58] <juliank> slangasek: I mean, we shared the cron job before. mvo replaced that with the systemd timer.
[18:58] <juliank> Because people complained that the apt cron job was delaying other cron jobs by up to 30 mins
[18:58] <slangasek> juliank: shared a cronjob that began in Ubuntu, was merged upstream to Debian, and then regressed without discussion in Ubuntu ;)
[18:59] <juliank> slangasek: Well, mvo switched from the cron job to the timer mostly to fix a ton of bugs in launchpad :D
[18:59] <slangasek> heh
[18:59] <juliank> There was also the funny ones like cron job runs sleep, that sleep process eats to much memory
[19:00] <slangasek> juliank: aiui the move to the systemd timer also loses the anacron support for catching up if the system was offline at the appointed time
[19:00] <juliank> slangasek: No, that's built into systemd (see the Persistent option)
[19:00] <slangasek> s/offline/powered off/
[19:00] <juliank> systemd will retry at resumes and boots
[19:00] <juliank> I think anacron only does boots
[19:01] <slangasek> er, anacron absolutely did on resume also
[19:01] <slangasek> though it's not impossible that *that* regressed as well :P
[19:01] <juliank> Hey, I don't know, I just guessed :D
[19:01] <slangasek> (that may have been a pm-utils integration that got lost in a migration; I don't know if it was lost, just saying it's possible)
[19:02] <juliank> So the idea is to go down from 12 hours of randomized delay to like 30 mins and have the accuracy reduced too
[19:02] <juliank> like 5 minutes or so
[19:03] <slangasek> Persistent=true - cool, that makes sense
[19:03] <slangasek> but AFAICS, on boot this will start before the network is up
[19:03] <slangasek> because timers.target is DefaultDependencies=no
[19:03] <slangasek> whereas cron starts much later (runlevel 2 / multi-user.target)
[19:03] <juliank> slangasek: Yes. We can add an After=network.target. That does not help with resumes, though.
[19:04] <juliank> anacron also delays these catch up events by 5 minutes,  which systemd does not https://github.com/systemd/systemd/issues/5659
[19:04] <juliank> That's a reason why we run twice a day, BTW.
[19:05] <juliank> The script itself checks a stamp file too, so it will only run actual stuff once a day
[19:05] <slangasek> yeah, but running twice a day is a bad workaround
[19:08] <juliank> slangasek: If we find consensus on some better values, then we can probably push that into a 1.4.1 release :) - if Debian RT says it's OK - I'd like to get this improved a few weeks ago, but I forgot about it
[19:09] <juliank> Then we can also SRU that back into yakkety and xenial with another fix pending from 1.4
[19:10] <juliank> (after the current SRUs migrated)
[19:11] <slangasek> juliank: can we agree that being able to assert that timers running on resume can rely on the network being up first is something that systemd should be guaranteeing? (<-- xnox)
[19:11] <juliank> Well, it sort of does with network.target, but that does not really cover non-server use cases
[19:12] <juliank> Like on a laptop with NetworkManager, network.target by default does not wait for you being connected
[19:12] <juliank> And on resumes, the target is considered started already, so no wait at all
[19:13] <juliank> You can work around the resume scenario with this job: https://github.com/julian-klode/dotfiles/blob/master/.config/systemd/user/nm-online-exit.service
[19:14] <juliank> This is like the normal NetworkManager-wait-online.service, but with RemainAfterExit=no instead of RemainAfterExit=yes
[19:14] <slangasek> juliank: you want network-online for this, not network.target
[19:15] <slangasek> it's perfectly appropriate to say "don't try to do apt updates unless you're online"
[19:15] <juliank> Ah makes sense.
[19:15] <slangasek> so that's just After=network-online.target
[19:15] <slangasek> which the network provider will implement
[19:16] <juliank> Yes.
[19:16] <juliank> Only for boots though
[19:16] <slangasek> yes; the resume case is more difficult
[19:16] <juliank> And I think it the NetworkManager one might be disabled by default, not sure
[19:16] <slangasek> but I think that needs to be solved in systemd, *not* in this uint
[19:16] <slangasek> unit
[19:17] <juliank> slangasek: Sure. We need a target that shuts down when there is no network. And then we can bind network needing jobs to that
[19:17] <juliank> So, after a resume, the target comes back once the network is up again, and then network-needing units get started again
[19:23] <juliank> slangasek: OK, so that seems to be the right thing to do: https://github.com/Debian/apt/compare/master...julian-klode:lp1615482?expand=1
[19:24] <juliank> After + Wants on network-online.target
[19:25] <juliank> We can also start it After=multi-user.target to get some more delay during boot to fix "slow" boots
[19:25] <slangasek> juliank: fwiw I don't see any reason to use a non-default value for AccuracySec vs. the default of 1m
[19:25] <juliank> "slow" = 5 second slower on an HDD machine...
[19:26] <slangasek> juliank: yeah, I responded to that comment on the bug log - as far as I'm concerned "my boot is slower because my machine has to check for critical security updates" should be wontfix
[19:26] <juliank> slangasek: It's just that we don't really need that kind of accuracy, so we decided back than to just be generous and allow it to merge with any hourly cron job in the near time
[19:27] <ricotz> infinity, works, thanks!
[19:27] <juliank> manual page says: "To optimize power consumption, make sure to set this value as high as possible and as low as necessary."
[19:28] <juliank> But 5m vs 1m does not make a huge diff
[19:28] <slangasek> juliank: we don't want millions of Ubuntu machines to all wake up on exactly the 5 minute mark and hit the mirrors
[19:29] <juliank> Well sure, with a 30m randomize, 1m probably makes sense.
[19:29] <juliank> I think we can calculate this out, how many machines on average would update at the same time
[19:30] <slangasek> my point is we want it smoothed as much as possible over the interval, and this swamps any benefit of reducing wakeups... especially when we're talking about a single wakeup per day per machine
[19:31] <juliank> Assuming an update takes about 1m, with 30m random delay, we would have N/30 machines hitting at the same time (or well, more like N/60, as the job runs twice a day)
[19:31] <slangasek> (the fine controls of the systemd timer design are useful, just not for this)
[19:31] <juliank> That's like it was before, basically, just running at 6/18 instead of 0.
[19:32] <juliank> (I think cron ran at midnight, right?)
[19:32] <slangasek> no
[19:32] <slangasek> this was *always* in the 6am-7am window
[19:32] <slangasek> 25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
[19:32] <juliank> Ah, OK, great
[19:33] <slangasek> and, I do think the 2x-daily frequency needs to be dropped back down to 1x
[19:33] <sarnold> I suspect even 30m smearing isn't 'enough' -- our network always gets saturated start of every europe work day, heh
[19:34] <slangasek> sarnold: there are some hotspots based on population centers, but that part is a conscious tradeoff
[19:34] <juliank> slangasek: I think that needs some more digging in the backlog and possibly interrogating mvo to figure out why we have 2 tries at all
[19:34] <sarnold> slangasek: heh, I guess i'm only ever awake for the one hotspot then :)
[19:35] <drab> hi, anybody familiar with the process of starting ssh in a chroot from an ubuntu-install?
[19:35] <slangasek> sarnold: I think you can ask IS for graphs that show the big EU peak, followed by two smaller US-East/US-West peaks
[19:36] <drab> I'm trying to automate one last step that requires ssh install, but starting ssh from late-command fails
[19:36] <slangasek> drab: basically unsupported
[19:36] <drab> so preseed does its job, fires off late-command which creates a user, installs a pub key part and then tries to start ssh
[19:37] <slangasek> you could start the daemon manually, but you can't start services via systemd units inside of a chroot
[19:37] <slangasek> (and certainly not within d-i, which does not run systemd as init AFAIR)
[19:37] <juliank> slangasek: Another fancy alternative would be to have unattended-upgrades drop in some overrides to tighten things up, but have apt run randomly during the day if u-u is not installed
[19:37] <drab> slangasek: yeah, so I tried to just run /usr/sbin/sshd
[19:37] <slangasek> juliank: I disagree that this behavior should be tied to unattended-upgrades
[19:37] <drab> and in fact, it also works if I do /etc/init.d/ssh start
[19:38] <drab> but it doesn't work if I do it from the late-command
[19:38] <drab> or rather
[19:38] <juliank> Well, the other stuff (running update and maybe clean up) is not that hurtful, it could have more flexibility than running an upgrade
[19:38] <drab> if I run /usr/sbin/sshd it actually runs, process is there, but ssh in fails
[19:38] <juliank> Probably not as much as now, but still
[19:38] <drab> slangasek: complaining that /var/run/sshd does not exist even tho I just mkdir'ed it
[19:39] <drab> so I'm really confused because if I do it manually it works, but if I do it from the script it doesn't
[19:39] <drab> and I don't see the difference
[19:39] <drab> especially for something as simple as mkdir, which btw works to create stuff in the homedir of the user I create
[19:39] <slangasek> juliank: I have in fact had an apt update in the middle of the day on my laptop disrupt my work when it was *not* installing any packages, just because of the memory usage of all of the bits involved with updating indices
[19:40] <slangasek> juliank: that was what prompted my comment on the bug back in March
[19:40] <slangasek> (the apt indices themselves are probably fine, but then there are supplementary things like apt-xapian-index and appstream(?))
[19:43] <juliank> yep
[19:45] <juliank> slangasek: I think the reason not to do 1800 is that the admins go home at that point, rather than arrive at work around that time, so it takes longer to fix breakage?
[19:48] <slangasek> juliank: for my part, the reason not to do 1800 is that I'm still using my computer at 1800 ;)
[19:49] <juliank> slangasek: That makes sense too
[19:50] <juliank> slangasek: I hope mvo is around next week, he has insight
[19:50] <juliank> Unless it was pitti's idea to run twice a day
[19:55] <juliank> slangasek: sarnold: If 30 minutes turns out to be a bit low, it might make sense to just go to 5:30 with a 1 hour random delay
[19:56] <juliank> That's basically 6:00 +/- 30 minutes then
[19:56] <sarnold> I like the sound of that
[19:59] <juliank> The imaginary queue for the next SRUs has https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2ce15bdeac6ee93faefd4b42b57f035bef80c567 and https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=5094697fe4b2459ff6f706a22006d3028369f3fa for now basically
[20:00] <juliank> + the timer change would make a nice short SRU :D
[20:02] <juliank> (The config change is only needed for yakkety)
[20:03] <juliank> (that is, the "Fix and avoid quoting in CommandLine::AsString")
[20:11] <juliank> It will be really fun to see how many stable apt series I can maintain longer term. 2 works OK, soon it's 3 for a few months.
[20:12] <juliank> I think I have a sheet somewhere
[20:12] <juliank> Yeah at https://docs.google.com/spreadsheets/d/12C3rcJBYc3tUHYUVOW_6Z_mqGqmFmGh4kV921ClbiJs/edit?usp=sharing
[20:14] <juliank> Well, I also do security updates and on-demand critical bug fixing for 1.0.9.something in addition to the 1.2 and 1.3 stable series.
[20:18] <juliank> I'd be happy to hear some more opinions on how the 1.2 and 1.3 series went so far. I know I sometimes waited too long between updates, causing a larger amount of fixes to accumulate, but if there's anything else to improve, let me know.
[21:47] <infinity> juliank: I've had no complaints about the stable series' in general.  Given we used to have pretty much 0 apt updates except for security and when we encountered a world-ending critical, it can't get worse. :P
[21:48] <infinity> juliank: If you're worried about signing up for too much work there, though, you might want to dial back the knob for what you consider a critical enough bug to warrant a cherry-pick, especially for non-LTS/non-Debian-stable release branches.
[21:56] <rbasak> While we're talking about apt, nacc and I have a feature request. "apt-cache bin2src". Trivial enough I think, or would apt-cache be the wrong place?
[21:56] <infinity> grep-dctrl?
[21:57] <infinity> rbasak: I assume you mean "tell me this binary's source"?
[21:57] <rbasak> Right, like chdist does it.
[21:57] <juliank> infinity: I think the load is OK on my side. It will mostly be interesting to see how the cherry-picking scales :)
[21:57] <rbasak> I appreciate that other tools exist, and I can easily use them.
[21:58] <rbasak> But for new contributors, it seems like a simple enough question that should have a one command answer, instead of having to look up Packages files or set up other tooling.
[21:59] <rbasak> As for grep-dctrl, it also needs a "well, if there's a Source header, then it's that, otherwise it's the same as the binary name" logic that isn't present there.
[21:59] <juliank> rbasak: more source based stuff will come with the next ABI break. I want to add Source fields into the cache
[21:59] <juliank> or rather, a source hash table.
[21:59] <juliank> Although, that does not really help here as it's Src -> Binary
[22:00] <juliank> we already have the information for Binary -> Source, I wasn't sure of tha
[22:00] <rbasak> Thanks. Just thought I'd mention it as it came up in a conversation just now, and I saw you were here :)
[22:01] <cjwatson> It *is* actually in grep-dctrl (-XFSource:Package), but I agree it would be useful to have a simple way to query the apt cache for it
[22:01] <juliank> rbasak: I'm always here. If I'm not actually connected to my ZNC, it's supposed to send me a push message if someone highlights me, but that seems broken right now.
[22:01] <rbasak> Oh, you can do that? Useful to know, thanks.
[22:01] <juliank> :D
[22:01] <cjwatson> If only because grep-dctrl often isn't installed in the sort of minimal contexts I want this
[22:02] <infinity> To be fair, just adding "Source" to every binary stanza, even when it's identical to Package, would clear up a lot of confusion.  People's concerns about their 2400 baud modems likely shouldn't trump useful data in 2017.
[22:02] <infinity> I get why it was deemed redundant data, but people have been confused about it since 1999.
[22:03] <juliank> well it's just ${source:-$package}
[22:03] <juliank> after you read both source and package fields into variables (in shell syntax)
[22:03] <infinity> juliank: Sure.  The people discussing this know that.
[22:03] <infinity> juliank: People new to it don't seem to find it so obvious. ;)
[22:03] <nacc> and we want it for the case of a drive-by developer who wants to help provide a fix for a binary package and may not necessarily realize the distinction -- or know about the mapping and we'd like like to do something like "We couldn't find that source package, but did find a binary package with that name, that is built from this source package. Maybe you meant that one."
[22:04] <infinity> "Why do some binary packages not have a Source field?"
[22:04] <juliank> We should synthesize the field in apt show output
[22:04] <nacc> we can just wrap grep-dctrl for this case in the meanwhile :)
[22:04] <infinity> nacc: Well, apt-get source does that.
[22:04] <nacc> infinity: good point! :)
[22:04] <juliank> That makes the automatic lookup easier.
[22:05] <infinity> juliank: Right, that's do it.  No need to have it on the disk or wire, if you can synthesize it at lookup time.
[22:05] <infinity> s/that's/that'd/
[22:06] <infinity> I don't think complicated tooling is needed when we *should* be encouraging people to read and understand "apt-cache show", but that one tiny change would be a large quality of life improvement for first-timers.
[22:06] <infinity> And even for people attempting to do quick shell loops.
[22:08] <infinity> Well, look at that, proposed-migration works.
[22:08] <infinity> And autopkgtests are autopkgtesting.
[22:09] <infinity> Will wonders never cease.
[22:09] <infinity> juliank: SPEAKING OF...
[22:09] <infinity> juliank: I *still* have a hint in place for test-apt-download-progress sucking.
[22:10] <infinity> juliank: I feel like the time you've wasted on that test could have been better applied to perhaps several more graduate degrees or perhaps starting a few families around the world.
[22:13] <juliank> infinity: that is an odd test for sure
[22:13] <infinity> "odd" is probably not the adjective I'd choose.
[22:14] <juliank> Yay, push notifications work again
[22:15] <juliank> infinity: There actually is of course a somewhat fix for that: Throttling in the web server.
[22:16] <juliank> But that's a situation where unit tests would be much nicer
[22:16] <juliank> The test was to check that One method was called when downloading stuff
[22:17] <juliank> Speaking of autopkgtests, the failures in reverse deps for the 1.3.5 and 1.2.19 SRUs are the usual unrelated ones.
[22:18] <infinity> juliank: But it is entertaining that autopkgtest fails its autopkgtests.
[22:18] <juliank> Yes, it sure is.
[22:19] <juliank> The fix is probably simple but I never bothered looking at it.
[22:19] <juliank> The autopkgtest autopkgtests fail as soon as the next development cycle has started
[22:21] <juliank> infinity: I feel like that always delays the SRUs a bit
[22:21] <infinity> Yeah, it does.
[22:21] <infinity> I investigated the sbuild "regression", and that looks like a simple enough fix.
[22:21] <infinity> The autopkgtest one, I'm not as intimately familiar with.
[22:23]  * infinity scratches his head at britney's logs...
[22:23] <infinity> I: [Fri Apr 21 22:16:14 2017] - gcc-4.7-arm-linux-gnueabihf on s390x has no source (NBS?)
[22:23] <infinity> I mean, sure, it has no source.  But it also has no binary.  So what are you on about?
[22:24] <juliank> The current SRU got a bit weird because 1.2 entered proposed a week before 1.3 and was verified quickly, but then nothing happened when 1.3 was accepted, because I was busy doing Android development
[22:24] <juliank> infinity: lol
[22:27] <juliank> Android community is a lot more different and more engaged than anything I've seen before
[22:28] <infinity> Young communities usually have a very different feel.
[22:28] <infinity> Not enough grumpy old guys like me (or just the right number).
[22:28] <juliank> But the engagment is mostly testing and feature requests, not code contributions.
[22:44] <juliank> Will aptdaemon go away this cycle?
[22:45] <juliank> or rather, is someone trying to make it go away?
[22:47] <juliank> it's like vampire code or something
[22:47] <infinity> juliank: I think people wanted it to die, but I'm not entirely clear on what one replaces it with.
[22:48] <juliank> Well, drop sessioninstaller, switch g-s to packagekit, live with the reboot-to-upgrade nonsense, and call it a day?
[22:48] <infinity> juliank: update-notifier and update-manager are the two interesting ones I see.
[22:48] <jbicha> bug 1673258 bug 1643134
[22:50] <jbicha> juliank: I expect the reboot-to-upgrade feature could be patched out but there are other concerns about switching GNOME Software to PK
[22:50] <juliank> Honestly, I'd basically just kill update-notifier and update-manager, and just have a special tool for release upgrades.
[22:51] <jbicha> I like the idea of switching it to PK but apparently it's slower for some use cases
[22:51] <juliank> (Not sure if there was anything else in there that's really needed, have not looked at that in a long time)
[22:52] <juliank> jbicha: Well, yes, it's likely slower, but at least it's more maintained than just kept barely alive :)
[22:52] <jbicha> and the Ubuntu Desktop team is somewhat risk-averse so they would rather not knowingly introduce regressions if they can avoid it
[22:52] <infinity> juliank: update-manager is pretty iconic part of the Ubuntu experience, IMO.  gnome-software is super clunky in comparison.
[22:52] <jbicha> juliank: you're welcome to bring up the topic on the ~ubuntu-desktop list or wherever
[22:58] <juliank> infinity: I'm not a huge fan of gnome-software either. But I'm not sure it's worth it to fight it. There's also something to gain by potentially having one software center like thing where you can schedule/do upgrades for all kind of formats (not sure if snap backend exists yet, does it?)
[22:59] <juliank> I only ever used gnome-software to update flatpaks, though
[22:59] <jbicha> juliank: if you have questions about gnome-software in Ubuntu, you should talk to Lan_ey or robert_ancell
[22:59] <juliank> sure. Or I could look it up myself :)
[23:01] <jbicha> well I mean to say that Ubuntu's Desktop Team is putting work into integrating g-s into Ubuntu but it's a big project
[23:01] <juliank> I know
[23:02] <infinity> juliank: snaps upgrade without human intervention.
[23:03] <juliank> infinity: oh yes, right. otherwise my "server" laptop would have had issues ...
[23:04] <infinity> But aside from the update-manager UI being about 1000 times better, I also have no idea what an "apt upgrade via packagekit" actually looks like.
[23:04] <infinity> Does it abide by the same resolver constraints we carefully chose in update-manager?  Can it be made to?
[23:04] <juliank> infinity: I only know the UX: It's click, it reboots, applies updates, and then boots to the system.
[23:05] <infinity> Uhm.  Ew.
[23:05] <juliank> I know, it takes some time to get used to that.
[23:05] <infinity> Even Windows doesn't force me to reboot for most updates anymore.
[23:05] <infinity> That feels like a step rather far backward for apt/dpkg systems.
[23:05] <juliank> I don't use it, but I do almost always reboot after an upgrade
[23:06] <infinity> I've decided I need to go eat a whole pizza and wallow in software-induced depression.
[23:06] <juliank> because library changed and were loaded, or kernel changed, or well, just to see if the machine still boots
[23:07] <infinity> juliank: If we did a "patch Tuesday" thing like Microsoft, that might be acceptable.  Given that we push SRUs daily, however, and you may well get one a day, it's pretty much a non-starter to suggest that users be forced to reboot when it's not necessary.
[23:07] <jbicha> I think that feature was driven by Fedora where maybe upgrade problems are more common? I don't really know enough about rpm/yum/dnf
[23:08] <juliank> jbicha: basically *Everything* is driven by Fedora :D
[23:08] <infinity> rpm, in theory, is about as error-prone (or not) as dpkg.  RPM distros (especially Fedora) have historically lacked the policy and general anal retention of the Debian community that insisted on smooth upgrades.
[23:09] <jbicha> lol
[23:09] <infinity> Honestly, most Debian people consider it a bug if you're doing a release upgrade and you can't keep working through it.
[23:10] <infinity> Me, I think our release upgrader should actually bounce you to a minimal session.
[23:10] <infinity> But taking that logic to daily updates is not sane, IMO.
[23:11] <juliank> infinity: You have to see it like this: If an update gets pushed that breaks boots, you'll immediately notice it! :D
[23:11] <jbicha> yeah, the Unity>GNOME upgrade in particular would be nice to do offline
[23:11] <sarnold> heh, I once upgraded a machine to oldstable, then stable, then unstable, all in one go, and it didn't disrupt the machine's use. (minimal at the time, but still.)
[23:12] <juliank> I fail quite spectacularly at Debian upgrades. Hit Ctrl+C at the wrong moment, dpkg gets interrupted, and I play half an hour with --force and --unpack and -i options recovering from my mess.
[23:12] <jbicha> infinity: you should try the GNOME Software offline upgrade feature in like Fedora 25 or Debian stretch, I believe it uses systemd to apply the upgrade
[23:13] <infinity> juliank: Have you considered not doing that?
[23:13] <juliank> But it's probably still smoother than a Windows update.
[23:13] <jbicha> it might be something we would be interested in for release upgrades
[23:13] <sarnold> juliank: you like living on the edge :D
[23:14] <juliank> infinity: It's not that bad. Last time I just run dpkg --unpack --recursive /var/cache/apt/archives a few times, and then the system was OK enough for apt to function again and calculate the rest.
[23:14] <infinity> jbicha: Of course it does.  If systemd isn't involved (and if we can't make up more excuses for jamming it in the initrd while we're at it), it's not modern Linux, right?
[23:14] <infinity> juliank: Still, not interrupting it sounds like it would be a better option. :P
[23:14]  * infinity -> pizza.
[23:15] <juliank> infinity: true. but it's like "oh, it's still reading package lists for a huge upgrade and I just noticed something I missed"
[23:15] <Unit193> infinity: What type?
[23:15] <juliank> a round one?
[23:15] <Unit193> Square ones are rather sub-par, yes.
[23:16]  * Unit193 waves to juliank.
[23:17]  * juliank does not eat much pizza. And most people might not even consider something without cheese and only vegatables on top of it a pizza.
[23:18] <sarnold> at that point it's just vegetables on flat bread
[23:18] <sarnold> might be alright as it goes but i'm not sure you still get to call it pizza ;)
[23:18] <juliank> sarnold: I think the core point of the pizza is the bread, and just a drop of vegetables for fun.
[23:19] <Unit193> What about "white" pizzas?  White chicken, ranch, etc?
[23:19] <jbicha> juliank: if you add a piece of bread on top, that sounds like a sandwich to me
[23:21] <juliank> Pizza is basically just Focaccia with stuff on top that's baked with it
[23:22]  * juliank should visit his pizza baker tomorrow
[23:23] <juliank> they speak Italian
[23:24] <juliank> or maybe they just pretend, I can't tell :D
[23:24] <sarnold> it's all in the hands anyway, right? :)
[23:25] <Unit193> sarnold: There's a place here that bakes them in a stone/wood oven, I hear that's sooo much better.
[23:25] <sarnold> Unit193: that's almost always a good sign
[23:25] <tsimonq2> I think it's annoying that my mom cuts pizzas into squares sometimes...
[23:25] <juliank> You basically need like 500C to bake pizza
[23:25] <tsimonq2> It just bugs me because someone has to get the corner pieces
[23:26] <juliank> and then bake at something like 60 to 90 seconds
[23:26] <tsimonq2> With triangle pizza, you have to share it :P
[23:27] <juliank> Let's make Ubuntu pizza
[23:27] <juliank> the logo should work fine as a pizza


[17:14] <R_P_S> hey, so I've got a cluster that I created a few days ago with juju, and now all juju commands are simply hanging.  I thought maybe I got auto logged out?  (using admin user).  But every juju command I've tried just hangs
[17:15] <R_P_S> juju had created a k8s cluster, and kubectl appears to be working, but juju is completely non-responsive
[18:07] <jamesbenson> how do you issue the post-processing steps?
[18:25] <jamesbenson> for k8s conjure-up
[18:35] <R_P_S> that is so weird... so juju was hanging for any commands including status for hours there... but it's suddenly come back.
[18:36] <R_P_S> I'm not sure I like the juju command being randomly unavailable for hours on end.  Any idea how I would troubleshoot this?  the juju client literally just hung for hours with any command until I noticed it started working again
[18:43] <rick_h> juju show in just over 15!!!!!!
[18:54] <rick_h> https://www.youtube.com/watch?v=Kq1sgJs9miU for those that want to watch the stream
[18:55] <rick_h> https://hangouts.google.com/hangouts/_/xgsuvuvuyrcpnk3hkqgz4u7opee for those that want to hop in and chat
[20:07] <R_P_S> I'm trying to setup one of my coworkers on my conjure-up juju cluster.  ME: juju add-user <username>, juju grant superuser  HIM: juju register <stuff>, juju switch <controller>, juju add-ssh-key "$(cat ~/.local/share/juju/ssh/juju_id_rsa.pub)", juju ssh kubernetes-master/0   ERROR permissions denied (unauthorized access)
[20:08] <bdx> R_P_S: `juju grant <username> admin|read|write <model-name>`
[20:09] <bdx> `juju grant superuser` grants controller acls
[20:09] <R_P_S> superuser doesn't have model access?
[20:09] <bdx> R_P_S: superuser is a role
[20:09] <R_P_S> if he's superuser, could he technically grant himself model acess?
[20:09] <bdx> nah
[20:09] <bdx> you would think
[20:10] <bdx> superuser is just controller level
[20:10] <bdx> admin|read|write are model level
[20:10] <R_P_S> so if you create a new model, the admin user has to go in and grant admin access to the new model to each user already in the system?
[20:10] <bdx> yeah
[20:11] <bdx> because the users aren't added to the model
[20:11] <bdx> they just exist at the controller level
[20:11] <bdx> so you must explicitly grant them the access level you want them to have as the model owner or as a model admin
[20:12] <R_P_S> ah, I just listed model users
[20:14] <R_P_S> I was watching the auth.log, and my coworker wasn't even hitting it... so something definitely felt off.  In other news, I got to watch all the attack attempts because ssh was given <IP_ADDRESS>/0 ingress ACLs >.>
[20:36] <R_P_S> So I'm running through a quick demo with my coworker on what should be a vanilla conjure-up cluster
[20:36] <R_P_S> https://kubernetes.io/docs/tasks/access-application-cluster/load-balance-access-application-cluster/
[20:36] <R_P_S> and we get to step 4 - exposing the service... and the external-ip gets stuck at <pending>
[20:37] <R_P_S> the tutorial talks about a "minikube" getting stuck at pending, but doesn't provide any reasoning as to why this happens
[20:39] <R_P_S> so despite being "exposed" there's no actual external access since it's only available via IPs that are tied to the flannel networking layer
[20:46] <bdx> R_P_S: is that subnet its deployed to configured to auto assign public ips?
[20:46] <bdx> and also using the igw and correct routing table(s)?
[20:46] <R_P_S> well, it's in ec2-classic... the vanilla install doesn't even stick it into a VPC
[20:47] <bdx> so its deployed in a vpc, or in default ec2-classic?
[20:48] <R_P_S> ec2-classic
[20:48] <R_P_S> which is always assign public IP by default
[20:49] <R_P_S> each of these instances do have public IPs, and juju status shows each instance with their actual public IP
[20:58] <R_P_S> and as for ec2-classic... the concept of igw and routing tables are completely hidden.
[21:09] <elmaciej> Hi! Just want to ask - do you have guys any bundle for openstack without ceph or I have to make it manually from charms
[22:15] <R_P_S> What are the S3 buckets used for when you select helm in a conjure-up?  I just realized that the IAM credentials I provided was never given S3 access... but it never at any point stated there was a failure since the conjure-up succeeded.
[22:16] <R_P_S> so of course the buckets don't exist... do I need to rebuild the entire cluster?  or can I just modify the IAM policy now and the system will pickup and get into the state it's expected?
[22:37] <stokachu> R_P_S: https://docs.ubuntu.com/conjure-up/2.4.0/en/cni/k8s-and-aws
[22:41] <R_P_S> stokachu: that page pretty much mirrors the link I was following: https://kubernetes.io/docs/tasks/access-application-cluster/load-balance-access-application-cluster/ except that it actually talks about what happens in AWS
[22:42] <stokachu> Heh ok
[22:43] <R_P_S> but no ELB was ever created.  My policies are "effect allow, action elasticloadbalancing:*, resource *" and "effect allow, action ec2:*, resource *"
[22:43] <R_P_S> that's cool that it's supposed to make an ELB... but it's strange that no ELB was ever created :(
[22:44] <stokachu> Well the docs state where to look for the error logs
[22:45] <stokachu> So that's probably where I would start
[22:46] <R_P_S> hrmm... I don't have any permissions for EBS... but I see the hint for checking logs on kubernetes master at the bottom of your page
[22:50] <R_P_S> EBS should be contained within EC2:* though... I'll have to check that... but that shouldn't be blocking anything now anyways since I'm not doing anything with volumes yet
[22:51] <R_P_S> yup create volume and attach volume are covered by ec2:*
[23:08] <R_P_S> weird, not found anything in the logs... but in ~/.cache/conjure-up/canonical-kubernetes/steps/04_enable-cni/ec2, there's a pair of files call policy-master and policy-worker that specify a pile of access including ec2, elasticloadbalancing, route53, s3 etc
[23:08] <R_P_S> hum... it looks like conjure-up needs to make aws roles?  It sure doens't have any permissions to do that...