-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthew Miller brought to my attention that a group of people within
the CentOS Project have kicked off a proposal[1] for a CentOS variant
focused around a small, turnkey server that simplifies the
installation of certain common server operations.
Reading through the proposal, it struck me that there's a very
significant overlap between what they want to accomplish and what we
in Fedora Server have set out to do as well. I approached them today
in #centos-devel to bring our efforts to their attention.
The response was quite favorable and several of the people involved
with the SLS SIG will be reviewing our PRD and Technical Specification
and plan to join us for our meeting on Tuesday.
If you happen to hear from filippoc (Filippo Carletti) or gsanchietti
(Giacomo Sanchietti), particularly if they're looking for more
information, please give them a hand. It would be excellent for us to
work closely with CentOS on this, since the end result will benefit
both projects significantly.
[1] http://wiki.centos.org/SpecialInterestGroup/SLS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlN8rBYACgkQeiVVYja6o6MJ2QCdEUVy2/bqG1eC4/vMEKT0h2aO
ilUAoJy1Vex/Jbh1m1s7J7cD3dUFEn2h
=Mze9
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-05-20)
===================================================================
Meeting started by sgallagh at 14:59:28 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-05-20/fedora-meeting…
.
Meeting summary
- ---------------
* roll call (sgallagh, 14:59:37)
* Primary Work Projects for Fedora Server 21 (sgallagh, 15:05:00)
* Work Project: Release Engineering (sgallagh, 15:05:59)
* Work Project: Branding / Project Identity (sgallagh, 15:06:12)
* Work Project: Server Roles (sgallagh, 15:06:23)
* Work Project: Branding / Project Identity (sgallagh, 15:09:22)
* LINK: https://fedorahosted.org/cloud/ticket/3 (mizmo, 15:09:42)
* Q: (1) What problem does your product solve, in one sentence?
(sgallagh, 15:12:16)
* A: (1) Fedora Server is a server operating system that provides a
new set of integrated tools for the installation and management of
network-based infrastructure services. (sgallagh, 15:25:29)
* Q: (2) Who is the target audience for your product, in one sentence?
(sgallagh, 15:31:54)
* A: (2) System administrators building and maintaining a stable
environment in support of users and applications (sgallagh,
15:32:06)
* Q: (4) List at least 5 products that try to solve the same problem
(sgallagh, 15:47:29)
* A: (4) Successful: "RHEL+clones, Windows Server, SLES, HPUX,
Solaris, AIX" (sgallagh, 15:47:43)
* A: (4) Not as successful: OS X Server, Ubuntu Server (sgallagh,
15:47:52)
* Q: (3) List at least 5 products that successfully target the same
target (sgallagh, 15:48:03)
* (3) A: USENIX/ LISA, O'Reilly books, StackExchange, ArsTechnica,
Cisco (mizmo, 15:53:03)
* Work Project: Server Roles (sgallagh, 15:54:35)
* sgallagh to shepherd the Server Role effort (sgallagh, 15:56:07)
* Work Project: Release Engineering (sgallagh, 15:56:17)
* nirik to shepherd the Release Engineering effort (sgallagh,
15:58:38)
* Open Floor (sgallagh, 15:58:43)
Meeting ended at 16:07:33 UTC.
Action Items
- ------------
Action Items, by person
- -----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* mizmo (126)
* sgallagh (121)
* simo (24)
* nirik (22)
* danofsatx-work (18)
* mitr (14)
* zodbot (7)
* stefw (5)
* adamw (0)
* tuanta (0)
* davidstrauss (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/
iEYEARECAAYFAlN7flUACgkQeiVVYja6o6MRpQCfevZGMH3wNEX1KhY4J9omhXKE
4RAAn3w3a0Ae563+BYSKQ0nohfuH79IJ
=5TaN
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry for forgetting to send out a call for agenda this week and
sending this agenda late. I've had two sick kids.
As the Feature Freeze rapidly approaches (July 22nd), we need to focus
on our three main projects for this Product:
* Release Engineering
* Branding / Product Identity
* Server Roles
I'd like to discuss in the meeting today what our strategy is for
delivering these three things on time, as well as selecting a shepherd
for each of them (I'm volunteering to do that job for the server roles).
If anyone has other agenda items this week, we'll try to get to them
after we cover these topics.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlN7N/oACgkQeiVVYja6o6OtFACfZjFKEaafc4P8hJ2d0h/aIVgv
TY8An1LPMs6n1jDHEr3AYlzAzUnl1mZy
=IkQU
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is languishing a bit and we're running out of time.
I've got some high-level requirements listed at
https://www.piratepad.ca/p/ServerRoleRequirements (copied below,
better formatted on the Piratepad)
We need to define the interface and start implementation soon, as we
only have seven weeks until Alpha freeze.
Requirements:
* Must be able to install all necessary packages for a Server
RoleRequirements:
* Must be able to install all necessary packages for a Server Role
* Using yum/comps "groups" for this is acceptable
* Must provide a plugin architecture for each available Server Role
* Must be able to indicate the set of system services that should be
running (based on the current configuration)
* Must be able to indicate the set of ports that need to be open to
public, private or both types of networks.
* Must be able to individually open ports presented above on
specific interfaces.
* Must be able to query the current state of required ports and
system services.
* Apart from "indicating" properties, the typical uses should also
be in the API provider and not the clients. Notably, "install and set
up a role", and later "upgrade role" are API calls.
* (Nice-to-have/future) Must be able to report a list of files for
backup software to key off
* (Nice-to-have/proposed) List configuration files differing from
defaults installed via RPM and not accounted for by RPM installations;
show diff (if altered) and allow reverting
* (Nice-to-have/proposed) procfs integration to see processes (and
related services) mapping replaced/deleted executables and libraries
* Eventually: access to major configuration items (those cockpit
would want to manage in its UI)
* stefw: I think the cockpit ui for configuring a role would be a
per-role cockpit plugin (ie: likely not via a generic API, via role
specific APIs, and or tools)..
* Eventually: Monitoring integration (undefined what to integrate
with ATM)
* The daemon implementing this (important but rarely used) server
role API must exit when not in use.
* "not in use" means that all DBus clients which have invoked
methods have gone away.
* What is the plan with openLMI for example?
* its providers are subprocesses that exit when not in use,
and as such their dbus connections close.
Considerations:
* The set of Roles will be small. It is not required that we build a
generic API that can handle all possible cases. It is permissible for
individual Roles to have their own custom API.
Cockpit Notes:
* Likely cockpit will not perform installs against a generic API,
but a per-role tool or API
* ie: ipa-server-install is very close to what you need to install IPA
* Likely cockpit will want to see state and status of installed
server roles via a generic API:
* List of installed roles.
* What set of systemd services comprise a role
* Mount points that contain the role's "data"
* When the role was installed
* Networking ports and routes required by the role.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlN5+ScACgkQeiVVYja6o6Ny1ACfeIBwfl7gTxg+NArukRvDqUb7
CSUAoJRq8yLKl7u5oRwX0bUZM0CKhNVm
=ibGw
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What shall we discuss this week? We said we'd continue the API
discussions on the list, so do we have anything that would benefit
from a high-bandwidth meeting?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNs9ewACgkQeiVVYja6o6OuDQCeJ0w8k1En+TUbHlgV3yXstmi7
cxEAn2V5/dFSaOSYnoB3vA8uLLNhVH4e
=sFbq
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
One thing that we haven't finished discussing (and need to settle on
sooner rather than later) is exactly what installation media we are
going to distribute. We are certainly going to distribute a DVD/USB
media (which also implies creation of an installable tree that can be
used over a network with virt-install).
The PRD also calls for a generic network install of one kind or
another. It has been unclear in past discussions how we plan to handle
that. If I remember correctly, two approaches have been suggested:
1) We build a traditional netinstall with anaconda included on it and
point it at the installable tree on the mirrors based on the DVD.
Advantage: Tooling is already available. No additional trees need to
be specified. Potentially can be shared with Workstation if we
coordinate it.
2) We use boot.fedoraproject.org and add entries for the Fedora Server
in the installation selection
Advantage: Allows us to potentially address serious bugs in Anaconda
after the stable release. Smaller install media download.
One additional thing to note is that with the network install media,
we should probably default to allowing access to the full Fedora
repositories and on the DVD/USB media we should make this an easy
option to enable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNqI0gACgkQeiVVYja6o6OB3wCfSZHAFiOl6r3IZvswBqiiGfOc
Z2MAn0CLmG/WMyNDnIRQ26dIIGu28qXE
=u2TQ
-----END PGP SIGNATURE-----