Fedora Server Use Cases Prioritization

[Stephen Gallagher]

-----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)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlKzKPwACgkQeiVVYja6o6NC7ACfafYeZ3kLNem47KvknhIfVUGf
> rx4AnRcPyegQoZvfhDKWkE1/tN7nCiHC
> =7GD1
> -----END PGP SIGNATURE-----

[Marcela Mašláňová]

----- Original Message -----
> From: "Stephen Gallagher" 
> To: [e-mail]
> 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

[Stephen Gallagher]

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

On 12/20/2013 04:46 AM, Marcela Maslanova wrote:
> ----- Original Message -----
> > From: "Stephen Gallagher"  To:
> > [e-mail] 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlK0PFsACgkQeiVVYja6o6OW2ACcDve+sD/RvV23lf5ZyY/Fh6Ek
> A8AAn12zBQHpX/9zVdJzfARNUbc01feo
> =wgbI
> -----END PGP SIGNATURE-----

[Miloslav Trmač]

On Fri, Dec 20, 2013 at 10:46 AM, Marcela Maslanova  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

[Marcela Mašláňová]

On 01/02/2014 03:35 PM, Miloslav Trmač wrote:
> On Fri, Dec 20, 2013 at 10:46 AM, Marcela Maslanova  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

[Miloslav Trmač]

On Tue, Jan 7, 2014 at 12:46 PM, Marcela Mašláňová  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

[Simo Sorce]

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á  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

[Miloslav Trmač]

On Tue, Jan 7, 2014 at 5:10 PM, Simo Sorce  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

[Dan Mashal]

On Thu, Dec 19, 2013 at 9:12 AM, Stephen Gallagher  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

[Stephen Gallagher]

-----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
>  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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLFaakACgkQeiVVYja6o6MtsQCfUCGD9X3AZtefu6fgRtiq9Ich
> zFQAn2ofaqSitonl5+C1/qCqHlxBcm8n
> =/Acf
> -----END PGP SIGNATURE-----