User: Password:
|
|
Subscribe / Log in / New account

Grover: Fedora for short-lifespan server instances

Grover: Fedora for short-lifespan server instances

Posted Jun 4, 2013 14:27 UTC (Tue) by drag (subscriber, #31333)
Parent article: Grover: Fedora for short-lifespan server instances

The problem isn't the OS really. It's the applications.

All businesses server uses that matter depend on custom applications and dependencies that are not going to be managed by Fedora itself. Sometimes these applications are developed internally, sometimes externally, sometimes both. They range from everything from perl and shell scripts to huge C++/Java programs with hundreds of dependencies. Everybody's business is different so the logic of the applications need to be crafted to match the business.

Under the current regime of typical application deployment Fedora will have to prove that they can release upgrades that will not break third party binaries and custom applications then this scheme can work.

I don't really think that it's possible unless the application is carefully compartmentalized from the OS in a way to reduce dependencies on Fedora-packaged software to a minimum.

So advice like this:

> Second, we need to ensure Fedora supports the packages people are really using these days. Latest Ruby. Latest OpenStack. Vagrant. Django. Chef. Puppet. All the weird JS stuff that’s popular now on GitHub.

Is actually really really bad. It's never going to work because many times people don't need the latest. Sometimes you need older packages, sometimes newer, sometimes you want to be able to use multiple versions of ruby on the same server for whatever insane reason. It's impossible for Fedora to support this. This approach to packaging software is really quite worthless. It will help the people that always use the latest versions of the software.. ie developers and hobbyists, but it will not be useful for the majority of cases.

The Business needs dictate the application. The Application dictate the dependencies. The dependencies dictate the OS. Budget and time restraints control decisions related to all of this. Trying to package all the dependencies users need so that you are free to do whatever you'd like on the OS side isn't going to be the best approach.

So what Fedora needs to do is develop tools, procedures and work with upstream projects to make it easy as possible for end users to pull directly from upstream repositories (whatever they may be; deb packages, some weird python management tool, tarballs, compile-from-git, etc etc) and make it easy regular users to manage this stuff.

Doing stuff like making it easy to compile software and bundle dependencies (ie: pull in libraries and setup ld path stuff) into something like /opt/application-name_version/ and generate systemd configs to start/stop/status/check logs would be something that would be probably very useful, for example.


(Log in to post comments)

Grover: Fedora for short-lifespan server instances

Posted Jun 6, 2013 0:46 UTC (Thu) by vonbrand (guest, #4458) [Link]

Sorry, but there is even more madness in this. The big advantage of a distribution is that is offers a set of stable, working together, tested packages. The stuff I have installed here is the same as the one reporting a bug is running, what fails here will fail elsewhere (and hopefully eventually get fixed). Running random "latest"(or whatever other version someone wants for assorted reasons) together makes for a totally unmaintainable system (except for whoever put it together, and we all know how much time we can spare for keeping up).

As said, applications are very often binary blobs (or near enough) that have all sort of insidious dependencies. Can't begin testing if it will come crashing down if some ostensibly totally unrelated library API is changed, sorry. So you keep what is running, and want to pay the price of perhaps having to redo literally years of tweaking as unfrequently as possible.

Grover: Fedora for short-lifespan server instances

Posted Jun 7, 2013 20:08 UTC (Fri) by drag (subscriber, #31333) [Link]

> The big advantage of a distribution is that is offers a set of stable, working together, tested packages.

Which you often can't use. Realities in your applications dictate versions of libraries. Just because Fedora supports a certain version of something has zero bearing on whether or not you can use it in your application.

> The stuff I have installed here is the same as the one reporting a bug is running, what fails here will fail elsewhere (and hopefully eventually get fixed).

No it's not. Because Fedora is not the developer of either the application nor the library it ships. If you have a bug with a particular version of something it's going to be a bug that you will have to engage with the developers to fix. Sometimes developers are also package maintainers, sometimes they are not, it's hit or miss.

> Running random "latest"(or whatever other version someone wants for assorted reasons) together makes for a totally unmaintainable system (except for whoever put it together, and we all know how much time we can spare for keeping up).

Sorry, this is so much bullshit. When you develop applications for server purposes or for a particular business reason you have to have your own ability to do QA. You have to be able to maintain your own software and a huge part of that is maintaining the environment your applications depend on.

Right now Fedora packages arbitrary versions of packages which may or may not match what you need to have. It provides little to no mechanism to make it easy to manage anything that is not automatically built by Fedora's system.

This is why 'Enterprise' distros don't change often. The people that use them need to able to maintain specific application stacks and relationships between applications. Fedora and other distros update their versions of packages based on their own time lines and their own needs without consideration of what you may need or want.

This is not a fault of Fedora. It's a fault of the 'distribution' concept that says that everybody has to be built and refreshed every six months or ever release or whatever. Users may not desire or need or be able to use the version of X software or library that is built when Fedora decides to do a change freeze.

If Fedora wants people to be able to do effortless upgrades for the 'cloud' or whatever they will have to make it easy for end users to manage arbitrary versions of software and libraries that the users need, not what is convenient or makes sense for the Fedora project.

Yes this is hard. This is why nobody does this. And is why people can't use Fedora in place of a distribution like Redhat or CentOS that will remain relatively static for 5 years or more. It is also why packaging Ruby or whatever other vertical application stack with Fedora isn't going to make any difference in this regard.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds