[RFC] plans for initscripts in F22

Reindl Harald h.reindl at thelounge.net
Sat Apr 26 11:16:56 UTC 2014


Am 26.04.2014 11:24, schrieb Michael Scherer:
> Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit :
>> And it's not only commercial software; private projects that make no
>> sense to publish (such as a company's web site) are equally affected
>> such changes. Simply spoken, if we care only about package in Fedora,
>> we are building an appliance; if we want to build an operating system,
>> we do need to cater for software not included directly in the repo.
> 
> Then how can we signal to people that they need to update those
> packages ?

the problem is that people don't want to rewrite/update
perfectly working things which are broken by intention

moving config files around or replace them with a completly
new syntax because the rewrite of whatever piece of software
did not have backwards compatibility in mind is annoying for
a lot of reasons - besides some voices saying "i don't care
about anything which is not part of the distribution"

* it breaks working setups
* it renders howtos invalid
* it throws away knowledge of people that learned how to do things

it's already a big problem that if you try to achieve something you can't
rely on any information you find in the internet if it's not brand new
written

with stable interfaces and configurations you can build on top of several
articles and howtos pieces together for your solution

by permenantly changing interfaces (CLI params are user-interfaces) that
ends in 3 of 5 pieces are still working that way but the big picture fails
by the 2 no longer behave that way parts and if you try something you did
never before and not sure what is the best way at all it get's really hard
________________________________________________________

i have built a lot of automation for systems administration that way over
years where machines for different services are configuring themself by
meta-informations coming from simple actions like "fill out one webform
for a new domain"

* register that domain via EPP
* add the domain to the DNS servers
* add the domain on the primary webserver and create a document root
* create a mysql database
* install our self written cms with a default setup and configure it for that database
* add the domain including whois-infos to the billing database
* add the email addresses to dbmail
* add the domain
* add the domain to the spamfirewall-appliance
* add a SPF record to 4 nameservers with LAN/WAN DNS views
* configure autoconfig/autodiscover aliases on apache and add the DNS records
* add the domain on the Trafficserver machine (ATS and local dnsmasq) to
  later decide with a single DNS change if it needs load-balancing

that can be one big task and several cronjobs on several machines are doing that
one time, but all these jobs also working alone for cases where no mail addresses
where ordered and 6 months later are needed - well, enter the mail-addresses in
a textfield, the above tasks which are relevant are happening and the result is
a list with username:generated-password

so all that pieces are running standalone but also heavily combined
if one of them falls because a change in the distribution the damage
depends on which one, can it be automatically detected and following
actions stopped while raise alarm, how can you test the cases which
may lead to failing one of the pieces, how do you manage to test the
behvior if the underlying operating system make abusive changes

and last but not least even if you know which things are changing
in case of dist-upgrades how do you plan these changes in case we
are talking about a lot of machines acting together since a distupgrade
on a ton of machines is a non-atmoic process and you hardly can stop
the whole infrastruture

until now i managed to surivive dist-upgrades from Fedora 9 to 19 in such
a environment inluding make space for GRUB2 with test-machines and dd-dumps
of the (luckily) /boot-disks instead partitions distributed but that don't
mean you ask yourself not if the current change is really worth the impact
________________________________________________________

if you managed to get your result after that and the next Fedora
version breaks it again because someone says "ah that was a terrible
way to do things, we no longer support that please change that" and
that happens too often it raises the question "is Fedora something you
can build things on top of which is the job of an operating system or
is Fedora something narcissistic you should avoid if you don't want to
rebuild your work every few years or sometimes months"

don't get me wrong, i am a perfectionist too re-factoring and optimizing
my code up to comments and seek even wrong code-indenting of single lines
while trying to get rid of code better never written that way - but doing
that you need to draw a line where you better should stop because the damage
defeats the positive effect and if you are not drawing that line you end
in a loop of breaking, replacing, adopting, breaking, replacing, adopting
simply because the now perfect thing 3 days later likely looks like "oh
i would have better done this and that completly different"

that's fine if it happens under stable interfaces but not if it demands
the userbase to change their software running on top of yours

> Because we can as well say "we are gonna support that forever", but that
> will result into bitrot if no one really test.

in case of network.service you have enough users which are testing and
if it would have a problem in Rawhide make notice about

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140426/ea09a502/attachment.sig>


More information about the devel mailing list