| === sambetts_ is now known as sambetts | ||
| 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:23 |
|---|---|---|
| powersj | smoser: yes | 13:26 |
| smoser | link ? | 13:26 |
| powersj | https://github.com/PyCQA/pylint/issues/1444 | 13:54 |
| smoser | powersj, thats a good quality bug report. | 14:04 |
| smoser | thank you | 14:04 |
| 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:36 |
| smoser | fixed | 14:37 |
| === smatzek_ is now known as smatzek | ||
| === rangerpbzzzz is now known as rangerpb | ||
| smoser | blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324401 | 15:53 |
| 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:54 |
| 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 | 15:56 |
| smoser | powersj, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324401 | 16:07 |
| smoser | do you know... do we re-use .tox in c-i ? will we have to kill something to make it refresh tox ? | 16:08 |
| powersj | smoser: not sure I follow. What do you mean refresh tox? | 16:09 |
| 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:11 |
| smoser | ok. so can you ack that MP ? | 16:12 |
| powersj | oh yeah - sorry about not catching the diff. Launchpad has been doing that to me as well | 16:13 |
| powersj | done | 16:14 |
| smoser | yeah, annoyinng | 16:14 |
| smoser | we shoudl probably open a bug | 16:14 |
| * smoser does that | 16:14 | |
| seanbright | are user questions on topic here? | 16:26 |
| 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:27 |
| seanbright | smoser: i'm actually reading a bug report now that may answer my question. back in a tick. | 16:28 |
| smoser | k | 16:28 |
| 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:31 |
| 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:35 |
| seanbright | but i'll just try to work with some of the suggested work arounds mentioned there | 16:36 |
| smoser | seanbright, well, there is a path to that now.. | 16:44 |
| smoser | but it still takes some dev work | 16:45 |
| smoser | we are hoping to address it | 16:45 |
| smoser | seanbright, its been quite some time since we'd have loved to have a solution for that. :-( | 16:47 |
| seanbright | i might take a stab at it | 16:53 |
| seanbright | but no promises | 16:53 |
| 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:05 |
| smoser | and also blackboxsw or rharper on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324274 | 17:06 |
| rharper | smoser: ok | 17:12 |
| smoser | and i'll trade for a bcache review now | 17:13 |
| * smoser finds | 17:13 | |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| powersj | http://paste.ubuntu.com/24625234/ | 17:46 |
| powersj | My run command: tox -e citest -- run -n xenial -t modules/ntp_pools | 17:46 |
| powersj | ah actually my local run won't have your change in cloud-init | 17:47 |
| 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:48 |
| rharper | we should see a run_cmd doing systemctl reload-or-restart or a 'service ntp restart' | 17:49 |
| rharper | in the log | 17:49 |
| === sambetts is now known as sambetts|afk | ||
| smoser | rharper, ok. back. finished your bcache review request | 18:01 |
| rharper | thanks, I'll check | 18:01 |
| 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:02 |
| 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:03 |
| rharper | I did enjoy getting cloud-init verbose output from journal, but understand w.r.t debug | 18:04 |
| 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:19 |
| 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:28 |
| rharper | ack | 19:32 |
| * rharper goes to pickup kiddo | 19:32 | |
| smoser | powersj, thank you for that. | 19:34 |
| 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:36 |
| smoser | it was kind of disappointing that i couldnt just 'rebase -i' and squash stuff on your branch. | 19:37 |
| 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:41 |
| powersj | smoser: done | 19:43 |
| 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:56 |
| 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 | 19:58 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| rharper | but force just overwrites things | 20:05 |
| rharper | seems like it could figure it out but I don't really know enough | 20:06 |
| === x58 is now known as TerceroEquis | ||
| === TerceroEquis is now known as x58 | ||
| 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:52 |
| 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:53 |
| paulmey | but somehow, we also have to figure out a way to get good answers from lsblk that aren't dependent on timing... | 20:55 |
| === nacc_ is now known as nacc | ||
| paulmey | left a comment on the review... | 21:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!