I am no flatpack expert, but I think that really any container technology in question should be just a porter of an rpm or set of rpms and there should (could) be packaged ansible scripts that are able to setup and spawn those containers e.g. in OpenShift or just on a host machine through ssh or by other communication means. This approach is not bound to a particular container technology and therefore provides huge amount of flexibility. We could also actually provide flatpacks for downloading to create some 'halo' effect but that again should be result of an automated image-creation process in which we should be able to chose what kind of containerization we want.
Really, if you can put rpms you want on the host system without any container encapsulation, that will always be superior because containers are just another added layer. They don't provide anything else than a way to avoid conflicts. There is no gain in using them except portability but that does not mean they need to be an end product. They can be an end product but then that doesn't mean we need to stop working with rpm internally. I am sorry if I am stating obvious things here. clime On Thu, Jul 20, 2017 at 5:54 AM, Kevin Kofler <kevin.kof...@chello.at> wrote: > Matthew Miller wrote: > > Containers (and particularly, Docker-style containers with Kubernetes > > orchestration) are rapidly taking over the server world. This is not > > hyperbole, and while one might fairly throw "everything old is new > > again", it's not a fad. This is a real generational shift. > > This premise is already questionable. I can see large organizations like > Red > Hat using these (e.g., so they can easily move services from one physical > server to another), but for the servers that I take care of (my personal > VPS > and my employer's server), I don't have any use for containers. All that > they would give me is a lot more maintenance work. The typical server > software is the same as always: Apache httpd, Tomcat, etc., which have all > been packaged nicely as native packages for years. I am surely not the only > admin who feels like that. > > Kevin Kofler > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
