=== tds7 is now known as tds
[00:40] <blackboxsw> rharper: https://github.com/canonical/cloud-init/pull/308 is updated. and so is https://github.com/CanonicalLtd/uss-tableflip/pull/45
[00:41] <blackboxsw> new instructions :)
[00:41] <blackboxsw> will check back later
[00:41] <blackboxsw> otherwise we can do this in the morning.
=== hjensas is now known as hjensas|afk
[09:53] <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
=== vrubiolo1 is now known as vrubiolo
=== hjensas|afk is now known as hjensas
[13:09] <andras-kovacs> marlinc:  search around for docker image bulding best practices
[13:10] <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:37] <Odd_Bloke> marlinc: Are you asking because you're seeing issues, or just to be sure?
[14:46] <marlinc> Just to be sure Odd_Bloke, there's just tons if things that generated and its easy to forget something
[14:47] <marlinc> Systemd's /etc/machine-id for example, I don't think I'm deleting that rigth now
[14:49] <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:50] <Odd_Bloke> I don't know that we have much documentation around what else you might want to clean up.
[15:15] <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:17] <rharper>  find / -xdev -cnewer /etc/machine-id
[15:37] <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.)
[17:26] <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:48] <HellMInd> Hello!
[17:56] <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 :)
[18:10] <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:13] <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:37] <rharper> blackboxsw: yes, I'll review both today
[18:41] <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:42] <HellMInd> But how can I set that rule.
[18:42] <HellMInd> I need to do some post-up  cmds, not just the ip
[18:49] <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:51] <HellMInd> yes
[18:52] <HellMInd> I need a way to change the network templates to add some static routes
[18:54] <Odd_Bloke> When you say "the network templates", you mean /etc/network/interfaces{,.d/*}?
[18:55] <HellMInd> I think cloud-init uses some template to add  the interface file. But im not sure
[18:56] <HellMInd> cloud init isnt uses : /etc/cloud/cloud.cfg/custom-networking.cfg ?
[19:09] <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:13] <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:14] <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:17] <HellMInd> I did this, but no change: https://prnt.sc/ruxzbs
[19:22] <HellMInd> "not a new instance. network config is not applied" says :S
[19:24] <HellMInd> I dont  know  if that is some error,
[19:25] <HellMInd> how can I debug that .cfg
[19:32] <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:33] <HellMInd> tharper, if I want to change the ip from  proxmox?
[19:34] <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:35] <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:39] <HellMInd> devel: error  argument subcomman : invalid choice net'convert
[19:41] <rharper> hrm, what version of cloud-init ?
[19:42] <HellMInd> 18.3
[19:43] <rharper> just shy, landed in 18.4
[20:11] <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
=== 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
[20:24] <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:26] <Goneri> review of https://github.com/canonical/cloud-init/pull/298 welcome.
[20:29] <blackboxsw> Goneri: good reminder. cheers. will get some eyes on this today
[22:04] <blackboxsw> https://github.com/canonical/cloud-init/pull/308 and https://github.com/CanonicalLtd/uss-tableflip/pull/45 good
[22:35] <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:36] <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:38] <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:39] <blackboxsw> so the manual steps would be longer
[22:46] <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:51] <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:52] <rharper> sorry
[22:52] <rharper> here
[22:53] <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:54] <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:55] <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:56] <blackboxsw> and we can support the pop-all and push-all
[22:57] <rharper> I'm going to have to run now; let's discuss tomorrow;
[22:57] <blackboxsw> rharper: will do take care