| === tds7 is now known as tds | ||
| blackboxsw | rharper: https://github.com/canonical/cloud-init/pull/308 is updated. and so is https://github.com/CanonicalLtd/uss-tableflip/pull/45 | 00:40 |
|---|---|---|
| blackboxsw | new instructions :) | 00:41 |
| blackboxsw | will check back later | 00:41 |
| blackboxsw | otherwise we can do this in the morning. | 00:41 |
| === hjensas is now known as hjensas|afk | ||
| marlinc | Are there some official Ubuntu instructions on how to clean an image after a build for the next boot? I'm already running a cloud-init clean, deleting SSH host keys and clearing apt caches | 09:53 |
| === vrubiolo1 is now known as vrubiolo | ||
| === hjensas|afk is now known as hjensas | ||
| andras-kovacs | marlinc: search around for docker image bulding best practices | 13:09 |
| andras-kovacs | and don't forget to reset the /etc/machine-id | 13:10 |
| andras-kovacs | Do any of you know why runcmd doesn't work at all on a machine which uses LVM? | 13:10 |
| Odd_Bloke | marlinc: Are you asking because you're seeing issues, or just to be sure? | 13:37 |
| marlinc | Just to be sure Odd_Bloke, there's just tons if things that generated and its easy to forget something | 14:46 |
| marlinc | Systemd's /etc/machine-id for example, I don't think I'm deleting that rigth now | 14:47 |
| Odd_Bloke | So cloud-init will detect that it's running on a new instance, even without a clean, and regenerate host keys etc. | 14:49 |
| Odd_Bloke | I don't know that we have much documentation around what else you might want to clean up. | 14:50 |
| rharper | marlinc: it's really quite difficult. I do have some hand tuned files that I remove to return an image to "pristine" ; it's not exhaustive; I started with running find . -cnewer /etc/machine-id ; it's challenging to know which files are created or modified; and to know that, you need to have the filesystem layout captured *before* it's been booted; and then you can diff the two lists and then make some patters for removal | 15:15 |
| rharper | find / -xdev -cnewer /etc/machine-id | 15:17 |
| Odd_Bloke | For most cases, you don't need to restore an image to it's fully pristine state. (That's more of a concern for us when testing, because we want to ensure that cloud-init behaves properly specifically against a pristine image.) | 15:37 |
| HellMInd | Hello! | 17:26 |
| HellMInd | Im trying to use proxmox ovh, but in otder to use cloud init to assign an ip , i need an static route to make the gw valid. How should I do that ? | 17:26 |
| HellMInd | Hello! | 17:48 |
| sarnold | hey HellMInd, the webchat is working fine, I've just got no idea, and others who might are probably occupied elsewhere for the moment :) | 17:56 |
| blackboxsw | rharper: if there is time today. all instructions are updated on https://github.com/canonical/cloud-init/pull/308 and https://github.com/CanonicalLtd/uss-tableflip/pull/45 | 18:10 |
| Odd_Bloke | HellMInd: I'm not sure I fully understand the question. Could you explain the problem you're having in a bit more detail? | 18:13 |
| rharper | blackboxsw: yes, I'll review both today | 18:37 |
| HellMInd | Im using Proxmox, and I want to create a debian kvm template | 18:41 |
| HellMInd | So i need to use cloud init to assign an ip | 18:41 |
| HellMInd | Since my box is in ovh, you need to setup a fake route to enable the gw because its outside subnet | 18:41 |
| HellMInd | But how can I set that rule. | 18:42 |
| HellMInd | I need to do some post-up cmds, not just the ip | 18:42 |
| Odd_Bloke | Let me make sure I'm understanding right: you're running Proxmox on an OVH node, and you would like to configure the instances launched on Proxmox with network configuration? | 18:49 |
| HellMInd | yes | 18:51 |
| HellMInd | I need a way to change the network templates to add some static routes | 18:52 |
| Odd_Bloke | When you say "the network templates", you mean /etc/network/interfaces{,.d/*}? | 18:54 |
| HellMInd | I think cloud-init uses some template to add the interface file. But im not sure | 18:55 |
| HellMInd | cloud init isnt uses : /etc/cloud/cloud.cfg/custom-networking.cfg ? | 18:56 |
| rharper | HellMInd: https://cloudinit.readthedocs.io/en/latest/topics/network-config.html ; it's not a template; instead cloud-init will read configuration files written to disk, or in some platforms, it reads the configuration from a metadata-service ; | 19:09 |
| rharper | if you need a static route, there are a few examples; static routes in eni are added as post-ups , https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v1.html | 19:13 |
| blackboxsw | Odd_Bloke, or rharper, if there is time, can you peek at a json schema addition that needs eyes https://github.com/canonical/cloud-init/pull/152? | 19:14 |
| blackboxsw | I didn't want it to timeout and get closed | 19:14 |
| rharper | blackboxsw: ok | 19:14 |
| HellMInd | I did this, but no change: https://prnt.sc/ruxzbs | 19:17 |
| HellMInd | "not a new instance. network config is not applied" says :S | 19:22 |
| HellMInd | I dont know if that is some error, | 19:24 |
| HellMInd | how can I debug that .cfg | 19:25 |
| rharper | HellMInd: after each change, you'll want to cloud-init clean ; which will remove the instance-id file and tell cloud-init that it's booting a new instance .. | 19:32 |
| HellMInd | thank you rharper | 19:32 |
| HellMInd | tharper, if I want to change the ip from proxmox? | 19:33 |
| rharper | HellMInd: also, you can manually render the file, this is an awkward interface, but it exists: cloud-init devel net-convert --network-data /path/to/input.cfg --kind yaml --distro <debian|ubuntu> --output-kind eni --directory /tmp/test-network-config/ | 19:34 |
| rharper | HellMInd: I'm not sure what you mean? If you have proxmox give you a different IP for a VM, you'll need to reset cloud-init with the 'clean' command and reboot; | 19:35 |
| HellMInd | devel: error argument subcomman : invalid choice net'convert | 19:39 |
| rharper | hrm, what version of cloud-init ? | 19:41 |
| HellMInd | 18.3 | 19:42 |
| rharper | just shy, landed in 18.4 | 19:43 |
| HellMInd | dont know how to test the damn cfg, | 20:11 |
| HellMInd | I just need to see some error, there are no error on log files | 20:11 |
| === powersj changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting April 14 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug | ||
| blackboxsw | rharper: if you haven't reviewed https://github.com/canonical/cloud-init/pull/308 or https://github.com/CanonicalLtd/uss-tableflip/pull/45 yet, I think I can further simpify debian/cloud-init-cherry-picks by dropping the 'applied' column in that file. | 20:24 |
| blackboxsw | any objections to be force pushing new ubuntu/devel based on that ? | 20:24 |
| blackboxsw | any objections to *me* force pushing a new commit? | 20:24 |
| Goneri | review of https://github.com/canonical/cloud-init/pull/298 welcome. | 20:26 |
| blackboxsw | Goneri: good reminder. cheers. will get some eyes on this today | 20:29 |
| blackboxsw | https://github.com/canonical/cloud-init/pull/308 and https://github.com/CanonicalLtd/uss-tableflip/pull/45 good | 22:04 |
| rharper | blackboxsw: ok, finished my review, but not before you've pushed more changes; sorry some local drama interceded; one question though; should we land the cloud-init PR to fix ubuntu/devel while we work on improving #45 ? or should we get #45 in shape first and then redo the cloud-init PR ? | 22:35 |
| blackboxsw | rharper: I had drama related to that changeset too. I'm sorry about that. I wanted to make sure we were in a good state currently on ubuntu/devel by performing that initial "git add debian/cloud-init-cherry-picks; git commit -am 'Add debian/cherry-picks file" | 22:36 |
| blackboxsw | rharper: I suppose we could address the debian/cloud-init-cherry-pick* files afterwards. | 22:38 |
| blackboxsw | that'd make 308 a standalone | 22:38 |
| blackboxsw | yet you wouldn't have the --pop-all option for cherry-pick. | 22:38 |
| blackboxsw | so the manual steps would be longer | 22:39 |
| blackboxsw | hrm, you think it's worth maybe having cherry-pick put up a temporary tag before cherry-picking to ensure we reset back upon failure? | 22:46 |
| blackboxsw | rharper: ^? | 22:46 |
| blackboxsw | hrm this --push-all is gonna be fragile especially if we have to use quilt directly to refresh patches (which then has no knowledge to update debian/cloud-init-cherry-picks with new commitishes) | 22:51 |
| rharper | sorry | 22:52 |
| rharper | here | 22:52 |
| blackboxsw | I worry about putting too much stock in designing a fully-featured cherry-pick cmd. as generally I think initially we want to just fix daily recipe or revert all | 22:53 |
| blackboxsw | as most of our releases also tend to be new-upstream-snapshots too | 22:53 |
| blackboxsw | but I don't know the best path forward here at the moment. | 22:54 |
| blackboxsw | I really think we need to unblock daily recipe builds on focal for testing purposes | 22:54 |
| rharper | I guess it just seems to me that if we can push a single one on, we can pop one off.; | 22:54 |
| blackboxsw | rharper: we can, but I tried being smart and collectively doing that in bulk to avoid git commit log noise | 22:55 |
| blackboxsw | but, again, it's probably not worth the effort there given how complex I've made it | 22:55 |
| blackboxsw | so, if individual push/pop noise is acceptable during cherry-pick reverts an re-applies, then it will make the tooling simpler | 22:55 |
| rharper | ok, I see where you're coming from | 22:55 |
| blackboxsw | and we can support the pop-all and push-all | 22:56 |
| rharper | I'm going to have to run now; let's discuss tomorrow; | 22:57 |
| blackboxsw | rharper: will do take care | 22:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!