[11:43] <ajmyyra> are there any supported ways of hinting for the correct datasource? dmidecode reveals it of course but I don't see it being utilized. the new datasource eventually gets discovered and runs correctly, but before that there's quite a bit of wait for ec2 timeouts (120s) and for others as well
[11:48] <ajmyyra> the fork is here and for utilizing UpCloud's network metadata service, if interested. https://github.com/ajmyyra/cloud-init/tree/datasource-upcloud
[11:48] <ajmyyra> just testing with "cloud-init init" for now.
[12:06] <meena> ajmyyra: set datasource_list
[12:10] <ajmyyra> isn't it defined in cloudinit/settings.py?
[12:10] <ajmyyra> added it there, of course
[12:13] <ajmyyra> or do you mean as provided cloudconfig? can add it there, of course but it would mean that images that don't have it included could have to go through the same wait before initializing.
[17:08] <cyphermox> I'm curious, I'm having some weird issues configuring Saltstack via cloud-init while a machine is being commissioned by MaaS -- on what phase does this run? I managed to get things to work with late commands, but it seems wrong when there is syntax for it in the first place
[17:10] <meena> ajmyyra: maybe setting ec2 strict could be enough
[17:12] <meena> ajmyyra, you can't provide the data source config via cloud-config, since the cloud-config is read from the data source.
[17:12] <cyphermox> you can do so from the boot command-line though
[17:16] <meena> cyphermox: salt runs in final stage https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl#L124
[21:40] <ajmyyra> meena: oh yeah, that too. might need to check ci.datasource as a command line option. seems like something I was after in the first place.