[pve-devel] [PATCH Qemu-Server Adapt Cloudbase-init for windows 0/1]

[Thomas Lamprecht]

On 4/11/19 11:53 AM, Austin Chan wrote:
> Hi,
> 
> Thanks. 
> 
> BTW, please advise how to split these code?
> 
> Because these codes are doing one things that make the configdrive2 format cloudbase-init read correct info from cloud-init driver.

Hmm, so if you say they're all beloging together to make it work for windows
it _can_ be OK to have the changes all in one, but this would require a commit
message explaining why those things all need to be done. And even if it's all for
windows you could still split into

* geniso level change
* dns key format change
* hostname + pass change
* unencrypted password passing change

> 
> *These will not change the format for Linux based cloudinit (nocloud). 

not true, or? the configdrive2_network where you change the name server stuff is not
OS dependent, as is the metadata hostname/adminpass..

> 
>> On Apr 11, 2019, at 5:40 AM, Thomas Lamprecht <t.lamprecht at proxmox.com> wrote:
>>
>> On 4/11/19 11:31 AM, Austin Chan wrote:
>>
>>> Noted. So, do I have to resubmit it?
>>
>> I wrote a few comments on the changes itself, maybe go through them and address
>> them (at least if seem reasonable, if they do not seem reasonable to you,
>> please note that with a reason) and then send a second version (v2).
>>
>> Thanks a lot!
>>
>>
>>>
>>>
>>>> On Apr 11, 2019, at 5:27 AM, Thomas Lamprecht <t.lamprecht at proxmox.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 4/11/19 10:46 AM, Austin Chan wrote:
>>>>> 1. set plain text password for Windows VM (read in ostype) in qemu 
>>>>> configuration files (Cloudbase-init do only read and set password 
>>>>> by plain text password).
>>>>>
>>>>> 2. change dns to adapt cloudbase-init format "dns-nameserver".
>>>>>
>>>>> 3. pass the "hostname" and "admin_pass" info to metadata in the 
>>>>> driver of cloudbase-init.
>>>>>
>>>>> 4. change iso-lever of "genisoimage" to 3.
>>>>
>>>> first thanks for your contribution. A few general remarks here.
>>>>
>>>> 1. If you list such points, all speaking of different things, it's probably
>>>>  a good idea to split the changes up into multiple patches, as each patch
>>>>  should be contained to a single (logical) change
>>>>
>>>> 2. You describe what you do, but it would be good to know why something is
>>>>  done, the what can be good too, but should be normally be clear when reading
>>>>  the code changes.
>>>>
>>>> 3. This information would be great to have in the respective patch as git commit
>>>>  message, so that it gets into our git repo.
>>>>
>>>>>
>>>>> Austin Chan (1):
>>>>> Signed-off-by: Austin Chan <sptrsca at gmail.com>
>>>>>
>>>>> PVE/API2/Qemu.pm            |  8 ++++++--
>>>>> PVE/QemuServer/Cloudinit.pm | 13 +++++++++----
>>>>> 2 files changed, 15 insertions(+), 6 deletions(-)