[07:20] <lordievader> Good moning
[08:49] <tumbleweed> xenial amd64 images seem to be missing in AWS us-east-1: curl -s https://cloud-images.ubuntu.com/query/xenial/server/released.current.txt | grep 'amd64.*us-east'
[08:49] <tumbleweed> (vs bionic)
[09:14] <tumbleweed> filed https://bugs.launchpad.net/cloud-images/+bug/1808304
[10:03] <tobias-urdin> coreycb: in cloud-archive bionic-updates/stein the aodh-api seems to not be dropping the apache config but postinst tries to a2ensite it
[10:14] <tobias-urdin> coreycb: nvm, is probably my fault when puppet purges all configs :)
[10:35] <tobias-urdin> coreycb: might need to bump python3-eventlet to > 0.21, upper-constraints says 0.24.1 is max, eventlet https is broken so for example glance running under https fails
[10:38] <tobias-urdin> coreycb: seems like fedora bumped that to python3-eventlet to 0.24 for stein python3, i'm in pto tomorrow but maybe you could look into it
[10:38] <tobias-urdin> let me know if you want a bug report to track it
[10:41] <tobias-urdin> got info that https glance might not even work with eventlet 0.24 either, so maybe it doesn't matter, guess we'll have to disable glance https for now
[10:45] <kstenerud> Has anyone ever had the situation where a freshly checked out repo has unstaged changes?
[10:50] <tobias-urdin> coreycb: quoting a RDO packager "some issues are fixed in 0.24"
[10:54] <ahasenack> good morning
[11:29] <hays> cant figure out on this system why 127.0.0.1 is somehow getting to another machine on the network
[11:29] <hays> tcpdump filtered by port doesn't show it leaving any interfaces, but I see it on the receiving end--i think on lo of all place
[11:30] <hays> no ssh clients running (no tunnels i don't think)
[11:30] <hays> iptables-save is blank, ufw is disabled
[11:31] <hays> im pretty stumped
[11:41] <peetaur2> hays: try nethogs and then send lots of data there to make it come up in nethogs
[11:43] <tomreyn> hays: what are the facts you have so far about "127.0.0.1 is somehow getting to another machine on the network"?
[11:44] <hays> tomreyn: both the machines are running a process that returns a GUID through a REST API
[11:44] <hays> On machine 1 I can connect to that API on localhost and get the GUID for machine 2, but if I give the actual IP address of the machine, I get machine 1
[11:45] <hays> localhost, 127.0.0.1, 127.0.1.1, ::1 all go to machine 2
[11:47] <tomreyn> you connect (API consumer) using CLI utilities or web browsers?
[11:48] <hays> it is a library called python requests
[11:48] <bipul> How would i know my cloud init is diabled or not?
[11:48] <bipul> I tried with echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg , but failed to do so..
[11:50] <hays> tomreyn: i have a script that uses the python requests API
[11:50] <hays> ive used it before, its pretty well tested
[11:54] <tomreyn> hays: i see. if you can make the API log its responses, too, add the source of the information (hostname), maybe this will help. i'm puzzled, too. i'd say check arp tables (ip neigh), make sure the MAC addresses point to the right systems and check both systems' routing tables (ip route).
[11:56] <tomreyn> my guess is on a caching issue due to an earlier (since resolved) misconfiguration on node 1.
[11:56] <hays> ill keep digging.  i didnt see anything obvious with ip route or arp, but i honestly dont know exactly how to decode some of the more obscure routes, e.g., ip route show table lo
[11:58] <hays> oddly, i've seen something eerily similar to this on another machine, but for some reason it was only ipv4
[11:59] <hays> never figured out root cause
[11:59] <tomreyn> there should be no table for lo in the first place.
[11:59] <hays> that was a fedora box
[12:00] <hays> tomreyn: try typing ip route show table local
[12:01] <hays> this is the table i am not sure i understand
[12:02] <hays> i think ip route show filters out some routes from display normally
[12:07] <tomreyn> hays: as ip-route(8) explains, this will show the destinations assigned to the this very system. Packets addressed to these IP addresses, when handled by the systems' routing code (kernel), are looped back and delivered locally.
[14:37] <muhaha> Anyone has experinece with SCEP and certmonger?
[19:06] <kinghat> does livepatch work on ubuntu server?
[19:06] <nacc> kinghat: yes, it'
[19:07] <nacc> kinghat: yes, it's about the kernel, not the installation type, afaik
[19:07] <kinghat> ah
[19:07] <kinghat> how do you feel about snaps on server?
[19:08] <nacc> kinghat: if you need an app that is packaged as a snap, then use it. Dunno what you mean, exactly, kinghat
[19:08] <kinghat> sudo snap install canonical-livepatch
[19:08] <kinghat> i thought there was contention around using snaps. especially with security.
[19:09] <lordcirth_> There are a number of snaps that really should just be deb packages.  But they have their uses.
[19:09] <lordcirth_> The problem is when people bundle their apps in a snap with the version of libraries they developed with, and then never update it.  And then your app is running with openssl way out of date.
[19:12] <nacc> lordcirth_: the store automatically scans for stuff like that, fwiw
[19:12] <nacc> and emails the owners
[19:13] <lordcirth_> Ah, that's good
[19:13] <nacc> citing "some...contention" is really not a way to discuss it
[19:14] <nacc> specific issues would be good, otherwise, do some research
[21:17] <teward> anyone got the bug about how LVM sets up only a 4GB LV inside the PV and doesn't autoset it to expand with subiquity?
[21:17] <teward> I forget the exact bug number
[21:20] <powersj> teward, https://bugs.launchpad.net/subiquity/+bug/1785321
[21:28] <teward> powersj: thank you kindly.
[21:28] <ahasenack> teward: you just remembered the approximate bug number? :)
[21:28] <ahasenack> starts with 1? :)
[21:28] <teward> ahasenack: lol.
[21:28] <teward> ahasenack: that's 90% of the bugs I work with xD
[21:28] <ahasenack> wonder when we will reach 2
[21:28] <teward> i have a few that start with 9 but :P
[21:29] <ahasenack> yeah, precious old bugs