| smoser | rharper, https://jenkins.ubuntu.com/server/job/cloud-init-tests/nodes=metal-ppc64el/116/display/redirect | 00:33 |
|---|---|---|
| smoser | that sysstem was deployed wiht cloud-init, so it has a file /etc/systemd/network/50-cloud-init-enP2p1s0.link | 00:34 |
| smoser | and the glob in _render_systemd_links tried to unlink it | 00:34 |
| smoser | there is a FilesystemMockingTestCase that does a lot of what you had done there. | 00:35 |
| smoser | (and also does not get glob.glob | 00:35 |
| smoser | ) | 00:35 |
| smoser | but it could and it'd be good if we did do all these things in one place. | 00:36 |
| rharper | smoser: hrm; that's really old cloud-init which emitted .link files instead of doing it manually ... | 11:33 |
| rharper | huh; I didn't think we still emitted .link files at all it 's present in the eni renderer; that can't be helpful; | 12:29 |
| phr34k | question, how do i go about verifying cloud-config file for correctness? i am trying to automate openstack provider with libcloud and running some cloud_init actions.. | 12:44 |
| phr34k | it's my first time and i can't figure out where it goes wrong in my setup | 12:45 |
| smoser | phr34k, /var/log/cloud-init.log look for WARN is the first thing. /run/cloud-init/result.json will show errors. | 13:03 |
| smoser | also /var/log/cloud-init-output.log | 13:04 |
| smoser | and the easiest thing to do to debug / quickly launch/test/cycle is lxd | 13:04 |
| === rangerpbzzzz is now known as rangerpb | ||
| smoser | lxc launch ubuntu-daily:zesty "--config=user.user-data=$(cat /tmp/mycc.cfg)" my-container | 13:04 |
| rangerpb | Odd_Bloke, heya, i updated the patch proposal. Does https://code.launchpad.net/~bbaude/cloud-init/+git/cloud-init/+merge/320411 look any better to you ? | 13:05 |
| Odd_Bloke | rangerpb: Yep, looks much better! My only comment would be to rename the method to something like "bounce_network_with_azure_hostname" as it no longer really performs a "set". | 13:10 |
| rangerpb | ok | 13:10 |
| rangerpb | Odd_Bloke, done! | 13:12 |
| phr34k | @smoser okay had a look at the files which gave me the following | 13:13 |
| phr34k | https://gist.github.com/phr34k/d8caf3f28977cc236a08e8a72e7c8210 | 13:13 |
| Odd_Bloke | rangerpb: Approved! | 13:14 |
| phr34k | is there anything suspicious about the bootcmd command, it's pretty much copied over from the documentations.. | 13:14 |
| Odd_Bloke | smoser: Can I safely land the Azure bouncing branch, or do you have other stuff going on that means you'd prefer not to ATM? | 13:14 |
| smoser | phr34k, i suspect there is some stuff in the output of cloud-init-output.log | 13:15 |
| smoser | phr34k, secondly i suspect it will tell us that you need a -F on your mkfs /dev/vdb | 13:16 |
| smoser | Odd_Bloke, will review | 13:16 |
| Odd_Bloke | smoser: Cool, thanks. :) | 13:17 |
| smoser | Odd_Bloke, rangerpb i'm just lookiong at the merge proposal, but i think that the comment on line 31 ("Bouncing" the network, same ...) is not valid as i think that both are using the *same* method there. | 13:20 |
| phr34k | @smoser maybe -i've checked some things form the output.log, related to warnings/bootcmd (updated on the gist https://gist.github.com/phr34k/d8caf3f28977cc236a08e8a72e7c8210) | 13:21 |
| smoser | als, the commit message/description needs updating | 13:21 |
| smoser | s/als/also/ | 13:21 |
| smoser | Subject\nBlank Line\nDescription | 13:21 |
| phr34k | but i'm not seeing actual references to errors / which commands go wrong in particulair / why it does wrong. | 13:22 |
| smoser | phr34k, i'm pretty sure that 'output' is not /var/log/cloud-init-output.log | 13:22 |
| smoser | that looks like /var/log/cloud-init.log | 13:23 |
| smoser | and i'm pretty sure if you just run: sudo mkfs /dev/vdb | 13:23 |
| smoser | it will fail | 13:23 |
| rangerpb | smoser, ok just fixed that comment ... by commit message, you are talking about the launchpad commit message not the git commit message right? | 13:24 |
| rangerpb | what goes in there? | 13:24 |
| smoser | rangerpb, well, the MP might have several commits, and then i "squash" it and commit with the commit message taht you provide. | 13:25 |
| smoser | so for your 1 commit, you can take that and put it into 'commit message' in the merge proosal | 13:25 |
| phr34k | ah yeah you are right, hmm it seems to complain about /dev/vdb that doesn't exists, what do the things in the [] do in specific? are they even needed for the bootcmd? | 13:25 |
| smoser | (as i could too). but please do mention ideally in the subject that this only affects (i think) the "builtin" path. | 13:26 |
| rangerpb | ok done! | 13:26 |
| rangerpb | oh | 13:26 |
| rangerpb | ok | 13:26 |
| smoser | phr34k, i dont know what you're trying to do :) | 13:27 |
| smoser | if you want to put a filesystem on /dev/vdb, then doing so is pretty important | 13:27 |
| smoser | if there is no /dev/vdb, then it would not seem so important | 13:27 |
| smoser | :) | 13:27 |
| phr34k | ah the only thing i was trying to do was add a host entry to the host file | 13:27 |
| phr34k | there is no /dev/vdb no | 13:27 |
| rangerpb | smoser, Odd_Bloke ok, see how that suits ya | 13:28 |
| smoser | rangerpb, i'm going to change the subject line of that to | 13:30 |
| smoser | Bounce network interface on Azure when using the built-in path. | 13:30 |
| smoser | and then merge | 13:30 |
| rangerpb | ok | 13:30 |
| rangerpb | totally cool with that. | 13:30 |
| smoser | rangerpb, is there a lp bug ? | 13:31 |
| rangerpb | Not that I am aware of ... this is something paulmey identified and I fixed for the built-in path | 13:31 |
| smoser | ok. thanks. | 13:32 |
| smoser | https://bugs.launchpad.net/cloud-init/+bug/1674685 | 13:37 |
| rangerpb | ah cool | 13:38 |
| smoser | rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/320495 | 13:52 |
| smoser | powersj, ^ | 13:52 |
| smoser | i verified that this was correct by making 'return_value=["/etc/passwd"]' and see it faili trying to remove that. | 13:53 |
| rharper | smoser: yes; that fixes the unittest; I'm worried that we're still writing those files in the first place | 13:55 |
| smoser | i think we should be writing them. | 13:56 |
| rharper | what effect do they have when we use ip to rename interfaces anyhow? | 13:57 |
| smoser | they're not harmful. they will be put intot the initramfs on next update, and will make less work for cloud-init to do. it does seem like duplication a bit. | 13:57 |
| rharper | now that i see we're still writing them, I'll need to look at how the interaction works with netplan | 13:58 |
| rharper | netplan will also write .link files | 13:59 |
| smoser | we only write them when rendering eni | 14:02 |
| rharper | y | 14:03 |
| rharper | btw; I don't think we should unlink the files before writing | 14:03 |
| smoser | so its pretty much the same situation as netplan will be in | 14:03 |
| smoser | we unlink ones that cloud-init wrote | 14:03 |
| rharper | sure | 14:03 |
| smoser | otherwise we end up with stale values there. | 14:03 |
| smoser | these are "owned" by cloud-init | 14:03 |
| smoser | new instance , they get wiped | 14:03 |
| smoser | (same as /etc/network/interfaces.d/50-cloud-init.cfg) | 14:04 |
| rharper | yeah; I was thinking we wouldn't touch it if we've nothing to write; | 14:04 |
| smoser | rharper, do you want to approve that? | 14:12 |
| smoser | i'm willing to entertain investigation into whether ornot those should be written in eni path. | 14:12 |
| smoser | since cloud-init will set the names itself. i think we ended up writing them so they'd get into the initramfs | 14:13 |
| smoser | other wise, later attempts would fail due to the "only rename once" thing... | 14:13 |
| rharper | smoser: I think it's fine to clean those up; as you say, cloud-init owns them; | 14:14 |
| smoser | and then, we decided that in order to support renaming of nics in lxc we had to do it ourselves. | 14:14 |
| rharper | well, with ip rename in cloud-init itself, those files just don't matter nor the logic of systemd won't rename; we're doing it anyhow | 14:14 |
| smoser | (because no matter what, systemd will refuse to rename those devices that are guaranteed to have been renamed once (from tap-XXXXXX to ethX by lxd)) | 14:14 |
| smoser | right. the value is on update-initramfs and reboot, there is *less* movement of things. | 14:15 |
| smoser | but the end result should be the same. so it is arguable that they're confusing duplication. | 14:15 |
| rharper | we could look at transitioning | 14:15 |
| smoser | at least those are the cases that i remember. | 14:15 |
| rharper | we'd stop writing, but continue removing | 14:15 |
| smoser | you do remember all the fun we had getting this right the first time :) | 14:16 |
| rharper | that is, we would really want them to linger | 14:16 |
| rharper | "fun" | 14:16 |
| rharper | I'm still having that fun every time I touch a .service .link or .network file | 14:16 |
| smoser | yeah. and i'm afraid that there is probably some use case that i'm not thinking of. | 14:17 |
| rharper | smoser: what other paths will cloud-init look in for initial system config? I think we have /etc/cloud/cloud.cfg.d/* and /run/cloud-init/*.cfg ; do we have like a /usr/lib/cloud/cloud.cfg ? | 14:34 |
| rharper | smoser: I'm poking at the UC16 case where UC16 bind mounts files or dirs on top of /etc/cloud/cloud.cfg.d (it can't do a union mount as I would prefer); which means things like the default logging config and other things end clobbered by the mount, or we have to duplicate them into the writable partition when we create the image | 14:36 |
| rharper | if we had say a /usr/lib/cloud/cloud.cfg.d/* we could move things like 05_logging.cfg and other system defaults there, leaving /etc/cloud/cloud.cfg.d for clobbering ... and I suppose we wouldn't even have to change the default location of those files from etc to the system path; as long as cloud-init also read from that location (UC16 could move them during it's core snap build) | 14:37 |
| smoser | rharper, it seems to me that maybe uc16 needs to change. i'm really sort of adverse to adding yet another location for config files. | 14:49 |
| rharper | smoser: k | 15:00 |
| smoser | do you disagree? | 15:01 |
| rharper | smoser: not entirely sure; to some degree it wouldn't be bad to have the same system, etc, run config paths; that would let cloud-init set it's defaults in /usr/lib/cloud/* ; and then override those wil files from etc or run; that said; there are two issues 1) this is a change in default behavior w.r.t location of these files (if we updated the packaging; the core snap could move them there if we didnt) 2) it certa | 15:17 |
| rharper | inly introduces yet another path for config (which has positives and negatives) | 15:17 |
| === shardy is now known as coding_shardy | ||
| === coding_shardy is now known as shardy | ||
| smoser | rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/320555 | 20:35 |
| powersj | smoser: https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/320560 something for us to talk through at somepoint | 21:38 |
| === rangerpb is now known as rangerpbzzzz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!