From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id A088C1FF168 for <inbox@lore.proxmox.com>; Tue, 18 Mar 2025 17:24:18 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 76B4633382; Tue, 18 Mar 2025 17:24:06 +0100 (CET) Date: Tue, 18 Mar 2025 09:23:11 -0700 To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com>, raven@encodedbird.com References: <e0a39815-26cc-4530-9bcd-5e5e2f1f1ae4@disroot.org> <ec981a0e-31a3-40ac-8f7c-26d60c68b693@proxmox.com> In-Reply-To: <ec981a0e-31a3-40ac-8f7c-26d60c68b693@proxmox.com> MIME-Version: 1.0 Message-ID: <mailman.108.1742315045.416.pve-devel@lists.proxmox.com> List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Post: <mailto:pve-devel@lists.proxmox.com> From: Raven King via pve-devel <pve-devel@lists.proxmox.com> Precedence: list Cc: Raven King <thekingofravens@disroot.org> X-Mailman-Version: 2.1.29 X-BeenThere: pve-devel@lists.proxmox.com List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> Subject: Re: [pve-devel] Proposal For Podman Container Support Content-Type: multipart/mixed; boundary="===============6676387634097543106==" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> --===============6676387634097543106== Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <thekingofravens@disroot.org> X-Original-To: pve-devel@lists.proxmox.com Delivered-To: pve-devel@lists.proxmox.com Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id ED2DBCA16C for <pve-devel@lists.proxmox.com>; Tue, 18 Mar 2025 17:24:04 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CD96033343 for <pve-devel@lists.proxmox.com>; Tue, 18 Mar 2025 17:24:04 +0100 (CET) Received: from layka.disroot.org (layka.disroot.org [178.21.23.139]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Tue, 18 Mar 2025 17:24:01 +0100 (CET) Received: from mail01.disroot.lan (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 7638920217; Tue, 18 Mar 2025 17:23:55 +0100 (CET) X-Virus-Scanned: SPAM Filter at disroot.org Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavis, port 10024) with ESMTP id zP0DWaPFaigo; Tue, 18 Mar 2025 17:23:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1742315022; bh=UIf0raSjTpTEEBKGID1dxwt1TnOxPtkLCG3YzmW5wws=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=NzrbedxRFdVjHO20EsT1jMtzF88ldPt6/Pw9hBuZTq+9RqAGWOPFM6KU4vYOHTbSG qUo9pbiVilu6pDl8GMZe0TrwT8FUUA5EmzLdoczxVE2/zrraCovwp5hriCYYcO4l6f RP6LSFXvX35GVjBbJeoRaODT5WcVQvxuF2mTUsfNi3rgcoLZKcrzR5RG3XdPOA/1l2 5h7sfo6hootKf+pii58sbTNeFqgiYmqw+8uo2lMAIoqKd8HzIHnQuaLDaI4Qzb40qh WQjBdt9irDHLY1ALmEmBWDzveHuZzXpqXD5AEonu0+Fb6dpwEv0jm9VrvJj8QxFBc7 OSMiBVhDGNmYg== Message-ID: <9a7f5a00-200a-4f3a-a58b-dd0fad5bcb68@disroot.org> Date: Tue, 18 Mar 2025 09:23:11 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Proposal For Podman Container Support To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com>, raven@encodedbird.com References: <e0a39815-26cc-4530-9bcd-5e5e2f1f1ae4@disroot.org> <ec981a0e-31a3-40ac-8f7c-26d60c68b693@proxmox.com> Content-Language: en-US From: Raven King <thekingofravens@disroot.org> In-Reply-To: <ec981a0e-31a3-40ac-8f7c-26d60c68b693@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.350 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [disroot.org,proxmox.com] Thomas, Going forward, I will send all future emails from raven@encodedbird.com. Its a long story that has nothing to do with proxmox, but the timing is now. Please direct anything else to that as well. Thank you for a thoughtful and explanatory response. I can easily see that directly implementing OCI seems like a smarter approach that would integrate better. I definitely see how maintenance concerns and 3rd party dependencies are especially an issue when proxmox has a commercial support component. As for me, I am familiar with rust, more so than perl. However I haven't used it in a codebase that involves other people, mostly just privately at my work on internal tooling for the company. The insights you gave here leave me very glad I reached out before hand. It also causes me to realize some of the complications I had with using LXC containers as proxmox implements them would still exist with application containers because its actually the same stuff under the hood unless new frontend features were added to hide that complication. I should clarify that I was able to share LXC directories, but it required a much more in-depth understanding of how they are configured and wasn't something I could do in the user interface. I am now in sync on that. I can't know how big a task I would be committing to by taking this on unless I have already worked on the codebase. So I am gonna take some time to try and catch some bugs before I make grand promises about delivering such an integrated feature, staying inline with the advice y'all gave about it. Sadly this could mean the project is done by the time I am ready to start. I did read the developer documentation beforehand, it was mostly just looking at the bug lists I got a little lost. However, I will probably just try building it, maybe fixing a few bugs and adding some jokester toy features I never show to the world for now. Sincerely, Raven King On 3/18/25 02:45, Thomas Lamprecht wrote: > Hi Raven King, > > I want to say thanks up-front for trying to improve on of our open > source projects and reaching out upfront for doing so, highly > appreciated. > > Am 13.03.25 um 19:03 schrieb Raven King: >> This is my first time writing to this mailing list. I have never >> contributed to proxmox but I would like to try and write a feature that >> allows native container support (not inside an LXC or VM). > FWIW, LXC definitively are "native containers", it's less confusing > to use application containers (like OCI conform ones) and system > containers (running a full distro), as LXC can be used for both, > i.e. docker used LXC for a while for isolating application CTs. > >> My goal would be that you could manage those containers much like >> LXC/VMs with similar UI behavior (resource usage views, easy access to >> container console, and resource sharing). >> Its a large undertaking, and I would probably want to get a little >> experience with the proxmox codebase first. > I think we should take a step back and not focus on integrating podman > too much, but rather about adding support directly in our existing > container toolkit. Actually I'm pondering about adding support for the > OCI runtime spec [0] and maybe also the OCI image spec [1] over the > last years and had some light talks with developers about that, so I > think you and I agree on the end goal already, but not on the road or > method to get there. > > [0]: https://github.com/opencontainers/runtime-spec > [1]: https://github.com/opencontainers/image-spec > >> *Why do this?* >> 1. It is parroted by users frequently. Just look up "run docker in >> proxmox" and you will see dozens. >> 2. It would add a major use case to proxmox. >> 3. For me personally, it removes a major pain point of using >> proxmox, which is setting up an LXC to then share resources with to then >> setup a docker image to then share resources with. >> Or using docker directly and tearing my hair out as it >> magically breaks all my proxmox network config. > The why's are all fine, the reason it does not exist yet is not because > we saw no reason, but rather because there are good workarounds that > can be used and correctly implementing this into our container runtime > while ensuring as much as possible is shared with our existing > implementation. > >> *Why Podman?* >> 1. Easy enough to use. >> 2. Packaging. The support in debian is straightforward and won't >> confuse anyone. This means the project won't have to maintain podman >> itself in any way. >> 3. Security. Podman needs limited privileges to operate compared to >> docker. This makes it easier to mesh with things such as user accounts. >> 4. Interop. It easily goes to/from kubernetes, which can help in >> some enterprise use cases. Also doesn't interact in ways that break >> existing pve config mechanisms. >> >> *What does podman offer an LXC doesn't?* >> 1. Easy deployment, you can just pull images that someone prebuilt >> for a purpose, including most docker images. >> 2. Directly sharing a host directory (not a whole drive) such as >> single zfs datastore. While achievable in LXC, you have to do a bunch of >> user mapping and the setup is rather involved. > You're mixing things here, LXC is a lower-level technology, it simply > does not care about image management and certainly does not limit PVE > on sharing CT and/or host directories at all. LXC rather provide > building blocks that can definitively be used to support these things. > >> *What drawbacks have I considered? >> *1. Using privileged ports in a podman container is a little tricky >> without root. Proxmox mostly runs as root though, so this is really only >> a problem for secondary users. >> 2. I will take a lot of work to ensure the networking works in a way >> consistent with other networking in proxmox. >> 3. Increase support burden as users who aren't entirely familiar with >> docker/podman containers ask questions that could be answered through >> research. >> 4. Some services people might want to run, such as nginx proxy manager, >> are gonna be very hard to use in this way due to number 1. > IMO above are not that significant but rather minor/mid-level technical > hurdles that can be overcome, the biggest drawbacks of using podman > directly are IMO rather: > > - two CT stack we need to support, ours and a third-party one > - dependency on third party developers and a programming language (Go) > we do not use at all in any of our projects. > - while great software, it does not align _that_ well with Proxmox VE's > ways of things, thus a clean and good integration that feels native > to PVE, and not just tacked on, is IMO rather hard to do. > > That all means quite some high permanent maintenance cost, which is what > would have to bear, so I'm rather opposed to it, at least without some > concrete plan of someone having intermediate+ experience with not just > working with PVE but also internal development, as otherwise it's IMO > too hard to ensure above concerns are unfounded or not relevant. > In general, I'd highly favor a native implementation that we have control > over and can neatly integrate into Proxmox VE and all its features (SDN, > backup, HA that gets extended by orchestration ...), and given that > there are specifications for what we want to support here, that should > be (hopefully) doable without extreme effort, and ideally with not much > more effort than integrating complete solutions like podman, at least > if one also minds the long term maintenance cost. > >> I am writing to the mailing list before even beginning on this endeavor >> to get several questions answered: >> >> 1. Do y'all have any general tips and pointers about navigating and >> working with the proxmox codebase? > There is some basic info here: > https://pve.proxmox.com/wiki/Developer_Documentation > > Definitively does not cover all the things though, but basic patch > handling should be described. > >> 2. Where is a good list to grab bugs to get familiar with proxmox >> structure and what functionality is where? I have some hardware, but I >> am not capable of testing stuff like multi-gpu setups. >> I see >> https://bugzilla.proxmox.com/describecomponents.cgi?product=pve but >> there is a lot of components to proxmox. I have a hard time picking a >> spot to start. > We try to add a "start-contributing" tag to some issue requests, i.e.: > https://bugzilla.proxmox.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=UNDECIDED&bug_status=REOPENED&bug_status=MORE%20INFO%20NEEDED&bug_status=POSTPONED&list_id=5791&longdesc=\btag%3A\s*start-contributing&longdesc_type=regexp&query_format=advanced&resolution=--- > > This can be filtered for the "container" component, albeit I did not > ensured the three issues that come up are valid: > > https://bugzilla.proxmox.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=MORE%20INFO%20NEEDED&bug_status=UNDECIDED&bug_status=POSTPONED&component=Container%2FLXC&list_id=50251&longdesc=%5Cbtag%3A%5Cs%2Astart-contributing&longdesc_type=regexp&order=Importance&product=pve&query_format=advanced&resolution=--- > >> 3. Are there any major drawbacks to container support that need >> consideration? > Just to ensure we speak of the same: Containers are already supported > in general, albeit our runtime that wraps LXC and co is targeting > system containers, not application ones. > >> 4. Are there specific drawbacks to podman that need consideration? > See above. > >> 5. Anything else I am overlooking with this idea? > The way I'd get started is evaluating the OCI specs, pve-container and > potentially also existing runtimes that implement the OCI specs. > For then implementing the spec and integrating that into pve-container > we would definitively open, even lightly encouraging, doing so in rust, > maybe at least the lower level building blocks for understanding/parsing > formats as defined in the OCI specs. Then use perlmod [2] to integrate > that rust modules into the existing pve-container Perl based code. > You could also just stay in perl, that would be fine for us, but in > general we try to use rust if possible for new (bigger) features and > also find that it provides us with a lot of guarantees and modern > language features to make one lives easier in the long term. > > [2]: https://git.proxmox.com/?p=perlmod.git;a=blob;f=README.md;hb=HEAD > > That's naturally a lot to ask for a new contributor, but if it was > easy it would have been already done, and we simply want to favor > native and well integrated solutions to avoid external dependencies, > of which drawbacks we had to deal with too much in the past, so we're > pretty much set on that part. > > FWIW, I directly CC'd one developer I talked lightly over adding OCI > support to PVE, maybe he got some time to think over this and > spearhead the initial effort. > If you're still interested into tackling this we naturally will try > to help you on any specific question, I still appreciate you wanting > to move this forward, but I also wanted to manage expectations, as > this might be quite the task, especially for one not accustomed to > our project and its code basis. > > best regards > Thomas > --===============6676387634097543106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel --===============6676387634097543106==--