server January 2014

server@lists.fedoraproject.org

23 participants
21 discussions

Fedora server implementation straw man
by Kevin Fenzi 07 Mar '14

07 Mar '14

ok, so I figure I will see if I can't get some discussion going on implementation plans. Here's a straw man proposal for everyone to knock holes in and propose better ways to do our implementation. ;) * Our deliverable will be a iso image similar to the current netinstall iso image. It will be that + all packages needed to install/deploy our featured roles and base things they need. This will allow installing from the net or using the iso stand alone to install server roles. * We add comps groups for each featured server role we support. So, for example: 'server-freeipa'. This comps group has all the packages listed we want to install to setup the role as we determine is best. This may include packages that are not direct dependencies on the server pacakges. * The roles use cockpit to manage and configure the server role post install. If there's a way (not sure if there is), we could look at adding a anaconda 'spoke' for the server install that runs this at install time for folks that want to configure then? Or on firstboot. * We create a new fedora-server-$role package for each role. This role package contains the 'glue' we add to turn this into a fedora server role from just a install with the packages and local config. We will need to come up with guidelines and what these packages will contain, but: 1 A way to express what items should be monitored when the role is installed/running. Perhaps /etc/server/$role/monitoring/ports and processes and such. 2 A way to express data that should be backed up if you want to backup the role. Perhaps /etc/server/$role/backups/datadirs and configdirs or databases. 3. We may want to change systemd presets to indicate things that should be running/enabled/etc when the role package is installed. 4. Anything else we need to impement an "API" for roles. Are we going to define this soon? 5. We can tie this package to specific versions of requirements. So, for example, if there's a new freeipa update and we haven't valided fedora-server-freeipa with it, the requirement can be on the older version and the users will not be updated until we push an update to this package. 6. We setup specific bodhi requirements (like critpath) for server role packages, requiring specific testing before they can go stable. 7. We may have a fedora-server-base or fedora-server-common package to contain common/base stuff all roles need/user and make the role packages require it. We would need to be very careful about updates of this however. * Users can install fedora-server-freeipa via yum/dnf after the fact, or via the iso image/anaconda. * Users can decide they don't care about our valueadding/glue and remove fedora-server-freeipa and it will just go back to a machine with all those packages installed (ie, uninstalling shouldnt hopefully do anything other than allow them to remove required packages and ignore our old glue). ok. Poke holes away. ;) kevin

13 33

Re: Fedora.next: I would like working configurations
by Stephen Gallagher 28 Jan '14

