Fedora Server PRD Draft and call for participation

Sat Jan 11 10:16:50 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again,

thank for the clarification.
Than, well done!

I am looking forward to work on the details :-)

Cheers

Am 10.01.2014 22:07, schrieb Stephen Gallagher:
> On 01/10/2014 03:44 PM, Joerg Stephan wrote:
>> Hi Stephen,
> 
>> i guess i am late :-) so maybe caused by that, while reading 
>> through the document there are some basic questions in my mind,
>> so sorry that i start with some clearification question:
> 
>> (you EQUAL all contributors so far)
> 
>> When you speak about "Server Roles" you mean the service which
>> is provided by the server? Like DNS, so you mean that we need an 
>> easy/remote/api way of installing a service on an server? Like
>> you could do it with puppet or spacewalk or maybe WebYAST in
>> SUSE?
> 
> 
> Server Roles are a closer match to how Windows Server defines
> server roles (i.e. This machine is a domain controller, that one is
> an Exchange server, this other one is an IIS webserver, etc.) The
> idea would be for us to be able to take some common deployment
> patterns and turn them into pre-packaged roles. This would
> simultaneously make it easier for more junior administrators to
> start deploying things while also encouraging a level of uniformity
> in deployment that would be easier to support and update.
> 
> 
>> Were is the "base"? I mean the basic server, the naked 
>> installation like a minimal server. For me, as an administrator
>> i like really tiny iso`s which provide a basic installation so
>> that i can ran into the loud and noisy server room an install the
>> system within some seconds and do the rest via ssh (or something
>> else).
> 
> 
> Well, there are three things in play here. The first is that the
> Base Design Working Group is going to be defining what is the
> absolute minimum "Fedora" base system (similar to the 'minimal'
> group in Fedora today, but more constrained and with dependencies
> cleaned up so it's smaller). The Fedora Server and Fedora Cloud
> will be building atop this base.
> 
> One of the things we're proposing for the Fedora Server is to be
> less of a build-it-yourself environment, though. What we want to
> install (through whichever installation mechanism;
> DVD/netinstall/amazon image, etc.) should always be the same: the
> platform that describes the Fedora Server. This will be essentially
> the Base plus the infrastructure pieces necessary to support Server
> Role deployment on top of it. This will still be a small and
> tightly-controlled base platform, but it may be a bit larger than
> today's 'minimal install plus sshd'.
> 
> 
>> Than (currently last), i am missing "security". Now a days i
>> guess security plays a big role. So maybe we should tell a bit
>> about security features we need in this set. Like pre configured 
>> firewalls, maybe installation sets which open there port on 
>> firewall side. Or maybe an preferrred backup solution, easy to 
>> install maybe api triggered like we got it in zabbix to bound 
>> client and server.
> 
> 
> These are things that we have discussed and in most cases they
> will fall into either of two categories: "Server Roles" and
> "Infrastructure needed to support Server Roles".
> 
> These are implementation details and are (in my opinion) topics
> for the execution planning rather than the high-level requirements 
> planning. The purpose of this document is to set out our vision
> and goals, not to specify a specific implementation.
> 
> 
> I hope this clarifies things a bit.
> 
> 
>> So far & Cheers
> 
>> Jörg
> 
>> Am 10.01.2014 21:05, schrieb Stephen Gallagher:
>>> The first deliverable that the Fedora Server Working Group was 
>>> tasked with was the production of a Product Requirements 
>>> Document. This document is intended to provide a high-level
>>> view of the goals and primary deliverables of the Fedora
>>> Server distribution. A great deal of discussion has gone on
>>> during the weekly Working Group meetings as well as on the
>>> mailing list.
> 
>>> At this time, the deadline for the delivery of the PRD is 
>>> rapidly approaching. Originally it was due to be delivered for 
>>> ratification on Monday, January 13th, but at the FESCo meeting
>>> on Wednesday, it was agreed to delay this deadline by a single
>>> week. The primary reason for this delay was so that the Fedora
>>> Cloud and Fedora Server groups could have some last discussions
>>> about overlap and respective areas of responsibility.
> 
>>> This past Tuesday, we had an all-day PRD hackfest in IRC and 
>>> have come up with a fairly strong draft[1]. It is not yet 
>>> complete (notably, there remains a FIXME under "Misc.
>>> Concerns" and some ambiguity around the Use Cases), but I
>>> believe that it is close enough to its final form (as
>>> envisioned by those people that have contributed to it), that
>>> we should expose this document to the wider world and ask for
>>> input before submitting it to the Fedora Engineering Steering
>>> Committee and Fedora Advisory Board a week from Monday.
> 
>>> Please read through the PRD draft and provide feedback of any 
>>> sort. If you see that we have missed or misrepresented any of 
>>> our statements, we would very much like to hear this soon.
> 
>>> [1] 
>>> https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_Document_Draft
>
>>> 
>>> 
> 
>> _______________________________________________
>>> server mailing list server at lists.fedoraproject.org 
>>> https://admin.fedoraproject.org/mailman/listinfo/server
> 
>> _______________________________________________ server mailing 
>> list server at lists.fedoraproject.org 
>> https://admin.fedoraproject.org/mailman/listinfo/server
> 
> 
> _______________________________________________ server mailing
> list server at lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/server
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS0RoSAAoJEMkH+YqO31/BDf0H/iAvxLQu+ZmhW8zEAbX1IGXz
iermDLuShu+A7PhzbUlzL/5mZT7LaIv9ehMA+pgwdI9Q6VpAnDKM0K2a6PMcDeKs
M6Qibvju1gdKH1hr7jbvjPSobETgg7z+bOZbDyjdgYru94e7/mCEMkxUJMmjbv5r
AZ9eOCq969yFiPN7LUsot1gsuPyU6cnpsNBqBfiwDeYfxpzb664oOA3pjOBOEGkK
+KXAfiYYfjueMmnIAQCttaWLaxtPRaceS619FsQyT40GM9LSYRiEVZL9JUSQTG1e
7IbNmT1yxfUGshOyf5Tf05vuClDkjS/PBsatp96GmEGGU8Hj7AV3SrQsPd5EBXk=
=Rx9S
-----END PGP SIGNATURE-----