[00:04] sarnold: is mongodb some crap? [00:04] :D [00:04] I just started to use it and it seems interface initially is cumbersome [00:06] hehehe: I've gotten the impression that mongo is brittle and takes way more resources than one might think [00:07] well what to do [00:07] :D [00:07] and I'm slightly terrified of its eventual consistency thing [00:07] and apparently you ought to consider using numactl when starting it to ensure that it gets memory and lots of it [00:13] is there a quick way there to make admin user? [00:13] :D [00:16] anyway good news new chat coming soon :) [00:16] so i can at last move to chat where most people come to talk [00:16] :) [00:16] not just iddle [00:19] 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] question again. === genpaku_ is now known as genpaku === giraffe is now known as Guest17892 === clvx is now known as Guest44118 [06:06] what is a good media backend server to use so kodi and read the media over the network [06:08] Good morning [06:09] morning [06:15] Hey lwizardl [06:15] whats up [06:16] First coffee of the day. With you? [06:31] nice, I'm just trying to figure out what would be the best backend server setup to use for kodi media files === tohuw is now known as Guest12040 [09:59] hello [10:00] 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] this virt-aa-helper that cant read a couple of config files could block the all thing ? [10:01] 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] 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] but why this pops up when creating to snapshot ? [10:02] zioproto: hmm [10:03] zioproto: anything in the libvirt or qemu log files [10:03] ? [10:03] jamespage: https://pastebin.com/HbckXxvf [10:03] wait I check libvirt log file [10:04] libvirt.log also complains about apparmor [10:04] https://pastebin.com/wBZJyrJ0 [10:04] all seems related [10:09] do you think it makes sense to dig into this virt-aa-helper to solve the snapshotting issue ? [11:02] jamespage: still there ? [11:09] zioproto: yeah sorry - been having internet trouble - just replaced a socket for one with an in-built microfilter [11:17] jamespage: no problem, when you a chance to look into this apparmor thing tell me your opinion about it. [11:18] zioproto: tbh I'm a bit flummoxed - newton has the version of libvirt and qemu from xenial [11:18] zioproto: did this work with previous versions? [11:19] zioproto: looks similar to https://bugs.launchpad.net/fuel/+bug/1638269 [11:19] Launchpad bug 1638269 in Fuel for OpenStack "OSTF Launch instance, create snapshot, launch instance from snapshot failed" [Critical,Fix released] [11:21] 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] nothing happens [11:23] jamespage: but this looks like a patch for trusty https://review.fuel-infra.org/#/c/28086/2/debian/apparmor/libvirt-qemu [11:25] please forgive me ! I just found out that this hypervisor is actually still on trusty [11:53] 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] zioproto: \o/ [12:10] 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] 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] should I submit a patch for that package ? [12:51] zioproto: raise a bug - I'll ask christian to look next week (he's the libvirt maintainer in the server team) [13:12] rbasak, can you help me out ? [13:12] https://code.launchpad.net/~logan/ubuntu/+source/scim-chewing/+git/scim-chewing/+merge/327575 [13:12] i think i just confused things. [13:38] smoser: done [13:40] thanks [14:41] hi, should LP: #1618188 be added to Trello as something to watch, help out with or whatever? [14:41] Launchpad bug 1618188 in ubuntu-meta (Ubuntu) "systemd journal should be persistent by default: /var/log/journal should be created; remove rsyslog from default installs" [Wishlist,Triaged] https://launchpad.net/bugs/1618188 [14:46] jbicha: that feels like a feature request to me and not a regression or bug? [14:46] AIUI, rsyslog behaviour remains unaffected. [14:52] 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] Or are you asking us to drive it in some particular direction, and if so, which? [15:00] I think Ubuntu should consider enabling a persistent systemd journal by default before 18.04 LTS [15:01] it's a complicated issue: maybe we don't need both a persistent systemd journal and rsyslog [15:03] so I'm suggesting that y'all add it to your backlog of things to look into [15:04] OK, thanks. [15:04] I guess it's an open question as to what we actually want to do here. [15:04] dpb1, kirkland: ^ [15:04] rharper and smoser also maybe? ^ [15:04] the bug points out that there was some discussion on ubuntu-devel back in February [15:21] What is MASS Regional controller? [15:26] maas region controller in theory can have multiple rack level controllers registered to it [15:27] bipul: https://docs.ubuntu.com/maas/2.1/en/intro-concepts#controllers <-- see for more [15:27] Can we control my vm with mass? [15:29] yes [15:29] look over the docs, there are some good tips about vm usage in there [15:35] rbasak, i kind of think we shoudl be logging to a file, and i'm pretty sure rharper agrees. [15:39] nacc: how about http://paste.ubuntu.com/25177407/ [15:39] Prints the directory from top level subcommand code if --no-clean is in use. [15:39] rbasak: i would rather we didn't change any functionality first, then decide on whether it makes sense to always print it [15:40] rbasak: that is, just do it unconditionally, then file a bug saying you want `git ubuntu clone` to be less verbose [15:40] rbasak: but note, you need to change all the callers for GitUbuntuRepository(), not just clone [15:40] nacc: rbasak: could I please have an import of shim-signed? [15:40] nacc: can we just decide that now? [15:41] (looks missing to me, or maybe I don't know where to look) [15:41] nacc: I don't think library code should _ever_ output to stdout/stderr. [15:41] rbasak: this isn't about library code [15:41] I also think that commands should in general be silent. [15:41] rbasak: i'm saying right now `git ubuntu clone` always prints where it clones to [15:41] TAOUP principle. [15:41] rbasak: right, those are *two* commits then [15:41] rbasak: and one is a change in behavior [15:41] Sure. I'm requesting a change in behaviour. [15:42] right, but it's easier to review as two steps [15:42] and easier to revert :) [15:42] 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] I fundamentally disagree :) [15:42] It will be easier to revert, but only as much easier as it is to write the code in the first place. [15:42] It doesn't save anything overall whether we decide to revert or not. [15:43] should _ever_ output> except on caller request, of course. [15:43] 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] taht's asinine to me [15:44] the user doesn't *know* that they need to pass that flag, until it's possibly too late [15:45] rbasak: the no-clean thing was an example, not the rule, sorry [15:45] rbasak: the rule is, if the user wouldn't know what the directory we are using is, emit it [15:46] git ubuntu clone uses a tempdir by default? [15:46] rbasak: yes [15:46] rbasak: err, not clone, import, sorry [15:46] I thought it mirrored "git clone". [15:46] rbasak: the thing you just pastebinned :) [15:46] rbasak: also, `git ubuntu clone` should be *more* verbose, tbh. it should show the `git fetch` output [15:46] right now it's silent for *way* too long [15:46] and i think a regular user will ^C it every time [15:46] thinking it's hung [15:47] I agree with commands that take time showing progress. [15:48] 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] +1 on that [15:48] i want `git ubuntu import` to emit the directory used unconditionally (or at least whenever a tempdir is used) [15:48] i guess for the remainder of the submcommands, it doesn't matter. `git ubuntu review` will also need to follow that pattern [15:49] 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] rbasak: hrm? what do you mean by "either"? [15:50] 1) emit unconditionally; 2) only when --no-clean is used and a directory wasn't given. [15:50] rbasak: i'm suggesting consolidating those to 1) if no directory is given, emit the directory used [15:50] rbasak: otherwise that information is *not* available to the user [15:51] I agree that not having it available to the user is bad. [15:51] I think this is a symptom of a poor CLI option though, rather than a lack of output. [15:51] rbasak: not sure i follow? [15:51] rbasak: what option are you referring to? [15:51] Perhaps we shouldn't permit --no-clean when a directory name isn't given for example. [15:52] rbasak: the directory option, period, is optional, regardless of other flags [15:52] rbasak: e.g., if you ^C the importer, you can go look at where it is [15:52] rbasak: but if you don't emit the tempdir used, you can't [15:52] 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] ... the user knows where it is because we tell them? [15:53] if you're suggesting a separate change in functionality, just do that [15:53] Right, and I'm saying that's a poor show. [15:53] I don't see anything poor about it, but in the end, I really don't care [15:53] I'm trying to hammer out our differences so we can agree on a path across all three interacting pieces :) [15:54] I think having to pass a directory when I do offline imports will make me actively use the importer less [15:54] :) [15:55] Perhaps we should default to the package name then, like "git clone"? [15:56] or require a directory [15:56] nacc: I only tacked this on in there because I was under the impression that you already agreed. [15:56] rbasak: my point was with the current functionality, you need not pass a directry [15:56] nacc: I can just drop it from this MP and we can work this out later? [15:57] 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] rbasak: which needs to be propogated to all wiki pages, the manpage, etc. [15:57] rbasak: and the bash completion script :) [15:57] 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] 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] 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] 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] Though I admit the commit message should be different then. [16:05] 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] rbasak: ack, thanks [16:18] i have installed mass on my VM , but what will be the next step ? [16:35] rbasak: do you want to do a HO today in prep for tmrw? [16:41] nacc: I was thinking about suggesting that :) [16:42] nacc: was just checking my schedule. I'm free now. [16:43] rbasak: ok, give me one sec to resolve dpb1's upload :) [16:43] ack === Masterph_ is now known as Masterphi [16:48] rbasak: use the standup HO? [16:49] omw [16:49] nacc: I'm there. [17:45] rbasak: actually, do you want me to land your branches since we agreed? [18:11] nacc: sure. Though I think both MPs need minor modifications? [18:11] 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] rbasak: ack, i'm stacking that on top [18:13] rbasak: if you're ok with that [18:32] nacc: yeah that's fine thanks! [20:42] rbasak: fyi, just pushed a new branch and requested review for a fixed SRU versioning test [21:08] hi, dumb networking question that's eluding me.. [21:08] if I add an ip alias to an interface, say eth0:1 [21:08] connections inbound for that ip will be routed out from the main ip associated to eth0 [21:09] 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] 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] drab: take a look at http://lartc.org/howto/lartc.rpdb.multiple-links.html [22:31] 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] guess not [22:31] drab: alias interfaces are wonky [22:31] (the gw has two uplinks) [22:31] best forget those as quick as you can :) [22:31] yeah, it's just for a migration, maybe I shuold have asked that question instead [22:31] just add multiple addresses to the nic as needed.. [22:32] need to move a service from one box to another that eventually will be on a diff ip [22:32] so wanted to add the old/current ip as an alias until settings propagate throuhgout the network [22:32] (it's the dns server and the lease if 48hrs) [23:26] 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] http://paste.ubuntu.com/25180158/ [23:27] 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] 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] rbasak: similar on line 10? [23:36] rbasak: not sure if that changes the result :) [23:36] Sorry, yes. Checking. [23:36] rbasak: i made the exact same typos and thought i had broken things when i was working on the change :) [23:37] Still fails I think [23:38] I don't like going >80 cols, but I'm not sure how to make that better :-/ [23:39] rbasak: ack, failure reproduced, let me see if i can see why [23:39] I get all passed now! [23:39] rbasak: what's the diff? :) [23:40] I added a further test, now one failure [23:40] http://paste.ubuntu.com/25180232/ [23:41] What's the correct method of adding a Windows shared printer to an ubuntu server via Samba? Is it added through smbclient? [23:42] 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] 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] rbasak: yeah [23:43] rbasak: something with versioning.py l.132 i think [23:45] rbasak: http://paste.ubuntu.com/25180252/ [23:45] rbasak: that passes here [23:46] OK, give me a few minutes to catch up [23:46] 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] rbasak: http://paste.ubuntu.com/25180277/ specifically fails