[00:04] <hehehe> sarnold: is mongodb some crap?
[00:04] <hehehe> :D
[00:04] <hehehe> I just started to use it and it seems interface initially is cumbersome
[00:06] <sarnold> hehehe: I've gotten the impression that mongo is brittle and takes way more resources than one might think
[00:07] <hehehe> well what to do
[00:07] <hehehe> :D
[00:07] <sarnold> and I'm slightly terrified of its eventual consistency thing
[00:07] <sarnold> and apparently you ought to consider using numactl when starting it to ensure that it gets memory and lots of it
[00:13] <hehehe> is there a quick way there to make admin user?
[00:13] <hehehe> :D
[00:16] <hehehe> anyway good news new chat coming soon :)
[00:16] <hehehe> so i can at last move to chat where most people come to talk
[00:16] <hehehe> :)
[00:16] <hehehe> not just iddle
[00:19] <tomreyn> fluvvell: with the (limited, no output, just summaries) information you provided, i provided all the suggestions i could. i then went afk. i'll head to bed now. if you would like more suggestions, i would suggest you put the actual output of some informational commands (such as 'mdadm --detail /dev/md0', 'cat /proc/mdstat' and the (in- and) output of the command that does not result in the expected result) on a pastebin and ask your
[00:19] <tomreyn> question again.
[06:06] <lwizardl> what is a good media backend server to use so kodi and read the media over the network
[06:08] <lordievader> Good morning
[06:09] <lwizardl> morning
[06:15] <lordievader> Hey lwizardl
[06:15] <lwizardl> whats up
[06:16] <lordievader> First coffee of the day. With you?
[06:31] <lwizardl> nice, I'm just trying to figure out what would be the best backend server setup to use for kodi media files
[09:59] <zioproto> hello
[10:00] <zioproto> coreycb, jamespage on Newton Xenial I am working on a problem were snapshotting a instance with a LVM backend fails. In the log files I see apparmor complaining. I never had problems with apparmor so far... so I am not sure this is a maybe a false positive. So everything I try to snapshot an instance I see this in the kernel log: https://pastebin.com/JTiiSNRz
[10:00] <zioproto> this virt-aa-helper that cant read a couple of config files could block the all thing ?
[10:01] <zioproto> I get a nice stacktrace in nova-compute.log that ends with libvirtError: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory
[10:01] <jamespage> zioproto: I don't think so - the virt-aa-helper is used on instance creation to create an apparmor profile for the instance
[10:02] <zioproto> but why this pops up when creating to snapshot ?
[10:02] <jamespage> zioproto: hmm
[10:03] <jamespage> zioproto: anything in the libvirt or qemu log files
[10:03] <jamespage> ?
[10:03] <zioproto> jamespage: https://pastebin.com/HbckXxvf
[10:03] <zioproto> wait I check libvirt log file
[10:04] <zioproto> libvirt.log also complains about apparmor
[10:04] <zioproto> https://pastebin.com/wBZJyrJ0
[10:04] <zioproto> all seems related
[10:09] <zioproto> do you think it makes sense to dig into this virt-aa-helper to solve the snapshotting issue ?
[11:02] <zioproto> jamespage: still there ?
[11:09] <jamespage> zioproto: yeah sorry - been having internet trouble - just replaced a socket for one with an in-built microfilter
[11:17] <zioproto> jamespage: no problem, when you a chance to look into this apparmor thing tell me your opinion about it.
[11:18] <jamespage> zioproto: tbh I'm a bit flummoxed - newton has the version of libvirt and qemu from xenial
[11:18] <jamespage> zioproto: did this work with previous versions?
[11:19] <jamespage> zioproto: looks similar to https://bugs.launchpad.net/fuel/+bug/1638269
[11:21] <zioproto> I have no idea if it worked before. Probably not. Usually we use the ceph backend. But for some users we force the lvm backend. We do this using a property in a private flavor. Then with host aggregates we make those flavor land on specific hypervisors where nova.conf has 'lvm' in the [libvirt] section. Now one of our users tried to make a snapshot. I was expecting a LVM snapshot to be created, but actually
[11:21] <zioproto> nothing happens
[11:23] <zioproto> jamespage: but this looks like a patch for trusty https://review.fuel-infra.org/#/c/28086/2/debian/apparmor/libvirt-qemu
[11:25] <zioproto> please forgive me ! I just found out that this hypervisor is actually still on trusty
[11:53] <zioproto> jamespage: upgrading libvirt-bin from 1.3.1-1ubuntu10.5~cloud0 to 1.3.1-1ubuntu10.9~cloud0 upgraded the apparmor files and fixed all the problems. Now I can do snapshots ! not sure if it was apparmor or libvirt internals
[11:53] <jamespage> zioproto: \o/
[12:10] <zioproto> jamespage: I reproduced it on another Hypervisor. There is a second thing. Not only upgrade libvirt. Also in /etc/apparmor.dabstractions/libvirt-qemu this patch is required: https://review.fuel-infra.org/#/c/28086/2/debian/apparmor/libvirt-qemu
[12:14] <zioproto> jamespage: what about this patch ? Is this something that should be included in a package ? the file /etc/apparmor.d/abstractions/libvirt-qemu belongs to the package libvirt-bin that I just upgraded at the latest version 1.3.1-1ubuntu10.9~cloud0
[12:14] <zioproto> should I submit a patch for that package ?
[12:51] <jamespage> zioproto: raise a bug - I'll ask christian to look next week (he's the libvirt maintainer in the server team)
[13:12] <smoser> rbasak, can you help me out ?
[13:12] <smoser>  https://code.launchpad.net/~logan/ubuntu/+source/scim-chewing/+git/scim-chewing/+merge/327575
[13:12] <smoser> i think i just confused things.
[13:38] <rbasak> smoser: done
[13:40] <smoser> thanks
[14:41] <jbicha> hi, should LP: #1618188 be added to Trello as something to watch, help out with or whatever?
[14:46] <rbasak> jbicha: that feels like a feature request to me and not a regression or bug?
[14:46] <rbasak> AIUI, rsyslog behaviour remains unaffected.
[14:52] <rbasak> And by feature request, I mean one where a decision has not been made. So there's no action on it currently, so I'm not sure what a Trello card would do.
[14:52] <rbasak> Or are you asking us to drive it in some particular direction, and if so, which?
[15:00] <jbicha> I think Ubuntu should consider enabling a persistent systemd journal by default before 18.04 LTS
[15:01] <jbicha> it's a complicated issue: maybe we don't need both a persistent systemd journal and rsyslog
[15:03] <jbicha> so I'm suggesting that y'all add it to your backlog of things to look into
[15:04] <rbasak> OK, thanks.
[15:04] <rbasak> I guess it's an open question as to what we actually want to do here.
[15:04] <rbasak> dpb1, kirkland: ^
[15:04] <rbasak> rharper and smoser also maybe? ^
[15:04] <jbicha> the bug points out that there was some discussion on ubuntu-devel back in February
[15:21] <bipul> What is MASS Regional controller?
[15:26] <dpb1> maas region controller in theory can have multiple rack level controllers registered to it
[15:27] <dpb1> bipul: https://docs.ubuntu.com/maas/2.1/en/intro-concepts#controllers <-- see for more
[15:27] <bipul> Can we control my vm with mass?
[15:29] <dpb1> yes
[15:29] <dpb1> look over the docs, there are some good tips about vm usage in there
[15:35] <smoser> rbasak, i kind of think we shoudl be logging to a file, and i'm pretty sure rharper agrees.
[15:39] <rbasak> nacc: how about http://paste.ubuntu.com/25177407/
[15:39] <rbasak> Prints the directory from top level subcommand code if --no-clean is in use.
[15:39] <nacc> rbasak: i would rather we didn't change any functionality first, then decide on whether it makes sense to always print it
[15:40] <nacc> rbasak: that is, just do it unconditionally, then file a bug saying you want `git ubuntu clone` to be less verbose
[15:40] <nacc> rbasak: but note, you need to change all the callers for GitUbuntuRepository(), not just clone
[15:40] <cyphermox> nacc: rbasak: could I please have an import of shim-signed?
[15:40] <rbasak> nacc: can we just decide that now?
[15:41] <cyphermox> (looks missing to me, or maybe I don't know where to look)
[15:41] <rbasak> nacc: I don't think library code should _ever_ output to stdout/stderr.
[15:41] <nacc> rbasak: this isn't about library code
[15:41] <rbasak> I also think that commands should in general be silent.
[15:41] <nacc> rbasak: i'm saying right now `git ubuntu clone` always prints where it clones to
[15:41] <rbasak> TAOUP principle.
[15:41] <nacc> rbasak: right, those are *two* commits then
[15:41] <nacc> rbasak: and one is a change in behavior
[15:41] <rbasak> Sure. I'm requesting a change in behaviour.
[15:42] <nacc> right, but it's easier to review as two steps
[15:42] <nacc> and easier to revert :)
[15:42] <rbasak> I don't think it's worth writing all the code to pull out the printing of stuff up one level only to then remove it.
[15:42] <nacc> I fundamentally disagree :)
[15:42] <rbasak> It will be easier to revert, but only as much easier as it is to write the code in the first place.
[15:42] <rbasak> It doesn't save anything overall whether we decide to revert or not.
[15:43] <rbasak> should _ever_ output> except on caller request, of course.
[15:43] <nacc> so you're saying that `git ubuntu clone`, which uses a tempdir by default, shouldn't tell the user what the tempdir is, unless they pass --verbose?
[15:43] <nacc> taht's asinine to me
[15:44] <nacc> the user doesn't *know* that they need to pass that flag, until it's possibly too late
[15:45] <nacc> rbasak: the no-clean thing was an example, not the rule, sorry
[15:45] <nacc> rbasak: the rule is, if the user wouldn't know what the directory we are using is, emit it
[15:46] <rbasak> git ubuntu clone uses a tempdir by default?
[15:46] <nacc> rbasak: yes
[15:46] <nacc> rbasak: err, not clone, import, sorry
[15:46] <rbasak> I thought it mirrored "git clone".
[15:46] <nacc> rbasak: the thing you just pastebinned :)
[15:46] <nacc> rbasak: also, `git ubuntu clone` should be *more* verbose, tbh. it should show the `git fetch` output
[15:46] <nacc> right now it's silent for *way* too long
[15:46] <nacc> and i think a regular user will ^C it every time
[15:46] <nacc> thinking it's hung
[15:47] <rbasak> I agree with commands that take time showing progress.
[15:48] <rbasak> In this case I think it should mirror "git clone", though I appreciate that since it doesn't do that exactly this may be difficult and we'll have to compromise with some other status output.
[15:48] <nacc> +1 on that
[15:48] <nacc> i want `git ubuntu import` to emit the directory used unconditionally (or at least whenever a tempdir is used)
[15:48] <nacc> i guess for the remainder of the submcommands, it doesn't matter. `git ubuntu review` will also need to follow that pattern
[15:49] <rbasak> I don't think either should be necessary. But I'll concede whenever --no-clean is used, as I see that as mainly a debug option.
[15:49] <nacc> rbasak: hrm? what do you mean by "either"?
[15:50] <rbasak> 1) emit unconditionally; 2) only when --no-clean is used and a directory wasn't given.
[15:50] <nacc> rbasak: i'm suggesting consolidating those to 1) if no directory is given, emit the directory used
[15:50] <nacc> rbasak: otherwise that information is *not* available to the user
[15:51] <rbasak> I agree that not having it available to the user is bad.
[15:51] <rbasak> I think this is a symptom of a poor CLI option though, rather than a lack of output.
[15:51] <nacc> rbasak: not sure i follow?
[15:51] <nacc> rbasak: what option are you referring to?
[15:51] <rbasak> Perhaps we shouldn't permit --no-clean when a directory name isn't given for example.
[15:52] <nacc> rbasak: the directory option, period, is optional, regardless of other flags
[15:52] <nacc> rbasak: e.g., if you ^C the importer, you can go look at where it is
[15:52] <nacc> rbasak: but if you don't emit the tempdir used, you can't
[15:52] <rbasak> And I'm arguing that --no-clean makes no sense if a directory is not given. Because how would the user know where it is? Printing it is a hack.
[15:53] <nacc> ... the user knows where it is because we tell them?
[15:53] <nacc> if you're suggesting a separate change in functionality, just do that
[15:53] <rbasak> Right, and I'm saying that's a poor show.
[15:53] <nacc> I don't see anything poor about it, but in the end, I really don't care
[15:53] <rbasak> I'm trying to hammer out our differences so we can agree on a path across all three interacting pieces :)
[15:54] <nacc> I think having to pass a directory when I do offline imports will make me actively use the importer less
[15:54] <nacc> :)
[15:55] <rbasak> Perhaps we should default to the package name then, like "git clone"?
[15:56] <nacc> or require a directory
[15:56] <rbasak> nacc: I only tacked this on in there because I was under the impression that you already agreed.
[15:56] <nacc> rbasak: my point was with the current functionality, you need not pass a directry
[15:56] <rbasak> nacc: I can just drop it from this MP and we can work this out later?
[15:57] <nacc> rbasak: if you think the user should always pass a directory, or default to using the srcpkg name, then do that, but as a clear functional change
[15:57] <nacc> rbasak: which needs to be propogated to all wiki pages, the manpage, etc.
[15:57] <nacc> rbasak: and the bash completion script :)
[15:57] <rbasak> I never thought that you considered the logging info printout as part of the CLI definition :)
[15:58]  * rbasak has always seen it as noise
[15:58]  * nacc thinks you haven't debugged the importer quite as much as I have :)
[15:59] <nacc> rbasak: i think the idea of dropping logging.info from internal library code is +100. I think the idea of changing user-facing functionality in the same commit is -100.
[16:00] <nacc> rbasak: I think you can change the user-facing functionality in a second commit and it goes to at least a positive value :)
[16:03] <rbasak> nacc: I agree with what you're saying. But I also think that if the conclusion is to drop user-facing functionality, then we can do that in one commit. This commit :)
[16:03] <rbasak> Though I admit the commit message should be different then.
[16:05] <nacc> that's fair, then. I guess my point was that what you had (commit message wise), did not match the effect (to me) and thus I had to pay closer attention to the review and think if it's ok.
[16:10] <kirkland> rbasak: ack, thanks
[16:18] <bipul> i have installed mass on my VM , but what will be the next step ?
[16:35] <nacc> rbasak: do you want to do a HO today in prep for tmrw?
[16:41] <rbasak> nacc: I was thinking about suggesting that :)
[16:42] <rbasak> nacc: was just checking my schedule. I'm free now.
[16:43] <nacc> rbasak: ok, give me one sec to resolve dpb1's upload :)
[16:43] <rbasak> ack
[16:48] <nacc> rbasak: use the standup HO?
[16:49] <rbasak> omw
[16:49] <rbasak> nacc: I'm there.
[17:45] <nacc> rbasak: actually, do you want me to land your branches since we agreed?
[18:11] <rbasak> nacc: sure. Though I think both MPs need minor modifications?
[18:11] <rbasak> nacc: IIRC a comment about using Version as an interface, and the moving of logging.info to everything that calls the GitUbuntuRepository constructor?
[18:13] <nacc> rbasak: ack, i'm stacking that on top
[18:13] <nacc> rbasak: if you're ok with that
[18:32] <rbasak> nacc: yeah that's fine thanks!
[20:42] <nacc> rbasak: fyi, just pushed a new branch and requested review for a fixed SRU versioning test
[21:08] <drab> hi, dumb networking question that's eluding me..
[21:08] <drab> if I add an ip alias to an interface, say eth0:1
[21:08] <drab> connections inbound for that ip will be routed out from the main ip associated to eth0
[21:09] <drab> I'm guessing because that's default route for the main table and both ips belong to the same network so that can't be used to pick the alias one
[21:09] <drab> is there some way with policy routing or something else that I can force outgoing connections to use the same interface/ip they came in through?
[22:06] <sarnold> drab: take a look at http://lartc.org/howto/lartc.rpdb.multiple-links.html
[22:31] <drab> sarnold: oh, yeah, I've done that on the gw, but I thought there was something "simpler" here given it's an alias interface
[22:31] <drab> guess not
[22:31] <sarnold> drab: alias interfaces are wonky
[22:31] <drab> (the gw has two uplinks)
[22:31] <sarnold> best forget those as quick as you can :)
[22:31] <drab> yeah, it's just for a migration, maybe I shuold have asked that question instead
[22:31] <sarnold> just add multiple addresses to the nic as needed..
[22:32] <drab> need to move a service from one box to another that eventually will be on a diff ip
[22:32] <drab> so wanted to add the old/current ip as an alias until settings propagate throuhgout the network
[22:32] <drab> (it's the dns server and the lease if 48hrs)
[23:26] <rbasak> nacc: here are a couple of additional cases that fail. The second is a little debatable but I think core devs/SRU would agree that it is what they expect should that situation arise. The first one is surely common though.
[23:27] <rbasak> http://paste.ubuntu.com/25180158/
[23:27] <rbasak> nacc: but your MP objectively improves things, so I wouldn't want to hold that up. I just wonder (without having looked at your code) whether we're headed in the right direction, or there's something fundamental about our approach we need to change.
[23:36] <nacc> rbasak: line 9 of your paste, that version doesn't look right? 1.01-ubuntu1.17.10.1 is definitely not right? should be 1.0-1ubuntu1.17.10.1 ?
[23:36] <nacc> rbasak: similar on line 10?
[23:36] <nacc> rbasak: not sure if that changes the result :)
[23:36] <rbasak> Sorry, yes. Checking.
[23:36] <nacc> rbasak: i made the exact same typos and thought i had broken things when i was working on the change :)
[23:37] <rbasak> Still fails I think
[23:38] <rbasak> I don't like going >80 cols, but I'm not sure how to make that better :-/
[23:39] <nacc> rbasak: ack, failure reproduced, let me see if i can see why
[23:39] <rbasak> I get all passed now!
[23:39] <nacc> rbasak: what's the diff? :)
[23:40] <rbasak> I added a further test, now one failure
[23:40] <rbasak> http://paste.ubuntu.com/25180232/
[23:41] <hashwagon> What's the correct method of adding a Windows shared printer to an ubuntu server via Samba? Is it added through smbclient?
[23:42] <rbasak> nacc: my current failure is that if the series part is set in the past or the future, for the same base and major version, then I think the series form must be used
[23:42] <nacc> rbasak: cool, let me see if i can figure that out, it appears to not see the same base version, if i had to guess
[23:42] <nacc> rbasak: yeah
[23:43] <nacc> rbasak: something with versioning.py l.132 i think
[23:45] <nacc> rbasak: http://paste.ubuntu.com/25180252/
[23:45] <nacc> rbasak: that passes here
[23:46] <rbasak> OK, give me a few minutes to catch up
[23:46] <nacc> rbasak: basically, if our current version is a prefix of any prior or future version, we should use the series-version. Although that's not quite right, as it will false match ubuntu1 to ubuntu11 ..
[23:50] <nacc> rbasak: http://paste.ubuntu.com/25180277/ specifically fails