[virt-tools-list] virt-install and cloud-init, feedback wanted

[Cole Robinson]

On 11/21/19 9:51 PM, Dusty Mabe wrote:
> 
> 
> On 11/21/19 5:34 AM, Daniel P. Berrangé wrote:
>> On Wed, Nov 20, 2019 at 08:18:01PM -0500, Dusty Mabe wrote:
>>>
>>>
>>> On 11/20/19 5:49 PM, Cole Robinson wrote:
> 
>>>> * Any other ideas, thoughts, feedback?
>>>
>>> I would love to have something like this support Ignition as well. Do you think
>>> that would be welcome? 
>>>
>>> If so, does it change your thoughts on the approach? Would we stick with `--cloud-init`
>>> and just add `--ignition` or would we want to group it under another heading
>>> `--userdata type=cloud-init,ssh-key=.....` `--userdata type=ignition,ssh-key=...`?
>>
>> If ignition is not a drop-in replacement for cloud-init, then I think
>> using the --cloud-init arg would be a bad idea. Instead we would need
>> a separate --ignition arg, or we could need a more general --userdata
>> as you sugggest.
> 
> It uses a different input format so it's not a drop in replacement. I think it
> would be really nice if we can use an option that addresses the category of problem
> and allow for other implementations to be dropped in. Today we know of cloud-init
> and ignition. There will probably be others in the future. If we could use a generic
> named argument (let's call it --userdata, but we could bikeshed on a more appropriate
> term) I could foresee:
> 
> * --userdata type=cloud-init,ssh-key=foo
> * --userdata type=ignition,ssh-key=foo
> * --userdata type=raw,data=/path/to/file
> 
> Where the raw type just passes the file directly. Then we could add other types in the
> future as they come about.
> 
> Just food for thought :)

I get the appeal, but I'd rather start with explicit options and add a
generic option in the future if/when it makes sense. Particularly for
cloud-init I'd like there to be an explicit option, so it stands out in
--help and man page content. There's been enough mailing list threads
and blog posts and bugzilla traffic about virt-install and cloud-init
that I want the solution to be as discoverable as possible.

Having a general option up front is also a little worrying in that it
may actually encourage contributions for more init style tool
integration, which I don't want to open the doors to entirely. I'd
rather wait and see if a usecase becomes particularly requested or
compelling that it makes sense to add.

But maybe ignition fits that bill, we can discuss more in a bug

Thanks,
Cole