Mira Limbeck writes:
> On 2/13/25 12:01, Fiona Ebner wrote:
>> Am 10.02.25 um 13:07 schrieb Daniel Herzig:
>>> From: Leo Nunner
>>>
>>
>> @Mira do you know more by chance?
> I don't think vendor-data should be part of the instance-id. It's used
> to create a first configuration that a user can
Am 13.02.25 um 12:01 schrieb Fiona Ebner:
> Am 10.02.25 um 13:07 schrieb Daniel Herzig:
>> diff --git a/src/PVE/LXC/Cloudinit.pm b/src/PVE/LXC/Cloudinit.pm
>> new file mode 100644
>> index 000..3e8617b
>> --- /dev/null
>> +++ b/src/PVE/LXC/Cloudinit.pm
>> @@ -0,0 +1,114 @@
>> +package PVE::LXC:
Am 13.02.25 um 12:29 schrieb Mira Limbeck:
> On 2/13/25 12:01, Fiona Ebner wrote:
>> Am 10.02.25 um 13:07 schrieb Daniel Herzig:
>>> +sub gen_cloudinit_metadata {
>>> +my ($user) = @_;
>>> +
>>> +my $uuid_str = Digest::SHA::sha1_hex($user);
>>
>> Hmm, shouldn't this also depend on the vendo
On 2/13/25 12:01, Fiona Ebner wrote:
> Am 10.02.25 um 13:07 schrieb Daniel Herzig:
>> From: Leo Nunner
>>
>> The code to generate the actual configuration works pretty much the same
>> as with the VM system. We generate an instance ID by hashing the user
>> configuration, causing cloud-init to run
Am 10.02.25 um 13:07 schrieb Daniel Herzig:
> From: Leo Nunner
>
> The code to generate the actual configuration works pretty much the same
> as with the VM system. We generate an instance ID by hashing the user
> configuration, causing cloud-init to run every time said configuration
> changes.
>
From: Leo Nunner
The code to generate the actual configuration works pretty much the same
as with the VM system. We generate an instance ID by hashing the user
configuration, causing cloud-init to run every time said configuration
changes.
Instead of creating a config drive, we write files direc
