=== cpaelzer__ is now known as cpaelzer [09:13] HEllo [09:13] Somone there to help me understand how datasource priority is working on cloud-init ? [12:47] PandemiK: There are a few people who may be able to help; go ahead and ask your question and you'll find out. :) [13:12] Ok, I just don't want to bother you with some noob question [13:12] Thanks ;-) [13:13] I'm using CI with Proxmox VE. In PVE, we cannot alter meta-data and user-data generated by PVE has iso9660 nocloud source [13:13] I'm trying to add another user-data source and merge it with PVE's one [13:14] So I thought I could go ahead with smabios settings [13:14] So I thought I could go ahead with smbios settings [13:14] But where settings something like "ds=nocloud-net;s=https://dev.altinea.fr/" [13:15] The files on the iso9660 are not used anymore. Any idea howto to 'merge' them without touching the PVE user-data file ? [13:16] Access to the user data file is public : https://dev.altinea.fr/user-data [13:16] I tried to setup merge_how on top a the file [13:17] perhaps could I add some #include ? Is that possible with a iso9660 file (cidata) ? [13:26] How to set an interface to promisc mode? [13:35] PandemiK: So the best way to do this would be to use multi-part user-data with an include, but that would require the user-data provided by Proxmox VE to be modified. [13:36] that's my fear [13:36] I also wrote a little patch for PVE that add support for vendor-data [13:36] That does the job (installing ssh keys and a few packages) but need to integrate a patch to PVE [13:37] And having a patch into mainstream PVE would be ... long [13:37] PandemiK: If that is immutable, then it becomes substantially more complicated; cloud-init expects to fetch its NoCloud configuration from a single source (e.g. an ISO, or a remote URL), so changing the configuration of the instance away from PVE's ISO will mean that you no longer get the metadata which PVE provides, which is likely to cause problems. [13:38] without PVE's iso9660 source, we don't have fqdn for example [13:38] which means creating a file for each VM, not wanted [13:38] I'm not sure I follow; why would that imply "creating a file for each VM"? [13:39] Is there a way to provide only vendor-data from a URL with smbios version setting ? [13:40] PVE generate some interesting config inside it's 'own' user-data : fqdn and hostname parameter, derived directly from the VM's name [13:41] everything else seems to be vm-agnostic so I could set it in another file (from a url for example) [13:41] Ah right, so you're saying you'd need to have a separate file on dev.altinea.fr for each server (and specify which one of those files to use in SMBIOS config at launch time)? [13:42] exactly ! [13:42] Yeah, I can see why you want to avoid that. :) [13:43] Do you create your own images, or do you using stock images provided by distros/OSes? [13:43] distro's one (Ubuntu in my test case) [13:43] All datasource are available, perhaps could I mix two ? [13:44] Nope, each boot uses a single DS, I'm afraid. [13:45] I only need to have some kind of vendor-data merged with user-data to add node to puppet and install a few packages [13:45] sad :-( So It would necessary go for a code change in Proxmox [13:46] Yeah, PVE not allowing you as a user to provide user data is breaking cloud-init's assumptions, unfortunately; maybe I'm not thinking of another way around it, but it does sound like a platform issue that's difficult for us to find a way around. [13:47] ok, many thanks for your help and confirmation [13:47] Time to annoy PVE devs so ;-) [13:47] ^_^ [13:47] Sorry I couldn't help more! [13:48] no problem, at least, I'll stop wasting time with something not possible [13:50] And a little remark if there's cloud-init dev here : CI seems to NOT support ssh certificates [13:51] I've been able to hack around this with 'disable_root_opts' of the ssh plugin but supporting it officially would be great [13:51] despite this, the possibilities with cloud-init are almost endless, it's really exciting ! [13:52] (if I could provide my own datas :-) [13:57] PandemiK: It's funny you should mention SSH certificates, someone opened this PR related to them yesterday: https://github.com/canonical/cloud-init/pull/487 :) [14:05] PandemiK: "having a patch into mainstream PVE would be ... long". I'd recommend starting that process. As the old saying goes, "the best time to plant a tree is 30 years ago. The second best time is now". [14:05] nice quote ;-) [14:08] PandemiK: one thing that maybe could help you... i dont know if we ever did this or not. i dont think so. [14:08] but we could make cloud-init able to put the instance id into the header of a seed request [14:11] @smoser : as said, this would need to generate a user-data 'on the fly' per VM, right ? [14:11] yeah... you're going to have to do that. i think. as yeah.. [14:12] as you don't have a way to put any differenciationg information into the url. (if i understand correctly) [14:12] My goal is to let PVE generated all vm-specific datas and add only vm-agnostics datas [14:12] some other cloud-init-like things put mac addresses of the NICs available in the headers [14:12] I won't try to create a script that get the instance-id from proxmox, correlate with VM fqdn and return a specific user-data file [14:13] so pve just does not provide any user-data ? [14:13] did I mention I'm not a developer ;-) [14:14] ah. i see. i think. [14:14] you dont' want to provide launch-time input ? [14:19] i guess https://pve.proxmox.com/wiki/Cloud-Init_Support is what you're using ? [14:19] yup [14:19] It seems there's an effort in what I'm looking for : [14:19] https://lists.proxmox.com/pipermail/pve-devel/2020-July/044241.html [14:19] really new but promising [14:23] yeah... it seems that that is what you're after. [14:23] and you'd just put in as ciuserdata base64("#include your.url.here\n") [14:24] it is pretty crazy... it looks from their patch that proxmox is writing yaml with strings and indents. [14:25] ie 'content .= "... mtu " [14:25] I'm trying to understand their idea but yeah ... strange [14:25] rather than creating some dict and yaml.dump() [14:33] remember it's Perl ;-) [14:37] yaml is a strict super set of json [14:38] cloud-init reads yaml, but they could just write json [14:38] and i'm sure there is a json for perl [14:38] (there probably yaml too) === ddstreet_away is now known as ddstreet [17:11] How to set an interface to promiscuous mode? [19:57] MICROburst: I don't believe that we have platform-independent configuration to express promiscuous mode, so I think you'll have to configure the system to apply it yourself. You may want to look at networkd-dispatcher which is recommended by the netplan docs (https://netplan.io/faq#use-pre-up-post-up-etc-hook-scripts) but this is not my area of expertise so I can't speak categorically. [19:59] : So you suggest to put the stuff in write_files: ? [20:02] MICROburst: That's what I'd try first, yeah. === apollo13_ is now known as apollo13