| === vrubiolo1 is now known as vrubiolo | ||
| === cpaelzer__ is now known as cpaelzer | ||
| viks____ | hi, how to upgrade the cloud-init in the image when creating a fresh instance.. i want this to happen before cloud-init user data being run.. | 09:23 |
|---|---|---|
| meena | viks____: by building a fresh image with an upgraded cloud-init | 09:57 |
| viks____ | meena: thanks... but is there any other way like say if a user uploads an image to my image repo, i want to make sure that a required version of cloud-init say 19.3 is present when an instance is created out of it | 10:00 |
| meena | you could possibly add scripts to vendor-data far far either check the version and error out, or very hackishly try to update cloud-init. however, vendor-data can be overwritten by user-data… so, if your horrible hackishly scripts don't work, your users will circumvent them | 10:06 |
| viks____ | meena: ok.. thnx | 11:45 |
| Odd_Bloke | viks____: If you want cloud-init upgraded before cloud-init runs, then you can't use cloud-init to do it. And if you don't have a way of modifying the image before it launches (either to upgrade cloud-init, or to add some pre-cloud-init systemd unit that attempts something similar on boot), then I don't think there is a good way of doing it. | 13:04 |
| Odd_Bloke | viks____: What is it that drives the minimum requirement? | 13:04 |
| viks____ | Odd_Bloke: Ok.. thanks.. actually i was trying to inject root password via cloud-init for debian9 i.e. http://cdimage.debian.org/cdimage/openstack/current-9/debian-9-openstack-amd64.qcow2 for my local test openstack cluster. it seems the above image has old cloud-init and it seems that is the reason cloud-init is not able to set root password given via user-data. | 13:13 |
| viks____ | so in case if any user tries to upload the image from the above link and tries to create instance, root password injection will not work via cloud init. So i wanted to know if there is any standard way this can be upgraded to a give cloud init version | 13:13 |
| viks____ | i even tried to install manually by cloning cloud-init repo in the instance created from the above link(debian9), but installation is not successful. Also i do not find any pip packages or any prebuilt package for debian 9 | 13:16 |
| Odd_Bloke | viks____: Hmm, that sounds like something that I would expect to work even on an older version of cloud-init. What does your user-data look like? | 13:51 |
| viks____ | https://www.irccloud.com/pastebin/2k5X0RpZ/ | 13:52 |
| viks____ | which works fine on debian10 based instance | 13:53 |
| viks____ | Also i see the discussion abt the version issue here: https://forum.proxmox.com/threads/change-password-cloud-init-does-not-work.46118/ | 13:55 |
| Odd_Bloke | viks____: Hmm, I _would_ expect that to work on an older version of cloud-init. Could you pastebin /var/log/cloud-init.log from a failing instance (if you have some other way of gaining access)? | 13:57 |
| riccardom | Ciao, I'm new to the technology, and trying to understand. I see that cloud-init is strongly bound to systemd | 13:59 |
| riccardom | Is the implementation dependant on systemd? | 14:00 |
| viks____ | Odd_Bloke: here it is: http://paste.openstack.org/show/797330/.. i do not see any error in this | 14:02 |
| viks____ | i'm facing this only in debian9. most of other distributions and their versions it works fine | 14:04 |
| Odd_Bloke | riccardom: cloud-init is involved in setting things up during the boot process (generally in four different stages: https://cloudinit.readthedocs.io/en/latest/topics/boot.html), so it has to be well-integrated with the init system. However, it doesn't have to be systemd: we have upstart scripts in the upstream tree, and I believe Alpine uses OpenRC. | 14:08 |
| Odd_Bloke | One caveat: the "Generator" stage in that link is systemd-only, as it relies on systemd's generator functionality (which allows us to enable/disable services at boot time, so cloud-init won't run when it isn't needed). | 14:09 |
| Odd_Bloke | viks____: From that log, it looks like cc_set_passwords never runs. Can you paste /etc/cloud/cloud.cfg, please? | 14:12 |
| viks____ | Odd_Bloke: here it is -> http://paste.openstack.org/show/797331/ | 14:15 |
| Odd_Bloke | viks____: Hmm, it is in there. Looking back at the log, it appears to be truncated, is that really the full file? | 14:17 |
| viks____ | yes | 14:17 |
| viks____ | wait.. it seems to be getting trucated.. | 14:19 |
| viks____ | here is the remaining part -> http://paste.openstack.org/show/797334/ | 14:20 |
| Odd_Bloke | viks____: Hmm, looks like it has worked. Can you confirm for me how you're testing that it hasn't worked? (Does the password work locally but not via SSH, for example?) | 14:36 |
| viks____ | i try to login via console on openstack horizon dashboard which fails... not ssh... i also cross verified the encrypted password in userdata with the password in shadow file which are not same | 14:48 |
| Odd_Bloke | viks____: What user are you trying to login as? | 15:00 |
| Odd_Bloke | Because your cloud.cfg has things configured such that the default user will be `ubuntu` (so I would expect the password to be set on `ubuntu`, not on `root`). | 15:01 |
| === smoser1 is now known as smoser | ||
| viks____ | Odd_Bloke: Oh i see... let me try changing that in the image and create an instance.. will let you know.. | 15:33 |
| viks____ | Odd_Bloke: but we are setting it for root right as in userdata file... also even in debian10, i see debian as default user in cloud.cfg: | 15:35 |
| viks____ | https://www.irccloud.com/pastebin/AcL0ZSuT/ | 15:35 |
| viks____ | but root password works there | 15:36 |
| viks____ | it seems cloud.cfg got changed when i tried to upgrade the version manually in instance... in original image it's indeed debian: http://paste.openstack.org/show/797342/ | 15:40 |
| viks____ | also on the debian 9 instance: | 16:03 |
| viks____ | https://www.irccloud.com/pastebin/JSdKixBo/ | 16:03 |
| viks____ | whereas on debian10 instance: | 16:03 |
| viks____ | https://www.irccloud.com/pastebin/GW6ivhw5/ | 16:03 |
| meena | Good grief | 16:58 |
| apatt | Hello everyone :-) Hoping someone can tell me if what I want to do is possible. | 18:15 |
| apatt | I'm trying to create a linux image that works across multiple server vendors. I've got a base cloud-init setup working great that uses the NoCloud provider and pulls a config from a web server. That all works great. | 18:15 |
| Odd_Bloke | viks____: Hmm, I'm not 100% sure we've seen a good test with Debian 9 if you'd tried to fix the instance yourself before capturing logs etc.; would you be able to spin up a clean one and recapture stuff? (If it's easier, you can push the tarball that `cloud-init collect-logs` generates.) | 18:16 |
| apatt | However, when I push my linux image to another server that has different network interface names that doesn't work so well since my netplan configuration is in the user-data file out on the network. | 18:16 |
| apatt | So I was curious if its possible to have a local user-data file that gets the network up and then have it pull the user-data information from the network share to finish up customization | 18:17 |
| apatt | I hate baking everything into the image since I have to respin the image just to change simple things | 18:17 |
| Odd_Bloke | apatt: netplan supports matching interfaces; would using that allow you to share your network configuration across servers? | 18:19 |
| Odd_Bloke | Or are the network configurations for each instance very different? | 18:19 |
| apatt | it does, but if the netplan information is in the user-data located on the network.... so if the target server has different network interface names the network does not come up at boot so we can't reach the network to tell us what our network configuration should be ;-) | 18:20 |
| Odd_Bloke | apatt: Are you using DHCP? | 18:21 |
| apatt | YEs | 18:21 |
| apatt | write_files:- path: /etc/netplan/50-cloud-init.yaml content: | network: version: 2 ethernets: id0: match: name: eno1* dhcp4: trueruncmd:- netplan --debug apply | 18:21 |
| apatt | well that didn't format so well | 18:21 |
| Odd_Bloke | I got the gist. :) | 18:21 |
| Odd_Bloke | (But in future multiline stuff would be better in a pastebin like https://paste.ubuntu.com/ :) | 18:22 |
| Odd_Bloke | apatt: So I would expect that cloud-init should be able to perform DHCP and reach your NoCloud endpoint without you providing any network configuration, either in the image or via user-data. | 18:22 |
| apatt | At least on Ubuntu it doesn't seem to work that way | 18:23 |
| apatt | unless I'm just horribly ignorant of how netplan deals with new interface names | 18:24 |
| Folamh | Hi I've come across an issue with an issue with cc_package_update_upgrade_install.py on arch distributions. It passes "upgrade" to arch.py which would create the command "pacman -Sy --quiet --noconfirm upgrade" which should actually be "pacman -Syu --quiet --noconfirm" or "pacman -Sy --quiet --noconfirm -u". What should I do to get this addressed? | 18:25 |
| blackboxsw | Folamh: probably file a bug https://bugs.launchpad.net/cloud-init/+filebug with details | 18:26 |
| Folamh | (y) | 18:26 |
| blackboxsw | and new contributions via pushing a PR up to https://github.com/canonical/cloud-init/ also encouraged | 18:27 |
| Odd_Bloke | apatt: Apologies, NoCloud doesn't actually behave in the way I was thinking of; it's datasource-specific. | 18:27 |
| apatt | It's not the end of the world if that just isn't possible, it just means I put some basic network information into a local user-data seed and then do everything else with Ansible once the host is up and on the network. | 18:28 |
| apatt | and give up on using a user-data config from a http share | 18:29 |
| Odd_Bloke | apatt: How are you specifying where to seed from? | 18:30 |
| apatt | Odd_Bloke specifying a NoCloud datasource cloud.cfg | 18:31 |
| apatt | Odd_Bloke what I may end up doing is writing out a netplan config that brings up the local adapters by matching everything (en*) and then pulling in the new netplan information once it boots. That would elongate the boot however, since Linux is going to try and bring up all six ethernet adapters I have in my servers. Only two of them are plugged in | 18:33 |
| apatt | so we pause quite a while. | 18:33 |
| apatt | Not sure if that would get me into any timeout issues | 18:34 |
| Odd_Bloke | apatt: Would you be able to gather logs from an instance which doesn't have local netplan configuration but does have your cloud.cfg? I'd like to see what's going on. | 18:38 |
| Odd_Bloke | (A pastebin of cloud-init.log would be a good starting point. :) | 18:40 |
| apatt | Odd_Bloke I'm fairly confident that the issue is that my user-data contains this text: https://paste.ubuntu.com/p/xhVXVDbZPZ/ | 18:40 |
| apatt | but before running cloud-init the local machine only has this https://paste.ubuntu.com/p/Dxg6n9pqzH/ | 18:42 |
| smoser | apatt: write_files attempting to write that is not really going to work. | 18:45 |
| smoser | by the time cloud-init writes files, networking is already up based on what it declared. and then... runcmd of 'netplan --debug apply', maybe that would do what you wanted. | 18:46 |
| smoser | but, yuck. | 18:46 |
| apatt | smoser I agree it's not optimal, but best I could come up with. All ears if you have a better alternative. | 18:48 |
| smoser | apatt: what i think you want to do is provide network config in the nocloud seed (i suspect that is what you mean by nocloud data) | 18:49 |
| apatt | correct | 18:50 |
| smoser | https://asciinema.org/a/145772 | 18:51 |
| smoser | https://asciinema.org/a/145772 | 18:51 |
| apatt | smoser thanks, will take a look. | 18:52 |
| smoser | i think it would work to #include a url from the user-data you provided. | 18:52 |
| smoser | or maybe use seed-from | 18:53 |
| smoser | but i'm not sure if that would work or not. | 18:53 |
| smoser | if you just #include the userdata, then you're going to have to hard-code the instance-id | 18:54 |
| smoser | and then its always going to be the same instance | 18:54 |
| apatt | Since I'm using bare metal servers I'm not sure that is going to work for me since it requires using a disk image attached to the VM. | 18:58 |
| apatt | After talking to you and Odd_Bloke I think I have an idea of how to make it work though | 18:58 |
| Odd_Bloke | apatt: Let us know how you get on! :) | 19:08 |
| Odd_Bloke | smoser: So as I'm working through these manual_cache_clean docs, my initial feeling is that exposing "trust" and "check" as values for a new configuration option would be a good step forward. This would allow us to introduce other modes; the first that occurs to me is, say, "check_failsafe" which would behave as "check" does _unless_ we fail to determine the current instance ID, in which case it behaves | 20:16 |
| Odd_Bloke | as "trust" does. I think this would be a best effort solution to bug 1885527; if there's an IMDS outage then you can't launch new instances, but your existing instances aren't trampled (and when there isn't an IMDS outage, you can launch instances from captured images; "trust" would prohibit this). | 20:16 |
| ubot5 | bug 1885527 in cloud-init (Ubuntu) "cloud-init regenerating ssh-keys" [Undecided,Incomplete] https://launchpad.net/bugs/1885527 | 20:16 |
| Odd_Bloke | I don't think that's a short-term thing at all, I'm more curious as to what you think of it as an idea. | 20:17 |
| Odd_Bloke | (s/you can't launch/you won't successfully launch/) | 20:18 |
| smoser | Odd_Bloke:i'm not sure i understand. | 21:05 |
| smoser | yeah, i dont think you ever really want what you're after. | 21:08 |
| smoser | either | 21:08 |
| smoser | a.) trust the cache completely (manual_cache_clean=true) | 21:09 |
| smoser | b.) check it. | 21:09 |
| smoser | doing | 21:09 |
| smoser | c.) check it, but if that check failed, then use it. | 21:10 |
| smoser | b.) was 'check it, and if it is good use it' | 21:10 |
| smoser | i dont know. i think it generally does work correctly as it is. | 21:12 |
| smoser | (if it in fact works the way i described it is supposed to) | 21:12 |
| smoser | if you wanted to change something, then the easiest thing to change, and probably the least surprising to the end user (or at least the flurry of end-users that have come along recently) is to always trust the cache. | 21:13 |
| smoser | and just throw away the "rebundle without clean" use case. | 21:13 |
| smoser | and just document that if the user wants to take a snapshot, they have to run 'cloud-init clean' | 21:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!