[00:03] <whoiswhere> forgot to add nameserver before ip
[00:03] <whoiswhere> o well :D
[00:41] <whoiswhere> so quit
[00:41] <whoiswhere> quite
[00:41] <whoiswhere> do people here talk only when at work?
[00:43] <whoiswhere> :)
[05:08] <cpaelzer> good morning
[07:36] <lordievader> Good morning
[10:59] <zetheroo> I am trying to figure out how to make a trigger expression for disk space being less than 10 percent ... but really not having much luck figuring this out
[11:01] <zetheroo> sorry ... wrong room :P
[11:03] <lordievader> zetheroo: In Zabbix? Or what?
[11:03] <zetheroo> yeah :D
[11:46] <lordievader> Let me check how I did it.
[11:47] <lordievader> zetheroo: I'm using the pfree: `vfs.fs.size[{#FSNAME}, pfree].last()}<10`
[11:48] <zetheroo> lordievader: thanks ... I just discovered the prototypes in the default templates
[16:11] <darinavbt> Hi all. I'm using a Canonical Autopilot-deployed OpenStack and I'm having problems attaching a Cinder/Ceph volume to instances. Could someone help me? This is the last major issue before we put this into testing.
[16:12] <darinavbt> Or does Canonical have sales engineers or something that I could call?
[16:21] <nacc> dpb1: --^ would you know?
[16:22] <nacc> ahasenack: you can use `dep3changelog` to generate a consistent changelog message from the DEP3 headers
[16:22] <nacc> ahasenack: re: squid3 MR
[16:22] <nacc> *MP
[16:24] <nacc> ahasenack: also, it's possible you need to be using continuation lines in the Description: section
[16:25] <nacc> ahasenack: see the second sample at http://dep.debian.net/deps/dep3/
[16:33] <dpb1> darinavbt: what errors are you getting?
[16:36] <darinavbt> dpb1: I get no errors in Horizon itself. It looks like it attaches. But it doesn't.
[16:36] <darinavbt> I've just started working on this over the past couple of weeks, so I'm still getting used to how it's all set up (e.g. getting into the Juju environment, what services run where, log locations, etc.)
[16:37] <darinavbt> Let me see if I can get something out of the logs for you.
[16:53] <darinavbt> In nova-compute.log on the node hosting the instance: " Failed to attach volume at mountpoint: /dev/vdb", then a stack trace, then "TypeError: Argument must be bytes or unicode, got 'NoneType'"
[16:54] <dpb1> darinavbt: what command line did you use to attach?
[16:54] <ikonia> darinavbt: so you can't connect to a virtual disk
[16:54] <darinavbt> I am using Horizon to try to attach it
[16:55] <darinavbt> No errors in Cinder logs, from what I can tell.
[16:56] <darinavbt> ikonia: Correct. I have an instance. I have a volume. I go to the instance, choose "Attach volume", Horizon says it's attaching, but it doesn't attach.
[16:57] <darinavbt> Google and I have been over and over that error and "can't attach volume to instance", etc. I see others having this issue, but no real answers. I'm actually a bit surprised that it didn't work out of the box.
[16:57] <dpb1> ya... :/  I suspect it's bit rotted a bit.
[16:58] <darinavbt> I see some "WARNING Deprecated" things in the Keystone log, but that's it.
[16:59] <darinavbt> This is a fresh installation as of two weeks ago
[16:59] <darinavbt> MAAS+Autopilot deployed. More than enough hardware according to the requirements. Everything else seems to work so far, except this.
[17:00] <dpb1> darinavbt: out of curiosity, did you check cinder.conf and if rdb_user was set?
[17:01] <dpb1> darinavbt: as you have obviously checked, google seems rife with people hitting this, and not with answers
[17:01] <darinavbt> Have a meeting. Back in a bit. yes, I think I checked that...
[17:02] <dpb1> darinavbt: https://askubuntu.com/questions/913365/openstack-autopilot-cant-attach-volume-to-an-instance -- is that a good synopsis of your problem?
[17:16] <nacc> ahasenack: i believe my comments in MP: #326034 applies to all of them for that bug, so I won't repeat the comments everywhere, if taht's ok with you.
[17:22] <ahasenack> ok
[17:25] <nacc> ahasenack: re: LP:#1669193, for the artful change, is that dropped by your merge? Can you do it in your merge?
[17:25] <nacc> ahasenack: rather than me reviewing two different changes
[17:25] <ahasenack> let me check what that is
[17:25] <nacc> sorry, LP: #1669193
[17:26] <ahasenack> yeah, I didn't include it, totally forgot about that thing
[17:26] <ahasenack> that was from the debdiff days
[17:26] <nacc> ahasenack: ok, if you want to update the bind9 merge, then i can review it as part of the merge
[17:26] <ahasenack> ok, will do
[17:26] <nacc> ahasenack: that would be one less step for me as reviewer :)
[17:27] <ahasenack> definitely
[17:27] <nacc> ahasenack: i'll update the card
[17:30] <nacc> ahasenack: i'm also going to unsub sponsors there
[17:37] <ahasenack> nacc: bind9 changes done
[17:37] <ahasenack> and lp linked the mp automatically to that bug, nice
[17:39] <darinavbt> OK. Back
[17:40] <darinavbt> dpb1: No. I don't remember seeing the libvirt errors
[17:40] <darinavbt> I'll look again, though (it's been a couple of days since I looked at this).
[17:43] <darinavbt> No. No errors in the libvirt log for that instance.
[17:44] <ahasenack> nacc: I can't find your MP comments in the openvpn-auth-ldap one, did you forget to save them perhaps? Were they inline comments?
[17:45] <dpb1> Daviey_: ok
[17:45] <dpb1> Daviey_: sry
[17:46] <dpb1> darinavbt: ok.  can you pastebin the output you are seeing that has the stacktrace in it (nova-compute.log)
[17:51] <darinavbt> dpb1: https://pastebin.com/XHsZkVxG
[17:55] <nacc> ahasenack: inline comments, let me look
[17:56] <nacc> ahasenack: ah sorry, i saved the indiv. comments but not the comemnt in the MP itself, updated just now
[17:56] <ahasenack> ah, now I see "show diff comments", cheers :)
[17:57] <nacc> ahasenack: sorry about that! TIL :)
[17:57] <ahasenack> nacc: going over it quickly, just a comment about this one: "And I believe the Author lines need to be e-mail addresses?"
[17:58] <ahasenack> nacc: I don't have his email address. It's hidden in his lp page
[18:00] <nacc> ahasenack: ah i see
[18:00] <nacc> ahasenack: i'm not sure what we're supposed to do there
[18:01] <nacc> rbasak: --^ ?
[18:02] <ahasenack> nacc: this is how he presented the fix: https://bugs.launchpad.net/ubuntu/+source/openvpn-auth-ldap/+bug/1602813/comments/0 (the original bug comment)
[18:02] <ahasenack> original description, that is
[18:02] <nacc> ahasenack: i see
[18:02] <ahasenack> I only got his name because he "signed" that comment with it
[18:02] <nacc> ahasenack: right
[18:03] <nacc> ahasenack: which sort of implies that maybe that lp id isn't actually (just) his
[18:03] <nacc> ahasenack: it's a team id (iiuc)
[18:03] <ahasenack> it sounds like a group, yes
[18:04] <ahasenack> nacc: how about this, from his gpg key: "Foxpass Engineering Team <eng@foxpass.com>"
[18:05] <nacc> ahasenack: that at least seems better :) i'm not sure how much digging is expected
[18:05] <nacc> ahasenack: as in, to find this information yourself
[18:05] <ahasenack> but incorrect credit is worse than incomplete credit
[18:06] <nacc> ahasenack: true
[18:06] <nacc> ahasenack: i guess the lp link lets them contact the user
[18:06] <nacc> ahasenack: it just feels like it doesn't fit dep3
[18:07] <ahasenack> we could also link https://launchpad.net/~foxpass-dev/+contactuser, that's more direct
[18:07] <ahasenack> or ask
[18:07] <ahasenack> but it's a 1yo bug
[18:07] <ahasenack> I can fill in the lp contact form, we can wait until tomorrow
[18:08] <nacc> ahasenack: ack, i hadn't done that digging yet, was just reviewing what was in front of me :)
[18:08] <nacc> ahasenack: maybe ask slangasek in #ubuntu-release what he would do
[18:10] <ahasenack> asking
[18:14] <dpb1> darinavbt: just to confirm, you have a xenial/ocata deployed cloud, right?
[18:15] <darinavbt> Xenial, yes
[18:16] <dpb1> ok
[18:16] <dpb1> if it's xenial with autopilot, it's ocata, that's enough
[18:16] <darinavbt> Whatever Autopilot installed for OpenStack is the version. It's not Ocata, is it?
[18:16] <darinavbt> k
[18:17] <darinavbt> Xenial, then MAAS 2.1.5, then etc.
[18:17] <dpb1> darinavbt: I might have a couple more commands for you to run, but let me do some more looking  so I don't send you on a wild goose chase
[18:18] <darinavbt> No problem.
[18:18] <darinavbt> This is my main project at the moment, so let me know what to check or what to do.
[18:21] <pettis> Has anyone else experience the boot messages being output to the shell at the login prompt/early after login? I.e. https://i.imgur.com/bXGQqV3.png .  On 16.04.2, fresh install.
[18:21] <dpb1> k
[18:22] <dpb1> pettis: that's normal, afaik.  ubuntu pushes the login prompt before it's finished everything in the boot up sequence.
[18:22] <sarnold> pettis: I haven't seen it but it's not entirely unexpected; systemd apparently fires up everything it can as soon as it can, and starting the gettys on the terminals may just happen before the other tasks, since they aren't _needed_ to be up before the gettys..
[18:22] <dpb1> darinavbt: pastebin of a `juju status` would be helpful
[18:25] <pettis> Ahhh, thank you both, that makes sense, good to know.
[18:41] <dpb1> darinavbt: also, take a look at this: https://bugs.launchpad.net/charm-nova-compute/+bug/1671422
[18:54] <dpb1> darinavbt: actually, attaching directly to that bug would be nice.
[19:04] <ahasenack> won't dep3changelog tell me what's wrong with the dep3 header? Just that it is "invalid"?
[19:04] <ahasenack> $ dep3changelog debian/patches/openvpn_ldap_timeout_fix-lp1602813.patch
[19:04] <ahasenack> debian/patches/openvpn_ldap_timeout_fix-lp1602813.patch: Invalid DEP3 header
[19:05] <nacc> ahasenack: i have some local changes that try to help with those error messages -- it's a pretty easy perl script
[19:06] <ahasenack> did you forward them upstream? :)
[19:06] <nacc> ahasenack: that messages means either no description or (no origin or no author)
[19:06] <nacc> ahasenack: not yet :)
[19:07] <ahasenack> it was an empty line
[19:07] <darinavbt> That bug I've seen
[19:07] <ahasenack> I had an empty line between the end of the (long) description, and the next field
[19:07] <darinavbt> But I'm not seeing libvirt errors
[19:07] <nacc> ahasenack: right, i think that's sort of known
[19:07] <nacc> ahasenack: basically, when `dep3changelog` sees the first all-empty line, it stops parsing
[19:07] <ahasenack> you can't suggest me to use a tool that is broken like that :)
[19:07] <nacc> ahasenack: technically it should be allowed to see one or two empty lines
[19:08] <nacc> ahasenack: well, don't have stray empty lines :)
[19:08] <nacc> ahasenack: technically they aren't supposed to be there in the headers (iirc)
[19:08] <ahasenack> I was even told in another patch to use empty lines to make it visually look better
[19:08] <nacc> ahasenack: which other patch?
[19:08] <ahasenack> it's in your queue somewhere :)
[19:08] <ahasenack> a bigger one
[19:08] <nacc> ahasenack: heh
[19:09] <darinavbt> So, ubottu and dpb1, if there's a fix for that bug, is there a patch or script to run to fix it in my deployment?
[19:09] <ahasenack> ok, so no empty lines
[19:09] <darinavbt> Or instructions, like "copy this key from here to all nova compute nodes" or something?
[19:09] <nacc> ahasenack: just going off the dep3 spec, empty lines specify the end of headers, and there can be at most two dep3 headers
[19:09] <ahasenack> ok
[19:13] <ahasenack> is this syntax correct? "  Closes LP: #1602813."
[19:13] <ahasenack> closes + lp
[19:13] <ahasenack> dep3changelog did that
[19:13] <nacc> ahasenack: it's allowed, yes
[19:13] <ahasenack> no ()?
[19:13] <nacc> ahasenack: the () are not necessary
[19:13] <ahasenack> it's a mix between debian, launchpad, and something else
[19:13] <ahasenack> ok
[19:14] <nacc> ahasenack: iirc, the regx is just looking for LP: # for ubuntu bugs and Closes: # for Debian bugs
[19:34] <darinavbt> dpb1: "juju status" output from the controller: https://pastebin.com/Rk6pAGFG
[19:37] <rbasak> nacc, ahasenack: AFAICT, there's no strict spec for the Author field. The normal style makes the most sense when available. If the email isn't known, I think it's fine for it just to be what is known - whether a name or a URL or whatever.
[19:38] <rbasak> eg. "Author: https://launchpad.net/~someone" would be fine IMHO.
[19:38] <ahasenack> ok
[19:38] <nacc> rbasak: ok
[19:40] <dpb1> darinavbt: on that bug, ask.  there might be, but posting it there will get the right people involved.
[19:40] <darinavbt> Two bugs were mentioned. You mean this one: https://bugs.launchpad.net/openstack-ansible/+bug/1697782
[19:41] <dpb1> darinavbt: your paste with juju status output and the log output will be helpful there.
[19:41] <dpb1> darinavbt: yup, that one
[19:41] <darinavbt> OK. Plus "how can I fix this?" :P
[19:42] <dpb1> yup, ask if there is a workaround on the bug
[19:45] <darinavbt> k
[19:47] <darinavbt> Done
[19:49] <dpb1> darinavbt: crap
[19:49] <dpb1> you asked and I told you the wrong one
[19:49] <darinavbt> Crap?
[19:49] <dpb1> this one please
[19:49] <dpb1> https://bugs.launchpad.net/charm-nova-compute/+bug/1671422
[19:49] <dpb1> same comment is fine.
[19:49] <dpb1> sorry!
[19:50] <darinavbt> LOL
[19:50] <darinavbt> No problem. Done.
[19:50] <dpb1> thx
[19:50] <darinavbt> Two-for-one deal ;)
[19:50] <dpb1> heheh
[19:50] <dpb1> great, perfect
[19:50] <darinavbt> Those are the same issue, though, aren't they?
[19:51] <dpb1> think so.
[19:51] <darinavbt> Just from different deployment angles.
[19:51] <dpb1> but different projects.
[19:51] <dpb1> right
[19:52] <dpb1> I added that on the 'openstack-ansible' one.
[19:52] <dpb1> 1671422 is the one that is closer to the deployment style that you are attempting, so should have the right people looking at it
[19:53] <darinavbt> Yep
[21:20] <nacc> ahasenack: are you around?
[21:41] <ahasenack> nacc: briefly, what's up?
[21:44] <nacc> ahasenack: oh it's ok, i just put some comments in the bind9 merge and though it might be easier to discuss in a HO. but we can do so tmrw too
[21:45] <nacc> ahasenack: working through the samba merge now
[21:45] <ahasenack> yes, better, thanks
[22:03] <hehehe> hey folks