[pve-devel] [PATCH container] lxc: fall back to 'unmanaged' on unknown ostype

[Thomas Lamprecht]

On 5/17/20 11:03 PM, Arnout Engelen wrote:
> On Sun, May 17, 2020 at 10:44 PM Thomas Lamprecht <thomas at lamprecht.org> wrote:
>> Am 5/17/20 um 10:10 AM schrieb Arnout Engelen:
>>> It would make the scenario of starting an unmanaged image without explicit
>>> parameters work.
>>
>> I'd rather add recognizing an explicit "unmanaged" type from the CTs
>> `/etc/os-release` or if really only return this on setup if there's no
>> os-release
>> and no other releasefile, which then at least ensures that modern
>> distros (which
>> most ship /etc/os-release) are wrongly mapped to "unmanaged".
> 
> Requiring an explicit "unmanaged" in `/etc/os-release` means proxmox will only
> auto-detect CTs that were explicitly written for proxmox... only falling back to
> 'unmanaged' when /etc/os-release does not exist sounds fine to me, though.

I mean, if you use such CTs already then they got created for a specific use
case and thus adding some extra file, hint or whatever..
I mean, I do not like that approach 100%, but it would make it explicit which
seems much better.

> 
> I'll create an updated version of this patch that implements these 2 paths.
> 
>> Fallback in update_pct_config for when no ostype is set in the config
>> for existing
>> CT is not OK, it must be recognizable on setup.
> 
> Right, I was less sure about that part.
> 
>>> When using the 'create CT' button in the web UI, PVE/LXC/Setup.pm will
>>> auto-detect the ostype.
>>>
>>> (...)
>>>
>>> While I agree failing early is generally good practice, here running the
>>> image 'unmanaged' when no OS was detected seems like a more
>>> optimistic choice, as it fixes the 'raw unmanaged image' scenario.
>>
>> This is something most user won't ever need.. Why is it a problem to set the
>> unmanaged OS type through CLI/API?
> 
> AFAICT the 'create CT' web UI does not currently allow setting the ostype.
> This of course could be changed/fixed, but the auto-detection that is already
> there seems nice. I haven't used the API yet, and wanted to avoid using the
> CLI (which requires root) where possible (though it looks like I'll have to
> compromise there to get access to some features anyway ;) ).
> 

>From our POV it's a feature, we support a set of distributions which we can all
detect in a sane way. All unsupported cannot really get made to work easily over
the web-interface anyway.

For what specific use case do you want this? What would be running in the CTs?
Maybe it's easier to add support for that distro?

cheers,
Thomas