| 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:04 |
| sarnold | hehehe: I've gotten the impression that mongo is brittle and takes way more resources than one might think | 00:06 |
| 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:07 |
| hehehe | is there a quick way there to make admin user? | 00:13 |
| hehehe | :D | 00:13 |
| 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:16 |
| 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. | 00:19 |
| === genpaku_ is now known as genpaku | ||
| === giraffe is now known as Guest17892 | ||
| === clvx is now known as Guest44118 | ||
| lwizardl | what is a good media backend server to use so kodi and read the media over the network | 06:06 |
| lordievader | Good morning | 06:08 |
| lwizardl | morning | 06:09 |
| lordievader | Hey lwizardl | 06:15 |
| lwizardl | whats up | 06:15 |
| lordievader | First coffee of the day. With you? | 06:16 |
| lwizardl | nice, I'm just trying to figure out what would be the best backend server setup to use for kodi media files | 06:31 |
| === tohuw is now known as Guest12040 | ||
| zioproto | hello | 09:59 |
| 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:00 |
| 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:01 |
| zioproto | but why this pops up when creating to snapshot ? | 10:02 |
| jamespage | zioproto: hmm | 10:02 |
| 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:03 |
| zioproto | libvirt.log also complains about apparmor | 10:04 |
| zioproto | https://pastebin.com/wBZJyrJ0 | 10:04 |
| zioproto | all seems related | 10:04 |
| zioproto | do you think it makes sense to dig into this virt-aa-helper to solve the snapshotting issue ? | 10:09 |
| zioproto | jamespage: still there ? | 11:02 |
| jamespage | zioproto: yeah sorry - been having internet trouble - just replaced a socket for one with an in-built microfilter | 11:09 |
| zioproto | jamespage: no problem, when you a chance to look into this apparmor thing tell me your opinion about it. | 11:17 |
| 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:18 |
| jamespage | zioproto: looks similar to https://bugs.launchpad.net/fuel/+bug/1638269 | 11:19 |
| ubottu | Launchpad bug 1638269 in Fuel for OpenStack "OSTF Launch instance, create snapshot, launch instance from snapshot failed" [Critical,Fix released] | 11:19 |
| 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:21 |
| zioproto | jamespage: but this looks like a patch for trusty https://review.fuel-infra.org/#/c/28086/2/debian/apparmor/libvirt-qemu | 11:23 |
| zioproto | please forgive me ! I just found out that this hypervisor is actually still on trusty | 11:25 |
| 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/ | 11:53 |
| 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:10 |
| 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:14 |
| jamespage | zioproto: raise a bug - I'll ask christian to look next week (he's the libvirt maintainer in the server team) | 12:51 |
| 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:12 |
| rbasak | smoser: done | 13:38 |
| smoser | thanks | 13:40 |
| jbicha | hi, should LP: #1618188 be added to Trello as something to watch, help out with or whatever? | 14:41 |
| ubottu | 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:41 |
| 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:46 |
| 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? | 14:52 |
| jbicha | I think Ubuntu should consider enabling a persistent systemd journal by default before 18.04 LTS | 15:00 |
| jbicha | it's a complicated issue: maybe we don't need both a persistent systemd journal and rsyslog | 15:01 |
| jbicha | so I'm suggesting that y'all add it to your backlog of things to look into | 15:03 |
| 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:04 |
| bipul | What is MASS Regional controller? | 15:21 |
| dpb1 | maas region controller in theory can have multiple rack level controllers registered to it | 15:26 |
| 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:27 |
| dpb1 | yes | 15:29 |
| dpb1 | look over the docs, there are some good tips about vm usage in there | 15:29 |
| smoser | rbasak, i kind of think we shoudl be logging to a file, and i'm pretty sure rharper agrees. | 15:35 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| nacc | the user doesn't *know* that they need to pass that flag, until it's possibly too late | 15:44 |
| 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:45 |
| 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:46 |
| rbasak | I agree with commands that take time showing progress. | 15:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| rbasak | Perhaps we should default to the package name then, like "git clone"? | 15:55 |
| 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:56 |
| 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:57 |
| * rbasak has always seen it as noise | 15:58 | |
| * nacc thinks you haven't debugged the importer quite as much as I have :) | 15:58 | |
| 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. | 15:59 |
| 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:00 |
| 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:03 |
| 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:05 |
| kirkland | rbasak: ack, thanks | 16:10 |
| bipul | i have installed mass on my VM , but what will be the next step ? | 16:18 |
| nacc | rbasak: do you want to do a HO today in prep for tmrw? | 16:35 |
| rbasak | nacc: I was thinking about suggesting that :) | 16:41 |
| rbasak | nacc: was just checking my schedule. I'm free now. | 16:42 |
| nacc | rbasak: ok, give me one sec to resolve dpb1's upload :) | 16:43 |
| rbasak | ack | 16:43 |
| === Masterph_ is now known as Masterphi | ||
| nacc | rbasak: use the standup HO? | 16:48 |
| rbasak | omw | 16:49 |
| rbasak | nacc: I'm there. | 16:49 |
| nacc | rbasak: actually, do you want me to land your branches since we agreed? | 17:45 |
| 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:11 |
| nacc | rbasak: ack, i'm stacking that on top | 18:13 |
| nacc | rbasak: if you're ok with that | 18:13 |
| rbasak | nacc: yeah that's fine thanks! | 18:32 |
| nacc | rbasak: fyi, just pushed a new branch and requested review for a fixed SRU versioning test | 20:42 |
| 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:08 |
| 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? | 21:09 |
| sarnold | drab: take a look at http://lartc.org/howto/lartc.rpdb.multiple-links.html | 22:06 |
| 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:31 |
| 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) | 22:32 |
| 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:26 |
| 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:27 |
| 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:36 |
| rbasak | Still fails I think | 23:37 |
| rbasak | I don't like going >80 cols, but I'm not sure how to make that better :-/ | 23:38 |
| 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:39 |
| rbasak | I added a further test, now one failure | 23:40 |
| rbasak | http://paste.ubuntu.com/25180232/ | 23:40 |
| hashwagon | What's the correct method of adding a Windows shared printer to an ubuntu server via Samba? Is it added through smbclient? | 23:41 |
| 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:42 |
| nacc | rbasak: something with versioning.py l.132 i think | 23:43 |
| nacc | rbasak: http://paste.ubuntu.com/25180252/ | 23:45 |
| nacc | rbasak: that passes here | 23:45 |
| 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:46 |
| nacc | rbasak: http://paste.ubuntu.com/25180277/ specifically fails | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!