28 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forwarding this to server(a)lists.fedoraproject.org as well. Responses inline. On 01/27/2014 07:35 PM, Oron Peled wrote: > > On Monday 27 January 2014 14:01:32 Stephen Gallagher wrote: >> ... or some mechanism to interactively configure and deploy a >> DHCP server. > > IMO, that's exactly the crux of the matter. Most non-trivial > services requires some administrative decisions to configure them > properly. > > Since rpm does not allow interactive query of the user (IMO > rightfully), everybody implement custom solutions: * Some custom > scripts (e.g: freeipa-server-install) * Only hand configuration > (e.g: dhcpd) * Some web-based PHP configuration (many php > web-applications that look for an easy solution to a tough problem > and forget about security along the way...) I realize you address this below somewhat, but I want to call out that what you're describing here is the *presentation layer* of configuration, not necessarily the configuration itself. In general, the vast majority of applications keep their configurations in 1) a set of text files, 2) a project-specific database or 3) a combination of the two) If projects provide a set of tools to manipulate this configuration, that's separate from the configuration itself. As we start talking about applying configuration to a system, we can reuse existing tools where they make sense, but it's also reasonable to say that we might choose to bypass them and use a tool such as Augeaus or Puppet to apply the configuration we want. > > Just like packaging systems implemented a common framework to > install software, we need a common framework to *configure* it (at > least base configuration if the full configuration management > problem is too tough). > > My suggestion is to look first at the "debconf" abstract model. > > Let's start with one design decision which I think we should > avoid: * Debian triggers debconf operations from the package > installer. This means package installation is potentially > interactive (not good). I think the configuration mechanism should > be explicitly called from elsewhere. (e.g: when administrator want > to activate/configure the service). > Yes, I agree. Simple package installation must not require interaction. We should define that as a fundamental tenet of our approach. We need it to always be possible to have unattended or scripted operation. > But now, let's look at the good properties which we can learn > from: * All configuration options are name-spaced (in debconf it's > done by package name) Yeah, obviously we'll need to maintain simple distinction about how we maintain the data. Namespacing is one option. Another might be to use an object-oriented API where we have objects associated with each service (not necessarily package...) that have configuration options specified as their attributes. > * Each configuration option has specific *type* info (string, > boolean, multi-select, etc.) Extending the above, one of my thoughts on another thread on the Fedora Server mailing list is to use D-BUS for the configuration API. Among other things, we have the D-BUS object types to work with. This would mean that we can have service-specific objects with appropriately-typed options. > * A package installation register its configuration options in a > system-wide "database". I'm not sure this makes sense. This would require us to maintain data in two places, because zero existing packages would *retrieve* their data from this location. We'd have a duplication problem and we would also be responsible for bi-directional sync (if someone hand-edited a configuration file, we'd need to read it back into the database). I think it makes more sense to build an API around something like Augeaus and rely on being able to read and write the configuration that the packages already understand. > * This also contains end-user visible text for each option > including i18n. I think it would be better to handle this at the API layer, rather than in a database. > * The debconf database may be populated via different front-ends: > GUI, TUI, command-line, web-based (experimental), preseed (for > "kickstart" install). > Again, if we build a sensible API, it should be possible to build whatever presentation layer we want to atop it. Of note, we're planning to work with the Cockpit Project for our reference implementation. > * All front ends need only understand the generic types of the > options. (I.e: they provide generic configuration UI widgets which > aren't modified when new packages/options are added) > I don't agree with this. Providing just a text entry box and a description isn't an effective UI technique, particularly if you want to be able to produce guided or wizard-based operation. (For example, if you have branching decisions during configuration). > * The debconf "API" allows fetching any option from the database > and the values of these options are used to configure the actual > software. > See above for the sync problem with this. > Note: I tried to abstract away the properties, because I don't > think the debconf *implementation* fits what we need. > > However, the model shows how very different packages can use a > common framework for basic configuration, just like RPM shows how > very different packages can use a common framework for > installation. > > Having such a framework would allow a *standard* way of configuring > a set of packages for specific roles. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLnr2IACgkQeiVVYja6o6PakwCeP8H/i/yakvVZhCXI0qSo1k84 tSwAn3rMeLFL6/FigFgk7LYqPwPA5OlQ =/tjT -----END PGP SIGNATURE-----

3 3

Summary/Minutes from today Fedora Server working group meeting (2014-01-28)
by Kevin Fenzi 28 Jan '14

28 Jan '14

=================================================================== #fedora-meeting-1: Server Working Group Weekly Meeting (2014-01-28) =================================================================== Meeting started by nirik at 16:00:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-28/fedora-meeting… . Meeting summary --------------- * roll call (nirik, 16:00:03) * no quorum, please continue lists and #fedora-server discussions on implementation. (nirik, 16:08:50) Meeting ended at 16:08:58 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (14) * zodbot (5) * adamw (2) * davidstrauss (2) * mitr (1) * Evolution (0) * tuanta (0) * sgallagh (0) * simo (0) * mizmo (0) -- 16:00:02 <nirik> #startmeeting Server Working Group Weekly Meeting (2014-01-28) 16:00:03 <zodbot> Meeting started Tue Jan 28 16:00:02 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:03 <nirik> #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr 16:00:03 <nirik> #topic roll call 16:00:03 <zodbot> Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta 16:00:09 <nirik> who all is around today? 16:00:14 <mitr> Hello all 16:00:19 * nirik knows several folks aren't so we may not have quorum. 16:01:00 <davidstrauss> hi 16:01:08 <davidstrauss> .hellomynameis davidstrauss 16:01:11 <zodbot> davidstrauss: davidstrauss 'David Strauss' <david(a)davidstrauss.net> 16:01:21 <nirik> .hellomynameis kevin 16:01:22 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin(a)scrye.com> 16:02:24 <nirik> thats 3... 16:04:04 <nirik> so, I guess we wait a few more and see if folks show up? or just take discussion to list? 16:06:14 <adamw> sorry, here 16:06:22 <adamw> but distracted by anaconda wording bikeshedding :) 16:06:40 <nirik> it's green! 16:06:49 <nirik> still only 4, so no quorum yet. 16:07:47 <nirik> so, I guess everyone go pick holes in my straw man post... and continue in #fedora-server then... 16:08:26 <nirik> thanks for coming everyone... 16:08:50 <nirik> #info no quorum, please continue lists and #fedora-server discussions on implementation. 16:08:58 <nirik> #endmeeting

1 0

Fedora Server PRD Draft and call for participation
by Stephen Gallagher 21 Jan '14

21 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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_Doc… -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLQUp4ACgkQeiVVYja6o6O8IwCcCIaNJEr919QgyB3XJC+2Ynqf 6PcAoJ2BpgMwi1NzdG2XBZ0nyEzlh9XZ =DINq -----END PGP SIGNATURE-----

14 24

Server WG Meeting Minutes (2014-01-21)
by Stephen Gallagher 21 Jan '14

21 Jan '14

1 0

Server WG Meeting Agenda (2014-01-21)
by Stephen Gallagher 21 Jan '14

21 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for the late agenda, I ended up on unplanned PTO yesterday. The primary agenda item this week should be getting start with implementation and scoping plans. We need to start figuring out exactly what our first round of deliverables are going to look like. Let's operate under the assumption that the PRD is going to be approved as-is and move ahead. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLecgsACgkQeiVVYja6o6PqrQCfd9kUX6GP8iNfS+SdrjYiWUji pRoAn17EnR7sRL+5YcfJ3PA3KNFI8n8S =BV6S -----END PGP SIGNATURE-----

1 0

Package Review Swap - Icinga 1.x? (Nagios fork)
by Shawn Starr 20 Jan '14

20 Jan '14

Hello folks, We're finally ready to begin review for Icinga 1.x https://bugzilla.redhat.com/show_bug.cgi?id=1055378 Any takers on reviewing for me? I'll grab one of your packages. Thanks, Shawn

2 2

Regrets for next week's meeting
by Máirín Duffy 16 Jan '14

16 Jan '14

Hi folks, I have an appointment I can't reschedule across town immediately before the Server WG meeting next Tuesday, so if I am able to make it I will be quite late. Sorry about this! ~m

1 0

Re: Fedora Server PRD Draft and call for participation
by Simo Sorce 16 Jan '14

16 Jan '14

----- Original Message ----- > > [1] > > https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_Doc… > > The draft document has been updated with all changes proposed at the > Working Group meeting yesterday and is now presumed to be effectively > complete. > > I respectfully request that all members of the Server Working Group > (CCed) respond with an approval vote, or if they feel something > requires changing, please describe it in detail. > > Given that we must submit this to FESCo and the Board by Monday, I am > setting a hard deadline on Friday at 1600 UTC for votes. +1 here too. Simo. -- --

1 0

Server WG Meeting Minutes (2014-01-14)
by Stephen Gallagher 14 Jan '14

14 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =================================================================== #fedora-meeting-1: Server Working Group Weekly Meeting (2014-01-14) =================================================================== Meeting started by sgallagh at 15:59:51 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-14/fedora-meeting… . Meeting summary - --------------- * roll call (sgallagh, 16:00:00) * PRD Draft (sgallagh, 16:06:04) * LINK: https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_Doc… (sgallagh, 16:07:13) * Positioning relative to Fedora Cloud (sgallagh, 16:08:33) * AGREED: remove use-case 7, move OpenStack Hypervisor Node reference to proposed Roles list (sgallagh, 16:55:00) * AGREED: Use case 8 remains as written (sgallagh, 17:08:38) * Use Case 6: Env/Stacks and deployment of frameworks (sgallagh, 17:09:14) * AGREED: drop "easy deployment of a framework" from our charter (sgallagh, 17:20:05) * FIXME for headless operation (sgallagh, 17:20:30) * AGREED: New use-case: "10. The user must be able to install and manage Fedora Server in a headless mode where the display framework is inactive." (sgallagh, 17:31:29) * Open Floor (sgallagh, 17:31:51) Meeting ended at 17:42:38 UTC. Action Items - ------------ Action Items, by person - ----------------------- * **UNASSIGNED** * (none) People Present (lines said) - --------------------------- * sgallagh (146) * simo (95) * davidstrauss (54) * mitr (52) * jzb (37) * mizmo (37) * nirik (35) * adamw (12) * tuanta (10) * zodbot (9) * number80 (4) * Evolution (3) * danofsatx (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLVd3IACgkQeiVVYja6o6OI3gCeJ7+P7P6HhMfqflZpgYudwZNW iwYAnRmdMkq3BDv6uXXt8Et3V2aU06Zl =7f+Y -----END PGP SIGNATURE-----

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server January 2014