| logan- | i'm having a hard time getting this config drive to render a bond | 03:09 |
|---|---|---|
| logan- | here's the network_data.json: http://paste.openstack.org/raw/723775/ | 03:09 |
| logan- | and here's cloud-init.log: http://paste.openstack.org/raw/723776/ | 03:09 |
| logan- | it looks like cloud-init is failing to find a iface['bond-master'] | 03:10 |
| logan- | looks like it was fixed by https://github.com/cloud-init/cloud-init/commit/51febf7363692d7947fe17a4fbfcb85058168ccb ...now to find out how to get a more updated cloud-init into my centos images I guess | 03:38 |
| === shardy is now known as shardy_afk | ||
| === shardy_afk is now known as shardy | ||
| smoser | caribou: did you get what you needed from me ? | 13:49 |
| caribou | smoser: I just replied to your comment | 14:52 |
| caribou | smoser: indeed, we _do_ need the possibility of changing the IP upon reboot | 14:52 |
| caribou | smoser: now I'm not against changing the way to do it though | 14:52 |
| smoser | ok. https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348000 | 14:53 |
| smoser | that is some of the code that blackboxsw is doing to suggest how we would handle this. | 14:53 |
| smoser | for "check_instance_id" we *could* just return 'True' | 14:53 |
| smoser | but that stinks... and requires then a user to "clean" before snapshotting the image | 14:54 |
| smoser | and starting a new one from it. | 14:54 |
| caribou | smoser: looks like it would fit our needs quite well | 14:57 |
| caribou | but I still need the functionality to generate the network config according to what comes from the metadata | 14:59 |
| smoser | right. | 15:06 |
| smoser | your changes generally seem correct. | 15:07 |
| smoser | or at least moving in the right direction. | 15:07 |
| caribou | smoser: so if I understand correctly, with the check_instance_id, we would only need the network_config() method w/o having to handle bringing up the network first ? | 15:11 |
| smoser | caribou: well, what would happen if you had check_instance_id. | 15:49 |
| smoser | you wouldnt bring up network ephemerally on every boot | 15:50 |
| smoser | but you also wouldnt re-write it | 15:50 |
| caribou | until your new feature comes around | 15:50 |
| caribou | might be preferable to keep it as such until the new feature comes around | 15:51 |
| caribou | which brings the question : is that feature expected to be present in the next upstream snapshot ? 'cause this is also when the 'fixed' DataSourceScaleway will hit the archive | 15:52 |
| caribou | so if both become public together, it would be preferable to have the DS use the new feature and not an obsolete behavio | 15:52 |
| caribou | behavior | 15:53 |
| caribou | since we'll be using a PPA up until it gets SRUed, I can go either way | 15:53 |
| smoser | caribou: we wont have the feature in the next few days. | 16:22 |
| caribou | smoser: oh, I understand | 16:22 |
| smoser | so i'm thinking that it might be an improvement to take your MP as it is, without the check_instance_id, which would effectively get you rendering network configuration every boot. | 16:22 |
| smoser | thats not a great scenario, but the check would not get you the feature you're after . | 16:22 |
| caribou | I think so too. My question was about the fact that, if the new feature is SRUed in the same snapshot as the update to the DS, might as well only do one change of the DS but you know the schedule better than me :) | 16:24 |
| smoser | i think i'd not bother trying to manage that. | 16:25 |
| smoser | we woudl want to avoid the check_instance_id addition until we had a solution to your "configure on boot" | 16:25 |
| smoser | but we can just do that in trunk check_instance_id wont go in until it would do what you want. | 16:26 |
| caribou | fine then | 16:27 |
| === r-daneel_ is now known as r-daneel | ||
| === r-daneel_ is now known as r-daneel | ||
| blackboxsw | smoser: or rharper have a moment to chat about https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348000? I think the discussion may be faster than review comment interaction | 20:01 |
| rharper | y | 20:02 |
| blackboxsw | thanks | 20:02 |
| blackboxsw | joining meet :) | 20:02 |
| rharper | brt | 20:03 |
| smoser | blackboxsw: | 20:38 |
| cornfeedhobo | does cloud init run bash scripts on every startup? | 21:32 |
| blackboxsw | rharper: or powersj doc trivial for new sudo:false cloud-config option that just landed https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/348252 | 22:12 |
| blackboxsw | cornfeedhobo by default it does not re-run base shell script user-data. | 22:16 |
| blackboxsw | if I provide the following userdata: it'll only get run once | 22:17 |
| blackboxsw | #!/bin/bash | 22:17 |
| blackboxsw | DATE=`date` | 22:17 |
| blackboxsw | echo "I ran" $DATE | 22:17 |
| cornfeedhobo | blackboxsw: thanks. that confirms the vague sense i got from the docs! | 22:17 |
| blackboxsw | because of semaphores blocking re-entry in /var/lib/cloud/sem/ | 22:17 |
| blackboxsw | cornfeedhobo: if you want something run per boot it would need to live in /var/lib/cloud/scripts/per-boot/ | 22:20 |
| blackboxsw | per docs @ http://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-per-boot | 22:20 |
| blackboxsw | no prob | 22:20 |
| cornfeedhobo | blackboxsw: they are at /var/lib/cloud/instance/scripts | 22:21 |
| cornfeedhobo | no symlinks to any of the scripts/per-* directories | 22:22 |
| blackboxsw | cornfeedhobo: sorry I didn't parse those coomments. On my bionic lxc container: | 22:25 |
| blackboxsw | cat /var/lib/cloud/scripts/per-boot/runme.sh | 22:25 |
| blackboxsw | #!/bin/bash | 22:25 |
| blackboxsw | DATE=`date` | 22:25 |
| blackboxsw | echo 'I RAN TOO! ' $DATE; grep RAN /var/log/cloud-init-output.log | 22:25 |
| blackboxsw | /var/log/cloud-init-output.log:I RAN TOO! Tue Jun 19 22:22:35 UTC 2018 | 22:25 |
| blackboxsw | /var/log/cloud-init-output.log:I RAN TOO! Tue Jun 19 22:23:43 UTC 2018 | 22:25 |
| blackboxsw | thx for the review powersj | 22:49 |
| powersj | that was an easy one ;) | 22:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!