=== sambetts_ is now known as sambetts
[13:23] <smoser> powersj, I think you opened a bug for https://jenkins.ubuntu.com/server/view/Cloud-init/job/cloud-init-style/38/console right ?
[13:26] <powersj> smoser: yes
[13:26] <smoser> link ?
[13:54] <powersj> https://github.com/PyCQA/pylint/issues/1444
[14:04] <smoser> powersj, thats a good quality bug report.
[14:04] <smoser> thank you
[14:36] <smoser> powersj, or blackboxsw https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324401
[14:36] <smoser> fiddle.
[14:36] <smoser> got an extra commit. will fix
[14:37] <smoser> fixed
=== smatzek_ is now known as smatzek
=== rangerpbzzzz is now known as rangerpb
[15:53] <smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324401
[15:54] <smoser> the reason i use os.path.sep.join is that os.path.join("/etc", "/passwd") ends up giving you "/passwd"
[15:54] <smoser> which i think is just horrible
[15:56] <smoser> $ python -c 'import os, sys; print("sep.join: %s" % os.path.sep.join(sys.argv[1:])); print("path.join: %s" % os.path.join(*sys.argv[1:]))' /etc /passwd
[15:56] <smoser> sep.join: /etc//passwd
[15:56] <smoser> path.join: /passwd
[16:07] <smoser> powersj, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324401
[16:08] <smoser> do you know... do we re-use .tox in c-i ? will we have to kill something to make it refresh tox ?
[16:09] <powersj> smoser: not sure I follow. What do you mean refresh tox?
[16:11] <smoser> tox -e pylint
[16:11] <smoser> that installs stuff into .tox/pylint
[16:11] <powersj> ah ok
[16:11] <smoser> and (i think) subsequent runs of 'tox -e pylint' will *not* freshen .tox/
[16:11] <powersj> In CI we use a new directory for every run
[16:11] <smoser> i m ight be wrong.
[16:11] <smoser> ok, then yeah, that should be fine.
[16:11] <powersj> yeah
[16:11] <powersj> fresh check out too
[16:12] <smoser> ok. so can you ack that MP ?
[16:13] <powersj> oh yeah - sorry about not catching the diff. Launchpad has been doing that to me as well
[16:14] <powersj> done
[16:14] <smoser> yeah, annoyinng
[16:14] <smoser> we shoudl probably open a bug
[16:14]  * smoser does that
[16:26] <seanbright> are user questions on topic here?
[16:27] <smoser> seanbright, sure
[16:27] <smoser> powersj, filed at https://bugs.launchpad.net/launchpad/+bug/1692571
[16:27] <ubot5> Ubuntu bug 1692571 in Launchpad itself "sometimes diff shown in git merge proposal is not updated" [Undecided,New]
[16:27] <powersj> smoser: thx
[16:28] <seanbright> smoser: i'm actually reading a bug report now that may answer my question. back in a tick.
[16:28] <smoser> k
[16:31] <blackboxsw> smoser: +1 I thought that the values coming out of pkg-config  would be the root path /..././.   and since we are adding a string which setup controls, ''systemd-fsck@.service.d' we shouldn't hit that issue. But defensive programming makes sense.
[16:35] <seanbright> smoser: was looking for an elegant solution to this -> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1153626
[16:35] <ubot5> Ubuntu bug 1153626 in cloud-init (Ubuntu) "Multiple Interfaces and IPs not detected in AWS VPC" [Medium,Triaged]
[16:35] <seanbright> oh. fancy bot.
[16:36] <seanbright> but i'll just try to work with some of the suggested work arounds mentioned there
[16:44] <smoser> seanbright, well, there is a path to that now..
[16:45] <smoser> but it still takes some dev work
[16:45] <smoser> we are hoping to address it
[16:47] <smoser> seanbright, its been quite some time since we'd have loved to have a solution for that. :-(
[16:53] <seanbright> i might take a stab at it
[16:53] <seanbright> but no promises
[17:05] <smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324338 i'd appreciate a 'please fix these things' or 'approve' i've resaponded to your comemnts
[17:06] <smoser> and also blackboxsw or rharper on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324274
[17:12] <rharper> smoser: ok
[17:13] <smoser> and i'll trade for a bcache review now
[17:13]  * smoser finds
[17:40] <powersj> rharper: seems your ntp changes broke the integration tests over the weekend from https://bugs.launchpad.net/cloud-init/+bug/1645644
[17:40] <ubot5> Ubuntu bug 1645644 in cloud-init (Ubuntu) "ntp not using expected servers" [Medium,In progress]
[17:40] <rharper> smoser: when I examine the journalctl of cloud-init units (in xenial up through artful) I don't see any DEBUG level items, just stdout/stderr
[17:40] <powersj> I noticed you made updates to the tests too, but the user-data pools are not found in the output
[17:40] <rharper> powersj: likely fubar'ed the merge
[17:41] <rharper> basically we run ntpd -q to dump what servers it found; and compare that with the user-data
[17:41] <rharper> do we have the artifacts ?
[17:42] <rharper> smoser: comparing /var/log/cloud-init.log vs. journalctl output  ; that's how I know there are messages being emitted but not showing up in the unit log ... thoughts on what changed ?
[17:42]  * powersj adds a card to keep artifacts from integration tests O.o
[17:42] <powersj> let me get you a copy of them
[17:42] <rharper> k
[17:44] <powersj> here is what ntpq_servers produces https://paste.ubuntu.com/24625221/
[17:44] <rharper> that looks like the defaults
[17:44] <rharper> vs. what we may have put in there
[17:44] <rharper> in the user-data configuration
[17:44] <powersj> ntp_conf_pools https://paste.ubuntu.com/24625227/
[17:45] <rharper> yeah, and we'll need the written ntp.conf file
[17:45] <rharper> and the cloud-init.log (which should log what it wrote)
[17:46] <powersj> http://paste.ubuntu.com/24625234/
[17:46] <powersj> My run command: tox -e citest -- run -n xenial -t modules/ntp_pools
[17:47] <powersj> ah actually my local run won't have your change in cloud-init
[17:48] <powersj> so I need to run with the local tree real quick and get the failure the jenkins job saw, since it runs with a locally build "daily" cloud-init
[17:48] <rharper> yes
[17:48] <rharper> it looks like it rendered template, but didn't restart ntpd (which is what the fix does)
[17:49] <rharper> we should see a run_cmd doing systemctl reload-or-restart or a 'service ntp restart'
[17:49] <rharper> in the log
=== sambetts is now known as sambetts|afk
[18:01] <smoser> rharper, ok. back. finished your bcache review request
[18:01] <rharper> thanks, I'll check
[18:02] <smoser> rharper, right. you dont see those in stderr and stdout any more . you actually never were supposed to. i forget the change that fixed that.
[18:02] <rharper> =(
[18:02] <rharper> well, it breaks cloudinit-analyze working with journalctl output
[18:02] <smoser> but by default running 'cloud-init' shouldnt just  print debug level sutff to stdout. intstead it logs to console.
[18:02] <smoser> er... to log file.
[18:02] <rharper> which has high res timers
[18:02] <smoser> log file shoudl now have high res timers
[18:02] <smoser> right?
[18:02] <rharper> lemme see
[18:02] <smoser> as we are not going through syslog
[18:03] <rharper> micro second
[18:03] <rharper> better than second level
[18:03] <smoser> well, millisecond
[18:03] <rharper> ah, yes
[18:03] <smoser> 1000th
[18:03] <rharper> ack
[18:03] <smoser> milli? micro
[18:03] <smoser> yeah, your'e right
[18:03] <rharper> milli IIRC
[18:03] <rharper> at least subsecond =)
[18:03] <smoser> i suspect that we weren't really getting prcision better than that (or not *much*) better than that
[18:04] <rharper> I did enjoy getting cloud-init verbose output from journal, but understand w.r.t debug
[19:19] <powersj> smoser: https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/324429 fix for ntp failures
[19:19] <powersj> smoser: https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/324430 fix for snappy failure on proposed/artful tests
[19:28] <powersj> rharper: thx for the reviews, just updated the snappy one with my comments. 100% open to ideas on how to work around this one.
[19:32] <rharper> ack
[19:32]  * rharper goes to pickup kiddo
[19:34] <smoser> powersj, thank you for that.
[19:36] <smoser> rharper, since you had done merge back and forth, a rebase was non-trivial, and that function actually was a collision and i had to resolv by hand.
[19:36] <smoser> its much easier to handle a rebase since ultimately thats what i'm after.
[19:37] <smoser> it was kind of disappointing that i couldnt just 'rebase -i' and squash stuff on your branch.
[19:41] <smoser> powersj, https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/324429
[19:41] <smoser> clean that up and i'll grab it quick
[19:41] <powersj> smoser: heh on it
[19:43] <powersj> smoser: done
[19:56] <rharper> smoser: I'm happy to know how to handle those in the future ... I end up doing a rebase -i twice, once when I merge in master and then again after I push to my -u branch
[19:58] <rharper> I know some folks --force push but I'd prefer to not do that;   it's strange to me (and I'm sure I don't understand what git's doing) that I can't have my remote branch pull in the rebase from master and have it fast-forward to apply the actual changes
[20:00] <smoser> rharper, twice ?
[20:00] <rharper> in my local branch, I git rebase -i master
[20:00] <rharper> replay and fix it up against master;, then I git push -u raharper ... and it fails, saying I need to merge changes
[20:01] <rharper> so then I git pull from my remote, and it has the  same conflicts that I had to resolve when I did my rebase -i on master
[20:01] <smoser> ah.
[20:01] <smoser> so yeah, rebase and having to 'push --force' does stink
[20:01] <rharper> the only thing that's worked is if I rework the patch before rebasing it
[20:01] <smoser> i always do:
[20:01] <smoser>  git rebase -i master
[20:01] <smoser>  git push smoser HEAD
[20:01] <rharper> ah
[20:01] <smoser> and with --force
[20:01] <rharper> oh
[20:01] <smoser> but then the single branch gets pushed
[20:02] <smoser> not all my branches, as yeah, that'd be scary.
[20:02] <rharper> it sorta feels like we're missing something
[20:02] <smoser> well, rebase pretty much is always going to require a push --force i think
[20:02] <smoser> right ?
[20:02] <rharper> like it seems of little use to git push -u if I'm going to have to do that
[20:02] <smoser> it *is* not a strict fast forward.
[20:02] <rharper> maybe; I don't think I know enough git to answer clearly
[20:02] <rharper> it seems like I want to push HEAD into the remote
[20:03] <rharper> and then "remotely rebase"
[20:03] <rharper> ie, we should only need to do the rebase once
[20:03] <rharper> the changes are *identical*
[20:03] <smoser> well, push is just dumb. it pushes what you have here over there.
[20:03] <rharper> since it's a mirror of operations
[20:03] <rharper> I mean, I do as you say, git fetch origin, git rebase -i master (fix up and complete rebase);
[20:04] <rharper> I should be able to update origin at my remote; and then replay the same rebase operations
[20:04] <rharper> says the non-git-expert
[20:04] <smoser> well, push is just dumb. in that all it does is set refs. it doesn't do stuff on the server othe rthan that (and check that it is "fast-forward" or not)
[20:04] <rharper> yeah
[20:05] <rharper> but force just overwrites things
[20:06] <rharper> seems like it could figure it out but I don't really know enough
=== x58 is now known as TerceroEquis
=== TerceroEquis is now known as x58
[20:52] <paulmey> Hi smoser, I just saw your comment re https://bugs.launchpad.net/cloud-init/+bug/1692093 ...
[20:52] <ubot5> Ubuntu bug 1692093 in cloud-init "Cloud init is re-executing fs and disk setup during reboot" [Undecided,Confirmed]
[20:53] <paulmey> we actually also have the same exact issue with new instances that attach an already prepared data disk
[20:53] <paulmey> it gets wiped, even when the fs_setup info matches...
[20:53] <paulmey> I agree that we shouldm'
[20:53] <paulmey> shouldn't run cc_disk_setup on every boot, just to catch the ephemeral disk...
[20:55] <paulmey> but somehow, we also have to figure out a way to get good answers from lsblk that aren't dependent on timing...
=== nacc_ is now known as nacc
[21:51] <paulmey> left a comment on the review...