Fedora server implementation straw man
by Kevin Fenzi
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
9 years, 9 months
Re: Fedora.next: I would like working configurations
by Stephen Gallagher
-----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-----
9 years, 10 months
Summary/Minutes from today Fedora Server working group meeting (2014-01-28)
by Kevin Fenzi
===================================================================
#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-meeti...
.
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
9 years, 10 months
Fedora Server PRD Draft and call for participation
by Stephen Gallagher
-----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_D...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLQUp4ACgkQeiVVYja6o6O8IwCcCIaNJEr919QgyB3XJC+2Ynqf
6PcAoJ2BpgMwi1NzdG2XBZ0nyEzlh9XZ
=DINq
-----END PGP SIGNATURE-----
9 years, 10 months
Server WG Meeting Minutes (2014-01-21)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-01-21)
===================================================================
Meeting started by sgallagh at 15:59:24 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-21/fedora-meeti...
.
Meeting summary
- ---------------
* roll call (sgallagh, 15:59:31)
* Post-PRD Steps (sgallagh, 16:08:30)
Meeting ended at 17:07:15 UTC.
Action Items
- ------------
Action Items, by person
- -----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (88)
* simo (51)
* nirik (49)
* adamw (33)
* mitr (33)
* davidstrauss (31)
* zodbot (6)
* Evolution (0)
* tuanta (0)
* mizmo (0)
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/
iEYEARECAAYFAlLeuuMACgkQeiVVYja6o6NvUACgh1L8Qxy9JnFjP0hYVWYRjBhb
9L4Anjp/pudQHRTX4tda5PYegVGRshez
=ve0k
-----END PGP SIGNATURE-----
9 years, 10 months
Server WG Meeting Agenda (2014-01-21)
by Stephen Gallagher
-----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-----
9 years, 10 months
Regrets for next week's meeting
by Máirín Duffy
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
9 years, 10 months
Re: Fedora Server PRD Draft and call for participation
by Simo Sorce
----- Original Message -----
> > [1]
> > https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_D...
>
> 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.
--
--
9 years, 10 months
Server WG Meeting Minutes (2014-01-14)
by Stephen Gallagher
-----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-meeti...
.
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_D...
(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-----
9 years, 11 months