-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Today at the overflow meeting, we came up with nine use cases that we believe we want to focus on with the Fedora Server product. We agreed that we want to list these in priority order, but I want to open this up to the wider server community so we can order these properly.
Please keep in mind that these use-cases are high-level and should not be construed to be exhaustive or exclusive. There are several items in this list that we need to coordinate with other working groups as well.
Please respond with your recommendations for the ordering of this list (assuming that all entries remain as they are) so we can get a sense of the relative importance of these items.
1) The user must be able to easily deploy and configure any supported Fedora Server role. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server, iSCSI target, File/Storage server.)
2) The user must be able to query, monitor, configure and manage a Fedora Server remotely using stable and consistent public interfaces.
3) The user must be able to simply enroll the Fedora Server into a FreeIPA or Active Directory domain.
4) Users must be able to control and contain the resources consumed by services running on the system.
5) Users must be able to rapidly re-deploy services in accordance with their DevOps practices using Fedora Server.
6) ASK SOFTWARE COLLECTIONS WG The user must be able to easily deploy and configure applications to supported high-value frameworks. (Example frameworks: JBoss, Ruby on Rails, Django, Turbogears, Node.js, PHP.)
7) ASK CLOUD WG Provide a platform for acting as a node in an OpenStack rack.
8) ASK CLOUD WG Users must be able to create, manipulate and terminate large numbers of containers using a stable and consistent interface.
9) Users must be able to use Fedora Server in fully headless operation. We commit to supporting only those GUI applications that can work with forwarded X (or the equivalent on other windowing systems)
----- Original Message -----
From: "Stephen Gallagher" sgallagh@redhat.com To: server@lists.fedoraproject.org Sent: Thursday, December 19, 2013 6:12:28 PM Subject: Fedora Server Use Cases Prioritization
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Today at the overflow meeting, we came up with nine use cases that we believe we want to focus on with the Fedora Server product. We agreed that we want to list these in priority order, but I want to open this up to the wider server community so we can order these properly.
Please keep in mind that these use-cases are high-level and should not be construed to be exhaustive or exclusive. There are several items in this list that we need to coordinate with other working groups as well.
Please respond with your recommendations for the ordering of this list (assuming that all entries remain as they are) so we can get a sense of the relative importance of these items.
- The user must be able to easily deploy and configure any supported
Fedora Server role. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server, iSCSI target, File/Storage server.)
- The user must be able to query, monitor, configure and manage a
Fedora Server remotely using stable and consistent public interfaces.
- The user must be able to simply enroll the Fedora Server into a
FreeIPA or Active Directory domain.
- Users must be able to control and contain the resources consumed by
services running on the system.
- Users must be able to rapidly re-deploy services in accordance with
their DevOps practices using Fedora Server.
- ASK SOFTWARE COLLECTIONS WG The user must be able to easily deploy
and configure applications to supported high-value frameworks. (Example frameworks: JBoss, Ruby on Rails, Django, Turbogears, Node.js, PHP.)
We didn't speak about easy deployment and configuration. We were discussing possibility of automatic packaging or updates of these packages. Do you have any specific goals for Env and Stack WG on your mind? Which technologies to use etc.
Marcela
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/20/2013 04:46 AM, Marcela Maslanova wrote:
----- Original Message -----
From: "Stephen Gallagher" sgallagh@redhat.com To: server@lists.fedoraproject.org Sent: Thursday, December 19, 2013 6:12:28 PM Subject: Fedora Server Use Cases Prioritization
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Today at the overflow meeting, we came up with nine use cases that we believe we want to focus on with the Fedora Server product. We agreed that we want to list these in priority order, but I want to open this up to the wider server community so we can order these properly.
Please keep in mind that these use-cases are high-level and should not be construed to be exhaustive or exclusive. There are several items in this list that we need to coordinate with other working groups as well.
Please respond with your recommendations for the ordering of this list (assuming that all entries remain as they are) so we can get a sense of the relative importance of these items.
- The user must be able to easily deploy and configure any
supported Fedora Server role. (Examples may include: FreeIPA Domain Controller, BIND DNS, DHCP, Database server, iSCSI target, File/Storage server.)
- The user must be able to query, monitor, configure and manage
a Fedora Server remotely using stable and consistent public interfaces.
- The user must be able to simply enroll the Fedora Server into
a FreeIPA or Active Directory domain.
- Users must be able to control and contain the resources
consumed by services running on the system.
- Users must be able to rapidly re-deploy services in accordance
with their DevOps practices using Fedora Server.
- ASK SOFTWARE COLLECTIONS WG The user must be able to easily
deploy and configure applications to supported high-value frameworks. (Example frameworks: JBoss, Ruby on Rails, Django, Turbogears, Node.js, PHP.)
We didn't speak about easy deployment and configuration. We were discussing possibility of automatic packaging or updates of these packages. Do you have any specific goals for Env and Stack WG on your mind? Which technologies to use etc.
Our definition of "easy" is intentionally vague here. I'm not sure on which side of the fence we need to do the simple configuration and deployment.
On the one hand, the Fedora Workstation will want to be able to quickly and easily set up an application to work on. This might just be a simple package/SCL like we have today. On the Fedora Server side, we're going to want to be able to take an application built by Fedora Workstation and deploy it (possibly in a continuous deployment scenario). That might mean doing something more like OpenShift cartridges, where the configuration is part of the definition of the application.
We agreed in the meeting that before we made that a formal piece of the Server WG, we would consult with the Env/Stacks group on what options we could have to implement it.
On Fri, Dec 20, 2013 at 10:46 AM, Marcela Maslanova mmaslano@redhat.com wrote:
- ASK SOFTWARE COLLECTIONS WG The user must be able to easily deploy
and configure applications to supported high-value frameworks. (Example frameworks: JBoss, Ruby on Rails, Django, Turbogears, Node.js, PHP.)
We didn't speak about easy deployment and configuration. We were discussing possibility of automatic packaging or updates of these packages. Do you have any specific goals for Env and Stack WG on your mind? Which technologies to use etc.
I think the "deploy and configure" aspect for specific server uses (e.g. how to get from an application package to an installed and running database and web server) would be handled by Server and Cloud products; what we would like to get from software collections or something similar is a way to _run_ an application (e.g. have all dependencies available, without focusing on the web server in particular), in a way that can be shipped within the Server product. Mirek
On 01/02/2014 03:35 PM, Miloslav Trmač wrote:
On Fri, Dec 20, 2013 at 10:46 AM, Marcela Maslanova mmaslano@redhat.com wrote:
- ASK SOFTWARE COLLECTIONS WG The user must be able to easily deploy
and configure applications to supported high-value frameworks. (Example frameworks: JBoss, Ruby on Rails, Django, Turbogears, Node.js, PHP.)
We didn't speak about easy deployment and configuration. We were discussing possibility of automatic packaging or updates of these packages. Do you have any specific goals for Env and Stack WG on your mind? Which technologies to use etc.
I think the "deploy and configure" aspect for specific server uses (e.g. how to get from an application package to an installed and running database and web server) would be handled by Server and Cloud products; what we would like to get from software collections or something similar is a way to _run_ an application (e.g. have all dependencies available, without focusing on the web server in particular), in a way that can be shipped within the Server product. Mirek
I'd say it's working fine now. If you think it's not true, then you have to go into more detail. We stated our task [1], but nothing like that was mentioned. There's currently more technologies for "deployment" - cartridges, rpms, collections, images. Hard to say, which one will be favourite.
[1] https://fedoraproject.org/wiki/User:Mmaslano/Draft:Env_and_Stack_PRD#Tasks
Marcela
On Tue, Jan 7, 2014 at 12:46 PM, Marcela Mašláňová mmaslano@redhat.com wrote:
I think the "deploy and configure" aspect for specific server uses (e.g. how to get from an application package to an installed and running database and web server) would be handled by Server and Cloud products; what we would like to get from software collections or something similar is a way to _run_ an application (e.g. have all dependencies available, without focusing on the web server in particular), in a way that can be shipped within the Server product. Mirek
I'd say it's working fine now. If you think it's not true, then you have to go into more detail.
At this very moment, I'm holding off upgrading to F20 because my Rails application (set up to run against the system-wide RPMs) will no longer work.
Now I'm not saying that the sky is falling, or that this must necessarily be solved by having RPMs of everything within Fedora; however if we want Server to allow deploying "e.g. Rails applications" and if I'm allowed to interpret that as "applications using e.g. Rails without having been ported to the very last version", we need a reasonably supportable mechanism that doesn't expose our users to unmanageable security vulnerabilities.
For all I know, perhaps "just use upstream gems" might be an acceptable solution... I'm not sure how I'd feel about requiring an explicitly-out-of-Fedora COPR repo.
In any case, do need to agree on an approach. Mirek
On Tue, 2014-01-07 at 16:19 +0100, Miloslav Trmač wrote:
On Tue, Jan 7, 2014 at 12:46 PM, Marcela Mašláňová mmaslano@redhat.com wrote:
I think the "deploy and configure" aspect for specific server uses (e.g. how to get from an application package to an installed and running database and web server) would be handled by Server and Cloud products; what we would like to get from software collections or something similar is a way to _run_ an application (e.g. have all dependencies available, without focusing on the web server in particular), in a way that can be shipped within the Server product. Mirek
I'd say it's working fine now. If you think it's not true, then you have to go into more detail.
At this very moment, I'm holding off upgrading to F20 because my Rails application (set up to run against the system-wide RPMs) will no longer work.
We had to advise FreeIPA users to hold the same way at GA, but we fixed the breakage and gave the green light now.
Now I'm not saying that the sky is falling, or that this must necessarily be solved by having RPMs of everything within Fedora; however if we want Server to allow deploying "e.g. Rails applications" and if I'm allowed to interpret that as "applications using e.g. Rails without having been ported to the very last version", we need a reasonably supportable mechanism that doesn't expose our users to unmanageable security vulnerabilities.
This is Collections territory though ...
For all I know, perhaps "just use upstream gems" might be an acceptable solution... I'm not sure how I'd feel about requiring an explicitly-out-of-Fedora COPR repo.
In any case, do need to agree on an approach.
ack
On Tue, Jan 7, 2014 at 5:10 PM, Simo Sorce simo@redhat.com wrote:
Now I'm not saying that the sky is falling, or that this must necessarily be solved by having RPMs of everything within Fedora; however if we want Server to allow deploying "e.g. Rails applications" and if I'm allowed to interpret that as "applications using e.g. Rails without having been ported to the very last version", we need a reasonably supportable mechanism that doesn't expose our users to unmanageable security vulnerabilities.
This is Collections territory though ...
Could be. So do we make Collections (and the ability to install Collections) a dependency of some Fedora Server roles? Mirek
On Thu, Dec 19, 2013 at 9:12 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Please respond with your recommendations for the ordering of this list (assuming that all entries remain as they are) so we can get a sense of the relative importance of these items.
I think the ordering is good.
I know it's early and I realize that this is a rough draft but I would like to see more specific plans (including development of gui administration tools), expansion of roles as we discussed in a previous thread.
Dan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/01/2014 07:37 AM, Dan Mashal wrote:
On Thu, Dec 19, 2013 at 9:12 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Please respond with your recommendations for the ordering of this list (assuming that all entries remain as they are) so we can get a sense of the relative importance of these items.
I think the ordering is good.
I know it's early and I realize that this is a rough draft but I would like to see more specific plans (including development of gui administration tools), expansion of roles as we discussed in a previous thread.
This is a use-cases document, not an implementation document. The goal here is to describe a set of use-cases we want to address. The explicit non-goal of a use-case document would be selecting a particular solution. That's a job for an execution document.
server@lists.fedoraproject.org
-
Dan Mashal -
Marcela Mašláňová -
Miloslav Trmač -
Simo Sorce -
Stephen Gallagher