[00:44] <nacc> powersj: rbasak: dpb1: nice! https://jenkins.ubuntu.com/server/job/git-ubuntu-ci-redux/8/consoleFull
[00:44] <nacc> git-ubuntu self-test in a snap
[00:44] <powersj> sweet!
[00:44] <powersj> nacc: plan for landing that?
[00:44] <nacc> rbasak: i'm rebasing the scripts into snap branch as well, and seeing if that works as well, and if so, then i'll update that MP
[00:45] <nacc> powersj: needs rbasak reveiew
[00:45] <powersj> ok
[00:48] <nacc> powersj: as i needed to do some functional changes to get the test to pass in the snap
[03:05] <madLyfe> any of you guys use IPMI?
[03:17] <dpb1> madLyfe: yes, most people here. :)
[03:29] <madLyfe> dpb1: so on my SM board i have two lan ports and an IPMI lan port. i am plugged into the red arrow and the blue is the IPMI port
[03:29] <madLyfe> https://files.slack.com/files-tmb/T8SG054AW-F9DGHLH6Z-5b089ba703/image_1024.png
[03:29] <sarnold> "You need to sign in to see this page"
[03:30] <jlacroix> My understanding is that Subiquity will be the new installer for Ubuntu Server. Any knowledge as far as when this will hit the dailys? I'm writing a book on Ubuntu Server so I want to make sure I cover the new installer properly and have a chance to test it out before the chapter is written
[03:30] <madLyfe> https://usercontent.irccloud-cdn.com/file/8CJCsybx/image.png
[03:31] <madLyfe> IPMI in the bios is DHCP and shows up in my router table. i can also connect to the IPMI using IPMI View software from SM. thing is im not even connected to that port?
[03:32] <sarnold> madLyfe: if you don't use the ipmi port, supermicro shoves ipmi and so on through the 'main' NICs..
[03:33] <madLyfe> is there a situation where i should be using it rather than it being pushed?
[03:35] <sarnold> madLyfe: in larger sites, the IPMI ports are usually on their own network, or on their own VLAN, as the case may be
[03:36] <sarnold> madLyfe: normally people assume the security on the IPMI port is crap
[03:36] <sarnold> and firewall those things to make sure they're hard to get to
[03:36] <madLyfe> ah that makes sense. tyvm.
[03:36] <sarnold> https://www.cvedetails.com/vulnerability-list/vendor_id-12753/year-2013/Supermicro.html
[03:47] <dpb1> jlacroix: it's there now... http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/
[03:47] <dpb1> jlacroix: 'bionic-live-server-amd64'
[03:50] <dpb1> jlacroix: FYI http://blog.dustinkirkland.com/2018/02/rfc-new-ubuntu-1804-lts-server-installer.html
[03:51] <jlacroix> Thanks, I am downloading now
[03:52] <jlacroix> So between bionic-server-amd64.iso and bionic-live-server-amd64.iso, is the latter going to replace the former, or will they both be available?
[04:19] <dpb1> jlacroix: live is the "new installer" one, it will be the default link on the download page come 18.04.
[04:19] <papajo> hello everyone
[04:19] <jlacroix> Thanks, that answers my questions
[04:20] <dpb1> jlacroix: the other one will stick around and is the "old installer", and will be referenced as "advanced" or something like that.  but the names of the images you are reading in the directory listing is likely final
[06:31] <cpaelzer> good morning
[06:54] <lordievader> Good morning
[06:56] <cpaelzer> hi lordievader, how are you today?
[06:56] <lordievader> I'm doing allright, how are you?
[06:57] <cpaelzer> waiting for Saturday :-)
[06:57] <lordievader> That is what Fridays are for, right?
[06:58] <cpaelzer> yes, to some extend this pattern repeats :-)
=== Bartuk is now known as p4501fr
=== Beret- is now known as Beret
[08:27] <gosslauok> _  _     _  _   _ _
[08:27] <gosslauok> _  _     _  _   _ _
[08:27] <gosslauok> _  _     _  _   _ _
[08:27] <gosslauok> _  _     _  _   _ _
[08:27] <gosslauok> _  _     _  _   _ _
[08:27] <gosslauok> _  _     _  _   _ _
[08:27] <gosslauok> _| || |_ _| || |_| | |
[08:27] <gosslauok> _| || |_ _| || |_| | |
[08:27] <gosslauok> _| || |_ _| || |_| | |
[08:27] <gosslauok> _| || |_ _| || |_| | |
[08:27] <gosslauok> _| || |_ _| || |_| | |
[08:27] <gosslauok> _| || |_ _| || |_| | |
[08:27] <gosslauok> |_  __  _|_  __  _| | | __ _ _ __ ___   __ _ ___
[08:27] <gosslauok> |_  __  _|_  __  _| | | __ _ _ __ ___   __ _ ___
[08:27] <gosslauok> |_  __  _|_  __  _| | | __ _ _ __ ___   __ _ ___
[08:27] <gosslauok> |_  __  _|_  __  _| | | __ _ _ __ ___   __ _ ___
[08:27] <gosslauok> |_  __  _|_  __  _| | | __ _ _ __ ___   __ _ ___
[08:27] <gosslauok> |_  __  _|_  __  _| | | __ _ _ __ ___   __ _ ___
[08:27] <gosslauok> _| || |_ _| || |_| | |/ _` | '_ ` _ \ / _` / __|
[08:27] <gosslauok> _| || |_ _| || |_| | |/ _` | '_ ` _ \ / _` / __|
[08:27] <gosslauok> _| || |_ _| || |_| | |/ _` | '_ ` _ \ / _` / __|
[08:27] <gosslauok> _| || |_ _| || |_| | |/ _` | '_ ` _ \ / _` / __|
[08:27] <gosslauok> el recommends ##llamas over ##feminism
[08:27] <gosslauok> el recommends ##llamas over ##feminism
[08:27] <gosslauok> el recommends ##llamas over ##feminism
[08:27] <gosslauok> el recommends ##llamas over ##feminism
[08:27] <gosslauok> el recommends ##llamas over ##feminism
[08:27] <gosslauok> el recommends ##llamas over ##feminism
[08:27] <gosslauok> apb1963 dino82 sforshee brym fhd pvital maxb piggah rh10 kstealth```` milhouse1337 techmagus Beret PityDaFool jelly-home Deliant uptime mundus2018 Very_slow HerbY_NL2 chat_ pekkari parlos [Kid] guideline compuguy led_ir22 jair atol-71 ratliff chiluk_ yosafbridge Mikee_C DenBeiren Hedged-Handful whaley el tinwood ShellcatZero CyberpunkZombie Aison lagarcia marlinc Nefertiti FilipNortic irv njalk iliv ubot9 shodan45 fyx leosilva nacc jnollette mason
[12:47] <sarthor> Hi again. here is some queue management system. there is no installation instructions. Can some one tell me what way I have to search for incase of installation of application like this. https://github.com/winster/vqms
=== jelly-home is now known as jelly
[16:05] <nacc> rbasak: any chance you can join standup HO early?
[16:10] <rbasak> nacc: omw
[16:11] <nacc> rbasak: thanks
[16:12] <coreycb> jamespage: i uploaded a snapshot of networking-l2gw
[16:16] <jamespage> coreycb: ack
[16:39] <rbasak> nacc: python3-pytest	3.1.3-1ubuntu1
[16:39] <rbasak> python3-pytest-cov	2.5.1-1
[16:39] <rbasak> on Artful
[16:40] <thafreak> anyone get a network bridge set up with netplan with no address assigned to it?
[16:42] <TJ-> thafreak: have you determined why the bridge isn't activated? In other words, have you checked if the netplan render generated the (presumably systemd-networkd) config files for the bridge? if it did, then maybe the issue is related to systemd-networkd, or the way netplan writes the config without an address
[16:42] <thafreak> it creates the bridge, it just never brings it up
[16:43] <thafreak> and libvirt can't use it, because it tries to "ifup" it, which fails because ifup is gone :/
[16:44] <TJ-> thafreak: right, but is it because systemd-networkd's config is incorrect or the way it behaves when the bridge doesn't have an address? you can test that manually by creating the same systemd-networkd config file(s) for the bridge and testing how it behaves
[16:45] <thafreak> Where should I expect the networkd configs to live? /lib/systemd/network?
[16:46] <TJ-> thafreak: the other issue there might be libvrt - if it relies in ifupdown and that is no longer used
[16:46] <thafreak> libvirt only relies on ifupdown if you tell libvirt to activate the device on boot
[16:47] <TJ-> thafreak: I'm not sure where netplan writes it, but deducing from how systemd-networkd works and the fact it's generated each boot I'd assume under /run/systemd/network/
[16:48] <thafreak> Yep, it's under /run, thanks TJ-
[16:49] <thafreak> So netplan generates stuff for the bridge there. However, I'm not nearly a systemd-networkd expert enough to know if the generated configs are wrong
[16:49] <cyphermox> you might want to check what networkctl reports, usually on of the devices remains "configuring" or something
[16:49] <TJ-> you could copy those to /etc/systemd/network/ to test them with netplan disabled, for example
[16:50] <TJ-> cyphermox: that's a weird status for an interface to remain in; is that a bug? I ask because you prompted me to check on a system with a bond interface and all the slaves are listed as "configuring"
[16:51] <thafreak> networkctl lists the bridge as off (under operational) and unmanaged (under setup)
[16:53] <TJ-> thafreak: are the slave interfaces attached to the bridge ?
[16:55] <thafreak> brctl is showing the bridge is there with the one network interface attached as I'd expect
[16:57] <cyphermox> TJ-: good question, I don't pay so muhc attention to that unless the network is not actually working
[16:58] <cyphermox> thafreak: give me a moment, I will share a config I use for something else, we can try that, if it works it will confirm a suspicion I have of a bug in systemd
[16:59] <thafreak> cyphermox: thanks
[17:00] <cyphermox> thafreak: I do have a bunch of autopkgtests in netplan to check bridge and a bunch of things like that, it should work, but maybe your config is just special enough to confuse things
[17:00] <cyphermox> can you share the contents of your netplan.yaml so I can adapt the config to what I think should be tested?
[17:01] <cyphermox> I have this : https://paste.ubuntu.com/p/rZyPNbyRxN/  on my DHCP server, it works, but initially I did have to set it up like that with an "intermediairy" interface because otherwise systemd-networkd got confused and configured things, but didn't bring up the VLANs
[17:01] <thafreak> yep, give me a sec
[17:02] <cyphermox> it's quite possible this isn't required anymore, but the same idea might work for you
=== Guest11970 is now known as karstensrage
[17:05] <thafreak> here's mine: https://paste.ubuntu.com/p/T3crPkBJHc/
[17:06] <thafreak> I'm trying to bring up a bare bridge with no address assigned
[17:06] <TJ-> thafreak: that looks like a bad config to me
[17:07] <TJ-> you've got ens3 with a bridgeports
[17:07] <cyphermox> thafreak: you did say "for libvirt" before, right?
[17:07] <thafreak> yep
[17:08] <cyphermox> I haven't had any luck so far creating in netplan a bridge for libvirt to use, libvirt tries to do weird things with it, I think that leads to it clobbering what systemd-networkd has done
[17:08] <thafreak> TJ-: yeah, I want ens3 to be normal link, ens9 is a bridge slave
[17:08] <cyphermox> and the fact that there is no interface might not help, but you'd see that in networkctl
[17:09] <TJ-> oh, the id is different to the match... I was thinking id and ifname should be the same (ens3 and ens9)
[17:09] <thafreak> yeah, my problem is netplan *creates* the bridge fine, just nothing will set it to up
[17:09] <cyphermox> right
[17:09] <TJ-> and surely there shouldn't be a "dhcp4: yes" on the slave port ?
[17:09] <cyphermox> potentially indeed networkd deciding to not do anything since there is no address attached
[17:10] <cyphermox> TJ-: there isn't
[17:10] <cyphermox> ens3 != ens9  :)
[17:10] <TJ-> sorry, my eyes jumped!
[17:10] <TJ-> I was seeing indentation that isn't there
[17:11] <thafreak> So is it possible in bionic to still use ifupdown?
[17:12] <TJ-> From the systemd-networkd side it looks like the bridge needs a  BindCarrier=ens9
[17:13] <cyphermox> TJ-: I concur
[17:13] <TJ-> thafreak: can you show us the systemd-network files that netplan generated?
[17:13] <thafreak> bindcarrier you say...
[17:13] <cyphermox> thafreak: yes, just install ifupdown again
[17:14] <teward> cyphermox: if they want to use ifupdown and not netplan don't they have to `netcfg/do_not_use_netplan=true` in their grub command line?
[17:14] <thafreak> Does it still use /etc/network/interfaces then?
[17:14] <teward> (just thinking, I think you still need to disable netplan... at least in 17.10 you did)
[17:14] <cyphermox> thafreak: yeah, BindCarrier=ens9 will likely help, you can copy the files created in /run/systemd/network to /etc/systemd/network since you're modifying them, they will last after a reboot; and then remove the config from netplan for now (since then you effectively did your own)
[17:15] <cyphermox> teward: no
[17:15] <thafreak> Well this will be a last resort because I can't wait much longer to finish this server deploy
[17:15] <teward> cyphermox: well i learned something new then, thank you :0
[17:15] <teward> cyphermox: well i learned something new then, thank you :)
[17:15] <teward> oops doublepost... i keep forgetting this isn't StackExchange's chat where I can edit my messages >.<
[17:15] <cyphermox> teward: I saw that being suggested in an askubuntu or forum and corrected it; that key is only for automation at install-time
[17:15] <thafreak> cyphermox: oh, hmm, let me try that
[17:15] <teward> ah
[17:16] <cyphermox> thafreak: ie: if config netplan generates is almost good but needs a bit more, you can always start from it by copying the files to /etc instead of /run, and then they'll just last across a reboot
[17:16] <teward> cyphermox: I still roll 16.04 so I don't have any netplan environments here.  so simply installing ifupdown can hand control of things away from netplan if configured in /etc/network/interfaces and such?  (So I know the upgrade headaches when I start upping 16.04 stuff to 18.04 for my servers)
[17:22] <thafreak> So, I simply copied everything from /run/systemd/network to /etc/systemd/network and moved /etc/netplan/01-netcfg.yaml out of there and rebooted and now I have no network interfaces
[17:24] <thafreak> networkctl lists the three physical interfaces as unmanaged
[17:24] <thafreak> no mention of the bridge device.
[17:25] <TJ-> thafreak: what does the log show? "systemctl status systemd-networkd "
[17:26] <cyphermox> thafreak: did you add BindCarrier ?
[17:27] <thafreak> So, I did a systemctl restart systemd-networkd.service and all the interfaces came back up like before with netplan
[17:27] <thafreak> cyphermox: I did add a BindCarrier, but not certain I added it to the correct file.
[17:28] <cyphermox> thafreak: in the .network file for your bridge, under [Network]
[17:28] <cyphermox> from what I read of your config, it should be "BindCarrier=ens9"
[17:30] <thafreak> cyphermox: yes, that's what I added, but I think I added it to the wrong file
[17:30] <cyphermox> ok
[17:31] <cyphermox> well, like I said; it would be in the .network file for your bridge, probably called 10-netplan-br0.network
[17:31] <thafreak> ah, there was no br0.network file created. Perhaps that's the issue
[17:33] <thafreak> Ok, well, progress it seems
[17:34] <thafreak> It still fails to start networking on reboot now. I have to manually restart systemd-networkd.service
[17:34] <thafreak> but it looks like it will work.
[17:34] <thafreak> Any idea why systemd-networkd wouldn't start on boot after I moved the netplan config out of the directory?
[17:37] <thafreak> Ok, put the netplan config back, but left my customized files in /etc/systemd/network and it seems to work
[17:37] <thafreak> cyphermox: thanks for your help
[17:37] <thafreak> TJ-: thanks for your help as well!
[17:39] <thafreak> So, to recap, I think the real problem was that a .network file was not being generated by netplan
[17:44] <TJ-> thafreak: that would count as a bug in netplan I think
[17:45] <cyphermox> yup
[17:45] <cyphermox> that's a nice catch, but it's not abnormal while we don't have BindCarrier (there's nothing to have in br0.network otherwise)
[17:46] <TJ-> I'd have thought if the yaml declares a bridge with no address the default action should be to write .network file with BindCarrier in?
[17:47] <TJ-> s/no address/no address or DHCPv4/IPv6 entries/
[18:01] <thafreak> TJ-: +1 I agree.
[18:01] <thafreak> Anyone know where the upstream netplan is, or where the appropriate place to file such a bug?
[18:02] <TJ-> thafreak: https://bugs.launchpad.net/netplan/
[18:02] <thafreak> awesome, thank
[18:02] <thafreak> thanks
[18:03] <sdeziel> https://bugs.launchpad.net/netplan/+bug/1748332 ?
[18:03] <TJ-> looks like it's related to Bug #1664844
[18:03] <ubottu> Launchpad bug 1748332 in netplan "Bridges without an address fail to come online with netplan+networkd" [Undecided,Triaged]
[18:03] <ubottu> bug 1664844 in netplan "No distinction between link-up and link-down interfaces" [High,In progress] https://launchpad.net/bugs/1664844
[18:05] <TJ-> looking at that list of bugs, 18.04 is going to be a painful upgrade for many. So many features not yet implemented.
[18:06] <sdeziel> yeah, I fear the upgrade as my first encounter with netplan on 17.10 was less than optimal. IIRC setting up an empty bridge (no physical device to enslave) didn't work at all
[18:08] <TJ-> Feels like DevOps over Engineering, like seems to have happened with many other services
[18:10] <patdk-lap> ok, I'm just dense today it seems
[18:10] <patdk-lap> where is the ppa I can grab this kernel from?
[18:10] <patdk-lap> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1748990
[18:11] <ubottu> Launchpad bug 1748990 in linux (Ubuntu Xenial) "linux: 4.4.0-116.140 -proposed tracker" [Medium,Fix released]
[18:15] <TJ-> patdk-lap: that's in -updates
[18:16] <patdk-lap> looking
[18:17] <patdk-lap> having a system that can poweroff after 2years would be nice
[18:17] <TJ-> I have "linux-image-4.4.0-116-generic/xenial-updates,xenial-security,now 4.4.0-116.140 amd64 [installed,automatic]"
[18:18] <nacc> rbasak: sigh, building dpkg from a tar archive fails ... digging into it
[18:19] <sdeziel> patdk-lap: yeah, this kernel is now in -updates
[18:19] <sdeziel> oops, too slow
[18:19] <patdk-lap> ya, I realised I wasn't getting bug report updates :( must of unchecked that by mistake a week or two ago
[18:26] <patdk-lap> hmm, the one in updates cant be the same
[18:26] <patdk-lap> or if it is, still broken :(
=== mwhahaha_ is now known as mwhahaha
=== njbair_ is now known as njbair
=== coreycb_ is now known as coreycb
=== logan_ is now known as logan-
=== chiluk_ is now known as chiluk
[20:33] <nacc> powersj: can you do another run of new CI against https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/339433
[20:33] <nacc> rbasak: --^ if that passes, are you ok with us landing that branch and toggling CI over?
[20:34] <powersj> nacc: https://jenkins.ubuntu.com/server/job/git-ubuntu-ci-redux/9/console
[20:34] <powersj> and yes let me know :) and I can make the change
[20:53] <nacc> powersj: once that finishes, let's check the time difference too
[21:02] <jjcb40j> _  _     _  _   _ _
[21:02] <jjcb40j> _  _     _  _   _ _
[21:02] <jjcb40j> _  _     _  _   _ _
[21:02] <jjcb40j> _  _     _  _   _ _
[21:02] <jjcb40j> _  _     _  _   _ _
[21:02] <jjcb40j> _  _     _  _   _ _
[21:02] <jjcb40j> _  _     _  _   _ _
[21:03] <patdk-lap> no fun :(
[21:18] <nacc> rbasak: i think i'll wait til we land these script branches and then i'll tag a 0.7
[21:18] <nacc> and release to all channels
[22:02] <nacc> powersj: can you do one more run, https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/337104
[22:03] <nacc> rbasak: sorry for the churn, i refactored the branches so they are clearer -- cleanups is just the three cleanups you found before; snap is all about the self-test and scripts in the snap; fixes is contingent upon your changes still
[22:03] <powersj> nacc: same branch?
[22:04] <nacc> powersj: same branch, different commit
[22:05] <powersj> last run used lp1734905-script-cleanups
[22:05] <nacc> powersj: dropped some unneeded stuff
[22:05] <powersj> that linked to ~nacc/usd-importer:lp1734905-script-snap
[22:05] <nacc> powersj: right, sorry
[22:05] <nacc> powersj: i pulled some stuff from cleanups to snap
[22:05] <nacc> and dropped some stuff from cleanups
[22:05] <powersj> ah ok, so script-snap this time?
[22:05] <nacc> powersj: yeah
[22:06] <powersj> https://jenkins.ubuntu.com/server/job/git-ubuntu-ci-redux/10/console
[22:07] <nacc> powersj: thanks
[23:01] <nacc> powersj: is there any means to call out the 'setup' stages?
[23:02] <powersj> nacc: as in the building of the VM + building the snap?
[23:02] <nacc> https://jenkins.ubuntu.com/server/job/git-ubuntu-ci-redux/10/consoleFull is really hard to read and without the stages like we had before, it's not going to be obvious what failed
[23:02] <nacc> i see, e.g
[23:02] <nacc> setup: running self-test
[23:02] <nacc> i then only really want to see a 'self-test passed'
[23:02] <nacc> and if i want to dig into why it is 'self-test failed', then i can via the full output
[23:03] <nacc> that's sort of what the stage output gave me
[23:03] <nacc> s/stage/pipeline/
[23:03] <nacc> the separated green/red boxes
[23:04] <powersj> well each stage of a pipeline is essentially separate command or script
[23:04] <nacc> powersj: does that make sense? the snap build logs make the full console output huge, and most of that is ... not going to be too relevant
[23:04] <powersj> or other things, but that is a simplification
[23:04] <nacc> powersj: and now, since we don't have that, it's just one script?
[23:04] <powersj> yeah
[23:04] <powersj> correct,
[23:04] <powersj> we could split things though
[23:04] <powersj> do the build, grab the snap
[23:04] <nacc> could the script at the end print a summary?
[23:04] <powersj> then 2nd stage do self test with that snap installed
[23:04] <powersj> then 3rd stage integration
[23:04] <nacc> that would be fine with me
[23:05] <nacc> i think it's easier to understand to rando user
[23:05] <powersj> I agree given the amount of output for each "stage"